A small repo-aware CLI for turning a large software objective into a sequence of compact, verifiable Codex /goal tasks.
Codex goal mode works best when the target is clear, bounded, and verifiable. Big goals often fail because they are too vague, too broad, or missing a stopping condition.
This project helps bridge that gap by converting one large objective into a short chain of smaller goals that are easier for Codex to execute reliably.
Given a large objective and some repository context, it generates:
- a one-sentence final objective
- 3-7 smaller sequential goals
- done conditions for each goal
- validation steps for each goal
- ready-to-run
/goal ...commands
The current version focuses on planning, not execution.
codex-goal-parser has now completed its first reliability roadmap and is ready for broader real-world use as a planning helper.
Highlights in the current release line:
- automatic repo detection when running inside a project
- clearer output controls with
--outputand--output-file - richer repo-context ingestion for validation, structure, and framework hints
- stronger goal-type heuristics with broad-objective narrowing
- file-based planning inputs via
--issue-fileand--context-file - documented JSON output contract and fixture-based automated tests
Inputs
- a large user objective
- repository context
- optional constraints
Outputs
- a structured goal plan
- compact
/goalcommands that Codex can execute one by one
From npm after publish:
npm install -g codex-goal-parserFrom source while developing:
git clone https://github.com/Hanjo92/codex-goal-parser.git
cd codex-goal-parser
npm install
npm linkInstall the bundled Codex skill from this repository:
python3 ~/.codex/skills/.system/skill-installer/scripts/install-skill-from-github.py \
--repo Hanjo92/codex-goal-parser \
--path skills/codex-goal-parserRestart Codex after installing so it can discover the new skill.
Run the basic example:
npm run exampleRun the repo-aware release example:
npm run example:releaseRun the automated tests:
npm testRun the CLI directly with your own objective:
node ./src/index.js \
--objective "Migrate this old Node service to a cleaner TypeScript structure and make it safe to deploy." \
--repo-context "Node service with package.json, README, and deployment scripts." \
--constraints "Do not rewrite unrelated modules. Keep validation explicit." \
--output markdownIf you're already inside a project repo, it can inspect the current directory automatically:
node ./src/index.js \
--objective "Prepare this project for a safe public release." \
--constraints "Do not change runtime behavior unless needed." \
--output markdownYou can still point at a specific repo explicitly:
node ./src/index.js \
--objective "Prepare this project for a safe public release." \
--repo-path . \
--constraints "Do not change runtime behavior unless needed." \
--output markdownFor JSON output:
node ./src/index.js \
--objective "Refactor this service safely." \
--repo-path . \
--output jsonTo write the generated plan directly to disk:
node ./src/index.js \
--objective "Prepare this project for a safe public release." \
--output markdown \
--output-file ./plans/release-plan.mdYou can also drive planning from an issue/spec workflow:
node ./src/index.js \
--issue-file ./docs/issue-notes.md \
--context-file ./docs/architecture.md \
--context-file ./docs/release-spec.md \
--repo-path . \
--output markdownIf --objective is omitted, the CLI will try to derive it from the first issue/context document.
After npm link, you can use it like a normal command:
codex-goal-parser --objective "Refactor this service safely." --output markdownA shortened real example for a release-readiness objective:
## Final objective
Prepare this project for a safe public release.
## Recommended sub-goals
1. Audit release readiness
2. Close release gaps
3. Verify the release path
4. Document and finalize release readinessThe full generated output also includes done conditions, validation steps, and ready-to-run /goal commands for each step.
For machine-readable integrations, use --output json and see docs/output-contract.md.
When --repo-path is provided — or when you run the CLI inside a repo without passing repo context explicitly — the CLI currently looks at:
README.mdpackage.jsonpyproject.tomlMakefile- top-level file names
- highlighted source / test / docs / deploy directories
- a shallow directory tree
- common file extension counts
- test/config hints
- likely validation commands from scripts or Make targets
- lightweight language/framework signals from repo structure
- external issue/spec/architecture notes passed with
--issue-file/--context-file
The generated /goal commands use a compressed version of that context so they stay readable instead of becoming bloated.
- break a refactor into goal-mode checkpoints
- plan a migration as a chain of
/goalruns - turn a repo cleanup effort into testable phases
- derive goal-mode commands from a README, issue, or repo structure
- prepare a release plan with validation checkpoints
docs/— design notes and specexamples/— sample inputs and outputssample-plan.md— migration-style decompositionrelease-plan.md— release-readiness decomposition
prompts/— reusable prompts for Codex or Claudeskills/— installable Codex skill packagesrc/— CLI implementationtests/— fixture-based CLI tests
- Prefer small verifiable goals over ambitious vague ones
- Preserve dependency order
- Keep each goal bounded to one checkpoint
- Treat validation as mandatory
- Avoid producing an oversized backlog
- Compress repo context instead of dumping raw structure into every command
codex-goal-decomposer— ClawHub/OpenClaw skill for turning large goals into smaller goal-mode taskslazyGithub— helper project for publishing GitHub repos with README and About metadata filled properly
The first reliability roadmap is complete:
- CLI ergonomics and output handling
- Better repo-context ingestion
- Better heuristic quality and splitting behavior
- Richer input sources like issues/specs/docs
- Structured output contract and tests
- add more representative planning examples and fixtures
- expand repo ingestion to more languages and deployment layouts
- keep refining heuristics with real-world planning transcripts
- decide whether to add a more explicit typed planning core over time