all-for-claudecode 2.3.0 → 2.5.0

package/commands/consult.md

@@ -0,0 +1,160 @@
+---
+name: afc:consult
+description: "Expert consultation — get advice from backend, infra, PM, design, marketing, legal, security, or tech advisor specialists"
+argument-hint: "[domain?] \"[question]\" [brief|deep]"
+model: sonnet
+---
+
+# /afc:consult — Expert Consultation
+
+> Consult a domain expert for advice tailored to your project.
+> Each expert has persistent memory — they remember your project's decisions across sessions.
+> Pipeline-independent: works anytime, no active pipeline required.
+
+## Arguments
+
+- `$ARGUMENTS` — (optional) Format: `[domain] "[question]" [brief|deep]`
+  - `domain` — one of: `backend`, `infra`, `pm`, `design`, `marketing`, `legal`, `security`, `advisor` (optional, auto-detected if omitted)
+  - `question` — the consultation question (optional, enters exploratory mode if omitted)
+  - `brief|deep` — depth hint (optional, default: `auto`)
+
+## Execution Steps
+
+### 1. Parse Arguments
+
+Extract from `$ARGUMENTS`:
+- **domain**: first word if it matches a known domain name
+- **question**: remaining text after domain (if any), with quotes stripped
+- **depth**: last word if it matches `brief` or `deep`
+
+If `$ARGUMENTS` is empty → go to Step 2 (domain selection).
+
+### 2. Domain Detection
+
+**A. Explicit domain provided** → use it directly.
+
+**B. No domain, but question provided** → keyword matching:
+
+| Domain | Keywords |
+|--------|----------|
+| backend | API, database, schema, query, server, auth, JWT, REST, GraphQL, ORM, migration, endpoint, middleware, validation, session, cookie, token |
+| infra | deploy, Docker, CI/CD, cloud, monitoring, k8s, pipeline, Kubernetes, terraform, AWS, GCP, Azure, nginx, SSL, DNS, CDN, container, scaling |
+| pm | feature, user story, priority, roadmap, PRD, MVP, backlog, metric, KPI, retention, churn, persona, requirement, scope |
+| design | UI, UX, accessibility, component, layout, color, animation, responsive, wireframe, prototype, typography, spacing, contrast, WCAG |
+| marketing | SEO, analytics, content, growth, conversion, funnel, GA4, acquisition, retention, landing page, Open Graph, meta tag, social media |
+| legal | GDPR, CCPA, privacy, cookie, consent, license, GPL, MIT, compliance, terms of service, data protection, PII, HIPAA, regulation, policy |
+| security | XSS, CSRF, injection, OWASP, vulnerability, attack, exploit, encryption, secret, credential, CORS, CSP, rate limit, brute force, penetration |
+| advisor | library, framework, stack, tool, package, which to use, alternative, compare, choose, select, recommend, what exists, ecosystem, best option, switch to |
+
+Match rules:
+- Case-insensitive keyword matching against the question
+- If multiple domains match: pick the one with the most keyword hits
+- If tie: pick the first domain in the table order above
+
+**C. No domain, no question, or no keyword match** → ask user:
+
+Use AskUserQuestion:
+```
+"Which expert would you like to consult?"
+Options:
+1. Backend — API design, database, authentication, server architecture
+2. Infra — deployment, CI/CD, cloud, monitoring, scaling
+3. PM — product strategy, prioritization, user stories, metrics
+4. Design — UI/UX, accessibility, components, user flows
+5. Marketing — SEO, analytics, growth, content strategy
+6. Legal — GDPR, privacy, licenses, compliance, terms of service
+7. Security — application security, OWASP, threat modeling, secure coding
+8. Advisor — technology/library/framework selection, ecosystem navigation, stack decisions
+```
+
+### 3. Construct Expert Prompt
+
+Build the prompt for the expert agent:
+
+```
+You are being consulted via /afc:consult.
+
+## Question
+{question or "No specific question — enter exploratory diagnostic mode. Ask the user probing questions to uncover what they need help with."}
+
+## Depth
+{brief|deep|auto}
+
+## Instructions
+1. Follow your Session Start Protocol (read project profile, domain adapter, memory, pipeline state)
+2. Follow the Communication Rules from expert-protocol.md
+3. Provide your consultation following the Progressive Disclosure format
+4. Update your MEMORY.md with any confirmed decisions or new project insights
+```
+
+### 4. Delegate to Expert Agent
+
+Invoke the expert agent via Task(). Map the detected domain to the corresponding agent:
+
+| Domain | subagent_type |
+|--------|---------------|
+| backend | `afc:afc-backend-expert` |
+| infra | `afc:afc-infra-expert` |
+| pm | `afc:afc-pm-expert` |
+| design | `afc:afc-design-expert` |
+| marketing | `afc:afc-marketing-expert` |
+| legal | `afc:afc-legal-expert` |
+| security | `afc:afc-appsec-expert` |
+| advisor | `afc:afc-tech-advisor` |
+
+Example for each domain:
+```
+Task("backend consultation", subagent_type: "afc:afc-backend-expert", prompt: "...")
+Task("infra consultation", subagent_type: "afc:afc-infra-expert", prompt: "...")
+Task("pm consultation", subagent_type: "afc:afc-pm-expert", prompt: "...")
+Task("design consultation", subagent_type: "afc:afc-design-expert", prompt: "...")
+Task("marketing consultation", subagent_type: "afc:afc-marketing-expert", prompt: "...")
+Task("legal consultation", subagent_type: "afc:afc-legal-expert", prompt: "...")
+Task("security consultation", subagent_type: "afc:afc-appsec-expert", prompt: "...")
+Task("advisor consultation", subagent_type: "afc:afc-tech-advisor", prompt: "...")
+```
+
+The agent runs in foreground (never `run_in_background`).
+
+### 5. Relay Response
+
+Return the agent's response to the user as-is. Do not summarize or filter the expert's output.
+
+### 6. Follow-up Prompt
+
+After relaying the response, suggest:
+
+```
+Follow-up options:
+- Ask a deeper question on this topic
+- Consult another expert: /afc:consult {other-domain}
+- If a recommendation involves code changes: /afc:auto or /afc:implement
+```
+
+## Examples
+
+```bash
+# Specific domain + question
+/afc:consult backend "Should I use JWT or session cookies for auth?"
+
+# Auto-detect domain from question
+/afc:consult "My API is slow when loading the dashboard"
+
+# Exploratory mode (Socratic diagnostic)
+/afc:consult backend
+
+# With depth hint
+/afc:consult infra "How should I set up CI/CD?" deep
+
+# No arguments (domain selection prompt)
+/afc:consult
+```
+
+## Notes
+
+- **Limited write scope**: Expert agents can create/update project profiles and their own memory files, but should not modify your application code.
+- **Persistent memory**: Each expert remembers your project's decisions across sessions (stored in `.claude/agent-memory/afc-{domain}-expert/MEMORY.md`).
+- **Project profile**: Shared context at `.claude/afc/project-profile.md` — auto-created on first consultation, review and adjust as needed.
+- **Domain adapters**: Industry-specific guardrails (fintech, ecommerce, healthcare) auto-loaded based on project profile.
+- **Pipeline-independent**: Works anytime, no active pipeline required. If a pipeline is active, experts consider the current phase context.
+- **Cross-referral**: Experts may suggest consulting another domain expert when a question crosses boundaries.

package/commands/implement.md

@@ -59,7 +59,11 @@ This enables Stop Gate and CI Gate hooks during standalone implementation. Relea
 3. **Recent changes**: run `git log --oneline -20` to understand what changed recently (context for implementation)
 4. **Smoke test**: run `{config.gate}` before starting implementation:
    - If it fails → diagnose before implementing (existing code is broken — fix first or report to user)
-   - If it passes → baseline confirmed, proceed
+   - If it passes → continue to baseline test
+5. **Baseline test** (if `{config.test}` is non-empty): run `{config.test}` before starting implementation:
+   - If it fails → report pre-existing test failures to user and ask: "(1) Proceed anyway (tests were already broken) (2) Fix first (3) Abort"
+   - If it passes → full baseline confirmed, proceed
+   - If `{config.test}` is empty → skip (no test framework configured)
 
 ### 1.3. Task List Generation (if tasks.md absent)
 
@@ -176,11 +180,13 @@ Task("T004: Create AuthService", subagent_type: "afc:afc-impl-worker", isolation
 
 **Failure Recovery** (per-task, not per-batch):
 1. Identify the failed task from the agent's error return
-2. Reset: `TaskUpdate(taskId, status: "pending")`
-3. Track: `TaskUpdate(taskId, metadata: { retryCount: N })`
-4. If retryCount < 3 → re-launch in the next batch round (not immediately — wait for current batch to finish)
-5. If retryCount >= 3 → mark as failed, report: `"T{ID} failed after 3 attempts: {last error}"`
-6. Continue with remaining tasks — a single failure does not block the entire phase
+2. Capture the `agentId` from the failed agent's result (returned in Task tool output)
+3. Reset: `TaskUpdate(taskId, status: "pending")`
+4. Track: `TaskUpdate(taskId, metadata: { retryCount: N, lastAgentId: agentId })`
+5. If retryCount < 3 → re-launch with `resume: lastAgentId` in the next batch round. The resumed agent retains full context from the previous attempt (what it tried, what failed, partial progress), enabling more targeted retry instead of starting from scratch.
+   - **Worktree caveat**: if the failed worker made no file changes, its worktree is auto-cleaned and `resume` will fail. In this case, fall back to a fresh launch (omit `resume`) for the retry.
+6. If retryCount >= 3 → mark as failed, report: `"T{ID} failed after 3 attempts: {last error}"`
+7. Continue with remaining tasks — a single failure does not block the entire phase
 
 #### Swarm Mode (6+ [P] tasks)
 
@@ -243,11 +249,13 @@ Task("Worker 2: T008, T010, T012", subagent_type: "afc:afc-impl-worker", isolati
 When a worker agent returns an error:
 1. Identify which tasks the worker was assigned (from the pre-assigned list)
 2. Check which tasks the worker actually completed (from its result summary)
-3. Reset uncompleted tasks: `TaskUpdate(taskId, status: "pending")`
-4. Track retry count: `TaskUpdate(taskId, metadata: { retryCount: N })`
-5. If retryCount < 3 → reassign to next worker batch
-6. If retryCount >= 3 → mark as failed, report: `"T{ID} failed after 3 attempts: {last error}"`
-7. Continue with remaining tasks
+3. Capture the `agentId` from the failed worker's result
+4. Reset uncompleted tasks: `TaskUpdate(taskId, status: "pending")`
+5. Track retry count: `TaskUpdate(taskId, metadata: { retryCount: N, lastAgentId: agentId })`
+6. If retryCount < 3 → re-launch with `resume: lastAgentId` to preserve context from the previous attempt. The resumed agent retains its full conversation history (files read, changes attempted, errors encountered), enabling targeted retry.
+   - **Worktree caveat**: if the failed worker made no file changes, its worktree is auto-cleaned and `resume` will fail. In this case, fall back to a fresh launch (omit `resume`) for the retry.
+7. If retryCount >= 3 → mark as failed, report: `"T{ID} failed after 3 attempts: {last error}"`
+8. Continue with remaining tasks
 
 > Single task failure does not block the phase. The orchestrator reassigns failed tasks to subsequent batches.
 

package/commands/init.md

@@ -123,6 +123,17 @@ Write sections as natural descriptions — **no YAML code blocks** except for CI
 For items that cannot be inferred: note `TODO: Adjust for your project` inline.
 Save to `.claude/afc.config.md`.
 
+### 4.5. Generate Project Profile
+
+Generate `.claude/afc/project-profile.md` for expert consultation agents:
+
+1. Create `.claude/afc/` directory if it does not exist
+2. If `.claude/afc/project-profile.md` already exists: skip (do not overwrite)
+3. If not exists: generate from the detected project information using `${CLAUDE_PLUGIN_ROOT}/templates/project-profile.template.md` as the structure
+   - Fill in Stack, Architecture, and Domain fields from the analysis in Step 3
+   - Leave Team, Scale, and Constraints as template placeholders for user to fill
+4. Print: `Project profile: .claude/afc/project-profile.md (review and adjust team/scale/domain fields)`
+
 ### 5. Scan Global CLAUDE.md and Detect Conflicts
 
 Read `~/.claude/CLAUDE.md` and analyze in the following order.
@@ -213,21 +224,30 @@ IMPORTANT: For requests matching the afc skill routing table below, always invok
 
 ## Skill Routing
 
-| Intent | Skill | Trigger Keywords |
-|--------|-------|-----------------|
-| Implement/Modify | `afc:implement` | add, modify, refactor, implement |
-| Review | `afc:review` | review, check code, check PR |
-| Debug | `afc:debug` | bug, error, broken, fix |
-| Test | `afc:test` | test, coverage |
-| Design | `afc:plan` | design, plan, how to implement |
-| Validate | `afc:validate` | consistency, validate, validate artifacts |
-| Analyze | `afc:analyze` | analyze, explore, investigate code, root cause |
-| Spec | `afc:spec` | spec, specification |
-| Tasks | `afc:tasks` | break down tasks, decompose |
-| Research | `afc:research` | research, investigate |
-| Ideate | `afc:ideate` | idea, brainstorm, what to build, product brief |
-| Ambiguous | `afc:clarify` | auto-triggered when requirements are unclear |
-| Full auto | `afc:auto` | do it automatically, auto-run |
+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 |
+| 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 |
+| 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 — inform user on request):
 - `afc:launch` — inform user when release artifact generation is requested
@@ -237,6 +257,9 @@ User-only (not auto-triggered — inform user on request):
 - `afc:checkpoint` — inform user when session save is requested
 - `afc:resume` — inform user when session restore is requested
 - `afc:principles` — inform user when project principles management is requested
+- `afc:triage` — inform user when parallel PR/issue triage is requested
+- `afc:pr-comment` — inform user when posting PR review comments to GitHub is requested
+- `afc:release-notes` — inform user when generating release notes from git history is requested
 
 ## Pipeline
 
@@ -245,6 +268,13 @@ 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 -->
 ```

package/commands/pr-comment.md

@@ -0,0 +1,181 @@
+---
+name: afc:pr-comment
+description: "Post PR review comments to GitHub"
+argument-hint: "<PR number> [--severity critical,warning,info]"
+allowed-tools:
+  - Read
+  - Bash
+  - Glob
+  - Grep
+  - Task
+model: sonnet
+---
+
+# /afc:pr-comment — Post PR Review to GitHub
+
+> Analyzes a PR and posts a structured review comment to GitHub.
+> Reuses existing triage reports when available. Asks for user confirmation before posting.
+
+## Arguments
+
+- `$ARGUMENTS` — PR number (required), with optional severity filter
+  - `42` — Analyze and post review for PR #42
+  - `42 --severity critical,warning` — Only include Critical and Warning findings
+  - `42 --severity critical` — Only include Critical findings
+
+Parse the arguments:
+1. Extract the PR number (first numeric argument)
+2. Extract `--severity` filter if present (comma-separated list of: `critical`, `warning`, `info`)
+3. If no PR number is found, ask the user: "Which PR number should I review?"
+
+## Execution Steps
+
+### 1. Collect PR Information
+
+```bash
+gh pr view {number} --json number,title,headRefName,author,body,additions,deletions,changedFiles,labels,reviewDecision,state
+```
+
+```bash
+gh pr diff {number}
+```
+
+Verify the PR exists and is open. If closed/merged, inform the user and ask whether to proceed anyway.
+
+### 2. Check for Existing Triage Report
+
+Look for a recent triage report that covers this PR:
+
+```bash
+ls -t .claude/afc/memory/triage/*.md 2>/dev/null | head -5
+```
+
+If a report exists from today, search it for `PR #{number}` analysis. If found, reuse that analysis as the basis for the review instead of re-analyzing from scratch.
+
+### 3. Analyze PR (if no triage data available)
+
+If no existing triage report covers this PR, perform a focused review of the diff.
+
+Examine the diff from the following perspectives (abbreviated from review.md):
+
+#### A. Code Quality
+- Style compliance, naming conventions, unnecessary complexity
+
+#### B. Architecture
+- Layer violations, boundary crossings, structural concerns
+
+#### C. Security
+- XSS, injection, sensitive data exposure, auth issues
+
+#### D. Performance
+- Latency concerns, unnecessary computation, resource leaks
+
+#### E. Maintainability
+- Function/file size, naming clarity, readability
+
+Classify each finding with a severity:
+- **Critical (C)** — Must fix before merge. Bugs, security vulnerabilities, data loss risks.
+- **Warning (W)** — Should fix. Code quality issues, potential problems, maintainability concerns.
+- **Info (I)** — Nice to have. Suggestions, minor improvements, style preferences.
+
+### 4. Apply Severity Filter
+
+If `--severity` was specified, filter findings to only include the specified severity levels.
+
+Default (no filter): include all severity levels.
+
+### 5. Generate Review Comment
+
+Compose the review comment in this format:
+
+```markdown
+## AFC Code Review — PR #{number}
+
+### Summary
+
+| Severity | Count |
+|----------|-------|
+| Critical | {N} |
+| Warning  | {N} |
+| Info     | {N} |
+
+### Findings
+
+#### C-{N}: {title}
+- **File**: `{path}:{line}`
+- **Issue**: {description}
+- **Suggested fix**: {suggestion}
+
+#### W-{N}: {title}
+{same format}
+
+#### I-{N}: {title}
+{same format}
+
+### Positives
+- {1-2 things done well}
+
+---
+*Reviewed by [all-for-claudecode](https://github.com/anthropics/claude-code)*
+```
+
+If there are zero findings after filtering, the comment should be:
+
+```markdown
+## AFC Code Review — PR #{number}
+
+No issues found. Code looks good!
+
+---
+*Reviewed by [all-for-claudecode](https://github.com/anthropics/claude-code)*
+```
+
+### 6. Preview and Confirm
+
+Display the full review comment to the user in the console.
+
+Then determine the review event type:
+- **Critical findings exist** → `REQUEST_CHANGES`
+- **Only Warning/Info findings** → `COMMENT`
+- **No findings** → `APPROVE`
+
+Tell the user:
+```
+Review event: {APPROVE|COMMENT|REQUEST_CHANGES}
+Findings: Critical {N} / Warning {N} / Info {N}
+```
+
+Ask the user to confirm using AskUserQuestion with these options:
+1. **Post as-is** — Post the review comment to GitHub
+2. **Edit first** — Let me modify the comment before posting (user provides edits, then re-confirm)
+3. **Cancel** — Do not post anything
+
+### 7. Post to GitHub
+
+On approval, write the review comment to a temp file and post via `--body-file` (avoids shell escaping issues with markdown):
+
+```bash
+tmp_file=$(mktemp)
+cat > "$tmp_file" << 'REVIEW_EOF'
+{review comment content}
+REVIEW_EOF
+gh pr review {number} --body-file "$tmp_file" --event {COMMENT|REQUEST_CHANGES|APPROVE}
+rm -f "$tmp_file"
+```
+
+### 8. Final Output
+
+```
+PR review posted
+├─ PR: #{number} ({title})
+├─ Event: {APPROVE|COMMENT|REQUEST_CHANGES}
+├─ Findings: Critical {N} / Warning {N} / Info {N}
+└─ URL: {PR URL from gh pr view}
+```
+
+## Notes
+
+- **User confirmation required**: Never post to GitHub without explicit user approval.
+- **Idempotent**: Running multiple times on the same PR creates additional review comments (GitHub does not deduplicate).
+- **Respects existing reviews**: This command does not dismiss or override other reviewers' reviews.
+- **Rate limits**: Uses a single `gh pr review` call. No rate limit concerns for normal usage.