AgentSkillsCN

verifying-acceptance

核对故事的反馈与验收条件，根据需要创建额外任务，或将用户添加至 assignees 列表，以标记故事已验收完成。适用于在故事完成时需要进行验收确认时使用。

SKILL.md
--- frontmatter
name: verifying-acceptance
description: ストーリーのフィードバックと受け入れ条件を確認し、必要に応じて追加タスクを作成または受け入れ完了としてユーザーをassigneesに追加します。ストーリー完了時の受け入れ確認が必要な場合に使用してください。
layer: feature
argument-hint: "[ストーリーのIssue番号]"

手順

  1. •

    ストーリーのIssue番号を決定する。

    • •引数で指定されている場合、その番号を使用する。
    • •引数が未指定の場合は「ストーリーのIssue番号を指定してください」とユーザーに通知し、処理を終了する。
  2. •

    フィードバック確認を行う。

    • •managing-github スキルの issue-comments.sh でストーリーのコメント一覧を取得する。
    • •managing-github スキルの issue-sub-issues.sh でサブIssue一覧を取得し、最新サブIssue作成日時を特定する。
    • •以下の全条件を満たすコメントを未対応フィードバックとして検出する：
      • •コメントの author_association が OWNER、COLLABORATOR、MEMBER のいずれか
      • •コメントの created_at が最新サブIssue作成日時より後（サブIssueが存在しない場合はすべてのコメントを対象）
      • •コメント内容に改善要望・変更依頼・不備指摘が含まれる（具体的には「〜してほしい」「〜すべき」「〜が足りない」「〜が不足」「〜を追加」「〜を修正」「〜が必要」等の表現）
    • •未対応フィードバックが検出された場合：
      • •各フィードバックの内容を分析し、「フィードバック判断基準」に従って対応方法を判断する。
      • •受け入れ条件の更新が必要な場合、以下の手順で更新する：
        1. •managing-github スキルの issue-get.sh でストーリーIssue本文全体を取得
        2. •本文から「受け入れ条件」セクションを抽出し、フィードバックに基づいて更新
        3. •managing-github スキルの issue-update.sh --body-file で更新した本文全体を再投稿
      • •追加タスクの作成が必要な場合、「追加タスクIssue作成ルール」に従ってタスクIssueを作成し（managing-github スキルの issue-create.sh を使用、--label task オプションを付与）、サブIssueとして登録する（managing-github スキルの sub-issue-add.sh を使用）。
      • •フィードバック対応の完了をストーリーIssueにコメントする（managing-github スキルの issue-add-comment.sh を使用）。
    • •未対応フィードバックが検出されなかった場合は、手順3へ進む。
  3. •

    managing-github スキルでストーリーIssueの情報を取得する。

    • •Issue本文から受け入れ条件（チェックボックス形式 - [ ]）を抽出する。
    • •受け入れ条件が存在しない場合は「受け入れ条件が定義されていません」とユーザーに通知し、処理を終了する。
  4. •

    managing-github スキルの issue-sub-issues.sh でサブIssueの一覧を取得する。

    • •各サブIssueのタイトル、状態（OPEN/CLOSED）、本文を確認する。
  5. •

    実装されたソースコードを確認する。

    • •サブIssueで言及されているファイルや変更内容を確認する。
    • •最近のコミット履歴を確認する（git log コマンド）。
    • •関連するPRがあれば managing-github スキルの pr-get.sh で内容を確認する。
  6. •

    各受け入れ条件について、満たされているか判定する。

    • •完了したサブIssueの実装内容を元に判定する。
    • •ソースコードの変更内容を元に判定する。
    • •受け入れ条件の判定基準に従って評価する。
  7. •

    判定結果に応じて処理を実行する。

    • •満たされていない受け入れ条件がある場合:
      • •満たされていない各条件について、追加タスクを作成する必要があるか検討する。
      • •追加タスクが必要な場合、タスクのIssue本文を「追加タスクIssue作成ルール」に従って生成する。
      • •managing-github スキルの issue-create.sh でIssueを作成する。--label task オプションを付与して task ラベルを自動付与すること。
      • •managing-github スキルの sub-issue-add.sh でストーリーIssueのサブIssueとして登録する。
      • •作成した追加タスクの一覧（タイトル・URL・理由）をユーザーに報告する。
    • •すべての受け入れ条件を満たしている場合:
      • •現在のGitHubユーザー名を取得する（gh api user --jq '.login' コマンド）。
      • •managing-github スキルの issue-update.sh でストーリーIssueにユーザーをassigneeとして追加する（--add-assignee オプション）。
      • •managing-github スキルの issue-add-comment.sh でストーリーIssueに受け入れ完了のコメントを追加する。コメント内容は以下の形式とする：
        code
        ## 受け入れ確認完了

すべての受け入れ条件を満たしていることを確認しました。

### 確認内容
- [確認した受け入れ条件1]
- [確認した受け入れ条件2]
...

受け入れ完了として、ユーザーをassigneesに追加しました。
      • •受け入れ完了をユーザーに報告する。

フィードバック判断基準

フィードバック内容を以下の基準で分類する：

  1. •

    受け入れ条件の更新が必要:

    • •ストーリーの要件や仕様変更を含むフィードバック
    • •既存の受け入れ条件の修正や追加が求められる内容
    • •例: 「認証機能はOAuth2.0に対応すべき」「パフォーマンス要件として5秒以内のレスポンスが必要」
  2. •

    追加タスクの作成が必要:

    • •実装上の不備や改善点の指摘
    • •新しいタスクとして独立して対応可能な内容
    • •例: 「エラーハンドリングが不足している」「テストケースを追加してほしい」「READMEを更新してほしい」
  3. •

    両方が必要:

    • •要件変更（受け入れ条件更新）と、それに対応する実装（追加タスク）の両方が必要な場合

受け入れ条件判定基準

受け入れ条件が満たされているかを判定する際、以下の基準を用いる：

  1. •

    機能の実装確認

    • •サブIssueまたはコミットで該当機能が実装されていることを確認する。
    • •関連するソースコードファイルを確認し、条件に対応する実装が存在するかを検証する。
  2. •

    テストの実装確認

    • •受け入れ条件に「テスト」が含まれる場合、テストコードの存在を確認する。
    • •テストファイルの内容を確認し、条件に対応するテストケースが存在するかを検証する。
  3. •

    ドキュメントの更新確認

    • •受け入れ条件に「ドキュメント」「README」等が含まれる場合、該当ファイルの更新を確認する。
  4. •

    実装の完了状態確認

    • •サブIssueがCLOSED状態であれば、実装完了とみなす。
    • •ただし、受け入れ条件で求められている内容がサブIssueに含まれているかを確認する。
  5. •

    不明な場合の取り扱い

    • •判定が困難な場合は、保守的に「満たされていない」と判断する。
    • •ユーザーに確認を求めることも検討する。

追加タスクIssue作成ルール

タイトル

具体的な作業内容を動詞で開始する（例: 「認証機能のテストを追加する」「READMEを更新する」）。

本文構成

概要

このタスクで実装する内容を簡潔に説明する。

親ストーリー

#[ストーリーのIssue番号] へのリンクを記載する。

背景

このタスクが必要な理由を説明する（どの受け入れ条件が満たされていないかを明記）。

実装内容

  • •実装する機能や作業の詳細を箇条書きで記載する。
  • •主な変更対象のファイルやディレクトリがわかる場合は記載する。

完了条件

  • • 具体的な完了基準をチェックボックス形式で列挙する。

依存関係

依存する他タスクがあれば、Issue番号を記載する（なければ「なし（並列着手可能）」と記載）。

注意点

  • •受け入れ条件の判定は、実装内容とソースコードを総合的に評価して行うこと。
  • •追加タスクを作成する際は、重複したタスクを作成しないよう既存のサブIssueを確認すること。
  • •ユーザーをassigneesに追加する際は、必ず現在のGitHubユーザー名を取得して使用すること。
  • •受け入れ完了のコメントは、確認した受け入れ条件を具体的に列挙すること。