GoalBuddy 0.4.3: Restore Claude's Native /goal

GoalBuddy 0.4.3: Restore Claude's Native /goal

GoalBuddy now uses /goalbuddy for execution in Claude Code. Codex continues to use its native /goal feature. Both commands read and update the same repo-native GoalBuddy board.

What Changed

• Fresh Claude Code installs create ~/.claude/commands/goalbuddy.md, not goal.md.
• Updates remove the old ~/.claude/commands/goal.md only when GoalBuddy can identify it as a GoalBuddy-authored file.
• A user-authored goal.md is never deleted. The installer warns, and goalbuddy doctor --target claude reports that Claude's native /goal remains shadowed.
• Goal Prep, goalbuddy init, and goalbuddy resume print the correct continuation command for each harness.

Continue a Board

In Codex:

/goal Follow docs/goals/<slug>/goal.md.

In Claude Code:

/goalbuddy Follow docs/goals/<slug>/goal.md.

The command names differ, but state.yaml, receipts, task ownership, and completion proof remain portable between the two harnesses.

Upgrade

npx goalbuddy@latest update

Restart Claude Code after updating, then use /goalbuddy for GoalBuddy execution. Your native /goal command is available again when no separate ~/.claude/commands/goal.md file exists.

GoalBuddy 0.4.2: Honest Continuation State

GoalBuddy 0.4.2 fixes a continuation gap exposed by a real-world GoalBuddy run. The executor completed one task, activated the next task, and then ended its host turn normally. The local board stayed available because it was only displaying state.yaml, which made an unattended goal look active.

What changed

Stop decisions are now machine-checkable

Run:

goalbuddy can-stop docs/goals/<slug>

The command exits nonzero while a valid active task remains. It permits a host turn to end only when the full outcome has a valid completion audit or the board records GoalBuddy's exact terminal approval-wait shape.

Receipt transitions name the next obligation

After goalbuddy receipt records a receipt and activates the next task, its report now includes:

• stop_allowed
• continuation_required
• next_action

This puts the continuation verdict at the exact transition where the prior run stopped.

The board is honest about what it knows

The browser surface now calls itself a local state viewer. For an active board, executor status is Not observed. A running board server proves only that the viewer is available. It does not prove that a Codex or Claude Code executor is working.

Native waits are durable and bounded

A native wait_agent timeout ends only one observation window. GoalBuddy checks live agent state and messages through bounded, role-aware windows instead of abandoning Scout, Judge, or Worker after the first timeout. Scout and Judge are read-only, so missing file changes are never treated as evidence that they stopped.

External CLI dispatch keeps different semantics: --timeout is a hard execution deadline and returns a terminal failure. Its report now includes the post-timeout scope check so the PM can see and inspect partial writes before fallback.

Enforcement boundary

The state predicate and receipt-transition verdict are enforced by GoalBuddy's CLI and test suite. A host that ignores the execution contract can still end its own turn, because Codex does not currently expose a verified GoalBuddy-controlled blocking turn-end hook here. This release does not claim an always-on supervisor, heartbeat, or automatic restart.

The next candidate feature is a bounded goalbuddy continue command that owns one check, dispatch, receipt, and recheck cycle. It is intentionally not included in this patch.

Verification

• Canonical and plugin skill trees match.
• Active, complete, and exact approval-wait stop decisions are covered.
• Receipt activation returns a continuation requirement.
• The board does not claim unobserved executor liveness.
• Native observation waits and external hard execution timeouts stay distinct.
• The complete package test suite passes.

GoalBuddy 0.4.1: Installed Contract Fixes

GoalBuddy 0.4.1: Installed Contract Fixes

GoalBuddy 0.4.1 fixes two installation and routing gaps reported by contributors after the cross-harness release.

Complete npm Skill Payload

The npm package now includes the entire canonical goalbuddy/ skill directory. This restores references/goal-execution.md for npm-channel installs, so /goal receives the same execution contract whether GoalBuddy came from npm or the plugin marketplace.

The regression test inspects npm's actual packed file list, requires parity between the canonical and plugin skill trees, builds a tarball, installs it into a clean temporary Claude Code home, and verifies the execution contract is present.

Exact Claude Code Role Routing

Task prompts now carry both harness-specific role identifiers:

Role	Codex agent_type	Claude Code subagent_type
Scout	goal_scout	goal-scout
Worker	goal_worker	goal-worker
Judge	goal_judge	goal-judge

Claude Code must invoke the exact named GoalBuddy role through the Agent tool. Generic Explore and general-purpose agents are not substitutes because they bypass the role prompt, tool limits, and receipt contract.

An unknown agent state now means availability has not been proven. /goal attempts the exact harness-specific role once and falls back to the PM only if the harness reports it unavailable or returns an error. The existing missing and bundled_not_installed fallback behavior is unchanged.

Verification

Before release:

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

The npm workflow runs only from a published GitHub release and verifies that its tag is exactly v0.4.1 before publishing through npm's trusted OIDC path.

After publication, verify that goalbuddy@0.4.1 contains goalbuddy/references/goal-execution.md, install into clean temporary Codex and Claude Code homes, and capture one Claude /goal run invoking a goal-* subagent type.

Thanks to floke75 for reporting the npm package omission and Xpos587 for tracing Claude Code's role-routing behavior.

GoalBuddy 0.4.0: Cross-Harness Goals

GoalBuddy 0.4.0: Cross-Harness Goals

GoalBuddy 0.4.0 makes goals portable across harnesses: the same board, started in Codex, resumes in Claude Code — and vice versa — because the goal's truth lives in your repo, not in any tool's session. The release also makes the documented commands real on Claude Code, splits the skill contract into explicit prep and execution modes, hardens the local board server and CLI, and locks the codebase against silent drift. Every contract change was exercised end to end by independent Opus and Sonnet agents before shipping.

Highlights

• Cross-harness goals. Harnesses churn; repos persist. A GoalBuddy board is plain YAML in docs/goals/, so any harness can pick it up: run goalbuddy resume in a repo to see every live board, its active task, and the exact /goal command to continue — identical in Codex and Claude Code. The execution contract defines the handoff (state.yaml receipts are ground truth regardless of which harness produced them; never reconstruct progress from chat history), and receipts may record an optional harness field so the board's history shows who did what across a handoff.
• Mixed fleets. Cross-harness goes one level deeper: the PM can dispatch an individual task to a different vendor's agent without leaving its own harness — best model for each role, one honest board. goalbuddy dispatch docs/goals/<slug> --to codex|claude-code runs the target CLI headless with role-appropriate sandboxing, extracts the goalbuddy_receipt_v1 from its output, and verifies write scope mechanically via git (worker changes must match allowed_files; scout/judge dispatches must change nothing). Scope violations fail the dispatch and leave the working tree for inspection. The dispatcher reports; only the PM records — the board ownership rule survives vendor boundaries.
• Field-tested workflow upgrades. Lessons from a real multi-day GoalBuddy run (17 logged observations) are baked into the contracts and tooling: goalbuddy init <slug> scaffolds a valid board from the templates, goalbuddy receipt applies board transitions atomically and fail-closed, worker receipts document in-scope deviations, workers treat a delivered receipt as their only valid stopping state, and judges derive allowed_files verbatim from plan file lists.
• /goal-prep surfaces as /goal-prep. Claude Code names skills by directory, so earlier installs listed the skill as /goalbuddy while the docs said /goal-prep. The skill now installs and ships in a goal-prep directory (matching its frontmatter name), and install/update migrates the legacy ~/.claude/skills/goalbuddy directory automatically. goalbuddy doctor --target claude reports legacy_skill_present until old installs are migrated.
• A real /goal command for Claude Code. The plugin ships commands/goal.md and the CLI installs ~/.claude/commands/goal.md, so the printed /goal Follow docs/goals/<slug>/goal.md. line runs a real command that loads the execution contract, instead of relying on implicit skill matching. (In Codex, native /goal remains the separate OpenAI-gated feature GoalBuddy prepares boards for.)
• Split contract: prep vs execution. SKILL.md now carries the $goal-prep contract plus the shared board model; references/goal-execution.md carries the /goal runtime contract (default bias, task rules, receipts, computed gate, blocked handling, continuation, completion). Three loaders keep the execution contract reachable: the /goal command reads it first, the generated charter's PM loop points at it, and SKILL.md points at it with inline fallback invariants.
• Receipt contract closed against real agent behavior. A done Worker receipt must list only passing commands; a red verify means blocked, not done, with the failure kept visible. Documented: the blocked Worker receipt shape with blocked_reason, the Judge worker_package slot carrying the exact next-Worker spec (objective, allowed_files, verify, stop_if), the strict T### task-id format, and the named pattern for a correct fix whose verify is blocked by an out-of-scope cause (block, spawn a scoped follow-up, never widen allowed_files mid-flight).
• Board server hardening. Unexpected Host headers and cross-site POST/PUT requests are rejected (closing DNS-rebinding reads and CSRF writes). Static serving refuses dot segments and directories. Degraded YAML parses render a visible warning banner instead of silently dropping tasks, and valid odd-indentation boards recover through the fallback parser. Settings updates merge over saved values instead of replacing them, and slug-collision boards report the deduplicated slug their URL uses.
• Checker and CLI fixes. check-goal-state.mjs accepts a goal directory as well as the state.yaml path, preserves # inside quoted values, and reports broken symlinks instead of crashing. The CLI validates --target, honors --json on argument errors, takes the last value for repeated flags, errors on missing option values, works with npm on Windows, writes ~/.codex/config.toml atomically, and install-agents.mjs no longer mistakes --force for a destination.
• Drift guard and CI. goalbuddy/ is the single canonical skill tree; plugins/goalbuddy/skills/goal-prep/ is a byte-exact mirror maintained by npm run sync:plugin and enforced by a test. A new GitHub Actions workflow runs the full check suite on Node 18 and 24 for every push and pull request — previously checks only ran at publish time, which is how tree drift shipped in earlier releases.

Why This Release Matters

Every harness's native planning state is trapped inside that harness's session. GoalBuddy's board never was — it lives in your repo — and 0.4.0 turns that architecture into a feature you can use: your goal outlives your tool. No harness vendor can build this portability themselves, because it structurally requires being neutral.

The two most-typed commands in GoalBuddy's docs — /goal-prep and /goal — also did not actually exist as typed on Claude Code before this release. Both are now real, installed surfaces on both channels (npx CLI and Claude marketplace).

The contract changes come from evidence, not speculation: independent Opus and Sonnet agents ran the prep and execution contracts against real boards with a seeded two-defect trap, an adversarial judge graded their artifacts, and the exact points where the two models diverged became the documentation fixes in this release. Both tiers now converge on honest, checker-valid board mechanics.

Verification

• npm run check (103 tests, including the new drift-guard, security, degraded-parse, and policy suites)
• npm run pack:dry-run
• node internal/cli/check-publish-version.mjs
• Agent test campaign: CLI functional sweep (14/14), board-server abuse probes (no crashes, no leaks), prep/execution roleplays on Opus and Sonnet with adversarial judging

Package Metadata

• npm package version: 0.4.0
• Codex plugin version: 0.4.0
• Claude Code plugin version: 0.4.0

Upgrade Notes

• Claude Code installs move from ~/.claude/skills/goalbuddy to ~/.claude/skills/goal-prep; npx goalbuddy update (or /plugin update goalbuddy@goalbuddy) migrates automatically and removes the legacy directory.
• A new ~/.claude/commands/goal.md is installed on the CLI channel; goalbuddy reset guidance is unchanged.
• Contributors: edit only the canonical goalbuddy/ tree and run npm run sync:plugin — the test suite fails if the mirror drifts.

Install

npx goalbuddy

For Claude Code marketplace installs:

/plugin marketplace add tolibear/goalbuddy
/plugin install goalbuddy@goalbuddy

GoalBuddy 0.3.9: Marketplace and Board Runtime Polish

GoalBuddy 0.3.9 is live on npm as the latest release.

Highlights

• Added a root Claude marketplace wrapper so /plugin marketplace add tolibear/goalbuddy can discover the existing GoalBuddy plugin.
• Made /goal-prep install-channel agnostic: model-run board, prompt, and parallel-plan commands now use bundled skill scripts instead of assuming npx goalbuddy or a global goalbuddy binary.
• Added install-channel-aware update and agent guidance for npm, pnpm, bun, mise, Claude marketplace, and unknown install channels.
• Stopped local-board flicker during rapid multi-write state.yaml task transitions.
• Let the local board render multiple active tasks in the In Progress column, so parallel/disjoint work stays visible.
• Added an exact-approval wait shape: ask once, preserve required_reply, set waiting_for_user_approval: true, and stop until the user replies.
• Added PM-owned board-health stewardship guidance without introducing an always-on steward actor.

Verification

• npm run check: 83 passing
• node internal/cli/check-publish-version.mjs: goalbuddy@0.3.9 > published 0.3.8
• npm run publish:check: passed before publish
• npm view goalbuddy version: 0.3.9
• npm view goalbuddy dist-tags.latest: 0.3.9

Install

npx goalbuddy

For Claude Code marketplace installs:

/plugin marketplace add tolibear/goalbuddy
/plugin install goalbuddy@goalbuddy

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.