dotfiles

Converge on a frontend look through rounds of prototypes and grilling verdicts.

Fill Clockify time entries by gathering GitHub activity (commits, PRs, issues), then previewing and committing entries via clockify-cli.

Behavioral guidelines to reduce common LLM coding mistakes. Use when writing, reviewing, or refactoring code to avoid overcomplication, make surgical changes, surface assumptions, and define verifiable success criteria.

Create conventional, one-line commits from current git changes, splitting work into the smallest sensible atomic commits. Use when the user asks to commit changes.

Write the idea the user provides into their `ideas.md` file.

Grill me about specs for the workflows I want to build, within this workspace.

Implement multiple user-authored plans in parallel, each on its own branch off the current branch in a separate git worktree and tmux pane running pi, then merge them all back. Use when the user wants to "implement these in parallel", "parallelize these plans", "fan out these handoffs", or build several plans at once in the same branch lineage.

Review PR comments and bot feedback, then decide whether each point should be fixed, rejected, deferred, or already handled. Apply accepted suggestions when asked.

Control herdr from inside it. Manage workspaces and tabs, split panes, spawn agents, read output, and wait for state changes — all via CLI commands that talk to the running herdr instance over a local unix socket. Use when running inside herdr (HERDR_ENV=1).

Lightweight project context and ADR maintenance. Use when creating or updating `CONTEXT.md`, recording design choices as ADRs, or when another workflow needs project vocabulary, commands, pitfalls, or design memory without full SDD.

A relentless interview to sharpen a plan or design, which also creates docs as we go.

Grill the user relentlessly about a plan or design. Use when the user wants to stress-test a plan before building, or uses any 'grill' trigger phrases, or when in spec driven development mode.

Implement a piece of work based on a set of issues or specs.

Scan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.

Review the changes since a fixed point (commit, branch, tag, or merge-base) along two axes — Standards (does the code follow this repo's documented coding standards?) and Spec (does the code match what the originating issue/PRD asked for?). Runs both reviews in parallel sub-agents and reports them side by side. Use when the user wants to review a branch, a PR, work-in-progress changes, or asks to "review since X".

Test-driven development. Use when the user wants to build features or fix bugs test-first, mentions "red-green-refactor", or wants integration tests.

Break a plan, spec, or PRD into independently-grabbable GitHub issues using tracer-bullet vertical slices.

Turn the current conversation into a PRD and publish it to GitHub issues — no interview, just synthesis of what you've already discussed.

Plan a huge chunk of work — more than one agent session can hold — as a shared map of investigation tickets on your issue tracker, and resolve them one at a time until the way to the destination is clear.