/
Prompt Engineering for Developers - One Sheet

Prompt Engineering for Developers - One Sheet

This training shows how to turn prompts from one-off requests into structured, reliable systems that guide how an AI thinks, decides, and executes.

By the end, you’ll know how to:

  • Shape output with personas and examples

  • Guide reasoning and decisions explicitly

  • Make prompts reusable with parameters and checklists

  • Break complex work into clear, multi-step workflows

All you need to get started is access to an LLM (preferably GitHub Copilot) and an idea for a prompt!

Environment Setup

  • Open GitHub Copilot in Agent Mode for a best in class experience

    • (Optionally) use your LLM chat bot of choice

  • Choose a prompt you want to build step-by-step

    • We’ll be walking through a prompt for generating a feature requirement, but the principles apply to all prompts.

    • TIP: Make the prompt something you can iterate on quickly so you can test each technique before time runs out.

  • Run the most basic version of the prompt and analyze the output

Basic Prompt

Generate a short requirements document for a todo list in output.md.

1. Personas

You are a PRODUCT OWNER at an AVIATION COMPANY that writes software for PILOTS. Generate a short requirements document for a todo list in output.md that will be implemented by a JUNIOR REACT DEVELOPER. Emphasize COMPLIANCE.
You are a PRODUCT OWNER at an AVIATION COMPANY that writes software for PILOTS. Generate a short requirements document for a todo list in output.md that will be implemented by a SENIOR BACKEND C++ ENGINEER . Emphasize SECURITY.

2. Few Shot

You are a PRODUCT OWNER at an AVIATION COMPANY that writes software for PILOTS. Generate a short requirements document for a todo list in output.md that will be implemented by a SENIOR BACKEND C++ ENGINEER . Emphasize SECURITY. The document should be output with the following sections: Overview - Functional Requirements - Non-Functional Requirements - Open Questions Each requirements should be given an ID (ex. TODO-1, TODO-2, etc.) Additional rules: - Requirements should be written testably (avoid vague terms like “easy” or “fast” without thresholds). - Do not include implementation code or specific libraries; focus on what must be true.
You are a PRODUCT OWNER at an AVIATION COMPANY that writes software for PILOTS. Generate a short requirements document for a todo list in output.json that will be implemented by a SENIOR BACKEND C++ ENGINEER . Emphasize SECURITY. The document should be output in a JSON format with the following structure: ```json { "document": { "title": "To-Do List Application Requirements", "version": "1.0", "status": "draft", "lastUpdated": "2025-01-01" }, "overview": { "purpose": "Define the functional and non-functional requirements for a basic To-Do List application.", "scope": { "inScope": [], "outOfScope": [] } }, "definitions": [ { "term": "Task", "definition": "A single unit of work tracked by the application." } ], "requirements": { "functional": [ { "id": "FR-1", "title": "Create Task", "description": "The system shall allow the user to create a new task.", "priority": "high", "acceptanceCriteria": [ "User can enter a task title", "Task is added to the task list" ] } ], "nonFunctional": [ { "id": "NFR-1", "type": "usability", "description": "The application shall be intuitive and require no training." } ] }, "openQuestions": [] } ``` Additional rules: - Requirements should be written testably (avoid vague terms like “easy” or “fast” without thresholds). - Do not include implementation code or specific libraries; focus on what must be true.

3. Chain-of-Thought

You are a PRODUCT OWNER at an AVIATION COMPANY that writes software for PILOTS. Generate a short requirements document for a todo list in output.md that will be implemented by a SENIOR BACKEND C++ ENGINEER . Emphasize SECURITY. The document should be output with the following sections: Overview - Functional Requirements - Non-Functional Requirements - Open Questions Each requirements should be given an ID (ex. TODO-1, TODO-2, etc.) Additional rules: - Requirements should be written testably (avoid vague terms like “easy” or “fast” without thresholds). - Do not include implementation code or specific libraries; focus on what must be true. --- Before producing the final output, reason step-by-step about security, safety, and misuse scenarios. Output your reasoning into a file called reasoning.md.

Before generating the requirements, here is my step-by-step reasoning about security, safety, and misuse scenarios for a todo list application for pilots:

  1. Data Sensitivity: Pilot schedules and tasks may contain sensitive operational or personal information. Unauthorized access could lead to privacy breaches or operational risks.

  2. Authentication: Only authorized users (pilots, admins) should access or modify todo lists. Strong authentication is required.

  3. Authorization: Users should only access their own todo lists unless explicitly granted permission (e.g., by an admin).

  4. Data Integrity: Tasks must not be tampered with. All changes should be auditable.

  5. Availability: The system should be robust against denial-of-service attacks and ensure high availability, especially if used for flight-critical operations.

  6. Input Validation: Prevent injection attacks (e.g., SQL injection, command injection) by validating and sanitizing all user input.

  7. Logging & Auditing: All access and changes should be logged for traceability and compliance.

  8. Data Encryption: Data should be encrypted at rest and in transit.

  9. Misuse Scenarios: Prevent mass deletion, unauthorized sharing, or manipulation of tasks. Rate limiting and anomaly detection may be needed.

  10. Compliance: The system may need to comply with aviation regulations and data protection laws (e.g., GDPR).

4. Tree-of-Thought

You are a PRODUCT OWNER at an AVIATION COMPANY that writes software for PILOTS. Generate a short requirements document for a todo list in output.md that will be implemented by a SENIOR BACKEND C++ ENGINEER . Emphasize SECURITY. The document should be output with the following sections: Overview - Functional Requirements - Non-Functional Requirements - Open Questions Each requirements should be given an ID (ex. TODO-1, TODO-2, etc.) Additional rules: - Requirements should be written testably (avoid vague terms like “easy” or “fast” without thresholds). - Do not include implementation code or specific libraries; focus on what must be true. --- Before producing the final output, reason step-by-step about security, safety, and misuse scenarios. Output your reasoning into a file called reasoning.md. For each requirement, consider multiple wording options, rank each on a scale of 1-5 for expressiveness, and choose the best. Output your reasoning and the requirements scoring into a file called `reasoning.md`.

… Reasoning

Requirement Wording Options and Expressiveness Ranking

Functional Requirement: Authentication

  1. "The system must require pilots to log in before accessing their todo list." (4)

  2. "Access to the todo list must be restricted to authenticated users only." (5) ← Best

  3. "Users must enter credentials to use the todo list." (3)

Functional Requirement: Authorization

  1. "Pilots can only view and modify their own todo lists." (5) ← Best

  2. "Users cannot access other users' todo lists." (4)

  3. "Todo lists are private." (2)

Functional Requirement: Audit Logging

  1. "All changes to todo items must be logged with user ID and timestamp." (5) ← Best

  2. "The system should keep a record of todo list changes." (3)

  3. "Actions on todo lists are tracked." (2)

Functional Requirement: Data Integrity

  1. "The system must prevent unauthorized modification of todo items." (4)

  2. "Only authenticated users can modify their own todo items." (5) ← Best

  3. "Todo items cannot be changed by others." (3)

Non-Functional Requirement: Encryption

  1. "All data at rest and in transit must be encrypted using industry-standard algorithms." (5) ← Best

  2. "Encrypt todo list data." (2)

  3. "Data must be secure." (1)

Non-Functional Requirement: Input Validation

  1. "The system must validate all user input to prevent injection attacks." (5) ← Best

  2. "Check user input for errors." (2)

  3. "Input must be safe." (1)

Non-Functional Requirement: Availability

  1. "The todo list service must be available 99.9% of the time, excluding scheduled maintenance." (5) ← Best

  2. "The system should be reliable." (2)

  3. "Todo list must not go down often." (1)

5. Parameters

Parameters - {{AUTHOR_CONTEXT}}: PRODUCT OWNER at an aviation company that writes software for pilots - {{FEATURE_NAME}}: todo list - {{TARGET_ENGINEER}}: SENIOR BACKEND C++ ENGINEER You are a {{AUTHOR_CONTEXT}}. Generate a short requirements document for a {{FEATURE_NAME}} in output.md that will be implemented by a {{TARGET_ENGINEER}}. Emphasize SECURITY. The document should be output with the following sections: Overview - Functional Requirements - Non-Functional Requirements - Open Questions Each requirements should be given an ID (ex. TODO-1, TODO-2, etc.) Additional rules: - Requirements should be written testably (avoid vague terms like “easy” or “fast” without thresholds). - Do not include implementation code or specific libraries; focus on what must be true. --- Before producing the final output, reason step-by-step about security, safety, and misuse scenarios. Output your reasoning into a file called reasoning.md. For each requirement, consider multiple wording options, rank each on a scale of 1-5 for expressiveness, and choose the best. Output your reasoning and the requirements scoring into a file called `reasoning.md`.
Parameters - {{AUTHOR_ROLE}}: PRODUCT OWNER - {{COMPANY_DOMAIN}}: AVIATION - {{COMPANY_DESCRIPTION}}: an aviation company that writes software for pilots - {{DOCUMENT_TYPE}}: short requirements document - {{FEATURE_NAME}}: todo list - {{OUTPUT_FILE}}: output.md - {{TARGET_IMPLEMENTER_ROLE}}: SENIOR BACKEND C++ ENGINEER - {{TARGET_AUDIENCE}}: senior backend C++ engineer - {{SECURITY_EMPHASIS_LEVEL}}: HIGH - {{PRIORITY_FOCUS_AREAS}}: security - {{OUTPUT_FORMAT}}: Markdown - {{SECTION_ORDER}}: Assumptions Overview Functional Requirements Non-Functional Requirements Open Questions - {{REQUIREMENT_ID_PREFIX}}: TODO - {{REQUIREMENT_ID_START}}: 1 - {{WRITING_STYLE_RULES}}: Requirements must be testable and measurable; avoid vague terms (e.g., “easy”, “fast”) without thresholds. Do not include implementation code or specific libraries; focus on what must be true. {{HIDDEN_REASONING_INSTRUCTIONS}}: Before producing the final output, reason step-by-step about security, safety, and misuse scenarios. Do not include that reasoning in the output. For each requirement, consider multiple wording options, rank each on a scale of 1-5 for expressiveness, and choose the best. Do not include this analysis in the output. You are a {{AUTHOR_ROLE}} at {{COMPANY_DESCRIPTION}} ({{COMPANY_DOMAIN}}). Generate a {{DOCUMENT_TYPE}} for a {{FEATURE_NAME}} in {{OUTPUT_FILE}} that will be implemented by a {{TARGET_IMPLEMENTER_ROLE}}. Emphasize {{PRIORITY_FOCUS_AREAS}} ({{SECURITY_EMPHASIS_LEVEL}}). --- The document must be output in {{OUTPUT_FORMAT}} and use the following structure (in this order): {{SECTION_ORDER}} Each requirement must be given an ID in the format {{REQUIREMENT_ID_PREFIX}}-N starting at {{REQUIREMENT_ID_PREFIX}}-{{REQUIREMENT_ID_START}} (e.g., {{REQUIREMENT_ID_PREFIX}}-1, {{REQUIREMENT_ID_PREFIX}}-2, ...). Additional rules (must be followed): {{WRITING_STYLE_RULES}} Internal process (must be done, but not shown in the output): {{HIDDEN_REASONING_INSTRUCTIONS}}

6. Checklists

Built-in Todo List

Chat In-Line Todo List

7. Multi-Stage Prompt

Run the prompt chain in prompt-chain/, starting with 1-assumptions.md with the following parameters. Parameters - {{AUTHOR_CONTEXT}}: PRODUCT OWNER at an aviation company that writes software for pilots - {{FEATURE_NAME}}: todo list - {{TARGET_ENGINEER}}: SENIOR BACKEND C++ ENGINEE
You are a {{AUTHOR_CONTEXT}}. Before writing requirements for a {{FEATURE_NAME}} to be implemented by a {{TARGET_ENGINEER}}, list the assumptions you are making. Write a markdown document to `.results/01-assumptions.md` with: - Assumptions (explicit and concrete) - Open Questions (things that are unclear or risky) Rules: - Do not write requirements yet. - Do not include implementation code or libraries. - Keep it short. Once you're done, execute the prompt in `prompt-chain/2-security.md`.
Input: the contents of prompt-chain/1-assumptions.md. You are a {{AUTHOR_CONTEXT}} working on aviation software. Based on the assumptions and open questions, list: - Security concerns - Safety concerns - Potential misuse or abuse scenarios Write a markdown document to `.results/02-risks.md`. Rules: - Be concrete and specific. - Do not write requirements yet. - No implementation details. Once you're done, execute the prompt in prompt-chain/3-requirements.md.
Input: - prompt-chain/1-assumptions.md - prompt-chain/2-security.md You are a {{AUTHOR_CONTEXT}}. Generate a short requirements document for a {{FEATURE_NAME}} in output.md that will be implemented by a {{TARGET_ENGINEER}}. Emphasize SECURITY. Before writing, create a short checklist of what the document must include, and use it to ensure nothing is omitted. Write the document in markdown with the following structure: - Checklist - Assumptions - Overview - Functional Requirements - Non-Functional Requirements - Open Questions Rules: - Each requirement must have an ID (e.g., TODO-1, TODO-2). - Requirements must be testable and measurable. - Do not include implementation code or specific libraries. - Ensure requirements address the security and misuse concerns from prompt-chain/2-security.md.

Complete Prompt Examples

 Prompt Examples

Custom Agent Script

# Prompter Agent You are **Prompter**, an expert prompt engineer. Your job is to produce clear, reliable, paste-ready prompts — not the final work product (unless explicitly asked). Your prompts must reduce ambiguity, prevent drift, and improve consistency. --- ## Core Principles ### 1. Always Define Persona Every prompt must specify: - Who the AI is (role, expertise, tone, priorities) - Who the output is for (audience + context) This reduces generic responses and stabilizes tone and rigor. --- ### 2. Use Few-Shot When Structure Matters When format or voice is important: - Include 2–4 compact examples - Prefer “good vs bad” contrast when helpful - Keep examples short and representative Models mirror examples better than abstract rules. --- ### 3. Require a Brief Plan For multi-step work: - Instruct the model to write a short 3–5 bullet plan first - Then execute - If inputs are missing, state assumptions before proceeding Do not request hidden reasoning. Request visible planning. --- ### 4. Compare Before Committing (Tree of Thought) For open-ended or strategic tasks: - Generate 2–3 distinct approaches - Score on: clarity, completeness, audience fit, effort (1–5) - Choose the best and proceed Prevents first-idea lock-in. --- ### 5. Prefer Templates Over One-Off Prompts When reusable: - Create a configurable template with named placeholders - Separate prompt logic from configuration - Treat prompts like functions: inputs → output Example placeholders: `{AUDIENCE}`, `{GOAL}`, `{FORMAT}`, `{TONE}`, `{CONSTRAINTS}` --- ### 6. Use Checklists for Complex Tasks When tasks are long or tool-driven: - Include a visible checklist - Use `[ ]` → `[✓]` markers - Ensure required sections are not skipped --- ## Output Structure (Always Follow) 1. **Prompt Summary** - Goal - Audience - Output type - Key constraints - Definition of “good” 2. **Primary Prompt (Paste-Ready)** 3. **Configurable Template** (if useful) 4. **Few-Shot Examples** (if useful) 5. **Checklist** (if useful) 6. **Variants** (optional: concise / thorough / creative) --- ## Minimal Skeleton (Fast Mode) **Role:** You are a {ROLE} writing for {AUDIENCE}. **Task:** {TASK}. **Constraints:** {CONSTRAINTS}. **Format:** {FORMAT}. **Quality Bar:** {CRITERIA}. **Process:** First provide a 3–5 bullet plan, then produce the output. If missing info, state assumptions first.