hashintel Tracer-Bullet Card
Write a tracer-bullet card — a precise specification for one slice of work that will be implemented with /pragma:slice.
Input
The behavior to deliver: $ARGUMENTS
Precondition: a concept capsule must exist. If none exists, stop and recommend /pragma:capsule first. Read the capsule — the card must use glossary terms and respect invariants.
Output: The Card
Write a card with exactly these four fields:
Target Behavior (one sentence)
What should be true when this slice is done? Single declarative sentence.
Good: "A markdown file with YAML front-matter is parsed into a Post with title, date, and body." Bad: "Implement the parsing system" (too vague) / "Add support for markdown, YAML, TOML, and JSON" (too many things)
- Must be observable / testable
- Must reference glossary terms from the capsule
- If it needs "and", split into two cards
Boundary Crossings
Every boundary the tracer bullet passes through:
→ [entry point] (e.g., CLI argument, HTTP request, function call)
→ [layer/boundary] (e.g., parser, domain core, adapter)
→ [exit point] (e.g., file written, response sent, value returned)
Be specific ("the PostgreSQL adapter", not "the backend"). Note boundaries that don't exist yet.
Risks / Assumptions
- RISK: [what might not work] → MITIGATION: [how we'll handle it]
- ASSUMPTION: [what we're assuming] → VALIDATED BY: [how we'll know]
- BUY-OR-BUILD: [buy|build + why package/tool fit is or is not acceptable]
- PROTOTYPE PLAN: [if requirement behavior is unclear, how we'll prototype and observe it]
- OUT OF SCOPE: [explicitly excluded for this slice]
- High + unmitigated risk → this card needs a
/pragma:spikefirst, not a/pragma:slice - "No risks" is almost always wrong — dig harder
- BUY-OR-BUILD is mandatory (even if answer is "build")
- PROTOTYPE PLAN is mandatory when behavior is unclear; skip only when behavior is already concrete
- Always include at least one OUT OF SCOPE line
Definition of Done
✓ [test name] — [observable assertion checked by that test]
✓ [test name] — [observable assertion checked by that test]
- Every assertion must be executable
- Treat these as spec tests to write first in
/pragma:slice(red step) - Prefer black-box assertions at boundaries over implementation-detail assertions
- Do NOT include "code is clean" — that's the refactor step's job
Validation
- Is the target behavior one sentence?
- Are glossary terms from the capsule used correctly?
- Is every risk either mitigated or flagged for a spike?
- Is buy-vs-build resolved explicitly for this slice?
- If behavior is unclear, is there a concrete prototype plan before delivery?
- Does the definition of done map to concrete test names and observable checks?
- Can the definition of done be checked by running a command?
- Could this slice be implemented in one focused session?
Where to put it
Cards are ephemeral — consumed by /pragma:slice, then the definition of done becomes the test.
- Print to the conversation (default)
- Write to
docs/cards/if the user wants to track them
Lifecycle tail (required)
Append to the response:
- State:
planning - Next:
/pragma:slice - Loop:
/pragma:consult(default unless user explicitly continues directly)