GoalBuddy 0.3.8: Runtime Cleanup and Board Polish

GoalBuddy 0.3.8 is live on npm as the latest release.

Highlights

• Added explicit local-board hub guardrails so unregistered board paths explain hub reuse instead of looking like stale-port failures.
• Show readable board card titles while preserving full objectives.
• Sort completed board cards newest-first.
• Fixed relative goal path handling for child CLI processes while preserving non-path option values such as --task T001.
• Aligned rendered receipt schemas with bundled Scout, Worker, and Judge agent contracts.
• Added Codex doctor reporting for residual runtime states.
• Added goalbuddy reset --target codex for GoalBuddy-owned Codex cleanup.
• Cleaned root release docs and removed stale top-level examples from the npm package.

Verification

• npm run check: 78 passing
• npm run publish:check: passed before publish
• npm view goalbuddy version: 0.3.8

Install

npx goalbuddy

GoalBuddy 0.3.7: Goalmaxxed

GoalBuddy 0.3.7: Goalmaxxed

Release date: 2026-05-19

Goalmaxxed is the release where GoalBuddy stops trying to become a workflow catalog and commits to one sharper job:

Give /goal enough pressure that it keeps working until the original outcome is actually true.

This release is heavily inspired by the Codex maxxing playbook: keep the goal visible, preserve context in local files, use subagents deliberately, demand evidence, and resist the temptation to declare victory because a plausible slice finished.

Update with:

npx goalbuddy update

The Headline

GoalBuddy now centers the native /goal loop around five small ideas:

• Intent: capture what the owner actually wants.
• Oracle: define the observable signal that proves the outcome is real.
• Surface: keep one local board visible while the run moves.
• Loop: Scout maps facts, Judge chooses the largest safe useful slice, Worker completes the whole slice.
• Proof: final completion requires receipts mapped back to the oracle.

That is the product. Everything else got judged against that loop.

Goal Pressure

GoalBuddy now treats the goal oracle as first-class state. A serious goal needs an observable signal before the board can pretend it knows what done means:

• a passing test suite
• a browser walkthrough
• a demo transcript
• a generated artifact
• a benchmark
• a source-backed answer
• a release check
• a final human decision

No oracle, no serious goal.

The checker also rejects weak final completion. A goal should not be marked done just because the active task ended. Done means a final Judge or PM audit records that the receipts and verification satisfy the oracle.

Larger Useful Slices

This release sharpens the slice policy:

Safe does not mean small. Safe means bounded, explicit, verified, and reversible.

GoalBuddy now pushes Judge and Worker toward the largest safe useful slice: a working screen, working API path, backend vertical slice, real bug fix, data pipeline step, or milestone review.

The board warns when it sees micro-slicing: helper files, contracts, proof notes, or tiny prep tasks that are safe but do not move the owner outcome.

Built-In Local Board

The local board is now a core surface, not an extension.

The bundled surface lives at:

goalbuddy/surfaces/local-goal-board/

It remains the default way to watch a GoalBuddy run: active task, blocked state, receipts, verification status, subgoals, and board switching all point back to the same state.yaml truth.

No Extension Catalog

GoalBuddy no longer ships a public extension catalog.

The old catalog made the product look bigger while making the core loop blurrier. Goalmaxxed chooses the smaller invariant:

GoalBuddy prepares and pressures /goal runs. Custom integrations are ordinary repo work.

If a team wants a GitHub, Linear, Slack, or release integration, they should prepare a concrete implementation plan in their repo and build it as normal software. GoalBuddy should not install arbitrary workflow packs as a side channel.

Simpler Public Surface

The public copy now says what GoalBuddy actually does:

• prepares /goal
• writes goal.md and state.yaml
• creates a goal oracle
• opens a local board
• keeps Scout/Judge/Worker handoffs receipt-shaped
• prevents early completion
• leaves custom integrations outside the core

The Codex and Claude Code plugin manifests are aligned with the package description, and the test suite now checks that the Claude manifest stays in sync.

Release Boundaries

This release intentionally does not add:

• an extension marketplace
• automatic parallel-agent spawning
• hosted board state
• automatic receipt application
• UI controls that mutate board state
• a replacement for native /goal

GoalBuddy stays local, file-backed, and boring in the parts that should be boring.

Package Notes

This release updates:

• npm package version: 0.3.7
• Codex plugin version: 0.3.7
• Claude Code plugin version: 0.3.7
• package contents to include goalbuddy/surfaces/
• mirrored GoalBuddy skill files under plugins/goalbuddy/skills/goalbuddy/

Before publishing, verify:

npm run check
npm run pack:dry-run
node internal/cli/check-publish-version.mjs

GoalBuddy v0.3.5

GoalBuddy 0.3.5: Subgoals, Parallel Agents, and Dark Mode

Release date: 2026-05-12

This is the release where GoalBuddy starts feeling less like a single board and more like a calm local workspace for serious agent work.

0.3.5 adds three big things:

• Subgoals: depth-1 child boards for branching work.
• Parallel agents: safe, explicit surfaces for parallel Scout, Judge, and bounded Worker handoffs.
• Dark mode: a cleaner local board that can stay open all day without punishing your eyes.

Under the hood, this release also hardens GoalBuddy's execution model: stricter agent contracts, deterministic task prompts, conservative parallel planning, stronger checker rules, and safer child-board rendering.

Update with:

npx goalbuddy update

The Headline

GoalBuddy still has one simple job: keep long /goal runs oriented until the real outcome is done.

0.3.5 makes that loop much easier to run when the work branches, when more than one agent is helping, or when you want a live board open beside Codex or Claude Code.

The model stays intentionally small:

• goal.md is the charter.
• state.yaml is the ledger.
• A board is a view of one state.yaml.
• A subgoal is one depth-1 child state.yaml linked from a parent task.
• The local hub is navigation, not workflow truth.
• Viewer settings are preferences, not state.

Subgoals

Subgoals give GoalBuddy a clean way to branch without turning into project-management software.

A parent task can now link to a child board under subgoals/:

subgoal:
  status: active
  path: subgoals/T004-board-view/state.yaml
  owner: Worker
  created_from: T004
  depth: 1
  rollup_receipt: null

The local board renders that child board inside the parent task detail, so you can open one task and see the focused child workflow underneath it.

What this is good for:

• a parent task that needs a focused implementation branch
• a verification slice that deserves its own mini-board
• a Scout/Judge/Worker path that should stay bounded
• parallel work that needs a visible surface without losing the parent context

What it is not:

• recursive planning
• nested subgoals
• a separate project hierarchy
• a new source of truth

One parent task can have one depth-1 child board. That is the whole trick.

Parallel Agents

GoalBuddy 0.3.5 is parallel-agent-ready, but deliberately not an automatic scheduler.

That distinction matters.

GoalBuddy now helps you prepare safe parallel work surfaces:

• Scouts are read-only and safe to run in parallel by default.
• Judges are read-only and safe on separate board decisions.
• Workers are only safe when they are on separate boards or have provably disjoint allowed_files.
• Ambiguous Worker write scopes fail closed.

Use the new planner:

goalbuddy parallel-plan docs/goals/<slug>

It reports active tasks across the parent board and linked child boards:

• board path
• task id
• role
• recommended agent
• reasoning hint
• whether it is safe to parallelize
• why
• the exact prompt-render command

It does not mutate state. It does not spawn agents. It does not pretend overlap is safe.

That keeps GoalBuddy in the sweet spot: it makes parallel execution easier to see and safer to hand off, while native Codex or Claude Code agent flows still do the actual dispatch.

Dark Mode

The local board now has real dark mode.

Not "the background changed and half the text disappeared" dark mode. The board, task cards, modals, settings, detail sections, receipt text, and embedded child boards all get readable dark styling.

The board also adds global viewer settings:

• Theme: system, light, dark
• Density: comfortable, compact
• Completed column: show, collapse
• Open boards: last viewed, newest
• Motion: system, reduce, allow

Settings are local viewer preferences and live at:

~/.goalbuddy/local-board-settings.json

Tests can override that path with:

GOALBUDDY_LOCAL_BOARD_SETTINGS_PATH=/tmp/goalbuddy-settings.json

The Local Board Got Sharper

The board header now matches the GoalBuddy site style more closely:

• GoalBuddy mark and wordmark
• green live blip beside the wordmark
• board selector only when multiple boards are running
• GitHub stars link that opens in a new window
• cleaner settings gear

Multiple boards now share one readable local hub:

http://goalbuddy.localhost:41737/

Each board gets its own path:

http://goalbuddy.localhost:41737/subgoal-parent-board/
http://goalbuddy.localhost:41737/local-kanban-board-extension/

Launch another board while the hub is already running and GoalBuddy registers it with the existing local server instead of replacing the first board.

If port 41737 is occupied by something that is not GoalBuddy, the CLI says so clearly.

Active Work Is Easier To See

Active cards now have a visible in-progress treatment: a subtle moving border that makes the current task obvious at a glance.

The motion respects:

• prefers-reduced-motion
• the board Motion setting

So the board can feel alive without becoming noisy.

Better Agent Contracts

Scout, Judge, and Worker now have sharper contracts.

Scout:

• read-only
• compact evidence
• no edits
• no task selection
• receipt-shaped output

Judge:

• read-only
• phase gates and risky decisions only
• completion skepticism
• parallel-safety decisions
• subgoal approval boundaries

Worker:

• edits only allowed_files
• runs listed verification
• stops when scope expands
• returns changed files and verification results
• treats parallel Worker safety conservatively

This is the durable GoalBuddy model:

Scout maps. Judge gates. Worker patches. Receipts prove. state.yaml decides.

Deterministic Prompt Rendering

New command:

goalbuddy prompt docs/goals/<slug>
goalbuddy prompt docs/goals/<slug> --task T004
goalbuddy prompt --board docs/goals/<slug>/state.yaml --task T004

The renderer emits compact task-specific prompts with:

• board path
• task id
• task type
• objective
• inputs
• constraints
• allowed files
• verify commands
• stop conditions
• reasoning hint
• recommended agent
• expected receipt shape

It avoids the bad handoff pattern where a subagent gets the entire state file, chat history assumptions, and too much inherited context.

Checker And Durability

The checker now understands 0.3.5 branching.

It accepts:

• depth-1 subgoals under the parent goal root
• child boards with goal.md, state.yaml, and notes/
• parent tasks linked to valid child boards
• Worker changed files that match simple allowed_files globs

It rejects:

• child paths outside the parent root
• child paths that do not point to state.yaml
• missing child state files
• nested child subgoals
• invalid child board state
• done Workers with changed files outside scope
• final completion without the expected verification and audit evidence

The board renderer also fails closed on invalid child paths, so a malformed subgoal cannot make the local board read a state.yaml outside the parent goal root.

Demo

Run the bundled parent/child board:

node goalbuddy/extend/local-goal-board/scripts/local-goal-board.mjs \
  --goal goalbuddy/extend/local-goal-board/examples/subgoal-parent

Then try:

• switch to dark mode from the gear menu
• open task T004 to see the embedded child board
• launch another board and use the header selector
• run goalbuddy parallel-plan goalbuddy/extend/local-goal-board/examples/subgoal-parent
• run goalbuddy prompt goalbuddy/extend/local-goal-board/examples/subgoal-parent

Tests

0.3.5 adds or expands coverage for:

• parent task subgoal payloads
• embedded child boards
• missing child state files
• outside-root child paths
• live child-state updates over SSE
• multi-board hub registration
• settings persistence and normalization
• dark-mode readability surfaces
• prompt rendering
• read-only parallel planning
• overlapping Worker write scopes
• overlapping Worker glob patterns
• checker rejection for outside-root, missing, and nested subgoals
• plugin/source mirror consistency

Verified locally with:

npm run check
git diff --check
npm run publish:check

Release Boundaries

This release intentionally does not add:

• automatic parallel-agent spawning
• a parallel Worker scheduler
• automatic receipt application
• UI controls for creating or editing subgoals
• recursive/nested subgoals
• cloud-hosted board state

The principle is Karpathy-level simple:

One board owns one state file. A subgoal is one child state file. Parallel work is allowed only when the write boundaries are clear.

That gives GoalBuddy a stronger execution loop without making it heavy.

Package Notes

This release updates:

• npm package version: 0.3.5
• Codex plugin version: 0.3.5
• Claude Code plugin version: 0.3.5
• mirrored GoalBuddy skill files under plugins/goalbuddy/skills/goalbuddy/

---

0.3.6 patch update

Published on npm as goalbuddy@0.3.6.

This patch keeps the 0.3.5 release line focused while tightening the everyday execution path:

• Shorter, friendlier local-board card titles while preserving the full task objective in details.
• Codex install/update now follows the canonical plugin-only path and cleans up stale personal GoalBuddy skill installs.
• Spawn prompts now expose the exact required GoalBuddy agent type, so Scout/Judge/Worker dispatch is harder to drift.
• Local board parsing is more forgiving for real-world state files: legacy complete / completed statuses normalize to done, and malformed deep receipt/check metadata no longer blanks the board.

Contributor thanks: @jjoanna2-debug for the Codex install complexity report in #16, and @millionart for the local-board parsing hardening work in...

v0.3.0 — Claude Code support

GoalBuddy now installs into both Codex and Claude Code with a single npx goalbuddy run. The shared /goal workflow is unchanged; this release makes Claude Code a first-class target and turns GoalBuddy into a bilingual operating system for long-running agent work.

Install

npx goalbuddy                  # Codex + Claude Code
npx goalbuddy --target codex   # Codex only
npx goalbuddy --target claude  # Claude Code only

Use

Platform	Prepare a board	Run
Codex	$goal-prep	/goal Follow docs/goals/<slug>/goal.md.
Claude Code	/goal-prep	/goal Follow docs/goals/<slug>/goal.md.

What's New

• One command installs both targets. npx goalbuddy enables the native Codex plugin in ~/.codex/, then installs the GoalBuddy skill, Scout/Judge/Worker subagents, and /goal-prep slash command into ~/.claude/.
• Claude Code support is first-class. The package now ships a Claude Code plugin scaffold, markdown subagents, and a slash-command entry point alongside the existing Codex plugin path.
• Updates are seamless. goalbuddy update refreshes the Codex plugin and Claude Code skill/agents/command together unless --target narrows the command.
• Target-aware CLI and doctor checks. Use --target codex|claude, --codex-home, and --claude-home for explicit installs and diagnostics.
• Release docs are bilingual. README, site copy, plugin docs, package metadata, and skill docs now present GoalBuddy as a /goal operating system for Codex and Claude Code.

Compatibility

• Existing Codex-only automation can keep using --target codex or --codex-home.
• npx goal-maker remains a temporary compatibility alias and points users to goalbuddy.
• Installed extension folders are preserved across update/install refreshes.

Verification

• npm run check passed with 46 tests.
• npm run pack:dry-run produced goalbuddy-0.3.0.tgz with 97 files.
• Publish version check passed: goalbuddy@0.3.0 > published 0.2.22.

v0.2.12

• Enforce the strict GoalBuddy intake boundary: prepares the board and prints the /goal command instead of starting implementation, research, skills, browsing, or asset work.
• Generate the temporary -maker compatibility skill during install instead of packaging a second goal-maker/ skill payload.
• Add regression coverage for canonical, plugin, and compatibility skill behavior.

GoalBuddy v0.2.11

Provenance-backed patch release through npm trusted publishing.\n\nVerification before release:\n- npm run check\n- npm run pack:dry-run\n- node internal/cli/check-publish-version.mjs

goal-maker v0.2.5

goal-maker v0.2.5 — EXTEND

goal-maker turns open-ended Codex work into a local Scout/Judge/Worker board with receipts and verification.

This release introduces EXTEND: the foundation for optional Goal Maker add-ons that can move through a GitHub-hosted catalog instead of requiring a new npm release every time.

Install

npx goal-maker

Then invoke the skill inside Codex:

$goal-maker

What Changed

goal-maker extend

A new extension workflow is now part of the CLI:

goal-maker extend
goal-maker extend <extension-id>
goal-maker extend install <extension-id> --dry-run
goal-maker extend doctor <extension-id>

Use it to discover optional extensions, inspect what they read/write/require, install checksum-verified files, and check local configuration.

GitHub-hosted catalog

Extensions live under:

extend/
  catalog.json
  <extension-id>/

The npm package stays the stable core. The catalog can change on GitHub, which keeps optional integrations from forcing constant npm updates.

Cleaner package boundary

The installable skill payload is now focused:

goal-maker/
  SKILL.md
  agents/
  scripts/
  templates/

Package-only CLI and tests moved under internal/, and repo guidance now lives in AGENTS.md.

Core Model

vague goal -> discovery -> board -> one active task -> receipt -> board update -> repeat

Scout maps evidence. Judge resolves ambiguity and completion claims. Worker performs one bounded implementation task. The main Codex thread stays PM, and state.yaml remains the source of truth.

Examples

This release includes completed Goal Maker runs under examples/, including an extend-catalog-workflow example showing the path from product framing to implementation and cleanup.

Verification

npm run check
git diff --check
npm publish --dry-run --json

npm

Published package: goal-maker@0.2.5