Prompt Craft

Prompt Craft

Purpose

Guide the creation of high-quality prompts for frontier reasoning models. The core challenge: give the model enough context to reason deeply, without steering it toward predetermined conclusions.

This skill is the opposite of reasoning-craft. Reasoning-craft assembles codebase context mechanically and defines a rigid output contract. Prompt-craft helps you design the question — what to include, what to leave open, how to frame the problem so the model does its best thinking.

---

The Anti-Prescriptive Principle

The single most important rule: context is data, direction is poison.

Every element in a reasoning prompt falls on a spectrum:

CONTEXT (good)                              DIRECTION (bad)
─────────────────────────────────────────────────────────────
"Here is how system X works"     →    "System X has problem Y"
"System A does X, System B       →    "The pattern here is Z"
 does Y"
"The primary pain point is..."   →    "The fix is..."
"Consider whether..."            →    "You should find that..."
"What's the relationship         →    "The Evaluation Sandwich
 between evaluation and            pattern solves this"
 optimization speed?"

A good reasoning prompt is heavy on the left, minimal on the right.

The Litmus Test

Before including any analytical framing, suggestion, or named pattern, ask:

"Am I telling the model what to find?"

If yes — delete it or convert it to an open question.

Exceptions

One or two provocative examples are acceptable to set the depth bar. These signal "I want this level of non-obvious thinking" without prescribing the full analysis. Example:

"I'm interested in things like: Why does restricting an evaluator's information access produce better signals? Is that a special case of something more general?"

This opens a door without walking through it.

---

Three Modes

The workflow has three modes. Choose based on where the context lives and whether this is a one-off or recurring analysis:

Mode	When to Use	Context Source	Clarification
Assemble	Context lives in systems — codebases, documents, external projects	Files, APIs, web research	3-4 scoping questions, then gather from systems
Interview	Context lives in the user's head — their experience, organizational reality, tacit knowledge	The user, via multiple rounds of AskUserQuestion	As many rounds as needed to surface the full picture
Review	Recurring deep review of a technical project — architecture critique, optimization proposals, test strategies	Compound-engineering knowledge base (subsystem specs, architecture.yaml, ORCHESTRATOR.md) + dynamic context (git, Linear, tests) + short interview for current focus	1-2 interview rounds focused on "what's the question right now?"
Writing Revision	Iterative revision of a draft using structured annotations and a persistent writing contract	Contract (frozen rules, style anchors, series context) + numbered draft + annotations file	Use /craft-revision — assembles a self-contained revision prompt for an external model

How to choose:

• "Look at these plugins" or "research this project" → assemble
• "Here's my situation" or organizational/strategic topic → interview
• "Review the architecture of project X" or "what should we optimize next?" → review
• "Revise this draft" or "I have annotations for my article" → writing revision (use /craft-revision)
• Mixed: interview first to understand reality, then assemble supporting artifacts

---

The Blind Model Principle

The single most critical constraint in reasoning prompt assembly: the target model has ZERO access to anything outside the prompt.

The reasoning model cannot:

• Read files from the codebase
• Access Linear, GitHub, or any API
• See previous conversation history
• Load subsystem specs or architecture docs
• Run code or tests

Everything the model needs to reason well must be inlined in the prompt text. If context is referenced but not included, the model will hallucinate or give generic advice.

The Self-Containment Test

Before finalizing any prompt, apply this test:

"If I gave this prompt to a brilliant developer who has never seen this project, could they give specific, actionable advice?"

If the answer is no, the prompt is missing context. Specifically check:

Check	Question	If Missing
Project identity	Does the model know what this project IS and what it's trying to achieve?	Add product concept / project description
System boundaries	For every subsystem mentioned, does the model know its purpose, owned files, and contracts?	Inline the subsystem spec or relevant sections
Dependency graph	Are relationships between components explicit?	Add a dependency diagram or list
Actual code	Where architecture meets implementation, is real code included?	Inline key files, interfaces, or code excerpts
Constraints	Does the model know what CAN'T change?	State non-negotiables explicitly
Current state	Does the model know what's working vs broken vs missing?	Add gap analysis or status summary
User's intent	Does the model know what the user is trying to achieve (not just what exists)?	Add the goal, not just the situation

Context Density Hierarchy

Not all context is equal. When assembling, prioritize by information density:

HIGH VALUE (always include)
├── Actual code: interfaces, schemas, key implementations
├── Subsystem specs: invariants, dependencies, public_api
├── Architecture constraints: what must stay true
├── Gap analysis: what's missing and what it blocks
└── User's stated intent and constraints

MEDIUM VALUE (include when relevant)
├── File tree / directory structure
├── Test structure and coverage state
├── Recent changes (git log summary)
├── Linear project state (milestones, open issues)
└── Common failure modes from specs

LOW VALUE (include only if space permits)
├── Full file contents when excerpts suffice
├── Historical decisions (unless directly relevant)
├── Build/deploy configuration
└── Helper scripts and utilities

---

The Prompt Craft Workflow

Phase 1: Understand Intent

Start with the real question — not logistics.

Before asking about models, depth, or output format, understand what the user actually needs help with. Extract from their initial request:

1. The stuck point — What decision, direction, or problem do they need an outside perspective on? This is the core. Examples:

   • "I need architectural clarity on restructuring auth"
   • "I want a step-by-step plan for closing these gaps"
   • "I need someone to challenge my assumptions about the data flow"
   • "I found problems in the API layer — I need a pragmatic approach"

2. Topic — What domain or system is this about?

3. Prior investigation — Has the user already explored this area? Check for:

   • Recent /investigate sessions (gap map artifacts in ./compound-discoveries/)
   • Existing understanding they've built (they may describe the architecture fluently)
   • Specific observations or hypotheses they've formed

4. Mode signal — Does context live in systems (assemble) or in the user's experience (interview)?

If the stuck point is unclear, ask ONE question before anything else:

"What would change if the reasoning model gave you a perfect answer? What decision would you make, or what direction would you take?"

This surfaces the real intent behind the request.

Phase 2: Scope (both modes)

Ask 3-4 targeted questions. Lead with intent, not logistics:

A. What the reasoning model needs to understand

• "For the model to help with {stuck point}, it needs to understand {X}. What else am I missing?"
• This determines: which subsystem specs, code, and context to include

B. What you want back

• A clear architectural direction? A step-by-step plan? A critique of your current approach? Trade-off analysis?
• This determines: how to frame the task section

C. Target model and interaction mode

• Which reasoning model? (o3, R1, Gemini 2.5 Pro, Claude with extended thinking)
• Single-shot prompt or interactive dialogue?
• This determines: prompt length budget, whether to include all context upfront or leave room for follow-ups

D. Scope boundaries

• How broad should the analysis go? Specific subsystems only, or system-wide?
• Are there specific constraints or non-negotiables the model must respect?
• This determines: how much context to gather

Important: Don't ask more than 4 questions in this phase. Use judgment to fill gaps. If the user just came from /investigate, you already have most of the context — lean on that.

Phase 2b: Interview (interview mode only)

When context lives in the user's head, run a multi-round interview to surface it. This is the critical differentiator — documents and systems describe what was planned; the interview surfaces what actually happens.

Interview Principles

1. Start with reality, not documents. If reference documents exist (like the pillar docs), read them first — then ask how reality differs. The gap between document and reality is where the most valuable context lives.

2. Build on previous answers. Each round of questions should reference and dig into what the user just told you. If they mention a tension ("the Deputy brings in projects"), the next round should explore that tension specifically.

3. Ask about specifics, not abstractions. "What does a typical project look like?" beats "How do you think about project management?" Concrete details produce better reasoning model context than the user's own generalizations.

4. Surface tensions and pain points. The reasoning model needs to understand what's not working — these are the constraints it needs to reason about. Ask directly: "What's the biggest gap between this document and reality?"

5. No fixed question count. Interview until you have a complete picture. Typically 3-5 rounds of 3-4 questions each. Stop when answers start confirming what you already know rather than adding new dimensions.

6. Capture the user's own framing. When the user describes their situation in their own words (especially in free-text notes on answers), preserve that framing in the prompt. Their language often carries nuance that a summary would lose.

Interview Structure

Round 1: Situation and composition

• Who's on the team? What's the actual composition vs. planned?
• How mature is the function? How does the organization see you?
• What's the current cadence/rhythm?

Round 2: How work actually flows

• How does work come in? (vs. what the documents say)
• What's the biggest operational pain point?
• How do key governance bodies actually function?

Round 3: Roles and tensions

• Dig into specific role boundaries that surfaced in Round 2
• How do people actually work — ownership model, collaboration patterns
• Where's the biggest gap between documents and reality?

Round 4: Context and constraints

• Organizational context (industry, culture, size)
• Authority — who needs to approve what?
• What does success look like?

Round 5+ (if needed): Go deeper on tensions

• Follow threads from previous rounds
• Ask about specific scenarios or examples
• Surface the user's vision for what "working" looks like

When to Stop Interviewing

Stop when you can answer these without guessing:

• What's the team's actual operating reality today?
• What are the 2-3 structural tensions that need resolving?
• What constraints is the reasoning model working within?
• What does the user want to be different?

Phase 2c: Review Context Assembly (review mode only)

Review mode uses the compound-engineering knowledge base as the static profile — no separate profile file needed. The existing artifacts ARE the profile:

Static Context (the "profile" — changes slowly)

Artifact	What It Provides	How to Read
subsystems_knowledge/**/*.yaml	Architecture, invariants, dependencies, gaps, milestone state per subsystem	Glob + Read all specs
subsystems_knowledge/architecture.yaml	Cross-subsystem invariants, ownership checks	Read directly
ORCHESTRATOR.md	Conventions, decisions, known risks, lessons, architecture overview	Read from repo root

Include the full subsystem specs — not summaries. The reasoning model needs to see actual invariants, dependency graphs, and gap lists to propose meaningful improvements. Trim only architecture.overview and architecture.components ASCII diagrams if they're very large.

Dynamic Context (changes every review — gathered automatically)

Source	What It Provides	How to Gather
git log since last review	What changed, active areas, momentum	git log --oneline -30 (or since last review date)
git diff --stat since last review	Scale and shape of changes	git diff --stat {last_review_commit}..HEAD
Linear project state	Current milestone, open issues, blockers, recently completed	Linear MCP tools
Test results	Current pass/fail state	Run tier0/tier1 commands from subsystem specs
Langfuse scores (if applicable)	Agent quality metrics	Langfuse helpers or MCP

If this is the first review: There's no "since last review" baseline. Gather the full current state and note that this is the initial review.

If a previous review exists: Read scripts/reasoning-prompt-{project}-v*.md to find the last version. Extract the date and key findings. The delta between then and now is valuable context.

Short Interview (1-2 rounds, focused on delta)

Unlike interview mode's full discovery, review mode asks only:

Round 1: Current focus

• "What's changed since we last looked at this? Any major shifts?"
• "What's the bottleneck or question you're wrestling with right now?"
• "Is there a specific area you want the reasoning model to challenge or stress-test?"

Round 2 (if needed): Dig into the bottleneck

• Follow up on whatever the user flagged in Round 1
• "What have you tried? What's your current thinking?"
• Surface the tension — what's the real question beneath the surface question

Review Types

The user may specify a focus, or leave it open:

Focus	What the reasoning model should emphasize
architecture	Structural critique, coupling, cohesion, subsystem boundaries
optimization	Where to apply agentic optimization, bottleneck identification
testing	Test coverage gaps, innovative test strategies, property-based testing candidates
direction	Strategic alignment — are we building the right thing?
(open)	The interview determines the focus

Don't prescribe which focus — let the user's answers in the short interview guide it.

Versioning

Review prompts are versioned per project:

scripts/
  reasoning-prompt-{project}-v1-2026-03-26.md
  reasoning-prompt-{project}-v2-2026-04-02.md

Each version includes a ## Review History section at the top of the context that summarizes what previous reviews found. This compounds — the reasoning model sees not just the current architecture but how it has evolved and what recurring patterns appear across reviews.

## Review History

### v1 (2026-03-26) — Initial architecture review
Key findings: [2-3 bullet summary from v1's reasoning model output]
Status: [which findings were acted on, which remain open]

### v2 (2026-04-02) — Post-refactor review
Key findings: [...]
Status: [...]

Updating review history: After the user gets the reasoning model's output, they can run /craft-prompt --review {project} --update-history to append the latest findings. This is the compounding step — without it, each review starts somewhat fresh.

Phase 2d: Pull Investigation Artifacts (if available)

Before gathering fresh context, check if the user has already done investigation work that should feed into the prompt:

1. Check for recent gap maps: ./compound-discoveries/*-gaps-*.md — these contain structured gap analysis with intent, current state, ranked gaps, and decisions
2. Check for recent reflections: ./compound-discoveries/*-reflection-*.md — these contain learnings from recent work sessions
3. Check for investigation session context: If the user just ran /investigate, the conversation already contains mental models, diagrams, and observations

If investigation artifacts exist:

• Read them. They contain pre-digested understanding that should be inlined in the prompt.
• Gap maps are especially valuable: they contain the user's stated intent, the current state analysis, and the specific gaps — exactly what the reasoning model needs.
• Don't re-gather what the investigation already captured. Build on it.

If the user came directly from /investigate:

• The session context contains diagrams, mental models, and observations. Ask: "Should I include the architecture understanding we just built in the investigation?"
• If yes, distill the key diagrams and findings into the prompt's context section.

Phase 3: Gather Context

Based on the clarified intent, assemble the raw material. Remember: the reasoning model is completely blind. Every piece of context must be self-contained.

Context sources by type:

Source	When to Use	How to Gather	What to Include
Investigation artifacts	User recently ran /investigate	Read from ./compound-discoveries/	Gap maps, intent statements, state analysis
Subsystem specs	Prompt involves engineering architecture	Read from subsystems_knowledge/	Full specs — invariants, dependencies, public_api, gaps
Actual code	Model needs to understand implementations, not just abstractions	Read source files identified by starter_files or paths.owned	Key interfaces, schemas, core logic. NOT entire files — targeted excerpts
Architecture docs	Prompt involves cross-subsystem concerns	Read architecture.yaml, ORCHESTRATOR.md	Invariants, conventions, decisions, known risks
Linear project	Prompt involves project state, direction, or product intent	Linear MCP tools	Project description, milestone structure, open issues, product concept
Web research	Prompt references external projects or concepts	WebSearch, WebFetch	Relevant documentation, alternative approaches
Multiple implementations	Prompt asks about patterns across systems	Gather 2-3 comparable systems	Full architecture of each for comparison

Context gathering principles:

1. Gather more than you'll include. Read broadly, then select what's relevant. The model needs accurate context, not exhaustive context.

2. Preserve specifics. Don't summarize "the system has 5 phases" — include the actual phase names, transitions, and constraints. Specifics enable reasoning; summaries enable confirmation.

3. Include what's working AND what's not. One-sided context produces one-sided analysis.

4. Comparative context creates contrast. If the user's system is one of several approaches to a problem, include the others. The reasoning model will find insights in the differences that a single-system analysis would miss.

5. Gather from the system's own perspective. Use READMEs, skill descriptions, and architectural docs as written — the model should understand the system's intended design, not just your interpretation of it.

6. Bridge abstraction levels. Subsystem specs describe architecture; code shows implementation. The reasoning model needs BOTH to give advice that's architecturally sound AND practically implementable. When a subsystem is central to the question, include spec + key code excerpts.

7. Include the dependency context. If the question is about subsystem A, and A depends on B and C, include enough about B and C that the model understands the constraints A operates within. The model can't "look up" what B's public_api is.

Phase 4: Assemble the Prompt

A well-crafted reasoning prompt has three sections. The ratio matters:

┌─────────────────────────────────────────┐
│           CONTEXT (~70-80%)             │
│                                         │
│  Rich, accurate, specific factual       │
│  material. Multiple systems if          │
│  comparative. Schemas, protocols,       │
│  decision tables, flow diagrams.        │
│                                         │
│  This is the "food" for reasoning.      │
│  Skimp here and the model starves.      │
├─────────────────────────────────────────┤
│           PROBLEM (~10-15%)             │
│                                         │
│  What you're trying to understand.      │
│  Name the problem or question clearly.  │
│  Name what's not working if relevant.   │
│  Do NOT name the causes or solutions.   │
│                                         │
├─────────────────────────────────────────┤
│           TASK (~10-15%)                │
│                                         │
│  What the model should produce.         │
│  Minimal structure — just enough so     │
│  the output is usable.                  │
│  Open questions, not leading ones.      │
│  "Structure however serves the ideas."  │
│                                         │
└─────────────────────────────────────────┘

Assembling the Context Section

Structure by system, not by theme. Let the reasoning model find the themes.

For each system or implementation:

1. What it is — one paragraph overview
2. How it works — the actual protocol, schema, or flow (specific, not summarized)
3. Key design decisions — what the designers chose and why (if known)
4. What it has and doesn't have — capabilities AND limitations, stated neutrally

If comparative (multiple systems): present each system fully, then note factual differences without interpreting them. A "what X has that Y doesn't" table is context. A "X is better because..." is direction.

Assembling the Problem Section

State what you want analyzed. Rules:

• Name the phenomenon, not the diagnosis. "Delegated work quality is inconsistent" not "The prompt template is too long."
• Include your vantage point. "I built these systems" or "I'm exploring whether X applies to Y" — this helps the model calibrate.
• One provocative question to set depth. Not a list of 10 things to investigate — one good question that signals "think at this level."

Assembling the Task Section

Minimal scaffolding for the output. Rules:

• Name the parts, not the contents. "Part 1: Principles. Part 2: Patterns." is fine. "Part 1: Extract these 5 principles: A, B, C, D, E" is not.
• Use open verbs. "Analyze", "identify", "derive", "explore" — not "confirm", "explain why X", "show that Y".
• End with freedom. "Structure however serves the ideas best" or "Keep it sharp — every paragraph should contain an insight."
• If you want the model to challenge assumptions, say so explicitly. "Where does this break?" is a powerful open question.

Phase 5: Quality Check

Before delivering the prompt, run two verification passes:

Pass 1: Self-Containment Test (The Blind Model Check)

Read the entire assembled prompt and ask: "If a brilliant developer who has never seen this project reads this, can they give specific, actionable advice?"

Check	Question	Fix if Failing
Project identity	Does the prompt explain what this project IS?	Add a 2-3 sentence project overview at the start of context
System boundaries	For every subsystem mentioned, is its purpose and scope clear?	Inline the subsystem spec's description, paths.owned, and public_api
Dependency graph	Are component relationships explicit, not implied?	Add a dependency list or diagram to the context
Code grounding	Where the question touches implementation, is real code included?	Add key interface files, schemas, or code excerpts
Constraints stated	Does the model know what CAN'T change?	Add explicit non-negotiables section
Intent included	Does the model know what the user wants to ACHIEVE, not just what exists?	Add the user's goal from Phase 1 / investigation
No dangling references	Does the prompt reference anything not included? (e.g., "see architecture.yaml")	Either inline the reference or remove it

If any check fails, fix it before proceeding. A prompt that fails self-containment will produce generic advice.

Pass 2: Anti-Prescriptive Check

Check	How
Anti-prescriptive test	Read the Task section. Count named patterns, prescribed solutions, or leading questions. Target: fewer than 2.
Context accuracy	Spot-check 3 facts against source files. Are schemas accurate? Are flows described correctly?
Ratio check	Is context ~70-80%? If the task section is longer than the context for any single system, it's too prescriptive.
Depth signal	Is there at least one provocative open question that shows the expected level of non-obvious thinking?
Output guidance	Is the output section minimal enough that the model could organize its response differently than you expect — and that would be fine?

Phase 6: Deliver

1. Write the prompt to a file (default: scripts/reasoning-prompt-{slug}.md)
2. Summarize what the prompt covers and what context was included
3. Note the target model and any length considerations

---

Writing Revision Mode

Writing revision is a specialized mode that uses a different workflow from the three reasoning-prompt modes above. Instead of crafting an open-ended reasoning prompt, it assembles a contract-driven revision prompt for surgical editing of a draft by an external model.

Entry point: /craft-revision command (not this skill directly).

How it works:

1. A persistent contract defines frozen rules, style anchors, and series context
2. The draft is paragraph-numbered automatically
3. The user writes annotations (PROBLEM+DIRECTION, PRESERVE, GLOBAL) targeting specific paragraphs
4. The command assembles everything into a single self-contained prompt
5. The user copies the prompt into a powerful external model for single-shot revision
6. After review, annotate again and repeat — or run --compound to capture series learnings

Reference files:

• references/annotation-format.md — syntax and examples for writing annotations
• references/writing-revision-template.md — the fixed prompt template structure

Storage:

• Contracts: contracts/{series-name}.md
• Assembled passes: passes/{series-name}/pass-{N}.md

---

Context Curation Patterns

Pattern: Comparative Analysis

When the user wants to understand principles across systems:

• Gather 2-4 implementations of the same idea
• Present each fully and neutrally
• Include a factual comparison table (features, not judgments)
• Let the task be: "What are the underlying principles?" — not "Here are the principles, confirm them"

Pattern: System Diagnosis

When the user wants to improve a specific system:

• Include the full architecture (schema, protocol, templates, state management)
• Include the intended design AND observed problems (both factual)
• Name the symptom ("quality is inconsistent") not the cause
• Let the task be: "Analyze why" — not "Here's what's wrong, propose fixes"

Pattern: Domain Transfer

When the user wants to apply ideas from one domain to another:

• Include rich context for the source domain (where the ideas come from)
• Include enough context for the target domain (where they'd be applied)
• Name what's different about the target domain
• Let the task be: "How do these translate?" — not "Here's how they translate"

Pattern: Strategic Exploration

When the user wants to think through a new direction:

• Include the current state (what exists, what's working)
• Include the aspiration (where they want to go)
• Include constraints (what can't change, what's fixed)
• Let the task be: "What's the path?" — not "Here's the path, evaluate it"

Pattern: Post-Investigation Handoff

When the user just completed /investigate and wants a reasoning model's perspective:

• Pull from investigation artifacts first — gap maps contain pre-digested understanding (intent, state, gaps, decisions)
• Include the investigation's diagrams — translate Mermaid diagrams into text descriptions for the reasoning model
• Include relevant subsystem specs in full — the investigation identified which subsystems matter; inline those specs completely
• Include actual code for the focal areas — the investigation built a mental model; the reasoning model needs the code behind it
• Frame the problem using the user's own observations — their insights from the investigation are the best problem framing
• Let the task be: "Given this architecture and these gaps, what's the pragmatic path forward?" — not "Here's our plan, validate it"
• Bridge the abstraction levels: include spec (what it should be) + code (what it is) + gaps (what's missing) + intent (where we want to go)

Pattern: Recurring Technical Review

When the user wants periodic deep analysis of a project:

• Use compound-engineering knowledge artifacts as the stable profile (subsystem specs, architecture.yaml, ORCHESTRATOR.md)
• Gather dynamic context automatically (git log, Linear, tests)
• Short interview for current focus (1-2 rounds)
• Include review history from previous versions — the reasoning model should see the project's evolution
• Let the task be open-ended by default, narrowed only if the user specified a focus
• The profile compounds: each review's findings get summarized back into the next version's context

---

Common Mistakes

Mistake	Why It Happens	Fix
Naming patterns before the model finds them	You've already thought about it and want to share your framework	Convert named patterns to open questions: "What patterns emerge?"
Leading questions disguised as open ones	"Don't you think X is a problem?" feels open but isn't	Rewrite as: "Where are the weaknesses?"
Summarizing context instead of including it	Fear of prompt length	Reasoning models handle long context well. Include the actual schema, not "the system uses a YAML schema"
Prescribing output structure	Want a specific deliverable format	Give minimal section headers at most. "Structure however serves the ideas."
Including too many provocative questions	Each one narrows the model's search space	Pick the single best one. Let the model find the others.
Omitting the "what's not working" signal	Feels like complaining	The model needs to know what to focus on. Symptoms are context, not direction.
Gathering context from one perspective only	Only reading your own system	Include external references, alternative approaches, or the user's perspective alongside the system's design
Referencing without inlining	"See architecture.yaml for details" in the prompt	The reasoning model CAN'T see it. Inline the content or remove the reference.
Abstract descriptions instead of specifics	"The auth subsystem handles authentication"	Include the actual interfaces, invariants, and key code. The model can't reason about abstractions alone.
Missing dependency context	Including subsystem A but not what it depends on	The model needs B and C's contracts to understand A's constraints. Include dependency specs.

---

Relationship to Reasoning Craft

	Prompt Craft (this skill)	Reasoning Craft (existing)
Focus	Designing the question	Assembling codebase context
Output	A prompt file ready for a reasoning model	A structured context document + transform pipeline
Context source	Anything relevant (code, web, multiple systems)	Subsystem specs + Linear + git (fixed sources)
Output contract	Minimal — "structure however serves the ideas"	Rigid — Linear Hierarchy, Subsystem Updates, ADRs
When to use	Exploring new ideas, cross-domain analysis, open-ended questions	Known codebase questions with actionable output needed
Anti-pattern	Prescribing conclusions	N/A (mechanical assembly)

Use prompt-craft when you want the reasoning model to discover. Use reasoning-craft when you want it to plan.