mirror of
https://github.com/bitwarden/android.git
synced 2026-04-30 04:49:36 -05:00
This commit introduces a set of standardized templates for common software engineering tasks to be used with Claude. These templates aim to streamline workflows and ensure consistent, high-quality outputs for tasks like code explanation, code review, refactoring, and implementation planning. The new command templates are: - `code-explainer.md`: To explain code at a high level, detailing its function, data flow, dependencies, and potential risks. - `code-review.md`: To provide structured, actionable feedback on a pull request, covering correctness, style, security, and performance. - `file-cleaner.md`: To improve the readability of a source file without altering its behavior, focusing on naming, comments, and formatting. - `implement-it.md`: To translate a user story or ticket into a detailed implementation plan, including architecture, code skeletons, and tests. - `refactor.md`: To guide the refactoring of legacy code towards a specific goal, emphasizing safety through tests and incremental changes. - `task-creator.md`: To break down a feature specification into smaller, sprint-ready engineering tasks. - `test-writer.md`: To generate thorough tests for a function or module, covering unit, integration, and property-based testing.
78 lines
1.5 KiB
Markdown
78 lines
1.5 KiB
Markdown
Use this template to turn a user story into a concrete plan, skeletons, and tests.
|
|
|
|
## INPUTS
|
|
|
|
- Ticket - the user story or ticket to implement
|
|
- (optional) Non-functional requirements
|
|
- (optional) Acceptance criteria
|
|
- (optional) Code - existing code context
|
|
|
|
## INSTRUCTIONS
|
|
|
|
1. Extract goals, actors, and constraints from the ticket.
|
|
2. Make explicit assumptions and edge cases.
|
|
3. Produce a step-by-step plan across affected layers:
|
|
- Frontend (web/mobile applications)
|
|
- APIs (backend services)
|
|
- Integrations (messaging, external services)
|
|
- Data (databases, data warehouses, ETL)
|
|
- Authentication/authorization systems
|
|
4. Provide key code skeletons and interface contracts.
|
|
5. Define tests to add (unit, integration, e2e).
|
|
6. Include rollout, feature flag, and observability plan.
|
|
7. Keep lines ≤80 chars.
|
|
|
|
## OUTPUT FORMAT
|
|
|
|
### Story summary
|
|
|
|
- **Goal:**
|
|
- **Users:**
|
|
- **Success criteria:**
|
|
|
|
### Assumptions & constraints
|
|
|
|
- ...
|
|
|
|
### Step-by-step plan
|
|
|
|
1. ...
|
|
2. ...
|
|
|
|
### Architecture impact
|
|
|
|
- **Modules/services:**
|
|
- **Events/messaging:**
|
|
- **Schemas/migrations:**
|
|
|
|
### API & model contracts (sketch)
|
|
|
|
### Key code skeletons
|
|
|
|
- **Components/services:**
|
|
- **Workers/consumers:**
|
|
- **Repositories/queries:**
|
|
|
|
### Tests to add
|
|
|
|
- **Unit:**
|
|
- **Integration:**
|
|
- **e2e:**
|
|
- **Property/fuzz:**
|
|
- **Load:**
|
|
|
|
### Rollout & safety
|
|
|
|
- **Feature flag:**
|
|
- **Backward compatibility:**
|
|
- **Metrics/logs/traces:**
|
|
- **Runbook:**
|
|
|
|
### Risks & mitigations
|
|
|
|
- ...
|
|
|
|
### Definition of done
|
|
|
|
- ...
|