22プロジェクトを経て辿り着いた、4つのコマンド
22以上のプロジェクトを並行で回してきた。Slack Bot、OCR パイプライン、AI エージェント、ゲーム、ブログ。規模も技術スタックもバラバラ。
その中で、どのプロジェクトでも繰り返していた4つの動作がある。
- 前回の続きを思い出す
- コードを書く
- 見落としがないか確認する
- 出す
これを Claude Code のコマンドとして抽出したのが workflow-essentials。
4つのコマンド
/ctx → 前回の続きから再開
/devil → 変更をレビュー(品質 + セキュリティ)
/ship → テスト → コミット → デプロイ
/reflect → 学んだことを記録
これだけ。設定ファイルなし、外部サービスなし、DB なし。インストールしたら即使える。
/ctx — 「昨日の続き」問題を解決する
Claude Code のセッションは揮発性。閉じたら全部消える。
/ctx save でセッション終了時に状態を保存し、次回 /ctx で復元する。保存先は .claude/ctx/resume.md の1ファイル。やったこと、変更したファイル、次にやること、未解決の問題。これだけで「えーと、何してたっけ」がなくなる。
/ctx save ← 終了時
/ctx ← 開始時(load がデフォルト)
覚えることが2つしかない。
/devil — 懸念をゼロにするレビュー
コードを書いた後、自分では気づかない問題がある。/devil は変更差分に対して2つの観点からレビューする。
品質: ロジックバグ、エッジケース、パフォーマンス、エラーハンドリング セキュリティ: OWASP Top 10 に基づくチェック(インジェクション、認証、機密情報露出…)
核心は収束原則。懸念が見つかれば修正して再レビュー。また見つかれば修正して再レビュー。これを懸念がゼロになるまで繰り返す。
/devil ← レビューのみ
/devil --fix ← 修正まで自動で
「懸念は潰すたびに減る。ゼロになったら完了」。このルールだけで、レビューの終了条件が明確になる。
/ship — 出荷を5ステップに構造化する
「レビューして、テストして、コミットして、デプロイ」。毎回同じ手順を手で回すのは無駄。
Phase 1: Review — /devil を実行
Phase 2: Fix — 指摘があれば修正
Phase 3: Test — テストスイート実行
Phase 4: Commit — 変更をコミット
Phase 5: Deploy — 本番反映
.claude/ship.yml でテスト・デプロイコマンドをプロジェクトごとに設定できる。設定がなければ Phase 3 と 5 をスキップして、レビュー + コミットだけ。
# .claude/ship.yml
test:
command: "npm test"
required: true
deploy:
command: "vercel --prod"
confirm: true
/ship --dry ならデプロイせずにレビュー + 修正まで。初回はこちらが安心。
/reflect — 未来の自分への投資
セッション中に学んだこと — 踏んだ罠、成功パターン、判断の理由 — を MEMORY.md に記録する。
MEMORY.md は Claude Code が毎セッション自動で読み込むファイル。ここに記録すれば、次回以降の Claude が「前にこういう問題があった」と教えてくれる。
/reflect ← 学びを記録
/reflect --clean ← 古い記録を整理
1回の /reflect の価値は小さい。だが蓄積すると、MEMORY.md がプロジェクト固有の知識ベースになる。同じ罠を二度踏まなくなる。
1コマンドだけ使っても価値がある
全部使う必要はない。
- PR 前のセルフレビューだけなら
/devil - セッション間の引き継ぎだけなら
/ctx - 出荷の自動化だけなら
/ship
段階的に取り入れて、合うものだけ残せばいい。
1日の流れ
朝: /ctx ← 昨日の続きから
[コーディング]
昼: /devil ← 午前の実装をチェック
[修正・追加実装]
夕: /ship ← まとめてリリース
/reflect ← 学びを記録
/ctx save ← 明日の自分へ引き継ぎ
インストール
/plugin marketplace add eris-ths/workflow-essentials
/plugin install workflow-essentials@eris-ths-workflow-essentials
Claude Code を再起動すれば使える。手動なら git clone して claude --plugin-dir で直接読み込みでもOK。
設計思想
このプラグインには意図的に含めなかったものがある。独自の用語体系、外部サービス連携、複雑な設定ファイル、AI ペルソナ。
「Claude Code を使っている人なら、誰でもすぐ使える」 が唯一の設計制約。
22プロジェクトで磨いたワークフローの全体は、もっと複雑で、もっと多くの概念がある。だが汎用部分だけを抽出すると、この4つのコマンドに収束した。
始める。作る。確認する。出す。振り返る。
開発の基本動作は、結局これだけだった。
GitHub: eris-ths/workflow-essentials