wire-aa-authoring

wire-aa-authoring — WireAA Authoring（汎用・Subagent・ASCII Art）

Story/Spec を起点に、対象リポジトリの component を調査し、画面UIの 現状 → 変更後 を ASCII Art ワイヤフレーム（コードブロック）で描く。仕様（文字）を「画面（図）」まで収束させ、エンジニアが実装イメージを掴める状態にする。

位置づけ: spec-story-starter（施策→Story/Spec）の次段。Spec の UI をワイヤフレームで具体化する収束の到達点。

When to Use

• Story/Spec は出来たが、UIの「現状と変更後」を目に見える形で示したいとき
• 画面変更を伴う機能で、実装前に導線・レイアウトの合意を取りたいとき
• 仕様を、エンジニアが実装着手できる粒度（どのcomponentをどう変えるか＋AA図）まで落としたいとき

入力インターフェース

入力	必須	説明
story	✅	対象Story（パス/参照）。Spec併記があれば一緒に読む
spec	⭕	対応Spec（未指定ならstoryから辿る/推定）
target_repo	⭕	component調査対象リポジトリのパス。未指定=カレント
screens	⭕	対象画面（例: NotificationSettings, MyPage）。未指定=SpecとStoryから推定
tier	⭕	lite（現状/変更後AA + AC のみ）/ full（+ フロー + エラー + 実装参考）。既定 full
update_story	⭕	既定 true。Storyに概要AA＋設計決定ログを追記

処理フロー（Subagent収束）

story/spec ──▶ P0 Load
                 │
                 ▼
        P1 component調査(Subagent①) ── target_repoの対象画面component・既存UI構造・状態管理を調べ、
                 │                       「既存実装済み/部分/未実装」を判定
                 ▼
        P2 対象画面の特定 + 現状UI把握 ──▶ Mob CP1(停止・対象画面と方針の確認)
                                             │ OK
                                             ▼
        P3 AAワイヤフレーム作図(Subagent②) ── 現状AA / 変更後AA を対で描く（コードブロック）
                                             │
                                             ▼
        Mob CP2 設計論点(決定項目/選択肢/推奨/根拠) ── 停止
                                             │ 決定
                                             ▼
        P4 wire_aaファイル出力 ─▶ P5 Story更新(概要AA+決定ログ) ─▶ P6 Verification ─▶ 完了報告

Phase 0: Load

story（+spec）を読み、対象機能・画面・AC・変更意図を把握する。

Phase 1: component調査（Subagent①）

target_repo を Subagent（Read/Glob/Grep）で調査し返させる:

• 対象画面の component ファイル（例: src/components/NotificationSettings.tsx）と現状の構造
• 使っている状態管理（stores）・呼ぶservice/API
• 「既存実装済み / 部分実装 / 未実装」の判定
• 変更時に触るファイル（component / store / service）

プロンプト骨子: 「target_repoで画面『[screen]』の現状UI構造を調べて。component/store/呼ぶserviceをファイルパス付きで。機能『[feature]』を足すならどのcomponentをどう変えるか。」