既存skillの品質を実走eval駆動で反復改善したいとき、run-skill-live-trialの受け入れFAILやgoal-proxy乖離を改善に引き継ぐときに、PASS詐欺・context汚染・評価縮退を構造的に防ぐeval帰属改善ループとして起動する。
中文简介正在准备中。当前显示原文说明。
查看安装方法安装前可以查看交给 AI 代理的指令内容。
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を実行しない。
以下の既存workflow・goal-seek・評価・修正sectionはlight/standard/detailedが記録されてsemantic_evaluator_startedへ遷移した場合だけ実行する。release/exhaustiveは別の明示eventを必要とする。
配布注記: cross-skill refs (
../run-goal-elicit/,../run-build-skill/,../run-elegant-review/) は repo-bundled 前提 (単独配布非対応)。本 skill とrun-skill-live-trialは実行 acceptance 系としてローカル開発環境限定であり、量産先 plugin へは配備しない (正本:../run-build-skill/references/feedback-loop-deployment.mdの配備境界)。CI でも実行しない。
target skill の品質を「current proof の機械再利用判定 → 未解決分だけ fresh-context 並列実走 eval → 弱点 diagnose + PASS 詐欺審問 → skill 層を少数件 Edit → commit → GOAL VERIFICATION」で反復改善する eval 帰属のメタ改善ループ (skill が skill を改善する)。
score を上げる方法は 2 つある — generator (成果物を作る側) を本当に良くするか、evaluator を緩めて score を通すか。後者の方が速く score が上がるので、規律が無いと必ずそちらへ流れる (Goodhart の法則)。本 skill は skill 改善ループで起きやすいこの事故を 8 INVARIANTS で構造的に防ぐ。INVARIANTS を破る改善ループは、score がいくら上がっても失敗である。
<plugin>/<skill>) + task args + --goal (goal 正本へのエイリアス、後述) + ループパラメータ (既定値の正本は後述 loop_bounds.iter_improve) + 任意の current build handoff (verification contract / evidence dir / stage。不在は未解決扱いであり再利用扱いにしない)wrap-git-commit-safe 経由eval-log/<plugin>/<skill>/iter-improve/<run-id>/interrogation-log.jsonl — 毎 iter の PASS 詐欺自己審問ログ (schemas/interrogation-log.schema.json 準拠の必須 artifact)<date>-score.jsonl — 既存の **/*-score.jsonl 合流規約 (run-skill-rubric-governance の aggregate-evals.py が収集)。採点行は evaluator id / mode / rubric hash / 前提を携帯する。独自 sink 新設禁止intermediate.jsonl — obligation id / fingerprint / reuse|observe|adjudicate / evidence path を各 iter の task-graph trace と同じ行へ記録。証拠再利用専用の別 sink は作らないrun-skill-live-trial の受け入れ verdict FAIL、または goal 達成度と score の乖離 ⚠️ からの handoff を受けて起動する。plateau 突破を狙う単独起動も可。issue 更新 / close / push は呼び元責務run-codex-plugin-package <plugin> の冪等upsertを実行し --all --check exit 0 を完了条件に追加する。| 改善の性質 | 担当 | 規律 |
|---|---|---|
| 1 回のレビューの findings 一括改善 (eval 非帰属) | run-elegant-review Phase 3 (elegant-improvement-executor) | severity high 放置 0・DAG 全件消化 |
| 実走 eval 帰属の反復改善 | 本 skill | 1 iter 少数件 (INVARIANT 5) で効果帰属を保つ |
| artifact (生成物 1 個) の改善 | 量産 skill 側の feedback_contract 評価ループ | 本 skill の対象は skill 層 (SKILL.md / writer-prompt / scripts / schema) そのもの |
| evaluator 自体の盲点 | 本 skill の target を当該 evaluator skill に切替 | 「緩める」でなく「goal に寄せて作り直す」 |
eval 帰属反復と一括改善の 2 エンジンは編集エンジン・収束判定を共有しない (相互参照: agents/elegant-improvement-executor.md「適用層境界」)。
固定手順は書かず、ゴール+チェックリストへ向け局面を都度選択・反復する。正本: ../run-build-skill/references/goal-seek-paradigm.md。
target skill が goal-spec.json.goal を実走で達成する状態に改善され、その過程の全 iter が審問ログ・score jsonl・commit として eval-log に帰属記録され、収束宣言が GOAL VERIFICATION (実走成果物ベース・PASS|FAIL+blocker) で独立確認されている。
artifact 単体の改善は LLM 主観評価 ±3-5pt のブレに律速され plateau に張り付く。skill 層の構造改善 (prompt rules / script logic / schema 制約) だけが plateau を破り、並列衝突・orchestrator stall 等の実 bug を E2E で発見できる。だが skill 改善ループは generator でなく evaluator から腐る — INVARIANTS はこの構造事故への防御である。
references/goal-declaration.md) <!-- CL-1 exempt: iter 0 の手順前提 (goal-declaration.md 準拠の宣言記録) であり、達成判定は run dir の宣言実体で決定論確認する。semantic criteria の評価対象ではない -->interrogation-log.jsonl へ 1 行 append され schemas/interrogation-log.schema.json を通過する <!-- CL-2 -->loop_bounds.iter_improve.batch_per_iter_max 以下 <!-- CL-3 -->wrap-git-commit-safe 経由) <!-- CL-5 -->eval-log/<plugin>/<skill>/iter-improve/<run-id>/ に保存済 (score は *-score.jsonl 合流規約) <!-- CL-7 exempt: run dir への保存規約は path 実在と *-score.jsonl 形式の決定論検査で閉じる。semantic criteria の評価対象ではない -->sync-plugin-platforms.py --all --check が exit 0 <!-- CL-8 exempt: sync-plugin-platforms.py --all --check の exit 0 で閉じる決定論検査。semantic criteria の評価対象ではない -->python3 plugins/harness-creator/scripts/audit-capability-parity.py --repo-root . --all と python3 plugins/skill-governance-lint/scripts/lint-plugin-composition.py plugins/*/plugin-composition.yaml がともに exit 0。静的契約PASSをinstall/enabled/trust/new-session/runtime実証と混同しない <!-- CL-9 exempt: audit-capability-parity.py / lint-plugin-composition.py の exit 0 で閉じる決定論検査。semantic criteria の評価対象ではない -->intermediate.jsonl に action と evidence path がある <!-- CL-10 -->正本 6 ステップ (現状評価→手順生成→実行→検証→Anchor Step→反復) に従い、下記局面カタログから未達チェックリスト項目を埋める局面を都度選ぶ。ループパラメータ (反復上限 / iter あたり投入件数 / 並列 agent 数 / score 閾値) の生値は本文に書かず、../run-elegant-review/references/convergence-policy.json の loop_bounds.iter_improve (max_iter / batch_per_iter_max / parallel_agents_default / score_threshold_default) を唯一の正本とする (二重宣言禁止)。
semantic_evaluator_started 後、iter 0 は GOAL DECLARATION → proof plan → unresolved eval → 集計+審問 → edit → 独立判定 → commit → GOAL VERIFICATION、後続 iter は GOAL DECLARATION を再生成せず proof plan から始める checklist として同 run dir の progress.json へ保持する。実際の進行は depends_on が全て done の item に限定し、別状態は作らない。
scripts/extract-ready-set-from-checklist.py <run-dir>/progress.json を実行し、ready 集合の最小 id だけを選ぶ。unresolved eval item は tier を保ち、live は run-skill-live-trial の live_batches、fork は Agent Team、static は決定論 check へ送る。fork は未解決 obligation 数と N の小さい方だけを並列実行し、個別 run dir のみを write scope として全結果の fan-in 後に done にする。reuse だけなら Agent 0 体で evidence path を記録して done にする。edit / commit は単一 writer で直列実行する。scripts/build-self-reflection-entry.py で次 iter chain を直前 verification 依存の sink として追記する。独立判定不要時も「発火条件非該当」証跡を残して done にし、依存を飛ばさない。追記 item を全て done にするまで self-reflect 完了 gate を閉じる。<run-dir>/intermediate.jsonl の各周回に ready_set / selected_item / original_goal / merged_directive_for_next と obligation の fingerprint / action / evidence_path を追記する。selected_item は ready_set 最小 id、その依存は過去に全て done であることを検証し、トレース不在を依存順消費や proof 再利用の成功に畳まない。required_keys と original_goal_hash を読み、hashlib.sha256 で不変性を確認する。着手前に scripts/extract-capability-dependency-graph.py を実行し、再利用価値のある依存判断だけを scripts/build-capability-graph-knowledge-entry.py で dependency graph knowledge へ記録する。| # | 不変条件 | 実体 |
|---|---|---|
| 1 | PASS 詐欺禁止 | 本文 (下記) |
| 2 | context 汚染回避 | 正本: goal-seek-paradigm.md「コンテキスト分離」節。改善の正否は改善履歴を知らない fresh-context agent にのみ判定させ、orchestrator の「良くなった」体感を証拠にしない |
| 3 | goal ≠ proxy | 正本: goal-seek-paradigm.md「達成判定 (GOAL VERIFICATION)」節。goal アンカー正本は goal-spec.json.goal / original_goal 単一系、--goal は正規化書込/読取エイリアス (二重宣言禁止) |
| 4 | 構造改善 > 対症療法 | 本文 (下記) |
| 5 | 1 iter 少数件 | 本文 (下記) |
| 6 | eval-driven commit | 正本: run-elegant-review「副作用境界 / ロールバック (B7)」+ wrap-git-commit-safe。commit は eval data 取得後のみ、speculative な先回りは regression の温床 |
| 7 | 自己適用安全 | 正本: scripts/feedback_contract_ssot.py の requires_subject_copy 述語。エンジン閉包 (ENGINE_SKILLS) と交差する時のみ被験体を scratch copy して編集し、通常 skill は直接編集を維持 |
| 8 | 評価縮退禁止 | 本文 (下記) |
2 / 3 / 6 / 7 は正本の再実装禁止 — 本表の 1 行相互参照のみを持つ。
score を上げる手段に「evaluator を緩める / 採点 mode を易しく倒す / threshold を下げる / 採点対象を goal から外す / 評価方法を差し替える」が含まれたら、それは改善でなく詐欺。手段 (target ファイル編集 / spec・入力編集 / 引数 / 環境変数 / 評価手順の差し替え) を問わず効果で判定する。構造防御は 3 点:
references/goal-declaration.md の手順で goal-spec の forbidden_loosening[] へ格納する。一般形は convergence-policy の anti_patterns が正本 (target 固有の具体形のみ宣言、再掲禁止)interrogation-log.jsonl に記録する (schema 準拠。保存は必須成果物 — 記録の無い iter は INVARIANT 1 違反とみなす)schemas/interrogation-log.schema.json の allOf が機械正本。独立判定が「緩め (loosening)」なら自己審問より外部判定を優先して破棄する弱点を観測したら「1 入力固有か / 複数 sample で再現するか」を必ず判定する。複数 sample で再現した弱点を入力側で手直しするのは敗北 — skill 層 (SKILL.md / writer-prompt / scripts / schema 制約) に safety net を入れる。1 箇所の skill 改修が全入力に波及する改善だけが plateau を破る。
1 iter の改善投入は loop_bounds.iter_improve.batch_per_iter_max 件以下。一括投入は消化不良で後退する (実証根拠: 一括投入時に平均 88→72)。この上限は eval 帰属 (どの編集がどの score 変化を起こしたか) を保つためのものであり、eval 非帰属のレビュー一括改善 (elegant-review Phase 3 の DAG 全件消化) とは適用層が異なる (境界の相互参照: agents/elegant-improvement-executor.md「適用層境界」)。
「実走が重い」を理由に実評価を SKILL.md 静的レビューへ置換するのは evaluator 緩和と同型の PASS 詐欺 (INVARIANT 1 の特殊形)。本 INVARIANT の輸入スコープは behavioral claim (自走完遂 / goal 達成などの実挙動) 限定で、design claim (設計 adequacy) は従来通り content-review / elegant-review / rubric が正本 — Gate 帰属は ../../references/orchestrate-gate-pattern.md「Gate D」を参照。
references/goal-declaration.md の 3 ステップ (goal 正本読取 / proxy 妥当性審問 Yes|No+根拠 / 緩め禁止リスト宣言→goal-spec 拡張 field 格納)。これを飛ばしたループは INVARIANT 3 違反。
差分再評価・証拠再利用の正本は ../run-build-skill/references/verification-obligation-protocol.md。claim / 対象 input slice digest / checker または scenario 契約 / upstream fingerprint が同じ current PASS receipt だけを reuse し、どれかが変わった claim と未解決 claim だけを observe|adjudicate へ送る。changed_paths[] や「影響なし」という自然文自己申告で省略しない。
{elegance,rubric}-verdict.json の SHA 一致だけは高速 pre-filter であり、再利用の十分条件にしない (content-review-protocol.md)。run-skill-live-trial の incremental planner が reuse とした schema-valid PASS verdict + behavior closure digest + stable scenario id + transcript digest、または同じ情報へ束縛された current observational receipt だけを再利用できる。content-review / 静的 rubric は behavioral claim を閉じない。escalate|defer として停止理由へ残す。reuse|observe|adjudicate、fingerprint、evidence path を <run-dir>/intermediate.jsonl に記録する。build handoff に verification contract / evidence dir / stage がある場合は、Agent 起動前に正本 planner を同じ stage で再実行する。$PLUGIN/$SKILL は target、$RUN_ID/$RUN_DIR は本実行の固定 id / canonical run dir、$CONTRACT/$EVIDENCE_DIR/$STAGE は handoff から設定する。iter-improve 側から draft を release へ自動昇格しない。llm_batches[] / observational_queue[] のうち target claim だけが未解決 work で、reuse は起動対象でない。
python3 plugins/harness-creator/skills/run-build-skill/scripts/plan-verification-obligations.py \
--contract "$CONTRACT" --repo-root . --evidence-dir "$EVIDENCE_DIR" \
--profile incremental --stage "$STAGE" --run-id "$RUN_ID" --out "$RUN_DIR/verification-plan.json"
live tier の再利用可否は専用 planner に委ねる。action=reuse だけを閉じた behavioral claim とし、run は run-skill-live-trial へ、fork|static は対応する軽量評価へ送る。
python3 plugins/harness-creator/skills/run-skill-live-trial/scripts/plan-live-trials.py \
--plugin-dir "plugins/$PLUGIN" --eval-root eval-log --profile incremental \
--skill "$SKILL" --out "$RUN_DIR/live-plan.json"
verification plan から実行した新規判定は、将来の再利用前に同じ fingerprint へ束縛する。evidence file が無い判定や plan 外の obligation は receipt 化せず、未解決のまま残す。
python3 plugins/harness-creator/skills/run-build-skill/scripts/record-verification-evidence.py \
--plan "$RUN_DIR/verification-plan.json" --obligation-id "$OBLIGATION_ID" \
--status "$STATUS" --verifier-kind "$VERIFIER_KIND" --verifier-id "$VERIFIER_ID" \
--evidence-path "$EVIDENCE_PATH" --repo-root . --evidence-dir "$EVIDENCE_DIR" \
--run-id "$RUN_ID" --model-action-id "$MODEL_ACTION_ID"
main orchestrator は proof plan の未解決 obligation だけを実行する。action=run の live tier は run-skill-live-trial の live_batches どおり本物の session へ送り、Agent fork へ格下げしない。fork tier だけを parallel_agents_default を上限として同一メッセージ内に並列発火し、static tier は対応する決定論 check だけを実行する。同じ fingerprint の current PASS receipt を「念のため」再採点する Agent は起動しない。fork agent prompt の核:
あなたは context-fresh agent。この skill の改善履歴・前回 score・改善意図を一切知らない前提で作業する。
Skill({skill: "<target>", args: "<task args>"}) を起動し、完走後 <run-dir>/eval-output.json を Read。
goal-spec.json.goal の 1 文が達成されているかを score と別立てで採点し、根拠を 3 行で書く。
target skill のファイル編集は絶対禁止 (改善は呼び元の責務)。
報告: overall_score / breakdown / 弱点 top3 / goal 達成度 (score と別立て)。
plateau が 2 iter 続いたら、未解決 obligation の範囲内で prompt を model swap / persona / source 深度に variant 化して再 iter する。current PASS の sibling claim を variant 数合わせのため再実走しない。
Bash(run_in_background=true) の polling ループで今回 observe した eval の完了を待つ (eval-output.json の個数 or deadline 到達)。current fingerprint の reuse receipt と新規結果を区別して overall_score / breakdown / goal 達成度を集計し、run dir の <date>-score.jsonl へ append する。異なる fingerprint / evaluator 契約の score は同じ平均へ混ぜない。score 平均と goal 達成度平均の乖離が iter を追って開く場合、generator でなく評価が壊れている兆候 (INVARIANT 3 の警告 signal)。
batch_per_iter_max 件以下に絞るinterrogation-log.jsonl へ 1 行 append (schema 必須)。独立判定の発火条件該当時は別個体 fresh agent に改善 diff だけを渡し「generator 改善か / 緩め操作か」を判定させる (期待する答え・改善履歴・score は渡さない)skill 層を batch_per_iter_max 件以下 Edit する (writer-prompt の rule 追加 / SKILL.md の手順明文化 / scripts の bug fix と defensive guard 注入 / schema 制約強化)。禁止: evaluator / rubric / 採点 mode を「score を通すため」に緩める編集。rubric が goal の悪い代理と判明したら、それは「緩める」のではなく target を evaluator skill に切り替えて「goal に寄せて作り直す」別ループで行う。
eval data 確認後に 1 ロジック 1 commit (wrap-git-commit-safe 経由、INVARIANT 6)。message に iter 番号 / 観測根拠 (どの run のどの弱点) / 期待効果を書き、複数ロジックを 1 commit に混ぜない (revert 可能性を保つ)。
成功停止は 1 つだけ。score は診断信号であり、成功条件でも周回継続条件でもない (INVARIANT 3):
goal-seek-paradigm.md「達成判定 (GOAL VERIFICATION)」節。final goal の exact fingerprint に束縛された current observational PASS receipt があれば reuse し、なければ fresh agent が実走成果物 / 行動ログ実体を入力に PASS|FAIL + blocker 列挙のみを返す (点数出力禁止・SKILL.md 静的レビューでの代替禁止)。edit / scenario・checker 契約 / upstream proof の変更で当該 fingerprint が変われば必ず再観測するscore_threshold_default なら PASS 詐欺疑いとして扱い、blocker が改善可能かつ max_iter 未満の場合だけ次 iter へ進む。連続 2 iter +0 または max_iter 到達時も成功へ丸めず「score X / goal FAIL / 残 blocker」の INCOMPLETE として停止する停止時の最終報告に必ず含める:
| 役割 | 受け取る入力 | 禁止事項 |
|---|---|---|
| unresolved eval agent (最大 N 体) | target + task args + 割当 obligation のみ | 改善履歴・前回 score の知悉 / target skill ファイルの編集 / reuse claim の再採点 |
| 審問独立判定 agent | 改善 diff のみ | GOAL VERIFICATION agent との兼任 / 期待する答え・改善履歴・score の受領 |
| GOAL VERIFICATION agent (observe 時のみ) | 実走成果物・行動ログ実体のみ | 審問独立判定 agent との兼任 / score・breakdown・改善履歴の受領 / 点数出力 |
context: main 必須 — Skill → Agent 不可制約により、本 skill を Skill 経由で起動すると fan-out 用の Agent ツールが使えない。常に main 直下から起動するschemas/interrogation-log.schema.json が機械正本run-skill-live-trial / run-elegant-review (エンジン閉包) を target にする場合は INVARIANT 7 の scratch copy 必須。判定は requires_subject_copy 述語に委ね、閉包リストをここへ再掲しないreferences/goal-declaration.md — iter 0 GOAL DECLARATION 手順書schemas/interrogation-log.schema.json — 審問ログ契約 (独立判定発火条件の機械正本)run-skill-live-trial — 前段の実走受け入れ (Gate D)。FAIL / 乖離 handoff の供給元../run-elegant-review/references/convergence-policy.json — loop_bounds.iter_improve / anti_patterns の正本../run-build-skill/references/goal-seek-paradigm.md — コンテキスト分離 / 達成判定 (GOAL VERIFICATION) の正本../run-build-skill/references/verification-obligation-protocol.md — fingerprint / receipt / machine-first 差分再評価の正本../run-build-skill/references/content-review-protocol.md — design claim と legacy content-review verdict 投影の境界还没有评价。欢迎分享你的使用感受。
无需登录即可发表。欢迎分享使用感受、提问，或说明在哪些环境下无法运行。
还没有评论。来写第一条吧。
アプリ・Webサービス・業務ツールの制作を、証拠分析→確定的な初稿→要件定義→体験設計→機能分解→実装→品質ゲート→リリース判定の手順ゲート制で進めるスキル。質問で要件を埋めるのではなく、依頼文・既存コード・資料・ログから最有力案を選び、動く成果物を先に出して差分で改善する。ユーザーが「アプリを作りたい」「ツールを作って」「〜を自動化したい」「システム化したい」「要件定義」「仕様を決めたい」「UI/UXを設計して」「体験を良くしたい」「機能を洗い出して」「MVPを決めたい」「品質チェック」「リリースしていいか判断して」などと言ったら必ず使用する。外部データの取込・マスタ・締め処理を伴う業務システムでは references/data-lifecycle.md も併用する。新規・既存を問わずアプリの制作・改善・リニューアルで使用する。
中文简介正在准备中。当前显示原文说明。
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 基準で機械検証したいときに使う。
中文简介正在准备中。当前显示原文说明。