mirzaaghazadeh
UserDescribe a team of AI agents and they work on your repo around the clock. BYOK desktop app for macOS, Windows and Linux.
Categories
Indexed Skills (27)
working-unattended
Take a run from "nothing was assigned to me" to a pushed, tested change without asking anyone. Use on a check-in that found no new messages, on an escalation from one, or any time you are choosing your own work.
asking-the-owner
Decide when something is genuinely the owner's call, and then ask it well with ask_user — one-line title, a recommendation, real options, and a default so nothing stalls overnight. Use before escalating anything to the owner, and when writing an approval request or a report.
building-a-screen
Get a designed screen onto the glass without the classic desktop-app faults — a panel that will not fill its window, a popover clipped by its parent, a list that re-renders forever, text in the wrong direction. Use when writing or changing any UI code, and before saying a screen is done.
debugging-systematically
Get from a symptom to a fix without guessing — reproduce it, narrow it, prove the cause, then fix it and leave a regression test. Use when something is failing, flaky, or behaving differently than expected.
designing-an-interface
Design a screen someone can read at a glance and act on without being taught — hierarchy, density, the states you forgot, and copy that says something. Use before building any screen, panel, sheet or empty state, and when a screen "works" but feels wrong.
fixing-a-red-build
Handle a broken default branch or failing CI — establish what broke and when, get the branch green the fastest safe way, then fix it properly. Use the moment you notice main is red or the suite fails for reasons that are not yours.
getting-oriented
Learn an unfamiliar codebase before changing it — what it is, how it builds, how it is tested, what the house rules are. Use on your first runs in a workspace, or when you are handed a part of the repo you have never touched.
growing-the-team
Propose a new teammate with evidence, and write the soul and rules that make them useful on day one. Use when work is repeatedly blocked on a role nobody holds, or when the owner asks who the team is missing.
handling-secrets
Keep credentials out of the repo, the logs and your own messages — how to read a secret you need, what to do when you find one committed, and why you never move one somewhere new. Use whenever a task involves an API key, token, password, certificate or connection string.
making-it-faster
Fix a performance problem with evidence rather than instinct — measure first, find where the time actually goes, change one thing, and prove the win. Use when something is slow, when a build or suite is dragging, or before optimising anything.
planning-the-work
Turn a goal into tasks a teammate can actually finish — sized to one run, with a definition of done, an owner and an order. Use when you are given something large, when you run the standup, or when the team is busy but nothing is shipping.
refactoring-safely
Change the shape of code without changing what it does — get a test harness under it first, move in reversible steps, and keep the refactor out of the change that alters behaviour. Use before restructuring, renaming across files, or untangling something to make a feature possible.
remembering-and-learning
Keep what you learned so future runs start ahead — what belongs in remember, what belongs in a skill written with learn_skill, and what belongs nowhere. Use at the end of a run where you worked something out the hard way.
reviewing-code
Review a teammate's change so the review is worth the time it costs — read the diff, run it, look for the bug that matters, and leave evidence rather than opinions. Use when reviewing a pull request, a branch or a patch.
reviewing-for-security
Take a security pass over a change — where untrusted input reaches something dangerous, what the authorisation check misses, and what leaks in a log or an error. Use when reviewing code that touches input, auth, files, queries, shell commands or the network.
running-a-spike
Answer an open technical question with a time-boxed throwaway experiment instead of arguing or over-building. Use when the team does not know whether an approach will work, which library to pick, or how much a change would cost.
shipping-a-change
Take one task from "assigned" to a reviewable change — branch, small diff, tests, green checks, honest commit message, pull request. Use whenever you are about to edit code you intend to merge.
staying-inside-budget
Do the work for what it is worth — spend your run on the thing that was asked, not on re-reading the repo, arguing with a teammate or grinding a stuck task. Use when a job looks large, when you have failed twice already, or when you are about to start something open-ended.
triaging-an-issue
Turn a report into something the team can act on — reproduce it, judge how much it matters, and either file it as a well-shaped task or close it. Use when a bug is reported, when an issue lands, or when the owner mentions something is broken.
updating-dependencies
Upgrade packages without breaking the build or importing something nobody vetted — read the changelog, move in separate steps, and prove it still works. Use when updating a dependency, responding to a security advisory, or adding a new package.
using-github
Work the forge from the command line with gh — open and describe a pull request, read review comments, check why CI failed, file and close issues. Use when a task involves a pull request, an issue, or a failing check rather than only local code.
working-safely
Stay inside the limits the owner set — the workspace fence, the permission rules, approvals that block a tool call, and commands that cannot be undone. Use before running anything destructive, touching a path outside the repo, or reaching a service on the network.
working-with-git
Use git without losing work or rewriting somebody else's history — branches, clean commits, conflicts, and the recovery moves when something has gone wrong. Use before branching, rebasing, resolving a conflict, or any command that discards changes.
working-with-teammates
Talk to the rest of the team so it moves work forward rather than filling channels — when to post, when to ask a named teammate, how to hand off a task, and how not to end up in a loop of replies. Use before posting in a channel, assigning work, or answering a mention.
writing-a-status-report
Write a standup plan, an end-of-day report or a retrospective that the owner can read in thirty seconds and act on. Use for any scheduled check-in, daily summary, weekly retro or "where are we" request.
writing-documentation
Write docs that stay true to the code — README, reference, release notes and comments that answer what a reader actually needs. Use when behaviour changed, when a README no longer matches, or when you are asked to document something.
writing-tests
Write tests that are worth keeping — testing behaviour rather than implementation, covering the case that actually breaks, and failing for a reason someone can read. Use when adding a test, fixing one, or deciding a change needs coverage.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.