• No subcommand given: Ask the user what they want. Present the available commands.
• No path given: Use the current working directory.
• Phase 3 stubs: If the user invokes

  diff

  or

  report

  , respond: "This feature is coming in Phase 3. Available now: audit, solid, security, smells, architecture, patterns, performance, errors, tests, framework, quick."

1. Use Glob to scan file extensions at the target path (recursive, reasonable depth).
2. Apply the following detection rules — multiple stacks can match simultaneously:

.php

references/php-laravel.md

.js

.ts

.jsx

.tsx

references/javascript-typescript.md

.py

references/python.md

.jsx

.tsx

next.config.*

references/react-nextjs.md

.sql

migrations/

references/sql-database.md

routes/

references/api-design.md

1. For each detected stack, attempt to load the corresponding reference file using Read. If the file does not exist yet (Phase 2+), skip silently.
2. Collect all loaded references into a context bundle to pass to sub-skills.

• If absent: All defaults apply. No error.

• severity_overrides

  : Pass to sub-skills so they adjust thresholds accordingly.

• skip_categories

  : Do not invoke the listed sub-skills, even in

  audit

  or

  quick

  mode.

• skip_rules

  : Pass to sub-skills so they suppress findings with matching IDs.

• framework

  : If set, skip auto-detection for that framework and force-load the corresponding reference. Other auto-detection still proceeds.

• extra_references

  : Additional reference file paths to load and pass to sub-skills.

• report_format

  : Output format preference (default:

  markdown

  ).

1. Read the shared preamble from

   shared-preamble.md

   (in this skill's directory). This contains the output contract, execution modes, and constraints shared by all sub-skills.
2. Read all source files at the target path:
   • Use Glob to find all source files (

     .ts

     ,

     .tsx

     ,

     .js

     ,

     .jsx

     ,

     .py

     ,

     .php

     ,

     .vue

     ,

     .sql

     ,

     .css

     ,

     .scss

     and config files like

     next.config.*

     ,

     package.json

     ,

     composer.json

     ,

     requirements.txt

     ,

     .env.example

     ).
   • Read each file using Read.
   • Size cap: If the codebase has more than 50 source files or total LOC exceeds 10,000 lines, do NOT pre-load all files. Instead, pass only the file listing (paths + line counts) and let sub-agents read files they need. Note this in the agent prompt: "Large codebase — file listing provided, use Read for files you need to inspect."
   • Store all file contents as a map:

     {filepath: content}

     .
3. Read all applicable reference files (already loaded during stack detection in Section 2). Store the content.

1. The shared preamble (from

   shared-preamble.md

   ) — output contract, modes, constraints.
2. The sub-skill name to invoke (e.g.,

   codeprobe-security

   ).
3. The mode — one of

   full

   or

   scan

   .
4. Pre-loaded source files — the full content of every source file, formatted as:

   === FILE: {filepath} ===
   {content}
   === END FILE ===

5. Pre-loaded references — the content of all applicable reference files.
6. Config overrides — severity overrides and skip rules from

   .codeprobe-config.json

   .
7. Target path — so the sub-skill knows the project root for any targeted lookups.
8. Sub-skill-specific pre-loaded script output (when applicable):
   • For

     codeprobe-architecture

     : before spawning the agent, run

     python3 scripts/dependency_mapper.py <target_path>

     via Bash and capture the JSON output. Pass it as an additional context block labeled

     === DEPENDENCY_GRAPH === ... === END DEPENDENCY_GRAPH ===

     . The sub-skill uses this as the ground truth for cycle detection. If Python 3 is unavailable or the script fails, omit the block — the sub-skill falls back to LLM-based import tracing.
   • For

     codeprobe-performance

     : if

     scripts/complexity_scorer.py

     output is available (optional), pass it as

     === COMPLEXITY_SCORES === ... === END COMPLEXITY_SCORES ===

     .

• /codeprobe audit

  : Run sub-skills sequentially in this order:

  codeprobe-security

  ,

  codeprobe-error-handling

  ,

  codeprobe-solid

  ,

  codeprobe-architecture

  ,

  codeprobe-patterns

  ,

  codeprobe-performance

  ,

  codeprobe-code-smells

  ,

  codeprobe-testing

  ,

  codeprobe-framework

  — all in

  full

  mode. Before invoking

  codeprobe-architecture

  , pre-compute the dependency graph via

  scripts/dependency_mapper.py

  and pass the JSON to the sub-skill as described in the Invocation Protocol (step 8). Collect all findings. Apply deduplication (Section 7A). Derive category scores from severity counts. Compute hot spots by aggregating findings per file and ranking by distinct-categories-flagged. Also run

  scripts/file_stats.py

  for codebase stats (skip gracefully if Python 3 unavailable).

• /codeprobe quick

  : Run all 9 sub-skills in

  scan

  mode. Collect candidate issues from all. Rank by severity (critical > major > minor > suggestion), then select top 5. Re-run relevant sub-skills in

  full

  mode for just those 5 findings to get complete detail.

1. codeprobe-security

   — Security vulnerability detection

2. codeprobe-error-handling

   — Error handling & resilience

3. codeprobe-solid

   — SOLID principles analysis

4. codeprobe-architecture

   — Architecture analysis

5. codeprobe-patterns

   — Design patterns advisor

6. codeprobe-performance

   — Performance & scalability

7. codeprobe-code-smells

   — Code smell detection

8. codeprobe-testing

   — Test quality & coverage

9. codeprobe-framework

   — Framework-specific best practices

Lines 45-50:

public function authenticate($credentials) { ... }

Lines 52-60:

public function sendWelcomeEmail($user) { ... }

Lines 62-67:

public function findByUsername($name) { ... }

UserMailer

UserRepository

Refactor

src/UserService.php

to follow Single Responsibility Principle: extract

sendWelcomeEmail()

into a new

UserMailer

class and

findByUsername()

into a

UserRepository

class. Keep

authenticate()

in

UserService

and inject the new dependencies.

---

• Missing tests (even for critical business logic)
• Code duplication or large classes/files
• Code smells of any kind
• Framework convention violations
• Missing documentation, comments, or type annotations

• Confirmed bugs (code that produces wrong results or crashes)
• Exploitable security vulnerabilities (injection, auth bypass, IDOR with proof)
• Data loss or corruption risks (missing transactions, race conditions on writes)
• Sensitive data exposure (secrets in code, credentials in logs)

1. Group findings by location. Normalize each finding's

   location

   to

   {file}:{start_line}

   . Two findings overlap if they share the same file AND their line ranges overlap (i.e., start_line_A <= end_line_B AND start_line_B <= end_line_A).
2. For each group of overlapping findings from different categories: a. Select a primary finding. Use this priority order:
   • Security findings (SEC) take priority for anything involving auth, injection, or data exposure
   • Error Handling findings (ERR) take priority for exception/validation issues
   • Performance findings (PERF) take priority for query/caching issues
   • SOLID findings (SRP/OCP/LSP/ISP/DIP) take priority for structural violations
   • Architecture findings (ARCH) take priority for layer/boundary violations
   • If still ambiguous, the category with the higher weight (Section 7) wins b. Mark duplicates. For each non-primary finding in the group, append to its

     problem

     field:

     [Duplicate of {primary_id} — counted there]

     and change its severity to

     suggestion

     so it does not affect the score of its own category. c. Cross-reference the primary. Append to the primary finding's

     suggestion

     field:

     Also flagged by: {list of duplicate category:id pairs}

3. Recount severity totals per category after deduplication, then proceed to scoring.

• "Refresh bypasses quota" found as SEC-007, ERR-011, FW-001 at same location: keep SEC-007, mark ERR-011 and FW-001 as duplicates (severity → suggestion).
• "God component" found as SRP-001, SMELL-001, ARCH-005 at same file: keep SRP-001 (SOLID priority for structural), mark others as duplicates.
• Same SRP violation found as SRP-001 and SMELL-001: keep SRP-001, mark SMELL-001 as duplicate.

1. Run sub-skills per Section 4, collect findings, deduplicate per Section 7A.
2. Derive category scores, overall score, hot spots, codebase stats.
3. Assemble an in-memory "report bundle":

   {dashboard_data, exec_summary, critical[], major[], minor_counts[], suggestion_counts[], fix_order[]}

   .

+N lines (ctrl+r to expand)

scripts/render_dashboard.py

/codeprobe audit

1. Dashboard (markdown) — emit the dashboard block inline. Include: title line (

   ## Code Health Report — {project}

   ),

   **Overall Health:** {score}/100 [{status_label}]

   , the 9-row Category Scores markdown table with columns

   Category | Score | Bar | Status

   (bar wrapped in backticks, 20-char Unicode

   █

   /

   ░

   proportional to score), codebase stats block (files, LOC, backend/frontend split, largest file, test ratio, comment ratio), and a hot-spots list (up to 3 entries). Status labels plain text in the Status column, no emoji, no brackets inside the table.
2. Executive Summary — 2-3 sentences covering the most important findings.
3. Critical findings — full detail — for each critical finding: ID, location, problem, evidence, suggestion, fix prompt. This is the highest-signal section; always show in the terminal.
4. Prioritized Fix Order (top 5) — the first 5 entries from the full prioritized fix order. Reference the saved file for the complete list.
5. Save confirmation line —

   --> Report saved to ./codeprobe-reports/{project}-{cmd}-{YYYY-MM-DD-HHMMSS}.md

   (no emoji; ASCII arrow). This is the LAST line in the terminal output.

1. Build the full markdown using

   templates/full-audit-report.md

   placeholders — this includes sections that are NOT streamed to the terminal (major findings table, minor/suggestion counts, full prioritized fix order).
2. Derive the filename as

   {project}-{cmd}-{YYYY-MM-DD-HHMMSS}.md

   :

   • {project}

     — resolve the target path to an absolute path (use the current working directory if the user passed no path); take its basename; if that basename points to a file, strip the extension; slugify it (lowercase; replace any run of

     [^a-z0-9]+

     with a single

     -

     ; trim leading/trailing

     -

     ); fall back to

     unknown

     if the slug ends up empty.

   • {cmd}

     — the subcommand routed in Section 1 (

     audit

     ,

     quick

     ,

     security

     ,

     solid

     ,

     architecture

     ,

     performance

     ,

     errors

     ,

     tests

     ,

     smells

     ,

     patterns

     ,

     framework

     ), lowercased.

   • {YYYY-MM-DD-HHMMSS}

     — current local time.
3. Ensure

   ./codeprobe-reports/

   exists (

   mkdir -p ./codeprobe-reports

   via Bash if missing).
4. Write to

   ./codeprobe-reports/{project}-{cmd}-{YYYY-MM-DD-HHMMSS}.md

   using the

   Write

   tool.
5. If the write fails (read-only filesystem, permission denied, etc.), surface a short inline note in the terminal but do not re-emit the summary.

• The terminal MUST include (in this order): dashboard → exec summary → critical findings → top 5 fix order → "Report saved" line.
• If there are zero critical findings, show the dashboard, exec summary, a one-line "No critical issues found" note, top 5 fix order (will be major-only), and save confirmation — still non-empty.
• If the report save fails, still emit the full terminal summary — do not block the summary on the file write.
• If the template file is missing, render inline following the same section ordering; the save step (C) still applies.

• 80-100 = "Healthy"
• 60-79 = "Needs Attention"
• 0-59 = "Critical"

/codeprobe security .

templates/quick-review-summary.md

1. Header: Project name, "Quick Review — Top 5 Issues".
2. Top 5 Findings: Full detail for the 5 most impactful issues, each with fix prompt.
3. Summary Counts: Total issues found by severity across all categories.
4. Next Step: Suggest running

   /codeprobe audit

   for the complete picture.

1. Switch to degraded mode: Analyze only the in-context code provided.
2. Execute sub-skills sequentially on the pasted code (no parallel agents).
3. Skip

   file_stats.py

   ,

   dependency_mapper.py

   , and all script-dependent steps (sub-skills fall back to LLM-only analysis — architecture loses deterministic cycle detection).
4. Skip

   /codeprobe diff

   ,

   /codeprobe report

   , the Codebase Stats row of the audit dashboard, and the report-save step (no filesystem write). Still render scores, hot spots, and findings to the terminal.
5. Inform the user: "Running in Claude.ai mode — some features like codebase statistics, diff review, and multi-file analysis are unavailable. Analyzing the provided code directly."
6. Still produce findings in the standard output contract format.
7. Still compute scores based on findings from available sub-skills.

Not yet available. This feature is coming in Phase 3. Currently available commands:

• /codeprobe audit <path>

  — Full code audit

• /codeprobe solid <path>

  — SOLID principles check

• /codeprobe security <path>

  — Security audit

• /codeprobe smells <path>

  — Code smells detection

• /codeprobe architecture <path>

  — Architecture analysis

• /codeprobe patterns <path>

  — Design patterns analysis

• /codeprobe performance <path>

  — Performance audit

• /codeprobe errors <path>

  — Error handling audit

• /codeprobe tests <path>

  — Test quality audit

• /codeprobe framework <path>

  — Framework best practices

• /codeprobe quick <path>

  — Top 5 issues

diff

report

/codeprobe

1. Parse command: Extract subcommand and target path from user input.
2. Validate command: Check routing table. If Phase 3 stub, respond with stub message.
3. Resolve target path: Use provided path or default to current working directory.
4. Load config: Check for

   .codeprobe-config.json

   at project root. Apply defaults if absent.
5. Auto-detect stack: Scan target path for technology signals. Load matching references.
6. Apply config overrides: If

   framework

   is set in config, adjust detection. Apply

   skip_categories

   and

   skip_rules

   .
7. Execute sub-skills: Route to appropriate sub-skills based on command and mode.
8. Collect findings: Aggregate all findings in the output contract format.
9. Deduplicate findings: Apply the cross-category deduplication procedure (Section 7A). Adjust severity of duplicates to

   suggestion

   . Recount severity totals per category.
10. Compute scores: Calculate per-category and overall scores using the post-deduplication severity counts and the formulas in Section 7.
11. Render report: Format output using the appropriate template or inline format. Use the tiered output format for

    /codeprobe audit

    .
12. Present to user: Display the final report.