mirror of
https://github.com/azaion/gps-denied-desktop.git
synced 2026-04-23 05:06:37 +00:00
enhancing clarity in research assessment and problem description sections.
some files rename
This commit is contained in:
Oleksandr Bezdieniezhnykh
+6
-14
@@ -1,19 +1,11 @@
|
||||
# decompose
|
||||
|
||||
## The problem description
|
||||
`@_docs/00_problem/problem_description.md`.
|
||||
|
||||
## Data samples
|
||||
Located here: `@_docs/00_problem/input_data`. They are for reference only, yet it is examples from the real data.
|
||||
|
||||
## Restrictions for the input data
|
||||
`@_docs/00_problem/restrictions.md`.
|
||||
|
||||
## Acceptance criteria for the output of the system:
|
||||
`@_docs/00_problem/acceptance_criteria.md`.
|
||||
|
||||
## Existing solution:
|
||||
`@_docs/01_solution/solution_draft.md`
|
||||
## Initial data:
|
||||
- Problem description: `@_docs/00_problem/problem_description.md`
|
||||
- Input data: `@_docs/00_problem/input_data`. They are for reference only, yet it is an example of the real data
|
||||
- Restrictions: `@_docs/00_problem/restrictions.md`
|
||||
- Acceptance criteria: `@_docs/00_problem/acceptance_criteria.md`
|
||||
- Full Solution Description: `@_docs/01_solution/solution.md`
|
||||
|
||||
## Role
|
||||
You are a professional software architect
|
||||
+6
-6
@@ -1,11 +1,11 @@
|
||||
# component assesment
|
||||
|
||||
## Problem statement
|
||||
- @00_problem
|
||||
|
||||
## Solution and decomposition
|
||||
- @_docs/01_solution/solution.md
|
||||
- @02_components
|
||||
## Initial data:
|
||||
- Problem description: `@_docs/00_problem/problem_description.md`
|
||||
- Input data: `@_docs/00_problem/input_data`. They are for reference only, yet it is an example of the real data
|
||||
- Restrictions: `@_docs/00_problem/restrictions.md`
|
||||
- Acceptance criteria: `@_docs/00_problem/acceptance_criteria.md`
|
||||
- Full Solution Description: `@_docs/01_solution/solution.md`
|
||||
|
||||
## Role
|
||||
You are a professional software architect
|
||||
+7
-15
@@ -1,25 +1,17 @@
|
||||
# generate Jira Epics
|
||||
|
||||
## The problem description
|
||||
`@_docs/00_problem/problem_description.md`.
|
||||
|
||||
## Data samples
|
||||
Located here: `@_docs/00_problem/input_data`. They are for reference only, yet it is examples from the real data.
|
||||
|
||||
## Restrictions for the input data
|
||||
`@_docs/00_problem/restrictions.md`.
|
||||
|
||||
## Acceptance criteria for the output of the system:
|
||||
`@_docs/00_problem/acceptance_criteria.md`.
|
||||
|
||||
## Existing solution:
|
||||
`@_docs/01_solution/solution.md`
|
||||
## Initial data:
|
||||
- Problem description: `@_docs/00_problem/problem_description.md`
|
||||
- Input data: `@_docs/00_problem/input_data`. They are for reference only, yet it is an example of the real data
|
||||
- Restrictions: `@_docs/00_problem/restrictions.md`
|
||||
- Acceptance criteria: `@_docs/00_problem/acceptance_criteria.md`
|
||||
- Full Solution Description: `@_docs/01_solution/solution.md`
|
||||
|
||||
## Role
|
||||
You are a world class product manager
|
||||
|
||||
## Task
|
||||
- Generate Jira Epics from the Components
|
||||
- Generate Jira Epics from the Components Using Jira MCP
|
||||
- Ensure each epic has clear goal and acceptance criteria, verify it with acceptance criteria
|
||||
- Generate draw.io components diagram based on previous diagram shows relations between components and current Jira Epic number, corresponding to each component.
|
||||
|
||||
+6
-14
@@ -1,19 +1,11 @@
|
||||
# generate Tests
|
||||
|
||||
## The problem description
|
||||
`@_docs/00_problem/problem_description.md`.
|
||||
|
||||
## Data samples
|
||||
Located here: `@_docs/00_problem/input_data`. They are for reference only, yet it is examples from the real data.
|
||||
|
||||
## Restrictions for the input data
|
||||
`@_docs/00_problem/restrictions.md`.
|
||||
|
||||
## Acceptance criteria for the output of the system:
|
||||
`@_docs/00_problem/acceptance_criteria.md`.
|
||||
|
||||
## Existing solution:
|
||||
`@_docs/01_solution/solution_draft.md`
|
||||
## Initial data:
|
||||
- Problem description: `@_docs/00_problem/problem_description.md`
|
||||
- Input data: `@_docs/00_problem/input_data`. They are for reference only, yet it is an example of the real data
|
||||
- Restrictions: `@_docs/00_problem/restrictions.md`
|
||||
- Acceptance criteria: `@_docs/00_problem/acceptance_criteria.md`
|
||||
- Full Solution Description: `@_docs/01_solution/solution.md`
|
||||
|
||||
## Role
|
||||
You are a professional Quality Assurance Engineer
|
||||
@@ -1,35 +0,0 @@
|
||||
# generate Features for the provided component spec
|
||||
|
||||
## Input parameter
|
||||
--component component_spec.md
|
||||
|
||||
## Existing solution:
|
||||
`@_docs/01_solution/solution.md`
|
||||
|
||||
## Acceptance criteria for the output of the system:
|
||||
`@_docs/00_problem/acceptance_criteria.md`.
|
||||
|
||||
## Role
|
||||
You are a professional software architect
|
||||
|
||||
## Task
|
||||
- Read very carefully component_spec.md
|
||||
- Decompose component_spec.md to the features. If component is simple or atomic, then create only 1 feature.
|
||||
- Split to the many features only if it necessary and would be easier to implement
|
||||
- Do not create features of other components, create *only* features of this exact component
|
||||
- Each feature should be atomic, could contain 0 API, or list of semantically connected APIs
|
||||
- After splitting asses yourself
|
||||
|
||||
## Output
|
||||
In a component's folder create feature specs `[component's number ##].[feature's number ##]_feature_[feature_name].md` with the next structure:
|
||||
- Name
|
||||
- Description
|
||||
- Component APIs it implements if any
|
||||
- External tools and service it uses for implementation if any
|
||||
- Internal methods and its purposes
|
||||
- Unit tests
|
||||
- Integration tests
|
||||
|
||||
## Notes
|
||||
- Do NOT generate any code yet, only brief explanations what should be done.
|
||||
- Ask as many questions as needed.
|
||||
@@ -0,0 +1,34 @@
|
||||
# generate Features for the provided component spec
|
||||
|
||||
## Input parameters
|
||||
- component_spec.md. Required. Do NOT proceed if it is NOT provided!
|
||||
- parent Jira Epic in the format AZ-###. Required. Do NOT proceed if it is NOT provided!
|
||||
|
||||
## Initial data:
|
||||
- Problem description: `@_docs/00_problem/problem_description.md`
|
||||
- Input data: `@_docs/00_problem/input_data`. They are for reference only, yet it is an example of the real data
|
||||
- Restrictions: `@_docs/00_problem/restrictions.md`
|
||||
- Acceptance criteria: `@_docs/00_problem/acceptance_criteria.md`
|
||||
- Full Solution Description: `@_docs/01_solution/solution.md`
|
||||
|
||||
## Role
|
||||
You are a professional software architect
|
||||
|
||||
## Task
|
||||
- Read very carefully component_spec.md
|
||||
- Decompose component_spec.md to the features. If component is simple or atomic, then create only 1 feature.
|
||||
- Split to the many features only if it necessary and would be easier to implement
|
||||
- Do not create features of other components, create *only* features of this exact component
|
||||
- Each feature should be atomic, could contain 0 API, or list of semantically connected APIs
|
||||
- After splitting asses yourself
|
||||
- Use `@gen_feature_spec.md` as a complete guidance how to generate feature spec
|
||||
- Generate Jira tasks per each feature using this spec `@gen_jira_task.md` usint Jira MCP.
|
||||
|
||||
## Output
|
||||
- The file name of the feature specs should follow this format: `[component's number ##].[feature's number ##]_feature_[feature_name].md`.
|
||||
- The structure of the feature spec should follow this spec `@gen_feature_spec.md`
|
||||
- The structure of the Jira task should follow this spec: `@gen_jira_task.md`
|
||||
|
||||
## Notes
|
||||
- Do NOT generate any code yet, only brief explanations what should be done.
|
||||
- Ask as many questions as needed.
|
||||
Reference in New Issue
Block a user