mirror of
https://github.com/azaion/gps-denied-onboard.git
synced 2026-04-23 04:06:37 +00:00
Update README and implementer documentation to reflect changes in task orchestration and structure. Remove obsolete commands and templates related to initial implementation and code review. Enhance task decomposition workflow and clarify input specifications for improved task management.
This commit is contained in:
Oleksandr Bezdieniezhnykh
@@ -1,38 +0,0 @@
|
||||
# Code Review
|
||||
|
||||
## Initial data:
|
||||
- Problem description: `@_docs/00_problem/problem_description.md`.
|
||||
- Acceptance criteria: `@_docs/00_problem/acceptance_criteria.md`.
|
||||
- Security approach: `@_docs/00_problem/security_approach.md`.
|
||||
- Full Solution Description: `@_docs/01_solution/solution.md`
|
||||
- Components: `@_docs/02_components`
|
||||
|
||||
## Role
|
||||
You are a senior software engineer performing code review
|
||||
|
||||
## Task
|
||||
- Review implemented code against component specifications
|
||||
- Check code quality: readability, maintainability, SOLID principles
|
||||
- Check error handling consistency
|
||||
- Check logging implementation
|
||||
- Check security requirements are met
|
||||
- Check test coverage is adequate
|
||||
- Identify code smells and technical debt
|
||||
|
||||
## Output
|
||||
### Issues Found
|
||||
For each issue:
|
||||
- File/Location
|
||||
- Issue type (Bug/Security/Performance/Style/Debt)
|
||||
- Description
|
||||
- Suggested fix
|
||||
- Priority (High/Medium/Low)
|
||||
|
||||
### Summary
|
||||
- Total issues by type
|
||||
- Blocking issues that must be fixed
|
||||
- Recommended improvements
|
||||
|
||||
## Notes
|
||||
- Can also use Cursor's built-in review feature
|
||||
- Focus on critical issues first
|
||||
@@ -1,53 +0,0 @@
|
||||
# Implement Initial Structure
|
||||
|
||||
## Input
|
||||
- Structure plan: `_docs/02_tasks/<topic>/initial_structure.md` (produced by decompose skill)
|
||||
|
||||
## Context
|
||||
- Problem description: `@_docs/00_problem/problem.md`
|
||||
- Restrictions: `@_docs/00_problem/restrictions.md`
|
||||
- Solution: `@_docs/01_solution/solution.md`
|
||||
|
||||
## Role
|
||||
You are a professional software architect
|
||||
|
||||
## Task
|
||||
- Read carefully the structure plan in `initial_structure.md`
|
||||
- Execute the plan — create the project skeleton:
|
||||
- DTOs and shared models
|
||||
- Component interfaces
|
||||
- Empty implementations (stubs)
|
||||
- Helpers — empty implementations or interfaces
|
||||
- Add .gitignore appropriate for the project's language/framework
|
||||
- Add .env.example with required environment variables
|
||||
- Configure CI/CD pipeline per the structure plan stages
|
||||
- Apply environment strategy (dev, staging, production) per the structure plan
|
||||
- Add database migration setup if applicable
|
||||
- Add README.md, describe the project based on the solution
|
||||
- Create test folder structure per the structure plan
|
||||
- Configure branch protection rules recommendations
|
||||
|
||||
## Example
|
||||
The structure should roughly look like this (varies by tech stack):
|
||||
- .gitignore
|
||||
- .env.example
|
||||
- .github/workflows/ (or .gitlab-ci.yml or azure-pipelines.yml)
|
||||
- api/
|
||||
- components/
|
||||
- component1_folder/
|
||||
- component2_folder/
|
||||
- db/
|
||||
- migrations/
|
||||
- helpers/
|
||||
- models/
|
||||
- tests/
|
||||
- unit/
|
||||
- integration/
|
||||
- test_data/
|
||||
|
||||
Semantically coherent components may have their own project or subfolder. Common interfaces can be in a shared layer or per-component — follow language conventions.
|
||||
|
||||
## Notes
|
||||
- Follow SOLID, KISS, DRY
|
||||
- Follow conventions of the project's programming language
|
||||
- Ask as many questions as needed
|
||||
@@ -1,62 +0,0 @@
|
||||
# Implement Next Wave
|
||||
|
||||
Identify the next batch of independent features and implement them in parallel using the implementer subagent.
|
||||
|
||||
## Prerequisites
|
||||
- Project scaffolded (`/implement-initial` completed)
|
||||
- `_docs/02_tasks/<topic>/SUMMARY.md` exists
|
||||
- `_docs/02_tasks/<topic>/cross_dependencies.md` exists
|
||||
|
||||
## Wave Sizing
|
||||
- One wave = one phase from SUMMARY.md (features whose dependencies are all satisfied)
|
||||
- Max 4 subagents run concurrently; features in the same component run sequentially
|
||||
- If a phase has more than 8 features or more than 20 complexity points, suggest splitting into smaller waves and let the user cherry-pick which features to include
|
||||
|
||||
## Task
|
||||
|
||||
1. **Read the implementation plan**
|
||||
- Read `SUMMARY.md` for the phased implementation order
|
||||
- Read `cross_dependencies.md` for the dependency graph
|
||||
|
||||
2. **Detect current progress**
|
||||
- Analyze the codebase to determine which features are already implemented
|
||||
- Match implemented code against feature specs in `_docs/02_tasks/<topic>/`
|
||||
- Identify the next incomplete wave/phase from the implementation order
|
||||
|
||||
3. **Present the wave**
|
||||
- List all features in this wave with their complexity points
|
||||
- Show which component each feature belongs to
|
||||
- Confirm total features and estimated complexity
|
||||
- If the phase exceeds 8 features or 20 complexity points, recommend splitting and let user select a subset
|
||||
- **BLOCKING**: Do NOT proceed until user confirms
|
||||
|
||||
4. **Launch parallel implementation**
|
||||
- For each feature in the wave, launch an `implementer` subagent in background
|
||||
- Each subagent receives the path to its feature spec file
|
||||
- Features within different components can run in parallel
|
||||
- Features within the same component should run sequentially to avoid file conflicts
|
||||
|
||||
5. **Monitor and report**
|
||||
- Wait for all subagents to complete
|
||||
- Collect results from each: what was implemented, test results, any issues
|
||||
- Run the full test suite
|
||||
- Report summary:
|
||||
- Features completed successfully
|
||||
- Features that failed or need manual attention
|
||||
- Test results (passed/failed/skipped)
|
||||
- Any mocks created for future-wave dependencies
|
||||
|
||||
6. **Post-wave actions**
|
||||
- Suggest: `git add . && git commit` with a wave-level commit message
|
||||
- If all features passed: "Ready for next wave. Run `/implement-wave` again."
|
||||
- If some failed: "Fix the failing features before proceeding to the next wave."
|
||||
|
||||
## Safety Rules
|
||||
- Never launch features whose dependencies are not yet implemented
|
||||
- Features within the same component run sequentially, not in parallel
|
||||
- If a subagent fails, do NOT retry automatically — report and let user decide
|
||||
- Always run tests after the wave completes, before suggesting commit
|
||||
|
||||
## Notes
|
||||
- Ask questions if the implementation order is ambiguous
|
||||
- If SUMMARY.md or cross_dependencies.md is missing, stop and inform the user to run the decompose skill first
|
||||
Reference in New Issue
Block a user