Pulse — Quick Inline Design Check

Purpose

Pulse is a 5-minute naysayer pass on a design decision. It's lighter than /shape (which runs a /plan + 2-seat huddle naysayer review) and lighter than /deepthink (which runs the full 9-phase multi-agent exploration). Use pulse when:

• You've just stated an approach (1-2 sentences)
• You want a sanity check before committing time
• A full /shape is overkill (5+ min, multiple phases)
• A full /plan is overkill (writes a plan doc, doesn't make sense for a single decision)
• You need a DECISIVE verdict (GO / GO-WITH-CAVEATS / NO-GO)

When to load

Load pulse automatically when ANY of the following are true:

1. The user says: "pulse this", "quick check", "is this sane", "sanity check", "punch holes in this", "what do you think", "any concerns"
2. You've just proposed a 1-paragraph design and the user hasn't committed to it yet
3. The user is choosing between 2-3 options and wants a quick "which is best?"
4. After a /shape or /deepthink concludes with "this is fine, just doing the lighter check"
5. Before committing 1+ hour of work to a non-trivial implementation
6. A /shape or /deepthink result was just shown and you want a second-pass tighter check

IMPORTANT: /pulse is a SKILL, not a slash command. Type /pulse at the prompt and you get "Unknown command: /pulse" because slash commands are for built-ins like /plan, /shape, /deepthink. Skills auto-load via natural language matching the trigger phrases above. If the user types /pulse, the system tries to invoke a slash command that doesn't exist — surface this distinction immediately so they know to use natural language ("pulse this..." or "quick check on...").

Do NOT use pulse for:

• Bug fixes (use /systematic-debugging or just do it)
• Trivial decisions (no design space to evaluate)
• Full architecture (use /deepthink)
• Code review (use /requesting-code-review)
• The user has already committed (don't second-guess)
• Pure execution work (just do it)

The pulse protocol

A pulse check produces 3 sections in plain text (no markdown headers, terminal-friendly). Max 15 lines total.

1. Approach (1-2 lines)

approach: [1-2 sentence description of what's being considered]

2. Failure modes (3-5 lines)

failure modes:
1. [most likely way this could go wrong — concrete, not vague]
2. [second most likely]
3. [third]
4-5. [optional, only if you have substantive additional concerns]

Each failure mode must be CONCRETE (not "edge cases might bite us" — say WHICH edge case). Skip anything with <5% probability.

1b. Scope check (before failure modes) — for BUILD proposals specifically

When the approach is "build X" and X is a multi-hour project, add a scope check BEFORE the failure-modes list. This is the single most common class of pulse that goes wrong: a build is proposed when existing tools (or a 10-minute alternative) could do the job. The user will catch this with a "can't I already do this with what I have?" / "does this solve a real problem or give me a new project?" / "isn't there a simpler way?" — the pulse should catch it FIRST.

scope check:
  - can the user already do this with existing tools? (grep? an installed skill? 5 lines of bash?)
  - is the proposed "build" actually a 10-minute script in disguise?
  - what gets WORSE if the user takes the build path? (new project to maintain, new surface to debug, new failure mode)
  - what's the smallest version that solves the real problem? (often a shell function, not a tool)

If the scope check reveals a 10-minute alternative, the verdict is usually GO-WITH-CAVEATS toward the 10-minute version, not GO on the full build. The 10-minute version preserves the option to do the full build later (option value) without committing to it.

Real signal that triggered this section (2026-06-11 transcript-unification session): user proposed "build a unified archive with 4 ingest paths, 5-6 hours." After pulse scope check, the answer was "write a 10-line shell function that greps 5 existing stores" (10 min, no new project). The 5-hour build is deferred to "A for later" if/when the 10-min version is actually a bottleneck. Pattern: when the user asks "build X" and X is large, the first pulse output is often "you can already do X-ish with what you have, here's the cheap version" — not "GO on the full build."

3. Verdict (1 line, optional 1-2 caveat lines)

verdict: GO | GO-WITH-CAVEATS | NO-GO
caveats: [if GO-WITH-CAVEATS, list 1-2 specific things to address before/during implementation]

Output format

Plain text only. NO tables, NO bold-for-emphasis (use CAPS sparingly), NO markdown headers, NO code fences. Each section starts with a lowercase label followed by a colon.

Example:

approach: shard leaderboard_snapshot to 3 jsonl files of ~10MB each, well under the 25 MiB CF Pages limit.
failure modes:
1. shard boundaries might cut a user's record mid-line (parse error on read)
2. rebuild script needs to know how many shards exist (coupling with metadata)
3. CF Pages might still reject if file count limit hit (20K)
verdict: GO-WITH-CAVEATS
caveats: write a wc -l test to verify each shard is complete; document the shard count in manifest.json

Constraints

• Do NOT use tools that modify files (Read, Bash for read-only verification is OK)
• Do NOT ask follow-up questions — be DECISIVE
• Do NOT exceed 15 lines total
• Do NOT use /pulse for trivial decisions (no design space)
• Do NOT skip a failure mode just because it's unlikely — only skip it if it's <5% likely
• Do NOT use a verdict of MAYBE — pick a side

Bias check (before giving NO-GO on parallel / multi-agent work)

When pulsing a strategy that involves parallel agents, multi-worktree dispatch, or concurrent execution, the failure modes you list MUST be actual blockers, not just risks. Before writing NO-GO, run this internal check:

• "Risk vs blocker" — is each failure mode a HARD block (cannot be worked around) or a SOFT risk (manageable)? risks that the orchestrator can handle (merge conflict resolution, incremental merge, --max-turns tuning, summary-reading) are NOT blockers.
• "Conflation test" — am I conflating "this is risky" with "this is a reason not to do it"? if the user is asking, they've already accepted some risk. NO-GO should be reserved for cases where the design is genuinely unsound, not where execution has friction.
• "Cost parity" — parallel batch has the same total cost as sequential (one dispatch per work item). if cost is the concern, it's not actually a concern. wall time and risk are the only real dimensions.
• "Incremental merge" — if each worker commits to its own feature branch, the orchestrator can merge one at a time and validate between. that makes "all-or-nothing batch" a false failure mode.

If after the bias check, the verdict is still NO-GO, give it. But if the verdict flips to GO or GO-WITH-CAVEATS, that's the right call. (Observed 2026-06-10: gave a NO-GO on a parallel-batch strategy for a large backlog; user pushed back ("any reason to not just do the parallel?"); honest re-analysis showed the verdict was wrong — the failure modes were all risks, not blockers, and the orchestrator could handle them. updated verdict: GO-WITH-CAVEATS.)

Hard-fail guard

Before sending the pulse output, check all of the following. If any fails, fix it before sending — don't ship a pulse that violates its own protocol:

• Verdict is exactly one of GO / GO-WITH-CAVEATS / NO-GO — not MAYBE, not hedged, not a restated failure mode
• Total output is ≤15 lines
• No follow-up question was asked anywhere in the output
• No state-modifying tool was used (Read/read-only Bash is fine; Write/Edit/Bash-that-mutates is not)
• At least 1 concrete failure mode is listed — zero failure modes means look harder, not "this approach has none"
• Output uses plain text labels (approach:, failure modes:, verdict:), not markdown headers or tables

This is the difference between the "Do NOT" rules under Constraints being read and being enforced — treat this checklist as a gate, not a suggestion.

When to escalate

If after the pulse you realize the design needs:

• More than 5 minutes of analysis → escalate to /shape
• Multi-agent debate or formal council review → escalate to /deepthink or /multi-model-review
• Actual planning into a structured plan doc → escalate to /plan
• Throwaway experiment to validate an idea → escalate to /spike

History

v1.0.0 (2026-06-10): initial install. concept referenced by /shape ("Sits between /pulse (inline ≈5 min) and /deepthink"). Filled the gap between no-check and full-shape.