本文へ移動
cccskills
無料GitHub で公開

run-intake-finalize

intake 全 JSON を統合したいとき、intake.md と intake.json を Jinja2 で render して quality_gate と cross_check を通したいときに使う。

インストール方法を見る

含まれるファイル(7)

  • SKILL.md13.2 KB
  • prompts/R1-main.md7.1 KB
  • references/resource-map.yaml278 B
  • references/template-pointer.md277 B
  • references/validation-flow.md429 B
  • schemas/output.schema.json2.7 KB
  • workflow-manifest.json3.2 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-intake-finalize

Runtime root contract

  • runtime_root_policy: host-skill-path を適用する。
  • Claude Codeでは CLAUDE_PLUGIN_ROOT をplugin rootとして使用する。
  • Codexではホストが提示したこの SKILL.md のabsolute pathから、plugin manifestを持つ祖先を上方探索して論理 PLUGIN_ROOT を解決する。
  • cwd からplugin rootを推測せず、literal placeholderをshellへ渡さない。各shell invocation内で解決済みabsolute pathを PLUGIN_ROOT に設定する。
  • prompts/ 配下はこのowner Skill契約を継承する。

Purpose & Output Contract

Phase 9 担当。Phase 1-8 で生成された全 JSON / sheet.md / visuals.json を統合し、最終成果物 intake.md (人間向け) と intake.json (harness-creator 入力) を 決定論的に生成する。render-intake-final.py (Jinja2) と quality_gate.py / cross_check.py を順に exec する。harness-creator 引き渡し用の next-action.json は Notion 公開後の Phase 11 で生成する。

入力: Phase 1-8 の全成果物 + intake-final-template.md.tmpl + intake-final-schema.json 出力:

  • output/<hint>/intake.md
  • output/<hint>/intake.json (schemas/output.schema.json 準拠、validation field 必須。procedure 拡張時は sections.6_five_axes_summary.procedure と validation.procedure_completeness を含む)

完了条件: procedure dual-gate PASS (procedure + true_purpose 両方存在 + as-is フィールドへの to-be 非混入) + render PASS + quality_gate PASS (--require-procedure) + cross_check PASS。FAIL 時は validation.failures[].retry_phase を埋めて orchestrator へ返却 (procedure/purpose 欠落・to-be 混入は Phase4 へ差し戻し)。

Key Rules

  1. LLM は呼ばない: render は Jinja2、検証は決定論 script のみ。
  2. schema/template の正本: 旧 aggregator references を参照。Phase C で物理移管予定。
  3. 失敗時の戻り先明示: render fail → 該当 Phase へ、quality_gate fail → 該当軸の Phase へ、cross_check fail → 不整合元 Phase へ。
  4. 検証順序固定: render → quality_gate → cross_check の直列 (順序入替・並列起動禁止、atomic write 保証)。
  5. 日本語成果物: 本文・validation reason は日本語、schema key / CLI 引数 / path は英語。
  6. procedure dual-gate (purpose+procedure 両立): intake.json 生成前に ../../scripts/validate-procedure-completeness.py --interview <procedure を持つ入力> を実行し、procedure 完全性と as-is フィールドへの to-be 語彙非混入を確認する。exit0 のときのみ procedure を sections.6_five_axes_summary.procedure へ、その stdout を validation.procedure_completeness へ格納する。加えて ../../scripts/quality_gate.py --require-procedure で true_purpose と procedure の両方が非空であることを強制する。procedure/purpose 欠落または contamination 検出時は Phase4 へ差し戻す。contamination 差し戻しは同一 axis につき上限 2 回とし、超過時は contamination を warning へ降格して人間確認 1 回へ切り替え、ヒアリング全体を停止させない (goal-spec C2 の「停止しない」原則の escape)。

ゴールシーク実行

Goal

Phase 1-8 の全成果物を決定論的に統合し、schemas/output.schema.json 準拠の intake.md / intake.json を bit-identical な再現性で生成、validation.render / validation.quality_gate / validation.cross_check が全 PASS、または FAIL 時に failures[].retry_phase が必ず埋まり intake.json に validation サマリが書き戻されている状態。

Why

LLM 推論を混入させると同入力で差分が出て、後段 (run-notion-intake-publish 公開・diff 監査) が破綻する。検証 2 段 (quality_gate → cross_check) は順序固定でなければ偽陽性/偽陰性が混入する。固定手順を辿るのではなく、チェックリスト未充足を起点に必要 script をその都度起動して反復することで、入力欠落や中間生成物破損にも頑健になる。

完了チェックリスト (停止条件)

  • Phase 1-8 全成果物 (JSON / sheet.md / visuals.json) の存在と schema 適合を確認した
  • LLM 推論を呼ばずに Jinja2 / script のみで完了している
  • intake.json が schemas/output.schema.json に適合している
  • quality_gate.py と cross_check.py を順序通り (順序入替禁止) 実行した
  • FAIL 時に validation.failures[] の各項目に where / reason / retry_phase が明示されている
  • 同一 Phase 1-8 入力で intake.md / intake.json が bit-identical (determinism)
  • 不足成果物を推測補完していない (欠落は FAIL として返している)
  • intake.json.validation サマリ書き戻し済み (render / quality_gate / cross_check 各 enum)
  • procedure を持つ入力に対し validate-procedure-completeness.py が exit0 (完全性 + to-be 非混入) で、結果を validation.procedure_completeness へ格納済み
  • quality_gate.py --require-procedure が true_purpose と procedure の両方非空を PASS (いずれか欠落・contamination 検出時は Phase4 へ差し戻し)
  • contamination 差し戻しが同一 axis で 2 回を超えた場合は warning 降格 + 人間確認 1 回へ切り替え、停止させていない

未充足項目を特定 → 必要 script (render-intake-final.py / convert_md_to_json.py / quality_gate.py / cross_check.py) を該当ステップから起動 → validation 更新 → 再度チェックリストで自己評価、を反復する。固定手順は持たない。

参考: 主要 script 起動例

# render: output/<hint>/ 直下の per-phase JSON (無ければ context.json) を集約し
# Jinja2 で intake-final.md を生成する (引数は output_dir 1 つ)。
python3 ${PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT:-plugins/skill-intake}}/scripts/render-intake-final.py output/<hint>/
cp output/<hint>/intake-final.md output/<hint>/intake.md

# intake.md → intake.json (front-matter + sections を JSON 化)
python3 ${PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT:-plugins/skill-intake}}/scripts/convert_md_to_json.py \
  output/<hint>/intake.md output/<hint>/intake.json

# procedure dual-gate (intake.json 格納前): 完全性 + as-is フィールドへの to-be 非混入を
# 確認し、その stdout を validation.procedure_completeness へ格納する (C04 が再利用)。
python3 ${PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT:-plugins/skill-intake}}/scripts/validate-procedure-completeness.py \
  --interview output/<hint>/interview.json

# 検証 2 段 (順序固定): quality_gate → cross_check
# cross_check の引数順は <intake.md> <intake.json> (md が先)。
# procedure 拡張 intake は --require-procedure で purpose+procedure 両立を強制する。
python3 ${PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT:-plugins/skill-intake}}/scripts/quality_gate.py --require-procedure output/<hint>/intake.json
python3 ${PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT:-plugins/skill-intake}}/scripts/cross_check.py  output/<hint>/intake.md output/<hint>/intake.json

Step/Gate の機械可読定義は workflow-manifest.json (P1-collect / P2-render / P3-quality-gate / P4-cross-check) を参照。

Gotchas

  1. template / schema は移管前: 旧 aggregator references パスを直書きしている。Phase C で本 references 配下へ移管後にパス書き換える。
  2. render と quality_gate は単一発火点: 重複呼び出し禁止。orchestrator は本 Skill を 1 回だけ呼ぶ。単一発火点の SSOT 定義は ../run-skill-intake/SKILL.md 「単一発火点」項を参照。
  3. 並列起動禁止: 検証順序維持と atomic write 保証のため、本 Skill は直列・単発のみ。
  4. 欠落の推測補完禁止: Phase 1-9 成果物に欠けがある場合は FAIL として retry_phase を埋めて返す (補完しない)。

Additional Resources

  • workflow-manifest.json — Phase (P1-P4) / Gate (C1-C4) / resource の機械可読定義
  • schemas/output.schema.json — intake.json 出力契約 (validation field 必須)
  • prompts/R1-main.md — R1 責務プロンプト (7 層 Markdown、決定論実行指示)
  • references/template-pointer.md — Jinja2 テンプレ / schema の正本パス案内
  • references/validation-flow.md — render → quality_gate → cross_check の順序と失敗戻り先表
  • ../../scripts/validate-procedure-completeness.py — procedure 完全性 + as-is フィールドへの to-be 混入検出 (dual-gate 第一段, C02)
  • ../../scripts/quality_gate.py — --require-procedure で true_purpose+procedure 両立を強制 (C04)
  • references/resource-map.yaml — リソース一覧 (machine-readable)

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

app-excellence

無料日本語概要

アプリ・Webサービス・業務ツールの制作を、証拠分析→確定的な初稿→要件定義→体験設計→機能分解→実装→品質ゲート→リリース判定の手順ゲート制で進めるスキル。質問で要件を埋めるのではなく、依頼文・既存コード・資料・ログから最有力案を選び、動く成果物を先に出して差分で改善する。ユーザーが「アプリを作りたい」「ツールを作って」「〜を自動化したい」「システム化したい」「要件定義」「仕様を決めたい」「UI/UXを設計して」「体験を良くしたい」「機能を洗い出して」「MVPを決めたい」「品質チェック」「リリースしていいか判断して」などと言ったら必ず使用する。外部データの取込・マスタ・締め処理を伴う業務システムでは references/data-lifecycle.md も併用する。新規・既存を問わずアプリの制作・改善・リニューアルで使用する。

daishiman/harness-dev102026年10月10日 更新

app-orchestrator

無料日本語概要

Webアプリの準備→要件定義→設計→実装→公開→品質ゲートを実行する内部オーケストレーター。Claude Codeの /build-app /improve-app、Codexの $build-app / $improve-app から明示的に委譲された場合、custom agent起動時、または利用者が $app-orchestrator を明示した場合だけ使用する。一般のアプリ相談から暗黙起動しない。

daishiman/harness-dev102026年10月10日 更新

run-extract-blueprint が生成した章別ブループリントの忠実性を独立 context で評価したいとき、事実/推測区別と粒度と被覆を検証し draft_hash に束縛した PASS/FAIL verdict をローカル品質ゲート (C01 の周回内の受入判定・差し戻し) へ渡したいときに使う。

daishiman/harness-dev102026年10月10日 更新

assign-briefing-evaluator

無料日本語概要

確認点で利用者が見る深さを選んだあと打ち合わせ資料を作り手とは別の目で確かめたいとき、正確さ・言葉・見た目・シンプルさの指摘を資料の編集なしで受け取りたいときに使う。

daishiman/harness-dev102026年10月10日 更新

生成した handout 資料が初心者に伝わるか読みやすさレビューを依頼したいとき、独立 context のレビュアーから指摘と根拠つきの verdict を回収したいときに使う。

daishiman/harness-dev102026年10月10日 更新

Notion ページを描画する直前に粒度を検証したいとき、info-collector-agent ページと同等の section 充足度を section_canonical_map 基準で機械検証したいときに使う。

daishiman/harness-dev102026年10月10日 更新

daishiman のスキルをすべて見る

このスキルの問題を報告する