mcpField
L
living-spec-consolidator

living-spec-consolidator

github.com/nextstage-brasilDevelopment040 installsUpdated 4d ago
Repository

About living-spec-consolidator

living-spec-consolidator is a development skill for maintaining the current functional specifications of a product, intended for teams closing out a version. It updates domain specs and their index, then produces a handoff report; requirements, a code review report, and completed tasks are prerequisites.

Key features

  1. 01Identify affected specs by functional domain
  2. 02Read existing specs before updating
  3. 03Maintain requirements, data models, and endpoints
  4. 04Update the specs index
  5. 05Produce a consolidation report

Use cases

  1. 01Refresh product specs after version closure
  2. 02Place new feature requirements in relevant domains
  3. 03Summarize specification additions and updates

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/nextstage-brasil/skills --skill living-spec-consolidator

After installing, type/living-spec-consolidatorin Claude Code to confirm it loaded.

Bundled filesevals/evals.jsonreferences/domain-spec.template.md

Details

From the project README

Living Spec Consolidator

Maintain {specs_root}/ as the current functional truth of the product.

Default {specs_root} = {product_root}/docs/specs/.

Harness discovery

See ../nextstage-harness/references/harness-discovery.md and ../nextstage-harness/references/artifact-layout.md.

When invoked

  • After version closure workflow (post code review)
  • Not before code-review-report.md exists for the version

Prerequisites

  • {product_root}/docs/versions/{version_san}/requirements.md
  • {product_root}/docs/versions/{version_san}/code-review-report.md
  • {product_root}/docs/versions/{version_san}/execution-handoff.md (tasks completed)

Workflow

1. Identify affected domains

Map features to canonical domains (examples):

Feature areaDomain file
Auth, login, RBACauth.md
Users, profilesusers.md
Billingbilling.md
Notificationsnotifications.md
Reportsreports.md
Integrationsintegrations.md
Agent / graphagent.md

Naming: English, kebab-case, singular (user-profile.md). Multi-domain features update multiple specs.

2. Per domain

If {specs_root}/{domain}.md missing: create from references/domain-spec.template.md

If exists: read entirely; append or update — never blind overwrite

For each relevant feature:

  • Add or update ### Requirement: blocks (SHALL + scenarios)
  • Update ## Data model and ## Endpoints when schema/API changed
  • Append ## Changelog entry: **{version_san}** — {ISO date}: {summary}
3. Update INDEX.md

Create or update {specs_root}/INDEX.md:

# Domain specs — {product_name}

| Domain | File                 | Last updated | Versions      |
| ------ | -------------------- | ------------ | ------------- |
| auth   | `docs/specs/auth.md` | {date}       | {version_san} |
4. Consolidation report

Emit short report for handoff:

## Living specs updated
| Domain | Action | File |
...
Requirements added: N
Requirements updated: N
New specs: N

Critical rules

  • English for spec content
  • Requirements use verifiable SHALL language
  • Read before write on existing specs
  • Planning orchestrator should read INDEX.md before new version requirements

Related skills

  • requirements-generator — reads living specs when planning
  • code-reviewer — prerequisite approval

Comments

Markdown supported