Goal Instruction Writer: keeping multi-day Codex tasks on target

[wu736139669]

I maintain Goal Instruction Writer, an MIT-licensed Codex skill for keeping a long task tied to an observable outcome, a bounded loop, and evidence that another turn can pick up.

I built it around a recurring problem in multi-day game development and software delivery: the agent keeps working, but the original scope, valid verification results, or next step becomes harder to recover.

The workflow is:

1. Preview the outcome, loop, branches, evidence, and stops.
2. Agree on a Goal Anchor: outcome, acceptance criteria, scope, and authority.
3. Inspect, choose a work unit, act, verify, and save the result plus the next cursor.
4. Defer side work, realign after repeated actionable attempts add no progress or new evidence, and stop against explicit completion or budget conditions.

Verification is proportional to the change: focused checks during edits, reuse of still-valid evidence, and the required broader checks at delivery.

A real case behind it

The Factory Town Idle Godot case traces analysis on October 13, playable systems on October 14, and a 0.49 local candidate with matching Mac and Android packages on October 17. The record includes production, research, cross-town effects, save/load checks, and a concrete next rule audit.

My longest game-development workflow is estimated at 60+ elapsed hours. That is a maintainer estimate, not a measurement of uninterrupted agent compute. The case reports stage deliveries; the full recreation Goal was still active at that checkpoint.

Try a small preview first

Install:

npx skills add wu736139669/goal-instruction-writer \
  --skill goal-instruction-writer -g -a codex -y

Then paste this in a Codex chat in a repository:

Use $goal-instruction-writer in Preview mode.
Design a read-only Goal to audit local Markdown links in README.md and report
broken targets with proposed fixes. Limit the eventual audit to two passes.
Show the outcome, acceptance evidence, loop, checkpoint, and stop conditions.
Do not perform the audit or edit files yet.

Look for a finite loop, a clear definition of evidence, and a usable next step. The preview should not claim it already checked the links. Three short prompts cover a read-only task, verification cadence, and a bounded game slice.

This is an instruction package. The host supplies execution, persistence, wake-up triggers, and permissions. The scheduled-wait instructions have not yet been validated by a live wait/resume test. This is an independent community project.

I'd welcome concrete feedback on whether the preview exposes missing criteria, whether checkpoints preserve scope across turns, and where verification becomes repetitive.

Source and quickstart · 36-second English demo

If the workflow is useful, a star helps you keep the repository handy and follow new examples.

[bomtobe-hgkim]

That failure mode resonates: a long task needs a durable goal, evidence, and next action. I’d add a verification-freshness rule: if scope, relevant files, or the environment changes, mark affected checks stale instead of carrying them forward. How do you decide which results need rerunning after a goal change? Disclosure: I work at BOMTOBE on Orke, a desktop workspace for Claude Code and Codex; I can’t claim automatic evidence-to-revision attachment from the public product description.

[wu736139669]

Thanks — that’s a useful distinction. The skill’s current rule is to reuse evidence only while the acceptance criterion, source/artifact, relevant inputs, dependencies, and environment it covers remain valid.

After an approved goal change, the agent should review the affected acceptance criteria, mark dependent evidence stale, and rerun the relevant checks. Unaffected evidence can carry forward; newly added criteria need new evidence.

For example:

• A README typo fix should not invalidate unrelated runtime checks.
• A change to shared game-economy logic should invalidate affected balance, behavior, and integration results.
• A dependency or runtime change should invalidate checks that relied on that environment.

Required release checks still apply. Before rerunning anything, the agent should explain what changed and which previous result that change invalidates.

Today, this is an instruction-level contract for the agent to follow. Automatic revision-to-evidence tracking would require additional tooling. Your question highlights something worth making more concrete in the examples.