菜单
Methodology for drafting technical design specs. Load when asked to write, draft, or refine a spec, design doc, architecture note, RFC, or similar document for a system, API, protocol, or subsystem.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
Token-efficient man page reading. Load when looking up CLI tool docs, flags, options, usage examples, config formats. Do NOT use bash to run `man` directly without loading this skill first.
Load when user asks to create, update, edit, or refactor any OpenCode (OC) artefact: skills, agents, commands, tools, plugins, or snippets — including modifying an existing one. Triggers examples: "create skill to …", "draft a command to …", "add Y to OC cmd Z", "edit the W agent", "write a plugin to …", "create a tool for …", "update crafter skill". Guides user through discovery, drafting, and iterative refinement.
Load ONLY when user explicitly invokes /reflect-friction or directly asks to review session friction (e.g. "review friction", "what went wrong", "where did you push back"). Do NOT auto-load speculatively.
General script writing guidelines: structure, naming, error handling, and organization. Language-agnostic. Auto-load when writing or reviewing any script. Language-specific skills (write-script-bash, write-script-bats) build on top of this.
Load whenever new files or directories are created in a git repo — via write, bash, or any other tool. Ensures `git_track_new_file` is called so new files are git-tracked for the user.
Bash script writing guidelines: shebang, strict mode, bash idioms, and full boilerplate. Auto-load when writing or reviewing bash scripts. Loads write-script-generic for language-agnostic rules.
| name | write-spec |
| description | Methodology for drafting technical design specs. Load when asked to write, draft, or refine a spec, design doc, architecture note, RFC, or similar document for a system, API, protocol, or subsystem. |
| metadata | {"maintainers":["bew"]} |
Produce structured, honest, maintainable technical specs capturing design decisions, API shape, invariants, and open questions.
Three phases, always in order:
Phase:Discover — gather inputs; establish $basedir, $specdir, $specpathPhase:Draft — confirm section structure; write spec; fill sections iterativelyPhase:Review — in-context review; assess readiness; optionally promote to _SPECS/Paths used throughout:
$basedir — base specs directory, either _WIP_SPECS/ (default) or _SPECS/ (promoted)$slug — short kebab-case identifier for this spec, confirmed in Phase:Discover$specdir — $basedir/<slug>/ — the spec's own directory; contains SPEC.md and related files$specpath — $specdir/SPEC.md — the spec file; defined at end of Phase:Discover; used in all subsequent phasesThe spec's H1 includes a status tag: # [STATUS] <Name>
Current status tags: DRAFT, MAYBE-READY, READY, ABANDONED
Default on creation: DRAFT.
Update in-place as spec evolves.
Phase:Discover — Gather inputs & establish $specpathWhen entering Phase:Discover: read <./refs/phases/discover.md> for full instructions.
Phase:Draft — Write skeleton; fill sections iterativelyWhen entering Phase:Draft: read <./refs/phases/draft.md> for full instructions.
Phase:Review — In-context review passWhen entering Phase:Review: read <./refs/phases/review.md> for full instructions.