dist/gemini/skills/spec-init/SKILL.md
Initialize a `.spec/` project or extract requirements from a document. Use when there is no `.spec/` directory yet, or to add requirements from an existing design doc. NOT for one-off task/req creation (spec-new) or deep PRD-quality requirement capture (spec-interview).
npx skillsauth add alexei-led/claude-code-config spec-initInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
spec init — initialize or extend a projectCLI at scripts/specctl. Three modes, picked by checking whether .spec/ exists and whether the user passed a file path.
ls .spec/ 2>/dev/null && echo "SPEC_EXISTS"
.spec/)If a brainstorming workflow is available in the runtime, use it to surface requirements. Otherwise ask the user directly:
Group findings into requirement topics (auth, data, ui, api, etc.).
Ask the user a multi-choice question: "Does this capture the project?" with options Yes / Adjust / Start over.
mkdir -p .spec/reqs .spec/tasks
echo "# Progress" > .spec/PROGRESS.md
echo "$(date +%H:%M) INIT project" >> .spec/PROGRESS.md
Create one REQ-<topic>.md per requirement topic:
---
id: REQ-<topic>
version: 1
priority: normal
---
# <Title>
<Description>
<Success criteria>
Create initial TASK-<name>.md files:
---
id: TASK-<name>
status: todo
priority: normal
implements: REQ-<topic>
---
# <Title>
<Vertical slice description, acceptance criteria, out-of-scope boundaries>
## Ready
.spec/
├── PROGRESS.md
├── reqs/ (<N> requirements)
└── tasks/ (<M> tasks)
Next: use the `spec-work` skill to start implementing tasks
.spec/ exists + file argument)Confirm the file exists and is readable text. If not, say "File not found or not readable." and stop.
Read the user-provided document. Extract:
Organize by topic. For each, create:
---
id: REQ-<topic>-<name>
version: 1
priority: normal
---
# <Title>
<Description from source>
<Success criteria>
Ask multi-choice: "Generated <N> requirements. Proceed?" with options Write / Preview / Adjust.
mkdir -p .spec/reqs
echo "$(date +%H:%M) GEN <N> requirements" >> .spec/PROGRESS.md
Write each REQ-*.md file. Suggest next: use the spec-new skill to create a task or the spec-work skill to start implementing.
## Already Initialized
.spec/ exists with <N> tasks, <M> requirements.
Use:
- `spec-work` — continue development
- `spec-status` — see progress
- `spec-init <doc.md>` — add requirements from docs
tools
Use when planning, executing, checkpointing, finishing, or inspecting lightweight spec-driven work. Runs one task at a time using `.spec/` markdown files and the bundled `specctl` helper. NOT for broad product discovery beyond a short requirement interview. NOT for generic implementation planning that does not read or write `.spec/` files.
development
Simple web development with HTML, CSS, JS, and HTMX. Use when working with .html, .css, or .htmx files, web templates, stylesheets, or vanilla JS scripts. NOT for React/Vue/Angular (use writing-typescript) or Node.js backends.
tools
Idiomatic TypeScript development. Use when writing TypeScript code, Node.js services, React apps, or TypeScript design advice. Emphasizes strict typing, boundary validation, composition, fast feedback, behavior tests, and project-configured tooling. NOT for Go, Python, Rust, plain HTML/CSS/JS, or server-rendered templates (use writing-web).
tools
Idiomatic shell development for POSIX sh, Bash, Zsh, Fish, hooks, CI shell steps, and scriptable CLI glue. Use when writing or changing `.sh`, `.bash`, `.zsh`, `.fish`, `.bats`, shell functions, shell pipelines, CI `run:` shell bodies, or command-runner recipes. Emphasizes portability, quoting, safe filesystem/process handling, non-TUI CLI tools, ShellCheck, shfmt, Bats, and ShellSpec. NOT for Python, Rust, TypeScript, Go, web code, or GitHub Actions workflow/job/permissions semantics; use operating-infra.