wire-aa-authoring

name	wire-aa-authoring
description	Story/Spec と対象リポジトリを起点に、画面UIの「現状」と「変更後」を ASCII Art（AA）ワイヤフレームで描き、Storyに設計決定ログを追記する。target_repoのcomponentを調査して実装状況にground。抽象仕様を"見える画面"まで収束させる可視化フェーズに使う。特定ツール連携の専用版スキルのローカル/汎用翻案。

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をどう変えるか。」

Phase 2: 対象画面特定 + 現状UI把握 → Mob CP1（停止）

対象画面と、現状UIの理解（Subagent①の結果）を提示し、作図対象と方針を確認する。🙋承認待ち。

📷 キャプチャは使わない（ローカル）。現状UIはcomponentコードから再構成する。

Phase 3: AAワイヤフレーム作図（Subagent②）

対象画面ごとに 現状AA と 変更後AA を対で描く（下記記法）。full時はフロー(mermaid)・AC・エラー・実装参考も。

Phase 4/5/6/Mob CP2: 決定・出力・Story更新・検証

• Mob CP2: 設計論点を「決定項目 / 選択肢 / 推奨 / 根拠」の4カラム表で提示し停止
• P4: <出力先>/wire_aa/[画面名]_wire_aa.md を作成（現状UI / BE実装状況 / 変更仕様 / フロー / AC / エラー / 実装参考 ＋ 現状AA・変更後AA）
• P5（update_story）: Story本文に (1)「対応方針」直下へ概要AA（現状→変更後の簡潔版） (2)「設計決定ログ」セクションを追記
• P6 Verification: 各wire_aaに現状/変更後AAが描かれ、実装参考パスが target_repo に実在し、Story⇔wire_aa整合、をチェックリスト出力

AA（ASCII Art）ワイヤフレーム記法

等幅テキストで画面レイアウトを描く。現状と変更後を必ず対で並べる。コードブロックで整列を保つ。

+----------------------------------+
| 画面見出し                [ 保存 ] |
| +------------------------------+ |
| | ● LINE で受け取る            | |  <- トグル（現状: 個別設定なし）
| | ○ メールで受け取る           | |
| +------------------------------+ |
|          [ 変更を保存 ]          |
+----------------------------------+

記法のコツ: (1) + - | で枠線 (2) [ ... ] でボタン/入力 (3) ● ○ でトグル/ラジオ (4) <- <= ↑ で注釈 (5) ★/（新規） で状態 (6) 現状↔変更後を対で。

ガードレール

• Mob CP1/CP2 は必ず停止（走り抜け禁止）
• 現状/変更後のAAワイヤフレームは省略不可（このスキルの本質。文字記述だけで済ませない）
• 実装参考は target_repo に実在するファイルパスのみ（存在しない構造を捏造しない）
• target_repo は読むだけ（書き込まない）。.env・秘密は扱わない
• component調査は2〜3クエリに絞る（過剰探索しない）

使用例

spec-story-starter が起票した Story/Spec を入力に、その画面をワイヤフレーム化する（収束チェーンの次段）:

/wire-aa-authoring
story: <spec-story-starterが起票したStoryのパス（例: examples/kotonoha/backlog/stories/ST-KTN-NNN_*.md）>
spec:  <対応Specのパス>
target_repo: examples/kotonoha/store
screens: NotificationSettings, MyPage
tier: full

⚠️ story/spec は前段（spec-story-starter）でライブ生成される。事前に用意しない。既存の backlog Story（例: examples/kotonoha/backlog/stories/ST-KTN-002_*）を対象に単体実行することも可。

---

作成日: 2026-07-08 ｜ 由来: 特定ツール連携の専用版スキル（v1.1）の汎用・ローカル・Subagent翻案。次段: spec-story-starter → wire-aa-authoring で収束チェーン完成