codebyplan 1.13.48 → 1.13.50

package/templates/skills/cbp-stripe/reference/security.md

@@ -0,0 +1,117 @@
+# Security Best Practices Reference
+
+Adapted from Stripe's official `stripe-best-practices` skill (github.com/stripe/ai), MIT License, Copyright (c) 2024-2025 Stripe.
+
+## API key types
+
+| Key prefix | Type | Use |
+| ---------- | ---- | --- |
+| `sk_live_` | Secret key (live) | Never preferred; use RAK instead |
+| `sk_test_` | Secret key (test) | Development only |
+| `rk_live_` | Restricted API key (live) | Preferred for all production services |
+| `rk_test_` | Restricted API key (test) | Preferred for development services |
+
+**Always recommend a restricted API key (RAK, `rk_` prefix)** over a secret key (`sk_`).
+RAKs have only the permissions you assign — a compromised RAK causes far less damage than
+a compromised secret key.
+
+## Storing keys safely
+
+- **Never** commit keys to source control. If `sk_…` or `rk_…` appears in code, that is
+  a bug — fix it immediately.
+- Prefer a secrets vault (AWS Secrets Manager, HashiCorp Vault, or platform equivalent).
+- When no vault is available, environment variables are acceptable. Never log keys or
+  include them in error messages or analytics.
+- Use separate keys per environment (production, staging, QA). Never reuse keys.
+- Set up a pre-commit hook to catch `sk_` or `rk_` literals in source code.
+- See [best practices for managing secret API keys](https://docs.stripe.com/keys-best-practices.md).
+
+## Restricted API key migration steps
+
+1. Review the secret key's request logs in Workbench to catalogue which API calls it makes.
+2. Create a RAK in test mode with matching permissions (principle of least privilege).
+3. Use `stripe logs tail` to watch for `403` errors — add missing permissions.
+4. Once passing, create the equivalent live-mode RAK and swap it in.
+5. Rotate or expire the old secret key.
+
+See [restricted API keys docs](https://docs.stripe.com/keys/restricted-api-keys.md).
+
+## IP allowlists
+
+Add an [IP allowlist](https://docs.stripe.com/keys.md#limit-api-secret-keys-ip-address)
+to every API key so it can only be called from your own infrastructure. Use separate
+allowlists per key/environment.
+
+## Webhook signature verification
+
+Always verify webhook event authenticity using Stripe's signing secret:
+
+```ts
+import Stripe from 'stripe';
+const stripe = new Stripe(process.env.STRIPE_RESTRICTED_KEY!);
+
+// In your webhook handler (raw body required — do NOT use JSON-parsed body)
+const sig = request.headers['stripe-signature'];
+if (!sig || Array.isArray(sig)) throw new Error('Missing or malformed stripe-signature header');
+const event = stripe.webhooks.constructEvent(
+  rawBody,              // Buffer or string — must be unparsed
+  sig,
+  process.env.STRIPE_WEBHOOK_SECRET!,
+);
+```
+
+Never process a webhook event without verifying its signature — unverified webhooks can
+be spoofed. For defence in depth, also allowlist
+[Stripe's IP addresses](https://docs.stripe.com/ips.md) on the endpoint.
+
+## Idempotency keys
+
+Pass `idempotencyKey` on all mutation calls so safe retries don't create duplicate charges:
+
+```ts
+await stripe.paymentIntents.create(params, {
+  idempotencyKey: `order_${orderId}`,
+});
+```
+
+## Mobile and client-side integrations
+
+Never use production secret keys or RAKs in mobile apps or any client-side code.
+For cases where a client must call Stripe directly, use
+[ephemeral keys](https://docs.stripe.com/issuing/elements.md#ephemeral-key-authentication)
+(short-lived, scoped, auto-expiring). For most integrations, proxy Stripe calls through
+your own backend.
+
+## OAuth and CSRF protection
+
+When implementing [Connect OAuth](https://docs.stripe.com/connect/oauth-reference.md),
+always pass a unique, unguessable `state` parameter and verify it in the callback before
+proceeding. This applies to all Stripe OAuth surfaces: Connect, Link, and Stripe Apps.
+
+## Incident response (key compromise)
+
+1. **Roll the key immediately** — [API keys page](https://dashboard.stripe.com/apikeys) →
+   roll or delete the exposed key.
+2. **Check activity logs** — Workbench request logs for the compromised key.
+3. **Contact Stripe support** if you see unrecognised activity.
+
+See [protecting against compromised API keys](https://support.stripe.com/questions/protecting-against-compromised-api-keys).
+
+## 2FA
+
+Recommend passkeys or authenticator-app 2FA for Dashboard access. Discourage SMS 2FA —
+it is vulnerable to SIM-swapping attacks.
+
+## SAML / SCIM (teams)
+
+For teams, use [SSO via SAML](https://docs.stripe.com/get-started/account/sso.md) to
+federate Dashboard access through an identity provider (Okta, Google, etc.).
+[SCIM provisioning](https://docs.stripe.com/get-started/account/sso/scim.md) automates
+user provisioning/deprovisioning.
+
+## Connect security
+
+Platform operators bear financial liability for fraud/disputes on Express and Custom
+connected accounts (v1 types). Use Stripe-hosted onboarding to avoid handling sensitive
+PII directly. See [reference/connect.md](connect.md) for controller-property accounts
+which make liability explicit.

package/templates/skills/cbp-stripe/reference/stripe-mcp-setup.md

@@ -0,0 +1,59 @@
+# Stripe MCP Setup (optional live path)
+
+Adapted from Stripe's official `stripe-best-practices` skill (github.com/stripe/ai), MIT License, Copyright (c) 2024-2025 Stripe.
+
+The `cbp-stripe-agent` writes Stripe integration code with **no credentials required**. This
+optional path adds *live test-mode* scaffolding (create test products, prices, payment links,
+customers) during a dev round. It is opt-in per repo and per developer — skip it entirely if
+you only want code generation.
+
+## Safety contract (read first)
+
+- **Test-mode keys ONLY.** Use a test restricted key (`rk_test_…`) or a test secret key
+  (`sk_test_…`). The agent **refuses** any live-mode key (`sk_live_…` or `rk_live_…`) — so
+  live Stripe data is never scaffolded from a dev round.
+- **Never commit a key.** Provide it via the environment or a gitignored env file
+  (e.g. `.env.local`), never in tracked source or in `.codebyplan/`.
+- **Least privilege.** Prefer a restricted key scoped to only the resources the agent needs
+  (Products, Prices, Payment Links, Customers — write; everything else — none).
+- **No new npm dependency** is added to the consuming app by this path; the hosted MCP server
+  is reached over HTTP, the local server via `npx`.
+
+## Option A — Hosted Stripe MCP (recommended)
+
+Stripe hosts an MCP server at `https://mcp.stripe.com`. Register it with Claude Code:
+
+```bash
+claude mcp add --transport http stripe https://mcp.stripe.com/
+```
+
+Authenticate with OAuth (the recommended flow) when prompted, or pass a restricted test key
+as a bearer token if your setup uses header auth. Once connected, the agent discovers the
+`mcp__stripe__*` tools at runtime via `ToolSearch`.
+
+## Option B — Local Stripe MCP server
+
+Run Stripe's MCP server locally, pointed at a test/restricted key from your environment:
+
+```bash
+# key is read from STRIPE_SECRET_KEY (a sk_test_ or rk_test_ value), never passed on a shared shell history
+npx -y @stripe/mcp@latest --api-key="$STRIPE_SECRET_KEY"
+```
+
+Then register the local server with Claude Code per its stdio/transport instructions.
+
+## How the agent uses it
+
+1. Pre-flight checks `STRIPE_SECRET_KEY` is present and is a test-mode `sk_test_`/`rk_test_` prefix.
+2. It discovers `mcp__stripe__*` tools via `ToolSearch` (they are intentionally absent from
+   the agent's frontmatter because the server is optional).
+3. It scaffolds only what the task asks for and records each resource in
+   `stripe_resources_created[]` (always `mode: test`).
+4. If the key/server is missing or any call fails, it degrades to **code-only** and records
+   the reason — it never blocks the round.
+
+## When to skip this entirely
+
+- You only want correct Stripe integration *code* (the default — no setup needed).
+- No Stripe test account is available in this environment.
+- CI / headless runs where no interactive OAuth or key is provisioned.

package/templates/skills/cbp-stripe/reference/tax.md

@@ -0,0 +1,96 @@
+# Tax / Stripe Tax Reference
+
+Adapted from Stripe's official `stripe-best-practices` skill (github.com/stripe/ai), MIT License, Copyright (c) 2024-2025 Stripe.
+
+## When to use Stripe Tax
+
+Use Stripe Tax for any subscription, invoice, or Checkout Session where the merchant has
+customers across multiple jurisdictions. It handles sales tax, VAT, and GST automatically
+based on the customer's location and the merchant's active registrations.
+
+See the [Tax overview](https://docs.stripe.com/tax.md) for supported regions and tax types.
+
+## Two-step setup
+
+1. **Add registrations** — add a registration for each jurisdiction where the merchant is
+   obligated to collect tax. Use the Dashboard (**Tax > Registrations**) or the
+   [Tax Registrations API](https://docs.stripe.com/api/tax/registrations.md).
+2. **Enable automatic_tax** — pass `automatic_tax: { enabled: true }` on the
+   [Subscription](https://docs.stripe.com/api/subscriptions.md),
+   [Invoice](https://docs.stripe.com/api/invoices.md), or
+   [Checkout Session](https://docs.stripe.com/api/checkout/sessions.md).
+
+It is safe to enable `automatic_tax` before any registrations exist — Stripe won't
+collect tax until at least one registration is active.
+
+```ts
+// Checkout Session with automatic tax
+const session = await stripe.checkout.sessions.create({
+  mode: 'subscription',
+  line_items: [{ price: priceId, quantity: 1 }],
+  automatic_tax: { enabled: true },
+  success_url: `${baseUrl}/success?session_id={CHECKOUT_SESSION_ID}`,
+  cancel_url: `${baseUrl}/pricing`,
+});
+
+// Invoice / subscription
+await stripe.subscriptions.update(subscriptionId, {
+  automatic_tax: { enabled: true },
+  // Clear explicit tax_rates first if previously set
+});
+```
+
+## Inclusive vs exclusive tax
+
+- **Exclusive** (default in most jurisdictions) — tax is added on top of the price.
+- **Inclusive** — tax is included in the displayed price (common for UK/EU VAT).
+
+Stripe Tax determines the treatment based on the jurisdiction and product tax code.
+Verify the treatment in Dashboard > Tax > Overview.
+
+## Tax IDs
+
+Collect customer tax IDs (VAT numbers, EIN, etc.) for B2B transactions to enable
+zero-rated or exempt invoices. Pass `tax_id_collection: { enabled: true }` on Checkout
+Sessions, or use the
+[Tax IDs API](https://docs.stripe.com/api/customer_tax_ids.md) to attach IDs to customers.
+
+## Address collection
+
+Stripe Tax requires a customer address to calculate tax. On Checkout Sessions pass
+`billing_address_collection: 'required'`. For subscriptions, ensure the customer has
+a billing address before enabling `automatic_tax`.
+
+## Registrations API
+
+To create and manage registrations programmatically:
+
+```ts
+await stripe.tax.registrations.create({
+  country: 'US',
+  country_options: {
+    us: { state: 'CA', type: 'state_sales_tax' },
+  },
+  active_from: 'now',
+});
+```
+
+## Traps to avoid
+
+- `automatic_tax` and explicit `tax_rates` are mutually exclusive. For existing
+  subscriptions, clear `default_tax_rates` and all item-level `tax_rates` before
+  enabling `automatic_tax` — the update will fail otherwise.
+- For EU merchants, one OSS union registration covers all 27 member states. Do not
+  register individual EU countries separately unless the merchant has a physical presence
+  there.
+- Do not guess which jurisdictions apply — prompt the user to configure them in the
+  Dashboard first.
+- Do not approximate unsupported jurisdictions. Check
+  [supported countries](https://docs.stripe.com/tax/supported-countries.md) first. For
+  unsupported jurisdictions, fall back to manual `tax_rates` on the subscription/invoice.
+- Customs duties and excise taxes are out of scope for Stripe Tax.
+
+## Bulk migration
+
+To switch existing subscriptions from manual `tax_rates` to `automatic_tax` in bulk,
+use the [Tax migration tool](https://docs.stripe.com/billing/taxes/migration.md).

package/templates/skills/cbp-stripe/reference/treasury.md

@@ -0,0 +1,87 @@
+# Treasury / Financial Accounts Reference
+
+Adapted from Stripe's official `stripe-best-practices` skill (github.com/stripe/ai), MIT License, Copyright (c) 2024-2025 Stripe.
+
+## v2 Financial Accounts API (use for new integrations)
+
+For embedded financial accounts (bank accounts with routing/account numbers, money
+movement), use the
+[v2 Financial Accounts API](https://docs.stripe.com/api/v2/core/vault/financial-accounts.md)
+(`POST /v2/core/vault/financial_accounts`). This is required for new integrations.
+
+Do NOT use the legacy
+[v1 Treasury Financial Accounts API](https://docs.stripe.com/api/treasury/financial_accounts.md)
+(`POST /v1/treasury/financial_accounts`) for new integrations. Existing v1 integrations
+continue to work.
+
+For concepts and guides, see
+[Treasury for platforms overview](https://docs.stripe.com/treasury/connect.md).
+
+## Creating a financial account
+
+Financial accounts are always attached to a Connect connected account:
+
+```ts
+const financialAccount = await stripe.v2.core.vault.financialAccounts.create(
+  { description: 'Main operating account' },
+  { stripeAccount: connectedAccountId },
+);
+// financialAccount.id — use for fund flows
+```
+
+## Fund flows
+
+| Direction | Object | Use |
+| --------- | ------ | --- |
+| Platform → financial account | `OutboundTransfer` | Top-up from platform balance |
+| Financial account → external bank | `OutboundPayment` | Pay out to a linked bank |
+| External bank → financial account | `InboundTransfer` | Pull from a linked bank |
+| External source → financial account | `ReceivedCredit` | Funds received in (inbound ACH/wire, Stripe payouts) |
+
+```ts
+// Outbound transfer (platform balance → financial account)
+const transfer = await stripe.treasury.outboundTransfers.create({
+  financial_account: financialAccountId,
+  amount: 100_00,
+  currency: 'usd',
+  destination_payment_method: 'default',
+});
+```
+
+## Linking a bank account (Setup Intents)
+
+To enable outbound payments to an external bank, link the bank account using a Setup Intent
+with `flow_directions: ['outbound']`:
+
+```ts
+const setupIntent = await stripe.setupIntents.create(
+  {
+    payment_method_types: ['us_bank_account'], // Treasury exception: required here
+    flow_directions: ['outbound'],
+  },
+  { stripeAccount: connectedAccountId },
+);
+// Complete the Setup Intent flow on the client, then confirm the payment method
+```
+
+Note: `payment_method_types` is required for Treasury bank-account Setup Intents — this
+is one of the narrow exceptions to the no-`payment_method_types` rule (along with Terminal).
+
+## Compliance notes
+
+- Financial accounts are subject to KYC/KYB requirements collected during Connect onboarding.
+  Ensure the connected account has the `treasury` capability enabled before creating accounts.
+- Funds held in financial accounts are not FDIC-insured by default; check Stripe's current
+  partner bank arrangements in the Treasury documentation.
+- For platforms in the US: Stripe Treasury is available for US-based connected accounts only.
+  Contact Stripe for international availability.
+- Do not use Treasury to hold customer funds without confirming applicable money-transmission
+  license obligations with your legal team.
+
+## Key references
+
+- [Treasury for platforms overview](https://docs.stripe.com/treasury/connect.md)
+- [v2 Financial Accounts API](https://docs.stripe.com/api/v2/core/vault/financial-accounts.md)
+- [OutboundTransfers](https://docs.stripe.com/api/treasury/outbound_transfers.md)
+- [OutboundPayments](https://docs.stripe.com/api/treasury/outbound_payments.md)
+- [InboundTransfers](https://docs.stripe.com/api/treasury/inbound_transfers.md)

package/templates/skills/cbp-task-check/SKILL.md

@@ -120,7 +120,12 @@ Save agent output to task context: `codebyplan task update --id <taskId> --check
 
 **READY + satisfied:**
 
-**Next**: Run `/clear`, then `/cbp-task-testing {chk-task}` to run comprehensive task-level testing.
+Starting task testing...
+
+Invoke `cbp-task-testing` via the Skill tool with the same `{chk-task}` argument. `cbp-task-testing`
+is `allow`-tier — it auto-fires silently. If the `cbp-skill-context-guard.sh` hook detects the
+context window is above the 200K threshold it will block the skill and direct you to run
+`/cbp-clear-prep` first; otherwise testing starts immediately.
 
 **NOT READY — fixable issues:**
 
@@ -130,7 +135,9 @@ Issues found that need addressing:
 - [issue 2]
 ```
 
-Suggest: `/cbp-round-input` with specific issues. **STOP HERE** — wait for user.
+Invoking `cbp-round-input` to address the issues found during review...
+
+Invoke `cbp-round-input` via the Skill tool. `cbp-round-input` is `allow`-tier — it auto-fires silently.
 
 **NOT READY — needs new task:**
 
@@ -139,7 +146,7 @@ Scope issues identified that require a new task:
 - [scope issue]
 ```
 
-Suggest: `/cbp-task-create`. **STOP HERE** — wait for user.
+Suggest: `/cbp-task-create`. **STOP HERE** — wait for user (creating a new task is a user scope decision — not auto-triggered).
 
 **NOT READY — approvals missing:**
 
@@ -147,7 +154,7 @@ Suggest: `/cbp-task-create`. **STOP HERE** — wait for user.
 Code review passed but [N] files need user approval.
 ```
 
-Suggest: Approve files, then re-run `/cbp-task-check`. **STOP HERE** — wait for user.
+Suggest: Approve files, then re-run `/cbp-task-check`. **STOP HERE** — wait for user (approval is a user action — not auto-triggered).
 
 ## Key Rules
 
@@ -161,5 +168,5 @@ Suggest: Approve files, then re-run `/cbp-task-check`. **STOP HERE** — wait fo
 
 - **Reads**: `.codebyplan/state/checkpoints/*.json`, `checkpoints/<id>/tasks/*.json`, `checkpoints/<id>/tasks/<id>/rounds/*.json`, `todos.json` (local-first; `npx codebyplan sync` on miss; MCP `get_current_task`/`get_rounds` break-glass), plus all changed files (via agent)
 - **Writes**: `codebyplan task update` (CLI write-through; MCP `update_task` break-glass)
-- **Triggers**: emits directive `Next: /clear, then /cbp-task-testing {chk-task}` on READY + satisfied (cross-context — testing is heavyweight, fresh context helps)
+- **Triggers**: auto-triggers `cbp-task-testing` via Skill tool on READY + satisfied (`allow`-tier, fires silently; the 200K context guard handles oversized contexts via the cbp-clear-prep flow); auto-triggers `cbp-round-input` via Skill tool on NOT READY — fixable issues (`allow`-tier, fires silently)
 - **Triggered by**: `/cbp-round-complete` (auto, when all files approved)

package/templates/skills/cbp-task-complete/SKILL.md

@@ -2,6 +2,7 @@
 name: cbp-task-complete
 description: Complete current task
 argument-hint: [chk-task]
+triggers: [cbp-task-start, cbp-checkpoint-check]
 effort: xhigh
 ---
 
@@ -155,7 +156,7 @@ Show the completion summary:
 **Warnings**: [any QA / file-approval warnings from Step 3, or "none"]
 ```
 
-Then route. Same-context transitions (next task in this checkpoint) auto-trigger via the Skill tool. Cross-context transitions (checkpoint done → /cbp-checkpoint-check, session end) surface as a single directive 'Next: /clear, then /cbp-X' for the user to invoke after refreshing context.
+Then route. Same-context transitions (next task in this checkpoint) auto-trigger `cbp-task-start` via the Skill tool. Checkpoint-done (last task) also auto-triggers `cbp-checkpoint-check` via the Skill tool (`ask`-tier — the permission prompt is the human gate; the 200K context guard handles oversized contexts via the cbp-clear-prep flow). Only the no-task-anywhere session-end fallback surfaces as a single directive (`Next: Run /clear, then /cbp-session-end`) for the user to invoke.
 
 #### 9a — Determine routing context
 
@@ -179,16 +180,13 @@ Use the Skill tool with `skill: cbp-task-start` and `args: "{NEXT_CHK}-{NEXT_TAS
 
 If no next task is found (no pending work anywhere in the repo), emit directive and stop: `Next: Run /clear, then /cbp-session-end.`
 
-#### 9c — Checkpoint-done directive (last task in checkpoint)
+#### 9c — Checkpoint-done auto-trigger (last task in checkpoint)
 
-The checkpoint has no remaining tasks. Emit this directive and stop:
-
-```
-CHK-{NNN} is fully tasked. Run /clear, then /cbp-checkpoint-check to verify and ship.
-Alternatives: /cbp-checkpoint-update {NNN} to expand the checkpoint with more tasks, or /cbp-session-end to wrap up here.
-```
-
-Do NOT use AskUserQuestion here — this is a directive, not a menu. The user runs whichever command fits their intent.
+The checkpoint has no remaining tasks. Invoke `cbp-checkpoint-check` via the Skill tool.
+`cbp-checkpoint-check` is `ask`-tier — the harness permission prompt IS the human gate; the
+user confirms (or declines) before checkpoint verification and ship begins. If the context
+window is above the 200K threshold the `cbp-skill-context-guard.sh` hook will block it and
+direct you to run `/cbp-clear-prep` first; otherwise checkpoint-check starts on confirmation.
 
 ## Integration
 
@@ -197,5 +195,5 @@ Do NOT use AskUserQuestion here — this is a directive, not a menu. The user ru
 - **Reads**: `.codebyplan/state/checkpoints/*.json`, `checkpoints/<id>/tasks/*.json`, `checkpoints/<id>/tasks/<id>/rounds/*.json`, `todos.json` (local-first; `npx codebyplan sync` on miss; MCP `get_current_task`/`get_rounds`/`get_tasks` break-glass)
 - **Writes**: `codebyplan task update` for `files_changed` (CLI write-through; MCP `update_task` break-glass); MCP `complete_task` for task completion (kept MCP — CLI cannot forward `caller_worktree_id`)
 - **Uses skills (inline, no sub-agent)**: `cleanup` (if deletions), `migration` (if exports renamed)
-- **Triggers**: Same-context transitions auto-trigger via the Skill tool (next task in checkpoint → `/cbp-task-start {N}`). Cross-context transitions emit a directive `Next: /clear, then /cbp-X` for the user to invoke.
+- **Triggers**: Same-context transitions auto-trigger via the Skill tool (next task in checkpoint → `cbp-task-start {N}`, `allow`-tier, fires silently). Checkpoint-done → auto-triggers `cbp-checkpoint-check` via Skill tool (`ask`-tier, permission prompt IS the human gate). No-task-anywhere fallback → directive `Next: Run /clear, then /cbp-session-end.`
 - **Checkpoint-bound only** — for standalone tasks use `/cbp-standalone-task-complete`

package/templates/skills/cbp-task-complete/reference/checkpoint-done-branching.md

@@ -1,8 +1,8 @@
-# Checkpoint-Done Branching in `/cbp-task-complete` Step 9
+# Checkpoint-Done Auto-Trigger in `/cbp-task-complete` Step 9
 
-When the just-completed task was the LAST pending task in its checkpoint (every sibling task has `status === 'completed'`), Step 9c emits a directive instead of a routing menu. The user reads the directive and runs whichever command fits their intent — no AskUserQuestion.
+When the just-completed task was the LAST pending task in its checkpoint (every sibling task has `status === 'completed'`), Step 9c auto-triggers `cbp-checkpoint-check` via the Skill tool — no routing menu, no manual `/clear` directive.
 
-This file describes the detection logic, the directive form, and the standalone fall-through.
+This file describes the detection logic, the auto-trigger form, and the standalone fall-through.
 
 ## Detection
 
@@ -10,39 +10,32 @@ The skill detects "checkpoint done" at Step 9 by:
 
 1. Reading `current_task.checkpoint_id`. If `null` → standalone — see "Standalone Fall-Through" below.
 2. Calling `get_tasks(checkpoint_id)` and checking that EVERY task other than the just-completed one has `status === 'completed'`.
-3. If yes, the checkpoint has no pending or in-progress siblings — emit the Step 9c directive.
+3. If yes, the checkpoint has no pending or in-progress siblings — fire the Step 9c auto-trigger.
 
-## Step 9c Directive Form
+## Step 9c Auto-Trigger Form
 
-When all siblings are done, the skill emits:
+When all siblings are done, the skill invokes `cbp-checkpoint-check` via the Skill tool:
 
-```
-CHK-{NNN} is fully tasked. Run /clear, then /cbp-checkpoint-check to verify and ship.
-Alternatives: /cbp-checkpoint-update {NNN} to expand the checkpoint with more tasks, or /cbp-session-end to wrap up here.
-```
+- `cbp-checkpoint-check` is `ask`-tier — the harness permission prompt IS the human gate. The user confirms (or declines) before checkpoint verification and the shipment chain begin.
+- No `/clear` is emitted unconditionally. If the `cbp-skill-context-guard.sh` hook detects the context window is above the 200K threshold it blocks the skill and directs you to run `/cbp-clear-prep` first (which writes a handoff; the user then runs `/clear`, then `/cbp-clear-continue` resumes); otherwise checkpoint-check starts immediately on confirmation.
 
-This is a directive, not a menu. No AskUserQuestion. The user runs whichever command fits their intent:
-
-- `/clear` then `/cbp-checkpoint-check` — verify deliverables and begin the shipment chain
-- `/cbp-checkpoint-update {NNN}` — expand the checkpoint with more tasks (routes through `checkpoint-update` FIRST, not directly to `task-create`)
-- `/cbp-session-end` — wrap up here
-
-The skill does NOT auto-invoke any of these. Emit the directive, then stop.
+There is no AskUserQuestion menu. Expanding the checkpoint with more tasks (`/cbp-checkpoint-update`) or wrapping up the session (`/cbp-session-end`) are no longer surfaced as inline alternatives — the deterministic next step on checkpoint-done is `cbp-checkpoint-check`. (The user can still invoke those other skills manually at any time; they are simply not part of the auto-flow.)
 
 ## Standalone Fall-Through
 
 When the just-completed task is standalone (`checkpoint_id === null`):
 
-- The Step 9c directive does NOT apply. There is no checkpoint to ship, expand, or defer.
+- The Step 9c auto-trigger does NOT apply. There is no checkpoint to verify or ship.
 - Step 9 falls through to next-task routing per `next-step-heuristic.md` "Standalone Variant":
   - If a next pending task is found (standalone or in-progress checkpoint): auto-trigger via Skill tool — no AskUserQuestion, no /clear.
   - If no pending tasks remain anywhere: emit single directive `**Next**: Run /clear, then /cbp-session-end.` — all known work complete.
 
 ## What the Skill Does NOT Do
 
-Never auto-trigger `/cbp-checkpoint-check`, `/cbp-checkpoint-update`, or auto-mark the checkpoint complete — those are cross-context transitions that emit a single directive, not auto-invocations. Never combine the Step 9c directive with the Step 9b auto-trigger in the same response — one or the other based on detection, not both.
+- Never combine the Step 9c auto-trigger (checkpoint done → `cbp-checkpoint-check`) with the Step 9b auto-trigger (next task in checkpoint → `cbp-task-start`) in the same response — fire one or the other based on detection, not both.
+- Never present a multi-option AskUserQuestion menu for routing between known-next skills (per the close-out-routing rule — auto-trigger or a single directive, never an A/B/C menu).
 
 ## Pairs With
 
-- `next-step-heuristic.md` — sibling reference for non-last-task-in-checkpoint case (Step 9b auto-trigger)
-- `.claude/skills/cbp-checkpoint-update/SKILL.md` — destination of the expand path; accepts the entry-context preamble described in Step 9c
+- `next-step-heuristic.md` — sibling reference for the non-last-task-in-checkpoint case (Step 9b auto-trigger)
+- `.claude/skills/cbp-checkpoint-check/SKILL.md` — the auto-triggered destination on checkpoint-done

package/templates/skills/cbp-task-complete/reference/next-step-heuristic.md

@@ -17,19 +17,17 @@ No AskUserQuestion, no `/clear`. The skill fires immediately.
 
 ## Case 2 — Cross-Context (checkpoint done, session end)
 
-When the checkpoint is fully done or no pending tasks exist in the current context, emit a single directive line at the end of skill output and stop:
+Two sub-cases:
 
-```
-**Next**: Run /clear, then /cbp-checkpoint-check.
-```
+**Checkpoint done** (last task in the checkpoint complete): auto-trigger `cbp-checkpoint-check` via the Skill tool. `cbp-checkpoint-check` is `ask`-tier — the permission prompt is the human gate; the 200K context guard handles oversized contexts (via `cbp-clear-prep`) only when context is near the limit. No unconditional `/clear`. (See `checkpoint-done-branching.md`.)
 
-Or for session-end:
+**Session end** (no pending tasks anywhere): emit a single directive line at the end of skill output and stop:
 
 ```
 **Next**: Run /clear, then /cbp-session-end.
 ```
 
-The user runs the command after refreshing context. No menu, no options — just one directive.
+The user runs session-end after refreshing context. No menu, no options — just one directive.
 
 ## Rule
 

package/templates/skills/cbp-task-testing/SKILL.md

@@ -2,7 +2,7 @@
 name: cbp-task-testing
 description: Run comprehensive task-level testing after /cbp-task-check passes
 argument-hint: [chk-task]
-triggers: [cbp-task-complete]
+triggers: [cbp-task-complete, cbp-round-input]
 effort: xhigh
 ---
 
@@ -233,21 +233,16 @@ Collect failures from automated tests (Step 6), cross-round code review (Step 6.
 All tests passed for TASK-[N]. Routing to task-complete...
 ```
 
-Auto-trigger `/cbp-task-complete`.
+Invoke `cbp-task-complete` via the Skill tool. `cbp-task-complete` is `ask`-tier — the harness
+permission prompt IS the human gate; the user confirms (or declines) before task commit,
+merge-main, and completion.
 
 **Minor problems found:**
 
----
-
-**Next:**
-Run `/cbp-round-input` to:
-
-- Address the minor issues found during testing
-- Create a focused round for fixes
-
----
+Invoking `cbp-round-input` to address the minor issues found during testing...
 
-Waiting for user to run `/cbp-round-input`.
+Invoke `cbp-round-input` via the Skill tool. `cbp-round-input` is `allow`-tier — it auto-fires
+silently.
 
 **Major problems found:**
 
@@ -278,5 +273,5 @@ Waiting for user to run `/cbp-task-create`.
 
 - **Reads**: `.codebyplan/state/checkpoints/*.json`, `checkpoints/<id>/tasks/*.json`, `checkpoints/<id>/tasks/<id>/rounds/*.json`, `todos.json` (local-first; `npx codebyplan sync` on miss; MCP `get_current_task`/`get_rounds` break-glass), plus all aggregated files
 - **Writes**: `codebyplan task update` (CLI write-through; MCP `update_task` break-glass)
-- **Triggers**: `/cbp-task-complete` (auto, when ALL PASS)
-- **Triggered by**: user runs `/cbp-task-testing {chk-task}` per directive from `/cbp-task-check` on READY verdict (after `/cbp-round-execute`-driven validation completed all rounds)
+- **Triggers**: `cbp-task-complete` (auto via Skill tool, when ALL PASS — `ask`-tier, permission prompt IS the human gate); `cbp-round-input` (auto via Skill tool, on minor problems — `allow`-tier, fires silently)
+- **Triggered by**: `cbp-task-check` auto-triggers this skill via Skill tool on READY verdict; `cbp-task-testing` is `allow`-tier and fires silently (no permission prompt)