[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CQVZY5JC08BEMTSSST1464":3,"skill-same:01M6CQVZY5JC08BEMTSSST1464":125},{"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":23,"publishedAt":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":45,"commitSha":46,"skillDirectory":47,"forksCount":48,"repositoryHtmlUrl":49,"repositoryHomepageUrl":6,"ownerHtmlUrl":50,"ownerBlogUrl":51,"ownerDescription":6,"updatedAt":52,"install":53,"resources":66},"01M6CQVZY5JC08BEMTSSST1464","specification",null,"Expand one capability area from .gener8v\u002Fprd.md into a functional specification with atomic, testable [PREFIX]-REQ-XXX requirements, behaviors, edge cases and open questions under .gener8v\u002Fspecifications\u002F. Use when a PRD capability area needs elaboration before constraints, technical design or tickets, or a change brief still marks an area as pending specification, such as 'spec out the search area' or 'write the requirements for billing'. Not for the whole product (planning) or work items (ticket-breakdown).","gener8v\u002Fgener8v.claude-skills","gener8v","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F262388633?v=4","01M6CQT9VAG2MX3NN1CBMGR2T8","GENER8V","01M6CQT9YZXXYFF41ZYFW774DQ",3,"MIT","https:\u002F\u002Fgithub.com\u002Fgener8v\u002Fgener8v.claude-skills\u002Fblob\u002Fmain\u002Fskills\u002Fspecification\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000031","产品经理","PROFESSION","适用职业",[5,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"design","spec","change","planning","product","search","edge","brief","prd","constraints","open","work","technical","write","use","2026-11-10 10:12:30",false,"---\nname: specification\ndescription: \"Expand one capability area from .gener8v\u002Fprd.md into a functional specification with atomic, testable [PREFIX]-REQ-XXX requirements, behaviors, edge cases and open questions under .gener8v\u002Fspecifications\u002F. Use when a PRD capability area needs elaboration before constraints, technical design or tickets, or a change brief still marks an area as pending specification, such as 'spec out the search area' or 'write the requirements for billing'. Not for the whole product (planning) or work items (ticket-breakdown).\"\nargument-hint: \"[capability area] [for change-slug]\"\n---\n\n# Specification Skill\n\n**Invoked with:** `$ARGUMENTS`\n\nIf that is empty, ask the user which capability area (from `## Functional Capabilities` in `.gener8v\u002Fprd.md`) to specify before doing anything else. Never guess the target.\n\nThe optional `for \u003Cchange-slug>` names the change this specification work belongs to (`.gener8v\u002Fchanges\u002F\u003Cchange-slug>\u002Fchange.md`). When it is absent, read `.gener8v\u002Fpipeline-state.yaml`: if exactly one change lists this area under `pending_specification`, or exactly one change is active (`active_changes`), use that one; when several changes could apply, ask the user which change before doing anything else. If no change exists at all, stop and recommend running the Planning skill — every specification amendment belongs to a change (only Brownfield writes the baseline without one).\n\n## Purpose\n\nTransform a single Capability Area from a Planning Skill PRD into a detailed functional specification. The specification enumerates all functional requirements, defines behaviors, describes edge cases, and surfaces decisions needed—all while remaining implementation-agnostic. The output is designed for downstream analysis (Constraints, Dependencies) and eventual decomposition into tickets.\n\n## When to Use\n\nUse this skill when:\n- A Capability Area from a PRD needs detailed elaboration before implementation planning\n- A change brief's `## Affected Capability Areas` row for an area still says `(pending specification)`\n- Stakeholders need to review and approve detailed requirements\n- The scope of a capability area is ambiguous and needs explicit definition\n- Preparing input for the Constraints, Dependencies, or Ticket Breakdown skills\n\n## Input\n\n**Source:** A single Capability Area from a Planning Skill PRD, specified for one change\n**Read from:** `.gener8v\u002Fprd.md` and `.gener8v\u002Fchanges\u002F\u003Cchange-slug>\u002Fchange.md`\n**Expects:** A PRD with `## Functional Capabilities` containing `### [Capability Area]` subsections, and a change brief whose `## Affected Capability Areas` table names this area (its Why, Outcome and Priority Cut bound what this run adds, modifies or withdraws). This skill operates on one capability area at a time.\n\n## Output\n\n**Produces:** A detailed functional specification for one capability area — a living artifact, amended in place by every change that touches the area\n**Write to:** `.gener8v\u002Fspecifications\u002F[capability-area-slug].md`\n**Updates:** `.gener8v\u002Fchanges\u002F\u003Cchange-slug>\u002Fchange.md` — the area's row in `## Affected Capability Areas` (Adds \u002F Modifies \u002F Withdraws with the real IDs) and a `## Change Log` line\n**Creates directory:** `.gener8v\u002Fspecifications\u002F` if it does not exist\n**Naming convention:** Lowercase, hyphen-separated slug of the capability area name (e.g., `search-and-retrieval.md`, `documentation-ingestion.md`)\n\nRun this skill once per capability area per change. A PRD with 5 capability areas produces 5 specification files; a later change that touches two of them amends those two.\n\n## Output Format\n\nWrite the specification in the shape of `assets\u002Fspecification.md`. Read it before writing and follow it exactly, headings and field lines included; its bracketed notes on prefixes and requirement tags are part of the format. `scripts\u002Fgener8v-state.py` reads the `**Status:**` line in Source Context as the approval state and counts requirements only from bullet lines that open with the bold ID (`- **SR-REQ-001** …`). Lint warns on an NFR bullet without `verified by`, matches the `change: \u003Cchange-slug>` tags against the change brief, and reads the `## @spec Coverage` rows as coverage.\n\n---\n\n## Principles\n\n### Atomic Requirements\nEach requirement (REQ-XXX) should describe exactly one behavior. If a requirement contains \"and,\" consider splitting it.\n\n### Testable Statements\nEvery requirement should be verifiable. Avoid subjective language like \"quickly,\" \"easily,\" or \"user-friendly.\"\n\n**Good:** \"The system should return results within the user's current session.\"\n**Avoid:** \"The system should return results quickly.\"\n\n### Behavior Over Interface\nDescribe what happens, not how it looks.\n\n**Good:** \"The user should be able to filter results by date range.\"\n**Avoid:** \"The user clicks the date picker dropdown and selects start and end dates.\"\n\n### Explicit Edge Cases\nCommon failure modes and boundary conditions should be called out explicitly. If unsure, add to Open Questions.\n\n### Namespaced for Traceability\nRequirements use [PREFIX]-REQ-XXX identifiers (e.g., SR-REQ-001 for Search & Retrieval) and non-functional requirements [PREFIX]-NFR-XXX. The prefix is derived from the capability area name — typically the first letter of each word or the first 2-4 letters. This ensures requirement IDs are unique across the entire project, preventing ambiguity when tickets, constraints, or audits reference requirements from different specifications.\n\n### Targets, Not Boundaries\nA non-functional requirement is a measurable target the system must *achieve* (a latency, an availability, a retention period, what gets logged) with a named way to verify it. A boundary the system must *operate within* (a mandated platform, a regulation, an integration that only exposes one API) is a constraint and belongs to the Constraints skill. If a target has no way to be verified, it is an Open Question until it does.\n\n### Living, Amended by Changes\nThe specification describes the area as it should be, across every change that has touched it. A change adds, amends or withdraws requirements and says so on each one with its tag; it never regenerates the file. The change brief records which IDs the change touched, so a reader can see the area's history from either side.\n\n## Process\n\n0. **Validate Input**: Confirm `.gener8v\u002Fprd.md` exists and contains a `## Functional Capabilities` section with `###` subsections. If the PRD is missing, stop and recommend running the Planning skill. If the target capability area is not found in the PRD, inform the user and list the available areas. Confirm `.gener8v\u002Fchanges\u002F\u003Cchange-slug>\u002Fchange.md` exists (resolving the change as described under **Invoked with**); if it does not, stop and recommend running the Planning skill to open the change.\n\n0b. **Load the Existing Artifact**: If the output file already exists, read it first. Every existing ID and heading is kept; new items are allocated above the current maximum ID; anything no longer applicable is marked `**Status:** Withdrawn` in place rather than deleted. IDs are append-only (`CONVENTIONS.md` §4) — code and downstream documents reference them, and renumbering silently re-binds those references.\n\n0c. **Read the Change Brief**: Take the change's Why, Outcome, Priority Cut and Out of Scope, and this area's row in `## Affected Capability Areas`. Only what the brief calls for is in scope for this run: a change that `modifies` an area amends or adds the requirements the brief describes and leaves the rest of the living specification untouched; a change that `adds area` writes the area from the PRD bullets. Priority words on requirements come from the Priority Cut.\n\n1. **Extract Context**: Identify the Capability Area and its relationship to parent PRD and sibling capabilities. Choose the requirement prefix (initials or first letters of the area name, 2–4 upper-case letters, not one of the reserved prefixes in `CONVENTIONS.md` §3, and not used by any existing specification) and record it in Source Context, together with `**Status:** Draft` and `**Approved by:** pending` on a new specification (an existing Approved specification that this change amends goes back to Draft — the amendment needs approval too).\n2. **Expand Requirements**: Decompose each bullet into atomic, testable requirements. Tag every requirement this change introduces with `*(\u003Cpriority> · change: \u003Cchange-slug>)*`; append `*(amended YYYY-MM-DD by \u003Cchange-slug>)*` to any existing requirement whose text this change alters.\n3. **Capture Non-Functional Requirements**: For each category that applies (performance, availability, capacity\u002Fretention, observability, accessibility, security posture), write a measurable target with its verification method as a `[XX]-NFR-NNN` item, tagged like the requirements. A target that cannot be verified goes to Open Questions instead.\n4. **Define Behaviors**: Document business rules and conditional behaviors.\n5. **Surface Edge Cases**: Identify boundary conditions, error states, unusual scenarios.\n6. **Identify States**: Map valid states and transitions for stateful entities.\n7. **Capture Data Needs**: List information to capture, store, or display.\n8. **Document Interactions**: Describe interaction patterns without prescribing UI.\n9. **Flag Unknowns**: Move ambiguity to Open Questions; document assumptions.\n10. **Review for Completeness**: Ensure standalone understandability.\n11. **Update the Change Brief**: After writing the specification, replace this area's `(pending specification)` cell in the brief's `## Affected Capability Areas` table with the real deltas — `Adds \u003CIDs>; Modifies \u003CIDs>; Withdraws \u003CIDs>` (use `—` for an empty group, ranges like `SR-REQ-011..012` for runs) — and append a `## Change Log` line: `YYYY-MM-DD — \u003CPFX> specification amended: adds …, modifies …, withdraws … (Specification)`.\n12. **Record Approval**: Present the specification to the user for Product Owner approval. **Ask, do not wait.** Present the artifact and request approval before the session moves on to another area, another skill, or another run — an artifact left `Draft` because nobody was asked is indistinguishable in the record from one the user declined to approve. When they approve in conversation, set `**Status:** Approved` and `**Approved by:** Product Owner — \u003Cname>, YYYY-MM-DD` in Source Context; until then the lines stay `Draft` \u002F `pending`, and Audit will warn if tickets are cut from a Draft specification.\n\n## Example\n\nA full worked example — the Search & Retrieval specification of the Support Documentation Search System for the `support-search` change, with tagged requirements, two NFRs, the Draft\u002FApproved lines, and the change-brief row and Change Log line the skill writes afterwards — is in `references\u002Fexample.md` (relative to this skill's directory). Read it before producing your first artifact of this kind.\n\n---\n\n## Troubleshooting\n\n- **Lint reports `requirement prefix XX- is used by both specifications\u002F\u003Ca>.md and specifications\u002F\u003Cb>.md`.** Two areas chose the same prefix. While nothing cites the newer area's IDs, change its prefix. Once tickets, delivery records or `@spec` annotations cite them, the IDs are append-only: withdraw them and re-issue under a new prefix, and record the Adds \u002F Withdraws in the change brief.\n- **Lint reports `changes\u002F\u003Cchange-slug>\u002Fchange.md lists XX-REQ-NNN for \u003Carea> but specifications\u002F\u003Carea-slug>.md does not contain it`.** The brief's Affected Capability Areas cell and the specification disagree — usually a typo, or a range in the cell that reaches past the IDs the specification defines. Correct whichever side is wrong; the cell names only IDs the specification holds.\n- **Lint warns `specifications\u002F\u003Carea-slug>.md has no requirement tagged with change '\u003Cchange-slug>' although the brief lists deltas for it`.** Process step 11 recorded the deltas in the brief, but step 2's tags are missing from the requirements. Add `*(\u003Cpriority> · change: \u003Cchange-slug>)*` or `*(amended YYYY-MM-DD by \u003Cchange-slug>)*` to each requirement the change touched; the tags are how a reader of the specification finds them.\n- **Orchestrate reports fewer requirements than the specification holds.** Only bullet lines that open with the bold ID are definitions — `- **SR-REQ-001** *(must · change: …)*: …`. An ID in a table, in a heading, or without the bold markers is invisible to the counts and to coverage lint; rewrite it in the template's bullet form.\n- **Lint warns that an NFR `names no verification method`.** The `- **XX-NFR-NNN**` bullet lacks `verified by`. Name the benchmark, load test, lint or query that verifies the target; if none exists, the target belongs in Open Questions (Process step 3).\n\n## Integration with Other Skills\n\n**Upstream:**\n- **Planning Skill**: Provides the Capability Area that this skill elaborates, and opens the change brief whose Affected Capability Areas row this skill fills in\n\n**Downstream:**\n- **Constraints Skill**: Analyzes for technical, compliance, or operational constraints (boundaries — the NFRs here are targets)\n- **Dependencies Skill**: Maps dependencies between capabilities and external systems\n- **Technical Design Skill**: Translates requirements into architecture decisions and component design; its Infrastructure Requirements and Technical Risks cite the NFR IDs they serve\n- **Ticket Breakdown Skill**: Decomposes the requirements and NFRs the change brief names for this area into implementable work items under `changes\u002F\u003Cchange-slug>\u002Ftickets\u002F\u003Carea-slug>\u002F` — one `TICKET-NNN.md` per ticket plus `backlog.md`\n- **Delivery Skill**: Annotates code with these requirement IDs, appends the `## @spec Coverage` rows, and runs the executable NFR checks in its Verification Run\n- **Orchestrate Skill**: Recommends `specification \u003Carea> for \u003Cchange>` while the brief's row for that area still says `(pending specification)`\n- **Code Review Skill**: Verifies requirement coverage and the `## @spec Coverage` table against the code\n- **Brownfield Skill**: Produces specifications in this format directly from existing code\n\n## Revisions\n\n- Re-running this skill for a later change loads the existing specification and amends it: existing IDs and headings are preserved, new requirements are added above the current maximum with the new change's tag, removed ones are marked Withdrawn — and the new change's brief records the Adds \u002F Modifies \u002F Withdraws\n- Downstream artifacts that reference this specification's requirements (constraints, technical designs, tickets, delivery records, and `@spec` annotations in code) become potentially stale when a requirement's *text* changes — say so in the requirement (`*(amended YYYY-MM-DD by \u003Cchange-slug>)*`) so Audit can find it\n- Requirements are never renumbered; a wrong number is withdrawn and re-issued\n- An amendment returns an Approved specification to `**Status:** Draft` until the Product Owner approves it again\n- If the PRD's capability area description changes, compare the new and existing specification to determine whether a full regeneration or targeted update is appropriate\n\n## Notes\n\n- Generate one specification per Capability Area; do not combine multiple areas\n- Requirements should be numbered sequentially within each specification, using the capability area prefix\n- Open Questions from source PRD relevant to this capability should be carried forward\n- This skill does not define acceptance criteria—that occurs during Ticket Breakdown\n- Keep specifications under ~2000 words; split complex capabilities if needed\n- The `@spec Coverage` section is not populated during greenfield specification creation — Delivery appends to it as code is delivered. The Brownfield skill populates it immediately since it works from existing code\n- `scripts\u002Fgener8v-state.py lint` fails on a requirement prefix shared by two specifications and warns on a specification that uses more than one prefix; it treats `[XX]-NFR-NNN` like requirements (uniqueness, dangling references) and warns — not errors — when an NFR is in no ticket\n- `NFR` and `REQ` are reserved segments (`CONVENTIONS.md` §3); never choose them as a prefix\n","# Specification Skill\n\n**Invoked with:** `$ARGUMENTS`\n\nIf that is empty, ask the user which capability area (from `## Functional Capabilities` in `.gener8v\u002Fprd.md`) to specify before doing anything else. Never guess the target.\n\nThe optional `for \u003Cchange-slug>` names the change this specification work belongs to (`.gener8v\u002Fchanges\u002F\u003Cchange-slug>\u002Fchange.md`). When it is absent, read `.gener8v\u002Fpipeline-state.yaml`: if exactly one change lists this area under `pending_specification`, or exactly one change is active (`active_changes`), use that one; when several changes could apply, ask the user which change before doing anything else. If no change exists at all, stop and recommend running the Planning skill — every specification amendment belongs to a change (only Brownfield writes the baseline without one).\n\n## Purpose\n\nTransform a single Capability Area from a Planning Skill PRD into a detailed functional specification. The specification enumerates all functional requirements, defines behaviors, describes edge cases, and surfaces decisions needed—all while remaining implementation-agnostic. The output is designed for downstream analysis (Constraints, Dependencies) and eventual decomposition into tickets.\n\n## When to Use\n\nUse this skill when:\n- A Capability Area from a PRD needs detailed elaboration before implementation planning\n- A change brief's `## Affected Capability Areas` row for an area still says `(pending specification)`\n- Stakeholders need to review and approve detailed requirements\n- The scope of a capability area is ambiguous and needs explicit definition\n- Preparing input for the Constraints, Dependencies, or Ticket Breakdown skills\n\n## Input\n\n**Source:** A single Capability Area from a Planning Skill PRD, specified for one change\n**Read from:** `.gener8v\u002Fprd.md` and `.gener8v\u002Fchanges\u002F\u003Cchange-slug>\u002Fchange.md`\n**Expects:** A PRD with `## Functional Capabilities` containing `### [Capability Area]` subsections, and a change brief whose `## Affected Capability Areas` table names this area (its Why, Outcome and Priority Cut bound what this run adds, modifies or withdraws). This skill operates on one capability area at a time.\n\n## Output\n\n**Produces:** A detailed functional specification for one capability area — a living artifact, amended in place by every change that touches the area\n**Write to:** `.gener8v\u002Fspecifications\u002F[capability-area-slug].md`\n**Updates:** `.gener8v\u002Fchanges\u002F\u003Cchange-slug>\u002Fchange.md` — the area's row in `## Affected Capability Areas` (Adds \u002F Modifies \u002F Withdraws with the real IDs) and a `## Change Log` line\n**Creates directory:** `.gener8v\u002Fspecifications\u002F` if it does not exist\n**Naming convention:** Lowercase, hyphen-separated slug of the capability area name (e.g., `search-and-retrieval.md`, `documentation-ingestion.md`)\n\nRun this skill once per capability area per change. A PRD with 5 capability areas produces 5 specification files; a later change that touches two of them amends those two.\n\n## Output Format\n\nWrite the specification in the shape of `assets\u002Fspecification.md`. Read it before writing and follow it exactly, headings and field lines included; its bracketed notes on prefixes and requirement tags are part of the format. `scripts\u002Fgener8v-state.py` reads the `**Status:**` line in Source Context as the approval state and counts requirements only from bullet lines that open with the bold ID (`- **SR-REQ-001** …`). Lint warns on an NFR bullet without `verified by`, matches the `change: \u003Cchange-slug>` tags against the change brief, and reads the `## @spec Coverage` rows as coverage.\n\n---\n\n## Principles\n\n### Atomic Requirements\nEach requirement (REQ-XXX) should describe exactly one behavior. If a requirement contains \"and,\" consider splitting it.\n\n### Testable Statements\nEvery requirement should be verifiable. Avoid subjective language like \"quickly,\" \"easily,\" or \"user-friendly.\"\n\n**Good:** \"The system should return results within the user's current session.\"\n**Avoid:** \"The system should return results quickly.\"\n\n### Behavior Over Interface\nDescribe what happens, not how it looks.\n\n**Good:** \"The user should be able to filter results by date range.\"\n**Avoid:** \"The user clicks the date picker dropdown and selects start and end dates.\"\n\n### Explicit Edge Cases\nCommon failure modes and boundary conditions should be called out explicitly. If unsure, add to Open Questions.\n\n### Namespaced for Traceability\nRequirements use [PREFIX]-REQ-XXX identifiers (e.g., SR-REQ-001 for Search & Retrieval) and non-functional requirements [PREFIX]-NFR-XXX. The prefix is derived from the capability area name — typically the first letter of each word or the first 2-4 letters. This ensures requirement IDs are unique across the entire project, preventing ambiguity when tickets, constraints, or audits reference requirements from different specifications.\n\n### Targets, Not Boundaries\nA non-functional requirement is a measurable target the system must *achieve* (a latency, an availability, a retention period, what gets logged) with a named way to verify it. A boundary the system must *operate within* (a mandated platform, a regulation, an integration that only exposes one API) is a constraint and belongs to the Constraints skill. If a target has no way to be verified, it is an Open Question until it does.\n\n### Living, Amended by Changes\nThe specification describes the area as it should be, across every change that has touched it. A change adds, amends or withdraws requirements and says so on each one with its tag; it never regenerates the file. The change brief records which IDs the change touched, so a reader can see the area's history from either side.\n\n## Process\n\n0. **Validate Input**: Confirm `.gener8v\u002Fprd.md` exists and contains a `## Functional Capabilities` section with `###` subsections. If the PRD is missing, stop and recommend running the Planning skill. If the target capability area is not found in the PRD, inform the user and list the available areas. Confirm `.gener8v\u002Fchanges\u002F\u003Cchange-slug>\u002Fchange.md` exists (resolving the change as described under **Invoked with**); if it does not, stop and recommend running the Planning skill to open the change.\n\n0b. **Load the Existing Artifact**: If the output file already exists, read it first. Every existing ID and heading is kept; new items are allocated above the current maximum ID; anything no longer applicable is marked `**Status:** Withdrawn` in place rather than deleted. IDs are append-only (`CONVENTIONS.md` §4) — code and downstream documents reference them, and renumbering silently re-binds those references.\n\n0c. **Read the Change Brief**: Take the change's Why, Outcome, Priority Cut and Out of Scope, and this area's row in `## Affected Capability Areas`. Only what the brief calls for is in scope for this run: a change that `modifies` an area amends or adds the requirements the brief describes and leaves the rest of the living specification untouched; a change that `adds area` writes the area from the PRD bullets. Priority words on requirements come from the Priority Cut.\n\n1. **Extract Context**: Identify the Capability Area and its relationship to parent PRD and sibling capabilities. Choose the requirement prefix (initials or first letters of the area name, 2–4 upper-case letters, not one of the reserved prefixes in `CONVENTIONS.md` §3, and not used by any existing specification) and record it in Source Context, together with `**Status:** Draft` and `**Approved by:** pending` on a new specification (an existing Approved specification that this change amends goes back to Draft — the amendment needs approval too).\n2. **Expand Requirements**: Decompose each bullet into atomic, testable requirements. Tag every requirement this change introduces with `*(\u003Cpriority> · change: \u003Cchange-slug>)*`; append `*(amended YYYY-MM-DD by \u003Cchange-slug>)*` to any existing requirement whose text this change alters.\n3. **Capture Non-Functional Requirements**: For each category that applies (performance, availability, capacity\u002Fretention, observability, accessibility, security posture), write a measurable target with its verification method as a `[XX]-NFR-NNN` item, tagged like the requirements. A target that cannot be verified goes to Open Questions instead.\n4. **Define Behaviors**: Document business rules and conditional behaviors.\n5. **Surface Edge Cases**: Identify boundary conditions, error states, unusual scenarios.\n6. **Identify States**: Map valid states and transitions for stateful entities.\n7. **Capture Data Needs**: List information to capture, store, or display.\n8. **Document Interactions**: Describe interaction patterns without prescribing UI.\n9. **Flag Unknowns**: Move ambiguity to Open Questions; document assumptions.\n10. **Review for Completeness**: Ensure standalone understandability.\n11. **Update the Change Brief**: After writing the specification, replace this area's `(pending specification)` cell in the brief's `## Affected Capability Areas` table with the real deltas — `Adds \u003CIDs>; Modifies \u003CIDs>; Withdraws \u003CIDs>` (use `—` for an empty group, ranges like `SR-REQ-011..012` for runs) — and append a `## Change Log` line: `YYYY-MM-DD — \u003CPFX> specification amended: adds …, modifies …, withdraws … (Specification)`.\n12. **Record Approval**: Present the specification to the user for Product Owner approval. **Ask, do not wait.** Present the artifact and request approval before the session moves on to another area, another skill, or another run — an artifact left `Draft` because nobody was asked is indistinguishable in the record from one the user declined to approve. When they approve in conversation, set `**Status:** Approved` and `**Approved by:** Product Owner — \u003Cname>, YYYY-MM-DD` in Source Context; until then the lines stay `Draft` \u002F `pending`, and Audit will warn if tickets are cut from a Draft specification.\n\n## Example\n\nA full worked example — the Search & Retrieval specification of the Support Documentation Search System for the `support-search` change, with tagged requirements, two NFRs, the Draft\u002FApproved lines, and the change-brief row and Change Log line the skill writes afterwards — is in `references\u002Fexample.md` (relative to this skill's directory). Read it before producing your first artifact of this kind.\n\n---\n\n## Troubleshooting\n\n- **Lint reports `requirement prefix XX- is used by both specifications\u002F\u003Ca>.md and specifications\u002F\u003Cb>.md`.** Two areas chose the same prefix. While nothing cites the newer area's IDs, change its prefix. Once tickets, delivery records or `@spec` annotations cite them, the IDs are append-only: withdraw them and re-issue under a new prefix, and record the Adds \u002F Withdraws in the change brief.\n- **Lint reports `changes\u002F\u003Cchange-slug>\u002Fchange.md lists XX-REQ-NNN for \u003Carea> but specifications\u002F\u003Carea-slug>.md does not contain it`.** The brief's Affected Capability Areas cell and the specification disagree — usually a typo, or a range in the cell that reaches past the IDs the specification defines. Correct whichever side is wrong; the cell names only IDs the specification holds.\n- **Lint warns `specifications\u002F\u003Carea-slug>.md has no requirement tagged with change '\u003Cchange-slug>' although the brief lists deltas for it`.** Process step 11 recorded the deltas in the brief, but step 2's tags are missing from the requirements. Add `*(\u003Cpriority> · change: \u003Cchange-slug>)*` or `*(amended YYYY-MM-DD by \u003Cchange-slug>)*` to each requirement the change touched; the tags are how a reader of the specification finds them.\n- **Orchestrate reports fewer requirements than the specification holds.** Only bullet lines that open with the bold ID are definitions — `- **SR-REQ-001** *(must · change: …)*: …`. An ID in a table, in a heading, or without the bold markers is invisible to the counts and to coverage lint; rewrite it in the template's bullet form.\n- **Lint warns that an NFR `names no verification method`.** The `- **XX-NFR-NNN**` bullet lacks `verified by`. Name the benchmark, load test, lint or query that verifies the target; if none exists, the target belongs in Open Questions (Process step 3).\n\n## Integration with Other Skills\n\n**Upstream:**\n- **Planning Skill**: Provides the Capability Area that this skill elaborates, and opens the change brief whose Affected Capability Areas row this skill fills in\n\n**Downstream:**\n- **Constraints Skill**: Analyzes for technical, compliance, or operational constraints (boundaries — the NFRs here are targets)\n- **Dependencies Skill**: Maps dependencies between capabilities and external systems\n- **Technical Design Skill**: Translates requirements into architecture decisions and component design; its Infrastructure Requirements and Technical Risks cite the NFR IDs they serve\n- **Ticket Breakdown Skill**: Decomposes the requirements and NFRs the change brief names for this area into implementable work items under `changes\u002F\u003Cchange-slug>\u002Ftickets\u002F\u003Carea-slug>\u002F` — one `TICKET-NNN.md` per ticket plus `backlog.md`\n- **Delivery Skill**: Annotates code with these requirement IDs, appends the `## @spec Coverage` rows, and runs the executable NFR checks in its Verification Run\n- **Orchestrate Skill**: Recommends `specification \u003Carea> for \u003Cchange>` while the brief's row for that area still says `(pending specification)`\n- **Code Review Skill**: Verifies requirement coverage and the `## @spec Coverage` table against the code\n- **Brownfield Skill**: Produces specifications in this format directly from existing code\n\n## Revisions\n\n- Re-running this skill for a later change loads the existing specification and amends it: existing IDs and headings are preserved, new requirements are added above the current maximum with the new change's tag, removed ones are marked Withdrawn — and the new change's brief records the Adds \u002F Modifies \u002F Withdraws\n- Downstream artifacts that reference this specification's requirements (constraints, technical designs, tickets, delivery records, and `@spec` annotations in code) become potentially stale when a requirement's *text* changes — say so in the requirement (`*(amended YYYY-MM-DD by \u003Cchange-slug>)*`) so Audit can find it\n- Requirements are never renumbered; a wrong number is withdrawn and re-issued\n- An amendment returns an Approved specification to `**Status:** Draft` until the Product Owner approves it again\n- If the PRD's capability area description changes, compare the new and existing specification to determine whether a full regeneration or targeted update is appropriate\n\n## Notes\n\n- Generate one specification per Capability Area; do not combine multiple areas\n- Requirements should be numbered sequentially within each specification, using the capability area prefix\n- Open Questions from source PRD relevant to this capability should be carried forward\n- This skill does not define acceptance criteria—that occurs during Ticket Breakdown\n- Keep specifications under ~2000 words; split complex capabilities if needed\n- The `@spec Coverage` section is not populated during greenfield specification creation — Delivery appends to it as code is delivered. The Brownfield skill populates it immediately since it works from existing code\n- `scripts\u002Fgener8v-state.py lint` fails on a requirement prefix shared by two specifications and warns on a specification that uses more than one prefix; it treats `[XX]-NFR-NNN` like requirements (uniqueness, dangling references) and warns — not errors — when an NFR is in no ticket\n- `NFR` and `REQ` are reserved segments (`CONVENTIONS.md` §3); never choose them as a prefix\n",{"name":5,"description":7,"argument-hint":44},"[capability area] [for change-slug]","main","26f591c601503d32ccba54a6ddbcba75a00910c0","skills\u002Fspecification",0,"https:\u002F\u002Fgithub.com\u002Fgener8v\u002Fgener8v.claude-skills","https:\u002F\u002Fgithub.com\u002Fgener8v","gener8v.com","2026-10-22 20:18:28",{"source":8,"skillName":5,"commands":54,"prompt":64,"zipAvailable":65},[55,58,61],{"tool":56,"command":57},"npx","npx skills add gener8v\u002Fgener8v.claude-skills --skill specification",{"tool":59,"command":60},"bunx","bunx skills add gener8v\u002Fgener8v.claude-skills --skill specification",{"tool":62,"command":63},"pnpm","pnpm dlx skills add gener8v\u002Fgener8v.claude-skills --skill specification","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fgener8v\u002Fgener8v.claude-skills\u002Fblob\u002Fmain\u002Fskills\u002Fspecification\u002FSKILL.md",true,[67,73,79,83,87,91,95,99,105,109,113,117,121],{"path":68,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":71,"sourceHtmlUrl":72},"assets\u002Fspecification.md","ASSET","资产文件",3924,"https:\u002F\u002Fgithub.com\u002Fgener8v\u002Fgener8v.claude-skills\u002Fblob\u002Fmain\u002Fskills\u002Fspecification\u002Fassets\u002Fspecification.md",{"path":74,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":77,"sourceHtmlUrl":78},"references\u002Fconfiguration.md","REFERENCE","参考文档",12776,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Ftrading\u002Fbankr-official-onchainkit\u002Freferences\u002Fconfiguration.md",{"path":80,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":81,"sourceHtmlUrl":82},"references\u002Fexample.md",7482,"https:\u002F\u002Fgithub.com\u002Fgener8v\u002Fgener8v.claude-skills\u002Fblob\u002Fmain\u002Fskills\u002Fspecification\u002Freferences\u002Fexample.md",{"path":84,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":85,"sourceHtmlUrl":86},"references\u002Fexamples.md",20667,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Ftrading\u002Fbankr-official-onchainkit\u002Freferences\u002Fexamples.md",{"path":88,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":89,"sourceHtmlUrl":90},"references\u002Ftoken-operations.md",11864,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Ftrading\u002Fbankr-official-onchainkit\u002Freferences\u002Ftoken-operations.md",{"path":92,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":93,"sourceHtmlUrl":94},"references\u002Ftroubleshooting.md",11066,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Ftrading\u002Fbankr-official-onchainkit\u002Freferences\u002Ftroubleshooting.md",{"path":96,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":97,"sourceHtmlUrl":98},"references\u002Fwallet-integration.md",8198,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Ftrading\u002Fbankr-official-onchainkit\u002Freferences\u002Fwallet-integration.md",{"path":100,"resourceType":101,"resourceTypeDesc":102,"sizeBytes":103,"sourceHtmlUrl":104},"scripts\u002Fcomponent-generator.py","SCRIPT","脚本",11388,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Ftrading\u002Fbankr-official-onchainkit\u002Fscripts\u002Fcomponent-generator.py",{"path":106,"resourceType":101,"resourceTypeDesc":102,"sizeBytes":107,"sourceHtmlUrl":108},"scripts\u002Fcreate-onchain-app.py",5299,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Ftrading\u002Fbankr-official-onchainkit\u002Fscripts\u002Fcreate-onchain-app.py",{"path":110,"resourceType":101,"resourceTypeDesc":102,"sizeBytes":111,"sourceHtmlUrl":112},"scripts\u002Fsetup-environment.py",6409,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Ftrading\u002Fbankr-official-onchainkit\u002Fscripts\u002Fsetup-environment.py",{"path":114,"resourceType":101,"resourceTypeDesc":102,"sizeBytes":115,"sourceHtmlUrl":116},"scripts\u002Fvalidate-setup.py",7756,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Ftrading\u002Fbankr-official-onchainkit\u002Fscripts\u002Fvalidate-setup.py",{"path":118,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":119,"sourceHtmlUrl":120},"SOURCE.md",159,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Ftrading\u002Fbankr-official-onchainkit\u002FSOURCE.md",{"path":122,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":123,"sourceHtmlUrl":124},"TRUST.auto.yaml",2367,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Ftrading\u002Fbankr-official-onchainkit\u002FTRUST.auto.yaml",[126,146,171,194,221,242],{"skillNo":127,"name":128,"nameZh":6,"description":129,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":130,"categories":131,"keywords":132,"publishedAt":39},"01M6CQW5KKZVDJTN9VREPRFT06","ticket-breakdown","Decompose one capability area's requirements for one change into implementable tickets with Priority, Value, acceptance criteria, Prior Art, Output contracts, Known Hazards, dependency ordering and relative sizing: one TICKET-NNN.md per ticket plus backlog.md, in the change's tickets directory. Use when a specification is approved and the team needs work items, such as 'break this spec into tickets' or 'create the backlog for search'. Not for implementing a ticket (delivery) or ordering whole capability areas (dependencies).","https:\u002F\u002Fgithub.com\u002Fgener8v\u002Fgener8v.claude-skills\u002Fblob\u002Fmain\u002Fskills\u002Fticket-breakdown\u002FSKILL.md",[],[133,134,25,26,135,136,29,137,35,38,138,139,140,5,141,142,143,144,145],"ticket breakdown","directory","create","acceptance","team","dependency","decompose","Art","contracts","acceptance criteria","backlog","dependencies","delivery",{"skillNo":147,"name":148,"nameZh":6,"description":149,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":150,"categories":151,"keywords":160,"publishedAt":39},"01M6CQW2XD2Q1JD7KFX944EH4W","technical-design","Translate specifications, constraints and dependencies into architecture decisions (AD-XXX), component boundaries, data model and interface contracts under .gener8v\u002Ftechnical-design\u002F. Use when technology or architecture choices must be settled before tickets are written, such as 'which datastore should we use' or 'design the components for search'. Skip it when the approach is obvious and uncontested. Not for judging an architecture that has already shipped (architecture-review).","https:\u002F\u002Fgithub.com\u002Fgener8v\u002Fgener8v.claude-skills\u002Fblob\u002Fmain\u002Fskills\u002Ftechnical-design\u002FSKILL.md",[152,157],{"categoryNo":153,"categoryName":154,"taxonomyType":155,"taxonomyTypeDesc":156},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",{"categoryNo":158,"categoryName":159,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000032","设计师",[24,36,161,162,163,164,165,166,29,167,33,168,169,170,38,141,144],"technical design","review","translate","components","component","architecture","data","system","model","decisions",{"skillNo":172,"name":173,"nameZh":6,"description":174,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":175,"categories":176,"keywords":177,"publishedAt":39},"01M6CQVX5MJQWPEEWDMRC21ZEJ","setup","Bootstrap the gener8v pipeline in a project: create .gener8v\u002F, copy the conventions, generate pipeline-state.yaml, and add the pipeline directives to CLAUDE.md. Use when the user says 'set up gener8v' or 'initialize the pipeline', when a project has no .gener8v\u002Fprd.md, or after a plugin upgrade to refresh the conventions. Not for deciding what to do next on a project already on the pipeline (orchestrate).","https:\u002F\u002Fgithub.com\u002Fgener8v\u002Fgener8v.claude-skills\u002Fblob\u002Fmain\u002Fskills\u002Fsetup\u002FSKILL.md",[],[173,178,179,135,180,181,182,183,32,184,185,186,187,188,189,38,190,191,192,193],"plugin","bootstrap","generate","state","orchestrate","yaml","pipeline","SET","Bash","python3","initialize","refresh","up","do","next","upgrade",{"skillNo":195,"name":196,"nameZh":6,"description":197,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":198,"categories":199,"keywords":203,"publishedAt":39},"01M6CQVT9PZZ64TC456Y1FWF55","security-review","OWASP-informed, code-level security review of delivered code: injection, authentication and authorization, data exposure, configuration, dependencies, cryptography and logging, with attack scenarios for Medium+ findings and compliance constraints (CC-XXX) treated as Critical. Use after a delivery, especially one touching input handling, auth, sensitive data or external integrations, such as 'security review TICKET-007' or 'check what this delivery shipped for injection or auth bypass before we merge'. Not for a whole-codebase OWASP posture assessment (owasp-top10-review) or prompt-injection risk in LLM features (owasp-llm-top10-review).","https:\u002F\u002Fgithub.com\u002Fgener8v\u002Fgener8v.claude-skills\u002Fblob\u002Fmain\u002Fskills\u002Fsecurity-review\u002FSKILL.md",[200],{"categoryNo":201,"categoryName":202,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000037","律师与法务",[162,204,205,26,206,207,208,209,210,211,212,213,214,215,216,217,218,38,219,220],"security","security review","auth","merge","assessment","code","authentication","compliance","owasp-llm-top10","prompt-injection","owasp-llm","risk","integrations","prompt","check","files","007",{"skillNo":222,"name":223,"nameZh":6,"description":224,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":225,"categories":226,"keywords":227,"publishedAt":39},"01M6CQVPP78PF4SB9H5WAD3837","rot-watch","Detect decay in code that is being actively written: measure six signals (packaging drift, dependency direction, comment language, growth slopes, tests, the detectable subset of SOLID) against a recorded baseline and report only what moved, at .gener8v\u002Frot\u002F. Use once code has been delivered and again every few deliveries, before a release, or when asked 'is the codebase getting worse' or 'has this module drifted'. The first run records the baseline and reports nothing. Not for one delivery's quality (quality-review), defects (defect-sweep) or whether the architecture was right (architecture-review).","https:\u002F\u002Fgithub.com\u002Fgener8v\u002Fgener8v.claude-skills\u002Fblob\u002Fmain\u002Fskills\u002Frot-watch\u002FSKILL.md",[],[228,162,229,166,230,209,231,232,233,234,235,236,237,238,38,239,138,240,241,145],"rot watch","solid","run","report","release","first","baseline","sweep","quality","growth","packaging","only","reports","drift",{"skillNo":243,"name":244,"nameZh":6,"description":245,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":246,"categories":247,"keywords":248,"publishedAt":39},"01M6CQVKYZXHVW9DJHWHF08TKK","quality-review","Review delivered code for engineering quality (organization, readability, error handling, tests, consistency with the codebase's patterns) independent of the specification. Use after a delivery in parallel with code-review and security-review, or on any files the user points at, such as 'is this module maintainable' or 'review this file for readability and tests'. Not for checking a delivery against its ticket (code-review), vulnerabilities (security-review) or decay across many deliveries (rot-watch).","https:\u002F\u002Fgithub.com\u002Fgener8v\u002Fgener8v.claude-skills\u002Fblob\u002Fmain\u002Fskills\u002Fquality-review\u002FSKILL.md",[],[162,236,249,204,250,26,209,251,252,253,254,196,255,256,38,219,5,257,258,145],"quality review","vulnerabilities","error handling","code-review","file","engineering","parallel","user","patterns","organization"]