メニュー
Use when decomposing approved scope into traceable capabilities, features, subfeatures, and atomic requirements; use user-story-generation for Agile backlog phrasing.
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/peterbamuhigire/srs-skills --skill 05-feature-decompositionコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
SOC 職業分類に基づく
SKILL.md を表示中
| name | 05-feature-decomposition |
| description | Use when decomposing approved scope into traceable capabilities, features, subfeatures, and atomic requirements; use user-story-generation for Agile backlog phrasing. |
| metadata | {"portable":true,"compatible_with":["claude-code","codex"]} |
Feature hierarchy and atomic requirement set is the next lifecycle deliverable.user-story-generation when that neighbouring route owns the decision or deliverable.| Artefact | Source or provider | Required? | Behaviour when missing |
|---|---|---|---|
| Vision, PRD or BRD, system context, models, interfaces, and prioritisation rules | Approved upstream product and requirements artefacts | Yes | Stop the affected step, name the missing source, and return only a qualified gap record. |
Feature hierarchy and atomic requirement set.| Artefact | Consumer | Acceptance condition |
|---|---|---|
| Feature hierarchy and atomic requirement set | SRS assembly, traceability, architecture, and testing | Required sections are populated, source links resolve, and every material requirement or decision has an observable review or test oracle. |
| Evidence | Reviewer | Acceptance condition |
|---|---|---|
Source, decision, trace, and validation record for Feature hierarchy and atomic requirement set | Requirements quality reviewer | Inputs used, decisions made, checks run, failures, and unassessed items are explicit. |
Read and search are required. Editing is allowed only when the request authorises creation or repair of the named requirements artefact. Publishing, production mutation, destructive action, spending, and certification require explicit authority.
Fallback: if a required file, reviewer, standard source, network check, renderer, or execution capability is unavailable, return the narrowest useful qualified result and mark the affected check not assessed; never convert an unassessed check into a pass.
| Choice or condition | Action | Failure or risk avoided |
|---|---|---|
| A feature mixes independent actors, outcomes, or release decisions | Split it while retaining parent and source trace links. | Requirements too broad to design or test. |
| Required inputs and test oracles are complete | Continue through the existing workflow and record evidence. | A deliverable whose acceptance cannot be reproduced. |
| A mandatory source or owner is missing | Stop the affected branch and issue a qualified gap record. | Fabricated context or unauthorised decisions. |
Feature hierarchy and atomic requirement set and its acceptance checks.Feature hierarchy and atomic requirement set from assumed context. Fix: cite the project source or mark the scope blocked.user-story-generation without routing the decision. Fix: hand off the named input and preserve trace links.not assessed and state the release consequence.Use this skill after Sections 1.0, 2.0, and 3.1 are generated. It transforms the feature set and quality standards into Section 3.2 (Feature Decomposition), ensuring every functional requirement follows a stimulus/response pattern with a single verifiable "shall" per clause per IEEE 830 Clause 5.3.1.
WBS Alignment: The output of this skill forms the requirements baseline equivalent to a WBS Work Package layer (per PMBOK Guide, 7th Ed.): it decomposes scope from Features (Epic level) → Subfunctions (Story level) → Verifiable Requirements (task-level acceptance criteria). Project managers familiar with WBS methodology can use this output directly to populate their WBS dictionary for the requirements scope baseline.
projects/<ProjectName>/_context/features.md, projects/<ProjectName>/_context/quality_standards.mdprojects/<ProjectName>/<phase>/<document>/SRS_Draft.md (Section 3.2 only)Every SHALL requirement must include an inline GWT (Given-When-Then) acceptance stub immediately after the requirement statement:
**FR-[ID]: [Requirement Title]**
The system shall [verb] [object] when [condition].
**Acceptance:**
- **Given** [precondition — system state before the action]
- **When** [trigger action — exactly one]
- **Then** [observable outcome — externally verifiable]
*Priority: [Must/Should/Could/Won't] | Audience: [End User / Admin / Developer] | Precondition: [System state required before this requirement applies, or "None"]*
GWT Rules (Adzic, 2023):
When clause per stub. Two Whens = two requirements.Then must describe an externally observable state change, not an internal variable.Given uses past tense (preconditions that existed before the action).[VERIFIABILITY-FAIL: expected result is not a test oracle].Checklist:
python feature_decomposition.py from this directory or invoke the logic.prompt through your skill runner.features.md, extract user story triggers, and build a Functional Decomposition Tree with numbered subsections (3.2.x.1 Description/Priority, 3.2.x.2 Stimulus/Response Sequences, 3.2.x.3 Functional Requirements).[Source: features.md > Feature Name] per IEEE 830 §4.3.8.features.md.../ieee-830-compliance-checklist.md (ID IEEE830-5.3.2) for compliance verification.SRS_Draft.md retains Sections 1.0, 2.0, and 3.1 content while replacing or appending Section 3.2.manifest.mdAfter generating all section files, create (or overwrite) manifest.md in the SRS document directory (projects/<ProjectName>/<phase>/<document>/01-srs/) listing the section files in the correct assembly order:
# Document Manifest — SRS Feature Decomposition
# Generated by feature-decomposition. Edit to reorder or exclude sections before building.
01-introduction.md
02-overall-description.md
03-functional-requirements.md
04-nfr.md
05-external-interfaces.md
06-constraints.md
This ensures scripts/build-doc.sh assembles sections in the intended order rather than alphabetical fallback.
README.md: Explains the intent and quality expectation for this skill.feature_decomposition.py: Automation script that performs parsing, decomposition, and writing of Section 3.2.logic.prompt: Provides meta instructions for Claude to orchestrate the process.