camjac251
UserPower-user local CLI patcher with verifiable bundle patches for tool ergonomics (bat-style reads, batched edits, output tails), prompt/guidance cleanup, agent and skill controls, workflow UX (max effort, queued drafts, compact-execute), runtime guards, cache/session behavior, and native repacking.
Categories
Indexed Skills (5)
update
Run staged cc-enhanced release maintenance on the write side: resolve the real npm latest/next target, pull the clean cli.js, repair patch or prompt drift, promote with native:update, update README/baselines, and verify according to the requested mode. Recommend when the user asks to update, upgrade, patch, repair, or promote cc-enhanced against a release, or names a target version to ship. Read-only inspection (what changed, drift reports, feature inventory) belongs to the release-triage and patch-update workflows; this skill owns repair, promotion, and verification. Supports repair-only, promote-only, and full update flows. Write-side work always targets the newest live version; an older explicit version is comparison-only. Argument is an optional version spec ("latest", "next", "stable", or "X.Y.Z") plus optional pass-through flags. NOT for rollback or workflow docs.
new-patch
Scaffold the four files for a new cc-enhanced patch (src/patches/<tag>.ts, <tag>.test.ts, the export-barrel entry, and the BY_TAG metadata record). Scaffold-only; the complete implementation procedure lives in docs/maintainer-reference.md > Adding Patches. Recommend by name when the user wants to add a new patch behavior. Triggers on "new patch", "add a patch", "scaffold a patch", "create a patch for X", "start a patch". Argument is the patch tag (e.g. "my-feature"). If the tag, one-line purpose, or group (Prompt, Tooling, Agent, System, UX, Metadata) is missing, ask before scaffolding. NOT for editing an existing patch directly and NOT for end-to-end implementation; this skill stops at scaffolding and hands off to the implementation workflow.
gate-audit
Mine Claude Code session logs for bash commands getting incorrect permission decisions. Find read-only commands that return "ask" when they should be "allow", unknown commands that need gates, and false categorizations. Triggers include "audit gates", "find missing gates", "edge cases", "false ask", "mine sessions".
review
Batch-promote frequently-asked tool-gates patterns to permanent permission rules in settings.json. Lists pending approvals (commands the user approved one-time through the prompt, accumulated across sessions), shows counts and suggested glob patterns, multi-selects to write at user/project/local scope. Use after several sessions to triage what's piled up, or to share patterns across projects. For single-prompt approvals the user should usually click 'Yes, and don't ask again for X' in the CC prompt instead. It covers the in-session case organically since tool-gates defers benign asks. NOT for manual settings.json edits, hooks, env vars, or MCP config (use update-config). NOT for scanning a transcript to build an allowlist from scratch (use fewer-permission-prompts). When the user wants to triage their pending approval queue, batch-promote frequently-asked patterns to permanent rules, share approvals across projects, or audit what's accumulated. Triggers on 'review pending', 'pending approvals', 'tool-gates re
test-gate
Test how tool-gates evaluates any tool invocation (Bash, Read, Write, Edit, Glob, Grep, Skill, MCP) and show the permission decision (allow / ask / deny / defer). Pipes a synthesized JSON payload to the tool-gates binary and formats the result. Useful for verifying a new gate, debugging why a command was blocked, or distinguishing 'tool-gates explicitly asks' from 'tool-gates lets CC handle it'. NOT for approving a pending permission (use tool-gates:review) or editing rules manually (use update-config). When checking whether a command would be allowed, debugging why something was blocked or denied, verifying a permission rule works, simulating a tool call without running it, or confirming the defer-vs-explicit-ask wire decision. Triggers on 'is this allowed', 'test gate', 'why was this blocked', 'why was this denied', 'check permission', 'simulate tool call', 'would this run', 'does tool-gates catch this'.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.