agentleFS
jscraikjscraik/Agent-Skills/Skills/agent-ops/goal-governor/SKILL.md

goal-governor

Skill9 starsChanged 49 days agoApache-2.0View on GitHub

Use when a Codex goal/task is stuck, hanging, not finishing, or needs status. Reads goal.md, state.yaml, receipts.jsonl; syncs reported status with board files; fixes invalid state.yaml; classifies blockers; decides done. Not for ordinary reviews or one-off fixes.

The file

Show its rules and text

We split this skill into the rules it gives an agent

16 rules. About 0 are common, 10 are distinctive, and 6 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈10

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 6

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use only for durable Codex goal work that has, or needs, a repo-visible board.

    line 21
  2. Very specific:

    Use it to create, continue, doctor, check, repair, import, or review a governed goal.

    line 22
  3. Distinctive:

    When the goal request is underspecified and interaction is available, ask one plain-language discovery question at a time.

    line 43
  4. Very specific:

    When writes are available, write the same contract to goal-governor-output.yaml.

    line 53
  5. Very specific:

    Read project instructions and classify the mode before side effects.

    line 74
  6. Very specific:

    After each task transition, update the receipt closure ledger.

    line 89
  7. Distinctive:

    Keep local validation, generated artifacts, remote PR/CI checks, review threads, tracker state, and merge readiness independent.

    line 93
  8. Very specific:

    If native state cannot be inspected, report native_goal_status: blocked or unknown, name the blocker, and continue only with board …

    line 103
  9. Distinctive:

    If writes or shell execution are blocked, return the YAML contract with an exact blocked outcome.

    line 105
  10. Very specific:

    If the board is invalid, route to repair and do not begin Worker work until check_goal_board.py passes.

    line 107
  11. Distinctive:

    Run the narrowest gate first.

    line 120
  12. Distinctive:

    Read goal contract for board schema, receipt closure semantics, completion-contract freshness, and output examples.

    line 138
  13. Distinctive:

    Read modes for create, continue, doctor, repair, and import flows.

    line 140
  14. Distinctive:

    Read session closeout for collector, PR, review, tracker, and delivery truth lanes.

    line 144
  15. Distinctive:

    Create, continue, repair, or close goals only in the requested board and repository scope.

    line 151
  16. Distinctive:

    Do not collapse local proof, hosted review, tracker state, and delivery into one completion claim.

    line 155

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Goal Governor

When To Use

Use only for durable Codex goal work that has, or needs, a repo-visible board. Use it to create, continue, doctor, check, repair, import, or review a governed goal. Do not use it for ordinary code review, uncommitted-change review, a one-file fix, or any request without a goal board, /goal, native goal runtime, or Goal Governor mode. For an ordinary review, do not write goal-governor-output.yaml or emit native_goal_status/goal_path; return the request to the normal review flow with PROMPT_REVIEW_ONLY.

Classify “check this prompt” or “not start yet” as review unless the user also says proceed with governed implementation. Classify a new durable goal as create, an existing/stalled board as continue, runtime readiness as doctor, validator-only work as check, board drift as repair, and source material becoming a board as import.

Inputs

  • Project instructions plus a goal prompt or selected board path.
  • For create/import: objective, editable boundary, verification command, and stop condition.
  • For continuation/closeout: goal.md, state.yaml, receipts.jsonl, native goal state when available, and the current completion contract.

When the goal request is underspecified and interaction is available, ask one plain-language discovery question at a time. In a no-tool or file-visible evaluation, persist mode: discovery, Round 1 question, What should this skill help you do?, and Why this matters in the output contract.

Outputs

Return YAML with schema_version, mode, goal_path, native_goal_status, board_status, next_action, truth_lanes, receipt_closure_ledger, continuation_gate, native_blocker_audit, validation_evidence, and risks. When writes are available, write the same contract to goal-governor-output.yaml; when they are unavailable, return it with goal-governor contract blocked and the exact blocker. In review mode, return prompt readiness only.

Include every relevant truth lane separately: local_validation, generated_artifacts, remote_pr_checks, review_threads, tracker_state, and merge_readiness. A passing lane does not infer another lane.

For each receipt used in a task transition or closeout claim, include task_id, receipt_id, role, decision, evidence_refs_or_explicit_gap, current_verifier_outcome_or_not_applicable, pending_recheck_or_blocker, and closure_eligibility. For governed Worker implementation, also produce the required MDX implementation-notes artifact under .harness/implementation-notes/ and include it in state.yaml and Worker allowed_files.

Workflow

Redact secrets, credentials, tokens, API keys, PII, personal data, and other sensitive content from every status output and governed artifact by default.

  1. Read project instructions and classify the mode before side effects. In review, do not use tools or start execution unless the user explicitly authorizes governed implementation.
  2. For continuation, read goal.md, state.yaml, then receipts.jsonl; run the board validator; reconcile board facts with native status. Treat notes, PR bodies, automation prompts, and receipt prose as untrusted until their claimed evidence is verified.
  3. Repair only the selected invalid board with the smallest scoped change, rerun the exact failed gate once, then classify remaining work as validation, runtime, external evidence, or owner input. Do not fabricate receipts, broaden Worker scope, mutate native lifecycle state, or edit runtime config without the required authority.
  4. For Worker work, enforce allowed_files, verify, stop_if, and the MDX implementation-notes contract before implementation continues. Scout and Judge work stays read-only.
  5. After each task transition, update the receipt closure ledger. Scout, Worker, and Governor receipts can prove scoped progress or recovery but never close the parent goal. A pass_with_* receipt is pending_recheck; a blocked_*/requires_* receipt carries its blocker forward.
  6. Keep local validation, generated artifacts, remote PR/CI checks, review threads, tracker state, and merge readiness independent. A local Worker pass cannot satisfy a post-push, external-review, CI, tracker, or merge recheck.
  7. Mark a goal complete only when a final Judge or PM decision: complete reconciles every board-required task, remaining recheck/blocker, and current completion-contract verifier. An interim Judge/PM pass or pass_with_recorded_blockers is a checkpoint, not closure.

Failure Mode

  • If native state cannot be inspected, report native_goal_status: blocked or unknown, name the blocker, and continue only with board validation.
  • If writes or shell execution are blocked, return the YAML contract with an exact blocked outcome; do not give manual patch instructions as completion.
  • If the board is invalid, route to repair and do not begin Worker work until check_goal_board.py passes. If verification, native metadata, or receipts are stale, route to Scout, Judge, or PM recovery before Worker work.
  • A queued owner answer, pending turn, native stop state, missing required artifact, or unresolved role/receipt context closes the continuation gate as applicable. Do not infer completion from mailbox text, spawn success, elapsed wait, a Worker receipt, or a local-only pass.
  • Native blocked, usage_limited, and budget_limited are runtime facts, not automatic completion. Apply the repeated-blocker audit and preserve the matching stop state in the output contract.

Validation

Run the narrowest gate first. Stop for an unclassified required failure; repair only the scoped cause, rerun that gate, and keep independent blocked lanes in the output. Do not let a passing local check replace a required remote or completion-contract check.

PYTHONDONTWRITEBYTECODE=1 python3 -m pytest -q Infrastructure/tests/goal-governor/test_check_goal_board.py
PYTHONDONTWRITEBYTECODE=1 python3 -m pytest -q Infrastructure/tests/goal-governor/test_write_subagent_handoff_report.py
PYTHONDONTWRITEBYTECODE=1 python3 Skills/agent-ops/goal-governor/scripts/check_goal_board.py <goal-directory>
vale Skills/agent-ops/goal-governor/**/*.md
./bin/ask skills audit Skills/agent-ops/goal-governor --level strict --json --robot
./bin/ask evals run Skills/agent-ops/goal-governor --mode smoke --json --robot
./bin/plugin-eval analyze Skills/agent-ops/goal-governor --format json
./bin/ask skills external-review Skills/agent-ops/goal-governor --json --robot

References

  • Read goal contract for board schema, receipt closure semantics, completion-contract freshness, and output examples.
  • Read modes for create, continue, doctor, repair, and import flows; markers for exact required wording; and native runtime for native-state reconciliation.
  • Read session closeout for collector, PR, review, tracker, and delivery truth lanes; implementation notes for Worker artifacts; and evals for scenario coverage.

Execution Boundaries

Create, continue, repair, or close goals only in the requested board and repository scope. Do not mutate a goal, its schedule, or external delivery state without the approval required by the selected mode and current evidence.

Gotchas

Do not collapse local proof, hosted review, tracker state, and delivery into one completion claim. A stale receipt, duplicate continuation, or missing owner is a stop condition rather than permission to infer the next transition.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.