Run any Skill in Manus with one click

doc-implementation

Stars6

Forks4

UpdatedJuly 24, 2026 at 00:50

Phase 4 (Implementation traceability). Use to record how approved requirements map to the build - ask the SWE which design components, modules, and code/PRs implement each FR, and link test IDs. Documents traceability only; no code lives here. Trigger on "link requirements to code", "update traceability", "which FRs did this PR implement", "record design components".

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

arousi

arousi/awesome-metho-docs

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

SKILL.md

readonly

name	doc-implementation
description	Phase 4 (Implementation traceability). Use to record how approved requirements map to the build - ask the SWE which design components, modules, and code/PRs implement each FR, and link test IDs. Documents traceability only; no code lives here. Trigger on "link requirements to code", "update traceability", "which FRs did this PR implement", "record design components".

Doc: Implementation Traceability (Phase 4)

Record the mapping from Approved requirements to the code that builds them. This repo holds documentation, not code - this skill maintains the traceability links only. Owns Phase 4 only (SCHEMA.md traceability rules). Consumes doc-design / doc-requirements; feeds doc-testing.

Inputs

Approved FR/UC IDs + their design components/entities.
Build references the SWE can provide: module names, code paths, PR/commit URLs, test IDs.

Process (elicitation loop)

Read the FR files' Traceability sections.
Ask the batch from the bank per Approved FR.
Write: fill each FR's Traceability with Design Components + code/PR/commit references + related FRs + test-case IDs.
Re-read; flag Approved FRs still missing a design-component or code link; ask follow-ups.
If the build deviated from the spec, DO NOT rewrite the FR - log a new candidate for doc-analysis / doc-requirements to handle. Repeat until DoD.

Questions to ask (bank)

Components: Which design components/modules implement FR X?
Code: Link to the implementing code, PR, or commit (if known)?
Tests: Which test-case IDs cover FR X?
Deviations: Did the implementation diverge from the spec? (capture as a new requirement candidate, not an edit)
Status: Has this been reviewed/approved? (status stays a review-state; there is no Implemented status)

Outputs (updates)

Traceability section of each Packages/<Package>/FR-*.md: Design Components, code/PR/commit refs, Related FRs, Test Cases.

Definition of Done (gate)

Each Approved FR/UC links its design components and, where known, the implementing code/PR and test IDs. (LIFECYCLE.md Phase 4.)

Handoff

FRs carrying design + code + test references -> doc-testing verifies coverage.

Guardrails

Never add an "Implemented" status (CI rejects it) - track build via links. Deviations become new IDs, never silent rewrites. ASCII; append-only. See SCHEMA.md, LIFECYCLE.md Phase 4.

More from this repository

same repository

doc-analysis

arousi/awesome-metho-docs

Phase 1 (Analysis). Use to analyze a module, feature, or requirement source - ask the SWE questions to understand as-is/to-be, actors, and capabilities, then normalize into atomic candidates classified FR/UC/NFR/Gap/Entity in Analysis/Analysis.md. Trigger on "analyze this feature/module", "break this down", "what are the requirements here", "normalize these notes".

2026-07-246

doc-design

arousi/awesome-metho-docs

Phase 3 (Design and Modeling). Use to model the data and behavior behind approved requirements - ask the SWE about entities, attributes, keys, relationships, and which flows need diagrams, then write the DDT + PlantUML and register entities. Trigger on "model the entities", "design the schema/ERD", "add a sequence/architecture diagram", "data dictionary".

2026-07-246

doc-planning

arousi/awesome-metho-docs

Phase 0 (Planning). Use to start documenting a software project or a major initiative - elicit the project charter by asking the SWE about goals, stakeholders, scope, constraints, risks, and success criteria, then generate or update the PM/ planning files. Trigger on "plan a project", "write a charter", "brainstorm scope", "who are the stakeholders", "define scope/risks".

2026-07-246

doc-requirements

arousi/awesome-metho-docs

Phase 2 (Requirements). Use to turn analysis candidates into Functional Requirements, Use Cases, and NFR references - ask the SWE for exact behavior, acceptance criteria, actors, flows, priorities, and NFR targets, then write the registry rows and per-package FR/UC files. Trigger on "write the FRs", "draft use cases", "define acceptance criteria", "specify NFRs".

2026-07-246

doc-testing

arousi/awesome-metho-docs

Phase 5 (Testing). Use to build the test-case registry that verifies requirements - derive test cases from each FR's Given/When/Then acceptance criteria by asking the SWE about happy/boundary/failure paths and test data, then write Testing/TestCases.md and back-reference the FRs. Trigger on "write test cases", "define test coverage", "TC registry", "verify these requirements".

2026-07-246

document-software-project

arousi/awesome-metho-docs

Umbrella skill to document a software project in this repo across the full lifecycle - planning, analysis, requirements (FR/UC/NFR), design/diagrams, implementation traceability, and testing. Routes to the phase skills doc-planning / doc-analysis / doc-requirements / doc-design / doc-implementation / doc-testing. Trigger when asked to document a project end-to-end, set one up, or when the phase is unclear.

2026-07-246

name	doc-implementation
description	Phase 4 (Implementation traceability). Use to record how approved requirements map to the build - ask the SWE which design components, modules, and code/PRs implement each FR, and link test IDs. Documents traceability only; no code lives here. Trigger on "link requirements to code", "update traceability", "which FRs did this PR implement", "record design components".

Doc: Implementation Traceability (Phase 4)

Inputs

Approved FR/UC IDs + their design components/entities.
Build references the SWE can provide: module names, code paths, PR/commit URLs, test IDs.

Process (elicitation loop)

Read the FR files' Traceability sections.
Ask the batch from the bank per Approved FR.
Write: fill each FR's Traceability with Design Components + code/PR/commit references + related FRs + test-case IDs.
Re-read; flag Approved FRs still missing a design-component or code link; ask follow-ups.
If the build deviated from the spec, DO NOT rewrite the FR - log a new candidate for doc-analysis / doc-requirements to handle. Repeat until DoD.

Questions to ask (bank)

Components: Which design components/modules implement FR X?
Code: Link to the implementing code, PR, or commit (if known)?
Tests: Which test-case IDs cover FR X?
Deviations: Did the implementation diverge from the spec? (capture as a new requirement candidate, not an edit)
Status: Has this been reviewed/approved? (status stays a review-state; there is no Implemented status)

Outputs (updates)

Traceability section of each Packages/<Package>/FR-*.md: Design Components, code/PR/commit refs, Related FRs, Test Cases.

Definition of Done (gate)

Each Approved FR/UC links its design components and, where known, the implementing code/PR and test IDs. (LIFECYCLE.md Phase 4.)

Handoff

FRs carrying design + code + test references -> doc-testing verifies coverage.

Guardrails

Never add an "Implemented" status (CI rejects it) - track build via links. Deviations become new IDs, never silent rewrites. ASCII; append-only. See SCHEMA.md, LIFECYCLE.md Phase 4.