spec-driven-extended-meta-planning

Validates OpenSpec change planning artifacts against schema rules and repository evidence.

Updated Aug 2, 2026
One-click install
npx skills add https://github.com/kxnzee/multi-repo-specs --skill spec-driven-extended-meta-planning-kxnzee
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: spec-driven-extended-meta-planning
Source: https://github.com/kxnzee/multi-repo-specs/tree/main/extensions/spec-driven-extended/skills/spec-driven-extended-meta-planning
Command: npx skills add https://github.com/kxnzee/multi-repo-specs --skill spec-driven-extended-meta-planning-kxnzee

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Teams using spec-driven development need an independent, read-only check that a change's planning artifacts (proposal, specs, design, tasks) actually comply with the active schema rules and confirmed evidence before moving forward, without accidentally mutating artifacts or treating a review as an approval gate. ## Core Features & Use Cases - Stage-scoped verification: Checks exactly one stage at a time (proposal, specs, design, tasks, impact-review, or planning-review) using the rules returned by the get_change_context MCP call, never reconstructed from memory. - Repository evidence scouting: Delegates single-question current-state checks to a repository evidence scout subagent with strict input/output contracts, anchors, and fallback rules. - Structured findings output: Returns a YAML result with blockers, warnings, notes, check_status, and next_action, plus traceability and repository coverage matrices for full planning reviews. - Use Case: Before approving a design document for a multi-repository change, run the design stage check to confirm every technical decision traces to a requirement and that repository impact matches the delta specs. ## Quick Start Ask the agent to run the spec-driven-extended meta-planning check on change 'add-user-auth' for the design stage and report any blockers.

Frequently Asked Questions about spec-driven-extended-meta-planning

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I verify an OpenSpec change design before implementation?▼

Run the meta-planning check for the design stage with the change ID. It reads the artifact instructions from get_change_context, validates the design against its template and requirement traceability, and returns blockers, warnings, or a ready status.

What is the difference between impact-review and planning-review stages?▼

Impact-review checks applicable contracts, data, security, compatibility, migration, rollout, and rollback concerns with an impact/repository matrix. Planning-review verifies the full traceability chain from source through requirements, scenarios, design decisions, tasks, and evidence.

Can this check modify my change artifacts or approve a gate?▼

No. The check is strictly read-only: it never modifies the change, master specs, code, or tasks, and a ready result is not an approval, gate decision, or evidence of implementation. Findings are returned to the calling workflow for resolution.

When is repository evidence allowed during planning checks?▼

Proposal and specs stages are store-only and forbid repository access. Design, tasks, impact-review, and planning-review allow targeted single-question repository evidence requests through the scout subagent, one question per call with explicit anchors.

What happens when the schema does not match spec-driven-extended?▼

The check returns BLOCKER: SCHEMA_MISMATCH immediately and does not apply its checklist. It verifies openspec_status.schemaName from get_change_context before any stage validation begins.

Why does a check return blocked instead of ready?▼

A blocked status means unresolved blockers exist, such as contradictions with intent or requirements, missing mandatory evidence, unavailable instructions, or an interrupted check. The output lists each finding with evidence and the required decision.