메뉴
Implement one acceptance criterion from a docs/specs spec as a transcription of the settled design. Use when starting implementation work on a spec, or when asked to implement an AC.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
設計や計画の壁打ちインタビュー。候補案、推奨案、選択式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.
SOC 직업 분류 기준
| name | spec-implement |
| description | Implement one acceptance criterion from a docs/specs spec as a transcription of the settled design. Use when starting implementation work on a spec, or when asked to implement an AC. |
| argument-hint | <docs/specs/spec-file.md> [AC-N] |
Implement exactly one AC from the given spec.
If no spec path is provided, ask for it. If no AC is specified, pick the first incomplete AC whose Depends On entries are all done.
Read the entire spec, not just the target AC. Mark the AC as 進行中 in the task list.
Collect transcription context before writing anything: find existing code closest to what this AC touches (same layer, similar feature), and note its naming, error handling, and test style. New code follows these observed patterns.
If an observed pattern appears inferior to a general best practice, present a discussion draft BEFORE starting implementation:
Wait for the user's decision. If the user defers, follow the observed pattern for this AC.
Write a failing test transcribed directly from the AC's 入力 → 結果 line.
Implement in one pass. If a decision the spec does not determine arises mid-implementation, stop. Report it as a spec defect and return to spec-authoring. Do not resolve it inline and keep typing.
Run the narrowest relevant test until green.
Run spec-implementation-check and follow its judgement.
