update DoD

This commit is contained in:
2026-04-29 00:27:30 +07:00
parent 0d9230bd5f
commit c616fcf037
4 changed files with 79 additions and 14 deletions
+21 -3
View File
@@ -33,6 +33,8 @@ description: Phase 2 skill. Use when issue scope is locked by Product Owner (Pha
3. **Write plan and post on issue**
- List implementation steps with verification criteria.
- List files to change.
- State whether `README.md` or `.env.example` must change.
- State whether an ADR is required or not required.
- Flag risks or tradeoffs.
- Post plan as comment: `mcp__gitea__.issue_write` (`method: "add_comment"`).
- **Wait for "Approved" before coding.** Stop here.
@@ -48,18 +50,32 @@ description: Phase 2 skill. Use when issue scope is locked by Product Owner (Pha
git worktree add .worktrees/<branch-name> main
```
- Implement following the plan (surgical changes only).
- Update `README.md` and `.env.example` when config, endpoint, or runtime behavior changes.
- If the change introduces a durable behavior, contract, architecture, or workflow decision, create/update `docs/adr/**`.
- Run validation:
```
gofmt -l .
go vet ./...
go test ./...
go vet ./...
staticcheck ./...
```
- Post an implementation summary comment on the issue with sections:
- `Summary`
- `Changes`
- `Test Plan`
- `Refactor`
- `Docs/ADR`
- `Risks/Follow-ups`
5. **Create PR**
- Use `mcp__gitea__.pull_request_write` (`method: "create"`).
- PR body must include:
- Summary of changes
- Test evidence (exact commands and output)
- `Summary`
- `Changes`
- `Test Plan` with exact commands and output
- `Refactor`
- `Docs/ADR`
- `Risks/Follow-ups`
- `Fixes #<issue-id>`
- Add reviewer.
@@ -76,6 +92,8 @@ description: Phase 2 skill. Use when issue scope is locked by Product Owner (Pha
- Use Gitea MCP tools for all issue/PR operations.
- Preserve existing assignees when adding yourself unless the user explicitly asks to replace them.
- Never edit remote files directly — always work on local branch.
- Satisfy the repo Definition of Done before claiming completion.
- Missing required tests, docs, `.env.example` updates, or ADRs is a quality failure unless explicitly justified in both the issue comment and PR body.
- Never claim completion without fresh verification output.
- Keep changes strictly scoped to the approved plan.
- If the change needs durable documentation, create/update `docs/adr/**`. Do not commit `docs/superpowers/**` planning artifacts.