continuous-improvement 3.16.0 → 3.17.0

package/.claude-plugin/marketplace.json

@@ -7,8 +7,8 @@
   "plugins": [
     {
       "name": "continuous-improvement",
-      "description": "The persistent-memory and runtime-discipline layer for Claude Code. It remembers the corrections you already gave, grounds every edit in real facts before it lands, and — through the Mulahazah engine — turns each fix into a reusable instinct, so a lesson learned once is applied automatically next time with no re-teaching. Built on the 7 Laws of AI Agent Discipline (research, plan, verify, reflect, learn) and shipped as 26 bundled skills, instinct-aware hooks, an MCP toolset for recall and reflection, and a GitHub Action transcript linter that feeds real work history back into sharper instincts.",
-      "version": "3.16.0",
+      "description": "The persistent-memory and runtime-discipline layer for Claude Code. It remembers the corrections you already gave, grounds every edit in real facts before it lands, and — through the Mulahazah engine — turns each fix into a reusable instinct, so a lesson learned once is applied automatically next time with no re-teaching. Built on the 7 Laws of AI Agent Discipline (research, plan, verify, reflect, learn) and shipped as 27 bundled skills, instinct-aware hooks, an MCP toolset for recall and reflection, and a GitHub Action transcript linter that feeds real work history back into sharper instincts.",
+      "version": "3.17.0",
       "source": "./plugins/continuous-improvement",
       "author": {
         "name": "naimkatiman"

package/CHANGELOG.md

@@ -4,6 +4,12 @@ All notable changes to this skill are documented here.
 
 ---
 
+## [3.17.0] — 2026-06-28
+
+### Added
+
+- **`/intent-driven-development`**: turn an ambiguous or high-impact change into verifiable acceptance criteria before you build. Converts a fuzzy request into observable `AC-NNN` criteria with named verification methods and a `[revised]` protocol that forbids silently dropping a criterion mid-build, so "done" is falsifiable and the agreed plan is held sacred (Law 2). Tier 2 (expert install). Brings the bundle to 27 skills. (#258)
+
 ## [3.16.0] — 2026-06-27
 
 ### Added

package/README.md

@@ -261,7 +261,7 @@ All 18 ship in the marketplace bundle. The Beginner install gets all of them —
 
 ## Skills
 
-The plugin ships **26 skills** — 1 core + 1 featured + 6 tier-1 + 15 tier-2 + 3 always-bundled. Beginner install gets tier-1, featured, and the always-bundled companion; Expert adds tier-2, the MCP server, and observation hooks. Full catalog with per-skill descriptions, Law tagging, and drop-in single-file install: [docs/skills.md](docs/skills.md). Adding a 27th skill: [CONTRIBUTING.md § Evolution — adding a new skill](CONTRIBUTING.md#evolution--adding-a-new-skill).
+The plugin ships **27 skills** — 1 core + 1 featured + 6 tier-1 + 16 tier-2 + 3 always-bundled. Beginner install gets tier-1, featured, and the always-bundled companion; Expert adds tier-2, the MCP server, and observation hooks. Full catalog with per-skill descriptions, Law tagging, and drop-in single-file install: [docs/skills.md](docs/skills.md). Adding a 28th skill: [CONTRIBUTING.md § Evolution — adding a new skill](CONTRIBUTING.md#evolution--adding-a-new-skill).
 
 ---
 
@@ -320,7 +320,7 @@ Authored end-to-end with `/superpowers` and `/proceed-with-the-recommendation`:
 
 - [QUICKSTART.md](QUICKSTART.md) — 2-minute setup
 - [SKILL.md](SKILL.md) — full 7 Laws spec
-- [docs/skills.md](docs/skills.md) — full 26-skill catalog
+- [docs/skills.md](docs/skills.md) — full 27-skill catalog
 - [examples/](examples/) — bug fix, feature build, refactor walkthroughs
 - [templates/insights-claude-md.md](templates/insights-claude-md.md) — paste-in CLAUDE.md blocks for verification discipline, environment notes, think-before-acting, and git/deploy workflow (sourced from the 28-day usage report)
 - [CONTRIBUTING.md](CONTRIBUTING.md) — architecture, repo internals, adding a new skill

package/commands/intent-driven-development.md

@@ -0,0 +1,36 @@
+---
+name: intent-driven-development
+description: "Turn an ambiguous or high-impact change into scoped, verifiable acceptance criteria (observable AC-NNN, explicit scope, named verification methods, and a [revised] protocol that forbids silently dropping a criterion) before or alongside implementation. Enforces Law 2 (Plan Is Sacred)."
+argument-hint: "[the change to scope into acceptance criteria]"
+---
+
+# /intent-driven-development
+
+Convert an ambiguous or high-impact request into observable acceptance criteria before you build, so "done" is a fact two people would agree on and the agreed plan is held sacred (Law 2). Produce useful criteria without ceremony: inspect context first, expose only genuine ambiguity, choose verification that fits the risk.
+
+## Trigger phrases
+
+- `/intent-driven-development`
+- `/intent-driven-development <the change>`
+- "define acceptance criteria"
+- "scope this change" / "make this testable"
+- "de-risk this before we build it"
+- "prepare implementation requirements for another agent"
+
+Do not trigger for trivial edits, one-line fixes, active debugging, code review, or requests whose acceptance conditions are already clear.
+
+## What happens
+
+1. **Inspect and scope.** Read the repo, docs, schemas, and tests for technical facts before asking. Capture product or business constraints only from the user or a product artifact, never inferred from code.
+2. **Choose depth.** Quick Capture (3-7 criteria, low or moderate risk) or Full Acceptance Brief (security, data, migration, cross-system, or handoff).
+3. **Write criteria.** Each `AC-NNN` names a scenario, a trigger, an expected observable result, a prohibited side effect when meaningful, a verification method, and a priority. No vague words without defined evidence.
+4. **Proceed or hand off.** Record the criteria and continue for a clear request; present blockers and wait when a change is risky. If a criterion cannot be met mid-build, mark it `[revised]`, increment the revision, and re-present only the changed criteria.
+
+## Skill file
+
+Full behavior is defined in [`skills/intent-driven-development.md`](../skills/intent-driven-development.md).
+
+## Pairs with
+
+- `/grill-me`: grill-me clarifies a fuzzy input; this skill turns the agreed intent into verifiable criteria.
+- `/roast`: roast validates the idea, then scope the survivor into acceptance criteria.

package/lib/plugin-metadata.mjs

@@ -26,7 +26,7 @@ const KEYWORDS = [
     "transcript-linter",
 ];
 const CLAUDE_PLUGIN_CATEGORY = "productivity";
-const SHARED_PLUGIN_DESCRIPTION = "The persistent-memory and runtime-discipline layer for Claude Code. It remembers the corrections you already gave, grounds every edit in real facts before it lands, and — through the Mulahazah engine — turns each fix into a reusable instinct, so a lesson learned once is applied automatically next time with no re-teaching. Built on the 7 Laws of AI Agent Discipline (research, plan, verify, reflect, learn) and shipped as 26 bundled skills, instinct-aware hooks, an MCP toolset for recall and reflection, and a GitHub Action transcript linter that feeds real work history back into sharper instincts.";
+const SHARED_PLUGIN_DESCRIPTION = "The persistent-memory and runtime-discipline layer for Claude Code. It remembers the corrections you already gave, grounds every edit in real facts before it lands, and — through the Mulahazah engine — turns each fix into a reusable instinct, so a lesson learned once is applied automatically next time with no re-teaching. Built on the 7 Laws of AI Agent Discipline (research, plan, verify, reflect, learn) and shipped as 27 bundled skills, instinct-aware hooks, an MCP toolset for recall and reflection, and a GitHub Action transcript linter that feeds real work history back into sharper instincts.";
 // Four vendored upstream companions registered alongside the CI plugin.
 // Each entry points at a pinned-SHA snapshot under third-party/<name>/.
 // See third-party/MANIFEST.md for refresh recipes and per-snapshot

package/llms.txt

@@ -1,6 +1,6 @@
 # continuous-improvement
 
-> The persistent-memory and runtime-discipline layer for Claude Code. It remembers the corrections you already gave, grounds every edit in real facts before it lands, and — through the Mulahazah engine — turns each fix into a reusable instinct, so a lesson learned once is applied automatically next time with no re-teaching. Built on the 7 Laws of AI Agent Discipline (research, plan, verify, reflect, learn) and shipped as 26 bundled skills, instinct-aware hooks, an MCP toolset for recall and reflection, and a GitHub Action transcript linter that feeds real work history back into sharper instincts.
+> The persistent-memory and runtime-discipline layer for Claude Code. It remembers the corrections you already gave, grounds every edit in real facts before it lands, and — through the Mulahazah engine — turns each fix into a reusable instinct, so a lesson learned once is applied automatically next time with no re-teaching. Built on the 7 Laws of AI Agent Discipline (research, plan, verify, reflect, learn) and shipped as 27 bundled skills, instinct-aware hooks, an MCP toolset for recall and reflection, and a GitHub Action transcript linter that feeds real work history back into sharper instincts.
 
 ## What This Is
 

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "continuous-improvement",
-  "version": "3.16.0",
-  "description": "The persistent-memory and runtime-discipline layer for Claude Code. It remembers the corrections you already gave, grounds every edit in real facts before it lands, and — through the Mulahazah engine — turns each fix into a reusable instinct, so a lesson learned once is applied automatically next time with no re-teaching. Built on the 7 Laws of AI Agent Discipline (research, plan, verify, reflect, learn) and shipped as 26 bundled skills, instinct-aware hooks, an MCP toolset for recall and reflection, and a GitHub Action transcript linter that feeds real work history back into sharper instincts. Beginner: one /plugin install command. Expert: adds MCP tools and session hooks.",
+  "version": "3.17.0",
+  "description": "The persistent-memory and runtime-discipline layer for Claude Code. It remembers the corrections you already gave, grounds every edit in real facts before it lands, and — through the Mulahazah engine — turns each fix into a reusable instinct, so a lesson learned once is applied automatically next time with no re-teaching. Built on the 7 Laws of AI Agent Discipline (research, plan, verify, reflect, learn) and shipped as 27 bundled skills, instinct-aware hooks, an MCP toolset for recall and reflection, and a GitHub Action transcript linter that feeds real work history back into sharper instincts. Beginner: one /plugin install command. Expert: adds MCP tools and session hooks.",
   "keywords": [
     "claude-code",
     "claude-code-skill",

package/plugins/beginner.json

@@ -1,6 +1,6 @@
 {
   "name": "continuous-improvement",
-  "version": "3.16.0",
+  "version": "3.17.0",
   "mode": "beginner",
   "description": "Beginner mode: see what your agent learned, list its instincts, and request a session reflection. Bundles three grounding skills (gateguard, tdd-workflow, verification-loop) so research, memory, tests, and verification happen by default — every edit starts from facts, not guesses.",
   "tools": [

package/plugins/continuous-improvement/.claude-plugin/marketplace.json

@@ -7,8 +7,8 @@
   "plugins": [
     {
       "name": "continuous-improvement",
-      "description": "The persistent-memory and runtime-discipline layer for Claude Code. It remembers the corrections you already gave, grounds every edit in real facts before it lands, and — through the Mulahazah engine — turns each fix into a reusable instinct, so a lesson learned once is applied automatically next time with no re-teaching. Built on the 7 Laws of AI Agent Discipline (research, plan, verify, reflect, learn) and shipped as 26 bundled skills, instinct-aware hooks, an MCP toolset for recall and reflection, and a GitHub Action transcript linter that feeds real work history back into sharper instincts.",
-      "version": "3.16.0",
+      "description": "The persistent-memory and runtime-discipline layer for Claude Code. It remembers the corrections you already gave, grounds every edit in real facts before it lands, and — through the Mulahazah engine — turns each fix into a reusable instinct, so a lesson learned once is applied automatically next time with no re-teaching. Built on the 7 Laws of AI Agent Discipline (research, plan, verify, reflect, learn) and shipped as 27 bundled skills, instinct-aware hooks, an MCP toolset for recall and reflection, and a GitHub Action transcript linter that feeds real work history back into sharper instincts.",
+      "version": "3.17.0",
       "source": "./",
       "author": {
         "name": "naimkatiman"

package/plugins/continuous-improvement/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "continuous-improvement",
-  "version": "3.16.0",
-  "description": "The persistent-memory and runtime-discipline layer for Claude Code. It remembers the corrections you already gave, grounds every edit in real facts before it lands, and — through the Mulahazah engine — turns each fix into a reusable instinct, so a lesson learned once is applied automatically next time with no re-teaching. Built on the 7 Laws of AI Agent Discipline (research, plan, verify, reflect, learn) and shipped as 26 bundled skills, instinct-aware hooks, an MCP toolset for recall and reflection, and a GitHub Action transcript linter that feeds real work history back into sharper instincts.",
+  "version": "3.17.0",
+  "description": "The persistent-memory and runtime-discipline layer for Claude Code. It remembers the corrections you already gave, grounds every edit in real facts before it lands, and — through the Mulahazah engine — turns each fix into a reusable instinct, so a lesson learned once is applied automatically next time with no re-teaching. Built on the 7 Laws of AI Agent Discipline (research, plan, verify, reflect, learn) and shipped as 27 bundled skills, instinct-aware hooks, an MCP toolset for recall and reflection, and a GitHub Action transcript linter that feeds real work history back into sharper instincts.",
   "author": {
     "name": "naimkatiman",
     "url": "https://github.com/naimkatiman"

package/plugins/continuous-improvement/commands/intent-driven-development.md

@@ -0,0 +1,36 @@
+---
+name: intent-driven-development
+description: "Turn an ambiguous or high-impact change into scoped, verifiable acceptance criteria (observable AC-NNN, explicit scope, named verification methods, and a [revised] protocol that forbids silently dropping a criterion) before or alongside implementation. Enforces Law 2 (Plan Is Sacred)."
+argument-hint: "[the change to scope into acceptance criteria]"
+---
+
+# /intent-driven-development
+
+Convert an ambiguous or high-impact request into observable acceptance criteria before you build, so "done" is a fact two people would agree on and the agreed plan is held sacred (Law 2). Produce useful criteria without ceremony: inspect context first, expose only genuine ambiguity, choose verification that fits the risk.
+
+## Trigger phrases
+
+- `/intent-driven-development`
+- `/intent-driven-development <the change>`
+- "define acceptance criteria"
+- "scope this change" / "make this testable"
+- "de-risk this before we build it"
+- "prepare implementation requirements for another agent"
+
+Do not trigger for trivial edits, one-line fixes, active debugging, code review, or requests whose acceptance conditions are already clear.
+
+## What happens
+
+1. **Inspect and scope.** Read the repo, docs, schemas, and tests for technical facts before asking. Capture product or business constraints only from the user or a product artifact, never inferred from code.
+2. **Choose depth.** Quick Capture (3-7 criteria, low or moderate risk) or Full Acceptance Brief (security, data, migration, cross-system, or handoff).
+3. **Write criteria.** Each `AC-NNN` names a scenario, a trigger, an expected observable result, a prohibited side effect when meaningful, a verification method, and a priority. No vague words without defined evidence.
+4. **Proceed or hand off.** Record the criteria and continue for a clear request; present blockers and wait when a change is risky. If a criterion cannot be met mid-build, mark it `[revised]`, increment the revision, and re-present only the changed criteria.
+
+## Skill file
+
+Full behavior is defined in [`skills/intent-driven-development.md`](../skills/intent-driven-development.md).
+
+## Pairs with
+
+- `/grill-me`: grill-me clarifies a fuzzy input; this skill turns the agreed intent into verifiable criteria.
+- `/roast`: roast validates the idea, then scope the survivor into acceptance criteria.

package/plugins/continuous-improvement/lib/plugin-metadata.mjs

@@ -26,7 +26,7 @@ const KEYWORDS = [
     "transcript-linter",
 ];
 const CLAUDE_PLUGIN_CATEGORY = "productivity";
-const SHARED_PLUGIN_DESCRIPTION = "The persistent-memory and runtime-discipline layer for Claude Code. It remembers the corrections you already gave, grounds every edit in real facts before it lands, and — through the Mulahazah engine — turns each fix into a reusable instinct, so a lesson learned once is applied automatically next time with no re-teaching. Built on the 7 Laws of AI Agent Discipline (research, plan, verify, reflect, learn) and shipped as 26 bundled skills, instinct-aware hooks, an MCP toolset for recall and reflection, and a GitHub Action transcript linter that feeds real work history back into sharper instincts.";
+const SHARED_PLUGIN_DESCRIPTION = "The persistent-memory and runtime-discipline layer for Claude Code. It remembers the corrections you already gave, grounds every edit in real facts before it lands, and — through the Mulahazah engine — turns each fix into a reusable instinct, so a lesson learned once is applied automatically next time with no re-teaching. Built on the 7 Laws of AI Agent Discipline (research, plan, verify, reflect, learn) and shipped as 27 bundled skills, instinct-aware hooks, an MCP toolset for recall and reflection, and a GitHub Action transcript linter that feeds real work history back into sharper instincts.";
 // Four vendored upstream companions registered alongside the CI plugin.
 // Each entry points at a pinned-SHA snapshot under third-party/<name>/.
 // See third-party/MANIFEST.md for refresh recipes and per-snapshot

package/plugins/continuous-improvement/skills/README.md

@@ -29,6 +29,7 @@ skill set on disk.
 - `grill-me` — Enforces Law 1 (Research Before Executing) of the 7 Laws of AI Agent Discipline. Interview the user relentlessly about a plan or design until shared understanding is reached, resolving every branch of the decision tree before any code is written. Ported from mattpocock/skills under MIT.
 - `grill-with-docs` — Enforces Law 1 (Research Before Executing) and Law 7 (Learn From Every Session) of the 7 Laws of AI Agent Discipline. Grilling session that challenges your plan against the existing domain model, sharpens terminology, and updates CONTEXT.md + ADRs inline as decisions crystallise. Ported from mattpocock/skills under MIT.
 - `handoff` — Enforces Law 5 (Reflect After Every Session) of the 7 Laws of AI Agent Discipline. Compact the current conversation into a handoff document for another agent to pick up. Ported from mattpocock/skills under MIT.
+- `intent-driven-development` — Enforces Law 2 (Plan Is Sacred) of the 7 Laws of AI Agent Discipline. Turn an ambiguous or high-impact change into scoped, verifiable acceptance criteria (observable AC-NNN, explicit in/out scope, named verification methods, and a [revised] protocol that forbids silently dropping a criterion) before or alongside implementation, so the plan that gets built is the plan that was agreed, not an invented default. Use when clarifying a feature, defining acceptance criteria, de-risking a security/data/migration/integration change, or preparing implementation requirements for another agent. Do not trigger for trivial edits, straightforward fixes, active debugging, or code review.
 - `reconcile` — Enforces Law 1 (Research Before Executing) of the 7 Laws of AI Agent Discipline. Establishes git ground truth — branch, status, stashes, worktrees, ahead/behind — before any mutation, halts on protected or destructive operations, and verifies a push actually landed instead of assuming it did.
 - `recovery-classification` — Enforces Law 4 (Verify Before Reporting) of the 7 Laws of AI Agent Discipline. After any failure in the verification ladder or auto-loop, classify the failure class before retrying — provider, tool-schema, deterministic-policy, git, worktree, runtime — so retry-vs-pause-vs-self-heal-vs-stop is an intentional decision, not a generic 'try again'.
 - `roast` — Enforces Law 1 (Research Before Executing) of the 7 Laws of AI Agent Discipline. Convene a 5-persona adversarial council (Contrarian, Expansionist, Logician, Researcher, Buyer) that attacks an idea from every angle, then a Judge returns one GO / RESHAPE / KILL verdict plus the cheapest 48-hour test to de-risk it — so you pressure-test an idea before sinking time into building the wrong thing.

package/plugins/continuous-improvement/skills/intent-driven-development/SKILL.md

@@ -0,0 +1,161 @@
+---
+name: intent-driven-development
+tier: "2"
+description: "Enforces Law 2 (Plan Is Sacred) of the 7 Laws of AI Agent Discipline. Turn an ambiguous or high-impact change into scoped, verifiable acceptance criteria (observable AC-NNN, explicit in/out scope, named verification methods, and a [revised] protocol that forbids silently dropping a criterion) before or alongside implementation, so the plan that gets built is the plan that was agreed, not an invented default. Use when clarifying a feature, defining acceptance criteria, de-risking a security/data/migration/integration change, or preparing implementation requirements for another agent. Do not trigger for trivial edits, straightforward fixes, active debugging, or code review."
+origin: continuous-improvement
+user-invocable: true
+argument-hint: "[the change to scope into acceptance criteria]"
+---
+
+# /intent-driven-development: scope the change before you build it
+
+Law 2 says the plan is sacred: once a goal and its acceptance conditions are agreed, you do not silently drift from them. The cheapest way to honor that is to make the plan verifiable in the first place. A goal phrased as "make export work" cannot be held sacred because nobody can tell when it is met. This skill converts an ambiguous or high-impact request into observable acceptance criteria (`AC-001`, `AC-002`, ...) with named verification methods, so "done" is a fact two people would agree on, and a criterion can never be quietly dropped mid-build.
+
+It produces useful criteria without turning specification into ceremony: inspect available context first, expose only genuine ambiguity, and choose verification that fits the work and its risk.
+
+## When to activate
+
+- The user asks to clarify a feature, define acceptance criteria, or de-risk a change before implementation.
+- The request touches security, authentication, persistent data, migrations, external APIs, or compliance.
+- The user wants a handoff artifact another agent or team can implement without inventing requirements.
+- The request is ambiguous enough that the expected outcome is not yet observable or testable.
+- The user types `/intent-driven-development`, "define acceptance criteria", "scope this change", or "make this testable".
+
+Do not activate for trivial edits, one-line fixes, active debugging, code review, or implementation requests whose acceptance conditions are already clear.
+
+## How it works
+
+1. **Inspect context first.** Read the repository, docs, schemas, and test infrastructure for technical facts before asking any question. Treat product and business constraints as something only the user or a product artifact can supply.
+2. **Choose depth.** Quick Capture (3-7 criteria, low or moderate risk) or Full Acceptance Brief (security, data, migration, cross-system, or handoff).
+3. **Ask minimally.** Only ask questions whose answers cannot be inferred and that materially change scope or behavior. Group related questions into one batch.
+4. Write observable criteria. Each AC-NNN names a scenario, a trigger, an expected observable result, a prohibited side effect when meaningful, a verification method, and a priority. Do not use "correctly" or "securely" without defined evidence.
+5. **Proceed or hand off.** For a clear request with no blocking risk, record the criteria and continue. For a risky change, present the blockers and wait for confirmation.
+6. **Hold the plan sacred.** If a criterion cannot be met due to a constraint found mid-build, do not silently drop or work around it. Mark it `[revised]`, state the constraint, adjust scope or verification, increment the revision number, and re-present only the changed criteria before continuing.
+
+## Operating rules
+
+1. Inspect available repository, docs, issue, design, and test context before asking for technical facts that can be discovered locally.
+2. Do not infer product or business constraints from code. Business rules, compliance obligations, contractual SLAs, pricing, data-retention policy, prioritization, and target users cannot be read from a repository. Record them as assumptions flagged for confirmation, never as discovered facts. The repository tells you how the system behaves today, not what the business requires it to do.
+3. Ask only questions whose answers are required and cannot be safely inferred.
+4. Do not block implementation by default. When the user has asked to implement a sufficiently clear change, record key assumptions and criteria briefly, then proceed or hand them to the implementation workflow.
+5. Require explicit confirmation before proceeding only when an unresolved decision could create material security exposure, data loss, irreversible migration, contractual or API breakage, meaningful cost, or destructive external action.
+6. Do not write an acceptance document into a repository, alter project files, create a branch, commit, or invoke another skill unless the user requests it or the active workflow requires it.
+7. Treat automated tests as evidence, not truth. Prefer automation when reliable and proportionate; allow manual UX, accessibility, security, legal, or operational verification where automation cannot establish the outcome.
+8. Never include real secrets, credentials, tokens, private keys, personal data, or production payloads in criteria, fixtures, examples, or saved artifacts. Use redacted or synthetic values.
+9. Do not run destructive tests, migrations, security probes, load tests, paid external calls, or operations against production data without explicit authorization and an identified safe environment.
+10. When a criterion cannot be satisfied due to a constraint discovered during implementation, update it (`[revised]`, state the constraint, adjust scope or verification), increment the revision, and re-present only the changed criteria. Require confirmation only if the revision changes a blocking decision or reduces a safety or correctness guarantee.
+
+## Choose the depth
+
+Use the smallest useful output.
+
+### Quick Capture
+
+For a clear but non-trivial change with low or moderate risk. Produce: Goal; In scope and out of scope; Assumptions; 3-7 acceptance criteria with verification methods; blocking questions if any. Do not delay implementation for approval unless a blocking risk exists or the user asked for a spec first.
+
+### Full Acceptance Brief
+
+For ambiguous, cross-system, security-sensitive, data-changing, migration, compliance, or high-cost changes, or when the user wants a handoff artifact. Produce the full template below and request confirmation for unresolved blocking decisions before risky implementation.
+
+### Existing specification review
+
+When the user already supplied a PRD, issue, plan, or criteria: review it instead of restarting discovery. Identify missing scope boundaries, unsafe assumptions, contradictions, and unverifiable requirements. Return corrected or supplemental criteria.
+
+## Write acceptance criteria
+
+Use `AC-001`, `AC-002`, and so on. Criteria and tests need not map one-to-one. For each applicable criterion include: scenario or starting condition; action or trigger; expected observable behavior; prohibited side effect when meaningful; verification method (automated test, integration check, manual UX review, accessibility check, security review, operational check, or stakeholder acceptance); environment or safety constraint when verification could affect data, services, cost, or secrets; priority (Required, Important, or Optional).
+
+Do not use "correctly", "securely", "fast", "intuitive", or "robust" without defining observable evidence or recording them as a human-review judgment.
+
+Cover only the boundaries that apply:
+
+| Category | Include when | Typical evidence |
+| --- | --- | --- |
+| Happy path | New or changed user-visible behavior | Successful workflow or state transition |
+| Validation | The change accepts input | Malformed or boundary value rejected without mutation |
+| Authorization/privacy | Data or actions have access boundaries | Denied access and no sensitive disclosure |
+| Persistence/migration | Stored data or schemas change | Backward read, migration, rollback, or backup behavior |
+| Compatibility | Public APIs, files, events, or clients may break | Existing contract or fixture stays valid |
+| Failure recovery | Network, service, or async failure exists | No partial state, or clear retry and degraded behavior |
+| Idempotency/concurrency | Repeats or simultaneous writes are plausible | No duplicate side effect or invalid final state |
+| Performance | A user or service threshold matters | Defined measurement conditions and threshold |
+| UX/accessibility | A person interacts with the result | Keyboard, feedback, error recovery, visual or manual review |
+
+## Output template (Full Acceptance Brief)
+
+Omit irrelevant sections for Quick Capture.
+
+```markdown
+# Acceptance Brief: <Change Name>
+
+**Status:** Draft | Approved | Implemented | Verified
+**Revision:** <number>
+**Prepared for:** <user/team/agent, when known>
+
+## Goal
+<One observable outcome sentence.>
+
+## Scope
+**In scope:** <behavior included>
+**Out of scope:** <adjacent work excluded>
+
+## Context
+**Discovered facts** (technical, verified from repository or artifact)
+**Product/business constraints** (supplied by user or artifact, never inferred from code, or "none supplied yet")
+**Assumptions** (unverified claims to confirm)
+**Dependencies and constraints**
+
+## Risk Review
+| Risk area | Applies? | Required handling |
+| --- | --- | --- |
+| Security/privacy | Yes/No | <redaction, authorization, review> |
+| Persistent data/migration | Yes/No | <compatibility, backup, rollback> |
+| External effects/cost | Yes/No | <sandbox, test environment, authorization> |
+| Compatibility/API | Yes/No | <contract to preserve or version> |
+| UX/accessibility | Yes/No | <manual or automated evidence> |
+
+## Acceptance Criteria
+### AC-001: <observable behavior>
+- **Scenario:** <starting condition>
+- **Action:** <single trigger>
+- **Expected:** <observable result>
+- **Must not:** <prohibited side effect, if applicable>
+- **Verification:** <method and intended evidence>
+- **Environment/safety:** <constraints, if applicable>
+- **Priority:** Required | Important | Optional
+
+## Blocking Decisions
+- [ ] <only decisions that prevent safe or correct progress>
+
+## Verification Plan
+| Criterion | Verification evidence | Status |
+| --- | --- | --- |
+| AC-001 | <test, check, or review command or evidence type> | Pending |
+```
+
+## Pass/fail rubric
+
+A brief passes only if every answer is "yes". Any "no" means revise before returning it.
+
+- [ ] Does every required criterion have a scenario, an observable expected result, and a named verification method?
+- [ ] Are vague terms ("correctly", "secure", "fast", "robust") either replaced with observable evidence or marked as human judgment?
+- [ ] Are product and business constraints listed as supplied or assumed, with none silently inferred from code?
+- [ ] Is scope explicit, with out-of-scope items named?
+- [ ] Are blocking decisions limited to choices that actually affect safety or correctness, not preferences?
+
+A failing criterion: `AC-001: The export works correctly and is secure.` (no scenario, no observable result, no verification, "correctly" and "secure" undefined). A passing one names the scenario, the expected result, the prohibited side effect, and the verification method, so two people would agree it was met.
+
+## How it fits the 7 Laws
+
+| Law | Role of this skill |
+|---|---|
+| Law 2 (Plan Is Sacred) | The acceptance brief **is** the sacred plan: observable criteria, explicit scope, and a `[revised]` protocol that forbids silently dropping or working around a criterion mid-build. |
+| Law 1 (Research Before Executing) | Rule 1 inspects repo, docs, schemas, and tests for technical facts before asking, and refuses to infer business rules from code. |
+| Law 4 (Verify Before Reporting) | Every criterion carries a named verification method and a pass/fail rubric, so "done" is falsifiable rather than asserted. |
+
+## Pairs with
+
+- [`grill-me`](./grill-me.md): interviews a fuzzy request to a shippable spec. Reach for `grill-me` when the input is unclear, then this skill to turn the agreed intent into verifiable criteria.
+- [`roast`](./roast.md): validates whether the idea should exist at all. Roast first, then scope the survivor into acceptance criteria.
+- [`goal-monitor`](./goal-monitor.md): the runtime drift gate. The `## Goal` and criteria this skill produces are what goal-monitor scores a session against.
+- [`verification-loop`](./verification-loop.md): runs the per-project verify ladder. The criteria's verification methods feed its evidence step.

package/plugins/expert.json

@@ -1,6 +1,6 @@
 {
   "name": "continuous-improvement",
-  "version": "3.16.0",
+  "version": "3.17.0",
   "mode": "expert",
   "description": "Expert mode: tune confidence, manage instincts, and persist plans on disk. Adds safety, token-budget, and strategic-compact skills plus the /learn-eval command so long sessions stay sharp and learnings survive context resets.",
   "tools": [

package/skills/intent-driven-development.md

@@ -0,0 +1,161 @@
+---
+name: intent-driven-development
+tier: "2"
+description: "Enforces Law 2 (Plan Is Sacred) of the 7 Laws of AI Agent Discipline. Turn an ambiguous or high-impact change into scoped, verifiable acceptance criteria (observable AC-NNN, explicit in/out scope, named verification methods, and a [revised] protocol that forbids silently dropping a criterion) before or alongside implementation, so the plan that gets built is the plan that was agreed, not an invented default. Use when clarifying a feature, defining acceptance criteria, de-risking a security/data/migration/integration change, or preparing implementation requirements for another agent. Do not trigger for trivial edits, straightforward fixes, active debugging, or code review."
+origin: continuous-improvement
+user-invocable: true
+argument-hint: "[the change to scope into acceptance criteria]"
+---
+
+# /intent-driven-development: scope the change before you build it
+
+Law 2 says the plan is sacred: once a goal and its acceptance conditions are agreed, you do not silently drift from them. The cheapest way to honor that is to make the plan verifiable in the first place. A goal phrased as "make export work" cannot be held sacred because nobody can tell when it is met. This skill converts an ambiguous or high-impact request into observable acceptance criteria (`AC-001`, `AC-002`, ...) with named verification methods, so "done" is a fact two people would agree on, and a criterion can never be quietly dropped mid-build.
+
+It produces useful criteria without turning specification into ceremony: inspect available context first, expose only genuine ambiguity, and choose verification that fits the work and its risk.
+
+## When to activate
+
+- The user asks to clarify a feature, define acceptance criteria, or de-risk a change before implementation.
+- The request touches security, authentication, persistent data, migrations, external APIs, or compliance.
+- The user wants a handoff artifact another agent or team can implement without inventing requirements.
+- The request is ambiguous enough that the expected outcome is not yet observable or testable.
+- The user types `/intent-driven-development`, "define acceptance criteria", "scope this change", or "make this testable".
+
+Do not activate for trivial edits, one-line fixes, active debugging, code review, or implementation requests whose acceptance conditions are already clear.
+
+## How it works
+
+1. **Inspect context first.** Read the repository, docs, schemas, and test infrastructure for technical facts before asking any question. Treat product and business constraints as something only the user or a product artifact can supply.
+2. **Choose depth.** Quick Capture (3-7 criteria, low or moderate risk) or Full Acceptance Brief (security, data, migration, cross-system, or handoff).
+3. **Ask minimally.** Only ask questions whose answers cannot be inferred and that materially change scope or behavior. Group related questions into one batch.
+4. Write observable criteria. Each AC-NNN names a scenario, a trigger, an expected observable result, a prohibited side effect when meaningful, a verification method, and a priority. Do not use "correctly" or "securely" without defined evidence.
+5. **Proceed or hand off.** For a clear request with no blocking risk, record the criteria and continue. For a risky change, present the blockers and wait for confirmation.
+6. **Hold the plan sacred.** If a criterion cannot be met due to a constraint found mid-build, do not silently drop or work around it. Mark it `[revised]`, state the constraint, adjust scope or verification, increment the revision number, and re-present only the changed criteria before continuing.
+
+## Operating rules
+
+1. Inspect available repository, docs, issue, design, and test context before asking for technical facts that can be discovered locally.
+2. Do not infer product or business constraints from code. Business rules, compliance obligations, contractual SLAs, pricing, data-retention policy, prioritization, and target users cannot be read from a repository. Record them as assumptions flagged for confirmation, never as discovered facts. The repository tells you how the system behaves today, not what the business requires it to do.
+3. Ask only questions whose answers are required and cannot be safely inferred.
+4. Do not block implementation by default. When the user has asked to implement a sufficiently clear change, record key assumptions and criteria briefly, then proceed or hand them to the implementation workflow.
+5. Require explicit confirmation before proceeding only when an unresolved decision could create material security exposure, data loss, irreversible migration, contractual or API breakage, meaningful cost, or destructive external action.
+6. Do not write an acceptance document into a repository, alter project files, create a branch, commit, or invoke another skill unless the user requests it or the active workflow requires it.
+7. Treat automated tests as evidence, not truth. Prefer automation when reliable and proportionate; allow manual UX, accessibility, security, legal, or operational verification where automation cannot establish the outcome.
+8. Never include real secrets, credentials, tokens, private keys, personal data, or production payloads in criteria, fixtures, examples, or saved artifacts. Use redacted or synthetic values.
+9. Do not run destructive tests, migrations, security probes, load tests, paid external calls, or operations against production data without explicit authorization and an identified safe environment.
+10. When a criterion cannot be satisfied due to a constraint discovered during implementation, update it (`[revised]`, state the constraint, adjust scope or verification), increment the revision, and re-present only the changed criteria. Require confirmation only if the revision changes a blocking decision or reduces a safety or correctness guarantee.
+
+## Choose the depth
+
+Use the smallest useful output.
+
+### Quick Capture
+
+For a clear but non-trivial change with low or moderate risk. Produce: Goal; In scope and out of scope; Assumptions; 3-7 acceptance criteria with verification methods; blocking questions if any. Do not delay implementation for approval unless a blocking risk exists or the user asked for a spec first.
+
+### Full Acceptance Brief
+
+For ambiguous, cross-system, security-sensitive, data-changing, migration, compliance, or high-cost changes, or when the user wants a handoff artifact. Produce the full template below and request confirmation for unresolved blocking decisions before risky implementation.
+
+### Existing specification review
+
+When the user already supplied a PRD, issue, plan, or criteria: review it instead of restarting discovery. Identify missing scope boundaries, unsafe assumptions, contradictions, and unverifiable requirements. Return corrected or supplemental criteria.
+
+## Write acceptance criteria
+
+Use `AC-001`, `AC-002`, and so on. Criteria and tests need not map one-to-one. For each applicable criterion include: scenario or starting condition; action or trigger; expected observable behavior; prohibited side effect when meaningful; verification method (automated test, integration check, manual UX review, accessibility check, security review, operational check, or stakeholder acceptance); environment or safety constraint when verification could affect data, services, cost, or secrets; priority (Required, Important, or Optional).
+
+Do not use "correctly", "securely", "fast", "intuitive", or "robust" without defining observable evidence or recording them as a human-review judgment.
+
+Cover only the boundaries that apply:
+
+| Category | Include when | Typical evidence |
+| --- | --- | --- |
+| Happy path | New or changed user-visible behavior | Successful workflow or state transition |
+| Validation | The change accepts input | Malformed or boundary value rejected without mutation |
+| Authorization/privacy | Data or actions have access boundaries | Denied access and no sensitive disclosure |
+| Persistence/migration | Stored data or schemas change | Backward read, migration, rollback, or backup behavior |
+| Compatibility | Public APIs, files, events, or clients may break | Existing contract or fixture stays valid |
+| Failure recovery | Network, service, or async failure exists | No partial state, or clear retry and degraded behavior |
+| Idempotency/concurrency | Repeats or simultaneous writes are plausible | No duplicate side effect or invalid final state |
+| Performance | A user or service threshold matters | Defined measurement conditions and threshold |
+| UX/accessibility | A person interacts with the result | Keyboard, feedback, error recovery, visual or manual review |
+
+## Output template (Full Acceptance Brief)
+
+Omit irrelevant sections for Quick Capture.
+
+```markdown
+# Acceptance Brief: <Change Name>
+
+**Status:** Draft | Approved | Implemented | Verified
+**Revision:** <number>
+**Prepared for:** <user/team/agent, when known>
+
+## Goal
+<One observable outcome sentence.>
+
+## Scope
+**In scope:** <behavior included>
+**Out of scope:** <adjacent work excluded>
+
+## Context
+**Discovered facts** (technical, verified from repository or artifact)
+**Product/business constraints** (supplied by user or artifact, never inferred from code, or "none supplied yet")
+**Assumptions** (unverified claims to confirm)
+**Dependencies and constraints**
+
+## Risk Review
+| Risk area | Applies? | Required handling |
+| --- | --- | --- |
+| Security/privacy | Yes/No | <redaction, authorization, review> |
+| Persistent data/migration | Yes/No | <compatibility, backup, rollback> |
+| External effects/cost | Yes/No | <sandbox, test environment, authorization> |
+| Compatibility/API | Yes/No | <contract to preserve or version> |
+| UX/accessibility | Yes/No | <manual or automated evidence> |
+
+## Acceptance Criteria
+### AC-001: <observable behavior>
+- **Scenario:** <starting condition>
+- **Action:** <single trigger>
+- **Expected:** <observable result>
+- **Must not:** <prohibited side effect, if applicable>
+- **Verification:** <method and intended evidence>
+- **Environment/safety:** <constraints, if applicable>
+- **Priority:** Required | Important | Optional
+
+## Blocking Decisions
+- [ ] <only decisions that prevent safe or correct progress>
+
+## Verification Plan
+| Criterion | Verification evidence | Status |
+| --- | --- | --- |
+| AC-001 | <test, check, or review command or evidence type> | Pending |
+```
+
+## Pass/fail rubric
+
+A brief passes only if every answer is "yes". Any "no" means revise before returning it.
+
+- [ ] Does every required criterion have a scenario, an observable expected result, and a named verification method?
+- [ ] Are vague terms ("correctly", "secure", "fast", "robust") either replaced with observable evidence or marked as human judgment?
+- [ ] Are product and business constraints listed as supplied or assumed, with none silently inferred from code?
+- [ ] Is scope explicit, with out-of-scope items named?
+- [ ] Are blocking decisions limited to choices that actually affect safety or correctness, not preferences?
+
+A failing criterion: `AC-001: The export works correctly and is secure.` (no scenario, no observable result, no verification, "correctly" and "secure" undefined). A passing one names the scenario, the expected result, the prohibited side effect, and the verification method, so two people would agree it was met.
+
+## How it fits the 7 Laws
+
+| Law | Role of this skill |
+|---|---|
+| Law 2 (Plan Is Sacred) | The acceptance brief **is** the sacred plan: observable criteria, explicit scope, and a `[revised]` protocol that forbids silently dropping or working around a criterion mid-build. |
+| Law 1 (Research Before Executing) | Rule 1 inspects repo, docs, schemas, and tests for technical facts before asking, and refuses to infer business rules from code. |
+| Law 4 (Verify Before Reporting) | Every criterion carries a named verification method and a pass/fail rubric, so "done" is falsifiable rather than asserted. |
+
+## Pairs with
+
+- [`grill-me`](./grill-me.md): interviews a fuzzy request to a shippable spec. Reach for `grill-me` when the input is unclear, then this skill to turn the agreed intent into verifiable criteria.
+- [`roast`](./roast.md): validates whether the idea should exist at all. Roast first, then scope the survivor into acceptance criteria.
+- [`goal-monitor`](./goal-monitor.md): the runtime drift gate. The `## Goal` and criteria this skill produces are what goal-monitor scores a session against.
+- [`verification-loop`](./verification-loop.md): runs the per-project verify ladder. The criteria's verification methods feed its evidence step.