mimukit
UserMy personal collection of AI agent skills; the *kit family. Portable, one install away.
Categories
Indexed Skills (18)
skillkit
Create a new AI agent skill from scratch — kit-convention naming, drafting, live testing, and publishing included. Use when the user wants to author, scaffold, or draft a new skill, runs "/skillkit", or says something like "help me make a skill for X". Interviews for intent, proposes on-brand kit names, drafts a conventions-compliant SKILL.md.
commitkit
Create a git commit with a Conventional Commits message derived from the actual diff. Use when the user asks to commit changes, says "commit this", runs "/commitkit", or wants a well-formed commit message written for staged work — even if they don't spell out the format.
grillkit
Grill the user relentlessly about any idea, plan, or design — one decision at a time, each with a recommended answer, until you both share the same picture. Use when the user wants to stress-test or pressure-test an idea, says "grill me", "grill this plan", "poke holes in this", "interrogate my design", or otherwise asks to interrogate a concept before committing to it — a rough idea, a plan file, an architecture, or a PR.
handoffkit
Compact the current conversation into a handoff document another agent or session can pick up cold — goal, state, next steps, key artifacts by reference, and constraints. Use when the user wants to hand off work, says "write a handoff", "create a handoff doc", "summarize this for the next session", or "pass this to another agent".
humankit
Strip the tells of AI-generated writing from prose so it reads like a person wrote it. Use when asked to humanize text, remove AI-isms, make writing sound less like ChatGPT, edit out "AI slop," or review a draft for robotic phrasing — covers em-dash overuse, rule-of-three cadence, promotional puffery, filler, hedging, and the AI vocabulary words.
implementkit
Implement a plan, spec, or issue into working code — no commit, that's commitkit's job — picking straight-through vs TDD mode by precedence (prompt → CLAUDE.md → repo habit → ask), then running the repo's test + build/typecheck gate before declaring done. Use when the user says "implement this plan", "build this issue", "write the code for plan-<slug>-YYYY-MM-DD.md", "implement #42", "do this TDD", or hands off a hardened spec to be turned into code — even if they don't name a mode.
issuekit
Own the GitHub issue lifecycle with three modes — create issues from a plan-<slug>-YYYY-MM-DD.md or a description (kept independent for parallel git-worktree work, with any prerequisite labeled `blocked`), sync PR↔issue links after merge, and triage the tracker. Use when the user says "create issues from this plan", "file an issue", "sync my issues", "close the issue this PR fixed", "triage the backlog", "issuekit", or wants issues opened, reconciled, or reviewed with the gh CLI.
orcakit
Bridge a GitHub issue to an Orca worktree and back — turn a `ready` issue into an isolated Orca worktree branched off origin/main with its label flipped, then reconcile the tracker and remove the worktree once the PR lands. Use when the user says "start issue #N", "spin up a worktree for #N", "finish #N", "orcakit", or wants an issue's isolated workspace created or torn down.
plankit
Turn a rough feature or change into a structured plan document (docs/plans/plan-<slug>-YYYY-MM-DD.md) before any code — brainstorm the approach, settle the big decisions, and write a plan that can be hardened and turned into issues. Use when the user says "plan this feature", "brainstorm a plan/PRD/spec", "write a plan doc", "help me think through this change before building", or runs "/plankit" — the front of the plan → grill → file workflow.
prkit
Draft and open a GitHub pull request from your branch — title, summary, and test plan written from the actual commits and diff, then created with the gh CLI, embedding verifykit proof artifacts inline when a bundle is present. Use when the user asks to open a PR, says "create a pull request", "raise a PR", "submit this for review", or "gh pr create" — even if they don't spell out the title or body.
qakit
Generate a step-by-step manual QA and test plan for a feature just implemented, grounded in the actual code changes, and save it to docs/qa for a human to run. Use when a coding session wraps and you want to hand-test the result, or the user says "write a QA plan", "make a manual test plan", "how do I test this", "generate a testing plan for this feature", or runs /qakit.
repokit
Set up a GitHub repo's metadata through the gh CLI — an inferred one-line About description + topics from the repo's own contents, and the issuekit lifecycle labels. Use when the user says "repokit", "set the repo description", "add topics/tags", "write an About blurb for this repo", "provision the workflow labels", "set up this repo's labels", or "configure this repo's metadata" — anything about a repo's About panel or its label vocabulary.
reviewkit
Review AI-agent-implemented code specifically — four ordered passes for convention-fit, agent-slop signatures, requirement-completeness, then correctness — against the working tree or the branch diff, findings ranked by severity and backed by quoted evidence. Use when the user says "review this code", "review my changes", "review this diff", "check the agent's work", "/reviewkit", or wants a self-review of AI-written changes before commit or PR — even if they don't name the passes.
domainkit
Maintain a project's domain model as a consented byproduct of design work — a CONTEXT.md glossary of the ubiquitous language and docs/adr/ decision records. Use when a domain term needs pinning down or is used inconsistently, when a hard-to-reverse trade-off decision gets settled, when the user says "record this decision", "write an ADR", "update the glossary/ubiquitous language", "add this term", or when another skill needs to keep the domain model current — it scribes the model, it doesn't interrogate it.
statuskit
Survey a project's status and recommend the single best next move — a read-only sweep of the git working tree, GitHub issues, open PRs, and unfiled plans, rendered as a one-screen dashboard with one finish-first action crowned and routed to the kit that does it. Use when you sit down at a project and ask "what should I do next", "check project status", "where's this at", "what's next", "project status", "orient me", or run "/statuskit".
afkkit
Run a groomed `ready` GitHub issue through the whole build span unattended — worktree, implement, commit, review, fix, QA plan, and open PR — so one issue reaches a reviewable PR with no human at the keyboard. Use when the user says "afkkit", "run issue #N unattended", "work the ready issues while I'm away", "autopilot this issue", "take this issue to a PR without me", or wants the middle of the kit workflow driven end to end on its own.
researchkit
Research the credible options for a technical decision and recommend one — a tool, library, framework, architecture, or service — grounded in primary sources with cited, dated evidence. Use when the user asks "which should I use, A or B", "compare X and Y", "evaluate options for Z", "what's the best tool/library/service for …", "should we use X or Y", "research X before we build", or runs "/researchkit" — the decision research that front-runs a plan.
verifykit
Prove a frontend feature actually works by driving it in a real browser and capturing screenshots + a short GIF as PR-ready proof, published so a pull request can embed it inline. Use when a frontend change is built and you want visual evidence it works before opening the PR — "verify this feature", "capture proof it works", "record the flow working", "prove the UI change", "/verifykit", or when a PR needs proof artifacts to attach.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.