sascha-gruesshaber
- 12 skills
- 0 followers
- 1 day ago last updated
- ▌ Tdd · sascha-gruesshaberThe red-green loop, and what makes a test worth keeping — one test, one implementation, repeat, at seams that were agreed before any test was written. Use when building a feature or fixing a bug test-first, when someone says "red-green-refactor" or "write the test first", and by `ticket-implementer` on every ticket. Keywords - tdd, test first, red green, write the test first, failing test, seam, tautological test, what should I test.
- ▌ Plan · sascha-gruesshaberTurn a committed spec into an ordered, executable plan — after agents have actually read the code it will change. Every task names its files, its test, its seam and the command that verifies it; a coverage table maps every numbered requirement to a task or an explicit deferral. Writes plan.md beside the spec. It plans, it never implements. Use when a spec exists and someone asks how we build it, wants the work broken into ordered tasks, or wants to know where the code lives today. Keywords - plan, how do we build it, break it into tasks, implementation plan, task order, test seams, coverage, where does this code live.
- ▌ Show · sascha-gruesshaber bundlePut something in front of the user as a page they can point at — a process flow, a set of options, a spec, a before-and-after, run progress — published as an artifact, opened in whatever browser this machine has, with every block annotatable so their notes come back labelled. Use when a picture would land better than prose, when a decision needs comparing side by side, or when someone says "show me", "draw it", "let me see it", "I want to comment on that". Keywords - show, show me, draw it, diagram, visualise, mockup, flow chart, options, side by side, let me see, annotate, comment on it, feedback page.
- ▌ Spec · sascha-gruesshaber bundleWrite the settled design down as the contract — one numbered list of requirements, one numbered list of acceptance criteria, the decisions and what they ruled out. States WHAT, never HOW. Commits the spec where the repo keeps them, at Status Specced, where `/plan` and `/build` pick it up. Use after a design is agreed, when someone asks to "write it up", "spec it out", "pin down the requirements", or to revise a spec the work has outgrown. Keywords - spec, write it up, spec it out, requirements, acceptance criteria, the contract, pin it down, revise the spec.
- ▌ Frame · sascha-gruesshaberTurn a ticket or a half-formed sentence into the facts, the size of the work, and the question set worth asking — before any design conversation starts. Reads the ticket, sweeps the edge cases, and splits what it finds into questions only you can answer and assumptions it settled itself. Use at the very start of new work, or on its own when someone asks "what do we actually know about this?", "what still needs deciding?", or "how big is this?". Produces no file; `/grill` consumes what it returns. Keywords - frame, scope it, what do we know, open questions, how big is this, assumptions, edge cases, before we design.
- ▌ Grill · sascha-gruesshaberA relentless interview that sharpens a design until nothing is silently assumed, and writes the glossary terms and decision records it settles as it goes. Use whenever a design needs stress-testing — "grill me", "poke holes in this", "let's think this through", "what am I missing" — and as the design half of the lifecycle, between `/frame` and `/spec`. Keywords - grill, grilling, stress test, poke holes, think it through, design tree, frontier, what am I missing, sharpen the idea, decision record, glossary.
- ▌ Onboard · sascha-gruesshaber bundleSet this lifecycle up in a repo that has never used it. Reads the repository to work out how it already builds, tests, tracks work and ships; asks only what evidence cannot settle; proposes where the way of working should change and lets you decline each one; then writes the eight files under .agents/ that every other skill reads, and proves the install by framing one real ticket. Use on a fresh clone, when `/frame` or `/build` says .agents/ is missing, or when the repo has changed enough that the config is lying. Keywords - onboard, install, set up, initialise, configure, first run, adopt the lifecycle, .agents, gates, which reviews, how many rounds.
- ▌ Diagnose · sascha-gruesshaberFind the cause of a hard bug or a performance regression by building a tight feedback loop first and a theory second. Six phases — loop, reproduce and minimise, ranked hypotheses, instrument, fix behind a regression test, clean up. Use whenever something is broken, throwing, failing, flaky or slow and nobody knows why, or when someone says "debug this", "why is this happening", "it works locally". Keywords - diagnose, debug, broken, throwing, failing, flaky, slow, regression, why is this happening, repro, root cause, bisect.
- ▌ Workflow · sascha-gruesshaberWork out where a piece of work already stands and run the phase that comes next — reading the state off disk rather than asking. Advances through the unattended phases in a row and halts at any phase that needs a person. Use when the user says "advance", "next step", "continue", "keep going", "carry on", "what's next", "where are we", "pick up where we left off", or invokes /advance. Also use when resuming work after a break or a fresh session, and when you are unsure which lifecycle phase applies. Keywords - workflow, advance, next step, continue, keep going, carry on, what's next, where are we, resume, pick up, drive it forward, which phase, state of play.
- ▌ Plan Check · sascha-gruesshaberAdversarially review an implementation plan before anyone builds it — open every path the plan cites, verify every claim it makes about the repository with a command, check it against the spec and the repo's own rules, and return a Ready / Ready with changes / Not ready verdict. Read-only; it judges a plan and never revises one. Use before starting a build, on a plan written days ago, or on one somebody else wrote. Keywords - plan check, review the plan, is this plan sound, safe to start, sanity check the plan, verify the claims, not ready.
- ▌ Plain Words · sascha-gruesshaberReport in plain, controlled English. Small words, short sentences, one idea each; what you did, whether it worked, what to do now; two options and a recommendation when a decision is needed. Use when the user asks for plainer answers, says they are tired or overloaded, says "ELI5", "explain it simply", "keep it short", "talk to me like I'm five", "too much text", "just tell me what to do", or when English is not their first language. Also load it before writing a report a non-specialist will read. Keywords - plain words, plain english, ELI5, simplified technical english, ASD-STE100, keep it short, too long, simply, brain fried, just tell me, controlled language.
- ▌ Resolve Conflicts · sascha-gruesshaberResolve an in-progress git merge or rebase conflict by finding out why each side made its change, rather than by picking a side. Use when a merge or rebase has stopped with conflicts, when a review reports a merge conflict, or when someone says "fix the conflicts", "this won't merge". Keywords - merge conflict, rebase conflict, conflicts, won't merge, resolve conflicts, both modified, HEAD marker.