wire-aa-authoring · git:20260708.e61f997 · 2026-07-08 · sha256 166f5c22b0a03f4d
wire-aa-authoring git:20260708.e61f997A
Immutable. This exact content never changes and is served at /api/v1/blob/166f5c22b0a03f4d.
---
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 で収束チェーン完成