[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M754MSMJ363B0XQYP0R718QM":3,"skill-same:01M754MSMJ363B0XQYP0R718QM":57},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":29,"commitSha":30,"skillDirectory":31,"forksCount":32,"repositoryHtmlUrl":33,"repositoryHomepageUrl":6,"ownerHtmlUrl":34,"ownerBlogUrl":35,"ownerDescription":36,"updatedAt":37,"install":38,"resources":50},"01M754MSMJ363B0XQYP0R718QM","x-generate-adr",null,"Automates ADR generation from architecture plan mini-ADRs: extracts inline decisions, expands to full ADR format, assigns sequential numbering, updates the ADR index, and adds cross-references.","review-bench\u002Federcnj_ia-dev-environment","review-bench","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F286778065?v=4","01M7517F9NTEPDZDAXJBR30FWT","ReviewBench","01M7517FAC9F4P7TGWCNJ8VYVW",0,"MIT","https:\u002F\u002Fgithub.com\u002Freview-bench\u002Federcnj_ia-dev-environment\u002Fblob\u002Fmain\u002Fsrc\u002Ftest\u002Fresources\u002Fgolden\u002Fjava-spring-fintech-pci\u002F.claude\u002Fskills\u002Fx-generate-adr\u002FSKILL.md",[],[],"2026-11-12 13:55:43",false,"---\nname: x-generate-adr\ndescription: \"Automates ADR generation from architecture plan mini-ADRs: extracts inline decisions, expands to full ADR format, assigns sequential numbering, updates the ADR index, and adds cross-references.\"\nuser-invocable: true\nallowed-tools: Read, Write, Edit, Bash, Grep, Glob\nargument-hint: \"[architecture-plan-path] [story-id]\"\ncontext-budget: medium\nrequires-capabilities: []\n---\n\n## Global Output Policy\n\n- **Language**: English ONLY.\n- **Tone**: Technical, Direct, and Concise.\n- **Efficiency**: Remove all conversational fillers and greetings to save tokens.\n\n# Skill: ADR Automation\n\n## Purpose\n\nAutomates the generation of Architecture Decision Records (ADRs) from mini-ADRs embedded in architecture plans. Extracts inline decisions, expands them to full ADR format using a standard template, assigns sequential numbering, updates the ADR index, and inserts cross-references between stories, architecture plans, and ADRs.\n\n## Triggers\n\n- `\u002Fx-generate-adr [architecture-plan-path] [story-id]` — extract mini-ADRs from the specified architecture plan and generate full ADR files\n- After the architecture plan phase, when mini-ADRs exist inline in the plan document\n- When `x-plan-architecture` has produced an architecture plan containing `### ADR:` markers\n- When architectural decisions need formal documentation as standalone ADR files\n- When the `docs\u002Fadr\u002F` directory needs to be populated or updated with new decisions\n- Do NOT use if ADRs have already been manually created for the same decisions\n\n## Parameters\n\n| Parameter | Type | Required | Description |\n|-----------|------|----------|-------------|\n| `architecture-plan-path` | String | Yes | Path to the architecture plan file (e.g., `plans\u002Farchitecture-plan-STORY-0004-0006.md`) |\n| `story-id` | String | Yes | Story identifier for cross-referencing (e.g., `story-0004-0006`) |\n\n## Input Format\n\nThe skill reads mini-ADRs embedded in architecture plan documents. Each mini-ADR follows this structure:\n\n```markdown\n### ADR: [Title of the Decision]\n- **Context:** Description of the problem or situation requiring a decision.\n- **Decision:** The architectural decision that was made.\n- **Rationale:** Justification for why this decision was chosen over alternatives.\n```\n\nThe four fields of a mini-ADR are:\n\n| Field | Required | Description |\n|-------|----------|-------------|\n| **title** | Yes | Short descriptive title of the architectural decision |\n| **context** | Yes | Problem statement or situation that prompted the decision |\n| **decision** | Yes | The specific decision that was made |\n| **rationale** | Yes | Justification explaining why this decision was chosen |\n\n## Output Format\n\nEach mini-ADR is expanded into a full ADR file with YAML frontmatter and structured sections:\n\n```markdown\n---\nstatus: Accepted\ndate: YYYY-MM-DD\nstory-ref: story-XXXX-YYYY\ndeciders: AI-assisted (via x-generate-adr)\n---\n\n# ADR-NNNN: Title of the Decision\n\n## Status\n\nAccepted — YYYY-MM-DD\n\n## Context\n\nExpanded description of the problem or situation requiring a decision.\nProvides background information and the forces at play.\n\n## Decision\n\nThe architectural decision that was made, described in full detail.\n\n## Consequences\n\n### Positive\n- Benefit 1 derived from this decision\n- Benefit 2 derived from this decision\n\n### Negative\n- Trade-off or downside 1\n- Trade-off or downside 2\n\n### Neutral\n- Observation that is neither positive nor negative\n```\n\nThe output ADR frontmatter fields are:\n\n| Field | Value | Description |\n|-------|-------|-------------|\n| `status` | `Accepted` | Initial status for auto-generated ADRs |\n| `date` | Current date (`YYYY-MM-DD`) | Date of ADR generation |\n| `story-ref` | Story ID from argument | Cross-reference to originating story |\n| `deciders` | `AI-assisted (via x-generate-adr)` | Attribution |\n\nThe output ADR sections are:\n\n| Section | Source |\n|---------|--------|\n| **Status** | Set to `Accepted` with generation date |\n| **Context** | Expanded from mini-ADR `context` field |\n| **Decision** | Expanded from mini-ADR `decision` field |\n| **Consequences** | Inferred from mini-ADR `rationale` field, split into Positive\u002FNegative\u002FNeutral |\n\n## Workflow\n\n### Step 1 — Parse Architecture Plan\n\n1. Read the architecture plan file at `{architecture-plan-path}`\n2. Search for `### ADR:` markers to identify mini-ADRs\n3. For each marker, extract the four fields: title, context, decision, rationale\n4. Build a list of mini-ADR objects to process\n\n```bash\n# Example: search for mini-ADR markers\ngrep -n \"### ADR:\" {architecture-plan-path}\n```\n\n### Step 2 — Scan Existing ADRs for Sequential Numbering\n\n1. List all existing ADR files in `docs\u002Fadr\u002F`\n2. Extract the numeric prefix from each filename (e.g., `0003` from `ADR-0003-use-postgresql.md`)\n3. Find the maximum number\n4. The next ADR number starts at `max + 1`\n5. If `docs\u002Fadr\u002F` is empty or does not exist, start from `ADR-0001`\n\n```bash\n# Example: find max ADR number\nls docs\u002Fadr\u002FADR-*.md 2>\u002Fdev\u002Fnull | sort -t'-' -k2 -n | tail -1\n```\n\n### Step 3 — Check for Duplicates\n\nFor each mini-ADR, before creating a new ADR file:\n\n1. Normalize the mini-ADR title (lowercase, strip punctuation, trim whitespace)\n2. Compare against existing ADR titles in `docs\u002Fadr\u002F`\n3. If a match is found (title similarity), emit a warning and skip:\n   ```\n   WARNING: Duplicate ADR detected for \"[title]\", skipping — existing ADR found at docs\u002Fadr\u002FADR-NNNN-*.md\n   ```\n4. Do NOT overwrite existing ADRs\n\n### Step 4 — Expand Mini-ADR to Full ADR\n\nFor each non-duplicate mini-ADR:\n\n1. Assign the next sequential number (padded to 4 digits: `ADR-0001` format)\n2. Generate the full ADR content:\n   - YAML frontmatter with `status`, `date`, `story-ref`, `deciders`\n   - `## Status` section: `Accepted — {date}`\n   - `## Context` section: expanded from mini-ADR context\n   - `## Decision` section: expanded from mini-ADR decision\n   - `## Consequences` section: inferred from rationale, split into Positive\u002FNegative\u002FNeutral\n3. Convert the title to kebab-case for the filename\n\n### Step 5 — Write ADR Files\n\n1. Ensure `docs\u002Fadr\u002F` directory exists (create if needed)\n2. Write each ADR to `docs\u002Fadr\u002FADR-NNNN-title-in-kebab-case.md`\n3. Verify the file was written successfully\n\n### Step 6 — Update the Index\n\n1. Open `docs\u002Fadr\u002FREADME.md` (create if it does not exist)\n2. If the file does not exist, create it with a table header:\n   ```markdown\n   # Architecture Decision Records\n\n   | ADR | Title | Status | Date |\n   |-----|-------|--------|------|\n   ```\n3. Append a new row for each generated ADR:\n   ```markdown\n   | [ADR-NNNN](ADR-NNNN-title-in-kebab-case.md) | Title of the Decision | Accepted | YYYY-MM-DD |\n   ```\n\n### Step 7 — Add Cross-References\n\n1. In each generated ADR frontmatter, ensure `story-ref: {story-id}` is present\n2. Update the architecture plan file to add links to the generated ADRs:\n   - After each `### ADR:` marker that was processed, add a reference:\n     ```markdown\n     > Generated: [ADR-NNNN](..\u002F..\u002F..\u002Fdocs\u002Fadr\u002FADR-NNNN-title-in-kebab-case.md)\n     ```\n3. If a service architecture document exists (Section 7), update it with new ADR links\n\n## Sequential Numbering\n\nThe sequential numbering algorithm ensures globally unique ADR identifiers:\n\n1. **Scan**: Use `Glob` to find all files matching `docs\u002Fadr\u002FADR-*.md`\n2. **Extract**: Parse the 4-digit number from each filename (e.g., `ADR-0003-*.md` yields `3`)\n3. **Maximum**: Find the maximum number among all existing ADRs\n4. **Increment**: The next ADR number is `max + 1`\n5. **Pad**: Format as 4-digit zero-padded string (`ADR-NNNN` format, e.g., `ADR-0004`)\n6. **Empty directory**: If no ADR files exist, start numbering from `ADR-0001`\n\n```\ndocs\u002Fadr\u002F\n  ADR-0001-use-postgresql.md\n  ADR-0002-adopt-hexagonal-arch.md\n  ADR-0003-event-driven-comms.md\n  -> Next: ADR-0004\n```\n\n## Duplicate Detection\n\nBefore creating each ADR, check for existing ADRs with similar titles:\n\n1. **Normalize** both the mini-ADR title and existing ADR titles:\n   - Convert to lowercase\n   - Remove punctuation and special characters\n   - Trim leading\u002Ftrailing whitespace\n   - Collapse multiple spaces into one\n2. **Compare** the normalized mini-ADR title against all normalized existing titles\n3. **If duplicate found**:\n   - Emit warning: `Duplicate ADR detected, skipping: \"[original title]\"`\n   - Skip this mini-ADR (do not create a file)\n   - Continue processing remaining mini-ADRs\n4. **If no duplicate**: proceed with ADR creation\n\nThis prevents accidental overwriting of manually curated ADRs and avoids redundant documentation.\n\n## Cross-Reference Rules\n\nCross-references create bidirectional traceability between stories, architecture plans, and ADRs:\n\n### ADR to Story (in ADR frontmatter)\n\nEach generated ADR includes a `story-ref` field in its YAML frontmatter:\n\n```yaml\nstory-ref: story-0004-0006\n```\n\n### ADR to Architecture Plan (in ADR Context section)\n\nThe Context section of each ADR references the originating story and architecture plan:\n\n```markdown\nThis decision was identified during the architecture planning phase for story-0004-0006.\n```\n\n### Architecture Plan to ADR (in plan document)\n\nAfter processing, the architecture plan is updated with links to generated ADRs:\n\n```markdown\n### ADR: Use PostgreSQL for Persistence\n- **Context:** ...\n- **Decision:** ...\n- **Rationale:** ...\n> Generated: [ADR-0004](..\u002F..\u002F..\u002Fdocs\u002Fadr\u002FADR-0004-use-postgresql-for-persistence.md)\n```\n\n### Service Architecture Document (Section 7)\n\nIf a service architecture document exists with a Section 7 (ADR references), update it with links to newly generated ADRs.\n\n## Index Update\n\nThe ADR index at `docs\u002Fadr\u002FREADME.md` serves as the master list of all ADRs:\n\n1. **Read** `docs\u002Fadr\u002FREADME.md` (or create if missing)\n2. **Locate** the markdown table (identified by `| ADR |` header row)\n3. **Append** one row per generated ADR:\n   ```\n   | [ADR-NNNN](ADR-NNNN-title-in-kebab-case.md) | Title | Accepted | YYYY-MM-DD |\n   ```\n4. **Preserve** existing table rows (never remove or reorder)\n5. **Sort** is not required — append in generation order (sequential numbering guarantees chronological order)\n\n## Examples\n\n### Example — Mini-ADR Input (from architecture plan)\n\n```markdown\n### ADR: Use PostgreSQL for Persistence\n- **Context:** The system requires a relational database for transactional data with ACID guarantees. The team has experience with PostgreSQL and it supports JSON columns for semi-structured data.\n- **Decision:** Use PostgreSQL 15+ as the primary relational database for all transactional persistence.\n- **Rationale:** PostgreSQL provides strong ACID compliance, excellent JSON support via jsonb columns, mature tooling, and the team has operational experience. Alternatives like MySQL lack native JSON indexing; NoSQL options like MongoDB sacrifice transactional consistency.\n```\n\n### Example — Full ADR Output (generated)\n\nFile: `docs\u002Fadr\u002FADR-0004-use-postgresql-for-persistence.md`\n\n```markdown\n---\nstatus: Accepted\ndate: 2024-01-15\nstory-ref: story-0004-0006\ndeciders: AI-assisted (via x-generate-adr)\n---\n\n# ADR-0004: Use PostgreSQL for Persistence\n\n## Status\n\nAccepted — 2024-01-15\n\n## Context\n\nThe system requires a relational database for transactional data with ACID guarantees. The team has experience with PostgreSQL and it supports JSON columns for semi-structured data.\n\nThis decision was identified during the architecture planning phase for story-0004-0006.\n\n## Decision\n\nUse PostgreSQL 15+ as the primary relational database for all transactional persistence.\n\n## Consequences\n\n### Positive\n- Strong ACID compliance ensures data integrity for transactional workloads\n- Native jsonb column support enables flexible schema for semi-structured data\n- Mature ecosystem with excellent tooling (pgAdmin, pg_dump, extensions)\n- Team has existing operational experience, reducing ramp-up time\n\n### Negative\n- Vertical scaling limits may require sharding for very high write throughput\n- Operational overhead for managing replication and backups\n- Less suitable for graph-like query patterns compared to specialized databases\n\n### Neutral\n- Requires standard database migration tooling (Flyway, Liquibase, or similar)\n- Connection pooling (e.g., PgBouncer) recommended for high-concurrency scenarios\n```\n\n### Example — Index Entry (appended to docs\u002Fadr\u002FREADME.md)\n\n```markdown\n| [ADR-0004](ADR-0004-use-postgresql-for-persistence.md) | Use PostgreSQL for Persistence | Accepted | 2024-01-15 |\n```\n\n### Example — Architecture Plan Cross-Reference (updated in plan)\n\n```markdown\n### ADR: Use PostgreSQL for Persistence\n- **Context:** The system requires a relational database...\n- **Decision:** Use PostgreSQL 15+...\n- **Rationale:** PostgreSQL provides strong ACID compliance...\n> Generated: [ADR-0004](..\u002F..\u002F..\u002Fdocs\u002Fadr\u002FADR-0004-use-postgresql-for-persistence.md)\n```\n\n## Error Handling\n\n| Scenario | Action |\n|----------|--------|\n| Architecture plan file not found | Report error with path and exit |\n| No `### ADR:` markers found | Report \"No mini-ADRs found in plan\" and exit cleanly |\n| Duplicate ADR title detected | Emit warning, skip the duplicate, continue processing remaining |\n| `docs\u002Fadr\u002F` directory does not exist | Create it automatically |\n| `docs\u002Fadr\u002FREADME.md` does not exist | Create it with table header |\n| Write failure | Report error with file path and reason |\n\n## Integration Notes\n\n| Skill | Relationship | Context |\n|-------|-------------|---------|\n| `x-plan-architecture` | called-by | Prerequisite: generates the architecture plan with inline mini-ADRs |\n| `x-update-architecture` | calls | Updates service architecture document Section 7 with new ADR references |\n| `x-implement-story` | called-by | Invoked during documentation phase to formalize architectural decisions |\n","## Global Output Policy\n\n- **Language**: English ONLY.\n- **Tone**: Technical, Direct, and Concise.\n- **Efficiency**: Remove all conversational fillers and greetings to save tokens.\n\n# Skill: ADR Automation\n\n## Purpose\n\nAutomates the generation of Architecture Decision Records (ADRs) from mini-ADRs embedded in architecture plans. Extracts inline decisions, expands them to full ADR format using a standard template, assigns sequential numbering, updates the ADR index, and inserts cross-references between stories, architecture plans, and ADRs.\n\n## Triggers\n\n- `\u002Fx-generate-adr [architecture-plan-path] [story-id]` — extract mini-ADRs from the specified architecture plan and generate full ADR files\n- After the architecture plan phase, when mini-ADRs exist inline in the plan document\n- When `x-plan-architecture` has produced an architecture plan containing `### ADR:` markers\n- When architectural decisions need formal documentation as standalone ADR files\n- When the `docs\u002Fadr\u002F` directory needs to be populated or updated with new decisions\n- Do NOT use if ADRs have already been manually created for the same decisions\n\n## Parameters\n\n| Parameter | Type | Required | Description |\n|-----------|------|----------|-------------|\n| `architecture-plan-path` | String | Yes | Path to the architecture plan file (e.g., `plans\u002Farchitecture-plan-STORY-0004-0006.md`) |\n| `story-id` | String | Yes | Story identifier for cross-referencing (e.g., `story-0004-0006`) |\n\n## Input Format\n\nThe skill reads mini-ADRs embedded in architecture plan documents. Each mini-ADR follows this structure:\n\n```markdown\n### ADR: [Title of the Decision]\n- **Context:** Description of the problem or situation requiring a decision.\n- **Decision:** The architectural decision that was made.\n- **Rationale:** Justification for why this decision was chosen over alternatives.\n```\n\nThe four fields of a mini-ADR are:\n\n| Field | Required | Description |\n|-------|----------|-------------|\n| **title** | Yes | Short descriptive title of the architectural decision |\n| **context** | Yes | Problem statement or situation that prompted the decision |\n| **decision** | Yes | The specific decision that was made |\n| **rationale** | Yes | Justification explaining why this decision was chosen |\n\n## Output Format\n\nEach mini-ADR is expanded into a full ADR file with YAML frontmatter and structured sections:\n\n```markdown\n---\nstatus: Accepted\ndate: YYYY-MM-DD\nstory-ref: story-XXXX-YYYY\ndeciders: AI-assisted (via x-generate-adr)\n---\n\n# ADR-NNNN: Title of the Decision\n\n## Status\n\nAccepted — YYYY-MM-DD\n\n## Context\n\nExpanded description of the problem or situation requiring a decision.\nProvides background information and the forces at play.\n\n## Decision\n\nThe architectural decision that was made, described in full detail.\n\n## Consequences\n\n### Positive\n- Benefit 1 derived from this decision\n- Benefit 2 derived from this decision\n\n### Negative\n- Trade-off or downside 1\n- Trade-off or downside 2\n\n### Neutral\n- Observation that is neither positive nor negative\n```\n\nThe output ADR frontmatter fields are:\n\n| Field | Value | Description |\n|-------|-------|-------------|\n| `status` | `Accepted` | Initial status for auto-generated ADRs |\n| `date` | Current date (`YYYY-MM-DD`) | Date of ADR generation |\n| `story-ref` | Story ID from argument | Cross-reference to originating story |\n| `deciders` | `AI-assisted (via x-generate-adr)` | Attribution |\n\nThe output ADR sections are:\n\n| Section | Source |\n|---------|--------|\n| **Status** | Set to `Accepted` with generation date |\n| **Context** | Expanded from mini-ADR `context` field |\n| **Decision** | Expanded from mini-ADR `decision` field |\n| **Consequences** | Inferred from mini-ADR `rationale` field, split into Positive\u002FNegative\u002FNeutral |\n\n## Workflow\n\n### Step 1 — Parse Architecture Plan\n\n1. Read the architecture plan file at `{architecture-plan-path}`\n2. Search for `### ADR:` markers to identify mini-ADRs\n3. For each marker, extract the four fields: title, context, decision, rationale\n4. Build a list of mini-ADR objects to process\n\n```bash\n# Example: search for mini-ADR markers\ngrep -n \"### ADR:\" {architecture-plan-path}\n```\n\n### Step 2 — Scan Existing ADRs for Sequential Numbering\n\n1. List all existing ADR files in `docs\u002Fadr\u002F`\n2. Extract the numeric prefix from each filename (e.g., `0003` from `ADR-0003-use-postgresql.md`)\n3. Find the maximum number\n4. The next ADR number starts at `max + 1`\n5. If `docs\u002Fadr\u002F` is empty or does not exist, start from `ADR-0001`\n\n```bash\n# Example: find max ADR number\nls docs\u002Fadr\u002FADR-*.md 2>\u002Fdev\u002Fnull | sort -t'-' -k2 -n | tail -1\n```\n\n### Step 3 — Check for Duplicates\n\nFor each mini-ADR, before creating a new ADR file:\n\n1. Normalize the mini-ADR title (lowercase, strip punctuation, trim whitespace)\n2. Compare against existing ADR titles in `docs\u002Fadr\u002F`\n3. If a match is found (title similarity), emit a warning and skip:\n   ```\n   WARNING: Duplicate ADR detected for \"[title]\", skipping — existing ADR found at docs\u002Fadr\u002FADR-NNNN-*.md\n   ```\n4. Do NOT overwrite existing ADRs\n\n### Step 4 — Expand Mini-ADR to Full ADR\n\nFor each non-duplicate mini-ADR:\n\n1. Assign the next sequential number (padded to 4 digits: `ADR-0001` format)\n2. Generate the full ADR content:\n   - YAML frontmatter with `status`, `date`, `story-ref`, `deciders`\n   - `## Status` section: `Accepted — {date}`\n   - `## Context` section: expanded from mini-ADR context\n   - `## Decision` section: expanded from mini-ADR decision\n   - `## Consequences` section: inferred from rationale, split into Positive\u002FNegative\u002FNeutral\n3. Convert the title to kebab-case for the filename\n\n### Step 5 — Write ADR Files\n\n1. Ensure `docs\u002Fadr\u002F` directory exists (create if needed)\n2. Write each ADR to `docs\u002Fadr\u002FADR-NNNN-title-in-kebab-case.md`\n3. Verify the file was written successfully\n\n### Step 6 — Update the Index\n\n1. Open `docs\u002Fadr\u002FREADME.md` (create if it does not exist)\n2. If the file does not exist, create it with a table header:\n   ```markdown\n   # Architecture Decision Records\n\n   | ADR | Title | Status | Date |\n   |-----|-------|--------|------|\n   ```\n3. Append a new row for each generated ADR:\n   ```markdown\n   | [ADR-NNNN](ADR-NNNN-title-in-kebab-case.md) | Title of the Decision | Accepted | YYYY-MM-DD |\n   ```\n\n### Step 7 — Add Cross-References\n\n1. In each generated ADR frontmatter, ensure `story-ref: {story-id}` is present\n2. Update the architecture plan file to add links to the generated ADRs:\n   - After each `### ADR:` marker that was processed, add a reference:\n     ```markdown\n     > Generated: [ADR-NNNN](..\u002F..\u002F..\u002Fdocs\u002Fadr\u002FADR-NNNN-title-in-kebab-case.md)\n     ```\n3. If a service architecture document exists (Section 7), update it with new ADR links\n\n## Sequential Numbering\n\nThe sequential numbering algorithm ensures globally unique ADR identifiers:\n\n1. **Scan**: Use `Glob` to find all files matching `docs\u002Fadr\u002FADR-*.md`\n2. **Extract**: Parse the 4-digit number from each filename (e.g., `ADR-0003-*.md` yields `3`)\n3. **Maximum**: Find the maximum number among all existing ADRs\n4. **Increment**: The next ADR number is `max + 1`\n5. **Pad**: Format as 4-digit zero-padded string (`ADR-NNNN` format, e.g., `ADR-0004`)\n6. **Empty directory**: If no ADR files exist, start numbering from `ADR-0001`\n\n```\ndocs\u002Fadr\u002F\n  ADR-0001-use-postgresql.md\n  ADR-0002-adopt-hexagonal-arch.md\n  ADR-0003-event-driven-comms.md\n  -> Next: ADR-0004\n```\n\n## Duplicate Detection\n\nBefore creating each ADR, check for existing ADRs with similar titles:\n\n1. **Normalize** both the mini-ADR title and existing ADR titles:\n   - Convert to lowercase\n   - Remove punctuation and special characters\n   - Trim leading\u002Ftrailing whitespace\n   - Collapse multiple spaces into one\n2. **Compare** the normalized mini-ADR title against all normalized existing titles\n3. **If duplicate found**:\n   - Emit warning: `Duplicate ADR detected, skipping: \"[original title]\"`\n   - Skip this mini-ADR (do not create a file)\n   - Continue processing remaining mini-ADRs\n4. **If no duplicate**: proceed with ADR creation\n\nThis prevents accidental overwriting of manually curated ADRs and avoids redundant documentation.\n\n## Cross-Reference Rules\n\nCross-references create bidirectional traceability between stories, architecture plans, and ADRs:\n\n### ADR to Story (in ADR frontmatter)\n\nEach generated ADR includes a `story-ref` field in its YAML frontmatter:\n\n```yaml\nstory-ref: story-0004-0006\n```\n\n### ADR to Architecture Plan (in ADR Context section)\n\nThe Context section of each ADR references the originating story and architecture plan:\n\n```markdown\nThis decision was identified during the architecture planning phase for story-0004-0006.\n```\n\n### Architecture Plan to ADR (in plan document)\n\nAfter processing, the architecture plan is updated with links to generated ADRs:\n\n```markdown\n### ADR: Use PostgreSQL for Persistence\n- **Context:** ...\n- **Decision:** ...\n- **Rationale:** ...\n> Generated: [ADR-0004](..\u002F..\u002F..\u002Fdocs\u002Fadr\u002FADR-0004-use-postgresql-for-persistence.md)\n```\n\n### Service Architecture Document (Section 7)\n\nIf a service architecture document exists with a Section 7 (ADR references), update it with links to newly generated ADRs.\n\n## Index Update\n\nThe ADR index at `docs\u002Fadr\u002FREADME.md` serves as the master list of all ADRs:\n\n1. **Read** `docs\u002Fadr\u002FREADME.md` (or create if missing)\n2. **Locate** the markdown table (identified by `| ADR |` header row)\n3. **Append** one row per generated ADR:\n   ```\n   | [ADR-NNNN](ADR-NNNN-title-in-kebab-case.md) | Title | Accepted | YYYY-MM-DD |\n   ```\n4. **Preserve** existing table rows (never remove or reorder)\n5. **Sort** is not required — append in generation order (sequential numbering guarantees chronological order)\n\n## Examples\n\n### Example — Mini-ADR Input (from architecture plan)\n\n```markdown\n### ADR: Use PostgreSQL for Persistence\n- **Context:** The system requires a relational database for transactional data with ACID guarantees. The team has experience with PostgreSQL and it supports JSON columns for semi-structured data.\n- **Decision:** Use PostgreSQL 15+ as the primary relational database for all transactional persistence.\n- **Rationale:** PostgreSQL provides strong ACID compliance, excellent JSON support via jsonb columns, mature tooling, and the team has operational experience. Alternatives like MySQL lack native JSON indexing; NoSQL options like MongoDB sacrifice transactional consistency.\n```\n\n### Example — Full ADR Output (generated)\n\nFile: `docs\u002Fadr\u002FADR-0004-use-postgresql-for-persistence.md`\n\n```markdown\n---\nstatus: Accepted\ndate: 2024-01-15\nstory-ref: story-0004-0006\ndeciders: AI-assisted (via x-generate-adr)\n---\n\n# ADR-0004: Use PostgreSQL for Persistence\n\n## Status\n\nAccepted — 2024-01-15\n\n## Context\n\nThe system requires a relational database for transactional data with ACID guarantees. The team has experience with PostgreSQL and it supports JSON columns for semi-structured data.\n\nThis decision was identified during the architecture planning phase for story-0004-0006.\n\n## Decision\n\nUse PostgreSQL 15+ as the primary relational database for all transactional persistence.\n\n## Consequences\n\n### Positive\n- Strong ACID compliance ensures data integrity for transactional workloads\n- Native jsonb column support enables flexible schema for semi-structured data\n- Mature ecosystem with excellent tooling (pgAdmin, pg_dump, extensions)\n- Team has existing operational experience, reducing ramp-up time\n\n### Negative\n- Vertical scaling limits may require sharding for very high write throughput\n- Operational overhead for managing replication and backups\n- Less suitable for graph-like query patterns compared to specialized databases\n\n### Neutral\n- Requires standard database migration tooling (Flyway, Liquibase, or similar)\n- Connection pooling (e.g., PgBouncer) recommended for high-concurrency scenarios\n```\n\n### Example — Index Entry (appended to docs\u002Fadr\u002FREADME.md)\n\n```markdown\n| [ADR-0004](ADR-0004-use-postgresql-for-persistence.md) | Use PostgreSQL for Persistence | Accepted | 2024-01-15 |\n```\n\n### Example — Architecture Plan Cross-Reference (updated in plan)\n\n```markdown\n### ADR: Use PostgreSQL for Persistence\n- **Context:** The system requires a relational database...\n- **Decision:** Use PostgreSQL 15+...\n- **Rationale:** PostgreSQL provides strong ACID compliance...\n> Generated: [ADR-0004](..\u002F..\u002F..\u002Fdocs\u002Fadr\u002FADR-0004-use-postgresql-for-persistence.md)\n```\n\n## Error Handling\n\n| Scenario | Action |\n|----------|--------|\n| Architecture plan file not found | Report error with path and exit |\n| No `### ADR:` markers found | Report \"No mini-ADRs found in plan\" and exit cleanly |\n| Duplicate ADR title detected | Emit warning, skip the duplicate, continue processing remaining |\n| `docs\u002Fadr\u002F` directory does not exist | Create it automatically |\n| `docs\u002Fadr\u002FREADME.md` does not exist | Create it with table header |\n| Write failure | Report error with file path and reason |\n\n## Integration Notes\n\n| Skill | Relationship | Context |\n|-------|-------------|---------|\n| `x-plan-architecture` | called-by | Prerequisite: generates the architecture plan with inline mini-ADRs |\n| `x-update-architecture` | calls | Updates service architecture document Section 7 with new ADR references |\n| `x-implement-story` | called-by | Invoked during documentation phase to formalize architectural decisions |\n",{"name":5,"description":7,"allowed-tools":24,"argument-hint":25,"context-budget":26,"user-invocable":27,"requires-capabilities":28},"Read, Write, Edit, Bash, Grep, Glob","[architecture-plan-path] [story-id]","medium",true,[],"main","952a630c6f38d193a349d86fa18db1de8843e837","src\u002Ftest\u002Fresources\u002Fgolden\u002Fjava-spring-fintech-pci\u002F.claude\u002Fskills\u002Fx-generate-adr",1,"https:\u002F\u002Fgithub.com\u002Freview-bench\u002Federcnj_ia-dev-environment","https:\u002F\u002Fgithub.com\u002Freview-bench","https:\u002F\u002Freview-bench.ai","An open benchmark for AI code review.","2026-10-27 06:56:37",{"source":8,"skillName":5,"commands":39,"prompt":49,"zipAvailable":27},[40,43,46],{"tool":41,"command":42},"npx","npx skills add review-bench\u002Federcnj_ia-dev-environment --skill x-generate-adr",{"tool":44,"command":45},"bunx","bunx skills add review-bench\u002Federcnj_ia-dev-environment --skill x-generate-adr",{"tool":47,"command":48},"pnpm","pnpm dlx skills add review-bench\u002Federcnj_ia-dev-environment --skill x-generate-adr","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Freview-bench\u002Federcnj_ia-dev-environment\u002Fblob\u002Fmain\u002Fsrc\u002Ftest\u002Fresources\u002Fgolden\u002Fjava-spring-fintech-pci\u002F.claude\u002Fskills\u002Fx-generate-adr\u002FSKILL.md",[51],{"path":52,"resourceType":53,"resourceTypeDesc":54,"sizeBytes":55,"sourceHtmlUrl":56},"README.md","REFERENCE","参考文档",1736,"https:\u002F\u002Fgithub.com\u002Freview-bench\u002Federcnj_ia-dev-environment\u002Fblob\u002Fmain\u002Fsrc\u002Ftest\u002Fresources\u002Fgolden\u002Fjava-spring-fintech-pci\u002F.claude\u002Fskills\u002Fx-generate-adr\u002FREADME.md",[58,65,72,79,86,93],{"skillNo":59,"name":60,"nameZh":6,"description":61,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":62,"categories":63,"keywords":64,"publishedAt":19},"01M757M8J48TQ1Y3X25GSJBXAS","x-parallel-eval","Detects and classifies file-collision risks between work units (tasks, stories, or epic phases) before parallel execution. Reads ## File Footprint blocks produced by x-task-plan \u002F x-story-plan, applies the parallelism-heuristics knowledge pack (hard \u002F regen \u002F soft categories + hotspot overrides), and emits a collision matrix + serialization recommendation in Markdown (default) or JSON.","https:\u002F\u002Fgithub.com\u002Freview-bench\u002Federcnj_ia-dev-environment\u002Fblob\u002Fmain\u002Fsrc\u002Ftest\u002Fresources\u002Fgolden\u002Fx-parallel-eval\u002FSKILL.md",[],[],{"skillNo":66,"name":67,"nameZh":6,"description":68,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":69,"categories":70,"keywords":71,"publishedAt":19},"01M757M57XMR9546S69466HDWT","parallelism-heuristics","Canonical catalog of file-collision heuristics for parallel task, story, and epic execution. Defines the File Footprint block format, the three Conflict Categories (hard \u002F regen \u002F soft), a hotspot list of high-contention paths, and the degrade-with-warning policy. Consumed by x-task-plan, x-story-plan, x-epic-map, x-parallel-eval, and x-dev-*-implement.","https:\u002F\u002Fgithub.com\u002Freview-bench\u002Federcnj_ia-dev-environment\u002Fblob\u002Fmain\u002Fsrc\u002Ftest\u002Fresources\u002Fgolden\u002Fparallelism-heuristics\u002FSKILL.md",[],[],{"skillNo":73,"name":74,"nameZh":6,"description":75,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":76,"categories":77,"keywords":78,"publishedAt":19},"01M757M11SZ8P1VCQABT08QVYA","x-watch-pr-ci","Polls a PR's CI checks and Copilot review status, blocking until checks complete or timeout. Returns one of 8 stable exit codes (SUCCESS=0, CI_PENDING_PROCEED=10, CI_FAILED=20, TIMEOUT=30, PR_ALREADY_MERGED=40, NO_CI_CONFIGURED=50, PR_CLOSED=60, PR_NOT_FOUND=70). Writes a versioned state-file for session resume.","https:\u002F\u002Fgithub.com\u002Freview-bench\u002Federcnj_ia-dev-environment\u002Fblob\u002Fmain\u002Fsrc\u002Ftest\u002Fresources\u002Fgolden\u002Fjava-spring\u002Fplatform-claude-code\u002F.claude\u002Fskills\u002Fx-watch-pr-ci\u002FSKILL.md",[],[],{"skillNo":80,"name":81,"nameZh":6,"description":82,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":83,"categories":84,"keywords":85,"publishedAt":19},"01M757KW53K8KFPGADFB4PH949","x-validate-docs","Documentation freshness gate: validates 6 dimensions (readme, api-specs, grpc-proto, adr, skill-docs, system-architecture) against code changes in a PR. Stack-aware — only validates targets declared\u002Fauto-detected from ProjectConfig.documentation.targets. Returns exit non-zero on staleness; produces structured report.","https:\u002F\u002Fgithub.com\u002Freview-bench\u002Federcnj_ia-dev-environment\u002Fblob\u002Fmain\u002Fsrc\u002Ftest\u002Fresources\u002Fgolden\u002Fjava-spring\u002Fplatform-claude-code\u002F.claude\u002Fskills\u002Fx-validate-docs\u002FSKILL.md",[],[],{"skillNo":87,"name":88,"nameZh":6,"description":89,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":90,"categories":91,"keywords":92,"publishedAt":19},"01M757KQZHSA10MKC0CR571D60","x-update-system-architecture","Incrementally updates docs\u002Farchitecture\u002Fsystem.md after an epic completes. Appends new entries to the Decision Log (§11) using x-internal-write-report --append (dedup by ## ID: marker) and surgically inserts component\u002Fintegration changes into sections 1-10 via Edit. Idempotent: re-running with the same epic produces a byte-identical system.md.","https:\u002F\u002Fgithub.com\u002Freview-bench\u002Federcnj_ia-dev-environment\u002Fblob\u002Fmain\u002Fsrc\u002Ftest\u002Fresources\u002Fgolden\u002Fjava-spring\u002Fplatform-claude-code\u002F.claude\u002Fskills\u002Fx-update-system-architecture\u002FSKILL.md",[],[],{"skillNo":94,"name":95,"nameZh":6,"description":96,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":97,"categories":98,"keywords":99,"publishedAt":19},"01M757KKBT5Q1SVF8DMJBVF46M","x-update-architecture","Incrementally updates the service architecture document with changes from architecture plans. Adds new components, integrations, flows, and ADR references without rewriting existing content. Use after implementation to keep architecture documentation current.","https:\u002F\u002Fgithub.com\u002Freview-bench\u002Federcnj_ia-dev-environment\u002Fblob\u002Fmain\u002Fsrc\u002Ftest\u002Fresources\u002Fgolden\u002Fjava-spring\u002Fplatform-claude-code\u002F.claude\u002Fskills\u002Fx-update-architecture\u002FSKILL.md",[],[]]