to-issues

Issue 化

計画や仕様を、個別に実行可能な垂直スライスの Issue に変換します。

このスキルを使う場面

• 計画や PRD を実装チケットに分解する
• 機能を並行作業できる項目に分割する
• AI エージェント（AFK）または人間の開発者（HITL）向けの作業を準備する

このスキルを使わない場面

• PRD をゼロから作成する → to-prd を使用する
• 既存の Issue を評価・分類する → triage を使用する
• 実装チケットを作らずに計画する → task-planning を使用する

基本原則：垂直スライス

各スライスは、あらゆる層（スキーマ、API、UI、テスト）を通る、狭くても完全な経路です。完了したスライスは、それぞれ単独でデモできます。

❌ 水平分割：「データベースのテーブルをすべて追加」→「API エンドポイントをすべて追加」→「UI コンポーネントをすべて追加」 ✅ 垂直分割：「ユーザーがタスクを作成できる」（スキーマ + API + UI + テスト、エンドツーエンド）

Issue の種類

• HITL — 人間の関与が必要：アーキテクチャ上の決定、デザインレビュー、外部アクセス、手動テスト
• AFK — 人間の入力なしで実装・マージが可能（可能な場合はこちらを優先）

プロセス

1. コンテキストを収集する

会話から計画を読み取るか、参照されている Issue を取得します。分解を始める前に、全体の範囲を把握します。

2. コードベースを調査する

Issue の命名には、プロジェクトのドメイン用語集（CONTEXT.md）と語彙を使用します。重複作業を避けるため、現在の状態を把握します。

3. 垂直スライスの草案を作成する

• 各スライスは、ユーザーに価値を提供する、単独で完了可能な単位です
• 各スライスは、関連するすべての層を通ります
• 依存関係に従って順序を付けます（何が先に必要か）
• HITL または AFK のラベルを付けます

4. ユーザーに確認する

公開する前に、以下を確認します。

• スライスの粒度は適切ですか？（大きすぎると見積もりが難しく、小さすぎると変更が頻発します）
• 依存関係の順序は正しいですか？
• 統合または分割すべきスライスはありますか？
• HITL/AFK の分類を変更するものはありますか？

5. トラッカーに公開する

依存関係の順に公開します。標準の Issue テンプレートを使用します。

## Context

[Brief description of what this slice delivers and why it matters]

## Acceptance Criteria

- [ ] [Specific, testable criterion]
- [ ] [Specific, testable criterion]

## Implementation Notes

[Key decisions, constraints, or approach hints if known]

## Type

HITL | AFK

適切なラベルを追加します。カテゴリ（bug/enhancement）と状態（needs-triage または ready-for-agent/ready-for-human）です。

手順

1. タスクのトリガーと期待される出力を特定します。
2. このスキルのワークフロー手順を上から順に実行します。
3. 次の手順に進む前に、出力を検証します。
4. 手順に失敗した場合は、ブロッカーと代替手順を記録します。

例

• 例：まずこのスキルを小さな範囲に適用し、検証に合格してから全範囲に拡大します。

ベストプラクティス

• 出力の再現性と監査可能性を保ちます。
• 広範囲でリスクの高い編集より、小規模で元に戻せる変更を優先します。
• 前提条件を明示的に記録します。

参考資料

• プロジェクト標準：.agent-skills/skill-standardization/SKILL.md
• バリデータースクリプト：.agent-skills/skill-standardization/scripts/validate_skill.sh