Shorthand prompt systems

Working with Claude on Projects

Chapter 4 · Shorthand Prompt Systems — Designing Your Own Prompt Maps

A shorthand prompt system turns a complex, context-heavy task into a single short trigger. Instead of typing a multi-paragraph prompt every time you want a course chapter, you type vpn3 — and Claude knows exactly what to produce, in what format, to what standard. This chapter explains how to design one that actually works, using the system powering every chapter in this course as a live example.

What a Shorthand System Is

A shorthand prompt system is a mapping from a short trigger (a word, a code, a number) to a complete, detailed task specification that lives in your project's memory. When you send the trigger, Claude looks up the specification in memory and executes it — without you having to repeat any context.

It has three layers:

The trigger

What you type — short, memorable, consistent. vpn3, Bash I 7, rdesk4, pi2. No context, no explanation — just the code.

The memory file

A memory file Claude loads when it sees the trigger — containing the full specification: what to produce, the format, styling, file naming, output location, and any automatic follow-up steps.

The output

A complete, correctly formatted deliverable — HTML chapter, SQL script, PDF, or whatever the task produces — generated without clarifying questions.

The key insight: you invest in the specification once, in the memory file. Every subsequent use costs you only the trigger. The longer a course runs, the more value the system pays back.

A Real Example — This Project's Course System

Here's the actual prompt map for the VPN course:

vpn1

→

What is a VPN and why — use cases, what a VPN does and doesn't protect

vpn_lesson_01.html

vpn2

→

VPN protocols compared — OpenVPN, WireGuard, IKEv2/IPsec, L2TP

vpn_lesson_02.html

vpn3

→

WireGuard server — install on Linux, generate keys, wg0.conf, systemd

vpn_lesson_03.html

⋮

vpn8

→

Troubleshooting & hardening — DNS leaks, kill switches, MTU, logging

vpn_lesson_08.html

Each trigger expands into a full chapter — correct styling, correct file name, correct format, next-chapter teaser at the end — because the memory file holds the complete specification for what a "VPN chapter" means. Claude doesn't guess: it follows the spec.

Designing Your Own System — Step by Step

Identify the recurring task

What do you produce repeatedly where each instance follows the same pattern? Course chapters, weekly reports, meeting notes, changelog entries, commit message templates, API endpoint stubs. If you've done it more than three times in the same format, it's a candidate.

Define the full specification

Write down everything Claude would need to produce the output without asking you anything: the format, the structure, the styling, the file naming convention, the output location, any automatic follow-up steps, and what varies between instances (usually just the topic or number).

Choose a trigger scheme

Pick short, memorable, collision-free triggers. prefix + number works well for sequences (vpn1–vpn9). prefix + keyword works for non-sequential tasks (report weekly, standup). Avoid triggers that could be confused with normal words.

Write the memory file

Create a project memory file that contains the complete specification, the trigger table, and any global rules (styling, format, automatic behaviours). Use the standard frontmatter format so Claude can find it.

Add to MEMORY.md

Add a one-line entry to MEMORY.md with a specific hook so Claude knows when to load it: "VPN course outline and shorthand prompt map (vpn1–vpn9)" — specific enough that Claude loads it when it sees vpn triggers.

Test and refine

Run the first trigger. If the output misses something, update the memory file — not just the current prompt. The fix should be in the spec, so every future instance benefits. Build in the feedback from the first few uses before relying on it heavily.

What Goes in the Specification Memory File

---
name: vpn-course
description: VPN course outline, shorthand prompt map (vpn1–vpn8), styling spec
metadata:
  type: project
---

# VPN Course

## Styling
- Fragment HTML (no DOCTYPE/html/head/body)
- Background: #0d1117 / surface: #161b22
- Accent: #22c55e (green), h3 color: #86efac
- Class: vpn-lesson

## File naming
vpn_lesson_NN.html  (e.g. vpn_lesson_03.html)

## Automatic behaviours
- End every chapter with a next-chapter teaser box
- Generate PDF automatically with the final chapter
- Ask for subtopic_id and page_id before generating SQL

## Prompt map
| Trigger | Topic                                              | Status |
|---------|----------------------------------------------------|--------|
| vpn1    | What is a VPN and why                              | ✅     |
| vpn2    | VPN protocols compared                             | ✅     |
| vpn3    | WireGuard server setup                             | ✅     |
| vpn4    | WireGuard clients                                  | ✅     |
| vpn5    | OpenVPN server setup                               | ✅     |
| vpn6    | OpenVPN clients                                    | ✅     |
| vpn7    | Commercial VPN clients                             | ✅     |
| vpn8    | Troubleshooting and hardening (final chapter)      | ✅     |

Notice what's in the spec: styling rules, file naming, automatic behaviours, and the full topic list with status tracking. Claude reads all of this from the single memory file trigger — you typed two characters to get a chapter that follows all of it.

Trigger Design Patterns

Sequential series

vpn1, vpn2 … vpn8 bash1, bash2 … bash12 proj1, proj2 … proj8

Best for courses, tutorials, numbered reports. The number tells Claude exactly which item in the sequence to produce.

Prefix + keyword

report weekly report monthly standup retro

Best for recurring documents that aren't numbered. The keyword selects the variant; the prefix routes to the right memory file.

Multi-level prefix

Bash I 1 … Bash I 12 Bash A 1 … Bash A 12 CSS 1-1 … CSS 12-4

Best when you have families of related sequences. The first prefix identifies the family; the second identifies the variant within it.

Single-word actions

progress diary consolidate

Best for meta-tasks about the project itself — status reports, diary generation, memory maintenance. Each maps to a full procedure in memory.

Common Problems and Fixes

Problem	Cause	Fix
Claude asks for clarification on a trigger	The memory file description isn't specific enough for Claude to load it confidently, or MEMORY.md hook doesn't mention the trigger prefix	Update the MEMORY.md entry to include the trigger prefix explicitly: "VPN course (vpn1–vpn8)"
Output drifts from spec over a long course	The styling or format spec in memory is ambiguous — Claude interpolates slightly differently each chapter	Add a concrete example to the spec (e.g. paste the exact CSS) rather than describing it in words
Trigger collides with a normal word	Claude treats the trigger as a regular word and responds to it literally	Choose more distinctive triggers — codes rather than words. `pi2` not `pi`, `rdesk3` not `rdp`
Automatic follow-up steps missed	The automatic behaviour rule is buried in a long memory file and doesn't carry enough weight	Move automatic rules to CLAUDE.md where they're loaded every session, not just when the course memory file is loaded
Status tracking goes out of date	The ✅/⬜ status table isn't updated after each chapter is generated	Include updating the status table as part of the post-chapter procedure — Claude should update it alongside the memory file after each chapter

Beyond Courses — Other Uses for Shorthand Systems

The same pattern works for any recurring task with a consistent format:

Weekly status reports — report expands to: pull from last week's notes, format as Markdown with sections for Done / In Progress / Blocked / Next week, save to reports/YYYY-WW.md
API endpoint stubs — endpoint GET /users expands to: FastAPI route with type hints, Pydantic schema, docstring, and test stub in the right file location
Language lesson generation — jp12 expands to: Japanese lesson 12, specific vocabulary format, dialog structure, hiragana annotations, saved to the right directory
Code review checklists — review security expands to: a security-focused checklist applied to the current diff, with specific items for OWASP top 10
Commit message drafts — commit expands to: run git diff, summarise changes, produce a conventional commit message in the project's style

The compounding return

A shorthand system gets more valuable the longer you use it. Chapter 1 of a course benefits from the spec. Chapter 10 benefits from the spec plus nine chapters of refinement you've baked back in. By the end of a long course, you type four characters and get a perfectly formatted, consistently styled chapter every time. That's the payoff.

Next — Chapter 5: Multi-Session Workflows
Picking up where you left off, managing context across many sessions, understanding how context summarisation works, and strategies for keeping long-running projects coherent over weeks and months.