アプリ・Webサービス・業務ツールの制作を、証拠分析→確定的な初稿→要件定義→体験設計→機能分解→実装→品質ゲート→リリース判定の手順ゲート制で進めるスキル。質問で要件を埋めるのではなく、依頼文・既存コード・資料・ログから最有力案を選び、動く成果物を先に出して差分で改善する。ユーザーが「アプリを作りたい」「ツールを作って」「〜を自動化したい」「システム化したい」「要件定義」「仕様を決めたい」「UI/UXを設計して」「体験を良くしたい」「機能を洗い出して」「MVPを決めたい」「品質チェック」「リリースしていいか判断して」などと言ったら必ず使用する。外部データの取込・マスタ・締め処理を伴う業務システムでは references/data-lifecycle.md も併用する。新規・既存を問わずアプリの制作・改善・リニューアルで使用する。
run-skill-rename
Skill名を変更するとき、改名後の参照整合を確認するときに使う。
含まれるファイル(6)
- SKILL.md7.5 KB
- prompts/R1-rename.md6.0 KB
- references/CHANGELOG.template.md742 B
- references/resource-map.yaml102 B
- schemas/output.schema.json972 B
- workflow-manifest.json2.5 KB
SKILL.md(原文)
インストールする前に、エージェントに与えられる指示の中身を確認できます。
Pre-choice usable artifact execution
Purpose & Output Contractの最小の実成果物をmain contextで作成する。effect別のparse/open・secret・irreversible・corrupt guardだけを実行し、現物path・digest・開き方を提示してからaccept-as-is/light/standard/detailedを記録する。accept-as-isはその場でhandoff完了とし、後続sectionを実行しない。
Post-choice selected improvement execution
以下の既存workflow・goal-seek・評価・修正sectionはlight/standard/detailedが記録されてsemantic_evaluator_startedへ遷移した場合だけ実行する。release/exhaustiveは別の明示eventを必要とする。
run-skill-rename
Purpose & Output Contract
スキルを安全に改名するワークフロー(A5/C2: 未実装スキルの新規作成)。
入力: old_name (現在のスキル名), new_name (新しいスキル名) 出力:
- 改名済みディレクトリ
$OUT_BASE/<new-name>/ - SKILL.md frontmatter の
name:更新 aliases:に旧名を追加CHANGELOG.mdに改名エントリ追加- 参照元スキルの
pair:/Skill()記述を新名に更新
完了条件: lint-skill-name.py, lint-skill-tree.py が exit 0。
Key Rules
- ディレクトリ名 == frontmatter.name: 第8条。改名後は両方を同時更新。
- alias必須: 旧名を
aliases:に登録して参照切れを防ぐ(第6条)。 - CHANGELOG必須: 改名エントリを
references/CHANGELOG.mdに追加(第6条)。 - 参照元更新:
pair:/Skill()の旧名参照を新名に更新する。 - gitの履歴保持:
git mvを使い、ファイル移動の履歴を残す。
ゴールシーク実行
ゴール (Goal)
旧名スキルが $OUT_BASE/<new-name>/ へ git 履歴を保ったまま改名され、frontmatter.name・aliases・CHANGELOG・全参照元 (pair:/Skill()) が新名で整合し、lint-skill-name.py / lint-skill-tree.py が exit 0 の状態になっている。
目的・背景 (Why)
ディレクトリ名・frontmatter.name・参照は同時に一致させないと参照切れを生む (第8条)。部分更新で不整合が起きやすいため、固定手順ではなく「全箇所が新名で整合した状態」へ向けて未達箇所を都度埋める。
完了チェックリスト (Checklist)
-
resolve-skill-dirs.pyで$OUT_BASE(eval-log/skill-dirs.json) が解決済み - 旧名
$OUT_BASE/$OLD_NAME/SKILL.mdの存在を確認済み、新名$OUT_BASE/$NEW_NAMEは未存在 (重複なし) - 新名が
lint-skill-name.py --name "$NEW_NAME"の命名規約を通過 - ディレクトリが
git mvで改名され git 履歴が保持されている (rm+mkdir 禁止) - 新 SKILL.md frontmatter の
name:が$NEW_NAMEに更新され、aliases:に$OLD_NAMEが登録されている (第6条、参照切れ防止) -
references/CHANGELOG.mdに改名エントリ (date / 旧→新 / Reason / aliases) が追記されている (第6条) -
pair:/Skill()の旧名参照を$OUT_BASE/配下 SKILL.md 全体から grep し、ヒット各所が新名へ更新されている -
lint-skill-name.py・lint-skill-tree.py・validate-frontmatter.py(新 SKILL.md) が全て exit 0
ゴールシークループ
正本 ../run-build-skill/references/goal-seek-paradigm.md の 6 ステップ (現状評価→手順生成→実行→検証→Anchor Step→反復/差し戻し) に従う。本スキル固有の差分:
- 対象パス:
$OUT_BASEはresolve-skill-dirs.py出力。入出力は$OUT_BASE/$OLD_NAME→$OUT_BASE/$NEW_NAME。 - 不可分セット: ディレクトリ改名・frontmatter.name・aliases は必ずひとまとめで満たす (どれか欠けると参照不整合)。
- 検証コマンド:
lint-skill-name.py "$OUT_BASE/$NEW_NAME/SKILL.md"/lint-skill-tree.py "$OUT_BASE/$NEW_NAME"/validate-frontmatter.py。いずれか非 0 なら frontmatter/参照更新へ差し戻す。 - 参照元検索:
grep -r "$OLD_NAME" "$OUT_BASE/" --include="SKILL.md" -l。
Gotchas
- git mv 省略禁止:
rm+mkdirで移動すると git 履歴が途切れる。 - alias 追加忘れ: alias なしで旧名参照があると呼び出し先が消える。
- CHANGELOG 省略禁止: 第6条違反。CI で検出される。
- 部分更新: ディレクトリ名だけ or frontmatter だけの更新は不整合を生む。改名・frontmatter.name・aliases は必ずセットで満たす。
Additional Resources
06-classification-and-naming.md— 命名規約 第6条(改名手続き)13-checklists.md— 命名規約条文チェックリストplugins/skill-governance-lint/scripts/lint-skill-name.py— 命名検証plugins/harness-creator/skills/run-build-skill/scripts/resolve-skill-dirs.py— OUT_BASE 解決スクリプト
レビュー
まだレビューはありません。使ってみた感想をお寄せください。
同じリポジトリのスキル
概要と使いどころ
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 基準で機械検証したいときに使う。