Guides component team engineers and tech leads through creating an OpenSpec Component Implementation Spec in their Component Repo. Trigger this skill when someone has received a fan-out task from the Platform Repo and needs to write the "how" for their service, when they say "I need to write my component spec", "how do I implement the platform spec in my service", "I got a task from the platform team and need to start", "what goes in my component spec", or "how do I declare my MCP sources". Also trigger when they need to create a local ADR in their component repo. Do NOT trigger for Platform Specs or Platform Constitution — those use the sdd-platform-spec skill.
You help component team engineers and tech leads write a correct, MCP-grounded Component Implementation Spec (OpenSpec). The Component Spec defines HOW a service implements the platform's intentions. It is owned by the Component Team. It lives in the Component Repo.
It is NOT a copy of the Platform Spec — it is the local "how" derived from the Platform Spec.
The human must have all of these before writing a single line of their component spec. If any are missing, stop and tell them to get them first.
□ Fan-out task from the Platform Repo containing:
- platform_spec_id (e.g., PLAT-124 v1)
- context_pack_version (e.g., cp-v2)
- contract_change: yes / no
- blocked_by: [] (must be empty — if not, use sdd-adr skill first)
□ Access to the Platform Spec file in the Platform Repo
□ Context Pack file: .specify/memory/context-<initiative-id>.md
(or the equivalent domain MCP files in your component repo's context/ directory)
□ Your component's domain MCP file: .specify/memory/domains/<your-domain>.md
If blocked_by in the fan-out task is non-empty → stop. The ADR must be resolved first.
Use the skill to check the ADR status.
sdd-adrIf contract_change: yes → before writing the component spec, confirm the Contract Change
Spec has been created in the Platform Repo and approved by the Integration Owner.
Every Component Spec must open with this metadata block — no exceptions:
## Metadata
- ID: SPEC-<DOMAIN>-<NUMBER>
- Implements: <Platform Spec ID + version> ← REQUIRED
- Context Pack: <cp-version> ← REQUIRED
- Contracts Referenced: [list of event/API versions used]
- Blocked By: [] ← Must be empty to implement
- Status: Draft
Then for each section below, the human must declare a Source: line before writing content.
This is what makes the spec anti-invention — no section can be written from memory or assumption.
Source: Platform MCP / Initiative ECO-124
Summarize the user-facing problem this component is solving. Copy the relevant part from the Platform Spec — do not rewrite it from scratch.
Source: Platform Spec PLAT-124 v1 — Component Responsibilities section
What this component specifically does and does not do. Keep it tight to this service.
Source: Domain MCP — <your domain> invariants v<version>
List the invariants from your domain MCP that are relevant to this spec. For example:
If an invariant is not in your domain MCP file — STOP. Ask the Domain Owner to add it first. Do not invent invariants.
Source: Domain MCP + Integration MCP — <contract names + versions>
Describe how this component interacts with other domains. Reference the exact event or API versions from the Integration MCP. For example:
Source: Integration MCP — <contract names> v<version>
List every event and API this component publishes or consumes. Include versions. If a new version is needed, flag it here and confirm the Contract Change Spec exists in Platform Repo.
Source: Component MCP — <your service> patterns v<version>
How this component implements the feature. This is the section unique to the Component Spec. Follow approved patterns from your Component MCP. Reference your service's tech stack, data model, and local constraints.
Source: Platform MCP — observability, security, performance v<version>
Copy the relevant NFR requirements from the Platform MCP. Do not reduce or soften them.
Source: Platform MCP — logging/metrics/tracing standards v<version>
Specify exact log events, metric names, and trace spans this implementation will produce.
Run /speckit.analyze in your Component Repo before marking the spec as Approved.
Walk through each gate with the human:
Gate 1 — Context Completeness
Source: line? → Yes/NoGate 2 — Domain Validity
Gate 3 — Integration Safety
Gate 4 — NFR Compliance
Gate 5 — Ready-to-Implement
Blocked By empty? → Yes/NoIf any gate fails → do not mark as Approved. Fix the failure first. Use sdd-gate-check
skill for detailed remediation guidance.
Before any implementation begins, update spec-graph.json:
{
"SPEC-CART-01": {
"implements": "PLAT-124 v1",
"context_pack": "cp-v2",
"contracts_referenced": ["CartUpdated-v2", "OrderPlaced-v3"],
"blocked_by": [],
"status": "Approved",
"affects": ["cart-service", "CartUpdated event"]
}
}
If during spec writing you encounter an ambiguity that is scoped only to your component (does not affect other components or platform policy), create a Local ADR:
component-repo/adr/ADR-LOCAL-001-<short-title>.md
Add to your spec:
Blocked By: ADR-LOCAL-001
Use the sdd-adr skill to draft and track it.
If the ambiguity affects multiple components or platform policy → escalate to the Platform Repo. Do not create a local ADR for a cross-cutting concern.