hashintel/card

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:spike first, 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

1. Is the target behavior one sentence?
2. Are glossary terms from the capsule used correctly?
3. Is every risk either mitigated or flagged for a spike?
4. Is buy-vs-build resolved explicitly for this slice?
5. If behavior is unclear, is there a concrete prototype plan before delivery?
6. Does the definition of done map to concrete test names and observable checks?
7. Can the definition of done be checked by running a command?
8. 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)