Your Name
2dabf8ef03
- memory/: cross-session project memory with decisions, lessons, failures, architecture, and sessions categories. Each has format templates and lifecycle documentation. - skills/: 12 reusable specialized methodologies (tdd, systematic-debugging, architecture-design, code-review, security-review, repository-analysis, failure-analysis, refactoring, test-analysis, incident-investigation, browser-automation, research). Each has frontmatter and methodology sections. - improvements/: proposal-based improvement system requiring human approval. - scripts/memory-lifecycle.sh: deterministic memory operations (recall, store, list, search, sessions, cleanup). - scripts/test-memory-system.sh: 12 structural tests for all new systems. - orchestrator.md: added Memory Recall stage, Learning and Memory Storage stage, Improvement Proposals workflow, memory/skills rules, and 3 new actions (A23-A27) to the action catalog. Updated behavioral acceptance test and state separation model. - All 12 subagents: added Memory & Skills Awareness sections with recall and store instructions. - docs/AGENT_ARCHITECTURE.md: documented memory, skills, and improvements systems (sections 12-14). Updated action count (27), state model, and remaining weaknesses. - README.md: documented new systems, updated repository layout, added test-memory-system.sh documentation. All 39 tests pass (16 architecture + 12 memory + 11 bootstrap).
72 lines
1.9 KiB
Markdown
72 lines
1.9 KiB
Markdown
---
|
|
name: code-review
|
|
description: Code review process — systematic review of changes for quality, correctness, and maintainability
|
|
version: "1.0"
|
|
owner: Reviewer
|
|
prerequisites: implementation completed, tests passing
|
|
---
|
|
|
|
# Code Review
|
|
|
|
## When to use this skill
|
|
|
|
- Before accepting a completed implementation
|
|
- When reviewing a pull request or change set
|
|
- When verifying scope compliance
|
|
|
|
## Core methodology
|
|
|
|
```text
|
|
READ CHANGES → CHECK CORRECTNESS → CHECK SCOPE → CHECK TESTS → CHECK DESIGN → CHECK SAFETY → VERDICT
|
|
```
|
|
|
|
## Review checklist
|
|
|
|
### Correctness
|
|
- [ ] Does the code do what it claims?
|
|
- [ ] Does it handle edge cases?
|
|
- [ ] Are error paths handled?
|
|
- [ ] Are there off-by-one errors?
|
|
|
|
### Scope compliance
|
|
- [ ] Does the change match the approved scope?
|
|
- [ ] Is there unauthorized scope expansion?
|
|
- [ ] Are only the files that should change actually changed?
|
|
|
|
### Tests
|
|
- [ ] Do tests verify the behavior (not implementation)?
|
|
- [ ] Are edge cases tested?
|
|
- [ ] Is there regression test coverage?
|
|
- [ ] Do tests pass?
|
|
|
|
### Design
|
|
- [ ] Is the code consistent with existing patterns?
|
|
- [ ] Are interfaces clean and minimal?
|
|
- [ ] Is there unnecessary complexity?
|
|
- [ ] Would a future developer understand this?
|
|
|
|
### Safety
|
|
- [ ] Are there security implications?
|
|
- [ ] Are there performance implications?
|
|
- [ ] Are there race conditions?
|
|
- [ ] Are secrets or credentials handled safely?
|
|
|
|
### Documentation
|
|
- [ ] Are public APIs documented?
|
|
- [ ] Are non-obvious decisions explained?
|
|
- [ ] Is the change self-documenting?
|
|
|
|
## Common pitfalls
|
|
|
|
- Rubber-stamping (approving without reading)
|
|
- Nitpicking style when correctness matters
|
|
- Not testing the change locally
|
|
- Accepting "it works" without evidence
|
|
- Missing scope creep
|
|
|
|
## Exit criteria
|
|
|
|
- All checklist items addressed (pass or explain why not)
|
|
- Findings categorized: BLOCKING / REQUIRED / SUGGESTED / NOTE
|
|
- Verdict: ACCEPT / ACCEPT_WITH_NOTES / CHANGES_REQUIRED / BLOCKED
|