メニュー
swbt-daemon の安定した spec page を作成、更新、整理する。Codex が複数の work unit record から参照され得る architecture、protocol、operations の spec を書く、source / use case / work unit との関係を整理する、references を根拠として整理する、置き換え済み spec を archive へ移す、または spec と work unit record のリンクを整えるときに使う。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
swbt-daemon の TDD Test List から 1 item だけを選び、CMake/CTest/just で red、green、必要な refactor を 1 cycle 進める skill。Codex が失敗する C test を追加し、最小実装で通し、refactor-done / refactor-skipped を含む work unit record の TDD status を更新するときに使う。
swbt-daemon の source / use case から観測可能な TDD Test List を作成または更新する skill。Codex が TDD の最初の分析、テストシナリオ、expected behavior、edge case、regression、characterization、hardware-gated item を実装前に洗い出すときに使う。work unit record の起点 / ユースケースから test item を作る。
swbt-daemon の TDD green 後に、観測可能な振る舞いを変えずに小さな構造変更を行う skill。Codex が TDD one cycle の refactor phase、green 後の重複整理、命名改善、責務境界の整理、test fixture の読みやすさ改善、または refactor-done / refactor-skipped の判断を行うときに使う。
CMake、Ninja、CTest、sanitizer preset、work unit record の source / use case / TDD Test List を使う swbt-daemon の TDD orchestration skill。Codex が TDD、ユースケースからの TDD test list 作成、red/green/refactor、green 後の refactor-done / refactor-skipped 判断、tidy-first 判断、Test Desiderata review、C unit test 追加、Switch packet behavior の characterization、protocol/IPC behavior の実装を求められたときに使う。必要に応じて tdd-test-list、tdd-one-cycle、refactor-after-green、tidy-first、test-desiderata-review に分岐する。
swbt-daemon の work unit record を作成、更新、完了する。Codex が source、use case、work unit の範囲定義、関連 spec/docs の参照、TDD list、根拠監査状態、検証結果、実機実行条件、先送り事項、チェックリストを work-units/wip または work-units/complete に記録するときに使う。source には user request、roadmap TODO、journal entry、deferred item、bug、実機観測、根拠監査 finding、既存 spec の未解決事項を含む。
Kent Beck の Test Desiderata に基づいて swbt-daemon の test の価値と trade-off をレビューする skill。Codex が CTest、characterization test、hardware-gated test、TDD で追加した test の品質、脆さ、実機未検証リスクを確認するときに使う。
| name | spec-page |
| description | swbt-daemon の安定した spec page を作成、更新、整理する。Codex が複数の work unit record から参照され得る architecture、protocol、operations の spec を書く、source / use case / work unit との関係を整理する、references を根拠として整理する、置き換え済み spec を archive へ移す、または spec と work unit record のリンクを整えるときに使う。 |
安定した spec page を作成または更新するときに、この skill を使う。
通常は work unit を先に立てる。複数の work unit から参照される設計、protocol、運用判断が必要になった場合だけ、spec page を作成または更新する。
spec page は work queue ではない。source、use case、TDD Test List、検証結果、完了チェックリストは work unit record に置く。work unit、spec、TDD Test List の作成順序は spec/operations/work-unit-spec-tdd-flow.md に従う。
| 目的 | path |
|---|---|
| architecture spec | spec/architecture/ |
| protocol spec | spec/protocols/ |
| operations spec | spec/operations/ |
| 根拠と外部資料 | spec/references/ |
| 置き換え済み spec | spec/archive/ |
| 初期方針と設計背景 | spec/initial/ |
| 未確定の観測 | spec/dev-journal.md |
spec/references/ は規範ではない。実装が従う判断は architecture、protocols、operations のいずれかに置く。
次の場合は spec page を作る。
次の場合は spec page にしない。
spec/dev-journal.md に書く。spec/references/ に書く。spec page には次を含める。
# <spec 名>
## 1. 状態
## 2. 目的
## 3. 適用範囲
## 4. 決定事項
## 5. 根拠
## 6. 関連 work units
## 7. 未解決事項
状態 には current、draft、superseded のいずれかを書く。
superseded の spec は spec/archive/ に移す。
spec page が次を含む場合は source-audit を使う。
根拠は spec/references/、source path、URL、commit、実機ログのいずれかへ辿れるようにする。
spec page と work unit record は相互に辿れるようにする。spec が journal entry から昇格した場合は journal entry を根拠として残す。spec が work unit を生む場合でも、work unit record 側には source と use case を明記する。
work unit record には次を置く。
## 関連 spec / docs
- spec/...
spec page には次を置く。
## 関連 work units
- work-units/...