Introduction
The AI Literacy Series taught you to get useful output from a model. This module is narrower and sharper: how to prompt so the output is a COMPASS artifact a reviewer will accept — a spec, a decomposition, an implementation plan — not a chat reply you'll rewrite.
The difference between a practitioner and a heavy chat user is that the practitioner stopped re-typing prompts. They build prompt assets: versioned, reusable prompts that reliably turn one artifact kind into the next.
What you'll be able to do by the end
- Apply structured prompting to each COMPASS transformation
- Shape output to the artifact schema instead of free-form prose
- Turn a prompt that worked once into a reusable, versioned asset
- Catch and fix prompt drift when models change
Prerequisite: AI Literacy Series — Guide 1 (Tool Use & Prompting). This module assumes the five-component prompt structure and the RAG-vs-fine-tuning distinction from there.
1. Structured prompting, applied to delivery
Recall the five components of a strong prompt: role, context, task, constraints, output format. For delivery work, two of them carry most of the weight.
Context is the upstream artifact. When you evolve a feature_request into a feature_specification, the request is the context — paste it whole, plus the constraints from Clarify and anything Observe surfaced. A spec generated without the research register will confidently invent the parts it can't see.
Output format is the artifact shape. Every COMPASS artifact has an expected structure. Don't ask for "a spec" — ask for the sections your team's specs actually have (problem, scope, acceptance criteria, non-functionals, open questions), in that order, with a revision-history block. The model fills a shape far more reliably than it invents one.
| Transformation | Context to paste in | Output format to demand |
|---|---|---|
| evolve (request → spec) | The full feature_request, Clarify constraints, Observe findings | Spec sections + acceptance criteria + open questions |
| decompose (spec → stories) | The accepted spec, fidelity level | N user stories, INVEST-shaped, each with acceptance criteria |
| plan (story → plan) | One story, the architecture decisions from Model | Step-by-step tasks with file-level changes + verification steps |
2. Tool- and function-shaped outputs
A COMPASS artifact is consumed by the next phase — often by another agent. That makes it a structured payload, not a human essay. Two consequences:
Prefer schema-shaped output. When an artifact (or the metadata around it) will be parsed, lean on structured-output / JSON-mode features rather than asking nicely for clean formatting. A decomposition that should produce N stories is exactly the kind of task where a schema beats prose — you get N well-formed stories instead of a paragraph you have to split by hand.
Decompose the work, not just the prompt. Asking one prompt to "evolve this request into a spec, then decompose it into stories, then plan the first story" produces three mediocre artifacts. Run one transformation per prompt, review the output, and feed the accepted artifact into the next. This mirrors COMPASS itself: one phase, one gate, one artifact at a time.
Why ATLAS's assistant proposes rather than writes The in-app assistant never edits state directly. It emits a structured proposal card — a shaped, reviewable artifact — that you inspect, edit, and Apply. That's structured output as a safety pattern: the human stays the approver, and the output is already in artifact shape.
3. From one-shot to prompt assets
Most prompts go from acceptable to good after three or four iterations. If you throw that work away every time, you pay the iteration cost on every feature. Don't.
A prompt asset is a prompt you've tuned for one job, saved somewhere durable, and treat like code:
- One asset per transformation. A "request → spec" asset, a "spec → stories" asset, a "story → plan" asset. Each encodes your team's house structure and quality bar.
- Versioned. Keep it in the repo (
prompts/or a team wiki), not in your scrollback. When you improve it, that's a new version everyone gets. - Parameterised by the artifact, not the feature. The asset takes "the upstream artifact" as a slot; it works across every Journey.
The payoff compounds: the tenth feature reuses the prompt the first nine features debugged. That's the difference between AI as a personal speedup and AI as part of the team's operating model.
4. Prompt drift across model versions
Prompts are written against a model's behaviour, and that behaviour changes when the model upgrades. A prompt that needed an explicit "think step by step" might not need it on a newer reasoning model; a format hack that worked around an old quirk might now cause one.
Keep a tiny evaluation habit:
- Keep a few golden inputs per asset. Three or four real upstream artifacts with known-good outputs.
- Re-run after a model upgrade. Did the spec still come out with all the sections? Did the decomposition still produce well-formed stories?
- Edit the asset, don't patch with follow-ups. If the output regressed, fix the saved prompt (a new version), don't nurse it with one-off corrections that won't be there next time.
The habit in one line Treat each prompt asset like a small program with a test: a handful of golden inputs, re-run on every model change, fix at the source.
Exercise — build a "request → spec" asset
- Take a real (or realistic) one-paragraph feature request.
- Write a prompt with all five components: role (a senior product engineer), context (the request + two constraints), task (evolve into a specification), constraints (fidelity = Definition; flag unknowns rather than inventing them), and output format (your team's spec sections + a revision-history block).
- Run it. Note what's missing or wrong. Edit the prompt, not the output. Run again.
- After it's good, strip the specific feature out and leave a
{{feature_request}}slot. Save it asprompts/evolve-request-to-spec.md. You just built your first prompt asset.
The first time you reuse it on a different feature and it just works — that's the moment prompting becomes leverage instead of labour. Module 03 takes the artifacts you're now producing and puts them into ATLAS cleanly.