Kerliula
UserA comprehension-first workflow for Claude Code: grill the problem, design on paper, build one commit at a time, verify against a running app, then write only the tests that earn their place.
Categories
Indexed Skills (7)
build-me
Implement a solution write-up (typically the markdown file produced by /solve-me) in this Laravel project, following existing project patterns and Laravel best practices. Cuts the work into commits itself, writes the commit plan to docs/build/<slug>.md, and gets the developer's approval before writing any code. Then builds one commit at a time, saying up front and afterwards why that commit is needed and which numbered requirement it serves, and stopping after each one for the developer to review and edit. Every piece of new logic gets a short plain-language comment explaining what it does and why that approach was picked — meant to be deleted once reviewed. Suggests a commit message after each commit. Always implements the option the developer already picked in the /solve-me file — never a different one. Use after /solve-me, when it's time to actually write code.
grill-me
Ruthlessly eliminate comprehension debt before design or implementation. Use when the developer wants to stress-test a plan, decision, requirement, bug, feature, architecture, or implementation idea. The developer must demonstrate that they understand the problem, constraints, behavior, and consequences in their own words before the session can advance. Closes the two answers developers always get wrong — what's out of scope, and how we'd know it works — by drafting both lists itself and having the developer confirm or correct them. Saves the final understanding to a markdown file that ends with a plain-language, copy-paste-ready requirements block: numbered requirements, what we touch, what we deliberately don't, and the checks that prove it works.
ship-me
Run the full pipeline end to end for one problem or feature: /grill-me, /solve-me, /build-me, /verify-me, /test-me, in order. The interactive phases (grill-me's interrogation, build-me's per-commit review) run right here in this conversation. The non-interactive phases (solve-me, verify-me, test-me) each run as a freshly spawned, separate session with no memory of this conversation. The developer keeps three approval gates: the solution options after solve-me, the commit plan at the start of build-me, and the go-ahead for tests after verify-me. Use when the developer wants the whole problem-to-tested-code pipeline run for something, instead of invoking each skill by hand one at a time.
solve-me
Turn an understood problem into a solution, using divide-and-conquer. Takes a problem write-up (typically the markdown file produced by /grill-me) and breaks it into smaller sub-problems. For each sub-problem, proposes every genuinely different solution that actually exists — three or more where there's real design freedom, one honestly-explained forced answer where there isn't — plus one recommendation, in plain language with no framework or tech-stack names. Saves the result to a markdown file. Use after /grill-me, before writing any code.
test-me
Write the automated unit and feature tests that /verify-me identified as missing, following this project's testing conventions and real testing best practices. Actively filters out useless tests — ones that can't fail, test the framework instead of the feature, or lock in implementation details instead of behavior. After writing each test (or batch of tests), explains in plain language why it's useful and what real bug or rule it protects against. Use after /verify-me, once you know what tests are missing and want them actually written.
verify-me
Check that a built feature actually matches the original problem (/grill-me) and the chosen solution (/solve-me). Acts like a real user and a QA engineer, not a code reviewer: confirms scope, environment, database safety and login with the developer first, then creates real dummy data in the database (via Laravel MCP/Boost tools if available, otherwise artisan), then hits the real running app with curl — golden path, edge cases, and heavy/weird inputs. No automated tests are written. Produces one clean markdown file with a simple, readable log of every request tested (input/output) plus a plain-language list of the unit/feature tests that still need to be written, and then stops — it never writes those tests and never starts another skill. Use after /build-me, once a commit (or the whole feature) is implemented.
map-me
Build the comprehension map across every ship-me run in this project and read it back in plain language. Runs a deterministic script over the markdown the pipeline already wrote (grill-me's R-numbers, solve-me's sub-problems and options, build-me's commits and touched files, verify-me's coverage table) and turns them into a graph: one node per requirement, sub-problem, option, commit, mid-build decision and touched file. Its real job is the holes — requirements nothing built, requirements nothing proved, commits tied to no requirement, decisions made mid-build that never went through a gate, and files where several runs collide. Use when the developer wants the big picture, wants to know what a run actually left behind, or is about to start work in a part of the code several runs have already touched.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.