@admin
No bio yet.
61 public skills · 13 public agents
Change what happens tomorrow — feedback that names a behaviour, a first week with a real merge, a meeting that decides — instead of a sandwich or a wiki dump. Use when work missed the mark, when someone starts, or when a meeting keeps stalling.
Turn a source into claims you can test, then drill the part that fails — and when the artefact is a codebase, walk the running system, not the file tree. Use when study is not turning into ability, when notes grow without understanding, or when you are new to a repo.
Find whether people can do the job, then fix the stall — tasks, a form that asks only what you will use, copy that says what happens. Use when a flow is new, a screen will not converge in critique, or a form is asking for data nobody reads.
Make a claim people can take with them — a talk, a post, or a cut — instead of a chronology of effort. Use when you have a slot, a write-up, or a draft that is long because it is afraid to choose.
Turn a vague request into a testable contract — scenarios, edge cases, and a definition of done — before anyone writes production code. Use when a change needs acceptance scenarios before a TDD slice starts.
Get a risky change to users in a slice, with a kill switch, then remove the flag — and sequence schema so old and new code never disagree. Use when a rewrite is going live, when a migration is in play, or when retries could make an outage worse.
Page on what users can feel, log so you can replay, and write the procedure the next person can run at 3am. Use when creating an alert, after a noisy night, or after an incident you do not want twice.
Change the shape of working code without changing what it does — small steps, tests after each move, behaviour-preserving commits. Use when the structure is blocking the next slice, or after a slice has gone green.
Implement one failing behaviour at a time from a spec — test first, smallest production change, then stop. Use when a scenario is ready to become code and the suite is already green.
Prove the project is in a known green state before and after work — same command, same counts, stop if the floor is already red. Use when starting a slice, after a change, or when asked to check that nothing broke.
Decide where the system should split and in what order the work should land — boundaries as bets about future change, not as extra files. Use when a design feels tangled, before a large slice, or when two modules keep changing together.
Find where the first session dies, talk to the people in the count, and kill what you will not staff — instead of adding another tour. Use when signups do not return, when two features do the same job, or before you build a replacement alongside the old one.
Grade the live product on a schedule, keep a frozen set for regressions, and decide where a model may draft versus act. Use when a model is in production, after a prompt or model change, or when wiring tools that send, pay, or delete.
Define a small set of type sizes on a ratio, with line height and measure tied to each, so text hierarchy is consistent without per-screen decisions. Use when setting typography, fixing inconsistent text, or starting a design system.
Write the steps the next person can run at 3am — preconditions, exact commands, expected output, and when to stop — instead of a wiki that assumes you are in the room. Use when something will be done without you, before you go on leave, or after an incident you do not want twice.
Assume the project already failed, list the causes independently, and kill the cheap likely ones before you start — instead of brainstorming hopes. Use when you are about to launch, rewrite, migrate, or take any bet you cannot afford to only examine after it dies.
Get a new person to a first real shipped thing in five days — access on day one, a buddy, a done definition — instead of a wiki dump and a calendar of talks. Use when someone starts, when a teammate rotates in, or when onboarding still means "read Confluence."
Say the behaviour, the impact, and the ask — soon, and specific enough that tomorrow can be different — instead of a sandwich or a review-season surprise. Use when work missed the mark, when a pattern is repeating, or when praise is too vague to repeat.
Get better at one skill by drilling the part that fails, with fast feedback and a stop rule — instead of rereading notes and calling it practice. Use when a skill has plateaued, before a high-stakes performance, or when study time is not turning into ability.
Turn a book, talk, or domain into a handful of claims you can test this week — not a summary you will never reread. Use when finishing a dense source, entering a new field, or when notes are growing and understanding is not.
Unplug the mouse and walk the flow with Tab, visible focus, and a name for every control — then a screen reader on the unhappy paths. Use when a screen is "done," before a form ships, or when access is a backlog item with no method.
Watch five people who actually do the job try real tasks, and change the one thing that stalled them — instead of interviewing them about taste. Use when a flow is new, before a redesign ships, or when opinions about a screen will not converge.
Design a form that finishes one job — only the fields you will use, labels that survive typing, and errors the user can still fix. Use when adding a form, rewriting a signup, or when a flow asks for data it does not act on.
Pick a spacing scale and use it for layout — not per-screen "a bit tighter" — so density is a decision you can repeat. Use when screens look inconsistent, when you are starting a UI kit, or when type and colour already exist but the layout still feels arbitrary.
Write a talk people can follow in the room — one takeaway, the result first, rehearsed against a timer — instead of reading a blog post aloud. Use when you have a slot, a conference, an all-hands, or a demo that has to land in twenty minutes.
Write a help article the search box can finish — the query is the title, the answer in the first paragraph, steps using the words on the screen. Use when a support ticket repeats, when a feature ships, or when the docs read like a product map instead of a job.
Turn a request into Given/When/Then scenarios that pin behaviour before anyone writes production code. Use when a change needs a definition of done, when a ticket is vague, or before a TDD slice starts.
Prove the suite is green and the project is in a known state before and after a change — if it is already red, stop. Use when starting work, after a slice, before a refactor, or when asked to check that nothing broke.
Answer one unknown in a clock, write the answer down, and throw most of the code away — instead of starting the feature in order to learn. Use when a slice cannot be estimated, before a rewrite, or when two approaches are both plausible.
Ship a behaviour to a slice of users with a kill switch, then delete the flag when it is done — instead of deploying to everyone and hoping. Use when a change is risky, when you need a cohort, or before a large rewrite goes live.
Change the shape of working code without changing what it does — small steps, tests after each one, behaviour-preserving commits. Use when the structure is in the way, after a slice has gone green, or before a behaviour change in tangled code.
Page people on what users can feel — error rate, latency past an SLO — not on causes like CPU, and only when the page includes a next step. Use when creating an alert, after a noisy night, or when the board is red and nobody is moving.
Implement one failing behaviour at a time — read the spec, write the test, write the smallest production change that turns it green. Use when coding from a spec, starting a TDD slice, or when a task is about to sprawl.
Decide where a system should split — what changes together stays together, and a boundary is a bet about future change. Use when adding a module, splitting a file that has grown, or reviewing a design that feels tangled.
Retire a feature on purpose — who still uses it, what it costs, a dated sunset, and a removal — instead of leaving it to rot on a flag. Use when usage is low, when two features do the same job, or before you build the replacement "alongside."
Find where the first session dies, name one bottleneck, and run one experiment — instead of "improving onboarding." Use when signups do not come back, when a launch looks busy and empty, or before you add another empty-state tour.
Decide where a model may draft and where it may not act — money, messages, deletes, anything a person cannot undo — instead of "the agent handles it." Use when wiring tools, before an agent sends or pays, or when a demo is about to become a product.
Sample live traces, grade a slice on a schedule, and catch drift the offline eval set never saw — instead of trusting a spreadsheet you ran once. Use when a model is in production, after a prompt or model change, or when quality complaints do not match your eval score.
Log events as queryable key-value records with a request id threaded through, so an incident is answered with a query instead of grep. Use when adding logging, debugging production, or when logs are unsearchable.
Handle webhooks that arrive twice, out of order, or during an outage — verify, persist, deduplicate on the provider's event id, then process. Use when consuming Stripe, GitHub, or any provider webhook.
Add timeouts, backoff with jitter, and a retry budget so failures recover instead of amplifying into an outage. Use when calling an external service, adding retries, or diagnosing a cascading failure.
Read EXPLAIN ANALYZE output to find why a query is slow — the expensive node, the row estimate that was wrong, and the index that would fix it. Use when a query is slow, before adding an index, or when a plan changed unexpectedly.
Locate and fix N+1 query patterns by counting queries per request rather than reading code, then batching the offender. Use when an endpoint is slow, when query counts scale with result size, or before adding an ORM relation.
Raise or restructure prices without a churn spike — grandfather existing customers, announce with notice, and measure the right number afterwards. Use when changing pricing, adding a tier, or considering an increase.
Make a model return data your code can parse every time — constrained decoding, a schema shaped for generation, and validation at the boundary. Use when parsing LLM output, extracting fields, or when JSON parsing fails intermittently.
Reduce an inference bill by measuring where tokens actually go, then applying caching, routing, and output limits in order of payoff. Use when LLM costs are rising, before scaling a feature, or when latency and cost both need cutting.
Capture a significant decision in one short document — the context, the options, the choice and its consequences — so nobody relitigates it from memory. Use when making an architecture decision, an ADR, or a hard call worth recording.
A 30-minute weekly pass that clears inputs, closes loops, and picks the next week's few real priorities — so the system stays trustworthy instead of becoming a graveyard. Use when running a weekly review, planning the week, or resetting a backlog.
Run meetings that produce decisions instead of updates — state the decision up front, invite only who is needed, and end with owners and dates. Use when running a meeting, setting an agenda, or fixing a recurring meeting nobody wants.
Read a research paper in three passes so you spend depth only on papers that earn it, and come away able to state the claim, the evidence, and the limitation. Use when reading a paper, doing a literature review, or summarising research.
Get productive in an unfamiliar codebase fast by tracing one real request end to end instead of reading files at random. Use when joining a project, onboarding, or opening a repo you have never seen.
Write the small text that carries an interface — buttons, empty states, errors and labels — so users know what will happen and what to do next. Use when writing UI copy, error messages, empty states, or button labels.
Run a critique that improves the work instead of collecting opinions — state the goal, critique against it, and separate observation from prescription. Use when reviewing a design, giving design feedback, or running a crit session.
Build a colour system with semantic tokens, a real contrast floor, and a dark mode that is not an inversion — so every new screen is legible by default. Use when defining colour tokens, adding a theme, or fixing contrast problems.
Write an engineering post people finish and share — lead with the result, keep the story concrete, and cut everything that is there to prove effort. Use when writing a technical blog post, a postmortem, or an engineering write-up.
Turn a rough draft into something tight by editing in passes — structure, then paragraphs, then sentences — and cutting the words that carry no weight. Use when editing a draft, tightening prose, or when writing feels flabby.
Write commits that explain why a change was made, so the history stays useful when someone reads it a year later with no memory of the ticket. Use when committing, squashing, or cleaning up a branch before review.
Get untested code under test before changing it by pinning its current behaviour, finding a seam, and testing through the smallest boundary that works. Use when modifying legacy code, code with no tests, or code nobody understands.
Change a database schema without downtime or data loss by expanding first, migrating in the background, and contracting only once nothing reads the old shape. Use when altering a schema, renaming a column, or planning a migration.
Review a pull request in a fixed order — correctness, then blast radius, then clarity — so the expensive problems surface before the cosmetic ones. Use when asked to review a PR, review a diff, or check changes before merge.
Make code faster by measuring first, fixing the largest real cost, and measuring again — instead of optimising the part that looks slow. Use when something is slow, before a performance rewrite, or when reducing latency.
Design an HTTP endpoint that is predictable to call and safe to change — resource-shaped URLs, honest status codes, useful errors, and pagination from day one. Use when adding an API endpoint or reviewing an API design.
Find the cause of a bug by halving the search space instead of guessing — bisect the timeline, the input, the code path, and the environment. Use when debugging, when a bug is hard to locate, or when something used to work.
Write release notes people actually read — organised by what changed for the user, leading with impact, and honest about breakage. Use when writing a changelog, release notes, or a "what's new" post.
Structure a landing page that converts — a headline naming the outcome, proof above the fold, and one obvious action — instead of listing features. Use when writing a landing page, a homepage, or a product launch page.
Interview users so you learn what they actually did, not what they think they would do — ask about the past, stay quiet, and separate signal from politeness. Use when doing user research, customer discovery, or validating an idea.
Work out what your product is, who it beats, and for whom — so the landing page writes itself and prospects understand you in one sentence. Use when positioning, writing a value proposition, or when nobody understands what you built.
Design tools an LLM can actually use — one job per tool, names that survive being read alone, and errors that tell the model how to recover. Use when adding a tool or function to an agent, or when a model keeps calling the wrong one.
Diagnose why a prompt underperforms and fix the cause — usually ambiguity, buried instructions, or missing examples — rather than adding more words. Use when a prompt gives inconsistent output or ignores instructions.
Build retrieval that actually finds the right passage — chunk on structure, combine keyword and vector search, rerank, and measure retrieval separately from generation. Use when building RAG, document Q&A, or semantic search.
Treat every piece of fetched content as untrusted input and design the agent so a malicious document cannot escalate into a real action. Use when an agent reads web pages, email, files, or any third-party data.
Pick a model by testing candidates on your own task against real cost and latency budgets, instead of trusting benchmarks or defaulting to the largest. Use when choosing an LLM, cutting inference cost, or considering a switch.
Replace "it seems better" with a small, honest test set — build cases from real failures, grade what actually matters, and keep a held-out slice. Use when measuring prompt or model changes, or when quality keeps regressing unnoticed.
Write an incident review that finds the systemic cause and produces owned actions, without naming a culprit — timeline first, contributing factors, then fixes. Use when writing a postmortem after an outage, a bad deploy, or any incident worth learning from.
Publish & fork community skills with Pro.
View Pro