菜单
Write a new spec from scratch when none exists for the idea yet. Gathers context, explores the codebase, fills the frontmatter, and indexes it in specs/README.md. Use when the user says "create a spec", "write a spec", or "new spec". When a spec already exists but is out of date, use refine instead.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/latere-ai/agent-skills --skill create命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
正在显示 SKILL.md
| name | create |
| description | Write a new spec from scratch when none exists for the idea yet. Gathers context, explores the codebase, fills the frontmatter, and indexes it in specs/README.md. Use when the user says "create a spec", "write a spec", or "new spec". When a spec already exists but is out of date, use refine instead. |
| argument-hint | <track/name> [one-line description...] |
| user-invocable | true |
| allowed-tools | Read, Grep, Glob, Edit, Write, Agent, Bash(ls *), Bash(mkdir *), Bash(git log *), Bash(git diff *) |
Create a new design spec in specs/ following the spec document model.
$ARGUMENTS has the form: <track/name> [description...]
<track>/<name> where <track> is
one of the tracks this repo actually uses and <name> is the kebab-case spec
name without .md. Example: local/live-serve.specs/, plus any frontmatter values in use
where specs sit directly in a directory that holds no sub-tracks. Take each
track's meaning from its section heading and intro in .track:specs/README.mdDerive the output file path by answering two independent questions from how the
tree is actually laid out. They compose: specs/local/003-live-serve.md is a
perfectly ordinary path.
If specs/ does not exist yet, bootstrap a flat tree: create specs/, put the
first spec directly inside it with the requested track in track: frontmatter,
and create specs/README.md in Step 5. Do not force a directory scheme before
the project has chosen one.
specs/ has track directories, the spec goes in the
one it belongs to: specs/<track>/<name>.md. If specs sit directly under
specs/, it goes there and the track is recorded as a track: frontmatter
field instead.NNN- prefix, give the new one the next number in that directory — usually
its current max + 1, zero-padded to three digits. If they do not, use the
bare name. Numbering is a per-directory reading-order convention, not a
property of the repo, and a repo may number one directory and not another.The number is a local ordering hint only. Dependency order lives in
depends_on, which resolves repo-root-relative and forms one DAG across the
whole tree regardless of how any directory is grouped or numbered.
specs/README.md to understand the track organization, dependency
graph, and what already exists. For a new tree where it is absent, record
that Step 5 must create a minimal index.specs/, or an
internals doc describing how specs are parsed. If neither exists, infer the
schema from the most recently updated spec in the tree.affects paths. If a closely related spec exists,
warn the user and ask whether to proceed, merge, or abort.Based on the description, identify which parts of the codebase are relevant:
The goal is to ground the spec in reality — reference actual file paths, function names, and existing patterns rather than hypothetical code.
Determine which existing specs this new spec depends on:
specs/README.md for specs that produce interfaces, types, or
infrastructure this spec needs.affects lists of existing specs for overlapping code paths.depends_on entries for specs whose deliverables are prerequisites
— not merely related specs.Also identify which existing specs might depend on this new one (reverse impact). Flag these to the user but do NOT modify them.
Create the spec file at the path derived in Step 0 with this structure (add a
track: <track> line under status: only when the spec's directory does not
already name its track):
---
title: <Human-readable title>
status: drafted
depends_on:
- <spec paths, or empty list>
affects:
- <code paths and packages this spec will modify>
effort: <small | medium | large | xlarge>
created: <today's date, YYYY-MM-DD>
updated: <today's date, YYYY-MM-DD>
author: your-name
dispatched_task_id: null
---
# <Title>
## Overview
<2-4 sentences: what this spec delivers and why it matters. State the problem,
the user need, or the architectural gap it fills.>
## Current State
<Brief description of what exists today in the codebase that is relevant.
Reference actual file paths, types, and functions. This grounds the spec in
reality and helps readers understand the starting point.>
## Architecture
<How the solution fits into the existing system. Describe the key components,
their relationships, and where they live in the codebase. Use a diagram
(Mermaid) if the relationships are non-trivial.>
## Components
<For each major component or change:>
### <Component Name>
<What it does, where it lives, key design decisions. Reference existing
patterns in the codebase where relevant. Include:>
- File paths (existing files to modify, new files to create)
- Key types and interfaces
- Integration points with existing code
## Data Flow
<How data moves through the system for the primary use cases. Describe the
request/response path, state transitions, or processing pipeline. Skip this
section if the spec doesn't involve data flow.>
## API Surface
<New or modified API routes, CLI flags, env variables, or configuration
options. Follow the repository's existing reference format. Skip this section
if no external surface changes.>
## Error Handling
<How errors are detected, reported, and recovered from. What failure modes
exist and how the system degrades. Skip this section if error handling is
trivial.>
## Testing Strategy
<What to test and how. Reference existing test patterns in the affected
packages. Identify:>
- Unit tests (per-function, per-method)
- Integration tests (cross-package, end-to-end)
- Edge cases and failure scenarios
Writing guidelines:
/spec:breakdown. Focus on architecture and
component boundaries rather than implementation details.specs/README.md. If it does not exist, create a minimal index with a
title, a short explanation of the track recorded in frontmatter, and the
spec table below.specs/:
| [<name>.md](<track>/<name>.md) | Not started | <one-line deliverable> |
○ for not
started).Stage the new spec file and the updated specs/README.md. Commit with:
specs: add <name> spec for <one-line purpose>
Do NOT push unless the user explicitly asks.
Report to the user:
/spec:breakdown <spec-path> design to decompose
into sub-design problems"/spec:breakdown <spec-path> tasks to create
implementable tasks, or /spec:implement <spec-path> to implement directly"/spec:impact <spec-path> for full analysis"