specflow-new-projectlisted

Generate a complete two-layer spec tree (business specs for stakeholders + developer specs for implementation), folder overview docs in every directory, tooling manifest, agents, skills, rules, and build order from a project description. Use this skill whenever the user wants to start a new project from scratch, describes a product idea, says things like "new project", "build me an app", "I want to create", "start a new", "specflow new", "start from scratch", "help me spec this out", "write specs for this", or presents any product concept that needs structured planning before implementation. Even if the user just describes what they want to build without explicitly asking for specs, this skill should trigger — the goal is to plan before coding. The output contains both `.specflow/specs-business/` (stakeholder-facing outcomes and journeys) and `.specflow/specs/` (developer-facing entity references, rules, acceptance criteria), bidirectionally linked, with an `_overview.md` in every folder of both trees.
pedropacheco95/cortex · ★ 1 · AI & Automation · score 74

Install: claude install-skill pedropacheco95/cortex

# Specflow: New Project Turn a product idea into a complete, buildable spec tree that Claude Code can implement autonomously. The output is a directory of markdown files — specs (business + developer), folder overviews, skills, agents, rules, and a build order — that serve as the single source of truth for the project. ## Why this matters Without specs, Claude Code tends to make ad-hoc architectural decisions, skip edge cases, and produce inconsistent code. Specflow front-loads the thinking: every behavior is defined once in a spec, every spec has acceptance criteria, and Claude implements them one vertical slice at a time. The spec tree is the product — code is just an artifact of it. ## The two-layer spec model Every Specflow project produces two parallel spec trees: - **`.specflow/specs-business/`** — high-level specs for non-technical stakeholders (clients, PMs, executives). Each business spec describes an outcome, a user journey, business rules, and success metrics. **No schemas, no APIs, no test-shaped acceptance criteria.** This is the contract with the client: what the product does and why. - **`.specflow/specs/`** — developer-facing specs (the existing layer). Schemas, APIs, dependency chains, Given/When/Then acceptance criteria. This is the contract with the implementer: how the product is built. The two layers are **bidirectionally linked**: - Every developer leaf spec has frontmatter `implements:` pointing to exactly **one** business spec — the outcome it p