Arsenal of Prompts: 6 reusable modes

Time: about 25 min theory + 40 min practice

The gist

Most people write prompts like throwaway notes. Task, prompt, answer, toss it. A week later a similar task comes up, and they write the prompt all over again. A month later, again. The quality is different every time, because the wording is slightly different.

That's working without an arsenal. Every fight starts from scratch.

The Arsenal of Prompts is a different approach. You invest an hour once in writing up a mode. From then on, one short command switches Claude into that mode. The same standards, the same discipline, the same output. Not "write it better," but "switch into editor mode."

In this lesson we'll go through 6 ready-made prompt modes from the course author's working arsenal: writer, editor, debug, research, architect, ADR. And most importantly, how to build your first prompt mode for a task you do often.

🎨 Picture this: a prompt mode is a hat you put on Claude's head. A chef's hat, and it cooks. A judge's wig, and it judges. A surgeon's cap, and it operates. It's the same Claude, but in each hat it behaves differently. You have 6 hats on the shelf: grab the one you need, put it on, get to work.

Key concepts

• Prompt: a one-off request for one task. Write it, get the answer, toss it
• Prompt mode: a reusable pattern you activate when you need that way of working. The wording lives in a file, not in the chat
• Activation phrase: a short key phrase ("use writer-mode", "activate Debug Mode") that turns the mode on
• Prompt body: system-level instructions inside the mode: role, rules, formats, anti-patterns
• Severity diff: the output format of editor-mode: 🔴 critical / 🟠 high / 🟡 medium / 🟢 low, a prioritized list of edits
• Karpathy 5-step: the systematic debugging methodology behind debug-mode: reproduce → isolate → hypothesis → fix → verify
• Versioning: writer-mode-v1.md, writer-mode-v2.md. v2 doesn't break things for users who stayed on v1
• Pipeline v1 → v2 → skill: after 5+ uses, a mode evolves into a full .claude/skills/ skill
• Applicable agents: each mode is tied to the subagents that carry it out best (writer-mode → writer/editor/content-strategist)
• Arsenal vs ad-hoc: an arsenal = modes prepared in advance. Ad-hoc = writing a prompt from scratch every time. An arsenal is faster and more consistent in quality

Theory

How a prompt mode differs from a regular prompt

A regular prompt lives in the chat. Write it, send it, forget it. The next day a similar task comes up and you word it all over again. Same Claude, but the quality of the answer swings noticeably because the words are slightly different.

A prompt mode lives in a file. It's a document with a fixed structure:

• Name and version (writer-mode-v1)
• When to use it (When to use)
• Activation phrase ("use writer-mode")
• Prompt body: a big block of text that you copy into the chat or that a subagent loads
• Output format: what Claude should return
• Anti-patterns: where it must not go

You activate it with one short phrase. From then on Claude works by fixed rules. Not "write well," but "write in writer-mode v1," and the mode brings along 200 lines of discipline: voice, formats, vetoes, imagery, an anti-assumption rule.

🎨 Picture this: a regular prompt is a note to the waiter on a napkin. A prompt mode is a recipe in the restaurant's cookbook. The note gets thrown out after the meal. The recipe gets opened every time someone orders the dish.

Anatomy of a prompt mode (the general template)

All 6 modes in this arsenal are built the same way. That makes them reusable: learn to read one, and you can read any of them.

---
id: writer-mode-v1
title: "Writer Mode v1 · Brand-voice content creation"
purpose: "Why this mode exists"
audience: "Who activates it and how"
created: 2026-05-10
status: active
applicable_subagents: [writer, editor, content-strategist]
---

# ✍️ PROMPT · "Writer Mode" — v1.0

## When to use
— A list of situations where the mode applies

## How to use
— Modus 1: Direct invoke
— Modus 2: Through a subagent
— Modus 3: Hybrid

## [PROMPT TEXT — copy from here]
```
[A big block of text with rules, formats, vetoes, examples]
```

## Version history
— v1.0, v2.0 (planned), reasons for the changes

## Linked
— Related files (communication rules, principles, list of banned phrases)

What the PROMPT TEXT itself is made of (this is the key part):

1. ACTIVATION: who I am in this room (the role)
2. RULES: what I do and how
3. VETO: where I don't go
4. FORMATS: what structure I produce
5. ANTI-PATTERNS: typical mistakes I avoid
6. OUTPUT: what I hand over at the end
7. PERSONAL: calibration for a specific owner (plain language first, use imagery, no preambles)

This structure repeats in every mode. The content changes, the structure stays the same.

Mode 1 · Writer Mode: drafts in your brand voice

When to use it:

• Before writing a social media post / YouTube script / article / email
• When a draft sounds like someone else (puffed up, academic, coach-speak)
• As a preamble in the prompts of subagents (writer, editor, content-strategist)

What's inside:

• 6 voice rules: plain language first, use imagery, anti-assumption, directness, brevity, no preambles
• 6 veto categories: coach-speak, bragging, comparisons between cultures, complaining, fake urgency, biography
• 4 formats: social media post (80-300 words), YouTube script, article (4 paragraphs), email
• Before/after examples: a bad draft next to a good one

Applicable agents: writer, editor, content-strategist

Activation:

use writer-mode
write a social media post about <topic>

🎨 Picture this: writer-mode = your voice on paper. Any subagent wearing this hat writes as if you wrote it yourself. Not a blogger. Not a coach. Not a marketer. You.

Mode 2 · Editor Mode: voice review with a severity diff

When to use it:

• After the writer subagent: a mandatory second pass
• Before publishing any text to external channels
• Before committing Tier 1/2 documentation
• When you suspect drift (Claude or a subagent has wandered off course)

What's inside:

• 6 levels of checks: plain-language compliance, imagery present, anti-assumption, vetoed phrases scan (CRITICAL), readability, structure
• Severity scoring: 🔴 CRITICAL (publishing blocked) / 🟠 HIGH (strongly recommended) / 🟡 MEDIUM (improves quality) / 🟢 LOW (nice to have)
• Format for each issue: WAS / ISSUE / FIX / WHY
• An escalation protocol: when not to auto-fix and instead return the text to the author for a decision

Applicable agents: editor, code-reviewer

Output format (severity diff):

🔴 CRITICAL Line 12 · Coach-speak
WAS:    "This approach will unlock your potential"
ISSUE:  Vetoed phrase (banned list, item 5)
FIX:    "This approach makes you 20% faster"
WHY:    Specifics beat grandstanding

🎨 Picture this: editor-mode = the guardian of your DNA. Not a comma checker, not a censor. It protects the owner's voice from drift. It doesn't flatter with "this isn't bad, but...". It says it straight: "This breaks a rule. Replace it with this."

Mode 3 · Debug Mode: Karpathy's 5-step systematic debugging

When to use it:

• A bug in the code: a test fails, the app crashes, the output is wrong
• Strange behavior: "it worked yesterday, not today"
• A production incident: you need a cool head
• Before you "just restart it": laziness = debt

What's inside (5 steps, none skipped):

Step 1: REPRODUCE. Write a failing test BEFORE any fix. The test has to fail on the current code. No reproduction, no fix.

Step 2: ISOLATE. Bisect: where's the line between "works / doesn't work"? Eliminate variables (environment, data, state, dependencies). Find a minimal reproducer.

Step 3: HYPOTHESIS. At least 2-3 hypotheses. One hypothesis = bias. For each one, what experiment confirms or rules it out. Rank them by likelihood.

Step 4: FIX. A minimal diff. Do NOT "improve" neighboring code along the way (Karpathy Principle 3). Every changed line answers one of the hypotheses.

Step 5: VERIFY. The test from Step 1 passes. All other tests pass (no regression). Edge cases are tested. Confidence: HIGH/MEDIUM/LOW with a reason.

Applicable agents: code-reviewer, eng-manager Related skills: superpowers:systematic-debugging, engineering:debug

🎨 Picture this: debug-mode = a surgeon with an MRI. Not someone panicking at work. Not "I'll change this and give it a try." Reproduce → isolate → hypothesize → fix → verify. Every step documented.

Mode 4 · Research Mode: verified multi-source research for 2026

When to use it:

• Before a financial decision ($100+ spent on a tool/subscription)
• Before a decision with legal implications (compliance, regulations, contracts)
• Before a technology choice (LLM, hosting, payments, framework)
• When you sense a stale answer: Claude is quoting outdated training data
• During competitive analysis: you need current numbers

What's inside:

• Role: an investigative journalist in 2026, not Wikipedia
• 5 methodology rules:
  1. MINIMUM 3 SOURCES: WebFetch 3+ different sources. Single-source = AUTOMATIC LOW confidence
  2. FRESHNESS CHECK: priority to material from the last 12 months. Older than two years → flag it "(may be outdated)"
  3. CROSS-SOURCE SYNTHESIS: 2+ sources agree → HIGH, 1 source → MEDIUM, contradiction → LOW
  4. CONFIDENCE LABELS on every claim: HIGH/MEDIUM/LOW
  5. GAPS: what we DON'T know, and what's needed to close it

Output format: Executive Summary (5 sentences MAX) → Key Facts with confidence → Numbers table → Gaps → Caveats → Sources cited

Applicable agents: researcher, idea-scout, trend-watcher

🎨 Picture this: research-mode = an investigative journalist. Every fact verified by 3 sources. Every number with a date and a URL. Every gap documented honestly. Decisions based on facts, not hallucinations.

Mode 5 · Architect Mode: architectural decisions

When to use it:

• Before a creative session on a system's structure
• Before a strategic decision about the educational/infrastructure side
• When you sense Claude is answering at 8/10 instead of 10/10
• Before a quarterly review of the platform
• When designing a portfolio pattern (CORE + SHARED + PROJECTS)

What's inside:

• Activation: "I am the architect of my own educational future. I'm building a university that doesn't exist anywhere in the world yet."
• The system's known pillars: what's already there (for example: a knowledge library, learning paths, a prompt catalog)
• 10/10 stretch questions: what has to work for the result to be a 10 twelve months from now
• Anti-patterns: the academic model, copying someone's UI, overengineering without real work
• Output: 5-7 elements of a 5th pillar + 3 long-term elements (2-3 years) + 1 unfair advantage + 1 main risk

Applicable agents: architect, architect-reviewer, strategist

🎨 Picture this: architect-mode = the hat of someone building for 30 years, not for a quarter. Not a tradesman laying bricks. An architect who thinks: "if in 2 years I haven't upgraded the system 5 times based on what I've learned, where did I drop the ball?"

Mode 6 · ADR Template: Architecture Decision Records

When to use it (mandatory):

• Cross-namespace impact (CORE + SHARED, or CORE + 2+ PROJECTs)
• Irreversible or expensive to roll back
• Changing the project's foundational rules (what everything else rests on)
• A tech stack choice (LLM provider, infrastructure, framework)
• A financial commitment of $100+/month

When you don't need one: trivial config tweaks, bug fixes without architectural impact, reversible experiments.

ADR structure (after Michael Nygard + the course author's additions):

1. Status: PROPOSED / ACCEPTED / DEPRECATED / SUPERSEDED by ADR-YYY
2. Context: what's happening, what the constraints are, why now (2-4 paragraphs)
3. Decision: what was decided (one paragraph, a clear statement)
4. Alternatives Considered: a table of at least 3 options with pros/cons/cost/verdict (anti-zombification)
5. Consequences: positive / negative / risks / required follow-up
6. Cross-Namespace Effects: CORE/SHARED/PROJECT affected, detachability impact
7. Decision level: ordinary (made right away) or a change to the project's foundational rules (with a cooling-off pause, for example 7 days)
8. References: related ADRs, sections of the project plan, knowledge base materials, communication rules

File naming: journals/decisions/ADR-XXX-<slug>.md (zero-padded sequence, kebab-case slug)

Applicable agents: architect, architect-reviewer, strategist

🎨 Picture this: an ADR = the minutes of a board meeting. Five years from now you open the folder and see: "here's why we chose Cloudflare Workers over AWS Lambda. Here are the alternatives. Here's what we signed off on." The system's memory, which doesn't get lost in chats.

Versioning: why v1 doesn't break things for users

One of the main principles of the arsenal: a mode has its version in the file name.

writer-mode-v1.md is version 1.0. People used to v1 keep using v1. writer-mode-v2.md is the next version. It doesn't overwrite v1, it sits next to it.

Why:

• The mode can evolve without breaking existing workflows
• You can compare what v2 gives you over v1 (after 5+ uses it's usually clear)
• If v2 turns out worse, you roll back to v1 with no losses
• Subagents hard-wired to v1 keep working

Every mode follows the same evolution pipeline:

v1 (draft) → used 1-2 times → adjustments → v1.x
            → used 5+ times → failure cases are clear → v2.0
            → used 10+ times, stabilized → upgrade to .claude/skills/<mode>/

From a prompt mode in a file to a full skill in .claude/skills/. That's the natural trajectory. First text in markdown, then a structured skill with tool integrations.

🎨 Picture this: versioning = layers of sedimentary rock. Each version is a separate layer. You see the history of how it evolved and understand why the mode is the way it is now. Not "rewrote it and forgot," but "v1 is alive, v2 is next to it, and in a year v3 will sit beside them both."

Comparison table: which mode when

🧪 Practice

Step 1 · Read 2 ready-made modes

Reread the descriptions of two of the modes above (10 minutes):

• Writer Mode: the most universal, for content
• Debug Mode: the one that builds the most discipline, for debugging

The finished mode files live in the course author's working repository and haven't been published. So take the anatomy of a mode from the "Anatomy of a prompt mode" section and the template from Step 5: with those you'll build the same kind of mode yourself. The activation phrases from this lesson ("use writer-mode", "Activate Debug Mode") work when the mode file is in your project and Claude can read it, for example if you saved it as a skill in .claude/skills/ or referenced it in CLAUDE.md.

Notice the structure: every mode has the same anatomy (When → How → PROMPT TEXT → Version → Linked). That's no accident: a reusable structure makes them fast to read.

Step 2 · Activate writer-mode on a real task

Take a real task, for example writing a short post about a tool you use.

In Claude Code:

use writer-mode
write a social media post (120 words) about cron in Cloudflare Workers

Claude should:

1. Read the writer-mode file in your project (if you don't have one yet, build it first using the template from Step 5)
2. Apply the 6 voice rules
3. Avoid the 6 veto categories
4. Return a post in the social post format (80-300 words max, a hook in the first line, an image, a strong closing line)

Compare the result with an ad-hoc prompt: "write a post about cron in Cloudflare." The difference in discipline is noticeable from the very first use.

Step 3 · Run editor-mode on someone else's draft

Find any text by someone else (an article, a post, an email) whose style annoys you. Copy it into a file called draft.md.

run editor mode on the file draft.md

You'll get a severity diff:

• 🔴 CRITICAL: vetoed phrases that absolutely have to go
• 🟠 HIGH: missing imagery, or jargon where plain English belongs
• 🟡 MEDIUM: passive voice, long sentences
• 🟢 LOW: stylistic polish

This isn't "rewrite it from scratch." It's a surgical breakdown by level. Use it when you need to understand "why does this text annoy me."

Step 4 · Run debug-mode on a bug

Pick a real bug in your code (or recall the latest one from git log). In Claude Code:

Activate Debug Mode
Symptom: <describe it>
File: <path:line>
Command to reproduce: <if you know it>

Claude will go through the 5 steps and return a report. The key thing to notice: it will NOT start changing code right away. First Reproduce (a failing test), then Isolate, then 2-3 Hypotheses. Only after that, Fix.

If you're used to debugging with "I'll change this and try running it," debug-mode will force some discipline.

Step 5 · Create your first prompt mode

This is the main exercise of the lesson. Find a task you do often, at least once a week, and write it up as a prompt mode.

Candidates (pick one):

• Code review of your own commits before pushing
• Turning a voice memo into a structured note
• Analyzing the week's metrics and drawing conclusions
• Going through PR comments and drafting replies
• Preparing for a client meeting

Create a file from the template:

mkdir -p ~/.claude/prompts/  # your local collection
touch ~/.claude/prompts/<your-mode>-v1.md

Content template:

---
id: <your-mode>-v1
title: "<Mode Name> v1 · <one-line purpose>"
purpose: "Why this mode exists"
audience: "Who activates it and how"
created: <YYYY-MM-DD>
status: active
applicable_subagents: [<if you use subagents>]
---

# <emoji> PROMPT · "<Mode Name>" — v1.0

## When to use
— Situation 1
— Situation 2
— Situation 3

## How to use
### Modus 1 — Direct invoke
"use <your-mode>" + describe the task

## [PROMPT TEXT — copy from here]

```
[ACTIVATION — who I am in this room]
<the role in one sentence>

[RULES — what I do]
1. <rule 1>
2. <rule 2>
3. <rule 3>

[VETO — where I don't go]
❌ <anti-pattern 1>
❌ <anti-pattern 2>

[FORMAT — what I hand over]
<output structure>

[PERSONAL — for calibration]
<plain language first, use imagery, brevity, no preambles>
```

## Version history
### v1.0 — <date>
- INITIAL — <why it was created>

### v2.0 (planned)
- After 5+ uses — refine based on what worked

## Linked
- <related files, principles, vetoes>

After 5 uses, move to v2. After 10, consider upgrading it to a full skill in .claude/skills/.

Step 6 · Build your arsenal gradually

Don't try to put together 10 modes at once. That'll just be a useless museum.

The rule: a new prompt mode is born only when you've already written the same thing ad-hoc 3+ times. That's the sign the task repeats and deserves to be pinned down.

In 6 months you'll have 5-8 modes you actually use. That's an arsenal. Not "100 ready-made prompts from the internet," but your own, built for your work, proven by use.

⚠️ Anti-patterns

❌ Writing v1 as the "final version" right away It's a draft. v1 = the first working version. After 5 uses you'll see what doesn't work. Don't try to write the perfect mode on the first go.

❌ Copying prompts from the internet Other people's prompts are other people's voices. They work for their tasks, not yours. Make your own. Outside prompts are inspiration, not a ready-made solution.

❌ One mode for everything A "universal mode" is provider lock-in, imposed on yourself. Six narrow modes beat one broad one. Narrow ones are more precise.

❌ Not versioning You overwrite v1 → you lose the history. A year later you don't understand why the mode works the way it does. v2 next to v1 is your insurance.

❌ Not filling in applicable_subagents Without this frontmatter, the mode is left hanging. With it, subagents can automatically load the relevant mode for a task.

❌ Coach-speak in the prompt body itself Motivational lines like "become the best version of yourself" or calls to leave your comfort zone are a loss. A prompt mode = a tool, not a motivational speech.

❌ Hiding negatives in the anti-patterns section If you know a failure case, write it down explicitly. You'll be grateful a year from now.

❌ A long PROMPT TEXT that nobody reads The point of a mode is discipline, not bulk. If a mode is over 300 lines, split it into 2 modes. One for writer, one for editor. Not one big "content-mode."

🔗 Related

• Subagents: specialized workers: applicable_subagents in the modes points to the subagents that carry out the mode
• Hooks: automatic rules in Claude Code: a hook that fires before a tool call can suggest the relevant mode based on file type
• What Skills are: the final stage of a mode's evolution: v1 text → v2 text → .claude/skills/<mode>/
• Debugging and self-repair: debug-mode builds directly on Andrej Karpathy's four principles for working with code, drawn from his observations

✅ Checkpoint

Before moving on to the next lesson, check yourself:

• You understand the difference between a prompt (one-off) and a prompt mode (reusable)
• You know the anatomy of a prompt mode: When → How → PROMPT TEXT → Version → Linked
• You can name the 6 modes from this lesson and when to use each one
• You understand why versioning matters (v1.md next to v2.md): backward compatibility
• You understand the evolution pipeline: v1 → v2 → skill
• You've activated at least one ready-made mode (writer/debug/editor) on a real task
• You've created your first prompt mode for a task you do often (Step 5 of the practice)
• You know the rule for building the arsenal: a new mode only after 3+ ad-hoc repeats

Sources

• The course author's arsenal of modes (a working repository, not published): 6 ready-made modes
  • writer-mode-v1.md: content creation in the brand voice
  • editor-mode-v1.md: voice review with a severity diff
  • debug-mode-v1.md: Karpathy's 5-step systematic debugging
  • research-mode-v1.md: verified multi-source research for 2026
  • architect-mode-v1.md: strategic architectural design
  • adr-template-v1.md: Architecture Decision Records
• Andrej Karpathy: four principles for working with AI-written code (the basis of debug-mode)
• Michael Nygard: the original ADR pattern (2011): cognitect.com/blog/2011/11/15/documenting-architecture-decisions
• Anthropic Prompt Engineering: guidance on system prompts and structured outputs
• The author's communication rules: a file with the communication style and a file with the list of banned phrases (writer-mode and editor-mode take their voice rules from these)
• superpowers:systematic-debugging: the skill that debug-mode complements
• The project's catalog of skills and prompts: the shared list where all 6 modes are collected