Help us improve
Share bugs, ideas, or general feedback.
From hephaestus
Use when completing tasks, implementing major features, or before merging — dispatches a Sonnet code reviewer and guides reception of feedback with technical rigor
npx claudepluginhub homericintelligence/projecthephaestus --plugin hephaestusHow this skill is triggered — by the user, by Claude, or both
Slash command
/hephaestus:code-review <what was implemented><what was implemented>This skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
Two-part skill: **Requesting** a code review via a Sonnet reviewer agent, and **Receiving** feedback with technical rigor.
Provides behavioral guidelines to reduce common LLM coding mistakes, focusing on simplicity, surgical changes, assumption surfacing, and verifiable success criteria.
Searches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.
Creates p5.js generative art with seeded randomness, noise fields, and interactive parameter exploration. Use for algorithmic art, flow fields, or particle systems.
Share bugs, ideas, or general feedback.
Two-part skill: Requesting a code review via a Sonnet reviewer agent, and Receiving feedback with technical rigor.
Core principle: Review early, review often. Verify before implementing. Technical correctness over social comfort.
Mandatory:
Optional but valuable:
1. Get the diff context:
BASE_SHA=$(git merge-base HEAD origin/main)
HEAD_SHA=$(git rev-parse HEAD)
git log --oneline "$BASE_SHA".."$HEAD_SHA"
git diff "$BASE_SHA".."$HEAD_SHA" --stat
2. Dispatch code reviewer as a Sonnet agent:
Agent(
model="sonnet",
description="Code review",
prompt="""You are a Senior Code Reviewer for the HomericIntelligence ecosystem.
Review the implementation against the plan and coding standards.
## What Was Implemented
{WHAT_WAS_IMPLEMENTED}
## Plan / Requirements
{PLAN_OR_REQUIREMENTS}
## Git Range
BASE_SHA: {BASE_SHA}
HEAD_SHA: {HEAD_SHA}
## Review Dimensions
1. **Plan Alignment**: Compare implementation against requirements. Are there deviations?
Are they justified improvements or problematic departures?
2. **Code Quality**: Adherence to SOLID principles, proper error handling, type safety,
naming conventions, modularity. No unnecessary complexity (YAGNI, KISS).
3. **Test Coverage**: Does every new function/method have a test? Were tests written first (TDD)?
Are tests testing behavior, not implementation?
4. **Type Safety**: Run `pixi run mypy hephaestus/` — are there type errors?
5. **Documentation**: Are public functions documented? Are inline comments explaining *why*?
## Issue Categorization
For each issue found:
- **Critical** (must fix before merge): broken functionality, security issues, data loss risk
- **Important** (should fix): missing tests, type errors, violates SOLID, unclear code
- **Suggestion** (nice to have): style, naming, minor improvements
## Output Format
Ready to merge / Fix Critical issues first / Fix Critical + Important issues first
"""
)
3. Act on feedback:
WHEN receiving code review feedback:
1. READ: Complete feedback without reacting
2. UNDERSTAND: Restate requirement in own words (or ask for clarification)
3. VERIFY: Check against codebase reality — does this actually apply?
4. EVALUATE: Is this technically sound for THIS codebase?
5. RESPOND: Technical acknowledgment or reasoned pushback
6. IMPLEMENT: One item at a time, test each
NEVER:
INSTEAD:
IF any item is unclear:
STOP — do not implement anything yet
ASK for clarification on unclear items
WHY: Items may be related. Partial understanding = wrong implementation.
BEFORE implementing external suggestions:
1. Is this technically correct for THIS codebase?
2. Does it break existing functionality?
3. Is there a reason for the current implementation?
4. Does the reviewer have full context?
IF suggestion seems wrong: Push back with technical reasoning.
IF can't easily verify: Say "I can't verify this without [X]. Should I [investigate/ask/proceed]?"
IF reviewer suggests "implementing properly" with new features:
Search codebase for actual usage
IF unused: "This isn't called. Remove it (YAGNI)?"
IF used: Then implement properly
Push back when:
How: Use technical reasoning, not defensiveness. Reference working tests/code.
✅ "Fixed. [Brief description of what changed]"
✅ "Good catch — [specific issue]. Fixed in [location]."
✅ [Just fix it and show the code]
❌ "You're absolutely right!"
❌ "Great point!"
❌ "Thanks for catching that!"
Actions speak. Just fix it.
pixi run pytest tests/unit -vAdapted from obra/superpowers under the MIT License. Copyright (c) 2025 Jesse Vincent.