audit
Project health audit and health check — architecture, performance, tests, dependencies, code quality. Use when assessing overall project health, before releases, or after refactors.
Install
npx skills add https://github.com/oliver-kriska/claude-elixir-phoenix/tree/main/plugins/elixir-phoenix/skills/audit
claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install oliver-kriska-claude-elixir-phoenix@llmmart
git clone https://github.com/oliver-kriska/claude-elixir-phoenix.git
The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole oliver-kriska/claude-elixir-phoenix collection as a plugin from our marketplace. Git is the plain clone.
Skill manifest
Project Health Audit
Comprehensive project-wide health assessment using 5 parallel specialist subagents.
Usage
/phx:audit # Full audit (default)
/phx:audit --quick # 2-3 minute pulse check
/phx:audit --focus=security # Deep dive single area
/phx:audit --focus=performance
/phx:audit --since abc123 # Incremental audit since commit
/phx:audit --since HEAD~10 # Audit last 10 commits
When to Use
- Quarterly health checks
- Before major releases
- After large refactors
- New team member onboarding (understand codebase health)
Iron Laws
- Wait for ALL agents before synthesizing — Partial results create misleading health scores because cross-category correlations get missed
- Scope agent prompts to specific directories — Vague prompts like "analyze the codebase" produce generic findings that waste tokens and miss real issues
- Never compare scores across projects — Scoring methodology depends on project size and maturity; only track trends within the same project
- Quick mode before full mode — Run
--quickfirst to catch compile/test failures before spending tokens on 5 parallel agents
Subagent Architecture
Spawn 5 specialists in parallel using Agent tool. Three route to plugin
specialists with a declared model; the two categories without a specialist use
general-purpose pinned to model: "sonnet" — unpinned, they inherit the
session model (Opus by default):
| Subagent | Focus | Output File | Routes to |
|---|---|---|---|
| Architecture Reviewer | Structure quality, coupling, cohesion | arch-review.md |
phoenix-patterns-analyst (sonnet) |
| Performance Auditor | N+1, indexes, bottlenecks, scalability | perf-audit.md |
general-purpose, model: "sonnet" (no perf specialist yet) |
| Security Auditor | OWASP scan, auth patterns, secrets | security-audit.md |
security-analyzer (opus) |
| Test Health Auditor | Coverage, quality, flaky tests | test-audit.md |
testing-reviewer (sonnet) |
| Dependency Auditor | Vulnerabilities, outdated, unused | deps-audit.md |
general-purpose, model: "sonnet" (hex-deps-triager is per-package only) |
Workflow
Step 1: Create Task List and Spawn All 5 Auditors (Parallel)
If TaskCreate is in your tool list, create Claude Code tasks for
progress visibility (Sonnet 5+ and Opus 4.8+ omit it unless
CLAUDE_CODE_ENABLE_TODO_TOOLS=1; never ToolSearch for it — skip this block):
For each auditor:
TaskCreate({subject: "{Area} audit", activeForm: "Auditing {area}..."})
TaskUpdate({taskId, status: "in_progress"})
Then spawn all 5 agents with Agent tool (parallel). Route to declared-model
specialists where they exist, keep general-purpose only where no specialist
covers the audit category:
Agent(subagent_type: "phx:phoenix-patterns-analyst", prompt: "Architecture audit: analyze module structure, context boundaries, coupling, cohesion. Write findings to .claude/audit/reports/arch-review.md", run_in_background: true)
Agent(subagent_type: "general-purpose", model: "sonnet", prompt: "Performance audit: N+1 queries, missing indexes, bottlenecks, scalability. Write findings to .claude/audit/reports/perf-audit.md", run_in_background: true)
Agent(subagent_type: "phx:security-analyzer", prompt: "Security audit: OWASP scan, auth patterns, secret leakage. Write findings to .claude/audit/reports/security-audit.md", run_in_background: true)
Agent(subagent_type: "phx:testing-reviewer", prompt: "Test health audit: coverage, quality, flakes. Write findings to .claude/audit/reports/test-audit.md", run_in_background: true)
Agent(subagent_type: "general-purpose", model: "sonnet", prompt: "Dependency audit: vulnerabilities, outdated, unused. Write findings to .claude/audit/reports/deps-audit.md", run_in_background: true)
Why specialist routing matters: a general-purpose subagent without
model: inherits the session model — Opus on every plan since CC 2.1.280.
Plugin specialists declare their own model in frontmatter, and the two
general-purpose tracks pin model: "sonnet", so no audit track runs on Opus.
Agent prompts must be FOCUSED. Scope each prompt to the relevant directories and patterns. Do NOT give vague prompts like "analyze the codebase."
Output efficiency: Tell each agent: "Report ONLY issues found. Do NOT list clean checks, passing categories, or 'What's Good'. One summary line per clean area suffices."
Step 2: Collect Results
Wait for ALL auditors to complete — one completion notification per agent
spawned. If you created tasks, mark each completed as it finishes. NEVER
proceed while any auditor is still running.
Read reports from .claude/audit/reports/.
Rate-limit circuit breaker: if 2+ auditors return empty results or
rate-limit/API errors, STOP spawning. Synthesize from the reports that
exist, mark missing categories as "not audited (rate limit)", and tell
the user to re-run /phx:audit after the limit resets. Never leave the
user typing "continue" against dead agents.
Step 3: Compress Findings
After all 5 auditors complete, spawn context-supervisor:
Agent(subagent_type: "phx:context-supervisor", prompt: """
Compress audit findings.
Input: .claude/audit/reports/
Output: .claude/audit/summaries/
Priority: Health scores per category, critical findings
only, cross-category correlations, deduplicate findings
found by 2+ agents.
""")
Read .claude/audit/summaries/consolidated.md for synthesis.
Step 4: Calculate Health Score
Each category scores 0-100. See ${CLAUDE_SKILL_DIR}/references/scoring-methodology.md.
Step 5: Generate Report
Write to .claude/audit/summaries/project-health-{date}.md.
Output Format
Report includes: Executive summary with health score (A-F, numeric/100), per-category score table (Architecture, Performance, Security, Tests, Dependencies), critical issues, top recommendations, and action plan (Immediate/Short-term/Long-term).
Quick Mode (--quick)
Only run essential checks (~2-3 minutes):
Run mix compile --warnings-as-errors, then mix hex.audit && mix deps.audit,
then mix xref graph --format stats, then mix test --trace 2>&1 | tail -20.
Skip: Full security scan, N+1 analysis, test quality metrics, architecture deep dive.
Focus Mode (--focus=area)
Deep dive single area with full specialist resources:
| Focus | Subagent | Extra Checks |
|---|---|---|
security |
security-analyzer | Full OWASP, sobelow, manual patterns |
performance |
general-purpose | Profile-level analysis, query explain (no plugin specialist yet) |
architecture |
phoenix-patterns-analyst | Full xref, coupling matrix, cohesion |
tests |
testing-reviewer | Coverage by context, quality metrics |
deps |
general-purpose | License audit, maintenance status (per-package hex-deps-triager only) |
Incremental Mode (--since <commit>)
Analyze only changes since a specific commit. Useful for pre-merge checks:
Run git diff --name-only <commit>...HEAD to identify changed files, then run targeted audits on changed files only (skips full project scan).
Combines with other flags: /phx:audit --since HEAD~5 --focus=security
Relationship to Other Commands
| Command | Scope | Frequency |
|---|---|---|
/phx:review |
Changed files (diff) | Every PR |
/phx:audit |
Entire project | Quarterly |
/phx:boundaries |
Context structure | On-demand |
/phx:verify |
Compile/test pass | Anytime |
References
${CLAUDE_SKILL_DIR}/references/scoring-methodology.md- How scores are calculated${CLAUDE_SKILL_DIR}/references/architecture-checks.md- Detailed architecture criteria
Files (claude-elixir-phoenix)
-
references
-
architecture-checks.md 5.1 KB
# Architecture Checks Reference Detailed criteria for architecture health assessment. ## Context Health Matrix ### What to Check For each context in `lib/{app}/`: | Metric | Healthy Range | Red Flag | |--------|---------------|----------| | Modules per context | 3-15 | >20 or <2 | | Public API functions | 5-30 | >40 | | Schemas per context | 1-5 | >8 | | Fan-out (contexts called) | 1-4 | >6 | | Fan-in (called by contexts) | 1-6 | >10 | ### Commands ```bash # Module count per context for dir in lib/my_app/*/; do echo "$(basename $dir): $(find $dir -name '*.ex' | wc -l) modules" done # Public function count grep -r "^ def " lib/my_app/*.ex --include="*.ex" | wc -l # Schema count grep -rl "use Ecto.Schema" lib/my_app/ | wc -l # Fan-out via xref mix xref graph --format stats ``` ## Coupling Analysis ### Fan-Out (Efferent Coupling) How many other contexts does this context depend on? ```bash # For each context, count outgoing dependencies mix xref graph --label compile-connected --format dot | grep "my_app_accounts ->" ``` | Fan-Out | Assessment | |---------|------------| | 0-2 | Excellent - well isolated | | 3-4 | Good - reasonable dependencies | | 5-6 | Warning - consider splitting | | 7+ | Critical - "god context" | ### Fan-In (Afferent Coupling) How many contexts depend on this context? | Fan-In | Assessment | |--------|------------| | 0 | Dead code? Or utility only | | 1-4 | Good - clear responsibility | | 5-8 | Common utility - ensure stable API | | 9+ | Core abstraction - avoid changes | ## Cohesion Analysis ### Signs of Low Cohesion - Context name is generic ("Utils", "Helpers", "Services") - Functions don't share domain vocabulary - Multiple unrelated schemas in same context - Context has >50 public functions ### Assessment ```bash # Check for generic names ls lib/my_app/ | grep -E "utils|helpers|services|common|shared" # Large API surface for file in lib/my_app/*.ex; do funcs=$(grep -c "^ def " "$file" 2>/dev/null || echo 0) if [ "$funcs" -gt 30 ]; then echo "WARNING: $(basename $file) has $funcs public functions" fi done ``` ## Boundary Violations ### Types of Violations | Violation | Severity | Example | |-----------|----------|---------| | Direct Repo from web | High | `Web.Controller` calls `Repo.all` | | Cross-context schema import | Medium | `Orders` aliases `Accounts.User` | | Direct schema access | Medium | `%Accounts.User{}` outside Accounts | | Context calling _web module | High | Business logic → presentation | ### Detection ```bash # Repo calls outside contexts grep -rn "Repo\." lib/my_app_web/ --include="*.ex" # Cross-context schema aliases grep -rn "alias MyApp\." lib/my_app/ --include="*.ex" | grep -v "alias MyApp\.$(dirname)" ``` ## Circular Dependencies (Compile-Time) Runtime cycles (e.g., from `verified_routes()`) are benign and don't cause recompilation cascades. Only compile-time cycles affect build performance and are scored. ### Detection ```bash mix xref graph --format cycles --label compile ``` ### Assessment | Cycles | Assessment | |--------|------------| | 0 | Excellent | | 1-2 | Warning - analyze and fix | | 3+ | Critical - architectural issue | ### Resolution Patterns 1. **Extract shared module** - Move shared code to new context 2. **Behavior/protocol** - Define interface, implement separately 3. **Event-driven** - Replace direct calls with PubSub 4. **Merge contexts** - If truly coupled, they're one context ## Naming Conventions ### Module Naming | Pattern | Assessment | |---------|------------| | `MyApp.{Domain}.{Entity}` | Correct | | `MyApp.{Domain}Service` | Avoid "Service" suffix | | `MyApp.{Domain}Manager` | Avoid "Manager" suffix | | `MyApp.{Domain}Helper` | Move to domain context | ### Function Naming | Pattern | Assessment | |---------|------------| | `get_user/1` | Correct - raises | | `fetch_user/1` | Correct - returns tuple | | `list_users/0` | Correct | | `find_user/1` | Inconsistent - use get/fetch | | `user/1` | Too vague | ### Context API Surface Well-designed context has: ```elixir defmodule MyApp.Accounts do # Queries (list/get/fetch) def list_users(opts \\ []) def get_user!(id) def fetch_user(id) # Commands (create/update/delete) def create_user(attrs) def update_user(user, attrs) def delete_user(user) # Domain operations def authenticate(email, password) def verify_email(token) end ``` ## Output Format ```markdown ## Architecture Review ### Context Health Matrix | Context | Modules | Public API | Fan-Out | Fan-In | Assessment | |---------|---------|------------|---------|--------|------------| | Accounts | 5 | 12 | 2 | 4 | Healthy | | Orders | 18 | 45 | 8 | 3 | Too Large | | Shared | 2 | 8 | 0 | 12 | Utility OK | ### Boundary Violations | Type | Location | Severity | |------|----------|----------| | Direct Repo | post_controller.ex:45 | High | ### Circular Dependencies - None found ✅ ### Recommendations 1. **Split Orders context** - 18 modules is too large - Extract Fulfillment (shipping, tracking) - Extract Invoicing (billing, receipts) 2. **Fix boundary violation** - Move Repo call to context - `PostController.create/2` should call `Blog.create_post/1` ``` -
scoring-methodology.md 4.3 KB
# Scoring Methodology How health scores are calculated for each category. ## Score Ranges | Score | Grade | Status | Meaning | |-------|-------|--------|---------| | 90-100 | A | Excellent | No critical issues, minor improvements only | | 80-89 | B | Good | Few warnings, solid foundation | | 70-79 | C | Needs Attention | Some issues to address | | 60-69 | D | Needs Work | Multiple issues, prioritize fixing | | <60 | F | Critical | Significant problems, immediate action | ## Category Scoring ### Architecture (100 points) | Criterion | Points | Deductions | |-----------|--------|------------| | Context boundaries respected | 25 | -5 per violation | | Module naming consistency | 15 | -3 per inconsistency | | Fan-out <5 contexts per module | 15 | -5 per over-coupled module | | API surface reasonable (<30 funcs/context) | 15 | -5 per bloated context | | No compile-time circular dependencies | 15 | -10 per cycle | | Folder structure follows conventions | 15 | -5 per deviation | **Commands used:** ```bash mix xref graph --format stats mix xref graph --format cycles --label compile find lib -name "*.ex" -type f | wc -l ``` ### Performance (100 points) | Criterion | Points | Deductions | |-----------|--------|------------| | No N+1 patterns detected | 30 | -5 per N+1 | | Indexes for common queries | 20 | -5 per missing index | | Preloads used appropriately | 15 | -3 per missing preload | | No GenServer bottlenecks | 15 | -10 per bottleneck | | LiveView streams for large lists | 10 | -5 per regular assign list | | Queries avoid SELECT * | 10 | -2 per SELECT * | **Commands used:** ```bash grep -B5 -A5 "Enum.map" lib/ -r --include="*.ex" | grep "Repo\." grep -r "Repo.preload" lib/ --include="*.ex" grep -r "assign(socket" lib/my_app_web/live/ --include="*.ex" ``` ### Security (100 points) | Criterion | Points | Deductions | |-----------|--------|------------| | No sobelow critical issues | 30 | -15 per critical | | No sobelow high issues | 20 | -5 per high | | Authorization in all handle_events | 15 | -10 per missing auth | | No String.to_atom with input | 10 | -10 per violation | | No raw() with untrusted content | 10 | -10 per violation | | Secrets in runtime.exs only | 15 | -15 per hardcoded secret | **Commands used:** ```bash mix sobelow --exit medium 2>&1 || true grep -r "String.to_atom" lib/ --include="*.ex" grep -r "raw(" lib/ --include="*.ex" grep -r "handle_event" lib/my_app_web/live/ -A10 | grep -v "authorize\|permit" ``` ### Test Quality (100 points) | Criterion | Points | Deductions | |-----------|--------|------------| | Coverage >70% | 30 | -5 per 10% below 70% | | No flaky test patterns | 20 | -5 per Process.sleep in test | | Async: true where possible | 15 | -2 per missing async | | verify_on_exit! in Mox tests | 15 | -5 per missing | | Reasonable test duration (<30s avg) | 10 | -5 if slow | | Error paths tested | 10 | -5 if only happy path | **Commands used:** ```bash mix test --cover 2>&1 | tail -30 grep -r "Process.sleep" test/ --include="*.exs" grep -r "async: true" test/ --include="*.exs" grep -r "verify_on_exit!" test/ --include="*.exs" ``` ### Dependencies (100 points) | Criterion | Points | Deductions | |-----------|--------|------------| | No hex.audit vulnerabilities | 40 | -20 per vulnerability | | No deps.audit issues | 20 | -10 per issue | | No major version behind (>2) | 20 | -5 per outdated | | No unused dependencies | 10 | -3 per unused | | Version pinning appropriate | 10 | -5 if all loose | **Commands used:** ```bash mix hex.audit 2>&1 mix deps.audit 2>&1 mix hex.outdated 2>&1 ``` ## Overall Score Calculation ``` overall_score = ( architecture_score * 0.20 + performance_score * 0.25 + security_score * 0.25 + test_quality_score * 0.15 + dependencies_score * 0.15 ) ``` **Weighting rationale:** - Security and Performance weighted highest (25% each) - runtime impact - Architecture weighted at 20% - long-term maintainability - Tests and Dependencies at 15% each - important but less immediate ## Grade Assignment ``` if overall_score >= 90: grade = "A" elif overall_score >= 80: grade = "B" elif overall_score >= 70: grade = "C" elif overall_score >= 60: grade = "D" else: grade = "F" ``` ## Critical Issues Override Regardless of score, flag as CRITICAL if any: - Security vulnerability detected - Hardcoded secrets found - Compile warnings present - Test suite failing
-
-
SKILL.md 7.9 KB
--- name: audit description: Project health audit and health check — architecture, performance, tests, dependencies, code quality. Use when assessing overall project health, before releases, or after refactors. effort: high argument-hint: "[--quick|--full|--focus=area|--since=commit]" --- # Project Health Audit Comprehensive project-wide health assessment using 5 parallel specialist subagents. ## Usage ``` /phx:audit # Full audit (default) /phx:audit --quick # 2-3 minute pulse check /phx:audit --focus=security # Deep dive single area /phx:audit --focus=performance /phx:audit --since abc123 # Incremental audit since commit /phx:audit --since HEAD~10 # Audit last 10 commits ``` ## When to Use - **Quarterly** health checks - **Before major releases** - **After large refactors** - **New team member onboarding** (understand codebase health) ## Iron Laws 1. **Wait for ALL agents before synthesizing** — Partial results create misleading health scores because cross-category correlations get missed 2. **Scope agent prompts to specific directories** — Vague prompts like "analyze the codebase" produce generic findings that waste tokens and miss real issues 3. **Never compare scores across projects** — Scoring methodology depends on project size and maturity; only track trends within the same project 4. **Quick mode before full mode** — Run `--quick` first to catch compile/test failures before spending tokens on 5 parallel agents ## Subagent Architecture Spawn 5 specialists in parallel using Agent tool. Three route to plugin specialists with a declared model; the two categories without a specialist use `general-purpose` pinned to `model: "sonnet"` — unpinned, they inherit the session model (Opus by default): | Subagent | Focus | Output File | Routes to | |----------|-------|-------------|-----------| | Architecture Reviewer | Structure quality, coupling, cohesion | `arch-review.md` | `phoenix-patterns-analyst` (sonnet) | | Performance Auditor | N+1, indexes, bottlenecks, scalability | `perf-audit.md` | `general-purpose`, `model: "sonnet"` (no perf specialist yet) | | Security Auditor | OWASP scan, auth patterns, secrets | `security-audit.md` | `security-analyzer` (opus) | | Test Health Auditor | Coverage, quality, flaky tests | `test-audit.md` | `testing-reviewer` (sonnet) | | Dependency Auditor | Vulnerabilities, outdated, unused | `deps-audit.md` | `general-purpose`, `model: "sonnet"` (`hex-deps-triager` is per-package only) | ## Workflow ### Step 1: Create Task List and Spawn All 5 Auditors (Parallel) **If `TaskCreate` is in your tool list**, create Claude Code tasks for progress visibility (Sonnet 5+ and Opus 4.8+ omit it unless `CLAUDE_CODE_ENABLE_TODO_TOOLS=1`; never ToolSearch for it — skip this block): ``` For each auditor: TaskCreate({subject: "{Area} audit", activeForm: "Auditing {area}..."}) TaskUpdate({taskId, status: "in_progress"}) ``` Then spawn all 5 agents with Agent tool (parallel). Route to declared-model specialists where they exist, keep `general-purpose` only where no specialist covers the audit category: ``` Agent(subagent_type: "phx:phoenix-patterns-analyst", prompt: "Architecture audit: analyze module structure, context boundaries, coupling, cohesion. Write findings to .claude/audit/reports/arch-review.md", run_in_background: true) Agent(subagent_type: "general-purpose", model: "sonnet", prompt: "Performance audit: N+1 queries, missing indexes, bottlenecks, scalability. Write findings to .claude/audit/reports/perf-audit.md", run_in_background: true) Agent(subagent_type: "phx:security-analyzer", prompt: "Security audit: OWASP scan, auth patterns, secret leakage. Write findings to .claude/audit/reports/security-audit.md", run_in_background: true) Agent(subagent_type: "phx:testing-reviewer", prompt: "Test health audit: coverage, quality, flakes. Write findings to .claude/audit/reports/test-audit.md", run_in_background: true) Agent(subagent_type: "general-purpose", model: "sonnet", prompt: "Dependency audit: vulnerabilities, outdated, unused. Write findings to .claude/audit/reports/deps-audit.md", run_in_background: true) ``` **Why specialist routing matters**: a `general-purpose` subagent without `model:` inherits the session model — Opus on every plan since CC 2.1.280. Plugin specialists declare their own model in frontmatter, and the two `general-purpose` tracks pin `model: "sonnet"`, so no audit track runs on Opus. **Agent prompts must be FOCUSED.** Scope each prompt to the relevant directories and patterns. Do NOT give vague prompts like "analyze the codebase." **Output efficiency**: Tell each agent: "Report ONLY issues found. Do NOT list clean checks, passing categories, or 'What's Good'. One summary line per clean area suffices." ### Step 2: Collect Results Wait for ALL auditors to complete — one completion notification per agent spawned. If you created tasks, mark each `completed` as it finishes. NEVER proceed while any auditor is still running. Read reports from `.claude/audit/reports/`. **Rate-limit circuit breaker:** if 2+ auditors return empty results or rate-limit/API errors, STOP spawning. Synthesize from the reports that exist, mark missing categories as "not audited (rate limit)", and tell the user to re-run `/phx:audit` after the limit resets. Never leave the user typing "continue" against dead agents. ### Step 3: Compress Findings After all 5 auditors complete, spawn context-supervisor: ``` Agent(subagent_type: "phx:context-supervisor", prompt: """ Compress audit findings. Input: .claude/audit/reports/ Output: .claude/audit/summaries/ Priority: Health scores per category, critical findings only, cross-category correlations, deduplicate findings found by 2+ agents. """) ``` Read `.claude/audit/summaries/consolidated.md` for synthesis. ### Step 4: Calculate Health Score Each category scores 0-100. See `${CLAUDE_SKILL_DIR}/references/scoring-methodology.md`. ### Step 5: Generate Report Write to `.claude/audit/summaries/project-health-{date}.md`. ## Output Format Report includes: Executive summary with health score (A-F, numeric/100), per-category score table (Architecture, Performance, Security, Tests, Dependencies), critical issues, top recommendations, and action plan (Immediate/Short-term/Long-term). ## Quick Mode (`--quick`) Only run essential checks (~2-3 minutes): Run `mix compile --warnings-as-errors`, then `mix hex.audit && mix deps.audit`, then `mix xref graph --format stats`, then `mix test --trace 2>&1 | tail -20`. Skip: Full security scan, N+1 analysis, test quality metrics, architecture deep dive. ## Focus Mode (`--focus=area`) Deep dive single area with full specialist resources: | Focus | Subagent | Extra Checks | |-------|----------|--------------| | `security` | security-analyzer | Full OWASP, sobelow, manual patterns | | `performance` | general-purpose | Profile-level analysis, query explain (no plugin specialist yet) | | `architecture` | phoenix-patterns-analyst | Full xref, coupling matrix, cohesion | | `tests` | testing-reviewer | Coverage by context, quality metrics | | `deps` | general-purpose | License audit, maintenance status (per-package `hex-deps-triager` only) | ## Incremental Mode (`--since <commit>`) Analyze only changes since a specific commit. Useful for pre-merge checks: Run `git diff --name-only <commit>...HEAD` to identify changed files, then run targeted audits on changed files only (skips full project scan). Combines with other flags: `/phx:audit --since HEAD~5 --focus=security` ## Relationship to Other Commands | Command | Scope | Frequency | |---------|-------|-----------| | `/phx:review` | Changed files (diff) | Every PR | | `/phx:audit` | Entire project | Quarterly | | `/phx:boundaries` | Context structure | On-demand | | `/phx:verify` | Compile/test pass | Anytime | ## References - `${CLAUDE_SKILL_DIR}/references/scoring-methodology.md` - How scores are calculated - `${CLAUDE_SKILL_DIR}/references/architecture-checks.md` - Detailed architecture criteria
Comments (0)
Sign in to join the conversation.
Reviews (0)
No reviews yet.
No comments yet.