From benji
Lightweight workflow for bugfixes and minor enhancements (<100 lines). Skips the full pipeline in favor of plan mode, focused implementation, and a single review pass. Use when the change is small and well-understood.
npx claudepluginhub ai-builder-team/ai-builder-plugin-marketplace --plugin benjiThis skill is limited to using the following tools:
Lightweight alternative to the full pipeline for bugfixes and minor enhancements.
Generates design tokens/docs from CSS/Tailwind/styled-components codebases, audits visual consistency across 10 dimensions, detects AI slop in UI.
Records polished WebM UI demo videos of web apps using Playwright with cursor overlay, natural pacing, and three-phase scripting. Activates for demo, walkthrough, screen recording, or tutorial requests.
Delivers idiomatic Kotlin patterns for null safety, immutability, sealed classes, coroutines, Flows, extensions, DSL builders, and Gradle DSL. Use when writing, reviewing, refactoring, or designing Kotlin code.
Lightweight alternative to the full pipeline for bugfixes and minor enhancements.
Determine the type of change:
Bug Fix — Something is broken, needs to work correctly.
Enhancement — Something works, needs to work better/differently.
This classification is lightweight — just sets the tone for the rest of the workflow.
Quick context scan, not a full exploration.
Check features directory for related documentation:
Glob: features/**/FEATURE.md
Skim any FEATURE.md files that cover the area being changed.
Read relevant source files to understand current state.
For bugs: Identify root cause before planning the fix.
Goal: Understand what exists and what's documented. 2-3 minutes, not 20.
Enter Plan Mode to design the approach.
Exit plan mode with user approval before implementing.
Implement the change, then ensure tests are current.
Not strict TDD ordering — just "tests are current when you're done."
Run a single pr-review-toolkit:review-pr pass:
Use Skill tool:
skill: "pr-review-toolkit:review-pr"
Address any issues found. This is the only QC gate for the lightweight path.
This prevents documentation drift. Before committing:
Check if any changed files appear in a FEATURE.md:
Grep for changed filenames across features/**/FEATURE.md
If a FEATURE.md covers this area:
If no FEATURE.md covers this area: That's fine — don't force-create one for a bugfix. The commit message carries the context.
Follow commit discipline with appropriate prefix:
fix(scope): descriptionfeat(scope): descriptiongit add {specific-files}
git commit -m "$(cat <<'EOF'
fix(scope): concise description of what and why
Co-Authored-By: Claude <noreply@anthropic.com>
EOF
)"
If FEATURE.md was updated, include it in the commit:
git add features/{domain}/{feature}/FEATURE.md