skills

Skills For Real Engineering

A small toolkit of slash commands for using Claude Code (and other coding agents) on real engineering work. Each one is independent — pick what you want, ignore the rest, edit them to fit how you actually work.

Real apps are hard to build. Frameworks like GSD, BMAD, and Spec-Kit try to help by taking the process out of your hands — but when something goes wrong inside that process, it's their problem to fix, not yours, and you're stuck waiting. These skills go the other way: small, composable pieces you stay on top of. They work with any model.

Quickstart

npx skills@latest add hammafataka/skills

Pick the skills you want when prompted, and make sure /setup-skills is selected.

Then run it once per repo:

/setup-skills

It asks three quick questions — what issue tracker you use (GitHub, Linear, local markdown), what triage labels you apply, and where your domain docs live. After that, you're set.

Why these exist

Most things that go wrong with coding agents fall into four buckets. There's a skill (or two) for each.

1. The agent built the wrong thing

Most failures aren't bugs — they're misalignment. You thought you told the agent what you wanted, it thought you meant something else, and it built something else.

The fix is talking first:

• /walk-and-talk — for any kind of plan or design
• /walk-and-write — same idea for engineering work, but also writes terminology and decisions down as you go

Both ask you focused questions, one at a time, until you actually know what you want. Use them before every meaningful change.

2. The agent uses 20 words where 1 would do

Every project has its own vocabulary. A "session" might mean something specific in your codebase. "Cancel" might mean something different from a refund. The agent doesn't know any of that, so it falls back on generic language — and ends up using long, fuzzy sentences to say small, simple things.

The fix is a glossary. CONTEXT.md is a short document listing your project's terms and what they actually mean. Once it exists, the agent reads it on every task. Names get consistent, code gets easier to navigate, responses get shorter.

/walk-and-write builds it for you as a side effect of planning. Probably the most useful skill in here — try it once and you'll see.

3. The code doesn't work

You're aligned, the language is shared, and the agent still produces broken code. Almost always, the problem is feedback: the agent can't tell whether what it just wrote runs.

Give it a fast feedback signal:

• /tdd — red-green-refactor, one slice at a time. The agent writes a failing test, then makes it pass.
• /debug-loop — a disciplined approach to hard bugs: reproduce it, narrow it down, form a hypothesis, prove it.

4. The codebase is becoming a mess

Agents make it easy to ship code. They also make it easy to ship messy code, fast. A few months in and the project is a tangle no one wants to touch.

The fix is paying attention to design as you go, not after it's already too late:

• /write-prd — asks you which modules you're touching before drafting a PRD
• /zoom-out — makes the agent explain unfamiliar code in the context of the whole system, not just in isolation
• /improve-codebase-arch — finds parts of the code that have become shallow and should be tidied up. Run it every few days.

All skills

Engineering