specflow-change-routerlisted

Classify every incoming user request against the project's spec tree (developer specs in `.specflow/specs/`, business specs in `.specflow/specs-business/`, and `_overview.md` folder docs) and route it to the correct action before any work begins. This skill is the mandatory entry point for ALL user interactions in a Specflow-managed project (any project with a `.specflow/specs/` directory, with or without a parallel `.specflow/specs-business/`). PROACTIVELY use this skill whenever the user says anything in a project under spec management — bug reports, feature requests, behavior changes, stakeholder questions, "what does this group do?", outcome/journey/metric talk, or anything that might touch a developer spec, a business spec, or a folder overview. Also triggers on "add a feature", "fix this bug", "change this behavior", "what does X do", "what's the goal of X", "why do we have X", and on requests that may have drifted between business and developer layers (e.g., a dev change that invalidates the business d
pedropacheco95/cortex · ★ 1 · Testing & QA · score 74

Install: claude install-skill pedropacheco95/cortex

# Specflow: Change Router Every request in a spec-managed project must be classified before any work begins. This prevents ad-hoc code changes that bypass the spec tree and ensures all changes flow through specs first. The core principle: **specs are the source of truth**. Code is an artifact of specs. Humans review specs, not code. Every change starts at the spec level. ## The two-layer spec model (read this first) A modern Specflow project has two parallel spec layers plus a folder-overview layer. The router must understand all three. | Layer | Lives in | Audience | Contains | Frontmatter link | |---|---|---|---|---| | **Business specs** | `.specflow/specs-business/` | Stakeholders, PMs, clients | Outcomes, user journeys, business rules, success metrics, KPIs. No schema, no API, no Given/When/Then. | `implemented_by: [path, …]` (points down to dev specs) | | **Developer specs** | `.specflow/specs/` | Engineers, AI builders | Entities, schemas, API contracts, rules, Given/When/Then acceptance criteria. | `implements: path` (points up to exactly one business spec) | | **Folder overviews** | `_overview.md` in every directory under `.specflow/specs/` and `.specflow/specs-business/` (root, every domain folder, every capability folder, sub-folders) | Anyone navigating the tree | What this group of specs IS, what it COVERS, WHY it exists as a group. No criteria, no rules — just orientation. | None | > **Filename note.** This skill uses `_overview.md` (underscore prefix sorts