Skip to content

Releases: jpbaking/goal-ledger

v5.0.0 — portable agent authoring layout

Choose a tag to compare

@jpbaking jpbaking released this 29 Jul 11:28

Breaking packaging update: moves all five canonical skills and the validator to .agents/skills, adds byte-identical Claude mirrors and thin Cline workflows, supports Pi, and consolidates persistent rules through host instruction pointers.

Full Changelog: v4.0.0...v5.0.0

v4.0.0 — hand-off: planner/executor roles and a review gate

Choose a tag to compare

@jpbaking jpbaking released this 28 Jul 23:34

Goal Ledger was built for crash recovery. This release turns it into a hand-off framework: your strongest model writes a plan that a weaker model can actually carry out, and reviews the result before you accept it.

Model tiering is back, but as a runtime role split rather than the divergent per-harness content sets removed in v3 — every harness gets the same skills, and the tiering happens at execution time.

The hand-off model

  • A planner — your strongest model — plans, prepares Git, hands out phases, reviews at Gate D, and accepts.
  • An executor — a cheaper model, a subagent, or a separate CLI session — runs one assigned phase from its written instructions and stops.
  • Execution mode: solo puts both roles in one session; the gates still apply.

The executor's standing instruction is escalate, do not improvise: when it meets a decision the phase file does not answer, it records needs-human — reason: <the exact question> and stops. A stopped phase is a clean hand-off; a phase finished by guessing is a mess the planner has to find.

Breaking changes

  • Ledger format v2. GOAL.md requires an ## Execution section (mode, planner/executor tiers, full verification command), Next role in ## Handoff, and a ## Review section. Phase files require Owner, Pattern to follow, and ## Context, ## Scope (In/Out), ## Verify, ## Escalate when, and ## Evidence sections. An in-flight ledger written under v3 will fail validation — see Migration below.
  • New skill goal-ledger-execute. Global installs are single-version per user: re-run the install before delegating, or a planner will hand an executor a skill it cannot load.
  • The single-writer rule is gone, replaced by a write-scope table. Executors write their own phase file, their phase's mirror line, ## Handoff, and ## Log. Goal status, the phase list, Git fields, and ## Review are planner-only. goal-ledger-resume restores planner-owned fields from Git history and logs the violation if an executor overstepped.
  • awaiting-acceptance now requires a recorded Gate D review.
  • Phase and sub-task caps raised from 7 to 9, leaving room for remediation. Drafting guidance is still 2–7.

New

  • Gate D — a planner-tier review gate and a new in-review goal status. Run the recorded Full verification, read git diff <baseline>..HEAD in full, check every changed path against some phase's scope, and re-check each phase's ## Evidence against its ## Verify. Executor summaries are claims until the planner re-runs the check. Findings become fix-up sub-tasks or a remediation phase, not caveats.
  • Phases written for the reader. Exact paths in Scope: In, an explicit Out list, a Pattern to follow: path:line pointing at real code to imitate, single-action sub-tasks, a copy-pasteable ## Verify, and an ## Escalate when list naming how the phase goes wrong. goal-ledger §5 has a "Writing phases a weaker model can execute" section.
  • A delegation prompt that deliberately carries no context — everything the executor needs is in the ledger.
  • goal-ledger-status now reports owners, next role, review state, and whether the next phase is executor-ready.
  • Pushing, opening a PR, and merging are explicitly never automatic. Goal Ledger prepares a reviewed branch and stops.

Validator

The bundled validate_goal_ledger.py now enforces the parts of the format that make delegation work, so an under-specified phase fails before an executor sees it. On a deliberately vague phase it reports six errors and two warnings, including sub-task 1 leaves a decision to the executor ('as needed').

  • Errors: missing/placeholder Scope In/Out, placeholder Context or Pattern to follow, a ## Verify that is neither a runnable command block nor an explicit - manual: check, an ## Escalate when with no real condition, an invalid Owner, and awaiting-acceptance without a recorded review.
  • Warnings: undecided wording ("as needed", "if necessary") in executor-owned sub-tasks, executor-owned phases verifiable only by eye, and phases marked done with nothing in ## Evidence.

Fixes

  • Sub-task parsing is scoped to the ## Sub-tasks section — a numbered list in the new prose sections no longer trips the malformed-sub-task check.
  • Committed Python bytecode that .gitignore already excluded is now untracked.

Migration

Finish or abandon any in-flight goal before upgrading. There is no automatic v3 → v4 ledger migration.

To migrate a live ledger by hand, add to GOAL.md an ## Execution section, Next role in ## Handoff, and a ## Review section with none values; then add Owner, Pattern to follow, and the ## Context, ## Scope, ## Verify, ## Escalate when, and ## Evidence sections to each phase file. Run scripts/validate_goal_ledger.py --root <project root> until it is clean. Completed and abandoned ledgers need no migration — they are historical records and are not re-validated.

v3.0.0 — user-global install model

Choose a tag to compare

@jpbaking jpbaking released this 20 Jul 01:26

Breaking: skills and rule now install user-global; install.sh/install.ps1 (and their test suite) are removed — AGENT-INSTALL.md is the only install path.

  • Skills to each harness's global skills dir (incl. Gemini CLI via ~/.agents/skills/); the rule self-gates on .goal-ledger/ and loads via global rules locations plus pointer blocks in ~/.codex/AGENTS.md, ~/.claude/CLAUDE.md, ~/.gemini/GEMINI.md.
  • .goal-ledger/ remains a committed, git-tracked execution record — every clone reads it with no tooling installed.
  • Installs never touch a project's .gitignore. Cursor supported via the shared global skill copies. CI now runs the validator tests only.

Migration: re-run the install prompt once per user; stale gitignored project adapters from v2 installs can be removed manually.

v2.1.0 — shared/ layout, gitignored adapters, agent-guided install

Choose a tag to compare

@jpbaking jpbaking released this 19 Jul 11:49

Highlights

  • AGENT-INSTALL.md — a merge-aware install procedure for AI agents, now the preferred install path (see README prompt).
  • Gitignored adapters — installed rule/skill copies are added to the target's .gitignore (marker-guarded, idempotent). Root instruction files and the runtime .goal-ledger/ stay committable.
  • Conditional bridgesAGENTS.md / GEMINI.md pointer text degrades safely on fresh clones; GEMINI.md now gets prose instead of a hard @import of a gitignored file.
  • Canonical sources moved to skills/shared/ and rules/shared/ (installer interface and environment variables unchanged; forks pinning old paths should update).

Installer behavior, harness selection prompts, and the Goal Ledger contract itself are otherwise unchanged. 28 tests pass.

v2.0.0 — two content sets, multi-harness installer

Choose a tag to compare

@jpbaking jpbaking released this 13 Jul 10:23

Breaking changes

  • Repo restructured: the live .clinerules/, .cline/, and .claude/ trees are replaced by a sets/{shared,small,frontier} source tree that the installer maps onto harnesses. The clone-as-template flow is gone — git init + run the installer instead.
  • plan-execute removed, replaced by the master-plan skill family (the installer migrates legacy installs): master-plan (two approval gates, autonomous execution, git commit per phase, squash-on-acceptance), master-plan-resume (crash recovery driven by git state), master-plan-status (read-only), master-plan-clear (gated revert + delete).
  • Installer now asks which harnesses to support (each defaults to Yes; WITH_CLINE/WITH_CLAUDE/WITH_AGENTS=1|0 to skip prompts).

New

  • Two content sets: sets/small (weak-model scaffolding → Cline) and sets/frontier (capable-model tuning → Claude Code and the .agents/ + AGENTS.md convention used by Codex CLI, Antigravity, and Gemini CLI), plus sets/shared for harness-neutral procedures. File conventions are identical across sets — plans and DOX trees interoperate across harnesses.
  • Claude Code support: CLAUDE.md (idempotent @imports) + .claude/{rules,skills,commands}.
  • .agents convention support: AGENTS.md pointer section + .agents/{rules,skills,workflows}.
  • Cross-harness ignores: .clineignore, .claude/settings.json deny rules (created only if absent), .geminiignore, and an AGENTS.md note — each harness ignores the others' config; AGENTS.md itself is never ignored.
  • /workflow and /command shortcuts for every installed skill.
  • DOX framework template packaged offline inside dox-init; dox-upgrade refreshes every installed harness's copy.

Fixes

  • Rule harmonization: post-compaction handling, master-plan trigger tightening, DOX exclusion of gitignored scratch folders.
  • Installer: idempotent appends throughout, set -e safety fixes.

v1.0.0 — initial release

Choose a tag to compare

@jpbaking jpbaking released this 03 Jul 01:04

First release of lazyway-io-boilerplate — a personal boilerplate that bundles three independent kits into one install, for use as either a template for new projects or a retrofit onto existing ones.

What's inside

  • .clinerules/ core rules (from cline-rules) — enforced reasoning workflow, the DOX AGENTS.md framework, and crash-safe multi-phase task plans. Always installed.
  • compose-helper.sh/.ps1 + env + rule/skill (from compose-helper) — a safe docker compose wrapper with agent-facing guardrails against destructive commands. Always installed.
  • lazyway-io-design rule/skill (from lazyway-io-design) — teaches an agent to build on-brand pages, fetching the full design kit on demand. Optional, for frontend projects.

Installers

install.sh (Linux/macOS) and install.ps1 (Windows), curl/irm-pipeable, safe to re-run. Each required kit is fetched fresh from its own upstream repo (nothing is reimplemented here), so the boilerplate never drifts from upstream fixes. See the README for usage, options, and the new-project vs. existing-project flows.

Usage

  • New project: clone this repo (or use it as a GitHub template — enabled) and drop README.md, LICENSE, and the installer scripts, which describe/license the boilerplate itself, not your app.
  • Existing project: curl -fsSL https://raw.githubusercontent.com/jpbaking/lazyway-io-boilerplate/main/install.sh | sh

Licensed 0BSD (covers this repo's own files only).