Domain To Spec

Domain To Spec

This is the first skill for a new project. It converts the user's domain knowledge into two repo-root files:

• AGENTS.md: shared instructions for future coding agents
• PRD.md: the product blueprint consumed by scaffold skills

Do not scaffold application code in this skill.

Preflight

Check whether AGENTS.md or PRD.md already exist. If either exists, stop and ask whether to update specific sections, append new scope, or cancel. Never overwrite these files silently.

Interview The Domain Expert

Extract the sentence:

I am a {profession or role} building a tool to {outcome}.

Ask only for missing essentials:

• Who will use the tool?
• What is the painful or error-prone workflow today?
• What rules, regulations, or professional constraints matter?
• What information does the user provide?
• What output should the tool produce?
• Does the tool need accounts, stored data, file processing, paid APIs, email, or secrets?
• What would make the MVP a success?

Mirror the user's domain language back to them before translating it into software.

Translate Domain Concepts

Map domain ideas into software primitives:

Use this translation to avoid vague specs. Every feature should connect to an input, process, output, or domain constraint.

Define The Simplest Flow

Propose the MVP as:

INPUT: what the user provides
PROCESS: what the app does
OUTPUT: what the user sees, saves, or sends

Keep the first version narrow enough to build. Put tempting extras in Out of Scope.

Decide Backend Needed

Recommend No backend when the app is a static guide, calculator, one-off form, or client-side tool with no persistence or secrets.

Recommend Yes backend when the app stores data between sessions, authenticates users, processes files server-side, calls paid APIs with secret keys, sends email, or integrates with a database.

Ask the user to confirm the backend decision before writing PRD.md.

Write AGENTS.md

Create AGENTS.md at the repo root. Include:

• Project overview
• Repo layout for client/, optional server/, AGENTS.md, and PRD.md
• Setup commands for frontend and backend
• Tech stack
• Code style
• Testing instructions
• Security considerations
• PR instructions
• Domain constraints

Use conservative defaults unless the user specified otherwise:

• Frontend: Next.js App Router, TypeScript, Tailwind CSS
• Backend: FastAPI only if backend is needed
• Validation: Zod for frontend forms, Pydantic for backend models
• Secrets: environment variables, never hardcoded

Write PRD.md

Create PRD.md at the repo root with these sections:

# Product Requirements Document

## What Is This?
## Target User
## Core Flow
## Core Features (MVP)
## Pages / Screens
## User Flow
## Data Model
## Backend Needed?
### Backend Routes
## Domain Constraints
## Success Criteria
## What This Is NOT
## Out of Scope (Save for Later)
## Risk Areas

Pages / Screens should be a table with Page, Purpose, and Key Elements. Backend Routes should list method, path, and purpose only when backend is needed.

Final Response

Return:

1. Files Created: AGENTS.md and PRD.md
2. One-Sentence Summary: what the tool does
3. Backend Needed? confirmed decision and reason
4. Next Step: run scaffold-frontend, and run scaffold-backend afterward only if the PRD says backend is needed

Quality Bar

• The PRD should be understandable to a non-coder and specific enough for a scaffold skill.
• Use the user's real domain words where possible.
• Separate MVP from later ideas.
• Do not invent regulations, data fields, or routes without grounding them in user answers.