Prompt Engineering Fundamentals
The prompting craft that every other module runs on. Keep this open.
Module Overview
Module 3 is the prompting craft that every other module runs on. You learn to treat a prompt as a specification — Role, Context, Task, Format, Constraints — and to refine iteratively instead of re-rolling. The same techniques apply whether you’re drafting a BRD, breaking down tasks, or generating code, and they transfer across any AI tool. Keep this handbook open during every other module.
| At a glance | |
|---|---|
| Covers | Prompt structure (Role + Context + Task + Format + Constraints); few-shot, chain-of-thought, least-to-most; the refinement loop; turning a prompt into a reusable agent; cross-tool portability |
| When it runs | Week 1 Monday (in-person), alongside Module 2 |
| Builds on | Module 2 (the artifacts you’ll prompt for) |
| Leads into | Every later module — this is the underlying craft |
What you'll produce
A set of refined, reusable prompts in your role’s area and your first prompt-to-agent conversion — committed to your project’s knowledge/prompts/{role}/, ready to use throughout Weeks 1–3.
How to Use This Handbook
Module 3 is not a module you finish and put away. It is the prompting craft that every other module depends on. Module 2 has you draft a BRD and PRD; Module 4 has you manage long sessions; Module 5 has you implement code; Module 6 has you build agents. Every one of those is prompting. This handbook is the reference you keep open while doing all of them.
A supplement, not a standalone deliverable
Modules 2, 4, 5, and 6 produce artifacts (BRD, PRD, architecture, code, agents). Module 3 produces no artifact of its own — it makes the artifacts in every other module better. Treat the techniques here as best practices you apply across the whole program.
Where Each Technique Gets Used
| Technique | Where you apply it downstream |
|---|---|
| Role + Context + Task + Format + Constraints | Every prompt, every module — BRD/PRD drafting (M2), implementation (M5), agent system prompts (M6) |
| Chain of thought | Architecture decisions and debugging (M2, M5) |
| Least-to-most decomposition | PRD generation, large refactors, messy requirement cleanup (M2, M5) |
| Few-shot examples | Matching a team format — test stubs, user stories (M2, M5) |
| Iterative refinement (the cycle) | Every artifact in every module |
| Prompts → agents → skills | Building reusable assets (M6); context isolation (M4) |
Part 1 — The Prompt Structure
Your go-to structure for any serious prompt. Five parts. Once it’s automatic, your output quality jumps.
| Part | What it does | Example |
|---|---|---|
| Role | Sets the expertise and lens | “You are a senior backend engineer reviewing for security.” |
| Context | Provides relevant background | “This is a Python Flask API handling user authentication.” |
| Task | States exactly what you want | “Review the following function for SQL injection.” |
| Format | Describes the output shape | “List each issue with line number, severity, and fix.” |
| Constraints | Sets boundaries | “Focus only on security, not style or performance.” |
The Same Task, Three Levels
Minimal: "Review this code."
→ vague, unfocused output
+ Role: "You are a security reviewer. Review this code."
→ better focus
+ Format: "...List each issue with severity and fix."
→ structured, actionable output
What Makes a Prompt Weak
| Weakness | Fix |
|---|---|
| Vague (“make it good”) | Be specific about what “good” means — measurable, observable |
| Missing context | Provide the background the AI needs to ground its answer |
| Conflicting instructions | Remove contradictions; one clear direction |
| No expected output | Describe the format and structure you need |
Part 2 — Core Techniques
Zero-Shot vs Few-Shot
Zero-shot: ask directly, no examples — works for common tasks. Few-shot: provide 2–5 example input/output pairs — use when you need a specific pattern or format matched (test stubs in your team’s style, user stories in a fixed shape).
# Few-shot: give the pattern, then the real input
Generate a unit test stub in this format:
Example 1:
Input: function add(a, b)
Output: test('add returns sum', () => { ... })
Example 2:
Input: function isEven(n)
Output: test('isEven detects even numbers', () => { ... })
Now generate one for: function parseDate(str)
Chain of Thought
Instruct the model to reason step-by-step before answering. Use for complex problems: debugging, architecture decisions, analysis.
Direct: "Should we use REST or GraphQL for this API?" Chain of thought: "Think through this step by step. 1. List the client consumers. 2. Evaluate data fetching patterns. 3. Assess team expertise. 4. Recommend REST or GraphQL with justification."
Least-to-Most Decomposition
Break a complex task into sub-tasks, solve each in sequence. Each output feeds the next prompt. Use for complex features, multi-step refactors, and long documents — this is the technique behind the BRD/PRD work in Module 2 and the messy-requirement cleanup.
# Least-to-most for PRD generation Step 1: "Generate a PRD outline for user authentication." Step 2: "Expand section 2.1 with 5 concrete user stories." Step 3: "For each user story, add acceptance criteria." Step 4: "Review the complete PRD and flag any gaps."
Delimiters & Output Formatting
Separate instructions from content with triple backticks, XML tags, or ---. Ask for structured output (JSON, Markdown tables, YAML). Delimiters also reduce prompt-injection risk.
Negative Prompting
Tell the model what NOT to do — sparingly. Too many negatives confuse it; prefer positive framing where you can.
Do not suggest Django. Do not use deprecated Python 2 syntax.
Part 3 — Iterative Refinement Is the Cycle
First drafts rarely produce final quality. Iteration is normal, not failure. The Evaluate → Plan → Apply → Validate cycle from Module 2 IS prompt refinement — here’s how it maps.
| Step | In prompt refinement |
|---|---|
| Evaluate | Review the output. Is it grounded in the spec? Does it hit the quality bar? Name the specific gap. |
| Plan | Decide what to change. Vague dissatisfaction produces vague next prompts. Change one thing at a time. |
| Apply | Refine the prompt and re-run. Is context missing? Task unclear? Format wrong? |
| Validate | Compare new output against the quality bar. Did it improve? Could it improve further? |
Three failed refinements = something structural
If you’ve refined three times and it’s still wrong, stop. The problem isn’t the wording — it’s missing context or an unclear task. Restart with a cleaner prompt and fresh context. (Module 4 teaches how to diagnose and recover surgically.)
The Refinement Drill
Practice the loop on any task. Document each refinement and why it helped — the refined prompt becomes a team asset.
v1: "Summarize this article."
→ too long, no focus
v2: "Summarize this article in 5 bullet points,
focused on the security implications."
→ better, but missing the recommendation
v3: "...in 5 bullets on security implications,
then one sentence on what we should do next."
→ hits the bar. Save this prompt.
Part 4 — From Prompts to Agents to Skills
Once you’ve written a great prompt, the next question is how to reuse it without retyping. Three layered customization mechanisms. You’ll see the map here; you build them hands-on in Module 6.
| Layer | What it is | Use when |
|---|---|---|
| Rule | Always-on guidance the AI sees at the start of every conversation | The guidance applies to every prompt (coding standards, output format, security policy) |
| Agent | A named, scoped, reusable role with its own system prompt | You have a recurring scoped role (code reviewer, BRD reviewer) to invoke by name |
| Skill | Packaged domain expertise loaded dynamically when relevant | Expertise that should load only when needed — not bloat every prompt |
| Prompt template | A reusable instruction shape that varies by parameters | A reusable shape lighter than an agent (test-from-AC, code-from-task) |
The portable artifact is a markdown file
All three layers — rules, agents, skills — are markdown files with YAML frontmatter + a system prompt body. That portability is the point: commit to the repo, version-control, peer-review, and port across AI tools. The convention is to organize them in your project under knowledge/agents/, knowledge/rules/, knowledge/prompts/, and knowledge/patterns/.
Example: An Agent Markdown File
# knowledge/agents/code-reviewer.md --- name: code-reviewer description: Reviews code for quality, security, and AGENTS.md compliance. tools: Read, Grep, Glob --- You are a code reviewer. When invoked, analyze the code and provide actionable feedback on: 1. Security (SQL injection, auth bypass, exposed secrets) 2. Rule compliance (validation, error format, soft delete) 3. Logic correctness (edge cases, off-by-one, missing await) Format: severity (critical/high/medium/low), line, issue, fix. Do NOT comment on style or formatting.
Part 5 — Prompt vs Agent: See the Difference
Stratpoint’s Ultimate AI Agents library has ready-made agents you can use right now to compare your manual prompt output against agent-assisted output. Two are directly relevant to your Week 1 deliverables.
| Agent | Produces |
|---|---|
| solarch-brd-generator | BRDs with module-based functional requirements, source traceability, MoSCoW prioritization, and built-in self-validation. Enforces the Module 2 BRD quality bar. |
| product-manager | PRDs with a 5-section structure, testable acceptance criteria in Given/When/Then format, and a completeness checklist. |
The Comparison Exercise
Take the same task — a BRD section or PRD user stories from the sample project’s inputs in source-docs/. First write your own prompt using Role + Context + Task + Format + Constraints and run it. Then run the same task through the agent. Compare side by side: structure, completeness, traceability, quality-bar alignment. The gap is what a well-designed agent gives you for free, every session, without re-prompting.
How to access
Browse agents and usage instructions at https://ultimate-ai-agents.stratpoint.io/browser.
Copy the relevant system prompt into your AI tool, then adapt it to your project. You’ll build your own agents in Module 6 — for now, use these to see what the destination looks like.
Part 6 — Same Craft, Any Tool
The structure and techniques are universal — properties of how language models work, not features of any product. They work in Claude Code, OpenCode, Gemini, ChatGPT, Cursor, and whatever comes next. Only the customization mechanics differ.
| Layer | Claude Code | OpenCode | Cursor | Gemini (Workspace) |
|---|---|---|---|---|
| Rules | CLAUDE.md + AGENTS.md | AGENTS.md (auto-loaded) + opencode.json | .cursor/rules/*.mdc + AGENTS.md | Gem instructions field |
| Agents | .claude/agents/{name}.md, auto-delegated | .opencode/agents/{name}.md or opencode.json; @-invoked subagents | .cursor/commands/ | Gems (UI) |
| Skills | .claude/skills/{name}/SKILL.md | .opencode/skills/{name}/SKILL.md | SKILL.md (open standard) | Knowledge files on a Gem |
AGENTS.md is the cross-tool rules standard
Write your project’s foundational rules in AGENTS.md so they apply across whatever tool a teammate uses (read by Claude Code, OpenCode, and Cursor). Layer tool-specific files (CLAUDE.md, opencode.json, .cursor/rules/) only for overrides. SKILL.md is also an open standard — skills you write are portable too. Write once, port everywhere.
Practice
These drills build the reflex. Do them on the sample project, then apply the same moves to your real Week 1 work.
Drill 1 — Bad Prompt to Good
Start with “Write some code to sort stuff.” Rewrite using Role + Context + Task + Format + Constraints. Run both, compare outputs, write down what specifically improved.
Drill 2 — Few-Shot Pattern Matching
Generate 10 unit test stubs in your team’s format. Try zero-shot first, then few-shot with 2 examples. Reflect: when does few-shot help, when is it overkill?
Drill 3 — Chain of Thought Debug
Take a buggy snippet. Try “What’s wrong with this code?” then a CoT version: (1) identify inputs, (2) trace execution, (3) find the bug, (4) suggest fix. Compare thoroughness.
Drill 4 — Least-to-Most on a Messy Requirement
Below is a messy stakeholder email — the kind of raw input a real BRD starts from. Decompose the cleanup into 4–6 sub-tasks (extract stakeholders, list functional needs, separate constraints, flag ambiguities, draft requirements), execute the chain one step at a time, then compare your structured output against the reference BRD/PRD in source-docs/demo-output/. Save the chain — it’s reusable for any future stakeholder cleanup.
From: Operations Lead Subject: the leave thing we talked about Hey — so we really need to sort out leave requests, right now it's all email and a spreadsheet and nobody knows what's approved. Managers complain they get blindsided. HR says we have a compliance problem because there's no record of who approved what. Employees just want to see their balance without asking HR every time. Oh and it has to work on phones I think? Some people don't have laptops. We have like 800 staff. Legal mentioned something about keeping records for years. Can we get this done before the audit in Q3? Also managers should only see their own team, not everyone. Thanks!
Drill 5 — Convert a Prompt into an Agent
Take your best prompt from Drill 1 or 4. Using knowledge/agents/code-reviewer.md as a template, create an agent file: name (kebab-case), description, tools, system prompt body. Save under knowledge/agents/{your-role}/. Reflect: what did you keep, what did you generalize, what’s now reusable?
Contribute back
Identify the 3 most reusable prompts you wrote and commit them to knowledge/prompts/{your-role}/ with title, purpose, template, example output, and notes. Every wave contributes back — that’s how the organizational prompt library compounds.
Self-Check
- I can write structured prompts using Role + Context + Task + Format + Constraints.
- I know when to use zero-shot, few-shot, chain of thought, and least-to-most.
- I can diagnose poor AI output and refine prompts one change at a time.
- I recognize when three failed refinements mean it’s a context problem, not a wording problem.
- I understand the difference between rules, agents, and skills, and when to use each.
- I can convert a strong prompt into a reusable agent markdown file with proper frontmatter.
- I’ve compared my manual prompt output against the solarch-brd-generator and product-manager agents.
- I understand the prompting craft and the markdown-as-portable-artifact pattern transfer across any AI tool.
- I’ve contributed at least 3 reusable prompts to knowledge/prompts/.