メニュー
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]