prompt-craft
Prompt Craft
Coverage
- Role and instruction layering: how to compose a system prompt that scopes the model's behaviour without over-constraining
- Context insertion order: where to put the task, the constraints, the examples, and the input — and why the order matters more than the content
- Few-shot example selection: when 0-shot is enough, when 1-shot is sufficient, when 3-5 shots are necessary, and when 10+ shots are a sign the prompt is wrong
- Output-format constraints: how to get strict JSON, strict Markdown, strict plain text, and how to recover when the model breaks the format
- Negative instructions: when "DO NOT do X" works, when it backfires (the X-mention reinforcement effect), and the principle of replacing prohibitions with positive specifications
- Chain-of-thought and reasoning prompting: when explicit reasoning improves accuracy, when it introduces noise, and how to budget reasoning tokens
- Adversarial-input awareness: how user-controlled content can attempt to subvert system instructions, and the defence patterns (delimitation, output validation, allowlists)
- Iterative improvement: the prompt-eval loop — measure baseline, change one thing, measure delta, keep or discard
- Provider differences: where Claude, GPT, Gemini, and open-weight models differ in their response to the same prompt structure
- The "prompt as program" mental model: prompts as executable specifications with deterministic-ish inputs and probabilistic outputs
Philosophy
A prompt is a specification, not a wish list. A good prompt is the smallest set of instructions that produces the correct output reliably. Brevity is not the goal — necessity is. Every sentence in the prompt earns its place by visibly improving outputs in eval runs; sentences that survive without justification are noise that the model has to pattern-match through.
More from jacob-balslev/skills
layout-composition
Use when deciding responsive page or screen structure: section order, scan pattern, grid/flex composition, breakpoints, viewport hierarchy, responsive media, and density. Do NOT use for user-goal decomposition (use `task-analysis`), navigation taxonomy (use `information-architecture`), visual polish (use `visual-design-foundations`), or component/token contracts (use `design-system-architecture`).
8context-graph
Use when designing or auditing the multi-graph context architecture of an AI-coding workspace: skill graph, document routing graph, memory index, script registry, and the cross-graph edges between them. Covers edge typing, orphan detection, connectivity health, deterministic graph synthesis signals, change-propagation checks, and drift or hub-and-spoke anti-patterns. Do NOT use for authoring one SKILL.md (use `skill-scaffold`), validating one skill (use `graph-audit`), live routing decisions (use `skill-router`), context-window budgeting (use `context-window`), or session load/drop choices (use `context-management`).
8visual-design-foundations
Use when designing or auditing visual craft: color palette, typography, spacing, elevation, rhythm, density, visual hierarchy, brand fit, contrast intent, and motion feel. Do NOT use for sign-system meaning (use `semiotics`), token/component architecture (use `design-system-architecture`), responsive structure (use `layout-composition`), or accessibility compliance (use `a11y`).
7project-knowledge-extraction
Use when extracting durable project knowledge from code, docs, issues, incidents, reports, screenshots, or conversations into reusable context such as skills, ADRs, glossaries, context docs, or memory. Do NOT use for writing a new skill contract (use `skill-scaffold`), maintaining library tooling (use `skill-infrastructure`), or generic documentation polish (use `documentation`).
6problem-framing
Use when a team is converging on solutions before agreeing on the problem, when a brief reads as a feature request, when symptoms and root needs are tangled, or when assumptions need surfacing before design work proceeds. Do NOT use for code-level bug triage, runtime failure diagnosis, or root-cause analysis of system errors — those are engineering investigation tasks, not design problem framing.
6ai-native-development
Use when reasoning about agent autonomy levels, designing auto-improve loops, evaluating AI-generated code quality, or measuring agent productivity in an LLM-assisted codebase. Covers Karpathy's three eras of software (1.0 explicit / 2.0 learned / 3.0 natural-language), the vibe-coding-vs-agentic-engineering distinction, the 0–5 autonomy slider with task-type recommendations, the one-asset / one-metric / one-time-box AutoResearch loop, Software 3.0 productivity metrics, and the documented quality regressions of ungated AI-generated code (the 'vibe hangover'). Do NOT use for choosing a specific autonomy-loop topology (use `agent-engineering`), for the per-prompt authoring discipline (use `prompt-craft`), or for reviewing the AI-generated code that comes out of a Software 3.0 workflow (use `code-review`).
6