アプリ・Webサービス・業務ツールの制作を、証拠分析→確定的な初稿→要件定義→体験設計→機能分解→実装→品質ゲート→リリース判定の手順ゲート制で進めるスキル。質問で要件を埋めるのではなく、依頼文・既存コード・資料・ログから最有力案を選び、動く成果物を先に出して差分で改善する。ユーザーが「アプリを作りたい」「ツールを作って」「〜を自動化したい」「システム化したい」「要件定義」「仕様を決めたい」「UI/UXを設計して」「体験を良くしたい」「機能を洗い出して」「MVPを決めたい」「品質チェック」「リリースしていいか判断して」などと言ったら必ず使用する。外部データの取込・マスタ・締め処理を伴う業務システムでは references/data-lifecycle.md も併用する。新規・既存を問わずアプリの制作・改善・リニューアルで使用する。
ref-output-routing
管理して成果物の出力先を切り替えたいとき、新しい出力先アダプタを追加したいときに使う。
含まれるファイル(5)
- SKILL.md5.4 KB
- prompts/R1-search-summarize.md6.5 KB
- references/resource-map.yaml651 B
- references/security-model.md4.4 KB
- references/sink-contract.md2.8 KB
SKILL.md(原文)
インストールする前に、エージェントに与えられる指示の中身を確認できます。
ref-output-routing
Purpose & Output Contract
タスクロジックと出力先を直交分離する。 workflow skill は本スキルに task_kind を渡すだけで、出力先 (Notion DB / Sheets / Local / HTTP / Slack 等) を意識しない。新出力先の追加は adapter 追加のみで完結する (Open/Closed原則)。
入力: task_kind (例: task-spec, meeting-minutes, audit-log)
出力:
{
"adapter": "notion|sheets|local|http|slack",
"params": {...},
"fallback": "local",
"multi": false
}
完了条件: output-routing.json から該当route解決 → adapter名とparams返却 → workflow側が dispatch.py 経由でadapterを起動。
Sink Contract (全adapter共通)
入力payload (workflow → adapter)
{
"schema_version": "1.0",
"kind": "<task_kind>",
"title": "<string>",
"body": "<markdown>",
"metadata": {
"tags": [],
"timestamp": "ISO8601",
"source_skill": "<skill_name>"
},
"attachments": []
}
出力result (adapter → workflow)
{
"status": "success|failure",
"adapter": "<name>",
"location": "<URL or path>",
"external_id": "<opaque ID>",
"errors": []
}
設定ファイル (3点)
.claude/config/output-routing.json— task_kind → adapter マッピング正本.claude/config/adapter-registry.json— 利用可能adapter宣言- macOS Keychain — APIキー等の秘匿情報 (リポジトリには絶対保存しない)
Key Rules
- API key は絶対にClaude context に乗らない: adapter scriptが subprocess 内で Keychain から取得し、HTTP呼出しに直接使う。Claude は key を見ない。
- output-routing.json にはIDのみ: database_id, spreadsheet_id 等の非機密IDは記載可。トークン/secret は
keychain:{{SECRET_NAMESPACE}}/<account>形式で参照のみ記載。env:/file:は使わない。 - adapter追加はJSON登録のみ: コード変更なしで
adapter-registry.jsonに登録すればoutput-routing.jsonで使える (Open/Closed)。 - multi-sink対応:
adapters: [notion, local]で複数同時出力可能。 - fallback必須: 各routeに
fallback: local推奨。外部API障害時にローカル退避でwork継続。
使い方 (workflow側)
# Step 1: routing解決
python3 ${HARNESS_ROOT:-.}/scripts/adapters/resolve_route.py --kind task-spec
# 出力: {"adapter":"notion","params":{"database_id":"..."},"fallback":"local"}
# Step 2: 解決されたadapter起動
python3 ${HARNESS_ROOT:-.}/scripts/adapters/dispatch.py \
--kind task-spec \
--payload payload.json \
# 出力: {"status":"success","location":"{{OUTPUT_ROUTE}}","external_id":"..."}
adapter 追加手順 (例: Linear連携)
scripts/adapters/sink_linear.pyを作成 (Sink Contract準拠).claude/config/adapter-registry.jsonに追加:{ "name": "linear", "script": "scripts/adapters/sink_linear.py", "requires_secret": true, "params_schema": { "team_id": { "type": "string", "required": true }, "token_ref": { "type": "string", "required": true } } }.claude/config/output-routing.jsonの該当 task_kind に"adapter": "linear"を指定- Keychainに API key を登録:
security add-generic-password -s {{SECRET_PREFIX}}-linear -a api-key -w <KEY>
workflow Skill のコード変更はゼロ。adapter script 追加、registry、routing のJSON更新のみで新出力先が量産可能。
Gotchas
- API keyをroutingに直書きしない:
params: { token: "sk-..." }は禁止。必ずparams: { token_ref: "keychain:{{SECRET_NAMESPACE}}/<account>" }で参照のみ。 - output-routing.jsonのコミット: 非機密ID (database_id等) はコミット可だがレビュー必須。tokenが紛れていないか lint で検証。
- fallback先のpath: ローカルフォールバックの保存先は
eval-log/等のrepo内に固定。外部書き出しは禁止。 - adapter内部のstdout汚染禁止: adapter は最終JSON以外を stdout に出さない。debug は stderr へ。Claude が adapter出力を読むためstdoutにkey/secretが混入すると context漏洩。
- Sheets/HTTP のスキーマ互換: 同じpayloadを異なるadapterで処理できるか lint で確認 (
schema_version不一致を検出)。
Additional Resources
references/sink-contract.md— Sink Contract詳細仕様references/security-model.md— APIキー管理モデル (Keychain中心).claude/config/output-routing.json.example— routing雛形.claude/config/adapter-registry.json— adapter宣言正本scripts/adapters/— adapter実装群scripts/secrets/README.md— Keychain登録手順
レビュー
まだレビューはありません。使ってみた感想をお寄せください。
同じリポジトリのスキル
概要と使いどころ
Webアプリの準備→要件定義→設計→実装→公開→品質ゲートを実行する内部オーケストレーター。Claude Codeの /build-app /improve-app、Codexの $build-app / $improve-app から明示的に委譲された場合、custom agent起動時、または利用者が $app-orchestrator を明示した場合だけ使用する。一般のアプリ相談から暗黙起動しない。
run-extract-blueprint が生成した章別ブループリントの忠実性を独立 context で評価したいとき、事実/推測区別と粒度と被覆を検証し draft_hash に束縛した PASS/FAIL verdict をローカル品質ゲート (C01 の周回内の受入判定・差し戻し) へ渡したいときに使う。
確認点で利用者が見る深さを選んだあと打ち合わせ資料を作り手とは別の目で確かめたいとき、正確さ・言葉・見た目・シンプルさの指摘を資料の編集なしで受け取りたいときに使う。
生成した handout 資料が初心者に伝わるか読みやすさレビューを依頼したいとき、独立 context のレビュアーから指摘と根拠つきの verdict を回収したいときに使う。
Notion ページを描画する直前に粒度を検証したいとき、info-collector-agent ページと同等の section 充足度を section_canonical_map 基準で機械検証したいときに使う。