| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
The skill ran one flat criteria set on every change, so a concurrent, DB-backed service got the same review as a shell script, and the checks that matter for the service (concurrency, performance, auth, API compatibility) weren't in the set at all.
Phase 3.5 splits the checks into a universal core that always runs plus nine modules that activate on the project's review profile. A project declares the profile with a "Review profile:" line in its CLAUDE.md. Absent that, the skill auto-detects from framework, ORM, concurrency, and manifest signals and recommends declaring one. The security and dependency modules defer their depth to /security-check.
|
| |
|
|
| |
The skill's chat echo (report, criterion table, verdict, draft summaries) was rendering bold and backtick spans as reverse video, which is hard to read in the terminal. Phase 5 now requires plain text for everything echoed to chat, while the artifact posted to GitHub keeps normal markdown. It's the same constraint as interaction.md's no-reverse-video rule, repeated at the print step where the violation actually happens.
|
| |
|
|
|
|
| |
Voice gains pattern #40: strip the "why" from praise on an approve, since the author already knows why their change is good and the justification reads as flattery. Always keep the why on a finding or change-request, delivered gently. Behavior only changes when the reason lands.
review-code now runs a praise/correction gate before posting any summary, and its inline-comment guidance is tightened so the why-it-matters survives the brevity cuts. The reviewer states the stakes (a user hits a 500, a screen reader announces nothing), not just the mechanism.
|
| |
|
|
| |
Extended the posted-summary voice guidance: a re-review confirming requested changes is just "Approving" plus at most a bare positive. An approve summary must not carry a clause describing what the change does or why it works — that's the banned pattern, since the author already knows the rationale and restating it reads as padding.
|
| |
|
|
|
|
|
|
| |
Two clarifications to review-code where it appeared to contradict other rules.
The "trust CI, don't run builds" rule read as a blanket license to skip verification. I scoped it to reviewing a diff, not shipping one. A pre-commit or pre-push flow still owes the local verification verification.md requires. Reading a PR doesn't duplicate CI. Producing one doesn't get to skip it.
The CLAUDE.md-adherence audit could put a CLAUDE.md citation into a team-visible PR comment, which commits.md says not to do. I added two modes. A private review cites CLAUDE.md directly. A public review translates the rule into the engineering reason and doesn't name the file, since a teammate can act on the reason but not on a file they can't reach.
|
| |
|
|
|
|
| |
Two related changes to review-code's strengths guidance. The mandatory "three minimum" could force filler on a tiny diff or padded praise on a weak PR, so I relaxed it to up to three specific strengths, with an honest "nothing notable" allowed when the diff doesn't earn them. I also reframed the old "No Strengths section" anti-pattern as "skipping strengths out of laziness": a substantive diff still demands them, a weak one doesn't.
The other change tells reviewers to name the good thing and stop, without explaining why it's good. Explaining praise reads as sycophantic since the author already knows the rationale. Elaboration is for findings, not compliments.
|
| |
|
|
|
|
| |
review-code was a command with disable-model-invocation set, so the model could never reach for it on its own. Every time a review fit the moment, the agent had to hand back to me to type the slash command. Moving it to a skill makes it model-invocable while it stays slash-invocable as /review-code.
git mv keeps the file history (99% rename). The frontmatter drops disable-model-invocation and gains name: review-code; the body is unchanged. It also drops the discovery-check paragraph in commits.md, which only existed to find the command on disk when it was missing from the skills list, moot now that the skill shows up there.
|
| |
|
|
|
|
|
|
| |
I converted 16 user-invoked skills to commands. Skills cost ~150-300 tokens each per session for descriptions the model uses to auto-route. Commands cost nothing until you type the slash. These 16 are workflows I always trigger deliberately. The auto-routing wasn't earning its keep. This reclaims ~4-5k tokens per session.
Nine skills stayed where auto-routing genuinely helps: debug, root-cause-trace, five-whys, add-tests, frontend-design, humanizer, playwright-js, playwright-py, and pairwise-tests. Pairwise-tests stays a skill because its helper files don't fit a single-file command shape.
For arch-decide, I preserved the upstream MIT LICENSE alongside the command at .claude/commands/arch-decide.LICENSE so attribution stays intact.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
skills
Linear ticket bodies are now Problem + Fix only. PR descriptions keep
the four-section format (Problem, Fix, Why this fixes it, How it was
tested). Linear's GitHub integration handles the cross-link via the
PR body's Linear: line.
Cross-ref to the content-scope rule appended at the end of each Tier 1
skill that produces public artifacts: testing.md, arch-document,
arch-decide, arch-design, review-code, respond-to-review, brainstorm,
codify. Single-source the rule in commits.md, point at it from each
output-producing skill.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The fix-issue skill has been replaced by start-work, which covers the same ground (picking up a ticket with a known fix and carrying it through to handoff) with a seven-phase structure and three user-approval gates. Deleted fix-issue/SKILL.md and swept the references.
Updated:
- Makefile SKILLS list: remove fix-issue, add start-work so make install creates the right symlink.
- brainstorm/SKILL.md: implementation-path list points at start-work.
- debug/SKILL.md description: both "do NOT use for ticket-driven work" and "Companion to" references updated.
- review-code/SKILL.md description: "drafting implementation" redirect updated.
No change in meaning. Every old fix-issue context now names start-work.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Cross-cutting rule covering subagent hygiene:
- Decision table: parallel-safe (read-only investigation, independent
test failures, multi-domain research) vs sequential-with-review
(plan execution, coupled edits) vs never-parallel (concurrent writes)
vs don't-subagent-at-all (target known, work fits in ~10 tool calls).
- Prompt contract: scope / pasted context / explicit 'do NOT' list /
required output format. Missing any field yields shallow work.
- Context-pollution rule: subagents absorb noise the main thread
shouldn't carry. When one fails, dispatch a fix-agent with the
failure report — do not retry in the orchestrator.
- Review-gate cadence: after each sequential task, or every ~3 in
parallel batches.
- Anti-patterns including parallel implementation on overlapping
files, broad 'fix all the tests' prompts, timeout-tuning to mask
flakes, and letting the agent decide scope.
Added one-line cross-references to subagents.md from debug/,
review-code/, and finish-branch/ SKILL.md — the skills that most
rely on delegation.
Clean-room synthesis from NeoLabHQ/context-engineering-kit's
subagent-driven-development pattern (MIT).
|
|
|
improvements
Renamed review-pr → review-code (the skill accepts PR, SHA range,
current branch, staged changes — "pr" was understating scope).
Rewrote SKILL.md with YAML frontmatter (previously header-style) and
merged useful patterns from two sources:
From obra/superpowers skills/requesting-code-review:
- Intent-vs-delivery grading (given plan/ADR/ticket)
- Mandatory Strengths section (three minimum)
- Per-issue Critical/Important/Minor severity (per-criterion
PASS/WARN/FAIL retained; complementary axes)
- Required verdict + 1-2 sentence reasoning
- Multi-input support (PR / SHA range / current branch / --staged)
- Sub-agent dispatch recommendation for heavy reviews
- Concrete filled-in example output
From the claude-plugins-official code-review plugin:
- Phase 0 eligibility gate (skip closed/draft/auto/trivial/already-reviewed)
- CLAUDE.md traversal + adherence criterion (reads root + per-directory
CLAUDE.md files; audits the diff against stated rules)
- Multi-perspective Phase 2: five passes (CLAUDE.md adherence, shallow
bug scan, git history context, prior PR comments, in-scope code
comments). For large reviews, dispatch as parallel sub-agents.
- Confidence filter (High/Medium/Low; drop Low before reporting)
- False-positive categories explicitly enumerated (pre-existing issues
on unmodified lines, lint/typecheck issues CI handles,
senior-wouldn't-call-out nitpicks, silenced issues with valid reason,
intentional scope changes, unmodified-line issues, framework-behavior
tests)
- Trust-CI discipline (don't run builds yourself)
Substance from the original review-pr kept verbatim:
- DeepSat-specific criteria (security, TDD evidence, conventions,
no-AI-attribution, API contracts, architecture layering, root-cause
discipline)
Size: 60 lines → 347 lines. Growth is structural (added phases, added
example, added perspectives, added filters) not verbose — each section
earns its lines.
NOT adopted from the plugin:
- GitHub comment output format (plugin posts PR comments; review-code
outputs a markdown report the user can paste if they want)
- "Generated with Claude Code" footer (violates no-AI-attribution rule)
- Specific 0/25/50/75/100 confidence scale (Critical/Important/Minor
covers the same signal with less ceremony)
Makefile SKILLS updated: review-pr → review-code. Old
~/.claude/skills/review-pr symlink removed; make install creates the
new one at ~/.claude/skills/review-code.
|
