// Set up the project instruction file (CLAUDE.md / AGENTS.md). Use when starting work on a new project that doesn't have an instruction file yet. Explores the codebase, drafts the instruction file, and asks the user to review and refine it.
Convert a Markdown file to a styled PDF and iterate on the design visually. Use when the user asks to render markdown as a PDF, style a PDF, produce a printable handout, or tune the look of a generated PDF. Ships a neutral default theme; pairs with any styling skill that provides a CSS file.
Triage all open issues in a GitHub repository: fetch them via the gh CLI, classify each by type, priority, and quality, flag likely duplicates and stale/low-quality reports, suggest labels, and produce a prioritized triage report. Read-only by default — recommends writes (labels, comments, closes) but never applies them without explicit human approval, one batch at a time. Use this skill when the user wants to triage their GitHub issues, clean up their backlog, label untriaged issues, find duplicate issues, identify stale bugs, prioritize what to work on next, or asks things like "help me triage my issues", "what should I work on from my backlog", or "which of my open issues are duplicates".
Applies Computer Love's official brand colors and typography to any sort of artifact that may benefit from having Computer Love's look-and-feel. Use it when brand colors or style guidelines, visual formatting, or company design standards apply.
Creates or extends static HTML slide decks under presentations/ using the shared iframe shell, slides.js manifest, and per-slide HTML. Use when the user asks to make, create, build, or add presentations, slide decks, slides, or HTML decks in this repository, or when they mention PRESENTATION_GUIDE or presentations/supply-chain-security as a template.
Author a new ralph — a directory containing a RALPH.md file that defines an autonomous agent loop for the ralphify runtime. Use when the user wants to create, draft, design, or scaffold a ralph for a repeatable autonomous task (test coverage, bug hunting, migrations, research, TODO execution, docs improvement, etc.). Asks a thorough set of questions up front, explores the target project for real test/lint/type commands, drafts RALPH.md from scratch using the canonical 5-section body shape, bundles helper scripts when commands need shell features, presents the draft for review, and writes the files only after sign-off.
Drive a Claude-Code-style plan-mode interview for ambitious work and emit a set of small, self-contained plan files that a ralph (or any fresh-context agent) can execute independently. Use when the user wants to plan something too big for a single plan file — multi-subsystem refactors, migrations, new features touching unrelated areas, or any work they intend to run through the execute-plans ralph. Runs an iterative interview → explore → decompose → draft → review → write loop. Each emitted plan file follows Claude Code's plan format (Context, recommended approach, critical files, existing code to reuse, verification) — not the research-plan-implement/create-plan framework. Read-only until the user signs off, then writes numbered plan files to ./plans/ or ./plans/groups/<name>/ in the project repo.
| name | setup-instructions |
| description | Set up the project instruction file (CLAUDE.md / AGENTS.md). Use when starting work on a new project that doesn't have an instruction file yet. Explores the codebase, drafts the instruction file, and asks the user to review and refine it. |
Creates a concise, high-signal instruction file for the project.
Respond with:
I'll set up an instruction file for this project. First, let me explore the codebase to understand what's here.
Then immediately begin the workflow — do not wait for user input.
Here's my draft. Before I write it, please review:
- **Correct** any misunderstandings — wrong commands, misidentified patterns, incorrect assumptions
- **Add** anything I missed — boundaries, team conventions, things you know that aren't in the code
- **Align** the file with how your team actually works — does this match your mental model of the project?
The goal is 15–30 lines of genuinely useful context. What should I change?
.claude/, .cursor/, .github/, .codex/) to infer the tool. Use CLAUDE.md for Claude Code, AGENTS.md for everything else. Confirm with the user before writing.# [CLAUDE.md or AGENTS.md]
## Project
<!-- 1-3 sentences: What is this? What does it do? Tech stack? -->
## Commands
<!-- The commands useful for working with this codebase. Adapt to the stack — e.g. build, test, lint, run, type-check, etc. -->
## Architecture
<!-- Key directories and what they contain. Only non-obvious ones. -->
## Conventions
<!-- Only rules a linter CANNOT enforce. -->
## Boundaries
<!-- What the agent must NOT do. Be specific about why. -->
## Testing
<!-- How tests work in this project. What pattern to follow. -->