Keel v3.1.0

The verification loop closes over the end-user guide, and code comments become a reviewed contract.

Added

• guide-qa — the eighth verifier subagent (references/assistant-config.md). Conditional like its siblings: generated at Phase 6 on first need, once the end-user guide decision is yes (the decision does not exist earlier). Fresh context, read-only: it receives ONLY guide/ plus the capability and settings lists, and verifies mechanical coverage (every capability and every setting has its guide section, troubleshooting covers the debug-log switch), that every internal link and image resolves (the offline rule), that every task's steps are followable exactly as written, per-locale orthography, and the guide's own accessibility basics. The session that wrote the guide no longer self-certifies it: Phase 6 runs guide-qa at the guide check, and the Phase 7 gate re-runs it on the exact release candidate when the guide ships in the package — inline with the standing fallback when the environment has no subagents.
• Comments are a reviewed contract. The code-style rule gains its comments line and code-reviewer gains check (7): every public surface in the diff carries its docblock per the platform's convention (purpose, params, return), non-obvious decisions carry a why comment, and comment language follows the recorded policy (English by default). Phase 5's slice loop writes them at creation — "Comment the code as you write it", never backfilled later — exactly like docs and accessibility.

Changed

• Phase 6 definition of done: the docs/api/INDEX.md one-to-one check is delegated to docs-verifier when the environment provides subagents (inline otherwise), and the guide's mechanical coverage check names guide-qa as its runner.
• MANIFEST Table 3 carries the v3.1.0 reconciliation delta: on projects with the assistant config package accepted, regenerate code-reviewer and the code-style rule in every capable container; where the User guide: card line is yes and guide/ exists, generate guide-qa at the next Phase 6 or maintenance touch.

Keel v3.0.0

Major release: Everything the workflow used to materialize only for Claude — the portability lock, the embedded skill, the native config package — now has a first-class container for every assistant the user actually works with: OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI and Windsurf alongside Claude Code, riding the two open standards that consolidated in 2025-2026 (AGENTS.md for agent instructions, Agent Skills for the skill format itself) so most other tools — opencode, Zed, Warp, JetBrains Junie, Kiro, Cline and more — are covered by the standards at no extra cost. The principle throughout: one source of content (the project's own recorded decisions), one container per tool, parity between containers as a duty.

Added

• The portability lock is dual, always (references/project-state.md). The same KEEL block now lives in CLAUDE.md AND AGENTS.md in every project — created together, refreshed together, stamped together. Claude reads the first; Codex, Copilot, Cursor, Windsurf, opencode, Zed, Warp, Junie, Kiro, Cline and most other tools read the second natively. Gemini CLI, whose default context file is GEMINI.md, gets one recorded pick when the user works with it: a GEMINI.md mirror, or context.fileName in .gemini/settings.json including AGENTS.md. The lock text itself is now assistant-neutral (embedded-copy paths name both trees; the continuation-prompt pointer no longer assumes .claude/). The lock-freshness check (references/keel-maintenance.md) refreshes both files — and creates the missing AGENTS.md on projects that predate the dual lock.
• The embedded skill is dual (references/project-state.md). The embed now goes to .claude/skills/keel/ + .agents/skills/keel/, identical byte for byte: between the native tree and the open Agent Skills discovery convention, virtually every assistant loads Keel as a project skill on its own. The verified full-copy protocol applies to each tree; version sync always touches both, so they can never diverge. The update check (references/keel-maintenance.md) compares and updates both trees, and user-level install locations now include ~/.agents/skills/keel/ alongside ~/.claude/skills/keel/.
• references/assistant-config.md — replaces references/claude-config.md, generalized. The offer now asks which assistants will work on the repo; the package materializes one container per accepted tool from the SAME sources (technical plan §Conventions, the loaded security profile, Keel's quality gates, the verified commands): rules with path scoping (.claude/rules/ with paths:, .cursor/rules/*.mdc with globs:, .github/instructions/*.instructions.md with applyTo:, .windsurf/rules/*.md with trigger: glob, and nested context files per source directory for Codex/Gemini, which have no glob mechanism); the seven verifier subagents (.claude/agents/ — which Cursor also reads natively — .github/agents/*.agent.md, .gemini/agents/*.md; Codex and Windsurf run the same checks inline per the standing fallback); permission allow-lists (.claude/settings.json, .codex/rules/ Starlark prefix rules, tools.allowed in .gemini/settings.json, .cursor/cli.json; Copilot and Windsurf have no committable equivalent — the verified commands are documented in the repo's development notes instead); and MCP registration (.mcp.json, .cursor/mcp.json, .vscode/mcp.json, [mcp_servers] in .codex/config.toml, mcpServers in .gemini/settings.json). New standing rules: a "—" cell removes the mechanism, never the duty; parity across containers is verified at the Phase 7 gate; per-tool size limits are respected by construction (Keel's under-40-lines rule sits far inside all of them); config syntax rots — the content is Keel's contract, the container is the tool's, verified against current docs when in doubt.
• Project card line renamed: Assistant config: [none / rules / rules+agents / full] (tools: ...) — replaces Claude config:, now recording WHICH tools were accepted. MANIFEST Table 1 rows updated accordingly (lock, embed, rules, subagents, permissions, MCP registration all name their per-tool containers), and Table 3 carries the v3.0.0 reconciliation delta for existing projects (rename the card line, create the missing AGENTS.md, add the second embed tree, offer the new tools' containers, extend .gitignore and the gate exemption).
• INSTALL.md: per-assistant installation. A user-level install-path table (Claude, Codex, Cursor, Gemini CLI, Copilot/VS Code, Windsurf, and the shared ~/.agents/skills/ convention that serves the standard-compliant tools with one copy), plus the note that an embedded Keel project needs no per-machine install at all. README and INSTALL are now written for the multi-assistant reality (repo docs).

Changed

• The confidential-data pre-commit gate exempts both embedded-skill trees (.claude/skills/* and .agents/skills/* — the canonical trees that legitimately contain the gate's own patterns); the assistant-side hook note now points at the native pre-tool-use hooks of Claude Code, Codex, Gemini CLI and Cursor as the optional layer on top, git hook always the baseline. The scaffold's .gitignore adds the accepted tools' personal files (AGENTS.override.md, .gemini/.env, .gemini/tmp/) to the unconditional trio.
• Phase 7 export-ignore covers every generated assistant config tree (.claude/, .agents/, .codex/, .cursor/, .gemini/, .windsurf/, .github/instructions/, .github/agents/, .vscode/mcp.json, nested context files, GEMINI.md when kept) — nothing from the package ships, whatever the tool. The pre-tag verification checks container parity, not just the Claude tree.
• Phase 5 plan mode names its equivalents (Claude Code, Cursor, Gemini CLI's plan approval mode) with the same no-plan-mode fallback; the scaffold completes the package per tool; the subagent hooks in Phases 4/5/7/8 and the accessibility reference now point at references/assistant-config.md.
• references/estimation-budget.md: subscription mode names the other flat-fee plans (ChatGPT Plus/Pro, Gemini AI plans), the price-verification step carries the OpenAI and Google official pricing pages next to Anthropic's, and the measured-usage examples add Codex /status and Gemini CLI /stats beside Claude Code /cost.
• SKILL.md: the portability paragraph, the shared-templates entry and the reference index describe the dual lock, the dual embed and the generalized package; the token-economy line no longer assumes the coding assistant is Claude Code.

Keel v2.1.0

Added

• The handoff directory is exclusively Design's delivery — wholesale-replaceable, always (handoff contract, new rule 10; field-tested). Nothing but the delivered bytes ever lives in docs/design/design-handoff/: no generated assets, no user-acquired fonts, no notes or audit evidence, no build output. The reason is operational: installing a delivery or a re-delivery is a whole-directory swap — archive the current delivery to docs/old/design-handoff/<DR-id-or-date>/ (move, never delete), place the new one, diff against the archived copy — and a single foreign file makes that swap unsafe and blocks it, which had repeatedly happened in the field. Phase 4 gains the matching non-negotiable rule (its seventh), its Step 1 mechanical pass now flags any file the delivery's own SPEC does not account for, and Step 6 targets the PROJECT's asset tree for user-generated assets and acquired fonts (the font acquisition block's target path is now explicitly a project path, with the delivered @font-face referencing that final path). Phase 3 states the rule at the exact moment the returned handoff is placed.

Keel v2.0.0

Major release: verification becomes executable, and the lifecycle no longer ends at the release. Gates that were prose now demand evidence — commands with outputs, diffs, recomputed values, independent reviewers with fresh context — and the skill itself gains its own test, lint and CI infrastructure so the failure classes its own changelog documents (version drift, field-tested mechanism gaps) get caught before a tag instead of in the field.

Added

• references/keel-maintenance.md — the update check, its 24-hour throttle, the lock-freshness check, version reporting, and the full UNBREAKABLE version change policy, extracted from the SKILL.md body (which drops roughly a third of its per-session weight). SKILL.md keeps a binding "read and execute first" block plus the policy's core paragraph, so the guarantee of execution survives the extraction. The throttle stamp now carries a consecutive-failure count, and at the fifth consecutive failed remote lookup the user is told once, briefly.
• references/playground-recipes.md — per-platform verification environments, operable by the assistant so "exercise it for real" means commands with recordable output: wp-env pinned to the support matrix with WP-CLI smoke checks and Woo seed data; MCP Inspector plus registering the dev server in .mcp.json so the assistant calls the tools live; local server or docker compose with Playwright e2e for web; a clean consumer project installing the BUILT artifact for libraries. Synthetic seed data with a reset command is part of every recipe (an empty store proves nothing), and "gate zero" (clean build + lint + one trivial passing test) opens every scaffold.
• references/maintenance.md — the post-release lifecycle the skill previously ended without: triage with reproduce-first, the hotfix path (branch from the release tag, regression test that fails before and passes after, the full Phase 7 gate compressed in time but never in content), rollback (WordPress.org Stable tag downgrade, redeploy, deprecate — never unpublish), dependency and CVE duty ("Tested up to" is never bumped untested), the recurring-feature cycle, the full-suite rule, and the site-freshness duty. Resume routes here when PROGRESS.md marks Phase 7 done.
• references/security/website.md + a routing row for websites — the profile Phase 8 referenced six times but no rule ever loaded: transport and security headers verified with curl -sI on the live site, forms as the one dynamic surface (server-side validation, rate limit, honeypot + time-trap anti-spam, CAPTCHA only with an accessible alternative, SPF/DKIM/DMARC-aligned mail), zero mixed content with SRI on approved third parties, deploy integrity.
• MCP profile: "Model-facing threats" — the section that makes an MCP server different from a classic API: tool results carrying third-party content are data, never instructions (the injection channel); tool descriptions are prompts whose integrity is release-controlled (poisoning/rug-pull); confused deputy (per-user credentials, never a master token any caller can drive); destructive tools gated behind human confirmation or dry-run by default; localhost binding and Origin validation on local transports (DNS rebinding). Plus matching test points and a malicious-content fixture.
• WordPress profile: five verified gaps closed — SSRF via wp_remote_* with user-influenced URLs, object injection (unserialize across a trust boundary), identifier placeholders (%i / allow-lists for ORDER BY and column names), hash_equals() for tokens and license keys, and output-escaping of translated strings (a malicious .po is a real vector). The embedded MCP/OAuth section is now the WP mapping only and orders loading the full MCP profile.
• Web-app profile: credential storage and recovery — argon2id/bcrypt, MFA available and required as an option for privileged accounts, single-use time-boxed hashed reset tokens, no account enumeration, rate limits.
• "Verify with" blocks in all five security profiles — the checks now name their tools: phpcs with the WordPress security sniffs and the Plugin Check plugin; npm audit/composer audit/pip-audit; OWASP ZAP baseline; MCP Inspector with schema fuzzing; published-artifact inspection and public-API diff for libraries. At a test point, the command and its result are the evidence — an unrecorded check did not happen.
• Four new project subagents in references/claude-config.md, and the existing three are now actually invoked. New: design-fidelity-auditor (fresh-context fidelity walk of the build vs BUILD-SPEC and handoff), playground-qa (follows docs/playground.md literally — an instruction gap is a defect), launch-verifier (crawls the deployed site from the sitemap and returns the pass/fail table), a11y-auditor (automated accessibility pass + the guided-loop script). Wired: code-reviewer reviews every slice diff before its commit (Phase 5 test-point confirmation (f)), docs-verifier runs at sprint closes, security-auditor before the Phase 7 tag — previously defined but never referenced by any phase. Plus an optional CI workflow piece built from the technical plan's exact verified commands, with gitleaks and scripts/keel-verify.
• scripts/keel-verify — every project generates its own release linter at the Phase 5 scaffold: version touchpoints in sync, changelog order, docs/api/INDEX.md parity, no placeholder copy in distributable surfaces, and a WP i18n dry run where it applies. Runs at every sprint close and at the Phase 7 gate, output pasted as evidence.
• Phase 5: the testing contract the user asked for — right the first time. Every acceptance criterion maps to a named automated test (unit / integration / e2e; browser-driven e2e required for web UI flows) or carries a recorded one-line justification; every test-point row records the exact commands, output summary and commit hash ("a result without its command and output is an empty cell"); after three failed attempts at the same test point the assistant STOPS and reports instead of looping; sprint closes run the FULL suite, docs-verifier, a cold playground-qa pass and keel-verify; the playground is re-booted from its documented commands at each session's first test point and stamped last verified; declared performance budgets are measured, with numbers. Two new principles seal it: anything a compile, a boot or a basic test would have caught is a process defect if it escapes; and a failing test is never deleted, skipped or weakened to pass.
• Phase 4: the audit leaves evidence. BUILD-SPEC §1 becomes an evidence table mirroring every gate bullet (item / checked / evidence / result — "an item without evidence is not audited"); a deterministic mechanical pass checks the filesystem facts (assets exist, SVG+PNG pairs, screens covered, open questions empty); token origin and full target-surface coverage are now audited (they were contract terms nobody checked); declared contrast pairs are recomputed from the delivered hex values; re-deliveries are diffed against the previous delivery (byte-stable is verified, the BUILD-SPEC is updated, the second bounce of an item escalates to the user); checkboxes are ticked in the file at the moment of verification.
• Fonts are first-class handoff assets, like logos and icons (handoff contract, rule 4). Design ships the actual self-hosted font files at their final paths — only the used weights/styles, woff2 first for the web, the @font-face rules already written against those paths — or, when licensing prevents shipping, a complete acquisition block per font: exact download source, license note, exact files, exact target path in the project structure, so the user drops them in and everything works and stays reusable. The Phase 4 audit checks it, the guided loop walks the acquisition one font at a time, and a font that is merely named is an incomplete handoff.
• Phase 3: no more single point of failure on Design. An "If Claude Design is not available" playbook with three recorded branches (round-trip through another environment, the assistant produces the handoff under the same contract and audits it with no self-exemption, or a human designer); a brief approval gate (mechanical scan for unfilled brackets + the user approves a summary); the exact waiting position lands in PROGRESS.md; and visual references travel as annotated SCREENSHOTS, never URLs — if the user offers an address, the assistant explains that captures of what they want are far more effective than expecting Design to visit links (field-tested).
• Phase 2: the spec defends itself. An adversarial fresh-context review before the firm estimate (six-part requirements, flow coverage, per-screen accessibility, acceptance-criterion completeness, empty/permission/double-submit ambiguities); the Testing block names frameworks and exact commands per layer, the playground recipe, seed data and the per-flow real-exercise command; the design split now carries foreseen external assets, per-screen accessibility requirements and exact target viewports/breakpoints all the way into the template (they previously died between the step and the brief).
• Phase 1: the edges get playbooks. Zero-competitors handling (retry differently, then record "no competitors found" as analysis: new niche or no market); "partial" scan status defined; a closure protocol for the honest assessment (verdict + user decision on record; parked status when the project stops; proceeding against a negative verdict is a recorded decision); the competitive scan delegates to subagents when available; and the Client budget: question, asked once.
• Phase 8: launch becomes auditable, and the site outlives it. <site-docs>/launch-report.md — every checklist item leaves a row (command/tool, result, date), with the page list derived from sitemap.xml and EVERY page checked (sampling one per template is called out as insufficien...

v1.13.0 — The vibe-coding onramp: Keel proposes the v1

This release makes Keel genuinely usable by someone with no development background who arrives with nothing more than a vague idea. The structure was already there; now the front door is too.

Added

Vague-idea onramp (Phase 1, step 1). A vague idea is a valid entry, not a defect to push back on. When the user cannot answer the discovery questions in their own terms, Keel does not interrogate — it proposes 2–3 concrete interpretations of the idea in plain language (grounded in the competitive scan where it helps) and lets them pick or correct one. The phase never stalls on a question the user cannot answer.

Proposed v1 — the assistant proposes, the user reacts (Phase 1, step 3). Nobody is asked to build a feature list from a blank page anymore. From what discovery has already produced — table stakes from the competitive scan, differentiator candidates from real user demand, AI/MCP added-value proposals, the honest assessment, and the user's own idea — Keel assembles a proposed v1 and presents it unprompted, always, as a draft to react to, never as a decision already made:

• Every feature carries its why — table stakes (competitors X, Y), differentiator (source), AI/MCP added value, or user's idea — so a non-developer can judge each row on its merits.
• An explicit "Later" list makes cutting visible and painless: deferred, not lost.
• The scope is tight by default, and removing items is explicitly invited. The proposal is a starting point, not an anchor — the user's corrections always win.

If the user already arrives with a defined scope of their own, Keel does not re-propose from scratch: it presents the diff against the scan instead — missing table stakes, items that belong in Later, differentiator candidates worth considering.

Every question answerable by a non-developer (all phases). Every question Keel asks now carries a recommended default and a one-line plain-language explanation of what it means and why the default is sensible. "I don't know / whatever you think" is a valid answer: the default is recorded in docs/decisions.md as "default accepted" and the work moves on.

Changed

• The skill's trigger description now names the vague-one-line-idea, no-technical-background entry (Keel shapes it and proposes the v1 unprompted), and the Phase 1 row of the phase map reads "proposed v1 (assistant proposes, user reacts)" instead of "feature discussion".

Full changelog: keel/CHANGELOG.md

Keel v1.12.1 — Update checks once a day, not once per chat

What's new in 1.12.1

Update-check throttle — at most one remote check per 24 hours per project

Field-tested friction: with the lock forcing a full SKILL.md read at every session start, the remote release lookup (git ls-remote / GitHub API) ran in every new chat and delayed the start of work.

• A tiny machine-local stamp at the project root — .keel-update-check, one line with the UTC timestamp of the last attempt and its outcome — now throttles it: less than 24 hours old → the remote lookup is skipped silently; missing, unparsable, or 24+ hours old → run it, then rewrite the stamp after EVERY attempt, success or failure, so a flaky network cannot re-impose the wait on every chat.
• Only the remote lookup is throttled. The installed-vs-embedded copy comparison, the full SKILL.md read, the stamp-only lock-freshness check, and the Keel baseline: comparison still run in every session — they are local and free.
• Asking explicitly for an update check always bypasses the throttle.
• The stamp is never committed: it joins CLAUDE.local.md and .claude/settings.local.json as an unconditional .gitignore entry (Phase 5 scaffold, Phase 7 list, claude-config.md and MANIFEST Table 1 updated).

How to update

Replace your installed keel/ directory with this release's (see INSTALL.md, "Updating"). From the next session in each project, the first update check writes the stamp — and every other chat that day starts instantly.

Keel v1.11.0 — The lock reads the skill first, and the gate stops fighting itself

What's new in 1.11.0

The CLAUDE.md lock now opens every session: step 1 is reading the FULL SKILL.md

Field-tested gap: on a fresh chat, an assistant that already had the lock in context would jump straight into the state files (the old step 1) and never load the skill body — so the session-start update check never ran, and you had to ask for a full re-read by hand.

• Step 1 — the skill, before anything else. Read the FULL SKILL.md (installed skill or embedded copy), starting with its session-start update check. Remembering the protocol from an earlier chat, or having the lock in context, does not count as having read it.
• After an update, catch up before working. When the check installs a newer Keel, the lock itself orders the post-update reconciliation BEFORE normal work continues — new files or directories, new project-card lines, the lock block itself, questions never asked in that project.
• Step 2 — then the state. PROGRESS.md, decisions.md, lessons-learned.md and the current phase's reference, plus the Keel baseline: comparison.

Lock freshness check — stamp-only, a one-line verification

CLAUDE.md is the one file every environment loads in every session, so the rules Keel keeps there must always be the current ones.

• The KEEL:BEGIN delimiter now carries a version stamp naming the Keel that last wrote the block: <!-- KEEL:BEGIN — v1.11.0 do not remove: … -->.
• SKILL.md's update check gains a companion step: every session inside a Keel project checks the stamp against the running version — equal → current, nothing else to read; different or missing (pre-1.11.0 blocks have no stamp; delimiters are matched by the KEEL:BEGIN prefix, never by exact text) → rewrite the block between the delimiters from the canonical copy in references/project-state.md, restamped with the running version, with the user's OK.
• The stamp alone decides — never a content comparison. The block itself states the same rule from its side, so an assistant that only has the lock in context knows the block may be outdated and where the canonical copy lives. The AGENTS.md mirror follows the same rule.

Confidential-data gate: field-tested false-positive hardening

Committing the gate's own script or the embedded skill tripped the gate — their files legitimately contain the very patterns it searches for — forcing a conscious bypass on the first real-world commit. Three measures:

• The hook now exempts the canonical trees .githooks/ and .claude/skills/; the assistant-side check still scans them like everything else.
• The synthetic-secret verification example — and SKILL.md's own by-content pattern list, dating from 1.9.0 — rewritten so no canonical skill file contains a matchable secret-shaped string, verified by running the gate's pattern over the whole tree: zero matches.
• New writing rule (SKILL.md "Confidential data never reaches Git", point 5, mirrored in the decisions template): docs, decision notes and lessons never embed a literal secret-shaped string — describe it or split it apart.

How to update

Replace your installed keel/ directory with this release's (see INSTALL.md, "Updating"). Projects that embed the skill get their .claude/skills/keel/ copy updated automatically by the session-start update check — the session then runs the post-update reconciliation and the stamp-only lock-freshness check, which bring the project and its CLAUDE.md block up to date.

Keel v1.10.0 — Native Claude Code project config, and projects that catch up when Keel does

What's new in 1.10.0

Native Claude Code project configuration (optional package)

Keel can now generate the configuration Claude Code loads natively — per project, only with your consent, and derived exclusively from decisions the project has already recorded. New reference: references/claude-config.md.

• .claude/rules/ — three path-scoped rules distilled from the technical plan and the security profile: code-style.md, security.md and docs-discipline.md. They load only when a session touches matching source files, stay under ~40 lines each, and point to their docs/ sources instead of duplicating them.
• .claude/agents/ — three read-only reviewer subagents: code-reviewer (conventions, reuse, i18n, accessibility, docs), security-auditor (the loaded security profile) and docs-verifier (docs/api/INDEX.md ↔ docs, one-to-one). They flag; they never rewrite.
• .claude/settings.json — a minimal permission allow-list built ONLY from the plan's verified tooling and playground commands, ALWAYS confirmed by the user before writing.
• Confidential-data pre-commit gate — a classic git hook (.githooks/pre-commit + core.hooksPath) that blocks staged secrets in EVERY environment and editor, not only Claude Code sessions. Installed at the scaffold and verified by blocking a synthetic secret, with a conscious, on-the-record bypass policy.
• .mcp.json — only when the technical plan defines development MCP servers; environment expansion, never a literal secret.

When it happens. Offered once, in the Phase 1 step 0a batch (and at adoption step 2); recorded in the project card as Claude config: [none / rules / rules+agents / full]. Rules and agents materialize at Phase 2 close, when their sources are fixed; settings, the gate and .mcp.json at the Phase 5 scaffold. In adoption, rules encode the OBSERVED conventions — never imposed ones — and existing .claude/ config is inventoried and reconciled, never overwritten.

Position in the workflow. The CLAUDE.md lock remains the universal mechanism — only Claude Code loads rules, agents and settings, so nothing critical to the workflow lives only in .claude/. CLAUDE.local.md and .claude/settings.local.json are never created by Keel but always gitignored. Phase 7's export-ignore now also covers generated config, .githooks/ and .mcp.json — none of it ever ships in the distributable.

Post-update reconciliation — the project catches up when Keel does

A Keel update changes the workflow; until now it did not change the project. New procedure in references/project-state.md, "Post-update reconciliation".

• When it runs. Right after the session-start update check replaces any copy, and on resume whenever the project card's Keel baseline: is older than the running version — or missing (any project created before 1.10.0).
• What it does. Re-reads the new SKILL.md and the current phase's reference (the copies in context belong to the old version), diffs versions via the changelog, and extracts what touches the PROJECT itself: files and directories that should now exist, new project-card lines, lock-block refreshes between the KEEL:BEGIN/END delimiters, questions a phase now asks that this project was never asked, new one-time verifications. Then it presents ONE batched catch-up plan you approve, trim or defer — deferrals are recorded in PROGRESS.md open items, never forgotten.
• What it never does. Re-open recorded decisions (conflicts are surfaced; the recorded decision wins until you reverse it), re-run completed phases, or force-install optional mechanisms — it asks their never-asked question, e.g. this release's Claude config package on a pre-1.10.0 project.
• The trail. New project-card line Keel baseline: vX.Y.Z, stamped at creation (Phase 1 step 0a / adoption step 2) and advanced ONLY by completing a reconciliation — a skill update alone never advances it.

How to update

Replace your installed keel/ directory with this release's (see INSTALL.md, "Updating"). Projects that embed the skill get their .claude/skills/keel/ copy updated automatically by the session-start update check — and from this release on, the session then offers the post-update reconciliation so the project itself catches up too.

Keel v1.9.0

What's new in 1.9.0

Confidential data never reaches Git

Before EVERY commit and push — test points and sprint closes, the release, website deploys, adoption's first commit, any ad-hoc commit — Keel now checks that nothing confidential is about to enter the repository. This applies from the project's very first commit, not only at release time.

What it scans. The staged files (at release, the whole tracked tree), by name and by content: .env* and credential files, private keys and certificates, wp-config.php with real values, database dumps and backups, API keys and tokens, passwords in config, OAuth client secrets, payment-gateway merchant keys, license keys, and real personal or customer data in fixtures, seeds, logs, or dumps. A dedicated scanner (gitleaks, trufflehog) is used when available — helpful, never required.

What happens on a finding. The commit STOPS. The user is warned file by file that letting it reach the repository is a serious security risk, and the fix matching the file's state is applied before anything is committed:

• Never tracked → excluded via .gitignore so it can never reach the repository.
• Tracked but never pushed → git rm --cached plus .gitignore.
• Ever pushed → removed from history (git filter-repo / BFG) AND the exposed credential rotated: a pushed secret is compromised.

The user has the last word: a flagged file they confirm as safe (placeholders, sandbox-only keys meant to ship) proceeds, with the decision recorded in docs/decisions.md.

Integrated end to end. The CLAUDE.md portability lock now forbids committing without this check (existing projects pick it up through the normal lock-refresh mechanism), Phase 5's commit discipline runs it at every commit, and Phase 7 re-runs it over the whole tracked tree before release.

Full details in keel/CHANGELOG.md.

How to update

Replace your installed keel/ directory with this release's (see INSTALL.md, section "Updating") — or let the session-start update check introduced in 1.8.0 do it for you where the environment allows.

Keel v1.8.0

What's new in 1.8.0

Execution discipline in the CLAUDE.md lock

The portability lock every Keel project carries in its CLAUDE.md gains a fifth protocol item: mandatory execution discipline for ANY assistant or model working in a Keel repository, in any environment.

• Batch independent tool calls in one parallel block; never run sequentially what does not depend on a previous result.
• Delegate broad searches and scans to a subagent when the environment provides them; bring back conclusions, never file dumps.
• No narration between tool calls; findings accumulate and are reported once, at the end of the work block.
• Locate before reading: search first, then read only the relevant fragment — never whole files or directories "for context".
• Edit surgically with exact-match edits; never rewrite a whole file to change one part.
• Batch clarifying questions at the start of a work block; close every work block with an explicit verification step (diff, test, or re-read) before calling it done.

Existing projects pick the new block up through the normal lock-refresh mechanism (between the KEEL:BEGIN/END delimiters, with the user's OK).

Release update check at session start

Keel now keeps itself current. Once per session, before any phase work, it checks this repository for a newer release (preferred method: git ls-remote --tags, with the GitHub API and the releases page as fallbacks) and compares the latest tag against EVERY copy in play — the environment's install and the project's embedded .claude/skills/keel/ — each one separately, so an up-to-date app install never hides an outdated embedded copy in the opened project.

• Copies the assistant can durably write (a user-level install, and always the project's embedded copy) are updated automatically: verified full-tree replacement, improvements summarized from the new CHANGELOG.
• Copies it cannot write (app-managed skill storage, as in the Claude app / Cowork) get a single notice: the new version, what it improves, and how to update per INSTALL.md.
• The check is best-effort and never blocks or delays the session's work.

Full details in keel/CHANGELOG.md.

How to update

Replace your installed keel/ directory with this release's (see INSTALL.md, section "Updating"). Keel is stateless, so overwriting is safe. From this version on, Keel performs this check for you at the start of every session.