Ejecuta cualquier Skill en Manus
con un clic

Ejecuta cualquier Skill en Manus con un clic

doc-implementation

Estrellas6

Forks4

Actualizado24 de julio de 2026 a las 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".

Instalación

Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.

Ejecutar en Manus

Fuente

arousi

arousi/awesome-metho-docs

Abrir repositorio de GitHub Ver repositorios del creador

Descarga

Ejecutar en Manus

Ocupaciones relacionadasSOC

Basado en la clasificación ocupacional SOC

Desarrolladores de softwareOcupaciones informáticas y matemáticas·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.

Más de este repositorio

mismo repositorio

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.