Check a codebase for known dependency vulnerabilities, hard-coded secrets, and risky code patterns using Ruflo security tools. Choose a scan depth, inspect matching lines, and report verified concerns with a clear account of what was checked.
Run full security scans on the codebase using Ruflo security tools. Use when reviewing PRs for security regressions, auditing auth/input-handling code, before production deploys, or when the user asks for a security check at quick/standard/deep depth.
Review the instructions the agent will receive before you install.
Run a security scan at the specified depth.
Via CLI:
npx @claude-flow/cli@latest security scan --depth DEPTH --output json
npx @claude-flow/cli@latest security cve --list
npx @claude-flow/cli@latest security threats --model stride --export md
What the scan really does (v3/@claude-flow/cli/src/commands/security.ts): phase 1 runs npm audit for dependencies, phase 2 greps for hard-coded secrets, phase 3 greps source for risky code patterns. --type deps|code|all picks phases; --depth only sets how many directory levels phases 2 and 3 descend:
| Depth | Dependencies | Secrets (levels) | Code patterns (levels) |
|---|---|---|---|
| quick | yes | 3 | skipped |
| standard | yes | 5 | 5 |
| deep | yes | 10 | 10 |
It is a pattern scanner, not a taint or auth-flow analyser, and security threats is a separate STRIDE/DREAD/PASTA template, not a scan of your code. Treat every finding as a lead, not a verdict: open the file at the reported line before reporting it, and drop matches in comments, error strings, generated bundles (coverage/, playwright-report/) and test fixtures. Say which of the phases above you ran and which you did not.
Store findings via MCP: mcp__plugin_ruflo-core_ruflo__memory_store({ key: "scan-findings", value: "SUMMARY", namespace: "security-findings" })
Train patterns: mcp__plugin_ruflo-core_ruflo__hooks_post-task({ taskId: "security-scan", success: true, storeResults: true })
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Compare models available through the HuggingFace router with chat-ui configuration, research missing models, and write short English descriptions of their architecture and capabilities. Add entries to both production and development configuration files and commit the changes.
Create an Architecture Decision Record, a document for recording important design choices, with the next sequential number. It generates a Markdown template, registers the record in AgentDB, and links related decisions found through search.
Build a searchable index and relationship graph from ADRs, records of architectural decisions. Import two supported document formats, refresh existing metadata without duplicate relationships, and review summaries of statuses, missing references, and inconsistencies.
Rebuild the index of ADRs, records of architectural decisions, after files or relationship lines are deleted. It clears stored records and relationships, indexes the files still present, and checks that the final record count matches.
Review code changes against accepted Architecture Decision Records, documents that capture agreed design choices. Report violations, outdated references, compliant changes, and areas without ADR coverage, then suggest code fixes or a new decision record where appropriate.
Check saved architecture decision records (ADRs) for broken references, circular replacement relationships, and inconsistent statuses. Use the results to verify imported records or stop a CI check when selected integrity rules fail.