aep-workflow-feedback

ワークフローフィードバック

下流プロジェクトでワークフローに関する所見を収集し、上流に伝えて AEP のスキルとドキュメントを改善するための再利用可能なパターンです。

2 つのモード：

• 収集 — ビルド後に下流プロジェクトで実行し、所見を標準化します。
• レビュー — AEP リポジトリで実行し、下流プロジェクトから上流候補を収集して振り分けます。

DOWNSTREAM PROJECT                           AEP REPO
━━━━━━━━━━━━━━━━━━                           ━━━━━━━━
/aep-build → lessons.md                          /aep-workflow-feedback review
/aep-wrap  → lessons-learned/                      ↓
/aep-workflow-feedback capture                   Read .aep/config.yaml
  ↓                                            ↓
.dev-workflow/feedback.md  ──────────────→   Route to docs/
  (standardized + classified)                  ↓
                                             Human approves
                                               ↓
                                             tag release → re-pin downstreams ──→ updated skills flow back

セッション： Main。ユーザーと対話しながら進めます。

厳格なガードレール — このスキルが AEP のスキルファイルを編集することはありません。 どちらのモードでも、フィードバック／教訓ファイルで修正案を提示します。人間が意図的に再ピン留めを行い、上流に適用します。

---

モード 1：収集

レイヤー、ストーリーのバッチ、または自動操縦の実行を完了した後、下流プロジェクトでこれを実行します。目的は、生の所見を AEP がレビューできる形式に標準化することです。

ステップ 1 — 情報源を収集する

AEP のスキル／プロセスの動作を含む、利用可能なすべての情報源から所見を収集します。製品のバグだけに限定しないでください（製品固有のバグはここではなく、/aep-reflect → ストーリー作成に記録します）。

1. アーカイブ済みの教訓： lessons-learned/*.md（/aep-wrap が作成）
2. プロセスに関する教訓： lessons-learned/process/*.md（/aep-reflect が作成）
3. 未アーカイブのワークスペースの教訓： .feature-workspaces/*/dev-workflow/lessons.md（ワークスペースがまだラップされていない場合）
4. ユーザーの所見： 上記に記録されていない、実行中に気づいた点をユーザーに尋ねます。

事後条件：ユーザーの所見はそれぞれフィードバックファイル（ステップ 3）に記録されるか、ユーザーが所見はなかったと明示的に確認しています。

ステップ 2 — 各所見を分類する

各所見に分類を割り当てます。

分類	説明	上流へ？
process	AEP のワークフロー改善 — スキル、フェーズ、またはゲートを変更する必要があります	はい
tech-stack	技術固有の注意点 — この技術を使用するすべてのプロジェクトに適用されます	はい
discovery	製品ドメインまたはアーキテクチャについて新たに得られた理解	場合による
project-local	このプロジェクトのコードベース固有で、一般化できません	いいえ

AEP を使用する他のプロジェクトにも役立つ項目に限り、upstream_candidate: yes と設定します。事後条件：すべての所見に分類が割り当てられています。

ステップ 3 — 標準化されたフィードバックを記述する

.dev-workflow/feedback.md に記述します。

# Workflow Feedback: <project> <layer/context>

Date: YYYY-MM-DD
Project: <name>
Layer: <layer>
Stories: <count>

## Observations

### <title>

- **Classification:** process | tech-stack | discovery | project-local
- **Skill affected:** /aep-calibrate, /aep-build, /aep-autopilot, etc. (if applicable)
- **Technology:** Rust, Cloudflare, etc. (if tech-stack)
- **Observation:** <what happened>
- **Recommendation:** <proposed change>
- **Upstream candidate:** yes | no

事後条件：.dev-workflow/feedback.md が存在し、収集した所見ごとに Observations エントリーが 1 つずつ含まれています。

ステップ 4 — コミットする

.dev-workflow/feedback.md を下流プロジェクトにコミットし、AEP のレビューで利用できるようにします。事後条件：git status に .dev-workflow/feedback.md がコミット済みとして表示されています。

---

モード 2：レビュー

下流プロジェクトからフィードバックを収集し、AEP のドキュメントに反映するため、AEP リポジトリでこれを実行します。

ステップ 1 — 下流プロジェクトを確認する

.aep/config.yaml を読み、登録済みの下流プロジェクトのパスを確認します。各プロジェクトについて：

1. .dev-workflow/feedback.md（収集モードで標準化されたフィードバック）があるか確認します。
2. feedback.md がない場合は、lessons-learned/**/*.md（ビルドから得られた生の教訓）を確認します。フィードバックが不完全な可能性があるため、これらが存在する場合は直接読みます。

フィードバックファイルがない下流プロジェクトは記録し、次に進みます。事後条件：登録済みの下流プロジェクトはすべてスキャンされているか、フィードバックがないことが記録されています。

ステップ 2 — 上流候補を絞り込む

次のいずれかに該当する所見を収集します。

• upstream_candidate: yes と設定されている。
• process または tech-stack に分類されている（ほとんどの場合、上流に関係します）。
• discovery に分類されており、1 つのプロジェクトを超えて適用できるパターンが明らかになっている。

project-local の項目は、人間から明示的に依頼された場合に限り収集します。

ステップ 3 — 項目の振り分け

上流候補ごとに、振り分け先を決定し、process の観察がどの AEP スキルに影響するかを記録します。

分類	振り分け先	形式
process	docs/lessons/YYYY-MM-DD-<project>-<context>.md	日付を先頭に付けた教訓。スキルの修正案を記載
tech-stack	docs/tech-stack/<technology>-<topic>.md	単独の技術的な注意点のドキュメント
discovery	人間に提示して判断を仰ぐ	docs/decisions/ または docs/workflow/ に保存する場合があります

ステップ 4 — 概要を提示する

軽微なものも含め、すべての上流候補と振り分け案を表で人間に提示します。

| # | Source | Classification | Title | Proposed destination |
|---|--------|---------------|-------|---------------------|
| 1 | <project> | process | /aep-calibrate should modify real components | docs/lessons/... |
| 2 | <project> | tech-stack | Rust keyring needs platform features | docs/tech-stack/... |

人間が項目ごとに承認、修正、または却下します。

ステップ 5 — 承認された項目を書き込む

承認された項目ごとに、docs/README.md の規約に従って対象ファイルを作成します。提案するスキルの修正は、人間が適用できるように、レッスン／決定ファイル内に記録します（上記の厳格なガードレールに従います）。

書き込み後、承認されたスキルの改善を下流プロジェクトに反映するには、意図的な再ピン留めが必要であることを人間に伝えます。新しい AEP リリースタグを作成し、README の「新しいリリースへのアップグレード」の手順に従って、.aep/config.yaml に登録されている各下流プロジェクトで再ピン留めします。事後条件：承認された各項目が docs/ 以下のファイルとして存在すること。

---

このスキルを使うタイミング

状況	モード
下流プロジェクトでレイヤーを完了した	Capture
オートパイロットの実行が完了し、学びを記録したい	Capture
/aep-reflect でプロセスに関する観察を特定した	Capture
下流プロジェクトで得た学びを確認するとき	Review
蓄積した改善を含む AEP リリースを準備するとき	Review

隣接するスキルとの関係：/aep-reflect は 製品 に関するフィードバック（バグ、改良、発見、仕上げ）を分類します。このスキルは、/aep-reflect が表面化させたものの上流に振り分けていない プロセス および 技術スタック に関する観察を扱います。/aep-wrap はワークスペースの教訓を lessons-learned/ にアーカイブし、/aep-build は未加工の観察を .dev-workflow/lessons.md に書き込みます。Capture はその両方を読み込みます。/aep-autopilot の orchestration-learning.md は、ワークスペースをまたぐメタパターンを記録し、Review が上流に取り込めるようにします。