菜单
Code review checklist, severity definitions, and document templates. Load when performing code reviews or defining review criteria.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Author Architecture Decision Records (ADRs) for the ck3-language-support (pychivalry) VS Code extension. Trigger this skill when asked to create, draft, or write a new ADR, or when a technical decision needs to be formally documented.
After-action report skill for producing structured, succinct summaries of completed missions. Use after any multi-step task, implementation, review, or operational mission to give the user a clear picture of what happened, what changed, and what remains. Covers mission debrief, change inventory, officer contributions, decision log, and follow-up items.
Systematic methodology for converting unknowns to knowns through structured investigation. Use when performing root-cause analysis, debugging complex issues, conducting codebase audits, or any investigative task requiring evidence-based findings. Provides confidence-level classification (Proven/Observed/Inferred), gap tracking templates, investigation techniques (log tracing, component isolation, binary search debugging, POC execution, upstream tracing), and a structured handoff protocol for multi-agent workflows.
Author Architectural Decision documents for the docs/architecture/decisions/ directory. Trigger this skill when asked to create, draft, or write a new architectural decision, or when a technology choice, design pattern, or infrastructure strategy needs formal documentation.
Common software architecture patterns, ADR templates, and anti-pattern detection. Supports architectural review, design decisions, and system documentation.
Produce ASCII flow charts using Unicode box-drawing characters in a specific visual style with double-line title banners, single-line phase boxes, numbered steps, nested sub-boxes, decision branches, and a key/legend footer. Use when the user asks for a flowchart, diagram, flow diagram, order of operations, process chart, decision tree, state machine visualization, pipeline diagram, or any visual representation of a workflow, pipeline, module, or multi-phase process. Also use when asked to "chart this," "diagram this," "map out the flow," or "show me how X works visually."
| name | code-review-standards |
| description | Code review checklist, severity definitions, and document templates. Load when performing code reviews or defining review criteria. |
Systematic approach to code review. Use this skill when:
Use this checklist when reviewing implementation code:
| Category | What to Review |
|---|---|
| Architecture Alignment | Does implementation match Architect's design? Follows system-architecture.md patterns? |
| SOLID Principles | SRP, OCP, LSP, ISP, DIP violations (load engineering-standards for detection patterns) |
| DRY/YAGNI/KISS | Duplication, speculative generalization, over-complexity |
| TDD Compliance | TDD Compliance table present in implementation doc? All rows show test-first? |
| Code Smells | Long Method, Large Class, Feature Envy, etc. (see engineering-standards) |
| Documentation & Comments | Appropriate inline comments explaining "why" (not "what"), function docstrings, module-level docs, complex logic explained |
| Naming & Clarity | Self-documenting names, appropriate abstractions, readable code |
| Error Handling | Defensive coding, graceful failures, appropriate exceptions |
| Security Quick Scan | Obvious vulnerabilities (injection, exposed secrets, hardcoded creds) |
| Performance | Obvious inefficiencies, N+1 patterns, memory leaks |
| Observability | Appropriate logging, telemetry for debugging |
| Severity | Definition | Action |
|---|---|---|
| CRITICAL | Security vulnerability, data loss risk, architectural violation | REJECT - must fix |
| HIGH | Anti-pattern, significant maintainability issue, missing tests | REJECT - must fix |
| MEDIUM | Code smell, minor design issue, unclear code | Fix recommended, may approve with comments |
| LOW | Style preference, minor optimization opportunity | Note for future, approve |
| INFO | Observation, suggestion for improvement | FYI only |
When documenting findings, use this format:
**[SEVERITY] [Category]**: [Brief title]
- **Location**: `path/to/file.py:L42-L55`
- **Issue**: [What's wrong and why it matters]
- **Recommendation**: [Specific fix suggestion]
Example:
**[HIGH] Documentation**: Missing docstrings on public API
- **Location**: `src/api/handlers.py:L15-L45`
- **Issue**: Public functions `create_user()` and `delete_user()` lack docstrings. Future maintainers won't understand expected inputs/outputs.
- **Recommendation**: Add Google-style docstrings with Args, Returns, and Raises sections.
Create in agent-output/code-review/ matching plan name:
# Code Review: [Plan Name]
**Plan Reference**: `agent-output/planning/[plan-name].md`
**Implementation Reference**: `agent-output/implementation/[plan-name]-implementation.md`
**Date**: [date]
**Reviewer**: Code Reviewer
## Changelog
| Date | Agent Handoff | Request | Summary |
|------|---------------|---------|---------|
| YYYY-MM-DD | [Who handed off] | [What was requested] | [Brief summary] |
## Architecture Alignment
**System Architecture Reference**: `agent-output/architecture/system-architecture.md`
**Alignment Status**: ALIGNED / MINOR_DEVIATIONS / MAJOR_DEVIATIONS
[Assessment of how implementation aligns with architectural decisions]
## TDD Compliance Check
**TDD Table Present**: Yes / No
**All Rows Complete**: Yes / No
**Concerns**: [Any issues with TDD compliance]
## Findings
### Critical
[List of critical findings, or "None"]
### High
[List of high findings, or "None"]
### Medium
[List of medium findings, or "None"]
### Low/Info
[List of low/info findings, or "None"]
## Positive Observations
[Acknowledge good patterns, well-written code, or improvements]
## Verdict
**Status**: APPROVED / APPROVED_WITH_COMMENTS / REJECTED
**Rationale**: [Brief explanation]
## Required Actions
[If rejected: specific list of fixes required]
[If approved with comments: optional improvements]
## Next Steps
[Handoff to Implementer for fixes / Handoff to QA for testing]