
Shape a rough plan, idea, or feature request into something concrete by working through it like a smart cross-functional advisor with strong instincts across engineering, product, design, ops, and business. Walks the design tree alongside the user, recommends answers, pushes back on weak assumptions, grounds claims in the actual codebase, and surfaces load-bearing (hard-to-reverse) decisions before they get baked in. Use whenever the user wants to stress-test a plan, flesh out a vague idea, get a second opinion on a design, scope a feature into tickets, write a spec, or just think through something out loud — including phrasings like "grill me", "challenge this", "help me think through X", "I want to build Y", "flesh this out", "shape this up", "write a spec", or "what do you think of..."
Runs a project's scheduled health checks in order — syncing the main worktree's main branch with origin, refreshing installed skills, then triaging the Linear backlog to pick and ship a next ticket. Use when the user asks to run the project health check, do the scheduled/periodic project checks, run routine project maintenance, or when this is invoked as a recurring scheduled agent. The Linear team (name or key) to triage is provided when the skill is invoked; an optional date cutoff for ignoring stale tickets may also be provided.
Commit changes and create or update a pull request following project standards. Use when the user wants to commit work, create a PR, update an existing PR, or use the /pr command.
Fetch and triage code review findings from PR comments and/or review markdown files. Pulls review comments from the current branch's open PR (GitHub review comments, inline suggestions, and general comments that look like code reviews — from Claude Code, Codex, Copilot, etc.), classifies which findings are valid versus ignorable, explains how valid findings should be fixed, and sets up a thread watcher for new PR review comments when working against a GitHub PR. Does not modify code unless the user explicitly gives approval to apply fixes. Also accepts local review files. When explicitly asked to commit and push review fixes, pushes the branch and comments "@codex review" on the PR to request a fresh review. Triggers on requests like "fix PR reviews", "fix review comments", "fix PR feedback", "apply review fixes", "fix code review findings", "check new findings", or any mention of fixing/issues from PR comments or review files.
Reimplement the current branch on a new branch with a clean, narrative-quality git commit history. Use when the user wants to clean up messy commits, create a tutorial-style commit history, or prepare a branch for review with logical, self-contained commits. Triggers on requests like "clean up my commits", "reimplement this branch", "create a clean history", or "make my commits reviewable".
End-to-end PR workflow: prepares a branch, commits staged changes, creates or updates a GitHub PR, then runs 5 rounds of AI code review from Codex, Greptile, and Devin — fixing findings after each round. Codex is the primary signal for round completion; Greptile and Devin are best-effort. After 5 rounds, the PR is submitted. Use when the user wants to ship a PR through automated review.
Map every Codex and Claude Code session for a project to the git worktrees they ran in, in an interactive local UI. Use whenever someone wants to see, search, audit, or clean up past AI coding-agent conversations and the worktrees those ran in — e.g. "what Codex sessions ran on this repo", "list my Claude Code sessions", "which worktree was that session in", "find the chat where I refactored auth", "archive old Codex sessions", or "show every session across my worktrees". Reach for it to untangle which of many worktrees still has live agent history attached. This is about Codex and Claude Code transcript history plus git worktrees — not HTTP, login, or auth sessions, not terminal or tmux sessions, and not user-research sessions.
Generally-applicable frontend/UI best practices. Use whenever building, modifying, or reviewing UI — adding a form/button/dialog/modal, wiring keyboard shortcuts, creating any interactive surface that submits a form, or any time TSX/JSX is being written or edited. Consult BEFORE writing the code so the patterns are baked in, not retrofitted. If a scenario described in the skill body matches the work, apply the pattern — don't ask, just follow it (call out the choice in one line so the user can override).
Creates a new Linear issue from a free-form description. Drafts a structured title and body, picks team/project/labels/priority from the connected workspace, shows the draft to the user for approval, then creates the ticket. Use when the user asks to "create a Linear ticket", "file an issue", "make a ticket", "open an issue in Linear", or any request to log a new bug/feature/task.
Generally-applicable backend/data best practices. Use whenever writing or modifying backend/data code — API routes, server actions, DB writes, background jobs, agent tools, import flows, webhooks, paste handlers, or anywhere data enters the system. Consult BEFORE writing the code so the patterns are baked in, not retrofitted. If a scenario described in the skill body matches the work, apply the pattern — don't ask, just follow it (call out the choice in one line so the user can override).
Runs on a schedule to mine recent Codex and Claude Code conversations across configured projects, find moments where things went off plan (the user had to steer, correct, abort, or re-explain), and propose targeted improvements to the specific skills that were in use at the time. Opens one pull request per run against the skills repo, with each proposed edit annotated with the concrete steering moment that motivated it. Also analyzes its own runs (the `skills` repo is one of the configured projects) so it iteratively improves itself. Use this skill when the user asks to "analyze recent conversations", "find what went wrong", "improve skills based on past runs", or sets up a scheduled run of skill-improver. Make sure to use this skill whenever the user mentions recursive skill improvement, post-mortem analysis of agent conversations, or automating skill quality based on real usage.
Generally-applicable conventions for how code is written and arranged — tooling/package manager, import style, file & component naming, comments, and where files live (colocation vs. global folders). Use whenever creating, naming, moving, or importing a file, running project commands, or deciding where a new module belongs. Consult BEFORE writing the code so the conventions are baked in, not retrofitted. If a convention below matches the work, apply it — don't ask, just follow it (call out the choice in one line so the user can override).
Build a safe local AI-agent HTTP interface for any web application. Scans the codebase, discovers all product actions, and exposes them as localhost API endpoints with a review/approval layer. Use when the user wants to expose product actions to an AI agent, create an agent API layer, build agent endpoints, add an MCP-like interface to their app, or make their app controllable by an AI agent. Works with any web framework.
Break a product or feature spec into a sequence of small, independently testable implementation steps. Use when the user has a spec document and wants to implement it incrementally rather than all at once — building and verifying one piece at a time before moving on. Triggers on requests like "break this spec into steps", "create an incremental plan", "split this into parts I can test", "how should I implement this step by step", "create a build plan", or when a user has a spec and wants a phased implementation approach.
Transform vague product or feature ideas into concrete, detailed specification documents through an interactive interview process. Use when the user wants to flesh out an idea, create a spec, write requirements, plan a product/feature/prototype, or go from "I have this idea..." to a concrete document. Works for software products, physical products, services, or any concept that needs specification.
Turn long, messy AI chat conversations into clear, durable, and easily scannable reference documents that humans can reliably return to weeks or months later.
Remove AI-generated code slop and clean up code style
Generates a rich, visual HTML one-pager describing the FINAL state of a branch or PR stack — what the code does now, how the key pieces work, and how each PR evolved (every commit beyond the initial slice and why it landed — review findings, user steering, or otherwise) — so a busy reviewer can do a confident final pass before merge. Use this after the work is done and reviewed — at a pre-merge gate in a shipping workflow once review is complete, or when the user asks to "explain the final code", "walk me through what shipped", "summarize the branch / the stack before merge", "what did the review change", or wants an overview of finished work. It leads with high-stakes surface area (service endpoints, auth, schema), walks the important functions, and traces every follow-up commit in each PR to the finding or steer that caused it. Reach for this skill whenever someone wants to understand finished, reviewed code before merging it — even if they don't say "brief" or "HTML".
Generates a rich, visual HTML one-pager that summarizes the current working-tree changes — and the proposed PR stack, if one exists — so a busy reviewer can grasp the work and approve it fast. Use this whenever someone needs an overview of in-progress changes before sign-off — at a stack-breakup or pre-approval gate in a shipping workflow, or when the user asks to "review the changes", "show me what changed", "summarize the diff / the branch", "what am I about to approve", or wants a digest of the working tree before approving. The brief leads with high-stakes changes (new service endpoints, auth/access control, database schema) and walks schema changes line by line. Reach for this skill whenever someone wants to eyeball a body of uncommitted work before approving it — even if they don't say the words "brief" or "HTML".
Guide for creating effective skills. This skill should be used when users want to create a new skill (or update an existing skill) that extends Claude's capabilities with specialized knowledge, workflows, or tool integrations.
Generates a rich, visual HTML one-pager that lets a busy reviewer understand a body of changes and either approve a proposed PR stack or merge a finished one — without reading the diff themselves. Auto-detects whether the run is DRAFT (working-tree changes plus a proposed stack, pre-approval) or FINAL (a real PR stack with review complete, pre-merge). Leads with a TL;DR, surfaces the PR stack near the top, flags high-stakes changes (endpoints, auth, schema), then walks the reviewer through the important code as a numbered Code Tour with inline diff snippets. Use whenever someone wants to eyeball a change before approving or merging — "review the changes", "show me what changed", "summarize the diff / the branch / the stack", "what am I about to approve", "walk me through what shipped", "explain the final code", or any shipping-workflow approval/merge gate — even if they don't say the words "brief" or "HTML".
Ships work end-to-end into a Graphite PR stack with review loops and a human-approved merge. Two modes — from a Linear ticket (selects or reads the named ticket, optionally plans, implements in a fresh worktree), or from changes already made locally ("ship these changes as a PR") where it skips ticket creation/selection and goes straight to PR creation. Use when the user asks to "ship", "implement", or "pick up" a ticket, or to "ship these changes / open a PR" for existing local work. Holds the human in the loop at every approval gate.
Improves how an existing skill reads and flows — tightens wording, removes redundancy, fixes structure, and resolves instructions that contradict each other across sections — so it's easy to follow for both humans and the agent executing it. Reducing length is incidental, not the aim; a skill that's long because it carries important detail can stay long. Edits the skill in place, then reports what changed and why. Use when the user asks to "clean up", "simplify", "tighten", "refactor", or "improve the flow/structure" of a skill, says it's "too long", "bloated", "cumbersome", "hard to follow", or "has conflicting instructions", or when another skill (e.g. skill-improver) flags a target for a cleanup pass. Also use when the user wants a second opinion on whether a skill reads well or is doing too much.
Expand an existing Obsidian-based learning map in any direction. User describes where to go deeper or what prerequisites to add, and the skill generates new lesson nodes, updates the canvas and index incrementally.
Interview the user to understand their learning goal and existing knowledge, then generate an interactive Obsidian-based learning map — a DAG of bite-sized lessons as markdown files linked via an Obsidian canvas.
Transform song lyrics into a structured, multi-stage representation for language learning and AI-generated music video visuals.
Transform a plain-text video lecture transcript into clean, skimmable markdown study notes. Use when the user provides a lecture transcript (or a file containing one) and wants structured notes, a summary, or a study reference from it. Triggers on requests like "make notes from this lecture", "summarize this transcript", "turn this lecture into notes", or when a transcript file is provided with a request for notes.