do-work

Do-Work スキル

タスクの記録と処理を行うための統一されたエントリーポイントです。

アクション：

• do：新しいタスク／リクエストを記録します → UR フォルダー（入力をそのまま保存）と REQ ファイル（キュー項目）を必ずセットで作成し、その後、網羅性を検証します
• work：保留中のリクエストを処理します → 計画を作成し（計画の検証を含む）、調査、構築、テストを行います
• verify：記録された REQ を元の入力と照合します → 網羅性を確認し、自動修正します（記録後にも自動で実行されます）
• cleanup：アーカイブを整理します → 単独の REQ を UR フォルダーに移動し、完了した UR をクローズします

基本コンセプト： do アクションでは、必ず UR フォルダー（元の入力を保持）と REQ ファイル（キュー項目）の両方が作成されます。各 REQ は user_request フロントマターを介して UR にリンクされます。このペアリングは、単純なリクエストでも複雑なリクエストでも必須です。

記録 ≠ 実行。 do アクションはリクエストを記録します。work アクションはそれを実行します。この 2 つの操作は厳密に分離されています。do アクションによるファイルの書き込みと報告が完了したら、停止してください。キューの処理を始めたり、実装に着手したり、気を利かせて work アクションに移行したりしてはいけません。実行するタイミングは常にユーザーが決定します。唯一の例外は、ユーザーが同じ呼び出しで「これを追加してから実行して」や「これを記録して作業を開始して」のように明示的に指示した場合です。

ルーティングの判断

ステップ 1：入力を解析する

「do work」に続く内容を確認します。

次のパターンを順番に確認してください。最初に一致したものを適用します。

優先度	パターン	例	ルート
1	空またはコマンドのみ	do work	→ 質問：「作業ループを開始しますか？」
2	アクション動詞のみ	do work run、do work go、do work start	→ work
3	検証キーワード	do work verify、do work check、do work evaluate	→ verify
4	クリーンアップキーワード	do work cleanup、do work tidy、do work consolidate	→ cleanup
5	バージョンキーワード	do work version、do work update、do work check for updates	→ version
6	変更履歴キーワード	do work changelog、do work release notes、do work what's new、do work what's changed、do work updates、do work history	→ version
7	説明的な内容	do work add dark mode、do work [meeting notes]	→ do

ステップ 2：ペイロードを保持する

重要なルール：ユーザーの内容を決して失わないでください。

単語のみのルール：単語 1 つの場合、既知のキーワードか曖昧な語のどちらかであり、「説明的な内容」ではありません。

• ルーティングテーブル内のキーワードに一致する（例：「version」、「verify」、「cleanup」）→ そのアクションに直接ルーティングします。
• どのキーワードにも一致しない（例：「refactor」、「optimize」）→ 曖昧です。「『{word}』を新しいリクエストとして追加しますか。それとも、別の意味でしたか？」と尋ねます。

入力が明らかに説明的な場合（複数の単語、文章、機能リクエストなど）に限り、do にルーティングしてください。

ルーティングが本当に不明確で、かつ複数語の内容が入力されている場合：

• do（タスクの追加）をデフォルトにします
• $ARGUMENTS を保持します
• 本当に曖昧な場合は、「これをリクエストとして追加しますか。それとも作業ループを開始しますか？」と尋ねます
• ユーザーが「add」または「work」だけで返答した場合 → 元の内容で続行します

アクション動詞（→ Work）

これらは「キューを処理する」ことを示します： run、go、start、begin、work、process、execute、build、continue、resume

検証動詞（→ Verify）

これらは「リクエストの品質を確認する」ことを示します： verify、check、evaluate、review requests、review reqs、audit

注：「check」は、単独で使われる場合、または対象とともに使われる場合（例：「do work check UR-003」）に限り verify にルーティングされます。説明的な内容に続く場合は do にルーティングされます（例：「do work check if the button works」→ do）。

クリーンアップ動詞（→ Cleanup）

これらは「アーカイブを整理統合する」ことを示します： cleanup、clean up、tidy、consolidate、organize archive、fix archive

変更履歴動詞（→ Version）

これらは「リリースノートを表示する」ことを示します： changelog、release notes、what's new、what's changed、updates、history

注：「updates」（複数形）は変更履歴の表示にルーティングされます。「update」（単数形）は更新チェックにルーティングされます。どちらも version アクションで処理されます。

内容のシグナル（→ Do）

これらは「新しいタスクを追加する」ことを示します：

• 1 つの動詞を超える説明的なテキスト
• 機能リクエスト、バグ報告、アイデア
• スクリーンショットまたはコンテキスト
• 「add」、「create」、「I need」、「we should」

例

Work にルーティング

• do work → 「キューの処理を開始しますか？」（確認）
• do work run → すぐに work アクションを開始します
• do work go → すぐに work アクションを開始します

Verify にルーティング

• do work verify → 最新の UR の REQ を評価します
• do work verify UR-003 → 指定された UR を評価します
• do work check REQ-018 → REQ-018 が属する UR を評価します
• do work evaluate → 最新の UR の REQ を評価します
• do work review requests → 最新の UR の REQ を評価します

Cleanup にルーティング

• do work cleanup → アーカイブを整理統合し、完了した UR をクローズします
• do work tidy → cleanup と同じです
• do work consolidate → cleanup と同じです

Changelog にルーティング（Version 経由）

• do work changelog → 変更履歴を表示します（最新の項目が末尾）
• do work release notes → changelog と同じです
• do work what's new → changelog と同じです
• do work updates → changelog と同じです
• do work history → changelog と同じです

Do にルーティング

• do work add dark mode → REQ ファイルと UR フォルダーを作成します
• do work the button is broken → REQ ファイルと UR フォルダーを作成します
• do work [400 words] → 入力内容を一字一句そのまま含む REQ ファイルと UR フォルダーを作成します

ペイロード保持ルール

内容が提供されていて、確認が必要な場合：

1. $ARGUMENTS を失わないでください - ペイロード全体をコンテキスト内に保持します
2. 簡潔な質問をします：「これをリクエストとして追加しますか。それとも作業ループを開始しますか？」
3. 短い返答を受け付けます：ユーザーが「add」または「work」だけを返答します
4. 元の内容で続行します：保存した引数に選択されたアクションを適用します
5. 内容の再貼り付けをユーザーに求めないでください

これにより、2 フェーズコミットパターンを実現できます：

1. 意図を示すペイロードを取得する
2. アクションを確認する

アクションの参照

詳細な手順については、以下を参照してください。

• do action - リクエストの取り込み
• work action - キュー処理
• verify-request action - 取り込んだリクエストの網羅性検証（取り込み後、または手動で実行）
• verify-plan action - 計画の網羅性検証（work actionでの計画後に実行）
• cleanup action - アーカイブの統合とURのクローズ
• version action - バージョン、更新、変更履歴