菜单
Turn the current conversation into a draft local spec in specs/ using this repository's spec template and Nightmanager conventions. Synthesis, not an interview.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Two-axis review of a diff — Standards (does it follow the repo's conventions and avoid code smells?) and Spec (does it implement what the ticket/spec asked?). Runs the axes as parallel sub-agents. Use to review a branch, PR, or work-in-progress.
Relentlessly interrogate a plan or design one question at a time until the goal, risks, and trade-offs are clear.
Implement one ready ticket or spec interactively in the foreground — the attended alternative to the AFK /nightmanager night shift. TDD where seams allow, then code review, then commit.
Investigate a question against high-trust primary sources and capture the findings as a Markdown note in the repo. Dispatches Nightmanager's librarian tool so you keep working while it reads.
Test-driven development reference — what a good test is, where tests go, the anti-patterns, and the rules of the red → green loop. Reference material for /implement and the night shift, not a workflow of its own.
Break a spec, plan, or conversation into vertically-sliced Nightmanager tickets — local TODOs.md entries, each declaring what it delivers and what blocks it.
| name | to-spec |
| description | Turn the current conversation into a draft local spec in specs/ using this repository's spec template and Nightmanager conventions. Synthesis, not an interview. |
Take the current conversation, idea, and codebase understanding and synthesise a draft spec under specs/ using the structure from specs/TEMPLATE.md. This document is a broad specification (you may know it as a PRD), not a strict product-requirements form.
Do not run an interview here — that is grill-me's job. Synthesise what you already know. Only ask a question when a required section cannot be written without a decision the conversation never settled.
Inspect the repo to ground the spec in current behaviour and likely implementation areas. Use the project's existing vocabulary and respect anything the surrounding specs establish.
Sketch the test seams. Decide where the feature will be observed and tested — prefer existing seams to new ones, and the highest seam possible. The fewer seams, the better; the ideal is one. Record them in the spec's Testing Plan / Suggested Approach. If a new seam is needed, briefly check it matches the user's expectations.
Write specs/draft-<slug>.md (unless the user names a file) filling every section of specs/TEMPLATE.md with concrete, testable content:
Status: draft and the draft- prefix — promotion to active is to-ready's job, not this skill's.TODOs.md entries or GitHub issues here — that is to-tickets.<title>, <human>, <yyyy-mm-dd>, empty bullets); to-ready will refuse to promote a spec that still has them.[draft] only, never [ready].