spec-to-repo

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Spec to Repo

需求转代码仓库

Turn a natural-language project specification into a complete, runnable starter repository. Not a template filler — a spec interpreter that generates real, working code for any stack.
将自然语言描述的项目需求转换为完整、可运行的启动代码仓库。这不是简单的模板填充工具,而是一个需求解析器,可为任意技术栈生成真实可运行的代码。

When to Use

使用场景

  • User provides a text description of an app and wants code
  • User has a PRD, requirements doc, or feature list and needs a codebase
  • User says "build me an app that...", "scaffold this", "bootstrap a project"
  • User wants a working starter repo, not just a file tree
Not this skill when the user wants a SaaS app with Stripe + Auth specifically — use
product-team/saas-scaffolder
instead.
  • 用户提供应用的文字描述并需要对应的代码
  • 用户拥有PRD、需求文档或功能列表,需要生成代码库
  • 用户说出“帮我构建一个能……的应用”“搭建这个项目的脚手架”“初始化一个项目”等需求
  • 用户需要可运行的启动代码仓库,而非仅仅是文件目录结构
请勿使用本工具的场景:用户需要包含Stripe + 认证功能的SaaS应用——请改用
product-team/saas-scaffolder

Core Workflow

核心工作流程

Phase 1 — Parse & Interpret

第一阶段——解析与理解

Read the spec. Extract these fields silently:
FieldSourceRequired
App nameExplicit or infer from descriptionyes
DescriptionFirst sentence of specyes
FeaturesBullet points or sentences describing behavioryes
Tech stackExplicit ("use FastAPI") or infer from contextyes
Auth"login", "users", "accounts", "roles"if mentioned
Database"store", "save", "persist", "records", "schema"if mentioned
API surface"endpoint", "API", "REST", "GraphQL"if mentioned
Deploy target"Vercel", "Docker", "AWS", "Railway"if mentioned
Stack inference rules (when user doesn't specify):
SignalInferred stack
"web app", "dashboard", "SaaS"Next.js + TypeScript
"API", "backend", "microservice"FastAPI (Python) or Express (Node)
"mobile app"Flutter or React Native
"CLI tool"Go or Python
"data pipeline"Python
"high performance", "systems"Rust or Go
After parsing, present a structured interpretation back to the user:
undefined
读取需求内容,自动提取以下字段:
字段来源是否必填
应用名称明确指定或从描述中推断
应用描述需求的第一句话
功能特性以项目符号或句子描述的功能行为
技术栈明确指定(如“使用FastAPI”)或从上下文推断
认证功能需求中提及“登录”“用户”“账户”“角色”等关键词时可选
数据库需求中提及“存储”“保存”“持久化”“记录”“ schema”等关键词时可选
API接口需求中提及“端点”“API”“REST”“GraphQL”等关键词时可选
部署目标需求中提及“Vercel”“Docker”“AWS”“Railway”等关键词时可选
技术栈推断规则(用户未明确指定时):
信号推断出的技术栈
“Web应用”“仪表盘”“SaaS”Next.js + TypeScript
“API”“后端”“微服务”FastAPI(Python)或Express(Node)
“移动应用”Flutter或React Native
“CLI工具”Go或Python
“数据管道”Python
“高性能”“系统级”Rust或Go
解析完成后,向用户展示结构化的理解结果:
undefined

Spec Interpretation

需求理解结果

App: [name] Stack: [framework + language] Features:
  1. [feature]
  2. [feature]
Database: [yes/no — engine] Auth: [yes/no — method] Deploy: [target]
Does this match your intent? Any corrections before I generate?

Flag ambiguities. Ask **at most 3** clarifying questions. If the user says "just build it", proceed with best-guess defaults.
应用名称: [名称] 技术栈: [框架 + 语言] 功能特性:
  1. [功能1]
  2. [功能2]
数据库: [是/否 — 引擎类型] 认证功能: [是/否 — 实现方式] 部署目标: [目标平台]
以上是否符合你的需求?生成前是否需要修改?

标记模糊的内容,最多提出3个澄清问题。如果用户说“直接构建”,则基于最佳默认值继续执行。

Phase 2 — Architecture

第二阶段——架构设计

Design the project before writing any files:
  1. Select template — Match to a stack template from
    references/stack-templates.md
  2. Define file tree — List every file that will be created
  3. Map features to files — Each feature gets at minimum one file/component
  4. Design database schema — If applicable, define tables/collections with fields and types
  5. Identify dependencies — List every package with version constraints
  6. Plan API routes — If applicable, list every endpoint with method, path, request/response shape
Present the file tree to the user before generating:
project-name/
├── README.md
├── .env.example
├── .gitignore
├── .github/workflows/ci.yml
├── package.json / requirements.txt / go.mod
├── src/
│   ├── ...
├── tests/
│   ├── ...
└── ...
在编写任何文件前先设计项目架构:
  1. 选择模板 — 匹配
    references/stack-templates.md
    中的对应技术栈模板
  2. 定义文件目录 — 列出所有将创建的文件
  3. 功能与文件映射 — 每个功能至少对应一个文件/组件
  4. 设计数据库Schema — 若涉及数据库,定义表/集合的字段及类型
  5. 识别依赖项 — 列出所有带版本约束的包
  6. 规划API路由 — 若涉及API,列出所有端点的方法、路径、请求/响应格式
生成前向用户展示文件目录:
project-name/
├── README.md
├── .env.example
├── .gitignore
├── .github/workflows/ci.yml
├── package.json / requirements.txt / go.mod
├── src/
│   ├── ...
├── tests/
│   ├── ...
└── ...

Phase 3 — Generate

第三阶段——代码生成

Write every file. Rules:
  • Real code, not stubs. Every function has a real implementation. No
    // TODO: implement
    or
    pass
    placeholders.
  • Syntactically valid. Every file must parse without errors in its language.
  • Imports match dependencies. Every import must correspond to a package in the manifest (package.json, requirements.txt, go.mod, etc.).
  • Types included. TypeScript projects use types. Python projects use type hints. Go projects use typed structs.
  • Environment variables. Generate
    .env.example
    with every required variable, commented with purpose.
  • README.md. Include: project description, prerequisites, setup steps (clone, install, configure env, run), and available scripts/commands.
  • CI config. Generate
    .github/workflows/ci.yml
    with: install, lint (if linter in deps), test, build.
  • .gitignore. Stack-appropriate ignores (node_modules, pycache, .env, build artifacts).
File generation order:
  1. Manifest (package.json / requirements.txt / go.mod)
  2. Config files (.env.example, .gitignore, CI)
  3. Database schema / migrations
  4. Core business logic
  5. API routes / endpoints
  6. UI components (if applicable)
  7. Tests
  8. README.md
编写所有文件,遵循以下规则:
  • 真实代码,而非占位符:每个函数都有真实实现,禁止使用
    // TODO: implement
    pass
    等占位符。
  • 语法合法:每个文件在对应语言中可正常解析,无语法错误。
  • 导入与依赖匹配:所有导入的包必须在清单文件(package.json、requirements.txt、go.mod等)中存在。
  • 包含类型定义:TypeScript项目使用类型注解,Python项目使用类型提示,Go项目使用带类型的结构体。
  • 环境变量配置:生成
    .env.example
    文件,包含所有必填变量,并添加注释说明用途。
  • README.md:包含项目描述、前置条件、安装步骤(克隆、安装依赖、配置环境变量、运行)及可用脚本/命令。
  • CI配置:生成
    .github/workflows/ci.yml
    ,包含安装、代码检查(若依赖中有检查工具)、测试、构建步骤。
  • .gitignore:根据技术栈生成合适的忽略规则(如node_modules、pycache、.env、构建产物等)。
文件生成顺序:
  1. 清单文件(package.json / requirements.txt / go.mod)
  2. 配置文件(.env.example、.gitignore、CI配置)
  3. 数据库Schema / 迁移文件
  4. 核心业务逻辑
  5. API路由 / 端点
  6. UI组件(若涉及)
  7. 测试文件
  8. README.md

Phase 4 — Validate

第四阶段——验证

After generation, run through this checklist:
  • Every imported package exists in the manifest
  • Every file referenced by an import exists in the tree
  • .env.example
    lists every env var used in code
  • .gitignore
    covers build artifacts and secrets
  • README has setup instructions that actually work
  • No hardcoded secrets, API keys, or passwords
  • At least one test file exists
  • Build/start command is documented and would work
Run
scripts/validate_project.py
against the generated directory to catch common issues.
生成完成后,执行以下检查清单:
  • 所有导入的包在清单文件中存在
  • 所有导入引用的文件在目录中存在
  • .env.example
    列出了代码中使用的所有环境变量
  • .gitignore
    覆盖了构建产物和敏感信息
  • README中的安装说明可正常执行
  • 无硬编码的密钥、API密钥或密码
  • 至少存在一个测试文件
  • 构建/启动命令已文档化且可正常运行
运行
scripts/validate_project.py
检查生成的目录,排查常见问题。

Examples

示例

Example 1: Task Management API

示例1:任务管理API

Input spec:
"Build me a task management API. Users can create, list, update, and delete tasks. Tasks have a title, description, status (todo/in-progress/done), and due date. Use FastAPI with SQLite. Add basic auth with API keys."
Output file tree:
task-api/
├── README.md
├── .env.example              # API_KEY, DATABASE_URL
├── .gitignore
├── .github/workflows/ci.yml
├── requirements.txt          # fastapi, uvicorn, sqlalchemy, pytest
├── main.py                   # FastAPI app, CORS, lifespan
├── models.py                 # SQLAlchemy Task model
├── schemas.py                # Pydantic request/response schemas
├── database.py               # SQLite engine + session
├── auth.py                   # API key middleware
├── routers/
│   └── tasks.py              # CRUD endpoints
└── tests/
    └── test_tasks.py         # Smoke tests for each endpoint
输入需求:
"帮我构建一个任务管理API。用户可以创建、列出、更新和删除任务。任务包含标题、描述、状态(待办/进行中/已完成)和截止日期。使用FastAPI和SQLite。添加基于API密钥的基础认证。"
输出文件目录:
task-api/
├── README.md
├── .env.example              # API_KEY, DATABASE_URL
├── .gitignore
├── .github/workflows/ci.yml
├── requirements.txt          # fastapi, uvicorn, sqlalchemy, pytest
├── main.py                   # FastAPI应用、CORS、生命周期管理
├── models.py                 # SQLAlchemy Task模型
├── schemas.py                # Pydantic请求/响应Schema
├── database.py               # SQLite引擎 + 会话
├── auth.py                   # API密钥中间件
├── routers/
│   └── tasks.py              # CRUD端点
└── tests/
    └── test_tasks.py         # 每个端点的冒烟测试

Example 2: Recipe Sharing Web App

示例2:菜谱分享Web应用

Input spec:
"I want a recipe sharing website. Users sign up, post recipes with ingredients and steps, browse other recipes, and save favorites. Use Next.js with Tailwind. Store data in PostgreSQL."
Output file tree:
recipe-share/
├── README.md
├── .env.example              # DATABASE_URL, NEXTAUTH_SECRET, NEXTAUTH_URL
├── .gitignore
├── .github/workflows/ci.yml
├── package.json              # next, react, tailwindcss, prisma, next-auth
├── tailwind.config.ts
├── tsconfig.json
├── next.config.ts
├── prisma/
│   └── schema.prisma         # User, Recipe, Ingredient, Favorite models
├── src/
│   ├── app/
│   │   ├── layout.tsx
│   │   ├── page.tsx          # Homepage — recipe feed
│   │   ├── recipes/
│   │   │   ├── page.tsx      # Browse recipes
│   │   │   ├── [id]/page.tsx # Recipe detail
│   │   │   └── new/page.tsx  # Create recipe form
│   │   └── api/
│   │       ├── auth/[...nextauth]/route.ts
│   │       └── recipes/route.ts
│   ├── components/
│   │   ├── RecipeCard.tsx
│   │   ├── RecipeForm.tsx
│   │   └── Navbar.tsx
│   └── lib/
│       ├── prisma.ts
│       └── auth.ts
└── tests/
    └── recipes.test.ts
输入需求:
"我想要一个菜谱分享网站。用户可以注册账号,发布包含食材和步骤的菜谱,浏览他人的菜谱,收藏喜欢的菜谱。使用Next.js和Tailwind。数据存储在PostgreSQL中。"
输出文件目录:
recipe-share/
├── README.md
├── .env.example              # DATABASE_URL, NEXTAUTH_SECRET, NEXTAUTH_URL
├── .gitignore
├── .github/workflows/ci.yml
├── package.json              # next, react, tailwindcss, prisma, next-auth
├── tailwind.config.ts
├── tsconfig.json
├── next.config.ts
├── prisma/
│   └── schema.prisma         # User、Recipe、Ingredient、Favorite模型
├── src/
│   ├── app/
│   │   ├── layout.tsx
│   │   ├── page.tsx          # 首页——菜谱信息流
│   │   ├── recipes/
│   │   │   ├── page.tsx      # 浏览菜谱
│   │   │   ├── [id]/page.tsx # 菜谱详情
│   │   │   └── new/page.tsx  # 创建菜谱表单
│   │   └── api/
│   │       ├── auth/[...nextauth]/route.ts
│   │       └── recipes/route.ts
│   ├── components/
│   │   ├── RecipeCard.tsx
│   │   ├── RecipeForm.tsx
│   │   └── Navbar.tsx
│   └── lib/
│       ├── prisma.ts
│       └── auth.ts
└── tests/
    └── recipes.test.ts

Example 3: CLI Expense Tracker

示例3:CLI费用追踪工具

Input spec:
"Python CLI tool for tracking expenses. Commands: add, list, summary, export-csv. Store in a local SQLite file. No external API."
Output file tree:
expense-tracker/
├── README.md
├── .gitignore
├── .github/workflows/ci.yml
├── pyproject.toml
├── src/
│   └── expense_tracker/
│       ├── __init__.py
│       ├── cli.py            # argparse commands
│       ├── database.py       # SQLite operations
│       ├── models.py         # Expense dataclass
│       └── formatters.py     # Table + CSV output
└── tests/
    └── test_cli.py
输入需求:
"用于追踪费用的Python CLI工具。支持命令:add、list、summary、export-csv。数据存储在本地SQLite文件中,无需外部API。"
输出文件目录:
expense-tracker/
├── README.md
├── .gitignore
├── .github/workflows/ci.yml
├── pyproject.toml
├── src/
│   └── expense_tracker/
│       ├── __init__.py
│       ├── cli.py            # argparse命令定义
│       ├── database.py       # SQLite操作
│       ├── models.py         # Expense数据类
│       └── formatters.py     # 表格 + CSV输出
└── tests/
    └── test_cli.py

Anti-Patterns

反模式

Anti-patternFix
Placeholder code
// TODO: implement
,
pass
, empty function bodies
Every function has a real implementation. If complex, implement a working simplified version.
Stack override — picking Next.js when the user said FlaskAlways honor explicit tech preferences. Only infer when the user doesn't specify.
Missing .gitignore — committing node_modules or .envGenerate stack-appropriate .gitignore as one of the first files.
Phantom imports — importing packages not in the manifestCross-check every import against package.json / requirements.txt before finishing.
Over-engineering MVP — adding Redis caching, rate limiting, WebSockets to a v1Build the minimum that works. The user can iterate.
Ignoring stated preferences — user says "PostgreSQL" and you generate MongoDBParse the spec carefully. Explicit preferences are non-negotiable.
Missing env vars — code reads
process.env.X
but
.env.example
doesn't list it
Every env var used in code must appear in
.env.example
with a comment.
No tests — shipping a repo with zero test filesAt minimum: one smoke test per API endpoint or one test per core function.
Hallucinated APIs — generating code that calls library methods that don't existStick to well-documented, stable APIs. When unsure, use the simplest approach.
反模式修复方案
占位符代码 — 使用
// TODO: implement
pass
或空函数体
每个函数都要有真实实现。若功能复杂,可实现简化的可用版本。
技术栈覆盖 — 用户指定Flask却使用Next.js始终遵循用户明确的技术偏好。仅在用户未指定时进行推断。
缺少.gitignore — 提交node_modules或.env文件生成适配技术栈的.gitignore文件,作为首批创建的文件之一。
无效导入 — 导入清单文件中不存在的包完成前交叉检查所有导入与package.json/requirements.txt的匹配情况。
过度设计MVP — 为v1版本添加Redis缓存、限流、WebSocket等功能构建最小可用版本。用户可后续迭代优化。
忽略明确偏好 — 用户指定PostgreSQL却生成MongoDB仔细解析需求。明确的偏好不可违背。
缺少环境变量 — 代码读取
process.env.X
.env.example
未列出
代码中使用的所有环境变量必须在
.env.example
中出现并添加注释。
无测试文件 — 交付的仓库中没有任何测试文件至少为每个API端点编写一个冒烟测试,或为每个核心函数编写一个测试。
虚构API — 调用不存在的库方法仅使用文档完善、稳定的API。不确定时采用最简单的实现方式。

Validation Script

验证脚本

scripts/validate_project.py

scripts/validate_project.py

Checks a generated project directory for common issues:
bash
undefined
检查生成的项目目录中的常见问题:
bash
undefined

Validate a generated project

验证生成的项目

python3 scripts/validate_project.py /path/to/generated-project
python3 scripts/validate_project.py /path/to/generated-project

JSON output

输出JSON格式结果

python3 scripts/validate_project.py /path/to/generated-project --format json

Checks performed:
- README.md exists and is non-empty
- .gitignore exists
- .env.example exists (if code references env vars)
- Package manifest exists (package.json, requirements.txt, go.mod, Cargo.toml, pubspec.yaml)
- No .env file committed (secrets leak)
- At least one test file exists
- No TODO/FIXME placeholders in generated code
python3 scripts/validate_project.py /path/to/generated-project --format json

执行的检查项:
- README.md存在且非空
- .gitignore存在
- 若代码引用环境变量,则.env.example存在
- 包清单文件存在(package.json、requirements.txt、go.mod、Cargo.toml、pubspec.yaml)
- 未提交.env文件(避免敏感信息泄露)
- 至少存在一个测试文件
- 生成的代码中无TODO/FIXME占位符

Progressive Enhancement

渐进式增强

For complex specs, generate in stages:
  1. MVP — Core feature only, working end-to-end
  2. Auth — Add authentication if requested
  3. Polish — Error handling, validation, loading states
  4. Deploy — Docker, CI, deploy config
Ask the user after MVP: "Core is working. Want me to add auth/polish/deploy next, or iterate on what's here?"
对于复杂需求,分阶段生成:
  1. MVP — 仅实现核心功能,确保端到端可运行
  2. 认证 — 若用户要求则添加认证功能
  3. 优化 — 错误处理、验证逻辑、加载状态
  4. 部署 — Docker、CI、部署配置
完成MVP后询问用户:“核心功能已可运行。是否需要添加认证/优化/部署配置,或是基于现有内容进行迭代?”

Cross-References

交叉引用

  • Related:
    product-team/saas-scaffolder
    — SaaS-specific scaffolding (Next.js + Stripe + Auth)
  • Related:
    engineering/spec-driven-workflow
    — spec-first development methodology
  • Related:
    engineering/database-designer
    — database schema design patterns
  • Related:
    engineering-team/senior-fullstack
    — full-stack implementation patterns
  • 相关工具:
    product-team/saas-scaffolder
    — 面向SaaS的脚手架(Next.js + Stripe + 认证)
  • 相关方法:
    engineering/spec-driven-workflow
    — 需求优先的开发方法论
  • 相关工具:
    engineering/database-designer
    — 数据库Schema设计模式
  • 相关方法:
    engineering-team/senior-fullstack
    — 全栈实现模式