Domain to spec

Skill IdkwhatImD0ing/hackathonstarterkit/.agents/skills/domain-to-spec

Win your next hackathon: a battle-tested playbook plus an AI agent skill pipeline that scaffolds and ships your project.

Install

npx -y skills add IdkwhatImD0ing/hackathonstarterkit --skill domain-to-spec

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Turn a non-coder's domain expertise into `AGENTS.md` and `PRD.md` at the repo root before scaffolding. Use this skill first for new projects, idea-to-spec work, PRD creation, app planning, or when the user describes a profession, workflow, constraint, or outcome and needs a buildable software blueprint.

SKILL.md

4.3 KB, as published. Nobody here has run it

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:

Domain Concept	Software Equivalent
Form or checklist	Validated input form
Decision tree	Wizard or conditional logic
Reference document	Searchable knowledge base
Approval process	Status workflow and roles
Report or summary	Generated page, PDF, or export
Compliance check	Rule engine with pass/fail results

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:

Files Created: AGENTS.md and PRD.md
One-Sentence Summary: what the tool does
Backend Needed? confirmed decision and reason
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.