Workflow

Creates and improves Bun-based tools for skills — decides when a tool earns its place, scaffolds zero-dependency scripts with dual output, validates tool quality, and wires tools into SKILL.md decision trees. Use when adding a tool to a skill, improving an existing tool, deciding whether something should be a tool or inline instructions, reviewing tool quality, or when the user says "add a tool to this skill", "write a validator for this skill", "make this repeatable", or "check this tool".

Use when the user asks to create, update, review, or refactor an agent skill, including requests like "turn this workflow into a skill", "make a skill for this", "fix this SKILL.md", "add references to this skill", "make this skill work in Codex and Claude", or "split this bloated skill". Creates skill directories, writes portable SKILL.md frontmatter and workflows, adds references, validates structure and token budgets. For adding executable helpers, use the tooling skill.

Manages Codex, Claude Code, and Cursor skill/plugin marketplaces — publishes plugin-owned skills, updates plugin groups, removes entries, packages skills for distribution, regenerates plugin manifests, and validates catalog integrity. Use when publishing a skill to the marketplace, bumping a version, removing a skill from the catalog, packaging a skill as a .skill file, regenerating marketplace files, moving a skill between plugins, fixing marketplace validation errors, or when the user says "publish this skill", "regenerate the marketplace", "move this skill to another plugin", or "package this skill".

Generates C4 model architecture diagrams (System Context, Container, Component) as Mermaid for embedding in docs — picks the right C4 level for the question being answered, labels every element with its technology and responsibility, and avoids the "everything touches everything" spaghetti that makes most architecture diagrams useless. Writes to .context/architecture/diagrams/. Use when the user asks for a diagram of their system, an architecture visualization, a container/component diagram, wants to see how pieces fit together, or mentions "C4".

Guides system architecture and decomposition — turns requirements into a concrete system shape by identifying components, drawing boundaries, tracing data flow, analyzing failure modes, and selecting technology. Covers the intellectual work of breaking a system apart, not the writing of a design document. Use when the user asks to architect a system, decompose a feature into components, figure out how services should talk to each other, evaluate system trade-offs, or says things like "how should we structure this", "what components do we need", "let's think through the architecture", or "where should this logic live".

Designs the data layer — schemas, entities, relationships, ID strategy, naming, tenancy, timestamps, indexes, audit logging, and migrations. Turns a set of domain concepts into a concrete Drizzle schema with all the small decisions that compound into either a clean data layer or a mess. Use when the user asks to design a schema, model the data, plan the database, add tables, review an existing schema, or says things like "what should the database look like", "design the schema for X", "add a table for Y", or "how should I store Z". Does NOT cover system decomposition (use architecture) or API design (use api-design).

Reviews and critiques an existing or proposed system design — flags single points of failure, missing non-functional requirements, scaling bottlenecks, security gaps, operational blind spots, unjustified tech choices, and places where the design will fall over under load or failure. Produces a structured review with severity-tagged findings, not just vibes. Use when the user asks for a second opinion on an architecture, requests a design review, wants feedback on a proposed system, pastes a design doc, or says things like "review this design", "what's wrong with X", "poke holes in this", or "is this a good architecture".

Mines recent Codex or Claude agent conversations and git history for struggles, repeated corrections, rework patterns, and taste signals — then turns findings into new skills or updates to existing ones. Use when retrospecting on recent coding sessions, extracting learnings, identifying skill gaps, improving skills from real usage patterns, codifying recurring preferences, or when the user says "retro this repo", "mine recent conversations", "what should become a skill", or "find repeated agent mistakes".

Creates decision trees that both humans and AI agents can follow reliably — captures expert knowledge as branching logic with concrete conditions, clear actions, and visible reasoning traces. Use when the user wants to document a decision process, create a troubleshooting guide, build a triage flowchart, write an escalation tree, or turn tribal knowledge into structured steps.

Interviews the user to extract their design taste, technology preferences, and opinionated defaults for a domain, then encodes those preferences into skill reference files, decision rules, conventions, and anti-patterns. Use when the user says "encode my taste", "add my preferences to this skill", "make this skill opinionated", "interview me about my preferences for X", or asks to capture style/defaults in a reusable skill.

Guides a full system design from idea to spec — sequences requirements gathering, architecture decomposition, data modeling, API design, and document writing into a coherent workflow with clear handoffs. Use when the user asks to "design a system", "build X from scratch", "architect something end-to-end", "plan a new service", or has a broad design ask that spans multiple concerns. Also use when the user says things like "I need to build X" without specifying which aspect to start with. This is the entry point for any design task that isn't clearly scoped to a single skill (data model only, API only, etc.).

End-to-end repository management: inspect and protect local state, create signed and well-scoped commits, split messy working trees, rebase or merge and resolve conflicts, open GitHub pull requests, repair PRs, watch and fix CI, clean stale branches/worktrees/stashes, and leave repos in a shippable state. Use when the user asks to commit, create a PR, clean up a repo, rebase, resolve conflicts, fix CI, make a PR merge-ready, watch checks, merge or prepare branches, or otherwise manage Git/GitHub repository state.