アプリ・Webサービス・業務ツールの制作を、証拠分析→確定的な初稿→要件定義→体験設計→機能分解→実装→品質ゲート→リリース判定の手順ゲート制で進めるスキル。質問で要件を埋めるのではなく、依頼文・既存コード・資料・ログから最有力案を選び、動く成果物を先に出して差分で改善する。ユーザーが「アプリを作りたい」「ツールを作って」「〜を自動化したい」「システム化したい」「要件定義」「仕様を決めたい」「UI/UXを設計して」「体験を良くしたい」「機能を洗い出して」「MVPを決めたい」「品質チェック」「リリースしていいか判断して」などと言ったら必ず使用する。外部データの取込・マスタ・締め処理を伴う業務システムでは references/data-lifecycle.md も併用する。新規・既存を問わずアプリの制作・改善・リニューアルで使用する。
run-codex-plugin-package
Claude Code 用に作った新規または既存 plugin を Codex からも install できるようにしたいとき、.codex-plugin/plugin.json と .agents/plugins/marketplace.json を同期・検査するときに使う。
インストール方法を見る含まれるファイル(3)
- SKILL.md10.4 KB
- prompts/R1-package.md4.4 KB
- workflow-manifest.json5.6 KB
SKILL.md(原文)
インストールする前に、エージェントに与えられる指示の中身を確認できます。
Pre-choice usable artifact execution
Purpose & Output Contractの最小の実成果物をmain contextで作成する。parse/open・secret・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-codex-plugin-package
Runtime root contract
runtime_root_policy: host-skill-path の製品別root解決、cwd推測禁止、prompt継承は
ref-cross-platform-runtime の共有正本
をそのまま適用する。生成対象repository rootはplugin runtime rootと混同せず --repo-root で明示する。
Purpose & Output Contract
Claude plugin実体、明示override、package contract、compositionを入力に、Codex manifestとrepository marketplace entryを不可分にupsertする。成功出力は実在surfaceとの双方向一致、plugin境界、再check、capability parityを証明する検証証拠を含む。user-global install/enable/hook trustは変更せず、検証済みpackageを run-codex-plugin-install へ引き渡す。
Claude Code plugin の実体と明示的な Codex override を入力として、Codex が読む plugin manifest と repository marketplace を決定論的に upsert する。新規作成と 既存改善は状態から自動判定し、同じ generator を使う。
ゴールシーク実行
ゴール (Goal)
指定されたplugin scopeのCodex manifestとrepository marketplace entryが実在資産・package contract・compositionと一致し、単独配布境界と再checkがexit 0で証明されている。
目的・背景 (Why)
生成物の存在だけでは、実在surfaceの漏れ・plugin境界外依存・marketplace driftを見逃す。書込み前差分と書込み後検証を分け、installとは異なるlocal-artifact境界で収束させる。
完了チェックリスト (Checklist)
- Claude/Codex manifestの
name/version/description/authorが一致する - Codexの
skills/hooks/mcpServers/appsが実在資産と双方向一致する - marketplace entryがofficial fieldsだけを持ち、sourceが対象pluginを指す
- package entry points・composition公開surface・実体が双方向一致する
- plugin root外を指すsymlinkが0件である
- 生成後の
sync-plugin-platforms.py --checkとcapability parity auditがexit 0である - user-global install/enable/hook trust状態が変更されていない
ゴールシークループ
workflow-manifest.json の依存とR1 promptを読み、未充足のチェックを1つ選ぶ。preflight・drift check・apply・verifyから、現状に必要な最小操作を都度立案・実行して再評価する。全項目充足まで反復し、3周で未達なら追加書込みを行わず open_issues に残して停止する。
ゴールシーク配線
反復はfrontmatter goal_seek.fork=subagent で親contextから分離する。周回状態は eval-log/run-codex-plugin-package-progress.json、アンカーは eval-log/run-codex-plugin-package-intermediate.jsonl に追記し、original_goal を不変として次周の merged_directive_for_next に必ず合流させる。
ゴールシーク検証
アンカーの機械検査は goal-seek正本 を適用する。各行の required_keys、progressの original_goal_hash、hashlib.sha256 による不変アンカー照合が通らなければ完了にしない。
検証
- 対象scopeで
sync-plugin-platforms.py --checkを再実行する audit-capability-parity.py --plugin <name>で実体・entry points・composition・semantic routeを照合するgit diff --checkとgit status --shortで部分書き・指定外変更がないことを確認する
入力と出力
- 入力: repo root 直下の
plugins/<plugin-name>/.claude-plugin/plugin.json - 任意入力:
plugins/<plugin-name>/.codex-plugin-overrides.json - 出力:
plugins/<plugin-name>/.codex-plugin/plugin.json - 出力:
.agents/plugins/marketplace.jsonの対応 entry - 非対象: user global config、plugin trust、plugin install 状態、
.claude/projection
実行手順
-
repo root と
plugins/<plugin-name>が実在し、Claude manifest のnameが directory 名と一致することを確認する。 -
references/package-contract.jsonにcodex_distributionがある場合、distributable=trueと source/marketplace の一致を確認する。 -
先に check を実行する。
PLUGIN_ROOTはRuntime root contractに従って、このSkillの absoluteSKILL.mdpathから解決済みのabsolute plugin rootを使う。python3 "$PLUGIN_ROOT/scripts/sync-plugin-platforms.py" \ --repo-root . \ --plugin "plugins/<plugin-name>" \ --check -
drift を確認後、同じ引数で
--applyし、再度--checkを実行する。 新規 marketplace 名を固定する場合だけ--marketplace-name <name>を追加する。 省略時は既存 marketplace 名を保存し、無ければ repo directory 名から作る。 -
次を確認する。
- 両 manifest の
name/version/description/authorが一致 - Codex 固有 interface/component は
.codex-plugin-overrides.jsonだけが入力 - Codex manifest の
skills/hooks/mcpServers/appsが実在資産と一致 - marketplace entry が official fields だけを持つ
- plugin 配下に plugin root 外を指す symlink が無い
- 両 manifest の
-
複数pluginを量産した後は、Claude manifestを持つ全pluginを一括生成・検査する。
python3 "$PLUGIN_ROOT/scripts/sync-plugin-platforms.py" \ --repo-root . --all --apply python3 "$PLUGIN_ROOT/scripts/sync-plugin-platforms.py" \ --repo-root . --all --check一括処理は削除済みpluginのrepo-local marketplace entryも除去する。 各pluginは単独cacheで動くよう、plugin root外を指すsymlinkを残さない。
install 境界
package生成は user-global 状態を変更しない。ユーザーが install を明示依頼した場合だけ
run-codex-plugin-install に委譲する。local/Git sourceの登録、Git snapshot更新、
install、codex plugin list --json によるreceipt確認を一操作で行う。
python3 "$PLUGIN_ROOT/scripts/install-codex-plugin.py" \
--source /absolute/path/to/repository --plugin <plugin-name>
GitHub では marketplace 定義が merge された ref を指定する。
python3 "$PLUGIN_ROOT/scripts/install-codex-plugin.py" \
--source owner/repo --ref main --plugin <plugin-name>
hook trust はinstallerも代行しない。current command/eventを /hooks またはPlugins画面で
確認してユーザーがtrustし、新規threadで確認する。
失敗時
- Claude manifest が無い、name 不一致、plugin が
plugins/外なら書き込まず停止。 --checkは常に無書込。- install / enable / hook trust は package generator が代行しない。
- Codex で公式対応されない Claude 固有 surface を推測配置しない。
レビュー
まだレビューはありません。使ってみた感想をお寄せください。
同じリポジトリのスキル
概要と使いどころ
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 基準で機械検証したいときに使う。