mirror of
https://github.com/azaion/gps-denied-onboard.git
synced 2026-04-22 05:26:37 +00:00
enhancing clarity in research assessment and problem description sections.
some files rename
This commit is contained in:
Oleksandr Bezdieniezhnykh
@@ -1,15 +1,11 @@
|
||||
## 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.md`.
|
||||
|
||||
## Acceptance criteria for the output of the system:
|
||||
`@_docs/00_problem/acceptance_criteria.md`.
|
||||
# research acceptance criteria
|
||||
|
||||
## 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`
|
||||
|
||||
## Role
|
||||
You are a professional software architect
|
||||
|
||||
|
||||
@@ -1,17 +1,13 @@
|
||||
## The problem description
|
||||
`@_docs/00_problem/problem_description.md`.
|
||||
# research problem
|
||||
|
||||
## 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.md`.
|
||||
|
||||
## Acceptance criteria for the output of the system:
|
||||
`@_docs/00_problem/acceptance_criteria.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`
|
||||
|
||||
## Role
|
||||
You are a professional software architect
|
||||
You are a professional researcher and software architect
|
||||
|
||||
## Task
|
||||
- Thorougly research in internet about the problem and all the possible ways to solve a problem, and split it to components.
|
||||
|
||||
@@ -1,17 +1,11 @@
|
||||
## The problem description
|
||||
`@_docs/00_problem/problem_description.md`.
|
||||
# Solution draft assesment
|
||||
|
||||
## 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.md`.
|
||||
|
||||
## Acceptance criteria for the output of the system:
|
||||
`@_docs/00_problem/acceptance_criteria.md`.
|
||||
|
||||
## Existing solution draft:
|
||||
`@_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`
|
||||
- Existing solution draft: `@_docs/01_solution/solution_draft.md`
|
||||
|
||||
## Role
|
||||
You are a professional software architect
|
||||
|
||||
+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.
|
||||
@@ -1,22 +1,12 @@
|
||||
# Create initial structure
|
||||
|
||||
## 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 an example of 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 spec:
|
||||
`@_docs/01_solution/solution.md`
|
||||
|
||||
## Components with Features specs
|
||||
`@_docs/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`
|
||||
- Components with Features specifications: `@_docs/02_components`
|
||||
|
||||
## Role
|
||||
You are a professional software architect
|
||||
@@ -29,7 +19,32 @@
|
||||
- component's interfaces
|
||||
- empty implementations
|
||||
- helpers - empty implementations or interfaces
|
||||
- add README.md, describe the project by @_docs/01_solution/solution.md
|
||||
- add README.md, describe the project by @_docs/01_solution/solution.md
|
||||
- Create a separate project for the integration tests
|
||||
|
||||
## Example
|
||||
The structure should roughly looks like this:
|
||||
-
|
||||
- api
|
||||
- components
|
||||
- component1_folder
|
||||
- component2_folder
|
||||
- ...
|
||||
- db
|
||||
- helpers
|
||||
- models
|
||||
- tests
|
||||
- unit_test1_project1_folder
|
||||
- unit_test2_project2_folder
|
||||
...
|
||||
- integration_tests_folder
|
||||
- test data
|
||||
- test01_file
|
||||
- test02_file
|
||||
...
|
||||
|
||||
Also it is possible that some semantically coherent components (or 1 big component) would be in its own project or project folder
|
||||
Could be common layer or project consisting of all the interfaces (for C# or Java), or each interface in each component's folder (python) - depending on the language common conventions
|
||||
|
||||
## Notes
|
||||
- Follow SOLID principles
|
||||
|
||||
@@ -3,40 +3,29 @@
|
||||
## Input parameter
|
||||
component_folder
|
||||
|
||||
## 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 an example of 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 professional software architect and developer
|
||||
|
||||
## Task
|
||||
- Read carefully component spec in the component_folder: `@_docs/02_components/[##]_[component_name]/[##]._component_[component_name]`
|
||||
- Read carefully initial data and component spec in the component_folder: `@_docs/02_components/[##]_[component_name]/[##]._component_[component_name]`
|
||||
- Read carefully all the component features in the component_folder: `@_docs/02_components/[##]_[component_name]/[##].[##]_feature_[feature_name]`
|
||||
- Investgate in internet what are the best way and tools to implement component and its features
|
||||
- During the investigation is is possible that found solutions required architecturally reorganization of the features. It is ok, propose that and if user agrees, include reorganization in the build feature plan. Also it is possible that interface could be changed or even removed or added new one. It is ok.
|
||||
- Analyze the existing codebase and get full context for the component's implementation
|
||||
- Make sure each feature is connected and communicated properly with other features and existing code
|
||||
- If component has dependency on another one, create temporary mock for the dependency
|
||||
- Create unit tests from the Test cases description, run it and make sure the result is a success
|
||||
- Create integration test for the feature, run and make sure the result is a success
|
||||
If integration tests are specified in component spec, then write them and run, and make sure that component working correctly
|
||||
- Include in the plan code assesment
|
||||
|
||||
- For each feature:
|
||||
- Implement the feature
|
||||
- Implement all unit tests from the Test cases description, add checks test results to the plan steps
|
||||
- Implement all integration tests for the feature, add check test results to the plan steps. Analyze existing tests, and decide whether to create new one or add to existing
|
||||
- Add to the implementation plan description of all component's integration tests, add check test results to the plan steps
|
||||
|
||||
## Notes
|
||||
- Follow SOLID principles
|
||||
- Follow KISS principle. Dumb code - smart data.
|
||||
- Follow DRY principles, but do not overcomplicate things, if code repeats sometimes, it is ok if that would be simpler
|
||||
- Follow conventions and rules of the project's programming language
|
||||
- Ask as many questions as needed, everything should be clear how to implement each feature
|
||||
|
||||
@@ -0,0 +1,30 @@
|
||||
# Implement tests by spec
|
||||
|
||||
## 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`
|
||||
- Tests specifications: `@_docs/02_tests`
|
||||
|
||||
## Role
|
||||
You are a professional software architect and developer
|
||||
|
||||
## Task
|
||||
- Read carefully all the initial data and understand whole system goals
|
||||
- Check that a separate project in a separate folder is existing (should be generated by @3.05_implement_initial_structure.md)
|
||||
- For each test description:
|
||||
- Prepare all the data necessary for testing, or check it is already exists
|
||||
- Check existing integration tests and if a similar test is already exists, update it
|
||||
- Implement the test by specification
|
||||
- Run system and integration tests and in 2 separate docker containers
|
||||
- Fix all problems if tests failed until we got a successful result. In case if one or more tests was failed due to missing data from user or API or other system, ask it from developer.
|
||||
- Repeat test cycle until no failed tests, iteratively fixing found bugs. Ask user for an additional information if something new appears
|
||||
- Compose a final test results in a csv with the next format:
|
||||
- Test filename
|
||||
- Execution time
|
||||
- Result
|
||||
|
||||
## Notes
|
||||
- Ask as many questions as needed, everything should be clear how to implement each feature
|
||||
@@ -1,185 +0,0 @@
|
||||
title: "Create PBI from Spec (Azure DevOps via NGA MCP) — v6"
|
||||
category: "development"
|
||||
tags:
|
||||
- azure-devops
|
||||
- automation
|
||||
- specifications
|
||||
- pbis
|
||||
- mcp
|
||||
version: "1.11"
|
||||
description: "Create/update a Product Backlog Item in Azure DevOps via NGA MCP and optionally move/rename the original spec file. Maps Description vs Acceptance Criteria vs Technical Details into the correct ADO fields with detection & flags. Links PBI to parent Feature using Hierarchy-Reverse relation."
|
||||
project: "Audit Platform" # default ADO project (override with --project if needed)
|
||||
---
|
||||
|
||||
# /create-pbi — Generate Azure DevOps PBI from Spec (via NGA MCP)
|
||||
|
||||
Create or update a **Product Backlog Item (PBI)** in **Azure DevOps** from a behavioral spec produced by `/generate-spec`.
|
||||
Optionally, when `--rename` is provided, **move/rename the original spec file** into a normalized path using the Feature and PBI context.
|
||||
|
||||
> ⚠️ Requires **NGA MCP** in Agent mode with ADO access and your PAT configured.
|
||||
> Uses the default project: **NextGenAudit-Platform** (no project listing).
|
||||
|
||||
---
|
||||
|
||||
## 🔧 Inputs
|
||||
|
||||
- **Spec path** (required): path to the source spec file. Example: `docs/specs/spec-export-e2e.md`
|
||||
- **Feature** (required on create): ADO **Feature** work item ID to parent under (e.g., `987654`).
|
||||
- **Optional flags:**
|
||||
- `--project "<ADO Project Name>"` (defaults to frontmatter `project`, here: "Audit Platform")
|
||||
- `--area "<Area Path>"`
|
||||
- `--iteration "<Iteration Path>"`
|
||||
- `--assign "<user@corp.com>"`
|
||||
- `--tags "t1,t2"`
|
||||
- `--update <PBI-ID>` (update existing PBI instead of creating a new one)
|
||||
- `--rename` (move/rename the original spec file to the pattern below)
|
||||
- `--pattern "{dir}/{featureId}-{featureSlug}/{id}-{slug}.md"` (override move pattern)
|
||||
- `--ac-field "Microsoft.VSTS.Common.AcceptanceCriteria"` (override Acceptance Criteria field name)
|
||||
- `--tech-field "Custom.TechnicalDetails"` (override Technical Details custom field name)
|
||||
|
||||
**Examples**
|
||||
```
|
||||
/create-pbi docs/specs/spec-export-e2e.md 987654 --area "Apps\JADx" --iteration "FY25\Q4" --rename
|
||||
/create-pbi docs/specs/spec-export-e2e.md --update 123456 --assign "j.doe@company.com" --ac-field "Microsoft.VSTS.Common.AcceptanceCriteria" --tech-field "Custom.TechnicalDetails" --rename
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🎯 Objective
|
||||
|
||||
1) Parse the spec to extract **Title**, **Description**, **Acceptance Criteria**, **Technical Details**.
|
||||
2) **Create or update** a PBI in **Azure DevOps** via **NGA MCP**, parented under **Feature** (unless `--update`).
|
||||
3) If `--rename` is used, move/rename the original spec file into a normalized folder path using Feature and PBI context.
|
||||
|
||||
---
|
||||
|
||||
## 🧩 Parsing Rules
|
||||
|
||||
### 🏷️ Title
|
||||
Use the first header (`#` or `##`) at the top of the spec.
|
||||
|
||||
### 📝 Description (Markdown ONLY — no AC/Tech here)
|
||||
Build from:
|
||||
- **Purpose & Outcomes → Intent** (bullets)
|
||||
- **Purpose & Outcomes → Success Signals** (bullets)
|
||||
- (Optional) one-paragraph summary from **Behavior Change → New Behavior**
|
||||
|
||||
> **Do not include** Acceptance Criteria or Technical Details in Description if those fields exist in ADO.
|
||||
|
||||
### ✅ Acceptance Criteria (Gherkin HTML)
|
||||
From **"5) Acceptance Criteria (Gherkin)"**, extract the **full Gherkin scenarios** including:
|
||||
- The `Feature:` line
|
||||
- Each complete `Scenario:` block with all `Given`, `When`, `Then`, `And` steps
|
||||
- Convert the entire Gherkin text to **HTML format** preserving structure (use `<pre>` and `<code>` tags or properly formatted HTML)
|
||||
- Do NOT create a simple checklist; keep the full Gherkin syntax as it is essential for test traceability.
|
||||
|
||||
### ⚙️ Technical Details
|
||||
Bullets composed of:
|
||||
- **Inputs → Key constraints**
|
||||
- **Scope → Included/Excluded** (condensed)
|
||||
- **Interfaces & Contracts** (names only — UI actions, endpoint names, event names)
|
||||
|
||||
---
|
||||
|
||||
## 🤖 Tool Usage — NGA MCP (Azure DevOps)
|
||||
|
||||
**Always use the configured project** (frontmatter `project`) unless `--project` overrides it.
|
||||
**Do not** call `projects.list`; resolve the project by name.
|
||||
|
||||
### Required capabilities
|
||||
- `nga-mcp.azdo.workitems.create`
|
||||
- `nga-mcp.azdo.workitems.update`
|
||||
- `nga-mcp.azdo.workitems.get`
|
||||
- `nga-mcp.azdo.workitems.fields` (to detect available fields on the PBI type)
|
||||
|
||||
### Field mapping (strict separation)
|
||||
1. Detect available fields for **Product Backlog Item** via `nga-mcp.azdo.workitems.fields`. Cache once per session.
|
||||
2. Determine target field names:
|
||||
- **Acceptance Criteria** target = `--ac-field` value if provided; else use `Microsoft.VSTS.Common.AcceptanceCriteria` **if present**; else `None`.
|
||||
- **Technical Details** target = `--tech-field` value if provided; else use a detected custom field containing "Technical" in its name; else `None`.
|
||||
3. Build payloads:
|
||||
- **System.WorkItemType**: `Product Backlog Item`
|
||||
- **System.Title**: `<Title>`
|
||||
- **System.Description**: **HTML** converted from **Description** only.
|
||||
- If AC target is `None`, append a `## Acceptance Criteria` section with full Gherkin (HTML formatted) to Description.
|
||||
- If Tech target is `None`, append a `## Technical Details` section (HTML) to Description.
|
||||
- **<AC target>** (when set): full Gherkin scenarios converted to HTML (preserve `Feature:`, `Scenario:`, `Given/When/Then/And` structure).
|
||||
- **<Tech target>** (when set): bullets converted to HTML.
|
||||
- **System.AssignedTo**, **System.Tags**: from flags if provided.
|
||||
|
||||
> This ensures that AC/Tech **do not get duplicated** into Description when dedicated fields are present.
|
||||
|
||||
### Parent Link Setup (on creation only, when Feature ID is provided)
|
||||
|
||||
After creating the PBI, add a parent-child relation to link the PBI under the Feature using a JSON Patch operation:
|
||||
|
||||
```json
|
||||
{
|
||||
"op": "add",
|
||||
"path": "/relations/-",
|
||||
"value": {
|
||||
"rel": "System.LinkTypes.Hierarchy-Reverse",
|
||||
"url": "https://dev.azure.com/pwc-us-prism/_apis/wit/workItems/{featureId}"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**CRITICAL**:
|
||||
- Do NOT modify the Feature (parent) - only update the child PBI
|
||||
- Do NOT use `System.Parent` field
|
||||
- Do NOT use 'replace' operation on relations
|
||||
- If creation-time relations aren't supported by NGA MCP, issue a follow-up PATCH on the newly created PBI with the same add operation
|
||||
|
||||
---
|
||||
|
||||
## 📝 Output Behavior — **Rename (Move original spec)**
|
||||
|
||||
- `{dir}` = directory of the original spec (e.g., `docs/specs`).
|
||||
- `{slug}` = kebab-case slug from the spec Title (e.g., `export-to-excel-e2e`).
|
||||
- `{id}` = PBI ID from ADO response (or `--update` value).
|
||||
- `{featureId}` = Feature work item ID provided as the second argument.
|
||||
- `{featureSlug}` = kebab-case slug from the Feature title when resolvable; otherwise derived from the spec title or left as `{featureId}` only.
|
||||
- When `--rename` is provided, the command will **move (not copy)** the original spec file to:
|
||||
- **Default pattern:** `{dir}/{featureId}-{featureSlug}/{id}-{slug}.md`
|
||||
- You may override with `--pattern` using placeholders `{dir}`, `{id}`, `{slug}`, `{featureId}`, `{featureSlug}`. The resolved path must remain under `{dir}`.
|
||||
- The move is atomic when supported by the OS; the original file is removed after a successful move. Parent directories are created if missing.
|
||||
|
||||
---
|
||||
|
||||
## 🔂 Steps (Agent)
|
||||
|
||||
1. Parse **Title**, **Description**, **AC**, **Tech** per **Parsing Rules**.
|
||||
- For AC: Extract the COMPLETE Gherkin syntax from the "5) Acceptance Criteria (Gherkin)" section (including Feature line, all Scenario blocks, and all Given/When/Then/And steps).
|
||||
2. Resolve project = frontmatter `project` or `--project`. (Do not list projects.)
|
||||
3. Detect field availability via `workitems.fields`.
|
||||
4. **Create** or **Update** the PBI with the field mapping above.
|
||||
- If creating a new PBI with a Feature ID provided, attempt to add the parent relation using the JSON Patch operation specified in "Parent Link Setup" section.
|
||||
- If creation-time relations aren't supported by the NGA MCP create function, immediately after creation perform a follow-up PATCH on the newly created PBI to add the relation with the same JSON Patch operation.
|
||||
- Do NOT modify the Feature (parent) work item.
|
||||
5. If `--rename`: compose the destination path and move the original spec file to that location (create parent directories as needed).
|
||||
|
||||
---
|
||||
|
||||
## 🛡️ Guardrails
|
||||
|
||||
- No source code edits; only one work item and (optional) one file move.
|
||||
- The destination must be within `{dir}`; abort if the resolved path escapes `{dir}`.
|
||||
- If ADO creation/update fails, do not move the file.
|
||||
- If AC/Tech fields are absent, append to Description; otherwise, keep Description clean.
|
||||
- **CRITICAL**: Extract the FULL Gherkin scenarios with all steps (Given/When/Then/And) - do NOT create simple checklist items. The Gherkin syntax is required for proper test traceability in Azure DevOps.
|
||||
|
||||
---
|
||||
|
||||
## ✅ Rename example (resulting path)
|
||||
|
||||
```markdown
|
||||
docs/specs/987654-export-to-excel/{id}-export-to-excel-e2e.md
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🚀 Prompt
|
||||
|
||||
```
|
||||
/create-pbi <spec-path> <feature-id> [--project "<name>"] [--area "<path>"] [--iteration "<path>"] [--assign "<user>"] [--tags "t1,t2"] [--update <pbi-id>] [--rename] [--pattern "{dir}/{featureId}-{featureSlug}/{id}-{slug}.md"] [--ac-field "Microsoft.VSTS.Common.AcceptanceCriteria"] [--tech-field "Custom.TechnicalDetails"]
|
||||
```
|
||||
@@ -1,73 +0,0 @@
|
||||
---
|
||||
title: "Save Plan — /save-plan"
|
||||
category: "planning"
|
||||
tags:
|
||||
- planning
|
||||
- documentation
|
||||
version: "1.0"
|
||||
description: "Save the current in-memory plan to disk mirroring the spec structure."
|
||||
---
|
||||
|
||||
# /save-plan — Save Plan to Disk
|
||||
|
||||
Save the current in-memory plan to disk (mirroring spec structure under `docs/plans/`).
|
||||
|
||||
---
|
||||
|
||||
## Syntax
|
||||
|
||||
```bash
|
||||
/save-plan --spec @<original-spec-path>
|
||||
```
|
||||
|
||||
- `--spec @<original-spec-path>` (required): Original spec path to mirror structure
|
||||
|
||||
---
|
||||
|
||||
## Behavior
|
||||
|
||||
1) Read the current in-memory plan from Cursor's Plan mode.
|
||||
2) Determine output path by mirroring the spec's subpath:
|
||||
- Spec: `docs/specs/<subpath>/<filename>.md`
|
||||
- Plan: `docs/plans/<subpath>/<filename>.md`
|
||||
3) Ensure parent directories exist; write the plan atomically.
|
||||
4) Return saved plan path.
|
||||
|
||||
---
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- Cursor is in Plan mode with an active plan
|
||||
- Original spec exists at the provided path
|
||||
|
||||
---
|
||||
|
||||
## Usage
|
||||
|
||||
After generating a plan in Plan mode:
|
||||
|
||||
```bash
|
||||
/save-plan --spec @docs/specs/888568-language-content-service-implementation-execute/920755-export-to-excel-backend-frontend-and-filters.md
|
||||
```
|
||||
|
||||
This writes plan to: `docs/plans/888568-language-content-service-implementation-execute/920755-export-to-excel-backend-frontend-and-filters.md`
|
||||
|
||||
---
|
||||
|
||||
## Example
|
||||
|
||||
Command:
|
||||
```bash
|
||||
/save-plan --spec @docs/specs/924274-jadx-test/924326-dashboard-export-to-excel.md
|
||||
```
|
||||
|
||||
Result:
|
||||
- Plan saved to `docs/plans/924274-jadx-test/924326-dashboard-export-to-excel.md`
|
||||
|
||||
---
|
||||
|
||||
## Notes
|
||||
|
||||
- Only works when a plan exists in memory (Plan mode)
|
||||
- If plan file already exists, it's overwritten
|
||||
- Preserves the original plan structure and todos as-is
|
||||
+25
-41
@@ -1,9 +1,11 @@
|
||||
# Generate Feature Specification
|
||||
|
||||
Create a focused behavioral specification that describes **what** the system should do, not **how** it should be built.
|
||||
|
||||
## Objective
|
||||
## Input parameter
|
||||
building_block.md
|
||||
Example: `03_building_blocks/01-dashboard-export-example.md`
|
||||
|
||||
## Objective
|
||||
Generate lean specifications with:
|
||||
- Clear problem statement and desired outcomes
|
||||
- Behavioral acceptance criteria in Gherkin format
|
||||
@@ -11,12 +13,13 @@ Generate lean specifications with:
|
||||
- No implementation prescriptiveness
|
||||
|
||||
## Process
|
||||
|
||||
1. Read the building block or feature description
|
||||
1. Read the building_block.md
|
||||
2. Analyze the codebase to understand context
|
||||
3. Generate a behavioral specification using the structure below
|
||||
4. **DO NOT** include implementation details, file structures, or technical architecture
|
||||
5. Focus on behavior, user experience, and acceptance criteria
|
||||
6. Save the specification into the `03_feature_specs/spec.md`
|
||||
Example: `03_feature_specs/01-dashboard-export-example.md`
|
||||
|
||||
## Specification Structure
|
||||
|
||||
@@ -34,31 +37,24 @@ Clear, concise statement of the problem users are facing.
|
||||
Measurable or observable goals/benefits (use bullet points).
|
||||
|
||||
### Scope
|
||||
|
||||
#### Included
|
||||
What's in scope for this feature (bullet points).
|
||||
|
||||
#### Excluded
|
||||
Explicitly what's **NOT** in scope (bullet points).
|
||||
|
||||
### Acceptance Criteria
|
||||
|
||||
Each acceptance criterion should be:
|
||||
- Numbered sequentially (AC-1, AC-2, etc.)
|
||||
- Include a brief title
|
||||
- Written in Gherkin format (Given/When/Then)
|
||||
|
||||
Example:
|
||||
```markdown
|
||||
**AC-1: Export Availability**
|
||||
```
|
||||
Given the user is viewing the dashboard
|
||||
When the dashboard loads
|
||||
Then an "Export to Excel" button should be visible in the filter/actions area
|
||||
```
|
||||
**AC-1: Export Availability**
|
||||
Given the user is viewing the dashboard
|
||||
When the dashboard loads
|
||||
Then an "Export to Excel" button should be visible in the filter/actions area
|
||||
|
||||
### Non-Functional Requirements
|
||||
|
||||
Only include essential non-functional requirements:
|
||||
- Performance (if relevant)
|
||||
- Compatibility (if relevant)
|
||||
@@ -66,6 +62,18 @@ Only include essential non-functional requirements:
|
||||
|
||||
Use sub-sections with bullet points.
|
||||
|
||||
### Unit tests based on Acceptance Criteria
|
||||
- Acceptance criteria references
|
||||
- What should be tested
|
||||
- Required outcome
|
||||
|
||||
### Integration tests based on Acceptance Criteria and/or Non-Functional requirements
|
||||
- Acceptance criteria references
|
||||
- Initial data and conditions
|
||||
- What should be tested
|
||||
- How system should behave
|
||||
- List of Non-functional requiremnts to be met
|
||||
|
||||
### Constraints
|
||||
|
||||
High-level constraints that guide implementation:
|
||||
@@ -82,10 +90,7 @@ Each risk should have:
|
||||
- *Risk*: Description
|
||||
- *Mitigation*: Approach
|
||||
|
||||
---
|
||||
|
||||
## Output Guidelines
|
||||
|
||||
**DO:**
|
||||
- Focus on behavior and user experience
|
||||
- Use clear, simple language
|
||||
@@ -101,6 +106,8 @@ Each risk should have:
|
||||
- Include step-by-step implementation instructions
|
||||
- Add "how to build" guidance
|
||||
|
||||
|
||||
|
||||
## Example
|
||||
|
||||
```markdown
|
||||
@@ -108,51 +115,37 @@ Each risk should have:
|
||||
|
||||
**Status**: Draft | **Date**: 2025-01-XX | **Feature**: Export Dashboard Data to Excel
|
||||
|
||||
---
|
||||
|
||||
## Problem
|
||||
|
||||
Users currently have no efficient way to export dashboard data for offline analysis, reporting, or sharing. Manual copy-paste is time-consuming, error-prone, and lacks context about active filters.
|
||||
|
||||
## Outcome
|
||||
|
||||
- Eliminate manual copy-paste workflows
|
||||
- Enable accurate data sharing with proper context
|
||||
- Measurable time savings (target: <30s vs. several minutes)
|
||||
- Improved data consistency for offline analysis
|
||||
|
||||
## Scope
|
||||
|
||||
### Included
|
||||
- Export filtered dashboard data to Excel
|
||||
- Single-click export from dashboard view
|
||||
- Respect all active filters (status, date range)
|
||||
|
||||
### Excluded
|
||||
- CSV or PDF export options
|
||||
- Scheduled or automated exports
|
||||
- Email export functionality
|
||||
|
||||
---
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
**AC-1: Export Button Visibility**
|
||||
```
|
||||
Given the user is viewing the dashboard
|
||||
When the dashboard loads
|
||||
Then an "Export to Excel" button should be visible in the actions area
|
||||
```
|
||||
|
||||
**AC-2: Basic Export Functionality**
|
||||
```
|
||||
Given the user is viewing the dashboard with data
|
||||
When the user clicks the "Export to Excel" button
|
||||
Then an Excel file should download to their default location
|
||||
And the filename should include a timestamp
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Non-Functional Requirements
|
||||
|
||||
@@ -164,27 +157,18 @@ And the filename should include a timestamp
|
||||
- Excel files openable in Microsoft Excel, Google Sheets, and LibreOffice
|
||||
- Standard Excel format (.xlsx)
|
||||
|
||||
---
|
||||
|
||||
## Constraints
|
||||
|
||||
- Must respect all currently active filters
|
||||
- Must follow existing hexagonal architecture patterns
|
||||
- No breaking changes to existing functionality
|
||||
|
||||
---
|
||||
|
||||
## Risks & Mitigation
|
||||
|
||||
**Risk 1: Excel File Compatibility**
|
||||
- *Risk*: Generated files don't open correctly in all spreadsheet applications
|
||||
- *Mitigation*: Use standard Excel format, test with multiple applications
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Implementation Notes
|
||||
|
||||
- Use descriptive but concise titles
|
||||
- Keep specifications focused and scoped appropriately
|
||||
- Remember: This is a **behavioral spec**, not an implementation plan
|
||||
@@ -0,0 +1,64 @@
|
||||
# Generate Jira Task from Spec (via Jira MCP)
|
||||
Create or update a *Jira ticket** from a specification feature_spec.md
|
||||
|
||||
## 🔧 Inputs
|
||||
- feature_spec.md (required): path to the source spec file.
|
||||
Example: `@_docs/03_feature_specs/spec-export-e2e.md`
|
||||
|
||||
- epic <Epic-Id> (required for Jira task creation): create Jira task under parent epic, for example:
|
||||
Example: /3.30_generate_jira_task @_docs/03_specs/spec-export-e2e.md epic AZ-112
|
||||
|
||||
- update <Task-Id> (required for Jira task update): update existing Jira task, for example:
|
||||
Example: /3.30_generate_jira_task @_docs/03_specs/spec-export-e2e.md update AZ-151
|
||||
|
||||
## 🎯 Objective
|
||||
1. Parse the spec to extract **Title**, **Description**, **Acceptance Criteria**, **Technical Details**.
|
||||
2. Create a Jira Task under Epic or Update existing Jira Task using **Jira MCP**
|
||||
|
||||
## 🧩 Parsing Rules
|
||||
|
||||
### 🏷️ Title
|
||||
Use the first header (`#` or `##`) at the top of the spec.
|
||||
|
||||
### 📝 Description (Markdown ONLY — no AC/Tech here)
|
||||
Build from:
|
||||
- **Purpose & Outcomes → Intent** (bullets)
|
||||
- **Purpose & Outcomes → Success Signals** (bullets)
|
||||
- (Optional) one-paragraph summary from **Behavior Change → New Behavior**
|
||||
> **Do not include** Acceptance Criteria or Technical Details in Description if those fields exist in Jira.
|
||||
|
||||
### ✅ Acceptance Criteria (Gherkin HTML)
|
||||
From **"Acceptance Criteria (Gherkin)"**, extract the **full Gherkin scenarios** including:
|
||||
- The `Feature:` line
|
||||
- Each complete `Scenario:` block with all `Given`, `When`, `Then`, `And` steps
|
||||
- Convert the entire Gherkin text to **HTML format** preserving structure (use `<pre>` and `<code>` tags or properly formatted HTML)
|
||||
- Do NOT create a simple checklist; keep the full Gherkin syntax as it is essential for test traceability.
|
||||
|
||||
### ⚙️ Technical Details
|
||||
Bullets composed of:
|
||||
- **Inputs → Key constraints**
|
||||
- **Scope → Included/Excluded** (condensed)
|
||||
- **Interfaces & Contracts** (names only — UI actions, endpoint names, event names)
|
||||
After creating the PBI, add a parent-child relation to link the Task under the Epic
|
||||
**CRITICAL**:
|
||||
- Do NOT modify the parent Epic - only update the child Task
|
||||
|
||||
## 🔂 Steps (Agent)
|
||||
|
||||
1. Parse **Title**, **Description**, **AC**, **Tech** per **Parsing Rules**.
|
||||
- For AC: Extract the COMPLETE Gherkin syntax from the "Acceptance Criteria (Gherkin)" section (including Feature line, all Scenario blocks, and all Given/When/Then/And steps).
|
||||
2. **Create** or **Update** the Task with the field mapping above.
|
||||
- If creating a new Task with a Epic provided, add the parent relation
|
||||
- Do NOT modify the parent Epic work item.
|
||||
3. Raname spec.md and corresponding building
|
||||
- Rename `_docs/03_specs/{taskId}-{taskNameSlug}.md`
|
||||
- Rename `_docs/03_building_blocks/{taskId}-{taskNameSlug}.md`
|
||||
{taskId} is Jira task Id which either was just created, either provided in update argument
|
||||
{taskNameSlug} is a kebab-case slug from the Jira Task title when update argument is provided, or derived from the spec title.
|
||||
|
||||
## 🛡️ Guardrails
|
||||
- No source code edits; only one work item and (optional) one file move.
|
||||
- If Jira creation/update fails, do not move the file.
|
||||
- If AC/Tech fields are absent, append to Description; otherwise, keep Description clean.
|
||||
- **CRITICAL**: Extract the FULL Gherkin scenarios with all steps (Given/When/Then/And) - do NOT create simple checklist items. The Gherkin syntax is required for proper test traceability in Jira
|
||||
- Do not edit parent Epic
|
||||
@@ -0,0 +1,10 @@
|
||||
---
|
||||
description: Coding and component architecture rules
|
||||
alwaysApply: false
|
||||
---
|
||||
- Follow SOLID principles
|
||||
- Follow KISS principle.
|
||||
- Follow principle: Dumb code - smart data.
|
||||
- Follow DRY principles, but do not overcomplicate things, if small or even medium code duplication (sometimes even 2 times) would make solution easier - go for it.
|
||||
Deduplicate code concepts if it is clear reusing pattern and semantically can be easily distinguish in reusable component
|
||||
- Follow conventions and rules of the project's programming language
|
||||
@@ -0,0 +1,22 @@
|
||||
---
|
||||
description: Coding
|
||||
alwaysApply: false
|
||||
---
|
||||
# Coding rules
|
||||
|
||||
- Always prefer simple solution
|
||||
- Generate concise code
|
||||
- Do not put comments in the code
|
||||
- Do not put logs unless it is an exception, or was asked specifically
|
||||
- Do not put code annotations unless it was asked specifically
|
||||
- Your changes should be well correlated with what was requested. In case of any uncertainties ask questions.
|
||||
- Mocking data is needed only for tests
|
||||
- When you add new libraries or dependencies make sure you are using the same version of it as other parts of the code
|
||||
|
||||
- Focus on the areas of code relevant to the task
|
||||
- Do not touch code that is unrelated to the task
|
||||
- Always think about what other methods and areas of code might be affected by the code changes
|
||||
- When you think you are done with changes, run tests and make sure they are not broken
|
||||
- Do not rename any databases or tables or table columns without confirmation. Avoid such renaming if possible.
|
||||
- Do not create diagrams unless I ask explicitly
|
||||
- Do not commit binaries, create and keep .gitignore up to date and delete binaries after you are done with the task
|
||||
@@ -0,0 +1,18 @@
|
||||
---
|
||||
description: Coding
|
||||
alwaysApply: false
|
||||
---
|
||||
- Use collection expressions for collection initialization
|
||||
- Non-derived "private" classes and records should be "sealed"
|
||||
- In tests Use 'Assert.ThrowsExactly' instead of 'Assert.ThrowsException'
|
||||
- Parameter names should match base declaration and other partial definitions
|
||||
- Exceptions should be either logged or rethrown but not both
|
||||
- Exceptions should not be thrown from property getters
|
||||
- A Route attribute should be added to the controller when a route template is specified at the action level
|
||||
- "Thread.Sleep" should not be used in tests
|
||||
- Maintain consistent whitespace formatting with blank lines between logical code blocks
|
||||
- Cognitive Complexity of methods should not be too high
|
||||
- Avoid constant arrays as arguments
|
||||
- Server-side requests should not be vulnerable to traversing attacks
|
||||
- String literals should not be duplicated
|
||||
- Value type property used as input in a controller action should be nullable, required or annotated with the JsonRequiredAttribute to avoid under-posting
|
||||
@@ -0,0 +1,9 @@
|
||||
# Building Block: Dashboard Export to Excel
|
||||
|
||||
## Problem / Goal
|
||||
Users need to export the dashboard data they’re currently viewing into Excel for offline analysis and sharing.
|
||||
|
||||
##
|
||||
|
||||
## Outcome
|
||||
Export dashboard data functionality. Expo
|
||||
@@ -1,7 +1,7 @@
|
||||
# 1 Research Phase
|
||||
|
||||
|
||||
## 1.0 Problem statement
|
||||
## **🧑💻 Developers**: 1.0 Problem statement
|
||||
### Discuss
|
||||
Discuss the problem and create in the `_docs/00_problem` next files and folders:
|
||||
- `problem_description.md`: Our problem to solve with the end result we want to achieve.
|
||||
@@ -47,7 +47,7 @@
|
||||
- Overwrite `acceptance_criteria.md` and `restrictions.md`
|
||||
|
||||
|
||||
## 1.2 **✨AI Research**: Research the problem in great detail
|
||||
## 1.2 **🤖✨AI Research**: Research the problem in great detail
|
||||
|
||||
### Execute `/1.research/1.2_research_problem`
|
||||
In case of external DeepResearch (Gemini, DeepSeek, or other), copypaste command's text and put to the research context:
|
||||
@@ -63,7 +63,7 @@
|
||||
- Store it to the `_docs/01_solution/solution_draft.md`
|
||||
|
||||
|
||||
## 1.3 **✨AI Research**: Solution draft assessment
|
||||
## 1.3 **🤖✨AI Research**: Solution draft assessment
|
||||
|
||||
### Execute `/1.research/1.3_solution_draft_assessment`
|
||||
In case of external DeepResearch (Gemini, DeepSeek, or other), copypaste command's text and put to the research context:
|
||||
@@ -99,7 +99,7 @@
|
||||
- Save plan to `_docs/02_components/00_decomposition_plan.md`
|
||||
|
||||
|
||||
## 2.15 **🤖AI agent**: Components assesment
|
||||
## 2.15 **🤖📋AI plan**: Components assesment
|
||||
|
||||
### Execute `/2.planning/2.15_components_assesment`
|
||||
|
||||
@@ -116,26 +116,26 @@
|
||||
"url": "https://mcp.atlassian.com/v1/sse"
|
||||
}
|
||||
```
|
||||
### Execute `/2.planning/2.20_gen_epics use jira mcp`
|
||||
### Execute `/2.planning/2.20_plan_jira_epics`
|
||||
|
||||
### Revise
|
||||
- Revise the epics, answer questions, put detailed descriptions
|
||||
- Make sure epics are coherent and make sense
|
||||
|
||||
|
||||
## 2.30 **🤖AI agent**: Generate tests
|
||||
## 2.30 **🤖📋AI plan**: Generate tests
|
||||
|
||||
### Execute `/2.planning/2.30_gen_tests`
|
||||
### Execute `/2.planning/2.30_plan_tests`
|
||||
|
||||
### Revise
|
||||
- Revise the tests, answer questions, put detailed descriptions
|
||||
- Make sure stored tests are coherent and make sense
|
||||
|
||||
|
||||
## 2.40 **🤖📋AI agent**: Component Decomposition To Features
|
||||
## 2.40 **🤖📋AI plan**: Component Decomposition To Features
|
||||
### Execute
|
||||
For each component in `_docs/02_components` run
|
||||
`/2.planning/2.40_gen_features --component @xx__spec_[component_name].md`
|
||||
`/2.planning/2.40_plan_features_decompose --component @xx__spec_[component_name].md`
|
||||
|
||||
### Revise
|
||||
- Revise the features, answer questions, put detailed descriptions
|
||||
@@ -195,19 +195,10 @@
|
||||
- Read the code and check that everything is ok
|
||||
|
||||
|
||||
## 3.20 **🤖AI agent**: Solution composition and integration tests
|
||||
## 3.20 **🤖📋AI plan**: Integration tests and solution checks
|
||||
|
||||
|
||||
Read all the files here `_docs/03_tests/` and for each file write down tests and run it.
|
||||
Compose a final test results in a csv with the next format:
|
||||
- Test filename
|
||||
- Execution time
|
||||
- Result
|
||||
|
||||
Fix all problems if tests failed until we got a successful result.
|
||||
In case if one or more tests was failed due to missing data from user or API or other system, ask it from developer.
|
||||
Repeat test cycle until no failed tests.
|
||||
|
||||
|
||||
|
||||
# 4. Refactoring phase
|
||||
### Execute `/3.implementation/3.20_implement_tests`
|
||||
|
||||
### Revise
|
||||
- Revise the plan, answer questions, put detailed descriptions
|
||||
- Make sure tests are coherent and make sense
|
||||
@@ -0,0 +1,39 @@
|
||||
# Iterative Implementation phase
|
||||
|
||||
## 10 **🧑💻 Developers**: Form a building block
|
||||
|
||||
### Form a building block in the next format:
|
||||
```
|
||||
# Building Block: Title
|
||||
|
||||
## Problem / Goal
|
||||
Short description of the problem we have to solve or what the end goal we need to achieve. 2-3 lines
|
||||
|
||||
## Architecture Notes (optional)
|
||||
How it should be implemented. Which subsystem to use, short explanation of the 3-5 lines.
|
||||
|
||||
## Outcome
|
||||
What we waht to achieve
|
||||
```
|
||||
### Example
|
||||
`_docs/iterative/building_blocks/01-dashboard-export-example.md`
|
||||
|
||||
## 20. **🤖AI agent**: Generate Feature Specification
|
||||
### Execute `/gen_feature_spec`
|
||||
|
||||
## 30. **🤖AI agent**: Generate Jira ticket
|
||||
### Execute `/gen_jira_task`
|
||||
|
||||
## 40. **🤖📋AI plan**: Generate Plan
|
||||
### Execute
|
||||
generate plan for `@_docs/iterative/feature_specs/spec.md`
|
||||
Example:
|
||||
generate plan for `@_docs/iterative/feature_specs/01-dashboard-export-example.md`
|
||||
|
||||
## 50. **🧑💻 Developer**: Save the plan
|
||||
Save the generated plan to `@_docs/iterative/plans`.
|
||||
(First, save with built-in mechanism to .cursor folder, then move to this folder `@_docs/iterative/plans`)
|
||||
|
||||
## 60. Build from the plan
|
||||
|
||||
## Check build and tests are successful.
|
||||
Reference in New Issue
Block a user