forge-workflow 0.0.10 → 0.1.0-beta.2

package/scripts/test.js

@@ -23,15 +23,9 @@ const PACKAGE_LEVEL_PATHS = new Set([
 ]);
 
 const KNOWN_TARGETABLE_PREFIXES = [
-  '.claude/commands/',
   '.cursor/',
-  '.cline/',
-  '.roo/',
-  '.kilocode/',
-  '.opencode/',
-  '.codex/skills/',
+  '.codex/',
   '.forge/',
-  '.github/prompts/',
   '.github/agentic-workflows/',
   '.github/workflows/',
   'test/',
@@ -45,6 +39,65 @@ const ALWAYS_RUN_RISK_TEST_TARGETS = [
 
 const isWindows = process.platform === 'win32';
 
+// Wall-clock ceiling for a single spawned test lane. Bun's per-test `--timeout`
+// races a JS timer and CANNOT preempt a synchronous blocking spawn (e.g. an
+// `execFileSync` of git/bash that hangs during git mid-push state). Without this
+// ceiling such a hang blocks `forge push` indefinitely (observed ~50 min on
+// Windows, issue 8aef79e8). This kills the lane process so the push fails fast
+// instead of hanging forever.
+//
+// The default is a practical 5 minutes for a single TARGETED lane: those run a
+// small, mapped subset that completes in seconds, so 5 min is comfortably a
+// fail-fast ceiling (not the old 15-min wait that made `forge push` feel
+// wedged). Raise it with FORGE_TEST_TIMEOUT_MS for slow machines.
+const DEFAULT_TEST_COMMAND_TIMEOUT_MS = 5 * 60 * 1000;
+
+// Wall-clock budget for the FULL-SUITE fallback lane (`scripts/test-full-suite.js`),
+// which runs on package-level, unmapped, or zero-resolved changes. Unlike a
+// targeted lane, a healthy full suite legitimately takes 5-10 min, so the 5-min
+// fail-fast ceiling would kill a good-but-slow full run. Kept at 10 min to stay
+// aligned with the local-validation budget (VALIDATION_COMMAND_TIMEOUT_MS = 600000
+// in lib/commands/validate.js and its "long enough subprocess timeout for the
+// full local suite" regression test). FORGE_TEST_TIMEOUT_MS still overrides.
+const DEFAULT_FULL_SUITE_TIMEOUT_MS = 10 * 60 * 1000;
+
+// Conventional shell exit code for a command terminated by a timeout.
+const TIMEOUT_EXIT_CODE = 124;
+
+/**
+ * Reads and validates the FORGE_TEST_TIMEOUT_MS override, if any.
+ *
+ * @param {NodeJS.ProcessEnv} env Environment to read the override from.
+ * @returns {number|null} The positive integer override, or null when unset/invalid.
+ */
+function readTimeoutOverride(env) {
+  const parsed = Number.parseInt(env.FORGE_TEST_TIMEOUT_MS, 10);
+  return Number.isInteger(parsed) && parsed > 0 ? parsed : null;
+}
+
+/**
+ * Resolves the wall-clock timeout for a targeted/e2e/edge-case lane, honoring
+ * FORGE_TEST_TIMEOUT_MS.
+ *
+ * @param {NodeJS.ProcessEnv} [env=process.env] Environment to read the override from.
+ * @returns {number} Timeout in milliseconds (defaults to DEFAULT_TEST_COMMAND_TIMEOUT_MS).
+ */
+function resolveCommandTimeoutMs(env = process.env) {
+  return readTimeoutOverride(env) ?? DEFAULT_TEST_COMMAND_TIMEOUT_MS;
+}
+
+/**
+ * Resolves the wall-clock budget for the full-suite fallback lane. An explicit
+ * FORGE_TEST_TIMEOUT_MS override wins; otherwise it uses the larger,
+ * validation-aligned budget so a healthy-but-slow full run is not failed fast.
+ *
+ * @param {NodeJS.ProcessEnv} [env=process.env] Environment to read the override from.
+ * @returns {number} Timeout in milliseconds (defaults to DEFAULT_FULL_SUITE_TIMEOUT_MS).
+ */
+function resolveFullSuiteTimeoutMs(env = process.env) {
+  return readTimeoutOverride(env) ?? DEFAULT_FULL_SUITE_TIMEOUT_MS;
+}
+
 /**
  * @typedef {Object} TestExecutionPlan
  * @property {string[]} changedFiles
@@ -101,7 +154,19 @@ function isKnownTargetablePath(file) {
     return true;
   }
 
-  if (file.startsWith('docs/plans/')) {
+  if (file === 'README.md'
+    || file === 'bin/forge.js'
+    || file === 'QUICKSTART.md'
+    || file === 'CHANGELOG.md'
+    || file === 'AGENTS.md'
+    || file === 'DEVELOPMENT.md'
+    || file === 'docs/INDEX.md'
+    || file === 'docs/PROJECT_DESIGN.md'
+    || file.startsWith('docs/forge/')
+    || file.startsWith('docs/guides/')
+    || file.startsWith('docs/plans/')
+    || file.startsWith('docs/reference/')
+    || file.startsWith('docs/work/')) {
     return true;
   }
 
@@ -257,6 +322,15 @@ function runCommand(command, args, options = {}, spawnSync = defaultSpawnSync) {
   });
 
   if (result.error) {
+    if (result.error.code === 'ETIMEDOUT') {
+      console.error('');
+      console.error('Test lane exceeded its wall-clock ceiling and was terminated.');
+      console.error('A single test likely hung (e.g. a spawned git/bash call that never returns).');
+      console.error('Adjust the ceiling with FORGE_TEST_TIMEOUT_MS. Failing the run instead of');
+      console.error('blocking the push. See issue 8aef79e8.');
+      console.error('');
+      return TIMEOUT_EXIT_CODE;
+    }
     throw result.error;
   }
 
@@ -276,30 +350,35 @@ function runTestExecutionPlan(plan, deps = {}) {
   const env = deps.env || stripGitHookEnv(process.env);
   const bunCommand = deps.bunCommand || env.BUN_EXE || process.env.BUN_EXE || 'bun';
   const label = deps.label || 'tests';
+  const timeout = resolveCommandTimeoutMs(env);
+  const laneOptions = { env, killSignal: 'SIGKILL', timeout };
+  // The full-suite fallback gets a larger, validation-aligned budget so a
+  // healthy-but-slow full run is not failed fast by the targeted-lane ceiling.
+  const fullSuiteOptions = { env, killSignal: 'SIGKILL', timeout: resolveFullSuiteTimeoutMs(env) };
 
   console.log(`Running ${label} (${pkgManager})...`);
 
   try {
     if (plan.runFullSuite) {
       console.log(`  Mode: full suite (${plan.reason})`);
-      const status = runCommand('node', ['scripts/test-full-suite.js'], { env }, spawnSync);
+      const status = runCommand('node', ['scripts/test-full-suite.js'], fullSuiteOptions, spawnSync);
       if (status !== 0) return status;
     } else if (plan.testTargets.length > 0) {
       console.log(`  Mode: targeted (${plan.testTargets.length} test file${plan.testTargets.length === 1 ? '' : 's'})`);
       const command = pkgManager === 'bun' ? bunCommand : pkgManager;
-      const status = runCommand(command, ['run', 'test', ...plan.testTargets], { env }, spawnSync);
+      const status = runCommand(command, ['run', 'test', ...plan.testTargets], laneOptions, spawnSync);
       if (status !== 0) return status;
     }
 
     if (plan.runE2E) {
       console.log('  Extra: running affected e2e tests');
-      const status = runCommand(bunCommand, ['test', 'test/e2e/'], { env }, spawnSync);
+      const status = runCommand(bunCommand, ['test', '--timeout', '15000', 'test/e2e/'], laneOptions, spawnSync);
       if (status !== 0) return status;
     }
 
     if (!plan.runFullSuite && plan.runTestEnv) {
       console.log('  Extra: running affected edge-case tests');
-      const status = runCommand(bunCommand, ['test', 'test-env/'], { env }, spawnSync);
+      const status = runCommand(bunCommand, ['test', '--timeout', '15000', 'test-env/'], laneOptions, spawnSync);
       if (status !== 0) return status;
     }
 
@@ -348,9 +427,13 @@ if (require.main === module) {
 
 module.exports = {
   ALWAYS_RUN_RISK_TEST_TARGETS,
+  DEFAULT_FULL_SUITE_TIMEOUT_MS,
+  DEFAULT_TEST_COMMAND_TIMEOUT_MS,
   buildTestExecutionPlan,
   classifyPushTests,
   detectPackageManager,
+  resolveCommandTimeoutMs,
+  resolveFullSuiteTimeoutMs,
   runLocalValidationTests,
   runPrePushTests,
   runTestExecutionPlan,

package/skills/claim-safety/SKILL.md

@@ -0,0 +1,102 @@
+---
+name: claim-safety
+description: >
+  Claim a Forge issue and then PROVE you hold the live lease before you touch it, using `forge
+  issue owns <id>` (exit 0 iff you hold the single unexpired lease). Use this whenever winning
+  the claim matters: right after `forge claim`, before you `dev`/edit/`close`/`release` a
+  claimed issue, when two agents or a subagent fan-out contend for the same work, or before
+  any irreversible step. A claim's `ok:true` does NOT prove you won — duplicate replays return
+  it and expired leases get reclaimed; only `owns` proves it, so re-verify before
+  close/release. Trigger on "claim this issue safely", "did I actually win the lease",
+  "verify/prove ownership", "claim conflict", "two agents grabbed the same issue", "check I
+  still own it before closing", or before ANY mutation of a claimed issue. NOT for plain
+  single-issue create/update/close/comment with no ownership question (that is issue-basics),
+  and NOT for read-only selecting or ranking the next ready issue without claiming (that is
+  triage-ready).
+allowed-tools: Read, Bash(forge:*)
+---
+
+# Claim safety — claim, then prove you own the lease
+
+Claiming is not owning. The Forge kernel keys a claim's idempotency on
+`claim.create:<issue_id>:<actor>`, so a **same-key duplicate replay returns
+`ok:true`** echoing the *current* call's `claim_id`. A genuine cross-actor
+conflict returns `ok:false` (the partial-UNIQUE active-lease index guarantees one
+lease) — but `ok:true` **alone does not prove sole ownership**. A live lease can
+also be **reclaimed on expiry** (an expired lease is superseded by the next
+claimant). Therefore every worker MUST verify ownership before mutating a claimed
+issue, and RE-verify before `close`/`release`.
+
+This is a reusable, standalone procedure: any skill or agent that mutates a
+claimed issue embeds it (it is NOT folded into one orchestrator).
+
+## The verification primitive
+
+```bash
+forge issue owns <id>          # exit 0 iff YOU hold the live lease; non-zero otherwise
+forge issue owns <id> --json   # { ok:true, data:{ owned, claimed_by, expired, actor, expires_at } }
+```
+
+`owns` resolves your actor the same way the kernel does — `FORGE_ACTOR` →
+`FORGE_SESSION_ID` → default `forge` — then reports `owned:true` iff you hold the
+**single active claim** AND that lease **has not expired**. It exits `0` when you
+own it and non-zero (conflict, code 4) when you do not, with a clear "you do not
+own the lease for `<id>` (held by `<actor>`)" message. It is a strict READ — it
+never mutates kernel state. (`data.claimed_by` is lease-derived; there is no
+`claims` command.)
+
+## Procedure
+
+1. **Select** work — `forge issue ready --json` (see the `triage-ready` skill).
+   Never claim epics/decisions or defer-windowed items.
+2. **Claim** — `FORGE_ACTOR=<your-actor> forge claim <id>`. Always run under a
+   distinct actor so a losing claim reaches the conflict guard instead of
+   collapsing to a shared-actor duplicate.
+3. **Prove ownership BEFORE working** — `forge issue owns <id>`.
+   - **exit 0 (OWNED)** → the lease is yours; proceed to work.
+   - **non-zero (NOT OWNED)** → you lost the race, or your claim collapsed to a
+     foreign/duplicate-collapsed claim. Do NOT work the issue. **Reselect** via
+     `forge issue ready --json` and start over at step 1.
+4. **Work** the issue (`dev`/edit/etc.).
+5. **RE-verify before `close`/`release`** — a live lease can be reclaimed on
+   expiry while you worked. Run `forge issue owns <id>` again:
+   - **OWNED** → `forge release check --target <release-ref> --json` (release-readiness; omit `--target` to use the project default), then
+     `forge close <id> --reason "…"` or `forge release <id>`.
+   - **NOT OWNED** → the lease was reclaimed (likely expired). Do NOT close/
+     release someone else's lease; reselect and, if the work is still needed,
+     re-claim and reconcile.
+
+## Contract (what each result means)
+
+| `forge claim` result | Meaning | Action |
+|----------------------|---------|--------|
+| `ok:false` (conflict, code 4) | A live lease is held by another actor | Reselect (`ready`) |
+| `ok:true` | Provisionally yours — **not proof** (duplicate replays also return ok:true) | **Run `forge issue owns <id>`** |
+
+| `forge issue owns` | Meaning | Action |
+|--------------------|---------|--------|
+| exit 0, `owned:true` | You hold the live, unexpired lease | Work / close / release |
+| non-zero, `owned:false` | Someone else holds it, or your lease expired | Reselect; never mutate |
+
+## Fork points
+
+- **Actor source** — how `<your-actor>` is derived (`FORGE_ACTOR` explicit id →
+  `FORGE_SESSION_ID` → default `forge`). Use a distinct per-agent actor so
+  contending claims reach the conflict guard rather than collapsing to a duplicate.
+- **Expiry / lease TTL** — whether claims carry an `expires_at` and how long;
+  `owns` treats an expired lease as NOT owned (it can be reclaimed).
+- **Re-verify cadence** — verify after claim and again before `close`/`release`;
+  a longer task may re-verify more often (e.g. before each irreversible step).
+- **Reselection policy** — on NOT-OWNED, how the next item is chosen (ranking /
+  filters live in the `triage-ready` skill).
+- **Fail-closed posture** — with no usable clock/state, treat ownership as NOT
+  proven (mirror the readiness model's "no usable clock ⇒ not workable").
+
+## Reliability notes
+
+- A genuine cross-actor conflict returns `ok:false` — there is no phantom
+  `ok:true`-on-conflict. The real hazards are (a) a duplicate replay's `ok:true`
+  and (b) expiry-driven reclaim. `owns` closes both.
+- Full multi-agent safety depends on the actor-identity kernel fix (distinct
+  actors per agent, kernel `d71a824b`): without distinct actors, two agents
+  share one idempotency key and `owns` cannot tell them apart.

package/skills/claim-safety/evals/evals.json

@@ -0,0 +1,46 @@
+[
+  {
+    "query": "I just ran forge claim on forge-abc — how do I make sure the lease is really mine before I start editing?",
+    "should_trigger": true
+  },
+  {
+    "query": "Two of my agents may have grabbed the same issue at once — how do I tell which one actually holds it?",
+    "should_trigger": true
+  },
+  {
+    "query": "Before I close this ticket, confirm nobody reclaimed it while I was working.",
+    "should_trigger": true
+  },
+  {
+    "query": "My claim came back ok:true but I'm not convinced I won the race. Can I trust that?",
+    "should_trigger": true
+  },
+  {
+    "query": "Prove I own forge-42 before the subagent starts mutating it.",
+    "should_trigger": true
+  },
+  {
+    "query": "The lease might have expired mid-task — check I still own it before I release.",
+    "should_trigger": true
+  },
+  {
+    "query": "What's the next ready issue I should pick up?",
+    "should_trigger": false
+  },
+  {
+    "query": "Create a feature issue titled 'Add CSV export'.",
+    "should_trigger": false
+  },
+  {
+    "query": "Close forge-19 with reason 'shipped in PR 88'.",
+    "should_trigger": false
+  },
+  {
+    "query": "Take forge-30 all the way through to a PR.",
+    "should_trigger": false
+  },
+  {
+    "query": "Implement the failing auth tests for this task.",
+    "should_trigger": false
+  }
+]

package/{.github/prompts/dev.prompt.md → skills/dev/SKILL.md}

@@ -1,14 +1,25 @@
 ---
 name: dev
-description: Subagent-driven TDD implementation per task from /plan task list
-tools: []
+description: >
+  Forge DEV stage — implement an already-planned /plan task list into committed, test-backed
+  code. Reads tasks.md + plan.md, then drives each task through a subagent TDD loop
+  (implementer → spec-compliance reviewer → code-quality reviewer) with RED-GREEN-REFACTOR,
+  HARD-GATE evidence checks, and a spec-gap decision score. Use when a plan and task list
+  already exist and it is time to implement — triggers: "/dev", "start the dev stage", "build
+  the tasks", "implement tasks.md test-first", "run the implementer/reviewer TDD loop", "write
+  the code for the planned tasks one by one", "work through the task list with subagents".
+  Per-task coding ONLY. Do NOT use for creating the design doc or task list (that is plan),
+  for the post-build type-check/lint/security/test gate (validate), for pushing the branch or
+  opening the PR (ship), for addressing PR review feedback (review), or for orchestrating
+  several stages / taking an issue end-to-end to a merged PR (smith).
+allowed-tools: Bash, Read, Write, Edit, Grep, Glob
 ---
 
 Implement each task from the /plan task list using a subagent-driven loop: implementer → spec compliance reviewer → code quality reviewer per task.
 
 # Dev
 
-This command reads the task list created by `/plan` and implements each task using a three-stage subagent loop. TDD is enforced inside each implementer subagent.
+This skill reads the task list created by `/plan` and implements each task using a three-stage subagent loop. TDD is enforced inside each implementer subagent.
 
 ## Usage
 
@@ -24,19 +35,19 @@ This command reads the task list created by `/plan` and implements each task usi
 
 ```bash
 # Find task list and design doc
-ls docs/plans/
+ls docs/work/
 ```
 
 Read:
-- **Task list**: `docs/plans/YYYY-MM-DD-<slug>-tasks.md` — extract ALL task text upfront
-- **Design doc**: `docs/plans/YYYY-MM-DD-<slug>-design.md` — including ambiguity policy section
+- **Task list**: `docs/work/YYYY-MM-DD-<slug>/tasks.md` — extract ALL task text upfront
+- **Design doc**: `docs/work/YYYY-MM-DD-<slug>/plan.md` — including ambiguity policy section
 
 ### Step 2: Create decisions log
 
 Create an empty decisions log at the start of every /dev session:
 
 ```bash
-# docs/plans/YYYY-MM-DD-<slug>-decisions.md
+# docs/work/YYYY-MM-DD-<slug>/decisions.md
 ```
 
 Format for each entry:
@@ -74,8 +85,8 @@ Before starting the per-task loop, check for cross-developer conflicts:
 # Auto-sync to get latest team state (non-blocking)
 forge sync || true
 
-# Check for conflicts with the current beads issue
-bash scripts/conflict-detect.sh --issue <beads-id>
+# Check for conflicts with the current Forge issue
+bash scripts/conflict-detect.sh --issue <forge-id>
 ```
 
 If exit code 2 (validation error): show error message, abort — do not show conflict prompt.
@@ -84,7 +95,7 @@ If exit code 1 (conflicts found):
 - Display the conflict output to the developer
 - Ask: "Other developers are working in overlapping areas. Proceed anyway? (y/n)"
 - If `n`: exit cleanly, no side effects
-- If `y`: log override via `bd comments add <id> "Conflict override: proceeding despite overlap with <conflicting-issues>"`, then continue to Per-Task Loop
+- If `y`: log override via `forge comment <id> "Conflict override: proceeding despite overlap with <conflicting-issues>"`, then continue to Per-Task Loop
 - Audit: record conflict override per OWASP A09
 
 If exit code 0: proceed silently to Per-Task Loop.
@@ -194,7 +205,7 @@ Reviewer checks:
 - Structure: functions not too long, proper separation of concerns
 - Duplication: no copy-paste that could be extracted
 - Test coverage: tests cover happy path and at least one error path
-- No magic numbers, no commented-out code, no TODO without a Beads issue
+- No magic numbers, no commented-out code, no TODO without a Forge issue
 
 If quality issues found: implementer fixes → re-review → repeat until ✅
 
@@ -213,7 +224,7 @@ Do NOT mark task complete or move to next task until ALL confirmed in this sessi
 4. Run it fresh — show the actual output. "Last run was fine" is not evidence.
 5. Tests run fresh — actual output shows passing.
 6. Implementer has committed (git log shows the commit).
-7. `bash scripts/beads-context.sh update-progress <id> <task-num> <total> "<title>" <commit-sha> <test-count> <gate-count>` ran successfully (exit code 0). If it fails: STOP. Show error. Do not proceed to next task.
+7. Progress recorded on the Forge issue — `forge comment <id> "task <task-num>/<total> done: <title> (<commit-sha>, <test-count> tests, <gate-count> gates)"` ran successfully (exit code 0). The Forge comment is the kernel-native record. If the recording command errors: STOP, show the error, do not proceed to the next task.
 
 Forbidden phrases (these are not evidence):
 - "should pass"
@@ -274,15 +285,18 @@ Do NOT declare /dev complete until:
 </HARD-GATE>
 ```
 
-### Beads update
+### Record stage transition
 
 ```bash
-bash scripts/beads-context.sh validate <id>
-bash scripts/beads-context.sh stage-transition <id> dev validate \
-  --summary "<N tasks done, M decision gates fired>" \
-  --decisions "<key spec gaps and how they were resolved>" \
-  --artifacts "<changed source files and test files>" \
-  --next "<validation priorities — lint issues, type concerns>"
+# Confirm the issue carries design + acceptance context.
+forge issue show <id>
+
+# Record the dev→validate transition kernel-natively (Stage:/Summary:/Decisions:/Artifacts:/Next: envelope).
+forge comment <id> "Stage: dev complete → ready for validate
+Summary: <N tasks done, M decision gates fired>
+Decisions: <key spec gaps and how they were resolved>
+Artifacts: <changed source files and test files>
+Next: <validation priorities — lint issues, type concerns>"
 ```
 
 ---
@@ -299,43 +313,23 @@ Document the gate count in the final commit message.
 
 ---
 
-## Example Output (all tasks complete)
+## Dynamic Output
 
-```
-✓ Task 1: Types and interfaces — COMPLETE
-  Spec: ✅  Quality: ✅  Tests: 4/4 passing  Commit: abc1234
-  Decision gates: 0
-
-✓ Task 2: Validation logic — COMPLETE
-  Spec: ✅  Quality: ✅  Tests: 8/8 passing  Commit: def5678
-  Decision gates: 1 (PROCEED, score 2 — documented in decisions log)
-
-✓ Task 3: API endpoint — COMPLETE
-  Spec: ✅  Quality: ✅  Tests: 6/6 passing  Commit: ghi9012
-  Decision gates: 0
-
-✓ Final code review: ✅ (coherent, consistent, correctly integrated)
+The completion summary is generated from the live task list, decisions log, Forge issue state, commits, and validation output at runtime. Do not copy a static example into this skill file; run `/dev` to view the current task/status summary.
 
-✓ Decisions log: docs/plans/2026-02-26-stripe-billing-decisions.md
-  - Decision 1: RESOLVED (score 2, proceeded with conservative choice)
-  - Decision gates fired: 1 (plan quality: Good)
-
-✓ Beads updated: forge-xyz → implementation complete
+## Integration with Workflow
 
-Ready for /validate
 ```
+Utility: /status  -> Understand current context before starting
 
-## Integration with Workflow
+Default template:
+  /dev       -> Implement each task with subagent-driven TDD (you are here)
+  /validate  -> Type check, lint, tests, security
+  /ship      -> Push + create PR
+  /review    -> Address PR feedback
+  /verify    -> Post-merge health check
 
-```
-Utility: /status     → Understand current context before starting
-Stage 1: /plan       → Design intent → research → branch + worktree + task list
-Stage 2: /dev        → Implement each task with subagent-driven TDD (you are here)
-Stage 3: /validate      → Type check, lint, tests, security — all fresh output
-Stage 4: /ship       → Push + create PR
-Stage 5: /review     → Address GitHub Actions, Greptile, SonarCloud
-Stage 6: /premerge   → Update docs, hand off PR to user
-Stage 7: /verify     → Post-merge CI check on main
+Pre-merge gate: doc updates + CI-green checkpoint embedded in /ship and /review (not a separate stage).
 ```
 
 ## Tips

package/skills/dev/evals/evals.json

@@ -0,0 +1,50 @@
+[
+  {
+    "query": "/dev",
+    "should_trigger": true
+  },
+  {
+    "query": "The plan and task list are done — start implementing the tasks one at a time, tests first.",
+    "should_trigger": true
+  },
+  {
+    "query": "Run the implementer then the spec and quality reviewer subagents over each task in tasks.md",
+    "should_trigger": true
+  },
+  {
+    "query": "Implement the already-planned tasks one at a time, red-green-refactor each",
+    "should_trigger": true
+  },
+  {
+    "query": "Time to write the code for the planned tasks and TDD each one in this worktree",
+    "should_trigger": true
+  },
+  {
+    "query": "Work through tasks.md subagent by subagent until every task is committed and reviewed",
+    "should_trigger": true
+  },
+  {
+    "query": "Set up the branch, worktree, and TDD task list for this new feature",
+    "should_trigger": false
+  },
+  {
+    "query": "Type-check, lint, and run the full test suite before I open the PR",
+    "should_trigger": false
+  },
+  {
+    "query": "Push the validated branch and open the pull request",
+    "should_trigger": false
+  },
+  {
+    "query": "The PR has open review threads from the bots — fix each finding, reply, and mark them resolved.",
+    "should_trigger": false
+  },
+  {
+    "query": "Grab the next ready issue and drive it all the way to a merged PR",
+    "should_trigger": false
+  },
+  {
+    "query": "Which workflow stage am I on and what work is in flight right now?",
+    "should_trigger": false
+  }
+]