Skip to content

Commit 33a382d

Browse files
ChrisHowdChrisHowd
committed
GitHub Copilot scenarios
1 parent 1d6701c commit 33a382d

1 file changed

Lines changed: 367 additions & 0 deletions

File tree

‎Instructions/Labs/LAB_AK_91_jibe_programming_web_app.md‎

Lines changed: 367 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,367 @@
1+
## Envision and plan your application
2+
3+
1. Brainstorm ideas
4+
- What problem does your application solve? What is the purpose of your application?
5+
- Who is your target audience?
6+
- What platforms will your application run on (web, mobile, desktop)?
7+
- What features will your application have?
8+
- What technologies will you use to build it?
9+
10+
1. Create Product Requirements Document (PRD)
11+
12+
```md
13+
14+
15+
# Product Requirements Document (PRD) Template for GitHub Copilot Agent Workflows
16+
17+
## 1. Executive Summary
18+
### Instructions:
19+
Provide a brief overview of the product, including its purpose, target audience, and key goals.
20+
21+
### Example:
22+
**Product:** Daily Mood Tracker Web App
23+
**Purpose:** To help users log their daily mood, view mood trends, and optionally share mood data with a therapist.
24+
**Target Audience:** Individuals seeking to track their mental health and therapists who monitor their patients' mood patterns.
25+
**Goals:**
26+
- Enable users to log their mood quickly and easily.
27+
- Provide visualizations of mood trends over time.
28+
- Allow users to share mood data with their therapist.
29+
30+
## 2. Problem Overview
31+
### Instructions:
32+
Describe the current pain points or inefficiencies that the product aims to address. Include assumptions and constraints.
33+
34+
### Example:
35+
**Current Pain Points:**
36+
- Users lack a simple and effective way to track their mood daily.
37+
- Therapists need a reliable method to monitor their patients' mood patterns remotely.
38+
**Assumptions:**
39+
- Users have access to a smartphone or computer.
40+
- Therapists are willing to use digital tools for monitoring.
41+
**Constraints:**
42+
- The app must be user-friendly and accessible.
43+
- Data privacy and security must be ensured.
44+
45+
## 3. Scope
46+
### Instructions:
47+
Define what is in scope and what is explicitly out of scope for the MVP.
48+
49+
### Example:
50+
**In Scope:**
51+
- Mood logging functionality.
52+
- Mood trend visualizations.
53+
- Data sharing with therapists.
54+
**Out of Scope:**
55+
- Advanced mood analysis algorithms.
56+
- Integration with other health tracking apps.
57+
58+
## 4. Use Cases & Scenarios
59+
### Instructions:
60+
Provide real-world examples of how users will interact with the product. Include user personas and workflows.
61+
62+
### Example:
63+
**Use Case 1:**
64+
- **Persona:** Jane, a 30-year-old professional experiencing stress.
65+
- **Scenario:** Jane logs her mood daily using the app and views her mood trends to identify patterns.
66+
**Use Case 2:**
67+
- **Persona:** Dr. Smith, a therapist.
68+
- **Scenario:** Dr. Smith reviews mood data shared by his patients to monitor their progress.
69+
70+
## 5. Requirements
71+
### Instructions:
72+
List the functional and non-functional requirements. Include user stories and acceptance criteria. Add mockups or wireframes if available.
73+
74+
### Example:
75+
**Functional Requirements:**
76+
- **User Story:** As a user, I want to log my mood daily so that I can track my mental health.
77+
- **Acceptance Criteria:** The mood logging feature should allow users to select their mood from predefined options and add notes.
78+
**Non-functional Requirements:**
79+
- The app should be responsive and work on both mobile and desktop devices.
80+
- Data should be encrypted to ensure privacy.
81+
82+
## 6. Dependencies
83+
### Instructions:
84+
Identify cross-team or cross-system dependencies. List required technologies, APIs, or services.
85+
86+
### Example:
87+
**Dependencies:**
88+
- Integration with a secure database for storing mood data.
89+
- Use of charting libraries for visualizing mood trends.
90+
91+
## 7. Success Metrics
92+
### Instructions:
93+
Define how success will be measured. Include adoption, performance, and satisfaction metrics.
94+
95+
### Example:
96+
**Success Metrics:**
97+
- Number of daily active users.
98+
- User satisfaction ratings.
99+
- Therapist adoption rate.
100+
101+
## 8. Competitive Analysis
102+
### Instructions:
103+
Provide an overview of similar products in the market. Highlight strengths, weaknesses, and differentiators.
104+
105+
### Example:
106+
**Competitive Analysis:**
107+
- **Product A:** Offers mood tracking but lacks data sharing with therapists.
108+
- **Product B:** Provides advanced mood analysis but is complex to use.
109+
**Differentiators:** Our app focuses on simplicity and therapist integration.
110+
111+
## 9. Product Roadmap
112+
### Instructions:
113+
Outline the timeline for MVP, V1.0, V2.0, etc. Include preview phases.
114+
115+
### Example:
116+
**Product Roadmap:**
117+
- **MVP:** Mood logging, trend visualizations, data sharing (Q1 2023)
118+
- **V1.0:** Enhanced visualizations, user feedback integration (Q2 2023)
119+
- **V2.0:** Advanced mood analysis, integration with health apps (Q3 2023)
120+
121+
## 10. Risks & Challenges
122+
### Instructions:
123+
Identify technical, legal, operational, or market risks. Provide mitigation strategies.
124+
125+
### Example:
126+
**Risks & Challenges:**
127+
- **Technical Risk:** Ensuring data privacy and security.
128+
- **Mitigation:** Implement robust encryption and security protocols.
129+
- **Market Risk:** User adoption.
130+
- **Mitigation:** Conduct user testing and iterate based on feedback.
131+
132+
## 11. Open Questions
133+
### Instructions:
134+
List unresolved issues or decisions pending input.
135+
136+
### Example:
137+
**Open Questions:**
138+
- Should the app include mood prediction features?
139+
- What additional mood tracking options should be provided?
140+
141+
## 12. Supporting Documentation
142+
### Instructions:
143+
Provide links to research, design docs, or related specs.
144+
145+
### Example:
146+
**Supporting Documentation:**
147+
- [User Research Report](link)
148+
- [Design Mockups](link)
149+
150+
## 13. Sign-Off
151+
### Instructions:
152+
Include stakeholder approvals and version history.
153+
154+
### Example:
155+
**Sign-Off:**
156+
- **Version 1.0:** Approved by Product Manager, Lead Developer, and UX Designer.
157+
158+
159+
160+
161+
162+
# Product Requirements Document (PRD) Template
163+
164+
## Executive Summary
165+
### What is the product?
166+
The product is a web application for pet adoption. It supports users who want to give up their pets for adoption and users who want to adopt pets. The app allows users to browse available pets without logging in, but requires authentication for donating or adopting pets.
167+
168+
### What problem does it solve?
169+
The app addresses the need for a streamlined and user-friendly platform for pet adoption, making it easier for pet owners to find new homes for their pets and for potential adopters to find pets that match their preferences.
170+
171+
### Who are the users and what are their goals?
172+
- **Pet Owners**: Users who need to give up their pets for adoption.
173+
- **Potential Adopters**: Users who are looking to adopt a pet.
174+
- **General Users**: Users who want to browse available pets without logging in.
175+
176+
## Problem Overview
177+
### Description of the current pain points or inefficiencies
178+
Pet adoption processes can be cumbersome and inefficient, with limited online platforms that provide comprehensive information about pets available for adoption. Users often struggle to find detailed information about pets, including their medical history and care requirements.
179+
180+
### Assumptions and constraints
181+
- Only pets that can be found in a pet store (dogs, cats, hamsters, snakes, turtles) are accepted.
182+
- The business does not support fish or birds.
183+
- Users must provide credentials to donate or adopt pets.
184+
- Users can browse pets without logging in.
185+
186+
### Current vs. future state comparison
187+
- **Current State**: Limited online platforms with incomplete information about pets.
188+
- **Future State**: A comprehensive web app with detailed pet listings, user authentication, and streamlined adoption processes.
189+
190+
## Scope
191+
### What’s in scope and what’s explicitly out of scope
192+
#### In Scope
193+
- User authentication for donating and adopting pets.
194+
- Browsing pets without logging in.
195+
- Detailed pet listings including statistics, history with previous owner, medical history, care requirements, and images.
196+
- Support for pets commonly found in pet stores (dogs, cats, hamsters, snakes, turtles).
197+
198+
#### Out of Scope
199+
- Support for fish or birds.
200+
- Advanced features such as pet training or veterinary services.
201+
202+
### MVP definition: the smallest set of features that deliver value
203+
- User authentication for donating and adopting pets.
204+
- Browsing pets without logging in.
205+
- Detailed pet listings with basic statistics, history, medical info, care needs, and images.
206+
207+
## Use Cases & Scenarios
208+
### Real-world examples of how users will interact with the product
209+
#### Use Case 1: Browsing Pets
210+
- **Scenario**: A user visits the app to browse available pets without logging in.
211+
- **Steps**:
212+
1. User navigates to the homepage.
213+
2. User selects the "Browse Pets" option.
214+
3. User views a list of available pets with basic information and images.
215+
216+
#### Use Case 2: Donating a Pet
217+
- **Scenario**: A pet owner wants to give up their pet for adoption.
218+
- **Steps**:
219+
1. User logs in or creates an account.
220+
2. User selects the "Donate a Pet" option.
221+
3. User fills out a form with pet details (statistics, history, medical info, care needs, images).
222+
4. User submits the form, and the pet listing is created.
223+
224+
#### Use Case 3: Adopting a Pet
225+
- **Scenario**: A potential adopter wants to adopt a pet.
226+
- **Steps**:
227+
1. User logs in or creates an account.
228+
2. User browses available pets and selects a pet for adoption.
229+
3. User fills out an adoption form and submits it.
230+
4. User receives confirmation and instructions for completing the adoption process.
231+
232+
## Requirements
233+
### Functional Requirements: user stories and acceptance criteria
234+
#### User Story 1: As a user, I want to browse available pets without logging in.
235+
- **Acceptance Criteria**:
236+
- Users can view a list of available pets with basic information and images.
237+
- Users can filter pets by type (dog, cat, hamster, snake, turtle).
238+
239+
#### User Story 2: As a pet owner, I want to donate my pet for adoption.
240+
- **Acceptance Criteria**:
241+
- Users must log in or create an account to donate a pet.
242+
- Users can fill out a form with pet details (statistics, history, medical info, care needs, images).
243+
- The pet listing is created and visible to other users.
244+
245+
#### User Story 3: As a potential adopter, I want to adopt a pet.
246+
- **Acceptance Criteria**:
247+
- Users must log in or create an account to adopt a pet.
248+
- Users can fill out an adoption form and submit it.
249+
- Users receive confirmation and instructions for completing the adoption process.
250+
251+
### Non-functional Requirements: performance, scalability, security, etc.
252+
- The app must handle concurrent users efficiently.
253+
- User data must be securely stored and transmitted.
254+
- The app must be responsive and accessible on various devices.
255+
256+
## Dependencies
257+
### Cross-team or cross-system dependencies
258+
- Integration with authentication services (e.g., OAuth).
259+
- Integration with image storage services (e.g., AWS S3).
260+
- Dependencies on frontend and backend frameworks (e.g., React, Node.js).
261+
262+
## Success Metrics
263+
### How will success be measured? (e.g., adoption, performance, satisfaction)
264+
- **Adoption**: Number of registered users and active users.
265+
- **Performance**: Page load times and server response times.
266+
- **Satisfaction**: User feedback and ratings.
267+
268+
### ROI or impact metrics
269+
- **Adoption Rate**: Percentage of users who complete the donation or adoption process.
270+
- **User Engagement**: Average time spent browsing pets.
271+
272+
## Competitive Analysis
273+
### Overview of similar products in the market
274+
- Comparison of features, strengths, and weaknesses of existing pet adoption platforms.
275+
276+
## Product Roadmap
277+
### Timeline for MVP, V1.0, V2.0, etc.
278+
- **MVP**: Basic pet browsing, donation, and adoption features.
279+
- **V1.0**: Enhanced pet listings, user profiles, and search functionality.
280+
- **V2.0**: Advanced features such as pet training resources and veterinary services.
281+
282+
### Preview phases (dogfood, private/public preview)
283+
- **Dogfood**: Internal testing with team members.
284+
- **Private Preview**: Limited release to selected users.
285+
- **Public Preview**: Open release to all users.
286+
287+
## Risks & Challenges
288+
### Technical, legal, operational, or market risks
289+
- **Technical Risks**: Scalability and performance issues.
290+
- **Legal Risks**: Compliance with data protection regulations.
291+
- **Operational Risks**: Ensuring user adoption and engagement.
292+
293+
### Mitigation strategies
294+
- Implement robust testing and monitoring.
295+
- Ensure compliance with legal requirements.
296+
- Develop user engagement strategies.
297+
298+
## Open Questions
299+
### Unresolved issues or decisions pending input
300+
- What additional pet types should be considered for future versions?
301+
- How can we enhance user engagement and satisfaction?
302+
303+
## Supporting Documentation
304+
### Links to research, design docs, or related specs
305+
- Research on pet adoption trends and user preferences.
306+
- Design mockups and wireframes.
307+
308+
## Sign-Off
309+
### Stakeholder approvals and version history
310+
- Approval from product manager, development team, and key stakeholders.
311+
- Version history and change log.
312+
313+
314+
315+
316+
Copilot Custom Instructions for MyTodoListApp
317+
318+
## Project Overview
319+
320+
This workspace contains a .NET Aspire solution for a Todo List application, including:
321+
322+
- **MyTodoApi**: Minimal API backend for todo items, using Entity Framework Core and SQLite.
323+
- **MyNewTodoListApp**: Blazor WebAssembly frontend for managing todo items, consuming the API.
324+
- **BlazorApp1**: Additional Blazor app (sample or test).
325+
- **Aspire.AppHost**: Orchestrator for running the solution locally with Aspire.
326+
- **Aspire.ServiceDefaults**: Shared service configuration for Aspire projects.
327+
328+
## Key Technologies
329+
330+
- .NET Aspire (for orchestration and service defaults)
331+
- Blazor WebAssembly (frontend)
332+
- ASP.NET Core Minimal API (backend)
333+
- Entity Framework Core with SQLite (data persistence)
334+
335+
## Main Features
336+
337+
- CRUD operations for todo items
338+
- API endpoints for todo management
339+
- Blazor UI for interacting with todos
340+
- Local development orchestration with Aspire
341+
342+
## File/Folder Highlights
343+
344+
- **MyTodoApi/**: API project, contains `Program.cs`, `TodoStore.cs`, `ApplicationDbContext.cs`, and `Models/`.
345+
- **MyNewTodoListApp/**: Blazor WASM frontend, contains `Program.cs`, `ToDoClient.cs`, `Pages/`, and `Shared/`.
346+
- **Aspire.AppHost/**: Aspire orchestration, contains `Program.cs` and `appsettings.json`.
347+
348+
## Coding/Response Guidelines
349+
350+
- Prefer .NET 9 idioms and minimal API patterns.
351+
- Use dependency injection and configuration best practices.
352+
- For Blazor, use component-based design and leverage `@inject` for services.
353+
- When suggesting code, reference the relevant project and file.
354+
- When discussing API endpoints, refer to **MyTodoApi**.
355+
- When discussing UI, refer to **MyNewTodoListApp**.
356+
- For orchestration or service config, refer to **Aspire.AppHost** or **Aspire.ServiceDefaults**.
357+
358+
## Example Use Cases
359+
360+
- Add a new todo item via the Blazor frontend.
361+
- Retrieve all todos from the API.
362+
- Update or delete a todo item.
363+
- Run the solution locally using Aspire.
364+
365+
366+
```
367+

0 commit comments

Comments
 (0)