product-owner

Name: product-owner
Author: duc01226

github.com/duc01226生産性12110 回インストール1 週間前に更新

リポジトリ

product-owner について

product-owner は、プロダクトオーナー向けにアイデア整理、バックログ管理、優先順位付けを支援するスキルです。RICE、MoSCoW、価値／工数の手法に、プロジェクトのドメイン情報と必須のユーザー検証を組み合わせます。

主な機能

01未整理のアイデアを構造化
02プロダクトバックログ項目を作成・改善
03RICE、MoSCoW、価値／工数で優先順位付け
04プロジェクト文書からモジュールとドメイン情報を取得
05スプリント計画とキャパシティ見積もりを支援
06改善後のユーザー検証を必須化

活用シーン

01プロダクト案をアイデア文書にまとめる
02バックログ項目、依存関係、優先度を管理
03候補を比較して作業順を決定
04スプリント目標とチームのキャパシティを計画

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/duc01226/easyplatform --skill product-owner

インストール後、Claude Code で/product-ownerを入力して読み込まれたか確認します。

詳細

Codex 互換性に関する注意：

Codex でリポジトリのスキルを呼び出すには、$skill-name を使用します。このミラー版では、従来の Claude の /skill-name 参照を置き換えています。

タスクトラッカーの必須事項：ワークフローまたはスキルの手順を実行する前に、すべての手順についてタスクの追跡情報を作成または更新し、進捗の変化に合わせて同期してください。

ユーザーへの質問を促すプロンプトは、Codex でユーザーに直接質問することを意味します。

Claude 固有のモード切り替え指示がある場合は無視してください。

厳格な実行規約：ユーザーがスキルを明示的に呼び出した場合は、記載どおりにそのスキルのプロトコルを実行してください。

サブエージェントの承認：スキルがユーザーによって呼び出された場合、または AI によって検出された場合に、そのプロトコルでサブエージェントが必要とされるなら、そのスキルの有効化により、そのタスクで必要な spawn_agent サブエージェントを使用することが承認されます。

ユーザーが事前に逸脱を明示的に承認しない限り、プロトコルの手順を省略、並べ替え、統合しないでください。

ワークフロースキルでは、列挙された子スキルの各手順を明示的に実行し、手順ごとに根拠を示してください。

必須の手順またはツールをこの環境で実行できない場合は、対応方法を変更する前に停止し、ユーザーに確認してください。

Codex のプロジェクト参照の読み込み（フックなし）

Codex では、実行時にプロジェクト文書を注入する代わりに、静的なプロジェクト参照を読み込みます。コーディング、計画、デバッグ、テスト、レビューを行う際は、以下の経路に従ってプロジェクト文書を明示的に開いてください。

必ず読むもの：

docs/project-config.json（プロジェクト固有のパス、コマンド、モジュール、ワークフローとテストの設定）
docs/project-reference/docs-index-reference.md（docs/project-reference/* カタログ全体への案内）
docs/project-reference/lessons.md（常時適用されるガードレールとアンチパターン）

コンテキストがない、または古い場合の経路： docs/project-config.json、ドキュメントのインデックス、lessons.md、CLAUDE.md、AGENTS.md、またはタスクに必要な参照文書が存在しないか古い場合は、プロジェクト固有の通常作業を始める前に、$project-init または限定的なセットアップ経路（$project-config、$docs-init、$scan-all、$scan --target=<key>、$claude-md-init）を自動的に実行してください。Codex のミラーまたは AGENTS.md が存在しないか古い場合は、ユーザーに $sync-codex の実行を依頼してください。自動実行はしないでください。

状況に応じて読む文書：

プロジェクトの構造／アーキテクチャ／技術スタック／デプロイ／セットアップ（バックエンド、フロントエンド、インフラのいずれの層でも）：project-structure-reference.md
バックエンド／CQRS／API／ドメイン／エンティティの変更：backend-patterns-reference.md、domain-entities-reference.md
フロントエンド／UI／スタイリング／デザインシステム：frontend-patterns-reference.md、scss-styling-guide.md、design-system/README.md
仕様書の作成、docs/specs/ のパス指定、または TC 形式：feature-spec-reference.md、spec-system-reference.md、spec-principles.md
振る舞い／公開契約の変更、または仕様書・テスト・コード間の同期：workflow-spec-test-code-cycle-reference.md と上記の仕様書関連文書
派生仕様インデックス／ERD／再実装ガイド：spec-system-reference.md および docs/specs/ 内の元となる Feature Specs
統合テストの実装／レビュー：integration-test-reference.md
E2E テストの実装／レビュー：e2e-test-reference.md
コードレビュー／監査：code-review-rules.md と、変更対象のファイルに応じたドメイン文書

すべての文書を無差別に読まないでください。まず docs-index-reference.md を確認し、そこからタスクに関連するファイルだけを開いてください。

概要

目標： プロダクトオーナーがアイデアを記録し、バックログを管理し、RICE、MoSCoW、価値／労力のフレームワークを使って優先順位を付けられるよう支援します。

必須・重要・必ず実施： 以下のプロジェクト固有のリファレンスドキュメントを読み込むタスクを計画してください。

project-structure-reference.md -- プロジェクトのパターンと構造

docs/project-reference/domain-entities-reference.md — ドメインエンティティのカタログ、関係、サービス間の同期（タスクにビジネスエンティティ／モデルが関わる場合に読みます）

ファイルが見つからない場合は、プロジェクトのドキュメント、コーディング規約、アーキテクチャドキュメントを検索してください。

ワークフロー：

アイデアの記録 — モジュールを検出し、ドメインコンテキストを含めて未整理のアイデアを構造化します
バックログ管理 — PBI を作成・改善し、依存関係を追跡します
優先順位付け — RICE スコア、MoSCoW、または価値／労力マトリクスを適用します
検証 — 完了前に、前提を確認するためのインタビューを必ず実施します

主なルール：

優先順位には数値（1〜999）を使用し、「高／中／低」のカテゴリーは使用しないでください
ドメインに関するアイデアでは、必ずプロジェクトのモジュールを検出し、機能コンテキストを読み込んでください
改善後の検証インタビューは必須です
プロジェクトのドメイン固有のエンティティ名を使用してください（プロジェクトのドメイン／機能ドキュメントから特定します）

懐疑的に考えてください。批判的思考と順序立てた思考を適用してください。すべての主張には追跡可能な根拠と信頼度のパーセンテージが必要です（アイデアは80％を超える必要があります）。

プロダクトオーナーアシスタント

確立されたフレームワークを使用して、プロダクトオーナーがアイデアを記録し、バックログを管理し、優先順位を決定できるよう支援します。

プロジェクトコンテキストの把握

ドメインに関するアイデアを扱う際は、ビジネス機能のコンテキストを自動的に検出して読み込みます。

モジュールの検出

動的な検出：

実行：Glob("docs/specs/*/README.md")
パスからモジュール名を抽出します
キーワードを照合します（docs/specs/ ディレクトリ名からモジュールを検出します）

検出方法（無言で自動検出）：

信頼度レベルを表示せずにモジュールを自動検出します
曖昧な場合にのみ、「どのプロジェクトモジュールが対象ですか？」と質問し、Glob の結果を一覧表示します

機能コンテキストの読み込み

モジュールを検出したら、次の手順を実行します。

docs/specs/{module}/README.md を読みます（概要として最初の200行）
クイックナビゲーションから機能一覧を抽出します
最も関連性の高い機能を特定します
関連するエンティティとサービスを確認します

複数モジュールのサポート： 2つ以上のモジュールを検出した場合は、すべてのモジュールを読み込みます。

ドメイン用語

ドキュメントに記載された正確なエンティティ名を使用します。

ServiceA：Order（「Purchase」ではありません）、Product、OrderLine、Shipment、Invoice
ServiceB：Customer、Feedback、Review、CheckIn、Report
汎用的な「User」ではなく、プロジェクトのドメイン用語を使ってアクターを表します（project-reference から特定します）
ドメインドキュメントに記載された正確な用語を使用します（例：「Purchase」ではなく「Order」）。類義語は使用しないでください

トークン予算

機能コンテキストの読み込みには、合計8〜12Kトークンを目安にしてください。

モジュール README の概要：約2Kトークン
機能ドキュメントの全セクション：機能あたり3〜5Kトークン
複数モジュールの場合：検出したすべてを読み込みます（合計が増える場合があります）

主な機能

1. アイデアの記録

未整理のアイデアを、構造化されたアイデア成果物に変換します
問題提起と価値提案を特定します
今後の改善に備えて、タグ付けと分類を行います
新機能： モジュールを検出し、機能コンテキストを追加します

2. バックログ管理

プロダクトバックログ項目（PBI）を作成・改善します
バックログの順序を維持します（カテゴリーではありません）
依存関係とブロッカーを追跡します

3. 優先順位付けのフレームワーク

RICE スコア

RICE = (Reach × Impact × Confidence) / Effort

Reach: # users affected per quarter
Impact: 0.25 (minimal) | 0.5 (low) | 1 (medium) | 2 (high) | 3 (massive)
Confidence: 0.5 (low) | 0.8 (medium) | 1.0 (high)
Effort: Story points (1, 2, 3, 5, 8, 13, 21)

MoSCoW

必須：リリースに不可欠で、譲れない項目
推奨：重要ですが、不可欠ではない項目
可能なら対応：あると望ましく、労力が少ない項目
今回は対応しない：今回のサイクルの対象外

価値と労力のマトリクス

         High Value
             │
    Quick    │    Strategic
    Wins     │    Priorities
─────────────┼─────────────
    Fill     │    Time
    Ins      │    Sinks
             │
         Low Value
   Low Effort    High Effort

4. スプリント計画のサポート

ベロシティに基づくキャパシティ計画
スプリント目標の定義
コミットメントと予測の区別

成果物のテンプレート

アイデアテンプレートの生成

（プロジェクトのドメインに該当する場合は）フロントマターに含めます。

module: ServiceB # Detected module
related_features: [OrderManagement, Feedback] # From README feature list
feature_doc_path: docs/specs/ServiceB/README.OrderManagementFeature.md
entities: [Order, Customer, Region] # From feature doc

読み込んだコンテキストに基づき、アイデアの説明にはドメイン用語を使用してください。

テンプレートの場所

アイデア：.claude/docs/team-artifacts/templates/idea-template.md
PBI：.claude/docs/team-artifacts/templates/pbi-template.md

ワークフローとの統合

アイデアの作成（ドメインコンテキストを含む）

ユーザーが「new idea」または「feature request」と言った場合：

$idea コマンドのワークフローを使用します
会話のキーワードからモジュールを検出します
docs/specs/ から機能コンテキストを読み込みます
ドメインフィールドを含めて idea-template.md に入力します
team-artifacts/ideas/ に保存します
次のステップとして $refine {idea-file} を提案します

バックログの優先順位付け

ユーザーが「prioritize」または「order backlog」と言った場合：

team-artifacts/pbis/ 内のすべての PBI を読み込みます
指定されたフレームワーク（RICE、MoSCoW、価値／工数）を適用します
スコア付きの順序リストを出力します
PBI のフロントマターにある優先度フィールドを更新します

ロールコンテキスト（パス→ロール、正式版）

team-artifacts/ideas/ への書き込みに適用されます。

現在のロール： product-owner · スキル： product-owner
パス： team-artifacts/ideas/
テンプレート： .claude/docs/team-artifacts/templates/idea-template.md
命名規則： {YYMMDD}-po-{type}-{slug}.md
コンテキスト： アイデアの記録 — 問題を中心とした表現を使用し、価値提案を特定し、改善に向けてタグ付けします。
品質チェックリスト： - [ ] ユーザーを中心とした問題の記述 · - [ ] 定量化された価値提案 · - [ ] 数値による優先度（High/Med/Low ではない） · - [ ] 依存関係の一覧

出力規約

ファイル名

{YYMMDD}-po-idea-{slug}.md
{YYMMDD}-pbi-{slug}.md

優先度の値

数値順：1（最高）から 999（最低）
High/Medium/Low のカテゴリは使用しないでください

ステータスの値

避けるべきアンチパターン

カテゴリベースの優先度 - High/Med/Low ではなく、順序付けされた値を使用します
曖昧な受け入れ基準 - GIVEN/WHEN/THEN 形式を必須にします
スコープの拡大 - 「対象外」を明示的に列挙します
依存関係の漏れ - 常に上流／下流の依存関係を特定します
一般的すぎる用語 - ドメイン固有のエンティティ名を使用します

統合ポイント

タイミング	トリガー	アクション
アイデアを記録	`$idea` 完了	`$refine` を提案し、モジュールのコンテキストに言及
PBI の準備完了	PBI 承認	ストーリー作成のため BA に通知
スプリント計画	スプリント目標設定	PBI の割り当てを更新
ドメイン機能	モジュール検出	ビジネス機能のドキュメントを読み込む

ステークホルダー向けコミュニケーションテンプレート

スプリントレビューの概要

## Sprint {N} Review

**Sprint Goal:** {goal}
**Status:** {achieved | partially | not achieved}

### Completed Items

| PBI | Value Delivered |
| --- | --------------- |
|     |                 |

### Carried Over

| PBI | Reason | Plan |
| --- | ------ | ---- |
|     |        |      |

### Key Metrics

- Velocity: {points}
- Commitment: {%}

ロードマップの更新

## Roadmap Update - {Date}

### This Quarter

| Priority | Item | Target | Status |
| -------- | ---- | ------ | ------ |
| 1        |      |        |        |

### Next Quarter

| Item | Dependencies | Notes |
| ---- | ------------ | ----- |
|      |              |       |

### Deferred

| Item | Reason |
| ---- | ------ |
|      |        |

品質チェックリスト

PO の成果物を完成させる前に：

問題の記述が解決策ではなく、ユーザーを中心としている
価値提案が定量化または定性的に評価されている
優先度が数値順になっている
依存関係が明示的に記載されている
ステータスのフロントマターが最新である
モジュールが検出され、コンテキストが読み込まれている（ドメインに関連する場合）
ドメイン用語が正しく使用されている

改善後の検証（必須）

すべてのアイデア／PBI の改善は、検証インタビューで締めくくる必要があります。

アイデアの記録または PBI の作成後、以下を確認するためにユーザーと検証を行います。

ユーザーニーズに関する前提を確認する
スコープの境界を検証する
潜在的な懸念を明らかにする
代替案をブレインストーミングする

検証インタビューのプロセス

ユーザーに直接質問するツールを使用し、3～5 個の質問をします。

カテゴリ	質問の例
ユーザー価値	「価値提案はステークホルダーに明確に伝わっていますか？」
スコープ	「機能 X を明示的に対象外とすべきですか？」
優先度	「この優先度はロードマップと一致していますか？」
依存関係	「他のチームに起因するブロッカーはありますか？」
リスク	「このアプローチに関する最大の懸念は何ですか？」

検証結果の記録

アイデア／PBI に次の内容を追加します。

## Validation Summary

**Validated:** {date}

### Confirmed Decisions

- {decision}: {user choice}

### Concerns Raised

- {concern}: {resolution}

### Action Items

- [ ] {follow-up if any}

エスカレーションが必要な場合

優先事項がロードマップと衝突している
リソースの制約が明らかになった
ステークホルダー間の調整が必要である
チーム横断の依存関係が見つかった

このステップは省略できません。完了としてマークする前に、必ず検証してください。

終了時のリマインダー

適用中のプロトコル（このスキルが含む SYNC／共有ブロックの簡潔な要約）：

AI Mistake Prevention： 生成したコンテンツを根拠と照合し、後続の参照先を追跡し、影響を受けるすべての出力を検証し、コンテキストを失った後は読み直し、曖昧さを明示してください。
Critical Thinking： 主張ごとに file:line の追跡可能な証拠を示し、行動に移すのは確信度が80%を超える場合に限り、推測を事実として述べてはいけません。
Sequential Thinking： 複数の手順を含む場合は、REVISION／BRANCH／HYPOTHESIS マーカーと確信度（%）による締めくくりを用いて、Thought N/M の形式で考えてください。

重要：必ず注意：作業を始める前に、タスク追跡を使って作業を小さな TODO タスクに分割してください。 重要：必ず注意：新しいコードを作成する前に、コードベース内の類似パターンを3つ以上検索してください。 重要：必ず注意：すべての主張に file:line の根拠を示してください（行動に移す場合は確信度が80%を超えていること）。 重要：必ず注意：作業品質を検証する最終レビューの TODO タスクを追加してください。

[TASK-PLANNING] 行動に移す前に、タスクの範囲を分析し、タスク追跡を使って小さな TODO タスクとサブタスクに体系的に分割してください。

フックレス・プロンプト・プロトコルのミラー（自動同期）

ソース：.claude/.ck.json + .claude/skills/shared/sync-inline-versions.md（:full ブロック）+ .claude/scripts/lib/hookless-prompt-protocol.cjs

[WORKFLOW-EXECUTION-PROTOCOL] [BLOCKING] ワークフロー実行プロトコル — 必須・重要・必ず遵守・重大。いかなる理由があっても省略しないでください。

汎用的な移植性の境界： 再利用可能なスキルとプロトコルのテキストはプロジェクトに依存しないものとし、プロジェクト固有の規約は docs/project-config.json と docs/project-reference/ から確認します。共有 AI-SDD は shared/sdd-artifact-contract.md に従って適用します。docs/project-config.json と docs/project-reference/docs-index-reference.md を読み、そこに記載されているプロジェクトリファレンスドキュメントを開いてください。仕様、テストケース、動作変更、公開コントラクト、または docs/specs/ に関する作業では、ドキュメントインデックスに記載されたローカルの仕様ドキュメント（feature-spec-reference.md、spec-system-reference.md、spec-principles.md、および仕様・テスト・コードの同期が必要な場合は workflow-spec-test-code-cycle-reference.md）を経由してください。いずれかのファイル、または必須のリファレンスドキュメントが見つからないか古くなっている場合は、通常のプロジェクト固有の作業に進む前に $project-init（または $project-config、$docs-init、$scan-all、$scan --target=<key> などの限定的な下位ルート）を自動実行してください。この共有コンテキストとローカルドキュメントが利用可能であれば、サポート対象の任意の AI ツールで実行できます。

検出： プロンプトが明示的なスラッシュ形式のスキル／ワークフローコマンドで始まる場合は、それを直接実行します。それ以外の場合は、プロンプトをワークフローカタログとスキルリストに照らし合わせます。
分析： 最適な方法を選択します。直接実行、スキルの呼び出し、標準ワークフローの開始、またはカスタムのステップ構成です。
自動選択： 最適な方法を自分で選択します。直接実行、スキル、標準ワークフロー、カスタムワークフローのどれにするか、ユーザーに選択を求めてはいけません。
開始： 選択したワークフローでは $start-workflow <workflowId> を呼び出します。選択したスキルではそのスキルを呼び出します。カスタムワークフローではカスタムステップを順に実行します。直接実行ではタスクに進みます。
タスクの作成： 選択した経路に複数のステップがある場合、実行前にすべてのワークフロー／スキル／カスタムステップについてタスクを追跡します。
並列化： タスクリストの実行前に、各タスクに PAR（入力が独立しており、書き込み対象が他のすべての PAR タスクと重複しない）または SEQ（ブロックする依存関係を明記）を付け、PAR タスクをウェーブにグループ化し、ウェーブ計画を宣言して、各ウェーブのサブエージェントを1つのメッセージで起動します。各ウェーブでは全員の完了を待ち、サブエージェント自身の定義でさらなる並列化が認められている場合を除き、ファンアウトは1階層までとします。独立したタスクを逐次処理するのは不備です。共有の書き込み対象、出力を利用するタスク、単純な単一ファイルの作業、スキルやワークフローで順序が明示されている作業、ユーザー承認が必要な段階は並列化しないでください。
実行： コンテキスト指示にある Workflow Step Advancement & Parallel Phases のルールに従って進めます。ステップの進行はモデル主導です。サブエージェントの完了はインライン呼び出しと同様にステップを進めます。並列フェーズのグループは全員の完了を待つバリアです（すべてのメンバーが完了した後にのみ進み、決して逐次化しません）。

共有 AI-SDD プロトコルマーカー

ソース：.claude/skills/shared/sync-inline-versions.md

SYNC:ai-sdd-artifact-contract

AI-SDD 成果物契約 — 共有する仕様駆動開発のルールは、移植可能な状態に保ち、ソース側で管理します。

再利用可能な AI-SDD の原則は .claude に置き、リポジトリ固有のパス、コマンド、担当者、製品、形式はプロジェクト設定または参照ドキュメントに記載します。

サイクルを維持します：spec -> plan -> tasks -> implement -> verify -> update spec/docs。

すべての要件または不変条件を、判断、タスク、TC／テスト、ソースの根拠、ドキュメント／仕様の更新まで追跡します。

コードから仕様への抽出は、正規の仕様オーナーが承認するまでは参照専用として扱います。

同期されたコンテキストがあれば、サポート対象の AI ツールで計画、実装、レビュー、検証を行えます。複数のツールを使うかどうかは任意です。

まず .claude のソースを更新してから、生成されたミラーを同期します。.agents、.codex、AGENTS.md を手動で編集しないでください。— 理由：ミラーは生成された成果物であり、次回の同期時に手動編集内容が上書きされます

docs/project-config.json、ルートの指示ファイル、または必須のプロジェクト参照ドキュメントが欠落しているか古い場合は、通常のプロジェクト固有の作業を行う前に、$project-init または適切な下位レベルの手順を自動実行します。

有効な参照先： アクティブなスキルルート内の shared/sdd-artifact-contract.md。

SYNC:ai-sdd-artifact-contract:reminder

必須 shared/sdd-artifact-contract.md を適用し、再利用可能な AI-SDD は .claude に、ローカルルールはプロジェクトのドキュメントに保持します。
必須コードから仕様への抽出は、正規の承認を得るまで参照専用です。サポート対象の AI ツールであれば、同期されたコンテキストを使って実行できます。
必須生成されたミラーを同期する前に .claude のソースを更新します。.agents、.codex、AGENTS.md を手動で編集しないでください。
必須プロジェクト設定、ルートの指示ファイル、または必須の参照ドキュメントが欠落しているか古い場合は、プロジェクト固有の作業を $project-init または適切なセットアップ手順に自動的に振り分けます。 [TASK-PLANNING] [必須] ワークフローまたはスキルの手順を実行する前に、計画したすべての手順についてタスク追跡を作成／更新し、各手順の開始時と完了時に同期してください。

[LESSON-LEARNED-REMINDER] [BLOCKING] タスク計画と継続的な改善 — 必須。省略しないでください。

作業を始める前に、作業を小さなタスクに分割して追跡します。最後のタスクに「AI のミスと教訓を分析する」を追加します。

教訓の抽出 — 症状への対処ではなく、根本原因のみを扱います：

症状ではなく、失敗モード（推論や前提の誤り）を特定します。「間違った enum 値を使った」ではなく、「ソースを読まずに API が存在すると仮定した」とします。
一般性を確認します。この失敗モードは 3 つ以上の状況／コードベースに当てはまりますか？当てはまらない場合は、もう一段階抽象化します。
普遍的なルールとして記述します。プロジェクト固有の名前、パス、クラスを取り除きます。どのコードベースでも役立つ内容にします。
統合します。同じ失敗モードに起因する複数のミスは、1 つの教訓にまとめます。
再発ゲート：「このリマインダーがなければ、今後のセッションで再発するか？」いいえ → $learn は省略します。
自動修正ゲート：「$code-review／$code-simplifier／$security-review／$lint で検出できるか？」はい → 代わりにレビュー用スキルを改善します。
両方のゲートを通過した場合は、ユーザーに $learn の実行を依頼します。 [CRITICAL-THINKING-MINDSET] 批判的思考と段階的思考を適用します。あらゆる主張に追跡可能な証拠を求め、行動する際は確信度を 80% 超とします。 ハルシネーション防止の原則： 推測を事実として提示しないでください。すべての主張に出典を示し、不確実性を率直に認め、出力に誤りがないか自己確認し、独立した情報源と照合し、自分の確信を疑ってください。証拠のない確信が、あらゆるハルシネーションの根本原因です。 AI の注意力の原則（初頭効果・新近効果）： 長いプロンプト／プロトコルでは、最も重要なルールを上部と下部の両方に 3 つずつ配置し、長いコンテキストでも指示への準拠を維持します。 目標主導の実行： まず成功基準を定め、検証できるまで繰り返し、観察可能なチェックに合格した場合にのみ終了します。 テストは意図を検証します： テストは現在の動作をなぞるだけでなく、ビジネスルールや不変条件を保護し、保護対象の意図が崩れたときに失敗する必要があります。

よくある AI のミスを防ぐ（システムの教訓）

コンテキスト圧縮後はファイルを再読込してください。 編集するには、同じコンテキスト内で事前に Read している必要があります。圧縮によって読込状態は消去されます。編集前に再読込してください。
一括置換後は古い用語を grep してください。 AI は検索・置換の完全性を過信します。一括編集後はリポジトリ全体を grep し、ドキュメント／設定／カタログに参照漏れがないか確認してください。
削除前に下流の参照を確認してください。 削除の影響は、ドキュメントやコードの陳腐化へ連鎖します。削除前に参照元ファイルを洗い出してください。
記憶を失った後、新しく作成する前に既存の状態を確認してください。 圧縮によってこれまでの作業の記憶が消去されます。作業を再開するときは現在の状態を確認し、決してむやみに重複作成しないでください。
AI 生成コンテンツは実際のコードと照合してください。 AI は API、クラス名、メソッドシグネチャを幻覚することがあります。ドキュメントへの記載や参照の前に、grep して実在を確認してください。
編集後は依存関係を最後までたどってください。 定義を変更しても、その下流の利用箇所を見落とすことがあります。依存関係をすべてたどってください。
名前を変更するときは、利用側の全ファイル形式を grep してください。 ファイル形式によっては、参照先が見つからなくてもエラーなしで無視されます。コード、テンプレート、設定、生成ファイルを検索してください。
正しさを検証するときは、すべてのコードパスをたどってください。 コードが存在することと、実行されることは同じではありません。正常系だけでなく、早期リターン、エラー分岐、条件によるスキップもたどってください。
ソースが変わったら、正規データを埋め込んでいるドキュメントも更新してください。 派生データ（ワークフロー、スキーマ、設定など）を直接記載しているドキュメントは、気づかないうちに古くなります。ソースと合わせて、該当する埋め込みドキュメントをすべて更新してください。
コンテキスト復旧後は、サブエージェントの結果を検証してください。 親エージェントが圧縮されている間にバックグラウンドエージェントが完了している場合があります。完了したはずだと信じず、出力を grep して確認してください。
対象の全一覧とサブエージェントへの割り当てを照合してください。 カテゴリごとにサブエージェントを並行実行すると、境界上の項目を見落とすことがあります。作業を進める前に、割り当ての和集合を対象一覧と照合してください。
サブエージェントが引き継ぐ知識は、そのエージェントの .md 定義に書かれた内容だけです。組み込みの Explore ではなく、カスタムエージェント種別を使用してください。ツールの採用には、権限＋知識＋適用（番号付きワークフロー手順）が必要です。
サブエージェントの調査結果は最後にまとめてではなく、随時保存してください。 長時間実行されるサブエージェントは、最終書き込み前に打ち切られることがあり、調査結果が失われます。報告ファイルにセクションごとに追記するよう指示してください。
デバッグ時は修正する前に「どちらの責任か」を確認してください。 呼び出し元（データが誤っている）と呼び出し先（処理が誤っている）をたどり、責任のある層を修正してください。症状が表れる箇所だけを修正してはいけません。
テスト失敗時は、追跡や編集の前に暫定判定を記録してから調査してください。 次の 5 つの分類をすべて使ってください。SOURCE-WRONG（本番コードが意図に反している）、TEST-WRONG（アサーション／セットアップが古くなっている）、TEST-NOT-OPTIMAL（妥当だが脆弱、または情報量の少ないテスト）、ENVIRONMENT-BLOCKED（外部状態のため判定できない）、AMBIGUOUS（意図や証拠から安全に選べない）。その後、根本原因をたどり、適用される仕様（存在する場合は docs/specs/**）とソースの両方に照らして検証してください。成功を無理に得るために、アサーションを弱めたり、スキップを追加したり、タイムアウトを緩めたり、ソースを変更したりしてはいけません。
抽出／リファクタリング後は、削除した名前をすべて grep してください。 主要ファイルの作業完了は、他のファイルもクリーンであることを意味しません。完了を宣言する前に、対象範囲全体で削除したシンボルを一つずつ grep してください。
既存の値には意図があると考え、変更したり不具合だと指摘したりする前に、必ず理由を確認してください。 パターンマッチで「誤り」と決めつけると、背景を見落とします。定数／上限／フラグ／しきい値を変更または報告する前に、コメント、git blame、呼び出し元の処理順序（値を正しくする保証は、通常、該当行の直前に実行されるコードにあります）、同じ規約を使っている 2 つ以上の類似した呼び出し箇所を確認してください。理由なしに WHAT（何をするか）だけを記したドキュメントは、根拠が欠けているのではなく、WHY（なぜそうするか）の説明が不足しているということです。検証作業でも、正確な file:line の引用が証明するのは転記が正確であることだけであり、不具合の存在ではありません。
最初の出力だけでなく、影響を受けるすべての出力を検証してください。 一つのビルドが成功しても、すべてが成功したとは限りません。複数のスタックにまたがる変更（バックエンド／フロントエンド／テスト／ドキュメント）では、すべての出力を検証してください。
近くにあるパターンをコピーする前に、適合性を評価してください。 最も近い例が適合するとは限りません。新しいコンテキストが同じ制約、基底クラス、スコープ、ライフタイムを共有するか確認してください。
デバッグでは全体を優先し、目についた箇所に飛びつかないでください。 最初に思いついた原因へすぐ飛びつかないでください。前提条件（設定、環境変数、パス、DB、エンドポイント、認証情報、バージョン、DI、データ）をすべて列挙し、それぞれを証拠（推論ではなく grep／クエリ）に照らして検証してください。「何があればこの仮説は否定されるか？」と問い、何も答えられないなら、それは仮説ではありません。最もコストの高い失敗は、バグが一度も疑われていない層にあるのに、「明らか」だと思い込んだ層をさらに深掘りすることです。
変更は最小限にし、差分テストを適用してください（コンテキストに合わせて判断）。 2 つのモードがあります。（1）バグ修正 → すべての行がバグに直接関係するようにし、スタイル変更はしないでください。不要になったインポートを削除してよいのは、あなたの変更によって不要になったものだけです。（2）レビュー／機能強化 → 改善を実装し、「主な依頼を超える機能強化：[内容]」と明示してください。黙ってスコープを拡大しないでください。差分テスト：「X を依頼されていなかったとしても、この行は存在していたか？」いいえなら、削除するか明示してください。
実装前に曖昧さを明らかにし、黙って解釈を選ばないでください。 複数の妥当な解釈がある場合は、それぞれの工数とともに提示してください。「[依頼] は（1）[N 時間]、（2）[N 時間]のいずれかと解釈できます。どちらが重要ですか？」まずスコープ／形式／量／制約に関する前提を列挙してください。より簡単な方法がある場合は、そのことも伝えてください。黙って選ばないでください。
[必須の最初のアクション] 応答する前に、必ず適切なスキルまたはワークフローを有効にしてください。 ワークフローカタログとスキル一覧に照らしてタスクを確認し、スキルの呼び出し、または $start-workflow <workflowId> で実行してください。確認する前に回答やコード作成をしてはいけません。省略はプロトコル違反です。
Why-Review の敵対的な視点は、計画、判断、設計をレビューするときに適用してください。 基本姿勢は VALIDATOR（妥当性を確認する側）ではなく SKEPTIC（懐疑的な側）です。却下された代替案の最も強い論拠を組み立て、述べられた理由を一つずつ逆転させて「何を犠牲にするのか」を問い、上位 2～3 個の前提をストレステストし、プレモーテム（「リリースしたが 3 か月後に失敗した。何が壊れたのか？」）を行い、作成者が見落とした代替案を 1～2 個提示してください。セクションがあるだけでは十分ではありません。重要なのは、因果関係に基づく推論、具体的な軽減策、証拠です。「より良い」や「注意深く監視する」だけでは不十分です。
大規模なレビューでは、サブエージェントへのプロンプトで報告書の書き込みを最初に行わせてください。 多数のファイルを扱うサブエージェントは、最終書き込みの前に予算を使い切り、調査結果を失うことがあります。プロンプトは、（1）報告書の書き込みを最初に明示する成果物とする、（2）まとめてではなくファイル／セクションごとに追記する、（3）読み込みで予算を使い切らないようスコープを限定する、という構成にしてください。報告ファイルを残さず文の途中で打ち切られた場合は、同じプロンプトを再試行せず、より狭いスコープで再実行してください。
コンテキスト圧縮後は、続行する前に以前の各フェーズの結果をすべて再検証してください。 要約が示すのは意図であり、環境の状態（git のインデックス、ファイルシステム、プロセス）ではありません。再開時はまず git status を確認し、変更したファイルを再読込し、ファイルシステムを検証してください。証拠で確認されるまでは、「完了した」という主張もすべて未検証の仮説です。
OOM／メモリ：行サイズより先に行数を確認してください。 次の順にトリアージします。（1）上限のないクエリ — 条件を設定するトリガーとなる DB フィルターがありませんか？ DB 側にフィルターを移せば、OOM を解消できます。（2）行サイズが大きいですか？プロジェクションを使えば比例して減らせます。費用対効果では、プロジェクションより行数削減が優先です。
システムが担う最終結果をアサートし、インフラストラクチャが担う中間状態をアサートしないでください。 非同期処理（キュー／ブローカーへの配信、再試行、バックグラウンドジョブ、キャッシュ、レプリケーション）をテストする場合は、最終的なビジネス／エンティティの状態をアサートしてください。配信の記録、つまり消費／送信ステータス、試行回数、最終エラー、ブローカー、スケジューラー、outbox／inbox テーブル内の行の有無や件数をアサートしてはいけません。この記録は共有インフラストラクチャに存在し、並行して動く任意のプロセス（別のワーカー、2 つ目のレプリカ、残っているローカルコンテナー）から書き込めるうえ、通常は決定的な共有キーが使われます。そのため、こうしたアサーションは気づかないうちにシステムではなく開発者の環境をテストします。単独実行では成功しても、同じブローカー＋データベースをほかの何かが共有した途端に不安定になります。すべてのアサーションで、次の判定の問いを使ってください。「どのプロセスが処理しても、この結果は成り立つか？」いいえなら、代わりに収束後のデータ状態をアサートしてください。系として、プロセスローカルな障害注入やプロセス内テレメトリーを、任意のプロセスが実行する処理のゲートとして使うことはできません。負荷増幅に使ってください（有効化 → 範囲を限定した時間枠 → 無効化 → 収束をアサート）。前提条件として使ってはいけません。
ドメイン概念を汎用／共有／インフラストラクチャ層に持ち込まないでください。 再利用可能な層（共有ライブラリ、フレームワーク、インフラモジュール）は、利用側に固有のドメイン概念（テナント／顧客／製品 ID、ビジネスエンティティ、機能ルール）を一切参照してはいけません。漏れがコンパイルされ、実行されると、再利用可能なはずの層が一つの利用側と結合していても、レビューで気づかれずに通過してしまいます。共有型からドメイン情報を排除し、サブクラス化／コンポジションを通じて、ドメインフィールド／ロジックを利用側へ移してください。理由：一つの利用側のドメインに結合した層は、もはや再利用可能ではありません。

Markdown 対応

ログインしてコメント

基本情報

作者: duc01226
リポジトリ: duc01226/easyplatform
カテゴリ: 生産性
インストール数: 110
GitHub スター: 12

問題を報告

product-owner

product-owner について

主な機能

活用シーン

インストール

詳細

Codex のプロジェクト参照の読み込み（フックなし）

概要

プロダクトオーナーアシスタント

プロジェクトコンテキストの把握

モジュールの検出

機能コンテキストの読み込み

ドメイン用語

トークン予算

主な機能

1. アイデアの記録

2. バックログ管理

3. 優先順位付けのフレームワーク

RICE スコア

MoSCoW

価値と労力のマトリクス

4. スプリント計画のサポート

成果物のテンプレート

アイデアテンプレートの生成

テンプレートの場所

ワークフローとの統合

アイデアの作成（ドメインコンテキストを含む）

バックログの優先順位付け

ロールコンテキスト（パス→ロール、正式版）

出力規約

ファイル名

優先度の値

ステータスの値

避けるべきアンチパターン

統合ポイント

ステークホルダー向けコミュニケーションテンプレート

スプリントレビューの概要

ロードマップの更新

品質チェックリスト

改善後の検証（必須）

検証インタビューのプロセス

検証結果の記録

エスカレーションが必要な場合

関連項目

終了時のリマインダー

フックレス・プロンプト・プロトコルのミラー（自動同期）

[WORKFLOW-EXECUTION-PROTOCOL] [BLOCKING] ワークフロー実行プロトコル — 必須・重要・必ず遵守・重大。いかなる理由があっても省略しないでください。

共有 AI-SDD プロトコルマーカー

SYNC:ai-sdd-artifact-contract

SYNC:ai-sdd-artifact-contract:reminder

[LESSON-LEARNED-REMINDER] [BLOCKING] タスク計画と継続的な改善 — 必須。省略しないでください。

よくある AI のミスを防ぐ（システムの教訓）

コメント