all-for-claudecode 2.9.1 → 2.11.0

package/{commands/review.md → skills/review/SKILL.md}

@@ -72,14 +72,14 @@ Before reviewing, identify **files affected by the changes** (not just the chang
 3. **Scope decision**:
    - Affected files are NOT full review targets (that would explode scope)
    - Instead, include them as **cross-reference context** in Step 2 and Step 3.5
-   - If an affected file has >3 references to a changed symbol → flag for closer inspection
+   - Flag affected files for closer inspection when they have significant coupling to the changed code — consider the nature of the references (type-only imports vs behavioral calls), the criticality of the affected file, and whether the references involve the specific symbols that changed.
 
 4. **Limitations** (include in review output):
    > ⚠ Dynamic dependencies not covered: runtime dispatch (`obj[method]()`), reflection, cross-language calls, config/env-driven branching. Manual verification recommended for these patterns.
 
 ### 2. Parallel Review (scaled by file count)
 
-Choose review orchestration based on the number of changed files:
+Assess review complexity holistically — consider total diff size (lines changed), file complexity, diversity of change types, and whether changes are localized to one module or cross-cutting across multiple boundaries.
 
 **Pre-scan: Call Chain Context** (for Parallel Batch and Review Swarm modes only):
 
@@ -97,21 +97,21 @@ Before distributing files to review agents, collect cross-boundary context:
    Review findings should account for these behaviors.
    ```
 
-For Direct review mode (≤5 files): skip pre-scan — orchestrator already has full context.
+For Direct review mode: skip pre-scan — orchestrator already has full context.
 
-#### 5 or fewer files: Direct review
-Review all files directly in the current context (no delegation).
+#### Low complexity: Direct review
+Appropriate when changes are small in total diff size, confined to a single module or area, and the reviewing model can hold all changed files in context without losing coherence. Review all files directly in the current context (no delegation).
 
-#### 6–10 files: Parallel Batch
-Distribute to parallel review agents (2–3 files per agent) in a **single message**:
+#### Moderate complexity: Parallel Batch
+Appropriate when changes span multiple files or modules, the total diff size is substantial, or different change types (e.g., API, UI, config) benefit from focused review segments. Distribute to parallel review agents (2–3 files per agent) in a **single message**:
 ```
 Task("Review: {file1, file2}", subagent_type: "general-purpose")
 Task("Review: {file3, file4}", subagent_type: "general-purpose")
 ```
 Read each agent's returned output, then write consolidated review.
 
-#### 11+ files: Review Swarm
-Create a review task pool and spawn pre-assigned review workers:
+#### High complexity: Review Swarm
+Appropriate when changes are large-scale, cross-cutting across many modules, involve mixed change types (security-sensitive code, architecture layers, business logic), or individual file groups require deep specialist focus. Create a review task pool and spawn pre-assigned review workers:
 
 > **Note**: Unlike implement swarm (which prohibits self-claiming due to write conflicts), review workers use orchestrator pre-assignment by file group. This is safe because review is read-only — no write race conditions.
 
@@ -204,9 +204,9 @@ For each changed file, examine from the following perspectives:
 
 After individual/parallel reviews complete, the **orchestrator** MUST perform a cross-boundary check. This is a required step, not optional — skipping it is a review defect.
 
-**For 11+ file reviews**: This is especially critical because individual review agents cannot see cross-file interactions. The orchestrator MUST read callee implementations directly.
+**For High complexity (Review Swarm) reviews**: This is especially critical because individual review agents cannot see cross-file interactions. The orchestrator MUST read callee implementations directly.
 
-0. **Impact Map integration**: Use the Impact Map from Step 1.5 to prioritize verification. Affected files with >3 references to changed symbols should be read and checked for breakage — even if no finding was raised against them.
+0. **Impact Map integration**: Use the Impact Map from Step 1.5 to prioritize verification. Affected files with significant coupling to changed symbols (behavioral call references, not just type imports, especially in critical code paths) should be read and checked for breakage — even if no finding was raised against them.
 
 1. **Filter**: From all collected findings, select those involving:
    - Call order changes (function A now calls B before C)

package/{commands/security.md → skills/security/SKILL.md}

@@ -41,11 +41,26 @@ For dependency audit command: infer from `packageManager` field in `package.json
 - `$ARGUMENTS` = "full" → entire `src/`
 - Not specified → changed files from `git diff --name-only HEAD`
 
-### 2. Agent Teams (if more than 10 files)
+### 2. Agent Teams (when scan complexity warrants it)
 
-Use parallel agents for wide-scope scans:
+Use Agent Teams when the scan scope is complex enough that a single-pass review would miss cross-file vulnerability patterns. Assess holistically:
 
-**Pre-scan: Data Flow Context** (before distributing to agents):
+- **File types**: Auth handlers, trust boundary code, and input-processing layers warrant deeper multi-agent scrutiny than config files or simple utilities
+- **Code volume**: Large files with dense logic benefit from focused agent attention
+- **Diversity of concerns**: Multiple distinct security domains (auth + injection + data exposure) across separate modules
+- **Trust boundaries**: Files that cross privilege levels (user input → DB, client → server, public → internal API)
+
+Use Agent Teams when any of the following apply:
+- Scan includes auth handlers, session management, or access control logic spanning multiple files
+- Input entry points and their sanitization/consumption code live in different directories
+- The scope spans multiple distinct security domains that cannot be assessed in a single coherent pass
+
+Use direct scan (orchestrator only) when:
+- Scope is a single module or tightly-coupled set of files
+- Security concerns are localized (e.g., one feature, one data flow)
+- No cross-file trust boundary transitions are involved
+
+**Pre-scan: Data Flow Context** (before distributing to agents, when using Agent Teams):
 
 1. For each changed file, identify **input entry points** (user input, API params, URL params, form data) and **sanitization calls** (validation, escaping, encoding)
 2. Trace input flow across changed files: where does user input enter? Where is it sanitized? Where is it consumed?
@@ -65,7 +80,7 @@ Task("Security scan: src/shared/api/", subagent_type: general-purpose,
   prompt: "... {include Data Flow Context} ...")
 ```
 
-For scans with ≤10 files: skip pre-scan — orchestrator has full context.
+For direct scans (orchestrator only): skip pre-scan — orchestrator has full context.
 
 ### 2.5. Cross-Boundary Verification
 

package/{commands/spec.md → skills/spec/SKILL.md}

@@ -53,7 +53,7 @@ Before writing the spec, understand the current project structure:
 3. Identify related type definitions, APIs, and components
 4. **Necessity & scope check** — evaluate whether the request warrants a full spec:
    - **Already exists?** If the feature substantially exists → report: "This feature appears to already exist at {path}." Ask user: enhance existing, replace entirely, or abort.
-   - **Over-scoped?** If `$ARGUMENTS` implies 10+ files or multiple unrelated concerns → warn and suggest splitting into separate specs.
+   - **Over-scoped?** If `$ARGUMENTS` implies multiple unrelated concerns or changes that span different architectural boundaries, warn and suggest splitting. Judge by the diversity and independence of concerns, not by file count — a well-organized feature touching many files in one module is fine, while a small change spanning security, database, and UI layers may be over-scoped.
    - **Trivial?** If the change is small enough to implement directly (typo, config value, single-line fix) → suggest: "This can be implemented directly without a full spec. Proceed with direct edit?"
    - If user chooses abort → end with `"No spec generated — {reason}."` and suggest the appropriate alternative.
 
@@ -75,82 +75,7 @@ Detect whether `$ARGUMENTS` references external libraries, APIs, or technologies
 
 ### 3. Write Spec
 
-Create `.claude/afc/specs/{feature-name}/spec.md`:
-
-```markdown
-# Feature Spec: {feature name}
-
-> Created: {YYYY-MM-DD}
-> Branch: {BRANCH_NAME}
-> Status: Draft
-
-## Overview
-{2-3 sentences on the purpose and background of the feature}
-
-## User Stories
-
-### US1: {story title} [P1]
-**Description**: {feature description from user perspective}
-**Priority rationale**: {why this order}
-**Independent testability**: {whether this story can be tested on its own}
-
-#### Acceptance Scenarios (GWT for user scenarios)
-- [ ] Given {precondition}, When {action}, Then {result}
-- [ ] Given {precondition}, When {action}, Then {result}
-
-#### System Requirements (EARS notation)
-
-> Use one of the 5 EARS patterns for each requirement. Each requirement must map to at least one expected test case (TC).
-
-| Pattern | Template | Use When |
-|---------|----------|----------|
-| Ubiquitous | `THE System SHALL {behavior}` | Always-on property (no trigger needed) |
-| Event-driven | `WHEN {trigger}, THE System SHALL {response}` | Specific event triggers a response |
-| State-driven | `WHILE {state}, THE System SHALL {behavior}` | Behavior depends on system state |
-| Unwanted | `IF {condition}, THE System SHALL {handling}` | Error/failure handling |
-| Optional | `WHERE {feature/config active}, THE System SHALL {behavior}` | Feature flag or conditional capability |
-
-- [ ] WHEN {trigger}, THE System SHALL {behavior} → TC: `should_{behavior}_when_{trigger}`
-- [ ] WHILE {state}, THE System SHALL {behavior} → TC: `should_{behavior}_while_{state}`
-
-### US2: {story title} [P2]
-{same format}
-
-## Requirements
-
-### Functional Requirements
-- **FR-001**: {requirement}
-- **FR-002**: {requirement}
-
-### Non-Functional Requirements
-- **NFR-001**: {performance/security/accessibility etc.}
-
-### Auto-Suggested NFRs
-{Load `${CLAUDE_PLUGIN_ROOT}/docs/nfr-templates.md` and select 3-5 relevant NFRs based on the project type detected from afc.config.md}
-- **NFR-A01** [AUTO-SUGGESTED]: {suggestion from matching project type template}
-- **NFR-A02** [AUTO-SUGGESTED]: {suggestion}
-- **NFR-A03** [AUTO-SUGGESTED]: {suggestion}
-{Tag each with [AUTO-SUGGESTED]. Users may accept, modify, or remove.}
-
-### Key Entities
-| Entity | Description | Related Existing Code |
-|--------|-------------|-----------------------|
-| {name} | {description} | {path or "new"} |
-
-## Success Criteria
-- **SC-001**: {measurable success indicator}
-- **SC-002**: {measurable success indicator}
-
-## Edge Cases
-- {edge case 1}
-- {edge case 2}
-
-## Constraints
-- {technical/business constraints}
-
-## [NEEDS CLARIFICATION]
-- {uncertain items — record if any, remove section if none}
-```
+Create `.claude/afc/specs/{feature-name}/spec.md` following the template in `${CLAUDE_SKILL_DIR}/spec-template.md`. Read it first, then generate the spec using that structure.
 
 ### 3.5. Inline Clarification (standalone mode only)
 

package/skills/spec/spec-template.md

@@ -0,0 +1,72 @@
+# Feature Spec: {feature name}
+
+> Created: {YYYY-MM-DD}
+> Branch: {BRANCH_NAME}
+> Status: Draft
+
+## Overview
+{2-3 sentences on the purpose and background of the feature}
+
+## User Stories
+
+### US1: {story title} [P1]
+**Description**: {feature description from user perspective}
+**Priority rationale**: {why this order}
+**Independent testability**: {whether this story can be tested on its own}
+
+#### Acceptance Scenarios (GWT for user scenarios)
+- [ ] Given {precondition}, When {action}, Then {result}
+- [ ] Given {precondition}, When {action}, Then {result}
+
+#### System Requirements (EARS notation)
+
+> Use one of the 5 EARS patterns for each requirement. Each requirement must map to at least one expected test case (TC).
+
+| Pattern | Template | Use When |
+|---------|----------|----------|
+| Ubiquitous | `THE System SHALL {behavior}` | Always-on property (no trigger needed) |
+| Event-driven | `WHEN {trigger}, THE System SHALL {response}` | Specific event triggers a response |
+| State-driven | `WHILE {state}, THE System SHALL {behavior}` | Behavior depends on system state |
+| Unwanted | `IF {condition}, THE System SHALL {handling}` | Error/failure handling |
+| Optional | `WHERE {feature/config active}, THE System SHALL {behavior}` | Feature flag or conditional capability |
+
+- [ ] WHEN {trigger}, THE System SHALL {behavior} → TC: `should_{behavior}_when_{trigger}`
+- [ ] WHILE {state}, THE System SHALL {behavior} → TC: `should_{behavior}_while_{state}`
+
+### US2: {story title} [P2]
+{same format}
+
+## Requirements
+
+### Functional Requirements
+- **FR-001**: {requirement}
+- **FR-002**: {requirement}
+
+### Non-Functional Requirements
+- **NFR-001**: {performance/security/accessibility etc.}
+
+### Auto-Suggested NFRs
+{Load `${CLAUDE_SKILL_DIR}/nfr-templates.md` and select 3-5 relevant NFRs based on the project type detected from afc.config.md}
+- **NFR-A01** [AUTO-SUGGESTED]: {suggestion from matching project type template}
+- **NFR-A02** [AUTO-SUGGESTED]: {suggestion}
+- **NFR-A03** [AUTO-SUGGESTED]: {suggestion}
+{Tag each with [AUTO-SUGGESTED]. Users may accept, modify, or remove.}
+
+### Key Entities
+| Entity | Description | Related Existing Code |
+|--------|-------------|-----------------------|
+| {name} | {description} | {path or "new"} |
+
+## Success Criteria
+- **SC-001**: {measurable success indicator}
+- **SC-002**: {measurable success indicator}
+
+## Edge Cases
+- {edge case 1}
+- {edge case 2}
+
+## Constraints
+- {technical/business constraints}
+
+## [NEEDS CLARIFICATION]
+- {uncertain items — record if any, remove section if none}

package/{commands/triage.md → skills/triage/SKILL.md}

@@ -71,9 +71,8 @@ Task("Triage PR #{number}: {title}", subagent_type: "general-purpose",
   2. Run: gh pr view {number} --comments
   3. Analyze the diff for:
      - What the PR does (1-2 sentence summary)
-     - Risk level: Critical (core logic, auth, data, security-related config) / Medium (features, UI) / Low (docs, non-security config, tests)
-       NOTE: Config files that touch auth, security, permissions, secrets, or access control keywords are Critical, not Low
-     - Complexity: High (>10 files or cross-cutting) / Medium (3-10 files) / Low (<3 files)
+     - Risk level: Assess the actual impact of this PR on the system. Consider: does it change trust boundaries, data flows, or core business logic? Could a bug here cause data loss, security breach, or service outage? Rate risk based on potential blast radius, not file categories.
+     - Complexity: Assess the cognitive complexity of reviewing this PR. Consider: how many distinct concerns does it touch, does it cross architectural boundaries, does understanding one change require understanding another? Rate complexity based on review difficulty, not file count.
      - Whether build/test verification is needed (yes/no + reason)
      - Potential issues or concerns (max 3)
      - Suggested reviewers or labels if obvious
@@ -98,9 +97,9 @@ Task("Triage Issues #{n1}-#{n5}", subagent_type: "general-purpose",
   For each issue:
   1. Read issue body and comments: gh issue view {number} --comments
   2. Classify:
-     - Type: Bug / Feature / Enhancement / Question / Maintenance
-     - Priority: P0 (blocking) / P1 (important) / P2 (nice-to-have) / P3 (backlog)
-     - Estimated effort: Small (< 1 day) / Medium (1-3 days) / Large (3+ days)
+     - Type: Classify based on the issue's actual nature. The standard categories (Bug, Feature, Enhancement, Question, Maintenance) serve as defaults, but adapt to the project's own labeling conventions if they differ.
+     - Priority: Assess priority based on the issue's relationship to current work, user impact, and project goals — not by forcing into generic P0-P3 buckets. Consider: is this blocking other work? How many users are affected? Does it align with current priorities?
+     - Estimated effort: Estimate based on the actual scope of work required, considering project complexity and available context — not by rigid day-count buckets.
      - Related PRs (if any mentioned)
   3. One-line summary
 
@@ -203,7 +202,7 @@ Merge Phase 1 and Phase 2 results into a single report:
 - **Immediate attention**: {list of Critical PRs and P0 issues}
 - **Ready to merge**: {PRs with no concerns and passing checks}
 - **Needs discussion**: {PRs/issues requiring team input}
-- **Stale items**: {PRs/issues with no activity > 14 days}
+- **Stale items**: {PRs/issues with no meaningful activity for an extended period. Consider the project's typical development cadence — what counts as stale depends on the project's release cycle and activity patterns.}
 ```
 
 ### 5. Save Report