ワンクリックで
using-commitment-control-json
Use when executing a v2 cybernetic run whose only approved task authority is commitment.control.json.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
メニュー
Use when executing a v2 cybernetic run whose only approved task authority is commitment.control.json.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
Use when a formed task needs durable human-approved meaning, completion obligations, evidence claims, non-goals, or live/destructive authority boundaries.
Use when maintaining or resuming an existing v1 requirements.control.json run; new runs use forming-cybernetic-commitments.
Use when an existing v1 run must compile its reviewed control chain into runtime.control.json.
Use when optional local workflow guidance or legacy v1 workflow compatibility needs diagnosis.
Use when an existing v1 control chain requires design.control.json; v2 strategies remain agent-owned.
Use when cybernetic routing is requested but user input is pre-task intent or role-ambiguous context: confusion, dissatisfaction, risk sense, observed symptoms, failed attempts, method preference, process distrust, source material, declared current state, or unclear requested transformation.
SOC 職業分類に基づく
| name | using-commitment-control-json |
| description | Use when executing a v2 cybernetic run whose only approved task authority is commitment.control.json. |
Execute an approved v2 commitment without turning the execution strategy into human-approved control data.
The authoritative run files are:
commitment.control.json immutable after approval
progress.jsonl append-only execution facts
evidence/ content-addressed subjects and evidence
final-report.json completion claim, never self-authorizing
Design notes, plans, work packages, file lists, command lists, subagent choices, and strategy snapshots are optional agent-owned working material. They cannot change the commitment or authorize a completion claim.
Read references/runtime-control-detailed-rules.md before recording a typed
wait, receipt, evidence subject, final Gate, or successor transition.
Run:
python3 .agents/skills/using-commitment-control-json/scripts/commitment_runtime.py \
validate <run-dir>
Read commitment.control.json completely.
Treat objective, obligations, non_goals, and authority as immutable.
Keep strategy agent-owned; record revisions and diagnose repeated unchanged failure fingerprints instead of stopping for the user.
Continue automatically for implementation defects, failed approaches, stale working plans, artifact mutations, new counterexamples, and unexpected conditions that can be investigated with current authority.
Pause only in one of these typed states:
WaitingForHumanDecision: commitment meaning genuinely needs a human choice.WaitingForAuthority: a declared live/external/destructive action needs a
fresh matching grant.WaitingForExternalDependency: required external state is unavailable.ImpossibleUnderCommitment: evidence proves the commitment cannot be met.SupersededBySuccessor: a human semantic decision produced a separately
approved successor commitment; this run is terminal and never resumes.AbortedByUser: the user explicitly stops the run.There is no generic Blocked state.
commitment_runtime.py state returns a machine next_action, not a user
handoff prompt. Continue agent-owned actions in the current turn; ask a user
only when its action_owner is user.
Re-route ordinary direct work before a consequential claim or action when it discovers durable obligations, exact-subject evidence, non-goals, or authority.
For a declared action: enter the authority wait, obtain an exact fresh human grant, resolve that wait, then record the executed action with evidence. Actions are default-denied; never execute a forbidden action. Local reversible work is not consequential authority.
A runtime human semantic decision never resolves the old commitment. Form and
approve a successor, then record run.superseded; execute only the successor.
Create one role-aware commitment.evidence_subject for the exact candidate.
Bind every obligation, declared path, and result place to evidence for that
subject. A candidate/configuration/environment change creates another subject;
never mix subjects.
Use the event appender so validation and file locking happen before write:
python3 .agents/skills/using-commitment-control-json/scripts/commitment_runtime.py \
append <run-dir> --event-json '<json-object>'
Events are hash-linked. A final report binds the chain head, selected evidence event hashes, and exact final-Gate event hash.
Read ../_shared/counterexample-gate-protocol.md before executing the final
Gate.
After all obligation evidence is bound:
execute the independent falsification Gate against the exact subject and completion claim;
store a valid commitment.final_counterexample_review artifact and append
counterexample.review.completed after the evidence it reviews;
if a counterexample is established, continue agent-owned repair and rerun the
Gate; otherwise write final-report.json using only evidence events for that
subject;
run:
python3 .agents/skills/using-commitment-control-json/scripts/commitment_runtime.py \
verify <run-dir>
Claim success only when permits_goal_achieved is true. A failed Gate names
invalidated evidence; a pass needs changed replacement evidence for the same
obligation and exact final-report/Gate binding.