JasperHG90

Author one loop-harness planning ticket in the format the implement-ticket loop consumes. Use when asked to plan a feature, scope a change, draft a ticket, or turn a described problem into a ticket the loop can run. Writes one ticket file to the configured plans directory.

Run one planning ticket through the loop lifecycle - perceive (ledger + git reconcile), implement tests-first, gate via `loopctl stamp`, self-review, adversarial review, commit, close via `loopctl finish`. Use when asked to implement the next ticket, run the loop, or continue autonomous ticket implementation.

Generate static artwork/illustrations for a repo with Nano Banana Pro (aka "nano banana", Gemini 3 Pro Image) via the bundled generate_art.py — craft a detailed prompt, run the script, view the result, iterate. Use this whenever the user wants to create, generate, or regenerate a visual asset for a project: an architecture diagram, portrait, card/illustration, icon, splash, or any image that lands as a PNG in the repo — even if they don't name the tool or just say "make me an image / a picture of X". Do NOT trigger for application runtime image needs, or for editing source code rather than producing an image file.

Remove a solid background from an image and write a transparent PNG, using the bundled remove_background.py. Use this whenever the user wants to knock out, drop, or make transparent the background of a logo, banner, icon, or other static image asset in a repo, or to trim an asset to its content and pad it. Pairs with generate-art: generate a flat asset, then key its background here. Do NOT trigger for photo cutouts needing subject segmentation, for runtime image processing, or for editing source code rather than an image file.

Teach the user a new codebase, technology, framework, or system by walking through it from high-level architecture down to implementation details using a paginated, layered approach. Use this skill whenever the user wants to understand how something works, needs onboarding onto a new technology, asks you to explain a system end-to-end, or says things like "walk me through", "explain how X works", "I need to learn X", "teach me", or "help me understand". Also use when the user shares documentation and asks to be taught from it.

Write or refactor project documentation — tutorials, how-to guides, reference pages, and explanation articles — using the Diátaxis framework. Enforces strict mode purity (a tutorial is not a how-to is not a reference is not an explanation), Orwell's six rules for clear prose, and a ladder-of-abstraction rhythm where concrete examples open and close each piece. Targets HUMAN readers — not agents — so emphasizes plain, everyday English over jargon. Use whenever the user asks to write, draft, refactor, edit, improve, or polish documentation — phrases like "write a tutorial", "draft a how-to", "turn this into a reference", "document this feature", "rewrite this doc", "improve the README", "add user docs", "document the API", "explain how X works for newcomers", or any task that produces user-facing prose for a software project. Triggers even when the user does not say "Diátaxis" explicitly — any doc-writing or doc-refactoring task gets this lens.

Create and maintain a MANIFESTO.md at a project's root — a living document capturing the project's vision, architecture, architectural rules, and design rules, where every hard "invariant" is anchored to the code that enforces it. Use this whenever the user wants to "write/set up a manifesto", "document the architecture and design rules", "create a vision/design doc", "capture our architectural invariants", or asks how a project is *supposed* to be built. ALSO use it proactively to keep the doc honest: whenever the user makes or describes an architecturally significant change — a new module or package, a changed/added invariant, a refactor of a core boundary, a dependency added or removed, a schema change — offer to reconcile MANIFESTO.md, even if they don't mention the manifesto. Three modes: init (interactive Q&A + codebase mining to bootstrap the doc), sync (reconcile the doc with changed code), and verify (read-only audit that every enforcer still resolves).

Review code for architectural quality, design principles, and language-specific best practices. Works top-down: starts with system architecture and abstraction boundaries, then moves to design principles (SOLID, coupling, cohesion), then to language-level patterns and anti-patterns. Supports any language but has deep Python expertise (typing, async, protocols, testing). Use this skill whenever the user asks to review code, says "review this", "review my PR", "what's wrong with this code", "code review", "check my code quality", "how can I improve this", "python review", "/python-review", or wants feedback on code quality, architecture, or design. Also use when the user pastes code and asks for opinions or improvements.

Deliberately capture what you JUST did as a Memex case — a worked episode (trigger / situation / actions / outcome / lesson) the system derives a reusable procedure from. Use right after finishing a multi-step task, diagnosing a bug, or resolving an incident, or when asked to 'record/log/save how I did this'. Distinct from /remember (auto-routes by shape) and /extract-case (converts existing content) — this is the structured, in-the-moment path.

Resume work from previous /handoff notes. Presents a multi-select list of the most recent handoff summaries, lets the user pick any number of relevant items (or 'load more'), then loads every selected note, summarizes them jointly, and asks what the next steps should be. Use at the start of a fresh session, or when the user says 'pick up where we left off', 'continue', 'what was I working on', 'resume', or 'catch me up on this'.

Tell Memex a surfaced memory was wrong, outdated, or noise. Use whenever you say 'stop suggesting that', 'that's stale / outdated / wrong', 'we removed that', or want a misleading fact to stop surfacing — records a not_helpful outcome on the offending unit(s) and deprioritizes them (the negative-signal loop). NOT for confirming a fix worked (that's a helpful outcome).

Turn a note, a markdown file, or a URL into a Memex case — but only when the content actually contains a reusable how-to / worked episode. Gated: if there's no case in it, files nothing.

Write a technical handoff summary of the current work to Memex — a descriptive, summarizing writeup of what you've been doing, the approach and key decisions, where it stands, and what's next — so you (or another agent) can pick the thread back up later. Use at the end of a workday, when wrapping up an involved conversation, or whenever the user says 'hand this off', 'write up where we are', 'summarize this so I can continue later', or 'I'll come back to this'.

Distill the durable learnings from the current session and save them to Memex, routing each into the right memory layer by shape. Use when the user says 'capture what I learned', 'save the lessons from this session', 'what should we remember from this', or wants the takeaways from the whole conversation kept — as opposed to one named episode (`/case`) or one supplied fact (`/remember`).

Review and resolve Memex memory-hygiene findings — stale facts, near-duplicates, contradictions, orphaned mental models, mis-routed notes. Use when the user says 'lint my memory', 'clean up stale/duplicate memories', 'triage the maintenance ledger', or wants to work through the linter's pending findings. The agent explains each finding and, with your go-ahead, resolves or dismisses it.

Search Memex long-term memory. Returns facts, notes, and entities matching the query.

Release a Claude Code plugin distributed via git — bumps the version in its .claude-plugin/plugin.json, keeps any marketplace.json entry in sync, commits, and pushes. Use whenever the user says "release the plugin", "bump the plugin version", "publish the Claude Code plugin", "ship the plugin", "cut a plugin release", or otherwise wants to version a plugin whose plugin.json holds the version. NOT for tag-and-CI release flows where a pushed v* tag builds artifacts — use the `release` skill for those.

Release a new version of a project. Handles version bumping (alpha / release candidate / stable), tagging, pushing, creating a GitHub release with curated release notes, and monitoring the CI pipeline until success. Use whenever the user says "release", "new version", "tag a release", "bump version", "ship it", "cut a release", "cut an RC", "promote RC", or anything about creating a new project version/tag. NOT for releasing a Claude Code plugin that is versioned in its .claude-plugin/plugin.json and distributed straight over git with no tag-triggered build — use the `release-claude-code-plugin` skill for that.

Creates a "rule" — a short, always-on guidance file (Markdown with name/description frontmatter, optionally path-scoped) that is injected into an agent's context to enforce or nudge a standing behavior. Writes it either into this repo's rules/ library or a project's .claude/rules/ directory, walking from intent through a fit check, interactive follow-ups (path scope, enforce-vs-nudge, save location, duplicate check), and a terse draft. Use whenever the user wants to create, write, add, scaffold, or draft a rule / constraint / guardrail / coding convention / standing instruction / always-on guidance / .claude/rules entry, or turn a repeated correction ("stop doing X", "always do Y") into a permanent rule. NOT for: authoring a reusable multi-step procedure (use skill-creator); a delegatable subagent (use agent-creator); editing settings.json, hooks, or permissions (use update-config); or recording project-specific facts like build commands and directory layout (those belong in CLAUDE.md / AGENTS.md, not a rule)

Scan a repository and produce a comprehensive architectural blueprint document with tech stack, component maps, Mermaid diagrams, data flow, API surfaces, dependency graphs, and design patterns. Spawns parallel analysis agents for speed. Use whenever the user says "blueprint", "architecture overview", "architectural blueprint", "map this repo", "codebase analysis", "system design doc", "repo scan", "how is this repo structured", "document the architecture", or wants to understand, document, or map the architecture of a codebase. Also use when onboarding to a new codebase and wanting a high-level understanding, or when asked to create technical documentation for a project. For standalone C4 diagrams (context, container, component) without a full document, use the c4-diagrams skill instead.

Create C4 model architecture diagrams (system context, container, component, plus dynamic and deployment views) as Mermaid, for software systems and data platforms. Use when the user says "C4", "C4 model", "context diagram", "container diagram", "component diagram", "system context", "architecture diagram", "diagram this system", "visualize the architecture", "diagram the data platform / pipeline", or wants audience-appropriate views of a system at different zoom levels. Also use to review or fix an existing C4 diagram. For a full written blueprint document of a repository, use the blueprint skill instead.

Creates a Claude subagent definition file (a .md agent spawned via the Agent/Task tool) and iteratively improves it — the way skill-creator does for skills, but adapted to the physics of subagents (isolated context, return value is data not chat, tool allowlist as guardrail, name and description as delegation trigger). Walks you from intent through the design dimensions, writing the file, testing it on realistic delegation prompts, and tuning its trigger. Use whenever the user wants to create, design, write, scaffold, draft, or improve a subagent / sub-agent / custom agent / agent definition, build an agent for a skill's agents/ directory, set up a specialized agent to delegate to, or tune an existing agent's description / tools / model. NOT for: creating a skill (use skill-creator); orchestrating a multi-phase multi-agent build or "agent team" (use dev-team); writing a one-off Agent-tool prompt you will not reuse; or authoring a multi-agent Workflow script.

Record polished GIFs (and MP4/WebM/PNG) of terminal programs — CLIs, TUIs, REPLs, dotfiles, your own tools — by scripting them with VHS. Use this whenever the user wants to "make a gif", "record a terminal", "capture a CLI/TUI demo", "show this command running", "create a demo for the README", "animate my tool", "screen-record the terminal", or asks for an asciinema-style recording, a terminal screenshot, or a demo of how a command-line program behaves. Trigger even when the user only describes the behavior they want to capture (e.g. "show what happens when I run `mytool init`") without naming GIF or VHS explicitly.

Generate a hierarchical page index — a table-of-contents tree with per-section and per-block summaries — from a markdown or text document, using DSPy with ANY model (ollama, gemini, claude, openai, or anything litellm supports). Use this whenever the user wants to outline, index, map the structure of, build a TOC for, or extract the hierarchy of a document or markdown file, even if they don't say the words 'page index'. The script is self-contained and portable: it depends only on dspy, tiktoken, regex, and pydantic — no database, no server, no Memex install.

Use whenever the user or another agent asks to install, add, update, remove, roll back, search for, or list skills, sub-agents, or rules managed by aim. Covers `aim skill`, `aim subagent`, and `aim rule` commands. This skill never registers source repositories — if a repo is missing, defer to the repo-add skill. Always prefer the `--compact` output format to keep context small.

Use when the user asks to register or add a source repository for aim — the repo that provides skills, sub-agents, and/or rules. Handles `aim repo add`, `aim repo list`, `aim repo refresh`, and `aim repo remove`.

Extracts 'version' or 'uuid' fields from YAML frontmatter using uv.