bitfootco/bender

Use when starting any new feature, significant change, or architectural decision. Explores requirements and options before any implementation begins.

Isolate, research, compare, implement, and simplify exactly one coherent kernel of code. Use when the user invokes $chunk, asks to decompose work into one small surgical slice and compare implementation options before editing, or asks to trace and implement one recurring simplification across a large diff. Accept $chunk [plan-or-slice] and $chunk review [branch|path|git-ref]. Do not use for broad milestone execution, ordinary feature implementation, brainstorming alone, or report-only code review.

Audit a repository, package, or directory for evidenced correctness, security, reliability, scale, test, performance, and complexity problems. Use for whole-codebase or subsystem audits; use code-review for a diff, branch, commit, or pending changes.

Independently review code before committing or merging. Use for a diff, branch, commit, path, or pending changes; route whole-repository or subsystem audits to code-audit.

Generate one concise Conventional Commit subject for the current uncommitted work. Use when the user invokes $commit or asks for a one-line, scoped, conventional commit message for recent or pending changes. Inspect the repository and return a message only; never create the commit.

Create or edit concise, brand-aware marketing, website, product, documentation, and editorial copy. Use for content writing and copy passes; do not activate for ordinary assistant replies, progress updates, or code-only tasks.

Execute one roadmap or milestone parent through sequential, simplicity-first behavior slices. Use when the user invokes $inchstone or explicitly asks to execute a roadmap parent surgically, incrementally, or as chunks. Authorize the parent once, verify each slice with targeted checks, and reserve full CI for the final review gate. Delegated pipeline mode returns verified changes without committing or marking the roadmap.

Pick up and implement the next item from a roadmap or milestone document. Use at the start of a session when the user asks to continue a roadmap, execute the next milestone, or supplies a roadmap path. Implement one parent directly; use inchstone instead when the user explicitly asks for surgical chunking.

Orchestrate a full roadmap-to-committed-code flow by delegating each parent to inchstone, independently inspecting verified changes, reviewing once per parent, and committing completed parents. Use when the user asks to run a whole roadmap or pipeline. Accept --auto to skip the parent review gate and --parallel for isolated independent worktrees.

Generate a high-level, markdown-formatted GitHub pull request description from the current branch and return it as Markdown in chat. Use when the user asks for a PR description; use a base branch from the request when supplied, otherwise discover main, master, or trunk.

Break a large feature, project, or initiative into discrete, sequenced, single-session milestones and write them to ROADMAP.md. Use when the user asks to create or update an implementation roadmap.

Summarize the most recent commit or pending changes — what they do, how they fit into the existing code, and a diagram if the change is structural.

Use when encountering any bug, test failure, unexpected behavior, or when a previous fix attempt did not work. Use before proposing any solution.

Use when implementing any new feature, fixing a bug, or refactoring existing code. Enforces red-green-refactor discipline throughout.

Use before claiming any work is complete, fixed, or passing. Use before every "done", "fixed", "tests pass", or "it's working" statement.