From cb292b03ba4dd179f0caf2694d988a629c85a5f4 Mon Sep 17 00:00:00 2001 From: Mujtaba Badat <1470881+mujtaba3B@users.noreply.github.com> Date: Tue, 18 Aug 2026 13:21:39 +0200 Subject: [PATCH 1/2] chore(eng,qa): trim seven over-long skill descriptions to stop listing truncation The injected skill listing was running over its context budget, with the longest descriptions truncated mid-sentence. Text past the cut does no routing work, so trimming recovers the tokens AND recovers trigger text that was being discarded. Rewrites each description as a routing surface: what it does, when to trigger, how it differs from siblings. Execution detail stays in the body; near-duplicate trigger phrases are dropped. No body content changed (verified byte-identical). 8,423 -> 6,132 description chars across the seven (~572 est. tokens/session). A trigger-survival check during QA caught real coverage loss in the first pass and it was restored: "review before merge" (cr), "is this good to deploy?" (cr-teammate), "the deploy failed, run it again" (deploy), "verify the happy path" (browser), "dev and prod qa plan" (qa-plan), and the sibling skill names in spike's NOT-this-skill list. Every phrase still absent has a kept near-duplicate. Also rewrites eng/skills/deploy's description as a block scalar. It was an unquoted YAML scalar containing ": ", which is strictly invalid; all seven now pass a real PyYAML parse. Bumps eng 2.9.0 -> 2.9.1 and qa 3.6.1 -> 3.6.2. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_015SMqMN8zAHtHgiZ596b8pC --- eng/.claude-plugin/plugin.json | 2 +- eng/skills/cr-teammate/SKILL.md | 2 +- eng/skills/cr/SKILL.md | 2 +- eng/skills/deploy/SKILL.md | 3 ++- eng/skills/spike/SKILL.md | 2 +- qa/.claude-plugin/plugin.json | 2 +- qa/skills/browser/SKILL.md | 19 ++----------------- qa/skills/headless/SKILL.md | 16 ++-------------- qa/skills/qa-plan/SKILL.md | 22 ++-------------------- 9 files changed, 13 insertions(+), 57 deletions(-) diff --git a/eng/.claude-plugin/plugin.json b/eng/.claude-plugin/plugin.json index c7c8172..267bd05 100644 --- a/eng/.claude-plugin/plugin.json +++ b/eng/.claude-plugin/plugin.json @@ -1,6 +1,6 @@ { "name": "eng", - "version": "2.9.0", + "version": "2.9.1", "description": "Engineer Ernie, the engineering persona. eng:cr is his master code-review skill and the single local review path the ~/dev merge gate keys on: it risk-tiers depth, runs the pr-review-toolkit lenses, and mints the merge-clearance stamp. It routes to cr-teammate (review someone else's PR and post a comment) and to address-pr-feedback / pr-watcher (respond to review feedback). He also spikes the riskiest unknown before building, generates CodeRabbit config, and builds macOS Shortcuts. The plugin also SHIPS Ernie's PR-lifecycle enforcement hooks (hooks/hooks.json): the ship-PR gate (PRs only via /ship), the merge-clearance gate (no merge without the cleared gauntlet AND a /land-and-deploy sentinel, making /land-and-deploy the single CLI merge path), the deploy gate (no deploy outside a ceremony: it blocks both the repo's declared deploy entrypoint and the hand-rolled ssh build/restart shape unless /land-and-deploy or /eng:deploy armed the session), the /ship and /land-and-deploy sentinels, the review stamp recorder, and an after-ship CodeRabbit-watcher nudge (after a genuine /ship opens a PR, points the agent at /eng:pr-watcher, or when CodeRabbit is rate-limited routes to /land-and-deploy if a current /eng:cr review backstops the head, else to /eng:cr and then /land-and-deploy), active in opted-in repos (.ship-gate.json / .merge-clearance.json / .deploy-gate.json) under ~/dev. Skills: eng:cr, eng:cr-teammate, eng:deploy, eng:address-pr-feedback, eng:pr-watcher, eng:spike, eng:coderabbit-config, eng:shortcut.", "author": { "name": "Mujtaba Badat", diff --git a/eng/skills/cr-teammate/SKILL.md b/eng/skills/cr-teammate/SKILL.md index 5eed835..53f44b6 100644 --- a/eng/skills/cr-teammate/SKILL.md +++ b/eng/skills/cr-teammate/SKILL.md @@ -1,7 +1,7 @@ --- name: cr-teammate description: >- - Review a GitHub pull request authored by SOMEONE ELSE (a human teammate or an autonomous agent like a mu*/*-ai bot) and leave one well-structured, author-tagged review comment on it. This is eng:cr's specialist for "review someone else's PR": it runs the same shared review engine (the pr-review-toolkit lenses plus a design/blast-radius lens), verifies the sharp findings against the actual repo rather than trusting the PR description, gives the user a quick chat summary, then always posts exactly ONE structured comment via gh pr comment led by an @ mention so the author (human or bot) is notified to act. The run always ends in a posted, author-tagged comment regardless of verdict, after a confirm gate on the wording. Never merges, never pushes, never resolves conversations, never touches the assignee, and does not mint the merge-clearance stamp (that is eng:cr's job for your own pre-merge work). Use when asked to "review this PR", "review the teammate's PR", "review the agent PR", "is this good to deploy?", "look at PR #N", "review MuThree's PR", or invoked as "/eng:cr-teammate" with a PR number or URL. + Review a GitHub pull request authored by SOMEONE ELSE (a human teammate or an autonomous agent like a mu*/*-ai bot) and leave one author-tagged review comment on it. This is eng:cr's specialist for reviewing someone else's PR: same shared review engine and lenses, findings verified against the actual repo rather than the PR description, a quick chat summary, then exactly ONE structured comment posted via gh pr comment led by an @ mention, after a confirm gate on the wording. Never merges, pushes, resolves conversations, or mints the merge-clearance stamp (that is eng:cr's job). Use for "review this PR", "review the teammate's PR", "review the agent PR", "is this good to deploy?", "look at PR #N", or "/eng:cr-teammate" with a PR number or URL. --- ## Update check (run first) diff --git a/eng/skills/cr/SKILL.md b/eng/skills/cr/SKILL.md index f9e3a5c..fa4a855 100644 --- a/eng/skills/cr/SKILL.md +++ b/eng/skills/cr/SKILL.md @@ -1,7 +1,7 @@ --- name: cr description: >- - Engineer Ernie's master code-review skill and the single local review path for ~/dev work. Call it to review ANY code before merge: your own uncommitted diff, your own PR, or someone else's. It scopes the diff, picks review depth by risk (trivial -> light; routine -> one Claude adversarial pass; major/risky like auth, money, migrations, concurrency, cross-host, generated code, or large refactors -> full pr-review-toolkit lens set plus a cross-model pass), runs the lenses, verifies the sharp findings against the real repo, surfaces a bucketed verdict, and mints the merge-clearance gate stamp (/review-skill-head) on the reviewed HEAD. It is the reviewer the ~/dev merge gate keys on. It ROUTES rather than duplicates: someone else's PR -> eng:cr-teammate (posts an author-tagged comment); existing review comments to handle -> eng:address-pr-feedback (manual) or eng:pr-watcher (autonomous CodeRabbit loop). Trigger when the user says "cr", "cr this", "code review", "review this", "review my diff", "review my code", "review my PR", "review before merge", "is this ready to merge", or invokes "/eng:cr". This is the default reviewer; prefer it over gstack /review for any ~/dev PR that must pass the merge-clearance gate, because it is what mints the gate stamp. + Engineer Ernie's master code-review skill and the single local review path for ~/dev work. Reviews ANY code before merge: your own uncommitted diff, your own PR, or someone else's. Scopes the diff, picks depth by risk (trivial -> light; routine -> one adversarial pass; major/risky like auth, money, migrations, concurrency, cross-host, or large refactors -> full pr-review-toolkit lens set plus a cross-model pass), verifies findings against the real repo, surfaces a bucketed verdict, and mints the merge-clearance gate stamp on the reviewed HEAD. Routes rather than duplicates: someone else's PR -> eng:cr-teammate; existing review comments -> eng:address-pr-feedback or eng:pr-watcher. Trigger on "cr", "cr this", "code review", "review this", "review my diff", "review my PR", "review before merge", "is this ready to merge", "/eng:cr". Prefer it over gstack /review for any ~/dev PR, because it is what mints the gate stamp. --- ## Update check (run first) diff --git a/eng/skills/deploy/SKILL.md b/eng/skills/deploy/SKILL.md index 1e74d88..8078ecd 100644 --- a/eng/skills/deploy/SKILL.md +++ b/eng/skills/deploy/SKILL.md @@ -1,6 +1,7 @@ --- name: deploy -description: Deploy what is already on main, as a verified ceremony. Engineer Ernie's deploy-only counterpart to /land-and-deploy, for the PR-less cases that skill structurally cannot serve: retrying after a failed deploy, recovering a wedged host, and re-running with --rebuild-base / --rederive-all. It asserts the tree is clean, on main, and synced; refuses when the branch has an open unmerged PR (that is /land-and-deploy's job); shows the delta between what the host is running and what main holds; runs the repo's declared deploy command from deploy.json; and gates the result on `devops check`, so the deploy is not "done" until the checks pass. It also arms the deploy gate, which is what makes it a sanctioned path rather than a hand-roll. Trigger when the user says "/eng:deploy", "deploy", "deploy it", "deploy main", "redeploy", "deploy to the mini", "retry the deploy", "the deploy failed, run it again", "rebuild and deploy", "push this live", or otherwise asks to deploy code that is already merged. Use /land-and-deploy instead when there is an open PR to merge first. +description: >- + Deploy what is already on main, as a verified ceremony. Engineer Ernie's deploy-only counterpart to /land-and-deploy, for the PR-less cases that skill structurally cannot serve: retrying after a failed deploy, recovering a wedged host, and re-running with --rebuild-base / --rederive-all. Asserts the tree is clean, on main, and synced; refuses when the branch has an open unmerged PR (that is /land-and-deploy's job); shows the delta between what the host is running and what main holds; runs the repo's declared deploy command from deploy.json; and gates the result on `devops check`. It also arms the deploy gate, which is what makes it a sanctioned path rather than a hand-roll. Trigger on "/eng:deploy", "deploy", "deploy it", "deploy main", "redeploy", "deploy to the mini", "retry the deploy", "the deploy failed, run it again", "rebuild and deploy", "push this live". Use /land-and-deploy instead when there is an open PR to merge first. --- ## Update check (run first) diff --git a/eng/skills/spike/SKILL.md b/eng/skills/spike/SKILL.md index 72d9781..5b74523 100644 --- a/eng/skills/spike/SKILL.md +++ b/eng/skills/spike/SKILL.md @@ -1,7 +1,7 @@ --- name: spike description: >- - Cheaply prove or disprove the riskiest unknown of a feature before committing to plan and build. Fire this skill whenever the user wants to "spike", "spike this", "spike a feature", "throwaway prove this works", "test the risky part first", "is this even possible", "smallest thing that proves the mechanic", "can we even do X", or otherwise signals they want to skip ahead and stress-test the one thing that could kill a feature before investing in the surrounding scaffolding. Proactively suggest this skill when the user is about to invoke `/plan-eng-review` or `/autoplan` on a feature that has a clear single unknown the plan would be guessing at. Drives a four-phase loop: lock the one-line outcome, write the leanest throwaway code that could falsify it on a `spike/` branch, escalate via `/second-opinion` (then user) when blocked, land a yes/no verdict in `SPIKE.md` before context compacts. NOT planning (`/plan-eng-review`), NOT ideation (`/office-hours`), NOT post-build QA (`/qa`), NOT change validation (`/verify`). Spike code is explicitly exempt from `karpathy-guidelines` production discipline. Also fires on `/eng:spike`. + Cheaply prove or disprove the riskiest unknown of a feature before committing to plan and build. Drives a four-phase loop: lock the one-line outcome, write the leanest throwaway code that could falsify it on a `spike/` branch, escalate via /second-opinion then the user when blocked, and land a yes/no verdict in SPIKE.md before context compacts. Trigger on "spike", "spike this", "spike a feature", "throwaway prove this works", "test the risky part first", "is this even possible", "can we even do X", "smallest thing that proves the mechanic", "/eng:spike". Proactively suggest it when the user is about to invoke /plan-eng-review or /autoplan on a feature with one clear unknown. NOT planning (/plan-eng-review), NOT ideation (/office-hours), NOT post-build QA (/qa), NOT change validation (/verify); spike code is exempt from karpathy-guidelines production discipline. --- ## Update check (run first) diff --git a/qa/.claude-plugin/plugin.json b/qa/.claude-plugin/plugin.json index b1a149a..363ce0a 100644 --- a/qa/.claude-plugin/plugin.json +++ b/qa/.claude-plugin/plugin.json @@ -1,6 +1,6 @@ { "name": "qa", - "version": "3.6.1", + "version": "3.6.2", "description": "QA Quincey, the manual-QA persona. Verifies one defined flow against the spec or mockup and records a QA posture. qa:browser drives the real running app through the user's persistent agent-browser session (click/pixel level), walks the spec, seeds and tears down tagged data via the repo's recipe, and ends with the QA_STATUS contract that satisfies the build-time Stop hook and the PR qa-gate CI. qa:headless does the same for backend features with no UI (capturing side effects). qa:qa-plan authors the two-phase QA plan and writes the approval stamp. The plugin also SHIPS Quincey's enforcement hooks (hooks/hooks.json): the QA-plan gates (presentation, build, PR) and the QA-status Stop gate, active in opted-in repos (.qa-plan-gate.json) under ~/dev. Skills: qa:browser, qa:headless, qa:qa-plan.", "author": { "name": "Mujtaba Badat", diff --git a/qa/skills/browser/SKILL.md b/qa/skills/browser/SKILL.md index 6026e5c..44ecb12 100644 --- a/qa/skills/browser/SKILL.md +++ b/qa/skills/browser/SKILL.md @@ -2,23 +2,8 @@ name: browser preamble-tier: 4 version: 2.0.0 -description: | - QA Quincey's flagship skill: defined-flow LIVE-browser QA that drives the - real running app through the user's persistent agent-browser session - (abrowser, headed) at click/pixel level, not just endpoint calls. Pulls the - happy path from a GitHub issue, spec, or Pencil mockup; WALKS THE SPEC - (spec/eng docs + Pencil frames) and reports per-assertion Spec compliance - (matches/drifts/missing); boots the app and seeds TAGGED test data via the - repo's own recipe, then tears it down exactly; observes at the real surface - (URL/redirect, rendered DOM, screenshots) with at least one adversarial - off-happy-path probe; and ends by stating the QA posture contract - (QA_STATUS: verified + EVIDENCE) that satisfies the build-time Stop hook and - the PR qa-gate CI. Use when the user says "qa quincey", "live qa", "qa this - flow", "test the happy path on the real browser", "verify the deploy on X", - "walk the spec", or invokes this skill directly. Use this rather than /qa - when the goal is to verify one specific flow against an explicit acceptance - bar and record a QA posture, not to sweep the app for any bugs. (gstack-extensions) - Voice triggers (speech-to-text aliases): "qa quincey", "live qa", "verify the happy path", "test this flow on the real browser", "walk the spec". +description: >- + QA Quincey's flagship skill: defined-flow LIVE-browser QA that drives the real running app through the user's persistent agent-browser session (abrowser, headed) at click/pixel level, not just endpoint calls. Pulls the happy path from a GitHub issue, spec, or Pencil mockup; walks the spec and reports per-assertion compliance (matches/drifts/missing); boots the app and seeds TAGGED test data via the repo's own recipe, then tears it down exactly; observes at the real surface (URL/redirect, rendered DOM, screenshots) with at least one adversarial off-happy-path probe; and ends by stating the QA posture contract (QA_STATUS: verified + EVIDENCE) that the build-time Stop hook and PR qa-gate CI read. Use for "qa quincey", "live qa", "qa this flow", "test the happy path on the real browser", "verify the deploy on X", "verify the happy path", "walk the spec". Use rather than /qa when verifying one flow against an explicit acceptance bar. (gstack-extensions) allowed-tools: - Bash - Read diff --git a/qa/skills/headless/SKILL.md b/qa/skills/headless/SKILL.md index 65494a5..aebf1a7 100644 --- a/qa/skills/headless/SKILL.md +++ b/qa/skills/headless/SKILL.md @@ -2,20 +2,8 @@ name: headless preamble-tier: 4 version: 2.0.0 -description: | - QA Quincey's backend-feature QA skill. Systematically verify backend features - that have no UI: cron jobs, queue workers, webhook handlers, notifiers, CLIs, - ETL/data pipelines. Drive the feature in dry-run, capture side effects - (Slack messages, emails, DB writes, log lines, generated files), render them - readably, find bugs, fix them with atomic commits, re-verify. Sibling to - qa:browser inside the qa plugin; both share - the QA Quincey identity defined in shared/core.md. Use when asked to - "qa quincey headless", "test this cron", "test this worker", "test this notifier", - "qa the backend", "test the digest", "/qa:headless", or when you need to verify - a backend feature whose output is a side effect rather than a rendered page. - v1 ships Python end-to-end; Node, Ruby, and Go shape detection works, with - HTTP capture coming in follow-up PRs. Successor to /qa-headless. (gstack-extensions) - Voice triggers (speech-to-text aliases): "test the cron", "test the worker", "test the notifier", "qa the backend", "test the digest". +description: >- + QA Quincey's backend-feature QA skill. Systematically verify backend features that have no UI: cron jobs, queue workers, webhook handlers, notifiers, CLIs, ETL/data pipelines. Drive the feature in dry-run, capture side effects (Slack messages, emails, DB writes, log lines, generated files), render them readably, find bugs, fix them with atomic commits, re-verify. Sibling to qa:browser inside the qa plugin; both share the QA Quincey identity in shared/core.md. Use for "qa quincey headless", "test this cron", "test this worker", "test this notifier", "qa the backend", "test the digest", "/qa:headless", or any backend feature whose output is a side effect rather than a rendered page. (gstack-extensions) allowed-tools: - Bash - Read diff --git a/qa/skills/qa-plan/SKILL.md b/qa/skills/qa-plan/SKILL.md index e5ed8df..6da83ed 100644 --- a/qa/skills/qa-plan/SKILL.md +++ b/qa/skills/qa-plan/SKILL.md @@ -1,26 +1,8 @@ --- name: qa-plan version: 2.2.0 -description: | - QA Quincey's planning skill: turn a change's success criteria into a two-phase - QA plan written into the PR body, BEFORE the PR is reviewed or merged. Produces a - Development QA section (must pass in a dev / preview environment before merge), - a Production QA section (verified live after deploy), and a Definition of Done. - It also publishes a companion Claude artifact: a rendered, pointable, always-linked - view of the same plan (the PR body stays the machine source of truth the gates read). - Each item traces to an acceptance criterion (Given/When/Then or EARS) and names - the tool that exercises it. It PLANS QA; it does not execute it (Development QA is - run by /qa, qa:browser, or qa:headless; Production QA by /canary). It ENDS by - presenting the plan (and a recommended QA driver from the qa plugin's qa-roster.json, - default mutwo, named in the PR body with their handle) for the human's approval - and, on a yes, writing the approval stamp the QA-plan gates read (build / PR / - deploy). It feeds the two-phase QA posture (dev_verified / - prod_verified) the QA-status gate reads. Use when the user says "qa plan", "write - the qa plan", "plan the QA", "qa section for the PR", "dev and prod QA plan", - "/qa:plan", or when a change needs its QA plan authored before the PR goes up. - Sibling to qa:browser and qa:headless inside the qa plugin; shares the QA Quincey - identity in shared/core.md. (gstack-extensions) - Voice triggers (speech-to-text aliases): "qa plan", "write the qa plan", "plan the QA", "dev and prod QA plan". +description: >- + QA Quincey's planning skill: turn a change's success criteria into a two-phase QA plan written into the PR body, BEFORE the PR is reviewed or merged. Produces a Development QA section (must pass in a dev/preview environment before merge), a Production QA section (verified live after deploy), and a Definition of Done, each item tracing to an acceptance criterion (Given/When/Then or EARS) and naming the tool that exercises it. Also publishes a companion Claude artifact rendering the same plan (the PR body stays the machine source of truth the gates read). It PLANS QA, it does not execute it (/qa, qa:browser, qa:headless run Development QA; /canary runs Production QA). Ends by presenting the plan and a recommended QA driver for the human's approval, then writes the approval stamp the QA-plan gates read. Use for "qa plan", "write the qa plan", "plan the QA", "qa section for the PR", "dev and prod qa plan", "/qa:plan". (gstack-extensions) allowed-tools: - Bash - Read From 60ed52521498fc92ec75cfc9f6b009cf41715ec5 Mon Sep 17 00:00:00 2001 From: Mujtaba Badat <1470881+mujtaba3B@users.noreply.github.com> Date: Tue, 18 Aug 2026 13:42:20 +0200 Subject: [PATCH 2/2] fix(eng): correct two descriptions that misstated their own skill body Both were pre-existing inaccuracies carried over verbatim in the trim, caught by CodeRabbit on #67 and verified against the bodies before accepting: - eng:deploy claimed "asserts the tree is clean", but the body (line 75) explicitly treats untracked files as NOT a blocker and stops only on tracked modifications. Now says so. - eng:spike claimed a "yes/no verdict", but Phase 4 (line 150) permits PROVEN | DISPROVEN | INCONCLUSIVE, and the skill deliberately lands INCONCLUSIVE when context runs short. A binary framing would push toward a false verdict in exactly the case the skill designs for. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_015SMqMN8zAHtHgiZ596b8pC --- eng/skills/deploy/SKILL.md | 2 +- eng/skills/spike/SKILL.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/eng/skills/deploy/SKILL.md b/eng/skills/deploy/SKILL.md index 8078ecd..681ad4f 100644 --- a/eng/skills/deploy/SKILL.md +++ b/eng/skills/deploy/SKILL.md @@ -1,7 +1,7 @@ --- name: deploy description: >- - Deploy what is already on main, as a verified ceremony. Engineer Ernie's deploy-only counterpart to /land-and-deploy, for the PR-less cases that skill structurally cannot serve: retrying after a failed deploy, recovering a wedged host, and re-running with --rebuild-base / --rederive-all. Asserts the tree is clean, on main, and synced; refuses when the branch has an open unmerged PR (that is /land-and-deploy's job); shows the delta between what the host is running and what main holds; runs the repo's declared deploy command from deploy.json; and gates the result on `devops check`. It also arms the deploy gate, which is what makes it a sanctioned path rather than a hand-roll. Trigger on "/eng:deploy", "deploy", "deploy it", "deploy main", "redeploy", "deploy to the mini", "retry the deploy", "the deploy failed, run it again", "rebuild and deploy", "push this live". Use /land-and-deploy instead when there is an open PR to merge first. + Deploy what is already on main, as a verified ceremony. Engineer Ernie's deploy-only counterpart to /land-and-deploy, for the PR-less cases that skill structurally cannot serve: retrying after a failed deploy, recovering a wedged host, and re-running with --rebuild-base / --rederive-all. Asserts no tracked modifications, on main, and synced (untracked files are not a blocker); refuses when the branch has an open unmerged PR (that is /land-and-deploy's job); shows the delta between what the host is running and what main holds; runs the repo's declared deploy command from deploy.json; and gates the result on `devops check`. It also arms the deploy gate, which is what makes it a sanctioned path rather than a hand-roll. Trigger on "/eng:deploy", "deploy", "deploy it", "deploy main", "redeploy", "deploy to the mini", "retry the deploy", "the deploy failed, run it again", "rebuild and deploy", "push this live". Use /land-and-deploy instead when there is an open PR to merge first. --- ## Update check (run first) diff --git a/eng/skills/spike/SKILL.md b/eng/skills/spike/SKILL.md index 5b74523..cbafd4d 100644 --- a/eng/skills/spike/SKILL.md +++ b/eng/skills/spike/SKILL.md @@ -1,7 +1,7 @@ --- name: spike description: >- - Cheaply prove or disprove the riskiest unknown of a feature before committing to plan and build. Drives a four-phase loop: lock the one-line outcome, write the leanest throwaway code that could falsify it on a `spike/` branch, escalate via /second-opinion then the user when blocked, and land a yes/no verdict in SPIKE.md before context compacts. Trigger on "spike", "spike this", "spike a feature", "throwaway prove this works", "test the risky part first", "is this even possible", "can we even do X", "smallest thing that proves the mechanic", "/eng:spike". Proactively suggest it when the user is about to invoke /plan-eng-review or /autoplan on a feature with one clear unknown. NOT planning (/plan-eng-review), NOT ideation (/office-hours), NOT post-build QA (/qa), NOT change validation (/verify); spike code is exempt from karpathy-guidelines production discipline. + Cheaply prove or disprove the riskiest unknown of a feature before committing to plan and build. Drives a four-phase loop: lock the one-line outcome, write the leanest throwaway code that could falsify it on a `spike/` branch, escalate via /second-opinion then the user when blocked, and land a PROVEN, DISPROVEN, or INCONCLUSIVE verdict in SPIKE.md before context compacts. Trigger on "spike", "spike this", "spike a feature", "throwaway prove this works", "test the risky part first", "is this even possible", "can we even do X", "smallest thing that proves the mechanic", "/eng:spike". Proactively suggest it when the user is about to invoke /plan-eng-review or /autoplan on a feature with one clear unknown. NOT planning (/plan-eng-review), NOT ideation (/office-hours), NOT post-build QA (/qa), NOT change validation (/verify); spike code is exempt from karpathy-guidelines production discipline. --- ## Update check (run first)