Help us improve
Share bugs, ideas, or general feedback.
From afc
Analyzes codebases via natural language: traces flows, diagnoses root causes, maps structures, audits consistency, explores components.
npx claudepluginhub jhlee0409/all-for-claudecode --plugin afcHow this skill is triggered — by the user, by Claude, or both
Slash command
/afc:analyzesonnetThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
> Performs general-purpose codebase exploration and analysis based on a natural-language prompt.
Traces actual code paths in codebases to analyze architecture, data flows, integrations, patterns, and provide recommendations across 5 evidence-based iterations. Use for deep 'how does X work' queries or complex system reviews.
Explores codebase areas: maps files, traces data flows, identifies patterns and dependencies. For 'how does X work', architecture queries, or pre-change analysis.
Investigates code by tracing execution paths, mapping data flow, and diagnosing root causes. Outputs an analysis report with architecture overview and findings.
Share bugs, ideas, or general feedback.
Performs general-purpose codebase exploration and analysis based on a natural-language prompt. Read-only — does not modify any files.
$ARGUMENTS — (required) description of what to analyze (e.g., "trace the login flow", "root cause of rendering bug", "how does the hook system work")Architecture, Code Style, and Project Context are auto-loaded via .claude/rules/afc-project.md.
Read .claude/afc.config.md if CI commands are needed.
If neither rules file nor config exists: read CLAUDE.md for architecture info. Proceed without config if neither exists.
Read the user's question semantically. What does the user actually want to understand? Select the mode that best serves their learning goal.
| Mode | When to select | Focus |
|---|---|---|
| Root Cause | User wants to understand WHY something is broken, failing, or behaving unexpectedly — the goal is diagnosing a problem | Error trace → data flow → hypothesis |
| Structural | User wants to understand HOW a system is built or how components relate — the goal is comprehension of design or flow | Component relationships, call graphs, data flow |
| Exploratory | User wants to discover WHAT exists in the codebase — the goal is finding, listing, or locating things | File/function discovery, pattern matching |
| Comparative | User wants to understand the DIFFERENCE between two or more things — the goal is contrast and tradeoff evaluation | Side-by-side analysis of implementations |
If the question spans multiple modes, select the PRIMARY mode that best matches the user's core learning goal, and note secondary aspects to incorporate during analysis.
If the intent doesn't clearly match a single mode, default to Exploratory.
Based on the classified mode:
$ARGUMENTSExploration should be guided by {config.architecture} layer structure when available.
Apply the appropriate analysis lens:
## Analysis: {summary of $ARGUMENTS}
### Mode: {Root Cause | Structural | Exploratory | Comparative}
### Findings
{Numbered findings with code references (file:line)}
### Key Relationships
{Relevant component/function relationships discovered}
### Summary
{2-3 sentence conclusion answering the original question}
### Suggested Next Steps
{1-3 actionable suggestions based on the analysis}
Analysis complete: {short summary}
├─ Mode: {mode}
├─ Files explored: {N}
├─ Findings: {N}
└─ Suggested next steps: {N}
file:line references so the user can navigate to relevant code./afc:validate instead.