Specification authoring with traceable paragraph IDs. Use when writing specifications, updating specs, adding new features to specs, or when implementing code that needs to reference spec paragraphs. Triggers on spec creation, implementation traceability, or coverage verification.
From disciplined-processnpx claudepluginhub rand/disciplined-process-plugin --plugin disciplined-processThis skill uses the workspace's default tool permissions.
Searches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.
Searches prompts.chat for AI prompt templates by keyword or category, retrieves by ID with variable handling, and improves prompts via AI. Use for discovering or enhancing prompts.
Compares coding agents like Claude Code and Aider on custom YAML-defined codebase tasks using git worktrees, measuring pass rate, cost, time, and consistency.
Specifications define WHAT the system does, not HOW. Every normative statement gets a unique ID that implementation and tests reference.
[SPEC-{section}.{paragraph}]
Examples:
[SPEC-01.03] - Section 1, paragraph 3[SPEC-05.12] - Section 5, paragraph 12[SPEC-03.07a] - Section 3, paragraph 7, sub-item a# {Section Title}
## Overview
[SPEC-{NN}.01] This section defines {what this section covers}.
## {Subsection}
[SPEC-{NN}.02] {Normative statement using RFC 2119 language}.
[SPEC-{NN}.03] {Another normative statement}.
### {Sub-subsection}
[SPEC-{NN}.04] {Detailed requirement}.
> **Informative**: {Non-normative explanation or rationale}
Use precise requirement language:
| Keyword | Meaning |
|---|---|
| MUST / SHALL | Absolute requirement |
| MUST NOT / SHALL NOT | Absolute prohibition |
| SHOULD / RECOMMENDED | Strong preference, exceptions allowed with justification |
| SHOULD NOT | Discouraged, exceptions allowed with justification |
| MAY / OPTIONAL | Truly optional |
Add trace comments linking implementation to spec:
// @trace SPEC-03.07 - Validates input length constraint
fn validate_length(input: &str) -> Result<(), Error> {
// Implementation per SPEC-03.07
}
/**
* @trace SPEC-05.12 - Handles authentication flow
*/
function authenticate(credentials: Credentials): Promise<Token> {
// Implementation per SPEC-05.12
}
def process_request(req: Request) -> Response:
"""
@trace SPEC-02.04 - Request processing pipeline
"""
# Implementation per SPEC-02.04
Reference spec paragraphs in test names and comments:
#[test]
// @trace SPEC-03.07
fn test_input_length_validation() {
// Tests requirement from SPEC-03.07
}
describe('SPEC-05.12: Authentication', () => {
it('should return token on valid credentials', () => {
// @trace SPEC-05.12
});
});
def test_request_processing_spec_02_04():
"""@trace SPEC-02.04"""
# Tests requirement from SPEC-02.04
To verify spec coverage, check that every normative paragraph has:
@trace SPEC-XX.YY marker@trace comment# Extract all spec paragraph IDs
grep -rhoE '\[SPEC-[0-9]+\.[0-9]+[a-z]?\]' docs/spec/ | sort -u > spec-ids.txt
# Extract all traced tests
grep -rhoE '@trace SPEC-[0-9]+\.[0-9]+[a-z]?' tests/ | \
sed 's/@trace /[/' | sed 's/$/]/' | sort -u > test-traces.txt
# Find untested specs
comm -23 spec-ids.txt test-traces.txt > untested-specs.txt
[SPEC-03.07] Input length MUST NOT exceed 1024 bytes.
> **History**: Changed from 512 bytes in v2.0. See ADR-0015.
| Type | Marker | Purpose | Tested? |
|---|---|---|---|
| Normative | [SPEC-XX.YY] | Requirements | Yes |
| Informative | Blockquote or "Note:" | Rationale, examples | No |
| Example | Code block | Illustration | Optional |
[SPEC-XX.YY] ID@trace SPEC-XX.YY comments@trace SPEC-XX.YY in name or docstring