القائمة
Draft or refine a docs/specs spec from a user goal or rough plan. Use when creating a new spec, turning a plan into acceptance criteria, or updating an existing spec.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
設計や計画の壁打ちインタビュー。候補案、推奨案、選択式UIを出さず、事実と開かれた問いだけを1つずつ投げて、ユーザー自身に設計理由を言語化させる。行き詰まりにはヒントを段階的に強め、明示的なギブアップ時のみ一般的に多数派の回答を出す。 ユーザーが「壁打ち」「kabeuchi」と言ったとき、または設計判断を自分の言葉で説明できるようになりたい・定着させたいという意図を示したときに使う。推奨案付きで決めたい場合は grill-me の領分なので、この skill は使わない。
Learning support coach for communicating in English on GitHub Issues and Pull Requests. Provides structure and stock phrases, then gives hints on the user's own draft instead of writing English for them. Assumes CEFR A2. Use when the user says「英語で返信したい」「英語でPRを書きたい」「この英語の意味を教えて」"english coach", or asks for help writing or reading English on Issues / PRs / OSS.
Control herdr from inside it. Manage workspaces and tabs, split panes, spawn agents, read output, and wait for state changes — all via CLI commands that talk to the running herdr instance over a local unix socket. Use when running inside herdr (HERDR_ENV=1).
日本語の技術文書における論証、演出の抑制、整形の規範。段落単位の再配置・削除・橋渡しで論証の筋を通す編集も扱う。技術ブログ記事、design doc、ポストモーテムを書くとき、推敲するとき、または議論の筋を点検して直すときに使用する。
Append a 日次掘り下げ section to today's AI diary. Run once at the end of the day after all work sessions are complete.
Append a work observation entry to today's AI diary file. Use at the end of any session where files were edited or commands were run.
| name | spec-authoring |
| description | Draft or refine a docs/specs spec from a user goal or rough plan. Use when creating a new spec, turning a plan into acceptance criteria, or updating an existing spec. |
| argument-hint | <goal, rough plan, or docs/specs/spec-file.md> |
Draft or refine a spec under docs/specs/, relative to the project root (jj root).
Follow ~/.docs/specs/_template.md when it exists. If it does not exist, use the same structure.
The user owns and approves the purpose, acceptance criteria, negative requirements, scope limit, and final spec.
Draft, refine, and point out ambiguity. Ask for missing decisions one at a time, but inspect the codebase instead when it can answer the question.
Before declaring the spec settled, verify every AC:
While any AC fails these checks, the spec is not settled and implementation does not start.
Do not create GitHub Issues or docs/tasks. Keep tasks inside the spec file.
