azure-devops-create-work-item

Azure DevOps 作業項目の作成

断片的なコンテキストを、公式の Azure Boards 作業項目モデルに基づくローカルの Azure DevOps 作業項目パケットにまとめます。

2026年5月9日、Microsoft Learn の「作業項目について」と「作業項目の種類」、Azure Boards の Scrum ワークフロー、Azure Boards の Agile ワークフロー、Azure Boards でのバグの定義、記録、トリアージ、管理、およびプロセスの選択に関するページと照合して検証しました。ガイダンスを調整した文章の書き方は、2026年8月19日に Google の開発者向けドキュメントのスタイルガイドに照らして確認しました。

まず、できないことを明確にする

このスキルで作成するのはローカルのパケットです。ユーザーが別途依頼しない限り、Azure DevOps のライブ作業項目を作成または更新することはありません。

このスキルで得意なこと：

• 作業コンテキストを抽出し、Azure Boards の主要な作業項目の種類を1つ選ぶ
• 呼び出し元の現在のディレクトリに、決定性のあるフォルダーを作成する
• コピーして貼り付けられる work-item.md と、補足成果物を生成する
• 提供または確認できたプロジェクトのプロセスを使用し、種類とプロセスが不明な場合は Product Backlog Item にフォールバックする
• プロジェクト内で実行された場合は、関連するコードスニペットを提示するために周辺のリポジトリを調査する
• メインのドラフトを標準フィールドスキーマに沿わせ、Bug には Reproduction Steps を追加する
• 技術職と非技術職の両方が読みやすい文章にする
• Azure Boards のセマンティクス、パケットスキーマ、ローカルの用語、ロケールを覆さずに、読者を優先するテクニカルライティングのルールを適用する
• 手動 QA のセクションを、経験豊富なテスターが書いたような、リスクに基づく的を絞ったシナリオとして構成する
• 独自のチケット形式ではなく、公式の Azure Boards 作業項目プリミティブを使用する

判断フロー

1. メモ、チャットのコンテキスト、または大まかな要件から、ローカルで Azure DevOps に登録できるドラフトを作成したい場合は、このスキルを使用します。
2. ブラウザー、REST API、または Azure CLI を通じて Azure DevOps に直接作業項目を作成したい場合は、ここで中止し、自動化または API のワークフローに切り替えます。
3. 単独の Azure DevOps wiki ページや一般的なドキュメントを作成したい場合は、ドキュメント作成のワークフローに切り替えます。このスキルでドキュメントのスタイルを適用するのは、ローカルの作業項目パケット内に限られます。
4. 種類が指定されていない場合は、提供または確認できたプロジェクトのプロセスに基づいて種類を選びます。種類もプロセスも不明な場合は、Scrum の Product Backlog Item にフォールバックします。
5. 種類が明示されている場合は、対応するテンプレートを使用し、判明しているプロセスとの不整合があれば、黙って別の種類に置き換えるのではなく、その不整合を明示します。
6. 種類またはプロセスに関する曖昧さは references/official-primitives.md を参照して解決します。残る不確実性によってパケットが大きく変わる場合に限り、簡潔な質問をします。
7. 現在のディレクトリがプロジェクトまたは git リポジトリの場合は、ドラフトの確定前にコードベースを調査します。
8. 問題や成果を説明するにはコンテキストが不十分な場合は、ドラフトの作成前に不足している情報を尋ねます。

既定の保存先ルール

ユーザーが保存先を指定しない場合は、現在の作業ディレクトリにパケットを作成します。隠しキャッシュ、テンポラリディレクトリ、またはホームフォルダーの既定の保存先には保存しないでください。

生成されるパケットのレイアウト：

<current-working-directory>/azure-devops-work-item-<type>-<slug>-<timestamp>/
  work-item.md
  context.md
  sources.md
  metadata.json

クイックリファレンス

タスク	コマンド	理由
現在のディレクトリに既定の PBI パケットを作成する	python3 scripts/create_work_item_packet.py --title "Restore team login after token expiry"	コマンドと同じ場所に Product Backlog Item パケットを作成します
保存済みのメモからパケットを作成する	python3 scripts/create_work_item_packet.py --type bug --title "Checkout button freezes on Safari" --context-file ./notes/checkout-bug.md	既存のメモをもとに context.md の内容を用意します
明示したディレクトリにパケットを保存する	python3 scripts/create_work_item_packet.py --type user-story --title "Resend invite from team page" --save-root ./work-items	選択した表示可能なフォルダー内にパケットを保存します
パケットのワークフローを最初から最後まで確認する	python3 scripts/probe_create_work_item_packet.py	スキャフォールドコマンドが期待どおりの成果物を作成することを検証します
種類の選択と記述ルールを確認する	references/official-primitives.md を読む	ドラフトを Azure Boards のセマンティクスに沿ったものにします

運用ルール

1. ユーザーが種類を指定していない場合でも、提示または確認できたプロジェクトのプロセスに従います。たとえば、アジャイルにおけるユーザーニーズは、スクラムの PBI ではなく User Story に対応します。種類とプロセスの両方が不明な場合に限り、デフォルトでスクラムの Product Backlog Item を使用します。
2. まずコンテキストを抽出します。work-item.md をより簡潔にする場合でも、元の資料は context.md に記録します。
3. 主となる種類は、Product Backlog Item、Epic、Feature、User Story、Task、Issue、Bug のうち1つだけを選びます。
4. ユーザーが別の形式を明示的に求めない限り、ヘルパーのパケット構成と主要なセクションラベルおよび順序を維持します。デフォルトでは、詳細な **Test Scenario** セクション以外に #、##、### の見出しを使わず、太字のセクションラベルを使用します。
5. バグ以外のドラフトでは、次の表示スキーマを使用します。
   • **Title**
   • **Problem**
   • **Action**
   • **Outcome**
   • **Acceptance Criteria**
   • **Developer Notes**
   • **Test Scenario**
6. Bug の場合は、**Problem** の直後に **Reproduction Steps** を追加します。QA、プロダクト担当者、または開発者が実行できる、簡潔な番号付き手順にします。
7. **Test Scenario** に手動 QA の内容を作成する際は、references/output-packet.md の Manual QA Scenario Contract に従います。リスクに基づくシナリオ、Test environment notes ブロック、テスト対象の UI、API、またはバックエンドに適した手順、観測可能な期待結果、動作に焦点を当てたタイトル、実際に役立つ検証上の落とし穴を含めます。ステージングに開発者のサポートが本当に必要な場合に限り、(needs dev support) と記載します。デフォルトでは NZ 英語を使用し、ユーザーまたはプロジェクトのロケールが指定されている場合はそちらに従います。
8. 種類ごとのテンプレートは、内容の指針として扱い、固定の文言やシナリオ数の割り当てとして扱いません。パケットのスキーマは維持しつつ、実際の作業に合わせて、セクション内の文言や形式、詳細度を調整します。
9. 補足情報、前提、元のメモ、引用した資料はメインの作業項目ドラフトではなく、context.md に記載します。
10. 幅広い読者に向けて記述します。平易な言葉を優先し、ビジネス上の影響を説明し、実装の詳細は依頼内容を実質的に変える場合に限って含めます。
11. パケットの文章には references/writing-style.md を適用します。調整した Google スタイルの優先事項を適用する前に、Azure の固定セクションラベルと順序、プロジェクト用語、指定されたロケール、正確なリテラルを維持します。
12. セキュリティ、アップグレード、コンプライアンス、保守、依存関係に関する作業でも、常に Task と決めつけず、同じ種類とプロセスの優先順位に従います。元のコンテキストで裏付けられる場合は、SECURITY:、MAINTENANCE:、COMPLIANCE: など、タイトルに直接付けられた接頭辞を維持します。
13. リポジトリ内で実行する場合、work-item.md を仕上げる前にコードベースを調査します。

• git status --short、rg --files、パッケージマニフェスト、ルーティングファイル、サービスフォルダー、テスト、関連するドキュメントを確認し、プロジェクトの構成と関連する可能性の高いモジュールを特定します。
• 作業項目のタイトル、症状、UI ラベル、API 名、エンティティ、エラー、関連しそうなファイル名に含まれるドメイン用語を検索します。
• 影響を受ける経路を把握するために必要な、最小限の関連ファイルを読みます。
• 実装またはトリアージに役立つファイル参照と短いコード断片を、必要な数だけ簡潔に追加します。ゼロでもかまいません。不要な内容は加えません。
• 長いコード断片、調査メモ、採用しなかった手がかりは context.md に記載します。
• 調査を行った証明だけを目的として、コード断片を捏造したり、無関係なコードを含めたりしません。

Type Contract

• Product Backlog Item：Scrum のバックログ作業に使用します。種類やプロセスが不明な場合のフォールバックとしても使用します。templates/product-backlog-item-template.md を使用してください。
• Epic：複数の機能をまとめる、大規模なシナリオや取り組みに使用します。
• Feature：ユーザーまたはビジネスに価値をもたらす具体的な機能に使用します。templates/feature-template.md を使用してください。
• User Story：実装方法を指定せずにユーザーのニーズを説明する、「誰が／何を／なぜ」の形式の記述に使用します。templates/user-story-template.md を使用してください。
• Task：スプリント規模の実行作業に使用します。templates/task-template.md を使用してください。
• Issue：作業の進行を遅らせたり妨げたりする可能性がある、ブロッカーまたはコード以外のプロジェクト課題に使用します。templates/issue-template.md を使用してください。
• Bug：再現可能な動作を伴うコードの不具合に使用します。templates/bug-template.md を使用し、Reproduction Steps を含めてください。

Recommended Workflow

1. ソースのコンテキストを読み、中心となる問題、対象者、望ましい成果を抽出します。
2. 呼び出し元がリポジトリ内にいる場合は、コードベースを調査し、関連するファイルパス、関数、設定、テスト、短いコードスニペットを収集します。
3. references/official-primitives.md を参照し、最適な作業項目の種類を選択します。
4. フォールバックの PBI を作成するには、呼び出し元の現在のディレクトリで python3 scripts/create_work_item_packet.py --title "<title>" を実行します。プロセスが判明している場合は、--type <type> と --process <process> の両方を渡してください。--process はメタデータを記録するもので、種類を推測するものではありません。メモがすでにディスク上にある場合は、--context-file を追加します。プロジェクトの種類がサポートされていない場合は、未対応のフラグやマッピングがネイティブに使えると主張せず、ヘルパーの制限を報告します。
5. 選択したテンプレート、references/writing-style.md、および references/output-packet.md のパケットルールに従って work-item.md を記入します。**Test Scenario** に手動 QA シナリオが含まれる場合は、Manual QA Scenario Contract も適用します。
6. 最終ファイルは簡潔で平易な内容にし、Azure DevOps にすぐ貼り付けられる状態にします。ユーザーが明示的に求めない限り、トップレベルのセクションを追加しないでください。

Sources and maintenance

ローカルパケットの境界、ソースの忠実性、ヘルパーの契約を安定して維持してください。種類の意味や手順が不十分、古い、または矛盾している場合は、関連する Microsoft Learn のドキュメント、または提供されたプロジェクトのプロセス定義を参照してください。日常的にウェブを閲覧する必要はありません。制限を報告し、サンプルパケットまたはリグレッションケースを添えて、情報源に基づく修正案を提示してください。メンテナンスが対象範囲に含まれる場合に限り、正規のスキルを変更してください。インストール済みのコピーを黙って更新したり、稼働中の Azure DevOps に変更を加えたりしないでください。

Reading Guide

Need	Read
Azure Boards の公式な種類の意味とプロセス間の注意事項	references/official-primitives.md
対象者が混在するフィールド向けの文章、用語、手順、リンク、アクセシビリティ、スタイルの優先順位	references/writing-style.md
パケットのレイアウト、セクションの記述ルール、Manual QA Scenario Contract、現在のディレクトリの動作	references/output-packet.md
失敗パターンと分類上の落とし穴	references/gotchas.md
Product Backlog Item テンプレート	templates/product-backlog-item-template.md
Epic テンプレート	templates/epic-template.md
Feature テンプレート	templates/feature-template.md
User Story テンプレート	templates/user-story-template.md
Task テンプレート	templates/task-template.md
Issue テンプレート	templates/issue-template.md
Bug テンプレート	templates/bug-template.md

注意点

1. このスキルが作成するのはローカルのパケットであり、Azure DevOps のライブアイテムではありません。
2. Product Backlog Item、Feature、User Story、Task は相互に置き換えられるものではありません。PBI はデフォルトの Scrum バックログアイテム、Feature は成果物となる機能をまとめる、または位置づけるもの、User Story は Agile プロセスで明示的に使われる表現、Task は実行作業を記録するものです。
3. Bug はコードの不具合を意味します。不具合のある動作を伴わないブロッカーや依存関係の場合は、代わりに Issue を使用してください。
4. Azure DevOps の作業項目の種類はプロセスによって異なります。Basic、Agile、Scrum、CMMI、またはカスタムプロセスについて判明している情報を使い、マッピングを確定できない場合にのみ確認してください。
5. メインの作業項目ドラフトでは、マークアップを控えめにしてください。太字のセクションラベルを使い、見出し構文は避けてください。
6. バグには、シンプルな番号付き手順を記載した **Reproduction Steps** セクションが必要です。コンテキストに詳細がない場合は、詳細を尋ねるか、context.md に不足している旨を記載してください。
7. ビジネスへの影響をエンジニアリングの詳細に埋もれさせないでください。対象読者にさまざまな人が含まれる場合、最初の短いセクションを読めば、その項目が重要である理由を理解できるようにしてください。
8. 機密性の高い環境名、URL、顧客名、システム識別子を作り出さないでください。ユーザーが提供したコンテキストにない詳細は、伏せるか一般化してください。
9. コードスニペットは根拠として使い、埋め草にしないでください。実装箇所、不具合の発生源、テスト対象、設定依存関係、またはロールアウト上の懸念を示す場合にのみ含めてください。
10. **Test Scenario** を網羅的な組み合わせ表にしないでください。手動 QA では、正常系と変更によって実際に生じるリスクをカバーしてください。
11. 単独の wiki ページにはこのスキルを使用しないでください。調整されたドキュメントスタイルは、作業項目のパケットにのみ適用されます。