|
| 1 | +# GitHub Copilot Instructions for Tech Design Documents |
| 2 | + |
| 3 | +## Overview |
| 4 | + |
| 5 | +This repository is used to create technical design documents using AI Agent mode in an IDE. When a user asks you to create a technical design document, follow the guidelines below. |
| 6 | + |
| 7 | +## Creating a New Technical Design Document |
| 8 | + |
| 9 | +### Step 1: Understand the Requirement |
| 10 | + |
| 11 | +Ask clarifying questions if needed to understand: |
| 12 | +- What feature or system is being designed? |
| 13 | +- What problem does it solve? |
| 14 | +- Who is the target audience for the document? |
| 15 | +- Any specific constraints (tech stack, timeline, team size)? |
| 16 | + |
| 17 | +### Step 2: Use the Template |
| 18 | + |
| 19 | +Always base new technical design documents on the template located at: |
| 20 | +``` |
| 21 | +templates/tech-design-template.md |
| 22 | +``` |
| 23 | + |
| 24 | +### Step 3: Save the Document |
| 25 | + |
| 26 | +Save the new document to the `docs/` directory using the naming convention: |
| 27 | +``` |
| 28 | +docs/<feature-name>-tech-design.md |
| 29 | +``` |
| 30 | + |
| 31 | +For example: |
| 32 | +- `docs/user-auth-tech-design.md` |
| 33 | +- `docs/payment-service-tech-design.md` |
| 34 | +- `docs/data-pipeline-tech-design.md` |
| 35 | + |
| 36 | +### Step 4: Fill in the Content |
| 37 | + |
| 38 | +When generating the document, ensure that: |
| 39 | +1. **All sections from the template are included** — do not skip sections; mark them as "N/A" if not applicable |
| 40 | +2. **The overview is concise** — 2-3 sentences maximum |
| 41 | +3. **Architecture diagrams** use ASCII art or reference image files stored in `docs/images/` |
| 42 | +4. **API designs** include request/response examples with realistic data |
| 43 | +5. **Security considerations** are always addressed, even for internal tools |
| 44 | +6. **Open questions** capture any unresolved decisions that need input from stakeholders |
| 45 | + |
| 46 | +### Step 5: Update Status |
| 47 | + |
| 48 | +Set the document status to `Draft` initially. The user will update it to `In Review` or `Approved` as appropriate. |
| 49 | + |
| 50 | +## Document Quality Standards |
| 51 | + |
| 52 | +- Use clear, concise language |
| 53 | +- Avoid jargon without explanation |
| 54 | +- Use tables for structured comparisons |
| 55 | +- Include diagrams for complex architectures (ASCII art is acceptable) |
| 56 | +- Reference external standards or RFCs where applicable |
| 57 | +- Ensure all links and cross-references are valid |
| 58 | + |
| 59 | +## Updating an Existing Document |
| 60 | + |
| 61 | +When a user asks to update an existing tech design document: |
| 62 | +1. Read the current document carefully |
| 63 | +2. Make targeted updates to the relevant sections |
| 64 | +3. Increment the version number (e.g., 1.0 → 1.1 for minor changes, 1.0 → 2.0 for major redesigns) |
| 65 | +4. Add a note in the document about what changed if the status is `In Review` or `Approved` |
| 66 | + |
| 67 | +## Example Prompts |
| 68 | + |
| 69 | +Users may interact with you using prompts like: |
| 70 | + |
| 71 | +- "Create a tech design doc for a new notification service" |
| 72 | +- "Write a technical design for migrating our database from MySQL to PostgreSQL" |
| 73 | +- "Generate a design document for the search feature refactor" |
| 74 | +- "Update the payment service tech design to add support for cryptocurrency" |
0 commit comments