specflow-entrylisted

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 · ★ 2 · Testing & QA · score 70

Install: claude install-skill pedropacheco95/cortex

# Specflow: Entry **This is the entry gate.** In a spec-managed project every request passes through here first — it decides *which skill should run*, then that skill does the work. Nothing else starts until this has. ## The Iron Law FIND AND RUN THE RIGHT SKILL BEFORE DOING THE WORK YOURSELF Violating the letter of this law is violating the spirit. If you find yourself constructing a reading under which this request is too small, too obvious, or too urgent to classify, that construction is the violation. Hardening mechanisms per `skills/_conventions/hardening.md`. 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. ## Priority: process skills before implementation skills When more than one skill could apply, the **process** skill runs first. Process skills decide what should happen; implementation skills carry it out. Running them in the other order means the implementation has already chosen the answer the process skill existed to determine. | Situation | Runs first | Then | |---|---|---| | An idea that is not yet a spec | `specflow-brainstorm` | spec-editor → plan → develop | | An agreed spec, no plan yet | `specflow-plan` | `specflow-develop` | | Something is broken | `sp