/
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:

{ "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 in a markdown format with the following structure:

  • Assumptions (all of YOUR assumptions)

  • 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 AVAIATION 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 in a markdown format with the following structure:

  • Assumptions (all of YOUR assumptions)

  • 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.

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 in markdown with the following structure:

  • Assumptions (all of your assumptions)

  • Overview

  • Functional Requirements

  • Non-Functional Requirements

  • Open Questions

Each requirement must be given an ID (e.g., TODO-1, TODO-2, etc.).

Additional rules:

  • Requirements must 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. 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.

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

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 in markdown with the following structure:

  • Assumptions (all of your assumptions)

  • Overview

  • Functional Requirements

  • Non-Functional Requirements

  • Open Questions

Each requirement must be given an ID (e.g., TODO-1, TODO-2, etc.).

Additional rules:

  • Requirements must 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. 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.

Before you start writing, break down what you need to do into concrete steps in the form of a checklist, and check off the things that you need to do as you go. This will help you keep track of everything and not omit any sections.

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++ ENGINEER

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

  • 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

 https://bitovi.atlassian.net/wiki/spaces/AIEnabledDevelopment/pages/1625587759