mimukit
UserMy personal collection of AI agent skills; the *kit family. Portable, one install away.
Categories
Indexed Skills (34)
commitkit
Create a git commit with a Conventional Commits message derived from the actual diff, then push it to origin. 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, a round of unblocked decisions 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, whether 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. Explicit invocation only, because auto-triggering is disabled so a session compaction never fires mid-work. Use when you deliberately run "/handoffkit" (optionally with a focus argument) to hand off work, write a handoff doc, or summarize the session for the next 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 without rewriting it. Covers em-dash overuse, puffery, filler, and the AI vocabulary words.
implementkit
Implement a plan, spec, or issue into working code, picking straight-through vs TDD mode by precedence (prompt → CLAUDE.md → repo habit → ask), then running the repo's test + build gate before declaring done. Use when the user says "implement this plan", "implement #42", "do this TDD", or "apply these review findings". It stops before the commit and runs attended; the unattended issue-to-PR span is afkkit's.
issuekit
Own the GitHub issue lifecycle in five modes: create issues from a plan or description, start a `ready` issue into its own worktree, close one out once its PR merges, sync PR↔issue links after merge, and triage the tracker for lifecycle, priority, and title gaps. Use when the user says "create issues from this plan", "file an issue", "open a GitHub issue", "log this as a task", "add this to the backlog", "make issues for these TODOs", "start issue #42", "close #42", "sync my issues", "triage the backlog", "set the priority on #42", "relabel #42", "rename issue #42", or "fix the titles on these issues". It runs the tracker only; it writes no plan and no code.
orcakit
Keep the Orca desktop app's workspace list honest about the git worktrees your workflow actually creates: link each one to its issue, keep its status current, and clean out the ones whose work already merged. Use when the user says "orcakit", "clean up my orca workspaces", "my Orca sidebar is full of finished work", "which workspaces are stale", "link my worktrees to their issues", "remove the workspaces for merged issues", or "where should Orca put new worktrees".
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" or "brainstorm a plan/PRD/spec", the front of the plan → grill → file workflow. It stops at the plan document; it files no issues and writes no code.
prkit
Draft and open a GitHub pull request from your branch, with 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 and configuration through the gh CLI: an inferred one-line About description + topics from the repo's own contents, the workflow labels (issuekit's lifecycle and priority sets, plus an `ai-review` trigger label for AI PR review tools), and a full new-repo setup that also applies the house repo settings (merge-commit-only, delete-branch-on-merge) and scaffolds the baseline files (LICENSE, README, .gitignore, AGENTS.md), plus a one-time migration that renumbers the repo's docs/ artifacts into creation order. 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", "add priority labels", "configure this repo's metadata", "set up this new repo", "make this repo match my conventions", "number my docs files", "renumber the docs", or "my docs don't sort by date", meaning anything about a repo's About panel, its label vocabulary, bringing a fresh repo up to conven
reviewkit
Review AI-agent-implemented code specifically, in four ordered passes (convention-fit, agent-slop signatures, requirement-completeness, 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", or "check the agent's work" before commit or PR.
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, when a hard-to-reverse trade-off decision gets settled, when the user says "write an ADR" or "update the glossary", or when another skill needs to keep the domain model current. It scribes the model, it doesn't interrogate it.
skillkit
Create a new skill from scratch for this collection, conventions and testing 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.
statuskit
Survey a project read-only (working tree, issues and their priority, open PRs, unfiled plans) into a one-screen dashboard that crowns one finish-first next move routed to the kit that does it, saved by default as a throwaway snapshot under docs/status/. Use when you sit down at a project and ask "what should I do next" or "check project status"; add "no file" to skip the snapshot. It reads and recommends only; the crowned kit does the work.
afkkit
Run a groomed `ready` GitHub issue through the whole build span unattended, covering worktree, implement, commit, verify-and-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 "run issue #N unattended" or "work the ready issues while I'm away". It starts from a groomed issue; planning and grooming stay attended.
validatekit
Pressure-test a SaaS or startup idea before you build it, with a few forcing questions, an optional market and competitor scan, an honest verdict graded on the evidence you can actually produce, the narrowest wedge worth testing, and one real-world assignment. Use when the user says "validate my idea", "is this worth building", "should I build this", "pressure-test my startup idea", "will anyone pay for this", or runs "/validatekit", and proactively whenever someone describes a new product or business idea and wants to know whether to build it.
gitkit
The shared git layer every other skill borrows: where a worktree lives and what it's called, how to create/adopt/tear one down, which branch is the base, whether to rebase or merge, how to sync a feature branch with its base and force-push it, how to sweep merged worktrees and branches away, how to recover work that looks lost, and how to stack a branch on one still in review. Use when the user says "spin up a worktree for this", "make me a worktree", "where's the worktree for #42", "tear down this worktree", "clean up my merged worktrees", "what's the base branch here", "should I rebase or merge", "sync this branch with main", "this PR is behind, bring it up to date", "I lost a commit", "recover my work after a bad rebase", "stack this on #43", or runs "/gitkit", and whenever another skill needs any of those answers.
mergekit
Take an open GitHub PR and set it up for review on your machine (worktree, project running, review pack), then merge it once you say so, or service review feedback on a PR you authored. Use when you say "pull PR #34 down so I can test it", "merge PR #34", "address the review comments on my PR", or "my PR is red, fix the CI".
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.
wikikit
Generate and maintain a project's reader-facing documentation in-repo (getting-started, how-to guides, architecture overview, runbooks), every command verified against the code, in four modes: init, update, audit, and an opt-in publish that mirrors the set to the GitHub wiki. Use when the user says "write docs for this project", "update the docs", "our docs are stale", or "sync the docs to the GitHub wiki". Not an agent handoff, and not the glossary or ADRs.
designkit
Derive a project's design system from the UI it already ships and keep it true as the code moves, producing a spec-compliant DESIGN.md at the repo root, validated by the official linter. Use when the user says "write a DESIGN.md", "document our design system", "extract our design tokens", "our design system is out of date", "audit our design tokens", "what colors does this project actually use", or "/designkit". Not a UI generator, not a palette library.
prototypekit
Build throwaway code that answers a question, whether an interactive state model you can drive, a script that measures one thing, or competing UI mocks to choose between, then fold the answer into the decision and delete the code. Use when the user says "prototype this", "spike this", "does this state model hold up", "is this library fast enough", or "mock up three versions". Not a demo generator and never production code.
uikit
Build production UI that reads as a deliberate choice for this project rather than an LLM default, and audit shipped UI for the tells that give it away. Use when the user says "build this page", "make this UI not look AI-generated", "this looks like slop", "design this screen", "audit our UI", "make the frontend look good", or "/uikit". Reads a project's DESIGN.md when one exists; never writes it.
promptkit
Sharpen the prompt before you send it, whether the one-shot instruction you're about to hand a coding agent or the system prompt your application ships. Use when the user says "optimize this prompt", "what's wrong with this prompt", "write or rewrite the system prompt my app ships", or "/promptkit".
refactorkit
Survey an existing codebase for the structural change worth making, then rank the candidates, crown one, and write it up as a reviewable proposal. Use when the user says "where should I refactor", "this code is hard to change", or "audit the module boundaries". It proposes and never edits code.
verifykit
Show a frontend change in a real browser, or prove it for a PR: drive the feature, capture screenshots (plus a short GIF for proof), and publish proof so a pull request can embed it inline; or set up the browser driver and the publish path on a machine. Use when a frontend change is built and you want to see it or want visual evidence it works before opening the PR: "show me what it looks like", "screenshot this", "verify this feature", "record the flow working", "prove the UI change", "/verifykit", when a PR needs proof artifacts to attach, "set up verifykit", or "install the browser driver".
debugkit
Chase a symptom to its true cause: reproduce it, shrink it, write falsifiable hypotheses, and prove the cause by toggling the symptom on and off, then hand over a failing reproduction instead of a fix. Use when the user says "debug this", "why is this failing", "find the root cause", "what's causing this bug", "this test is flaky", "it broke after the upgrade", "it worked yesterday", "this got slower", or "/debugkit". It diagnoses and never applies the fix.
paseokit
Push the git worktrees your workflow actually creates into Paseo's workspace registry, because Paseo discovers nothing on its own. Use when the user says "paseokit", "sync my worktrees to paseo", "sync all my projects to paseo", "my paseo sidebar is missing worktrees", "paseo doesn't show my worktree", or "where should paseo put new worktrees". It also reaps the finished work and the dead rows: "clean up the worktrees whose PRs merged", "clean up my paseo workspaces", "my paseo sidebar is full of dead entries".
releasekit
Cut a release from the Conventional Commits a repo already writes: derive the semver bump and a changelog from the commit range, bump the manifest, tag it, and publish a GitHub release, all behind a mandatory preview. Use when the user says "cut a release", "tag a version", "release this", "what's the next version", "generate a changelog", "ship v2", or "/releasekit". It never publishes to a package registry and never moves a published tag.
testkit
Retrofit an automated test suite onto a working codebase that has none: rank the untested surface, crown a slice, stand up a runner, and write tests that were each watched to fail before they were kept. Use when the user says "this project has no tests", "add test coverage", or "what should I test first". It never fixes the bugs it finds and never restructures code to make it testable.
tutorkit
Teach a topic across many sessions, with one learning repo holding a folder per topic, lessons pitched at what you already know, and spaced retrieval that makes it stick. Use when the user says "teach me X", "tutor me on X", "I want to learn X", "explain how X works", "quiz me on what I learned", "what's due for review", "test me", "am I ready", "exam me on X", "place me on X", "where am I with my learning", "what am I studying", "learning status", "show my progress", or runs "/tutorkit". Tuned for software engineering topics and works for any other.
ideakit
Think an idea through across many sessions, with one ideas repo holding a folder per idea, a jotpad for the thoughts that have none, one idea open at a time, and nothing written to disk until you ask for it. Use when the user says "capture this idea", "I just had an idea", "jot this down", "random thought", "promote that jot", "let's think about the <X> idea", "brainstorm <X> with me", "what was I thinking about <X>", "where do my ideas stand", "what should I think about next", or names their ideas repo or runs "/ideakit".
namekit
Name a project to a naming convention you already use, then prove the name is free on the domain, npm, and GitHub before you commit to it. Use when the user says "name this project", "what should I call this", "give me project name ideas", "come up with a name for X", "is <name> taken", "check if this name is available", or "/namekit".
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.