all-for-claudecode 2.12.0 → 2.13.0

package/.claude-plugin/marketplace.json

@@ -6,14 +6,14 @@
   },
   "metadata": {
     "description": "Automated pipeline for Claude Code — spec → plan → implement → review → clean",
-    "version": "2.12.0"
+    "version": "2.13.0"
   },
   "plugins": [
     {
       "name": "afc",
       "source": "./",
       "description": "Automated pipeline for Claude Code. Automates the full development cycle: spec → plan → implement → review → clean.",
-      "version": "2.12.0",
+      "version": "2.13.0",
       "category": "automation",
       "tags": ["pipeline", "automation", "spec", "plan", "implement", "review", "critic-loop"]
     }

package/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "afc",
-  "version": "2.12.0",
+  "version": "2.13.0",
   "description": "Automated pipeline for Claude Code. Automates the full development cycle: spec → plan → implement → review → clean.",
   "author": { "name": "jhlee0409", "email": "relee6203@gmail.com" },
   "homepage": "https://github.com/jhlee0409/all-for-claudecode",

package/README.md

@@ -132,6 +132,8 @@ Performance: ✓ no N+1 queries
 | `/afc:qa` | Project quality audit — test confidence, error resilience, code health |
 | `/afc:consult` | Expert consultation (backend, infra, PM, design, marketing) |
 | `/afc:triage` | Analyze open PRs and issues in parallel |
+| `/afc:issue` | Analyze a single GitHub issue and create actionable document |
+| `/afc:resolve` | Analyze and address LLM bot review comments on a PR |
 | `/afc:pr-comment` | Generate structured PR review comments |
 | `/afc:release-notes` | Generate release notes from git history |
 | `/afc:learner` | Review and promote learned patterns to project rules |

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "all-for-claudecode",
-  "version": "2.12.0",
+  "version": "2.13.0",
   "description": "Claude Code plugin that automates the full dev cycle — spec, plan, implement, review, clean.",
   "bin": {
     "all-for-claudecode": "bin/cli.mjs"

package/scripts/afc-user-prompt-submit.sh

@@ -42,7 +42,7 @@ if ! afc_state_is_active; then
   LOWER=$(printf '%s' "$USER_TEXT" | tr '[:upper:]' '[:lower:]' | cut -c1-500)
 
   # Compact skill catalog: injected when regex misses, so the model classifies semantically
-  FALLBACK_HINT="[afc] Route via Skill tool if applicable — debug(bug/에러/수정/fix) | review(코드검토/리뷰/PR) | test(테스트/coverage) | spec(요구사항/스펙) | plan(설계/계획) | implement(구현/리팩터) | auto(새기능/feature) | consult(조언/상의/discuss) | analyze(분석/trace) | research(조사/리서치) | security(보안/취약점) | architect(아키텍처/설계) | qa(품질감사) | launch(릴리스/배포) | triage(PR정리/이슈분류) | clean(정리/cleanup) | ideate(아이디어/brainstorm) | doctor(진단/health) | release-notes(변경이력)"
+  FALLBACK_HINT="[afc] Route via Skill tool if applicable — debug(bug/에러/수정/fix) | review(코드검토/리뷰/PR) | test(테스트/coverage) | spec(요구사항/스펙) | plan(설계/계획) | implement(구현/리팩터) | auto(새기능/feature) | consult(조언/상의/discuss) | analyze(분석/trace) | research(조사/리서치) | security(보안/취약점) | architect(아키텍처/설계) | qa(품질감사) | launch(릴리스/배포) | triage(PR정리/이슈분류) | issue(이슈분석) | resolve(LLM리뷰대응) | clean(정리/cleanup) | ideate(아이디어/brainstorm) | doctor(진단/health) | release-notes(변경이력)"
 
   # Early exit for empty prompts (context-only messages, malformed JSON)
   if [ -z "$LOWER" ]; then
@@ -83,6 +83,10 @@ if ! afc_state_is_active; then
     SKILL="afc:launch"
   elif printf '%s' "$LOWER" | grep -qE '(triage|pr.?정리|이슈.?정리|백로그.?정리|pr.?분류|이슈.?분류)' 2>/dev/null; then
     SKILL="afc:triage"
+  elif printf '%s' "$LOWER" | grep -qE '(issue.*분석|이슈.*분석|analyze.*issue|issue.*#[0-9]|이슈.*#[0-9])' 2>/dev/null; then
+    SKILL="afc:issue"
+  elif printf '%s' "$LOWER" | grep -qE '(review.*comment|resolve.*comment|coderabbit|copilot.*review|리뷰.*코멘트|봇.*리뷰|bot.*review.*fix)' 2>/dev/null; then
+    SKILL="afc:resolve"
   # Medium confidence: still distinctive but broader
   elif printf '%s' "$LOWER" | grep -qE '(specification|requirements|acceptance criteria|요구.?사항|기능.?정의|인수.?조건)' 2>/dev/null; then
     SKILL="afc:spec"

package/skills/issue/SKILL.md

@@ -0,0 +1,216 @@
+---
+name: afc:issue
+description: "Analyze GitHub issue and create actionable document — use when the user asks to analyze a GitHub issue, understand an issue, or inspect a specific issue number"
+argument-hint: "<GitHub issue URL, owner/repo#number, #number, or number>"
+allowed-tools:
+  - Read
+  - Grep
+  - Glob
+  - Bash
+  - WebFetch
+  - Write
+model: sonnet
+---
+
+# /afc:issue — GitHub Issue Analysis
+
+> Analyzes a single GitHub issue (title, body, labels, comments, attached images) and produces a structured analysis document.
+> Searches the codebase for related files and suggests the appropriate next afc skill (debug, spec, or auto).
+
+## Arguments
+
+- `$ARGUMENTS` — (required) One of:
+  - Issue number: `123` or `#123`
+  - GitHub URL: `https://github.com/owner/repo/issues/123`
+  - Cross-repo: `owner/repo#123`
+
+## Execution Steps
+
+### 1. Prerequisites Check
+
+Verify `gh` CLI is available and authenticated:
+
+```bash
+gh --version >/dev/null 2>&1 && gh auth status >/dev/null 2>&1
+```
+
+If either check fails:
+- Output: `[afc:issue] Error: GitHub CLI (gh) is not installed or not authenticated. Install from https://cli.github.com/ and run 'gh auth login'.`
+- **Abort immediately.**
+
+### 2. Parse Input
+
+Determine the input format and extract owner, repo, and issue number:
+
+1. **GitHub URL** (`https://github.com/{owner}/{repo}/issues/{number}`):
+   - Extract owner, repo, number from URL path segments
+   - Set `GH_REPO_FLAG="--repo {owner}/{repo}"`
+
+2. **Cross-repo** (`{owner}/{repo}#{number}`):
+   - Split on `#` — left part is `owner/repo`, right part is number
+   - Set `GH_REPO_FLAG="--repo {owner}/{repo}"`
+
+3. **Local number** (`123` or `#123`):
+   - Strip leading `#` if present
+   - Set `GH_REPO_FLAG=""` (use current repo from git remote)
+
+### 3. Collect Issue Data
+
+```bash
+gh issue view {number} {GH_REPO_FLAG} --json number,title,body,labels,author,comments,createdAt,state,url
+```
+
+If the command fails:
+- `Issue #{number} not found` → output error and **abort**
+- Other errors → output the gh error message and **abort**
+
+Parse the JSON response and extract:
+- `TITLE`, `BODY`, `LABELS`, `AUTHOR`, `COMMENTS`, `CREATED_AT`, `STATE`, `URL`
+
+### 4. Analyze Attached Images
+
+Extract image URLs from the issue body:
+- Markdown images: `![alt]({url})`
+- HTML images: `<img src="{url}">`
+- **Skip** images inside code blocks (` ``` ` fences)
+
+For each extracted image URL:
+1. Attempt to fetch with WebFetch
+2. If successful: analyze the image content (error messages, UI screenshots, console output, stack traces)
+3. If fetch fails: record `[Image unavailable: {url}]`
+
+Tag all image analysis results with `[Image Analysis]` to indicate AI interpretation.
+
+If no images found: note `No attached media found.`
+
+### 5. Analyze Comments
+
+If comments exist:
+- If more than 20 comments: analyze only the **most recent 20** and note `"Analyzed 20 of {N} comments (most recent)"`
+- Extract additional context from comments: reproduction steps, error logs, workarounds, maintainer responses, related issue/PR references
+
+### 6. Search Codebase
+
+Extract keywords from the issue title, body, and comments:
+- Error messages (quoted strings, stack trace patterns)
+- Function/class/module names
+- File paths mentioned
+- Technical terms specific to the project
+
+For each keyword, search the codebase using Grep and Glob:
+- Record matching files with line numbers and relevance reason
+- If no matches found: note `No related code found in current codebase.`
+
+### 7. Classify Issue
+
+Based on the analysis, classify the issue:
+
+| Signal | Classification |
+|--------|---------------|
+| Error messages, stack traces, reproduction steps, "doesn't work", "broken" | **Bug Report** |
+| "Add", "support", "new feature", "would be nice", "enhancement" | **Feature Request** |
+| "How to", "is it possible", "what is", "documentation" | **Question** |
+| "Improve", "refactor", "better", "optimize", existing feature modification | **Enhancement** |
+
+Assess severity:
+- **Critical**: Data loss, security vulnerability, crash, blocks usage
+- **High**: Major functionality broken, no workaround
+- **Medium**: Functionality issue with workaround, or significant UX problem
+- **Low**: Minor issue, cosmetic, or nice-to-have improvement
+
+Estimate scope:
+- **Small** (1-2 files): Typo, config change, simple bug fix
+- **Medium** (3-5 files): Feature addition, moderate refactor
+- **Large** (6+ files): Cross-cutting concern, architectural change
+
+### 8. Determine Next Step
+
+Based on classification:
+
+| Type | Suggested Next Step |
+|------|-------------------|
+| Bug Report | `/afc:debug "{issue title summary}"` |
+| Feature Request | `/afc:spec "{feature description}"` or `/afc:auto "{feature description}"` |
+| Question | `Reply to issue — provide answer or point to documentation` |
+| Enhancement | `/afc:spec "{enhancement description}"` |
+| Insufficient info | `Reply to issue — request: {specific missing information}` |
+
+### 9. Save Analysis Document
+
+Create directory if needed:
+```bash
+mkdir -p .claude/afc/issues
+```
+
+Check for existing analysis:
+- If `.claude/afc/issues/{number}-*.md` exists → ask user: "Overwrite existing analysis for issue #{number}?"
+
+Generate slug from title: lowercase, replace non-alphanumeric with `-`, truncate to 40 chars.
+
+Write to `.claude/afc/issues/{number}-{slug}.md`:
+
+```markdown
+# Issue #{number}: {title}
+
+> Analyzed: {YYYY-MM-DD}
+> Source: {url}
+> Labels: {labels, comma-separated}
+> Author: {author}
+> State: {Open/Closed}
+
+## Summary
+
+{2-4 sentence summary of what the issue is about and what it requires.
+Not just a restatement of the title — include context from body, comments, and images.}
+
+## Attached Media Analysis
+
+{If images exist:}
+> [Image Analysis] Below is AI interpretation of attached media.
+
+- **Image 1** ({filename or "screenshot"}): {description of what the image shows — error messages, UI state, console output}
+- **Image 2**: ...
+
+{If no images:}
+No attached media found.
+
+## Codebase Impact
+
+{If related files found:}
+- `{path}:{line}` — {why this file is related}
+- `{path}:{line}` — {why this file is related}
+
+{If no related files:}
+No related code found in current codebase.
+
+## Classification
+
+- **Type**: {Bug Report | Feature Request | Question | Enhancement}
+- **Severity**: {Critical | High | Medium | Low}
+- **Estimated Scope**: {Small (1-2 files) | Medium (3-5) | Large (6+)}
+
+## Suggested Next Step
+
+- [ ] {Primary suggestion with full command} — {reason}
+- [ ] {Secondary suggestion if applicable} — {reason}
+```
+
+### 10. Output Summary
+
+```
+Issue analyzed
+├─ Issue: #{number} — {title}
+├─ Type: {classification}
+├─ Severity: {severity}
+├─ Related files: {count}
+├─ Document: .claude/afc/issues/{number}-{slug}.md
+└─ Next step: {primary suggestion}
+```
+
+## Notes
+
+- **Read-only**: This skill does not modify any code. It only creates an analysis document.
+- **Image analysis is best-effort**: AI interpretation of screenshots may not be 100% accurate. The `[Image Analysis]` tag makes this explicit.
+- **Not part of auto pipeline**: This is a standalone skill invoked manually.
+- **Relationship to triage**: `afc:triage` handles bulk PR/issue analysis. `afc:issue` handles deep individual issue analysis. They are complementary.
+- **Comment limit**: Max 20 comments analyzed to keep context manageable. Most recent comments are prioritized as they often contain the most relevant information.

package/skills/resolve/SKILL.md

@@ -0,0 +1,245 @@
+---
+name: afc:resolve
+description: "Analyze and address LLM review comments on PR — use when the user asks to resolve, fix, or respond to bot review comments (CodeRabbit, Copilot, Codex) on a pull request"
+argument-hint: "<PR URL, owner/repo#number, #number, or number>"
+allowed-tools:
+  - Read
+  - Grep
+  - Glob
+  - Bash
+  - Edit
+  - Write
+  - AskUserQuestion
+model: sonnet
+---
+
+# /afc:resolve — LLM Review Comment Resolution
+
+> Collects LLM bot review comments (CodeRabbit, Copilot, Codex, etc.) from a PR, classifies each as VALID/NOISE/DISCUSS, applies fixes for VALID items, and asks the user about DISCUSS items.
+> Creates a single commit with all fixes and outputs a summary report.
+
+## Arguments
+
+- `$ARGUMENTS` — (required) One of:
+  - PR number: `456` or `#456`
+  - GitHub URL: `https://github.com/owner/repo/pull/456`
+  - Cross-repo: `owner/repo#456`
+
+## Execution Steps
+
+### 1. Prerequisites Check
+
+Verify `gh` CLI is available and authenticated:
+
+```bash
+gh --version >/dev/null 2>&1 && gh auth status >/dev/null 2>&1
+```
+
+If either check fails:
+- Output: `[afc:resolve] Error: GitHub CLI (gh) is not installed or not authenticated. Install from https://cli.github.com/ and run 'gh auth login'.`
+- **Abort immediately.**
+
+### 2. Parse Input
+
+Determine the input format and extract owner, repo, and PR number:
+
+1. **GitHub URL** (`https://github.com/{owner}/{repo}/pull/{number}`):
+   - Extract owner, repo, number from URL path segments
+   - Set `GH_REPO_FLAG="--repo {owner}/{repo}"`
+
+2. **Cross-repo** (`{owner}/{repo}#{number}`):
+   - Split on `#` — left part is `owner/repo`, right part is number
+   - Set `GH_REPO_FLAG="--repo {owner}/{repo}"`
+
+3. **Local number** (`456` or `#456`):
+   - Strip leading `#` if present
+   - Set `GH_REPO_FLAG=""` (use current repo from git remote)
+
+### 3. Collect Review Comments
+
+Collect all review comments from the PR:
+
+```bash
+gh pr view {number} {GH_REPO_FLAG} --json reviews,comments,url,title,headRefName
+```
+
+Additionally, collect inline review comments:
+
+```bash
+gh api repos/{owner}/{repo}/pulls/{number}/comments --paginate
+```
+
+If `--repo` flag was not used, derive owner/repo from `gh repo view --json owner,name`.
+
+If API call fails → output the error and **abort**.
+
+### 4. Filter Bot Comments
+
+Identify LLM bot comments by checking the comment author's login:
+
+**Known bot patterns**:
+- `coderabbitai[bot]` — CodeRabbit
+- `copilot[bot]` or `github-copilot[bot]` — GitHub Copilot
+- `codex[bot]` — Codex
+- Any login ending with `[bot]` — generic bot detection
+
+**Filter rules**:
+- Keep only comments where the author matches a bot pattern
+- Discard all human reviewer comments (MVP scope)
+- If an inline comment is marked as `outdated` by GitHub → tag as `[OUTDATED]`
+
+If 0 bot comments found:
+- Output: `No LLM bot review comments found on PR #{number}.`
+- **Exit gracefully** (success, not error).
+
+### 5. Classify Each Comment
+
+For each bot comment, analyze the content and classify:
+
+| Classification | Criteria | Action |
+|---------------|----------|--------|
+| **VALID** | Real bug, security issue, clear improvement, correct suggestion with code context | Auto-fix |
+| **NOISE** | Style preference difference, intentional design choice, false positive, already addressed | Skip |
+| **DISCUSS** | Architecture decision needed, tradeoff exists, multiple valid approaches, no code `path`/`position` (non-code feedback) | Ask user |
+
+**Classification guidelines**:
+- If the comment points to a concrete bug (null check, off-by-one, resource leak) → **VALID**
+- If the comment is about naming convention or style that differs from project rules → **NOISE**
+- If the comment suggests a refactor with pros/cons → **DISCUSS**
+- If multiple bots give conflicting advice on the same line → **DISCUSS**
+- If the comment is on an `[OUTDATED]` diff → **NOISE** (code already changed)
+
+Also collect from each comment:
+- `file_path`: the file the comment targets
+- `line`: the line number (if available)
+- `suggestion`: the suggested change (if available)
+- `body`: the full comment text
+
+### 6. Present Classification Summary
+
+Before making any changes, present the classification to the user:
+
+```
+PR #{number}: {title}
+Branch: {headRefName}
+
+Bot comments: {total_count} ({bot_names})
+
+VALID ({count}):
+  1. [{bot}] {file}:{line} — {1-line summary of issue}
+  2. [{bot}] {file}:{line} — {1-line summary of issue}
+
+NOISE ({count}):
+  1. [{bot}] {file}:{line} — {reason for skipping}
+
+DISCUSS ({count}):
+  1. [{bot}] {file}:{line} — {question for user}
+```
+
+### 7. Handle DISCUSS Items
+
+For each DISCUSS item, present to the user:
+
+```
+[DISCUSS #{n}] {bot_name} on {file}:{line}
+
+Comment:
+> {original comment text, truncated to 500 chars}
+
+Target code:
+> {relevant code snippet, 5 lines context}
+
+If applied: {description of what would change}
+Tradeoff: {why this is not a clear-cut decision}
+
+Options:
+  1. Apply — treat as VALID, fix the code
+  2. Skip — treat as NOISE, record skip reason
+  3. Defer — skip for now, revisit later
+```
+
+Wait for user response. Reclassify based on choice:
+- `Apply` → move to VALID list
+- `Skip` → move to NOISE list with user's reason
+- `Defer` → keep as DISCUSS in report
+
+### 8. Apply VALID Fixes
+
+For each VALID comment (including user-accepted DISCUSS items):
+
+1. **Read the target file** before modifying
+2. **Identify the exact location** from the comment's `file_path` and `line`
+3. **Apply the fix** using Edit tool:
+   - If the bot provided a specific code suggestion → apply it
+   - If the bot described the issue without a suggestion → implement the fix based on the description
+4. **Verify** the fix doesn't break the immediate surrounding code context
+
+If the target file is in a dirty state (uncommitted changes unrelated to this PR):
+- Warn user: `{file} has uncommitted changes not related to this PR. Proceed?`
+- If user declines → skip this fix, note in report
+
+If the target file was deleted in the PR branch:
+- Skip, note `[FILE DELETED]` in report
+
+### 9. Commit Changes
+
+**Before committing**, show the user a summary of all changes:
+
+```
+Changes to commit:
+  {file1}: {description of change}
+  {file2}: {description of change}
+  Total: {N} files changed
+
+Proceed with commit? (y/n)
+```
+
+**Wait for user confirmation** before committing. This is a safety requirement.
+
+**Commit strategy**:
+- If VALID items ≤ 9: single commit
+- If VALID items ≥ 10: group by file/module into 2-3 commits
+
+**Commit message format** (single commit):
+```
+resolve LLM review comments on #{number}
+
+- fix: {description} ({bot_name})
+- fix: {description} ({bot_name})
+- skip: {reason} (NOISE, {count} items)
+```
+
+Do **NOT** push automatically. The user decides when to push.
+
+### 10. Output Report
+
+```
+Resolve complete
+├─ PR: #{number} — {title}
+├─ Bot comments: {total} ({bot_names})
+├─ VALID: {count} (applied)
+├─ NOISE: {count} (skipped)
+├─ DISCUSS: {count} (applied: {n}, skipped: {n}, deferred: {n})
+├─ Commit: {hash} ({files_changed} files, +{additions}/-{deletions})
+└─ Push: not pushed (run 'git push' when ready)
+```
+
+If no VALID items were found (all NOISE/DISCUSS-skipped):
+```
+Resolve complete
+├─ PR: #{number} — {title}
+├─ Bot comments: {total} ({bot_names})
+├─ VALID: 0
+├─ NOISE: {count}
+├─ DISCUSS: {count} (all skipped/deferred)
+└─ No changes made
+```
+
+## Notes
+
+- **MVP scope**: Only bot comments are analyzed. Human reviewer comments are ignored. Use `afc:review` for human-initiated code review.
+- **No auto-push**: Changes are committed but never pushed automatically. The user controls when to push.
+- **User confirmation required**: All code changes must be confirmed by the user before committing (NFR-003 safety requirement).
+- **Not part of auto pipeline**: This is a standalone skill invoked manually.
+- **Idempotency**: Re-running on the same PR will skip comments that have already been addressed (the code diff won't match the bot's original concern).
+- **Relationship to other skills**: `afc:review` does full code review. `afc:pr-comment` posts review comments. `afc:resolve` addresses existing bot comments. They are complementary.

package/skills/setup/SKILL.md

@@ -163,6 +163,8 @@ User-only (not auto-triggered — when user invokes directly via `/afc:X`, execu
 - `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

package/skills/spec/SKILL.md

@@ -41,7 +41,8 @@ If config file is missing:
 2. Determine **feature name**:
    - Extract 2-3 key keywords from `$ARGUMENTS`
    - Convert to kebab-case (e.g., "add user authentication" → `user-auth`)
-3. **Create directory**: `.claude/afc/specs/{feature-name}/` (create parent `.claude/afc/specs/` directory if it does not exist)
+   - Prepend today's date in `YYYY-MM-DD` format (e.g., `2026-03-13-user-auth`)
+3. **Create directory**: `.claude/afc/specs/{YYYY-MM-DD}-{feature-name}/` (create parent `.claude/afc/specs/` directory if it does not exist)
 4. If already exists, confirm with user: "Overwrite existing spec?"
 
 ### 2. Explore Codebase
@@ -67,7 +68,7 @@ Detect whether `$ARGUMENTS` references external libraries, APIs, or technologies
 4. **If external references detected**:
    - For each unknown reference, run a focused WebSearch query: `"{library/API name} latest stable version usage guide {current year}"`
    - Optionally use Context7 (`mcp__context7__resolve-library-id` → `mcp__context7__query-docs`) for library-specific documentation
-   - Record findings to `.claude/afc/specs/{feature-name}/research-notes.md` (lightweight spec-scoped notes; distinct from plan phase's `research.md` which covers deep technical research)
+   - Record findings to `.claude/afc/specs/{YYYY-MM-DD}-{feature-name}/research-notes.md` (lightweight spec-scoped notes; distinct from plan phase's `research.md` which covers deep technical research)
    - Also use findings inline as context for spec writing
    - Tag each researched item in spec with `[RESEARCHED]` for traceability
 
@@ -75,7 +76,7 @@ Detect whether `$ARGUMENTS` references external libraries, APIs, or technologies
 
 ### 3. Write Spec
 
-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.
+Create `.claude/afc/specs/{YYYY-MM-DD}-{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)
 
@@ -127,7 +128,7 @@ When not running inside `/afc:auto`, save progress for `/afc:resume`:
 
 ```
 Spec generated
-├─ .claude/afc/specs/{feature-name}/spec.md
+├─ .claude/afc/specs/{YYYY-MM-DD}-{feature-name}/spec.md
 ├─ User Stories: {count}
 ├─ Requirements: FR {count}, NFR {count}
 ├─ Research: {N} external references researched / skipped (all internal)