What’s inside

One SKILL.md (the playbook) + one starter template. A preview:

Terminal Coder

When to use

• You have a repo and want to build a feature or fix a bug by describing it in plain language
• You want builds, tests, and lint run for you, with results summarized instead of terminal-scrolling
• PRs need drafting from plain-language instructions, and review before they're created
• You want read-only exploration — codebase tours, "where is X handled?" — without touching anything
• Repetitive safe shell chores (batch renames, cleanup checks, listing open PRs) you don't want to type yourself

Workflow

Tell the AI where the code lives and what to build or fix in ordinary words. It should read the relevant code first and sketch a plan — what it will change and why — before touching anything.

1. Point and describe (input: repo path + plain-language task → output: task plan)

The AI reads the relevant files and confirms its understanding: which files it will touch and why. Blind edits are how regressions happen; the read-first step is what separates this from autocomplete.

1. Read before writing (input: task plan → output: confirmed understanding)

The AI makes the changes, then runs the build and test commands to verify. "It looks right" is not done; tests passing is done. It shows you a summary of every change as a diff — you review the diff, not just the claim.

1. Edit, then verify (input: edits → output: diff + test results)

Reads run automatically. Anything that writes, moves, deletes, or hits the network asks first. Destructive commands (rm -rf, database wipes, force pushes) need explicit approval every time — no blanket "do whatever it takes," and "clean up everything" is never an approval.

1. Respect the permission ladder (input: command intent → output: approved or declined execution)

When tests pass, the AI drafts the PR — title, description, change summary, test evidence — and waits for your confirmation to create it. Nothing is committed or pushed without your go-ahead.

1. Ship with review (input: verified changes → output: draft PR)

For big tasks, split the work into independent subtasks handled by parallel sub-agents with a complexity budget, then integrate the results. Useful for large repos or batch work like "fix lint across all files." One real case ran eight sub-agents in parallel on separate C programs.

1. Parallelize when it helps (input: large task → output: split subtasks + integration)

Output spec

• Per task: change summary (files touched, what changed and why), full diff for review, build/test/lint results
• Permission ladder honored: read = automatic, write = ask, destructive = explicit per-command approval
• PR drafts include title, description, and test evidence; creation waits for your confirmation
• Honest failure states: if the build

Download the full skill pack (ZIP)