afc-setup
Configure afc routing block in global CLAUDE.md
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Menu
Configure afc routing block in global CLAUDE.md
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
Code and component analysis — analyze code, trace flows, audit consistency, inspect components
Architecture analysis and design review
Full auto pipeline — run spec-to-clean cycle automatically for new features
Save session state for later resumption
Resolve spec ambiguities with clarifying questions
Pipeline artifact cleanup and codebase hygiene
| name | afc:setup |
| description | Configure afc routing block in global CLAUDE.md |
| argument-hint | [--force] |
| allowed-tools | ["Read","Write","Bash","Glob"] |
| model | sonnet |
Manages the all-for-claudecode routing block in
~/.claude/CLAUDE.md. Global only — modifies~/.claude/CLAUDE.md, not project files. For project-local setup, use/afc:init.
!cat ~/.claude/CLAUDE.md 2>/dev/null || echo "[CLAUDE.md NOT FOUND]"
--force — skip conflict prompts, default to coexistence modeRead ${CLAUDE_SKILL_DIR}/../../package.json → extract "version" → use as {PLUGIN_VERSION}.
Parse the pre-fetched CLAUDE.md content above:
<!-- AFC:START --> found → existing AFC block
<!-- AFC:VERSION:X.Y.Z -->. If matches {PLUGIN_VERSION}: print AFC block already up to date (v{PLUGIN_VERSION}) and stop.<!-- SELFISH:START --> found → remove entire SELFISH:START…SELFISH:END block, print Removed legacy SELFISH block, proceed.Detect conflicts in unguarded content (outside any <!-- *:START/END --> blocks).
See conflict-detection.md for marker-block algorithm and conflict keyword table.
Skip this step if --force is set — default to coexistence.
No conflicts → proceed to Step 5.
Conflicts found — show scan summary and ask:
CLAUDE.md Scan Results
├─ Tool blocks found: {names} (lines {range})
├─ Agent routing conflicts: {count} — e.g. "executor" (line XX) ↔ afc:implement
└─ Skill routing conflicts: {count}
"Directives overlapping with afc were found. Choose resolution:"
- afc-exclusive — add override rules inside the AFC block (does not touch other tools' blocks)
- coexistence — append AFC block as-is (end-of-file position gives it priority)
- manual cleanup — print conflict list and abort
Append the block below to the end of ~/.claude/CLAUDE.md (or replace existing AFC block in place).
Also remove any legacy unguarded block (## all-for-claudecode Auto-Trigger Rules, etc.) before appending.
<!-- AFC:START -->
<!-- AFC:VERSION:{PLUGIN_VERSION} -->
<afc-pipeline>
IMPORTANT: For requests matching the afc skill routing table below, always invoke the corresponding skill via the Skill tool. Do not substitute with other agents or tools.
## Skill Routing
Classify the user's intent and route to the matching skill. Use semantic understanding — not keyword matching.
| User Intent | Skill | Route When |
|-------------|-------|------------|
| Full lifecycle | `afc:auto` | User wants end-to-end feature development, or the request is a non-trivial new feature without an existing plan |
| Specification | `afc:spec` | User wants to define or write requirements, acceptance criteria, or success conditions |
| Design/Plan | `afc:plan` | User wants to plan HOW to implement before coding — approach, architecture decisions, design |
| Implement | `afc:implement` | User wants specific code changes with a clear scope: add feature, refactor, modify. Requires existing plan or precise instructions |
| Review | `afc:review` | User wants code review, PR review, or quality check on existing/changed code |
| Debug/Fix | `afc:debug` | User reports a bug, error, or broken behavior and wants diagnosis and fix |
| Test | `afc:test` | User wants to write tests, improve coverage, or verify behavior |
| Validate | `afc:validate` | User wants to check consistency or validate existing pipeline artifacts |
| Analyze | `afc:analyze` | User wants to understand, explore, or audit existing code without modifying it |
| QA Audit | `afc:qa` | User wants project quality audit, test confidence check, or runtime quality gaps |
| Research | `afc:research` | User wants deep investigation of external tools, libraries, APIs, or technical concepts |
| Ideate | `afc:ideate` | User wants to brainstorm ideas, explore possibilities, or draft a product brief |
| Consult | `afc:consult` | User wants expert advice on a decision: library choice, architecture direction, legal/security/infra guidance |
| Launch | `afc:launch` | User wants to prepare a release — generate changelog, release notes, version bump, or tag |
| Tasks | `afc:tasks` | User explicitly wants to decompose work into a task breakdown |
| Ambiguous | `afc:clarify` | User's request is too vague or underspecified to route confidently |
### Routing Rules
1. **Auto vs Implement**: A new feature request without an existing plan routes to `afc:auto`. Only use `afc:implement` when the user has a clear, scoped task or an existing plan/spec.
2. **Compound intents**: Route to the primary intent. The pipeline handles sequencing internally.
3. **Design-first**: When scope is non-trivial (multiple files, architectural decisions needed), prefer `afc:auto` or `afc:plan` over direct `afc:implement`.
User-only (not auto-triggered — when user invokes directly via `/afc:X`, execute the skill immediately):
- `afc:doctor` — plugin health check
- `afc:setup` — global CLAUDE.md configuration
- `afc:init` — project-local setup
- `afc:architect` — architecture review
- `afc:security` — security scan
- `afc:checkpoint` — session save
- `afc:resume` — session restore
- `afc:principles` — project principles management
- `afc:clean` — pipeline cleanup (artifact cleanup, dead code scan, pipeline flag release)
- `afc:triage` — parallel PR/issue triage
- `afc:issue` — analyze a single GitHub issue
- `afc:resolve` — address LLM bot review comments on a PR
- `afc:learner` — pattern learning or rule promotion
- `afc:pr-comment` — post PR review comments to GitHub
- `afc:release-notes` — generate release notes from git history
## Pipeline
spec → plan → implement → review → clean
## Override Rules
NEVER use executor, deep-executor, debugger, planner, analyst, verifier, test-engineer, code-reviewer, quality-reviewer, style-reviewer, api-reviewer, security-reviewer, performance-reviewer for tasks that an afc skill covers above. ALWAYS invoke the afc skill instead.
## Source Verification
When analyzing or making claims about external systems, APIs, SDKs, or third-party tools:
- Verify against official documentation, NOT project-internal docs
- Do not hardcode reference data when delegating to sub-agents — instruct them to look up primary sources
- Cross-verify high-severity findings before reporting
</afc-pipeline>
<!-- AFC:END -->
When afc-exclusive mode (Option 1) is selected, append inside the block after Override Rules:
## Detected Conflicts
The following rules were auto-generated to resolve conflicts:
- The Skill Routing table above always takes priority over agent routing directives of {detected tool blocks}
- This block is at the end of the file and therefore has the highest priority
all-for-claudecode setup complete
├─ CLAUDE.md: {injected|updated|already current|user aborted}
├─ Version: {PLUGIN_VERSION}
│ {if conflicts} └─ Conflict resolution: {afc-exclusive|coexistence|user cleanup}
└─ Next step: /afc:init (project setup) or /afc:auto (start building)
<!-- AFC:START/END --> markers.<!-- *:START/END --> blocks.