Skills and commands I use for research, coding-agent workflows, integrations, and projects that need to outlive one chat session.
llm-toolkit is my working collection of resources for coding agents. Some are small, like a command for explaining a difficult change. Others run full research, naming, buying, review, or project-memory workflows. I keep them together because they solve jobs I run into repeatedly, and because their dependencies and awkward edges are worth documenting.
The source format is Claude Code. The install prompt below adapts selected resources to whatever the user runs — Claude Code, Pi, Codex, another agent with comparable skills, prompts, hooks, and subagents, or several of these side by side. That adaptation is a port, and some Claude-specific paths or tools will need translation.
Tip
Expand the prompt, copy it into a fresh session of the coding agent you want to install into, and let that agent inspect the repository before you choose resources.
Install prompt: click to expand
Install selected resources from the llm-toolkit repository into the coding agent setup I name.
Repository: https://github.com/rolandtolnay/llm-toolkit.git
# Intent
This repository is a personal toolkit of skills, commands, subagents, and references, authored in Claude Code format. I may be installing into Claude Code, Pi, Codex, another agent, or several of these on one machine. The goal is equivalent behavior in every harness I name — understand each selected resource and adapt it to its target, rather than copying files literally.
# Success criteria
- I confirm the target harness(es), scope (project or user), resources, and install mode (copy or symlink) before files are written.
- Each installed resource is discoverable through its harness's own conventions and preserves the behavior documented in this repository.
- Every reference inside an installed resource resolves from its final location. Source files address their own scripts and reference files through `~/.agents/skills/<skill>/...` as a harness-neutral stand-in; Claude-specific paths, tool names, hook syntax, and subagent references appear throughout. Adapt all of these to what each target harness actually supports, choosing the mechanism that fits this system — a shared resolvable location, symlinks, or rewrites in installed copies — without modifying a shared source checkout.
- When several harnesses share one machine, they share one stable source rather than drifting per-harness copies, wherever the chosen mode allows.
- Cross-resource dependencies are installed with the selected resource or reported as unmet. Notable couplings: the research skill, its CLI scripts, and the `research-subagent`; the `bootstrap-goal-project` companions; GitHub/Linear dependencies in delivery workflows; the `humanizer` dependency of `create-pr`; `publish-research` needs its bundled assets and config example, and example domains or deployment targets are never copied into a live config.
- Existing unmanaged files and local modifications are preserved unless I approve a specific overwrite or removal.
- A local manifest records the source revision, selected resources, destinations per harness, install mode, and rewrites, so a later run can update or uninstall cleanly.
- The final report leads with what now works where: resources and invocation names per harness, rewrites made, runtime dependencies and expected key locations, validation performed, and anything left unmet. Never print secret values.
# Decisions
Inspect the repository and each target harness's conventions first, then ask one compact round of questions covering only what is still unknown: harness(es), scope, resources, mode. Present the repository by use case (research and buying decisions; autonomous project foundations; engineering quality and delivery; integrations; creative workflows; commands and decision frameworks; optional bundles) and recommend a small starting set for my intent rather than installing everything by default.
Use a stable checkout for symlinks, never a temporary clone. Prefer copy mode for project/team installs, resources that need path rewrites, and environments where symlinks are impractical. Install whole skill directories so bundled references, scripts, assets, and agent metadata stay together.
# Approval boundaries
A request to install authorizes cloning to a stable location, writing the selected resource files into the agreed destinations, and non-destructive validation. Show the action and get confirmation before overwriting or deleting existing files, installing system packages, writing secrets, or wiring hooks that mutate anything beyond the install itself. If a resource cannot be faithfully adapted to a harness, leave it uninstalled there and name the missing capability.
# Validation and stopping
Use the minimum checks that prove the installation works: resolve final paths, search installed files for stale checkout or wrong-harness references, verify discovery names in each harness, and run one safe `--help` or `config` command for script-backed resources when the runtime is available. Do not make paid API calls or send external messages as a test.
When enough is known, install rather than continuing to survey options. Stop when the selected resources are installed and verified in every target harness, or when a missing capability, dependency, credential, or user decision blocks safe progress.
The prompt is intentional. Claude Code, Pi, and other agents put skills, prompts, hooks, and secrets in different places. They also use different names for interactive questions and subagents. A guided install can account for those differences while still handling selection, dependencies, conflicts, path changes, and verification.
| You want to… | Start with |
|---|---|
| Research a current topic with citations | research |
| Make a grounded buying decision | product-research |
| Turn completed product research into a website | publish-research |
| Name a company, product, app, or feature | brand-naming |
| Generate and judge app icon candidates | app-icon-studio |
| Prepare a repository for independent agent runs | new-project → bootstrap-goal-project → write-loop |
| Turn a vague request into a bounded task | scope |
| Get a dense answer restated in plain language | plain |
| Verify finished code or triage review feedback | /verify or triage-pr-comments |
| Work from a Linear ticket | /work-ticket |
| See what to work on next across Linear projects | roadmap-page |
| Search Gmail or Slack from an agent | gmail, slack, or linear |
| Generate narration or add a voiceover to video | elevenlabs |
Invocation examples below use Claude Code slash syntax. A port may expose the same resource through a different explicit command.
The research skill handles quick factual lookups without spinning up a team of agents. Broader questions get split into focused angles, with each subagent assigned the sources that fit its part of the problem. Standard and deep runs are saved under ~/Documents/Research/.
A few details make it more useful than a one-shot search:
- It starts with built-in web search and reaches for paid providers only when their coverage is needed.
- It checks saved research before repeating work.
- It verifies official claims against primary sources.
- It leaves disagreements between sources visible and labels findings as verified, community-sourced, or unverified.
Example:
Research how teams are using coding-agent subagents in production. Compare official guidance with practitioner reports, flag disagreements, and save the run.
This skill is for current web information. Local codebase questions belong with the coding agent's normal file tools. Provider-backed sources can fail, hit rate limits, or cost money, and saved research will age on fast-moving topics.
Research setup, API keys, and source coverage
The Python CLIs use uv with inline dependencies; the repository does not maintain a root Python environment.
Basic lookups can use the host agent's built-in web search and fetch tools without provider keys. The bundled CLI capabilities are unlocked by these variables:
| Variable | Service | Unlocks |
|---|---|---|
PERPLEXITY_API_KEY |
Perplexity | search, ask, and reason |
CONTEXT7_API_KEY |
Context7 | Version-aware library documentation |
FIRECRAWL_API_KEY |
Firecrawl | Site mapping and full-page scraping |
SCRAPECREATORS_API_KEY |
ScrapeCreators | Primary YouTube backend, Reddit, and short-form research |
Source defaults load from the shell, then ~/.claude/research/.env, then project .claude/research.env (highest precedence). A cross-agent installation may adapt those paths.
PERPLEXITY_API_KEY=pplx-...
CONTEXT7_API_KEY=...
FIRECRAWL_API_KEY=fc-...
SCRAPECREATORS_API_KEY=...
RESEARCH_NO_PERSIST=0
RESEARCH_DIR=~/Documents/ResearchYouTube uses ScrapeCreators first when configured. Install yt-dlp for the Free Fallback Backend. Long transcript preprocessing, video selection, and Reddit condensation can use claude -p. Use both --no-preprocess and --no-select to avoid Claude CLI calls in the YouTube path; Reddit condensation must also be avoided or adapted when that CLI is unavailable.
The searchexa companion uses EXA_API_KEY from ~/.claude/research/.env. It returns page text with search results and has a documented free allowance of 1,000 searches per month; it does not synthesize or fully scrape pages.
EXA_API_KEY=...Check the installed research CLI's config command before a real run. It reports key presence and resolved paths without printing secret values.
/product-research
This is for buying one thing well, whether that is a mattress, microwave, vacuum, or another household or personal product. The workflow asks only about constraints that could change the shortlist. It then researches the category before comparing models, so the final criteria come from evidence instead of mirroring the user's first assumptions.
Owner reports, expert reviews, and retailer data are gathered separately. Product quality and current stock also stay separate: an ambiguous retailer page adds a verification warning, but it does not quietly replace the better product with whatever happens to be available.
A completed run looks like this:
~/Documents/Research/YYYY-MM-DD-<category>-product-research/
├── 00-synthesis.md
├── 01-interview.md
├── 02-masterclass.md
├── 03-availability.md
├── 04-owner-voice.md
├── 05-expert-voice.md
├── 06-retailer-voice.md
└── aspects/
Each run covers one product category. Availability research starts in Romania and the EU, and import options are flagged. Prices and stock can change after the report is written. The workflow filters out obvious affiliate noise, but it cannot remove every source bias or replace trying a product when comfort, sound, or fit matters.
Product Research setup and dependencies
Install product-research, research, and the research-subagent together.
A full run expects:
uvfor bundled Python CLIsPERPLEXITY_API_KEYfor the researchaskandreasonpathsFIRECRAWL_API_KEYfor retailer-page scrape verificationSCRAPECREATORS_API_KEYfor richer Reddit and primary YouTube coverage, oryt-dlpfor the YouTube fallback- write access to the configured research directory, defaulting to
~/Documents/Research/
Use the same env files as Research. Missing optional sources reduce coverage; missing Perplexity or Firecrawl prevents parts of the documented full pipeline and must be reported rather than hidden.
/publish-research ~/Documents/Research/YYYY-MM-DD-example-product-research
publish-research turns a completed Product Research Skill run into a static article. It keeps the short recommendation up front, folds deeper research into evidence drawers, carries every considered product into a browsable inventory, and checks the page against the source before touching deployment.
The skill comes with the article template, shared CSS, a generic navigation script, and a separate article script for sites that block inline JavaScript. The original version published to one Firebase site for one reader. This version has no built-in domain, Firebase project, personal name, or deployment command. Those values live in .publish-research.json inside the target site.
The normal flow is local first: generate the article, run factual and structural reviews, humanize the editorial copy without changing specs or prices, add verified product images or placeholders, update the manifest, and inspect desktop and mobile layouts. Deployment runs only when the site profile contains a command and you confirm that exact external write.
This is meant for the output shape produced by product-research, not arbitrary Markdown. The bundled design is opinionated, remote product images can disappear, and good visual verification still benefits from agent-browser. Local image mode is more durable but leaves image licensing and repository size with the publisher.
Publish Research setup and site customization
Install the complete publish-research directory so its assets/ and references/ come with the skill. Then copy site-config.example.json to .publish-research.json in the target site's project root. The example leaves the public URL, footer disclosure, sign-off, and deployment unset, and starts with image placeholders.
The profile asks for:
- the research directory, static output directory, manifest path, and required array manifest format
- the site's public base URL, home and article URL prefixes, title, language, locale, favicon, and shared asset URLs
- optional reader and interviewee names plus the editorial voice
- the real affiliate disclosure and footer sign-off
- image mode:
hotlink,local, orplaceholder - optional reference and mockup pages
- an optional deployment command, working directory, publish paths, and public URL
Deployment is disabled by default:
{
"deployment": {
"command": null,
"workingDirectory": ".",
"publishPaths": ["public"],
"publicUrl": null
}
}Keep it disabled until local generation works. Do not put tokens or service-account files in the profile. Provider credentials stay in the provider CLI or secret store.
Other dependencies:
- a completed Product Research Skill run with
00-synthesis.md - fresh-context subagents or reviewers for content and structure checks
- optional
agent-browserfor desktop and mobile rendering curlandfilefor remote image validation- Google Fonts access for the starter template, or a local-font customization for strict CSP/offline sites
- optional
humanizerfor the editorial pass - a deployment CLI only when the configured command uses one
The skill can copy its bundled styles.css, nav.js, and article.js into a new site. It will not overwrite an existing design system without approval. Full setup and the post-install checklist are in references/setup.md.
/brand-naming
brand-naming is for the naming job where a quick list of 50 plausible words will not cut it. It starts with strategy and category language, gives three isolated generation teams different briefs, and keeps evaluation out of the generation stage.
The raw list runs into the hundreds before it is narrowed. You react to a curated longlist, then the remaining names go through collision, trademark, domain, search, and language checks. Five to seven survivors are tested in headlines, taglines, app-store or shelf contexts, and spoken introductions. The final dossier recommends three to five.
Runs persist under ~/Documents/Research/YYYY-MM-DD-<subject>-naming/, including the strategy, landscape, generation funnels, screening evidence, proof of concept, and final recommendation.
It is a long workflow with several user checkpoints, so it is overkill for a casual brainstorm. Its trademark and domain checks are screening, not legal clearance. A shortlisted name still needs qualified trademark review.
Brand Naming setup and dependencies
Install brand-naming, research, and the research-subagent together. The full workflow uses the shared research CLI for landscape and screening, so configure uv and PERPLEXITY_API_KEY. SCRAPECREATORS_API_KEY improves access to customer language from Reddit and video sources.
The agent host must support isolated subagents or an equivalent fresh-context mechanism. Without isolation, the three generation teams lose the deliberate diversity the pipeline relies on.
Pick the version based on who should run image generation: the skill itself, or you in the Gemini web app.
/app-icon-studio
app-icon-studio starts by asking what the icon should communicate in half a second. It then proposes four genuinely different directions and generates each one through OpenAI and Gemini. Independent craft and brand judges review the candidates at 48px before one focused revision turn produces a contact sheet with 5-7 finalists.
A normal run produces about 16 first-round images and saves every prompt and output under ./icons/<app-slug>/. Failed API calls stay in the funnel count. You approve the four design directions before the skill spends money.
A full run costs roughly $2-4 in image API fees and takes several minutes. The finalists are raster candidates, so production may still need a high-resolution rerender or vector redraw. The documented thumbnail and contact-sheet steps use the macOS tools sips and open; other operating systems need replacements or a manual step.
App Icon Studio setup and API keys
Requirements for the documented dual-engine workflow:
- Node.js 18 or newer
OPENAI_API_KEYGEMINI_API_KEY- an agent host capable of independent image-judging subagents
- optional macOS
sipsandopensupport for the documented presentation path
The dependency-free Node scripts load dedicated env files; the project file overrides the user file:
# ~/.claude/app-icon-studio/.env
# or ./.claude/app-icon-studio.env
OPENAI_API_KEY=...
GEMINI_API_KEY=...Run each installed script's config command before generation. The scripts report whether keys are present without printing them. If one key is unavailable, the skill supports a reduced single-engine run with doubled candidate counts; disclose the lost cross-engine comparison before proceeding.
/nano-banana-app-icon
nano-banana-app-icon runs the discovery and critique loop but leaves generation in gemini.google.com. It writes a JSON prompt, waits for you to return a PNG, scores the image against an eight-part rubric, and emits one-change refinement prompts until the 48×48 gate passes.
Use it when you want the same design discipline without API setup or automated batch generation. The tradeoff is manual work: you need Gemini web access, must paste each prompt and download each PNG, and should start a fresh Gemini chat after three failed refinements.
/new-project
/bootstrap-goal-project
/write-loop
These three skills are for projects that will span independent agent runs. They keep product judgment and project language in the repository, alongside the decisions, execution rules, and run history a new session would otherwise have to reconstruct from chat.
new-project interviews for information future runs cannot derive: core value, intended users, non-goals, constraints, and tradeoff preferences. It writes a compact PROJECT.md, then dry-runs that document against plausible product forks to check whether a cold agent would decide as you would.
The documented workflow initializes Git when needed and commits PROJECT.md. If that is not desired, tell the agent before invocation or adapt the installed skill's commit boundary.
bootstrap-goal-project creates or repairs the broader project-local system: PROJECT.md, CONTEXT.md, AGENTS.md, decision records, goal history, retained evidence, a stack-specific playbook, and fresh-context judging rules. It adapts templates to the actual repository instead of copying the web assumptions from hobby-bundle/.
write-loop turns a rough greenfield or brownfield idea into a short, gradeable /goal. It asks only for outcome, success, guardrails, regression boundaries, and other information the run cannot safely infer, then saves the prompt under etc/loop/.
The three fit together like this:
PROJECT.md and domain decisions
→ repository-specific playbook
→ short outcome-focused goal
→ implementation and evidence
→ fresh-context judgment
→ GOAL MET or an explicit blocker
Skip the full foundation for disposable experiments and small scripts. The extra documentation earns its keep only when work spans sessions or unattended runs. Bootstrap preserves existing artifacts and does not commit unless requested. new-project has the separate commit behavior noted above.
Goal-driven project setup
No API key or third-party runtime is required for the three core skills. Install them together when you want the complete flow:
new-projectbootstrap-goal-projectwrite-loop
The bootstrap skill includes project-foundation templates in its own assets/ directory. Install the complete directory so those assets come with SKILL.md.
The optional hobby-bundle/ is a worked Next.js/Firebase/Vercel example. Treat it as source material or install only the bundled skills that match the target project; do not import its stack assumptions as general rules.
elevenlabs generates narration through the official ElevenLabs CLI and uses FFmpeg for requested video voiceovers. Scripts are prepared for Eleven v4 with spoken-form text, audio tags and IPA pronunciation hints. Personal voice/model defaults live in ~/.config/elevenlabs/defaults.json; uv loads the owner-only credentials.env in that directory without putting the key in commands or repository files. Requires elevenlabs and uv, plus FFmpeg/ffprobe for media assembly. Setup covers permissions, account checks and installation.
Setup and metadata checks do not generate audio. Requested synthesis consumes allowance; community Voice Library voices require a paid plan for API use, and Free-generated output is noncommercial. The skill preserves source videos and distinguishes file validation from listening verification.
linear creates, updates, queries, relates, comments on, and organizes Linear issues, projects, cycles, milestones, labels, documents, attachments, and custom views. Single-team workspaces can often resolve the team automatically; multi-team setups can use a flag, environment variable, or .linear.json.
Direct update commands run immediately. Ticket creation asks for the smallest missing details first, but there is no universal confirmation gate. Delete and state-change commands mutate Linear as soon as they run.
Linear setup
Requirements: uv, a Linear personal API key, and network access to Linear's GraphQL API.
Claude Code source configuration in .claude/settings.local.json:
{
"env": {
"LINEAR_API_KEY": "lin_api_..."
}
}Optional project defaults in .linear.json:
{
"teamId": "team-uuid",
"projectId": "default-project-uuid",
"defaultPriority": 3,
"defaultLabels": ["mobile"]
}You can also set LINEAR_TEAM to a team key or UUID. The installing agent should adapt the secret location for non-Claude hosts while preserving the CLI's environment contract.
roadmap-page turns the tickets of one or more Linear projects into an HTML roadmap page: release phases, an in-progress strip, three next-up cards, areas of work, and a drawer per ticket with blockers and a copyable session prompt. A switch in the header and in each session box spells the session prompts for Claude Code, Pi or Codex. The skill asks three questions (projects and focus, goal and date, owner label), then writes humanized guidance for every ticket and recommends a session for each: /scope for bounded work, /prep then /cook-prd for anything substantial, and a guided walk-through for setup and decisions with no code output.
The page holds the curated config and guidance and is committed; the Linear facts live in a git-ignored <page>.snapshot.js beside it, so a colleague rebuilds them with one refresh. A dependency-free Node server shipped with the skill refreshes that snapshot through the linear CLI, serves the page on localhost, and offers a Self-heal button that runs headless Claude Code (claude -p, Opus, medium effort) under a fixed contract to integrate new tickets, reconcile unexpected states, re-check changed guidance, or apply a typed instruction. Each run is backed up, validated, and revertible from the page. It adds a just roadmap recipe to the project. Requires uv, Node 22+, just, the linear skill with its API key, and claude on PATH for self-heal.
slack searches messages, reads channel history and threads, sends or schedules messages, edits posts, adds reactions, and manages status using a Slack User OAuth Token. Messages appear as the user, not a bot.
Read-only operations run immediately. Sends, DMs, replies, and schedules are drafted and shown for confirmation before posting. Edit, delete, reaction, and status commands currently mutate Slack immediately; deletion is destructive.
Slack app, scopes, and token setup
Requirements: uv and a Slack app installed to your workspace with these User Token Scopes:
chat:write, search:read, channels:history, channels:read, users:read, users.profile:write, groups:history, groups:read, reactions:write, im:history.
Create an app at api.slack.com/apps, install it to the workspace, then store the xoxp-... User OAuth Token in .claude/settings.local.json:
{
"env": {
"SLACK_USER_TOKEN": "xoxp-..."
}
}A cross-agent installation may use another secret store, but the CLI still needs SLACK_USER_TOKEN in its process environment. Workspace permissions and Slack rate limits remain in force.
gmail gives an agent a narrow, read-only Gmail retrieval surface. It searches metadata and bounded snippets first, then fetches only selected messages or threads. Message content is not cached or logged, and attachments remain metadata-only.
The Gmail integration is read-only. It cannot send, reply, delete, archive, change labels or read state, or download attachments. It also rejects broad mailbox dumps.
Gmail setup and privacy boundaries
Requirements: uv, Gmail IMAP access, GMAIL_USER, and a Google app password in GMAIL_APP_PASSWORD.
Supported source paths include:
# Project: .claude/gmail.env
# User: ~/.claude/gmail/.env
GMAIL_USER=you@example.com
GMAIL_APP_PASSWORD=...The CLI can also read supported agent env.json locations or process environment variables. Run its config command to inspect credential sources, then doctor to test read-only IMAP connectivity without returning email content.
scope: Turns an underspecified fresh-session request into a confirmed task frame covering the goal, bounds, verification, and out-of-scope work. It first checks what the repository can answer, asks only material unknowns in one round, and implements only after approval. The skill is explicit-only and needs an interactive question-tool equivalent.triage-pr-comments: Fetches unresolved GitHub review comments, checks each against actual code usage, domain docs, and linked tickets, then classifies it as act, defer, ignore, or investigate. It confirms decisions before replying, resolving, or creating follow-up work.pr-qa-browser: Derives 5-8 risk-focused browser stories from a PR, runs feasible Agent Browser flows, and stores screenshots underetc/mine/test-<branch>/.- This one is written specifically for
dashboard-web, itsAGENTS.md, local server, auth state, and fixtures. It needs adaptation before it can serve as generic browser QA.
- This one is written specifically for
audit-prompt: Audits changed prompt-bearing Markdown and YAML for token waste, positioning, specificity, and structural problems./verify: Reconstructs intent, analyzes correctness and blast radius, runs tests, then resolves findings interactively before declaring issues.ripple-check: Looks for other code locations where a lesson from the latest fix genuinely transfers; "checked, does not apply" is an acceptable result. Explicit-only.boy-scout: Re-reads the flow the session just built or fixed for cheap fixes, missed edge cases, and behavior that would surprise a user or developer. It reports numbered findings with evidence and regression risk, then waits for you to pick; "nothing worth changing" is an acceptable result. Explicit-only.
create-pr: Builds a reviewer-oriented PR description from the diff, conversation, tickets, PRDs, and domain docs; confirms branch/commit/push actions and the final body; returns a reusable Slack or release-note summary./tidy-commits: Proposes squash and reorder groups for unpushed commits, confirms them, then compares the changed-file and line-count statistics with the pre-rebase baseline. That check is not content equivalence; inspect the final diff when the rewrite is sensitive./finalize-ticket: Commits, comments on a Linear issue, attaches the commit, and moves the ticket to Done./work-ticket: Runs diagnosis, design, implementation, and verification around a Linear ticket, with engineering checkpoints between phases. Before diagnosis, it moves the issue to In Progress and may create or check out a ticket branch.
GitHub, browser, and delivery dependencies
create-pr,triage-pr-comments, and PR-aware commands require authenticatedgh.create-pralso references thehumanizerskill fromhobby-bundle/humanizer. Install it and adapt the reference path withcreate-pr.triage-pr-commentsrequireslinearand credentials when the PR references tickets or a decision is deferred;create-prhas the same requirement when a ticket ID appears in its context./work-ticketand/finalize-ticketrequire thelinearskill and its credentials./finalize-ticketinvokes an external/commit-commands:commitresource that is not included in this repository. The installing agent must map it to an available commit workflow or report it as unmet.pr-qa-browserrequiresagent-browser, authenticatedgh, a runningdashboard-web, appropriate auth/fixtures, and project-specific testing instructions.- History rewriting in
/tidy-commitsis destructive to commit identities. The command requires confirmation and is intended for unshared commits.
The repository currently has 27 top-level skills. Use this collapsed list when you know the name and want the source file.
Show all 27 skills
create-engineering-skill: Turns an engineering failure mode, practice, or workflow into a vocabulary-dense skill with canonical grounding and falsifiable judgment rules.readme-best-practices: Supplies supporting guidance for scannable developer READMEs. It is not user-invocable by design.audit-prompt: Reviews prompt-bearing changes against prompt-quality principles.
research: Runs current web research with verification and optional persistence.product-research: Produces a category masterclass and ranked buying recommendations.publish-research: Turns completed product research into a reviewed static article and optionally deploys it from an explicit site profile.brand-naming: Produces screened brand-name finalists through research and isolated generation.searchexa: Returns semantic search results with inline page text through EXA.gmail: Retrieves narrow, read-only Gmail evidence.plain: Rephrases a dense explanation in plain language while preserving every decision-relevant fact. Explicit-only.
scope: Frames vague requests around an outcome, bounds, verification, and explicit exclusions before implementation.new-project: Captures product intent and default judgments inPROJECT.md.bootstrap-goal-project: Creates or repairs the repository's durable autonomous-run foundation.write-loop: Writes short, gradeable/goalprompts.create-pr: Opens a PR with grounded motivation and verification notes.triage-pr-comments: Separates valid review work from deferrals and false positives.boy-scout: Finds cheap, worthwhile fixes in the flow just built before the work concludes. Explicit-only.ripple-check: Carries a lesson from the latest fix to other code that shares its assumption. Explicit-only.pr-qa-browser: Runs dashboard-web-specific browser QA.
linear: Manages Linear work through a conversational CLI.slack: Reads and writes Slack through a user token; sends and schedules confirm first, while edit/delete/react/status paths are immediate.firebase-hosting-basics: Guides Firebase Hosting Classic configuration, emulation, previews, and deployment for static sites, SPAs, and simple microservices.- It does not cover Firebase App Hosting, SSR, or ISR. It requires Node/npm,
firebase.json, Firebase authentication and project access, andnpx firebase-tools@latest. A live deploy changes an external service.
- It does not cover Firebase App Hosting, SSR, or ISR. It requires Node/npm,
firebase-admin: Inspects and repairs Firestore data, Auth users, and Storage objects through a JSON CLI that reuses the existing Firebase CLI login, plus an escape hatch for Admin SDK JavaScript.- Requires Node 22+ and a one-time
npm ci && npm run buildin the skill directory. Writes run with the selected identity's real IAM permissions and bypass security rules; there is no sandbox, dry run, or rollback.
- Requires Node 22+ and a one-time
elevenlabs: Generates speech or adds narration to a video through the official CLI, with private local credentials and reusable voice defaults.app-icon-studio: Generates, judges, revises, and presents app icon candidates through OpenAI and Gemini APIs.nano-banana-app-icon: Writes and critiques app-icon prompts for a manual Gemini workflow.
The repository contains 21 Claude-style command prompts. Another host may install them as prompt templates or agent-specific commands.
/work-ticket ABC-123
Runs the full Linear-ticket workflow: orient, diagnose, choose a design, implement, and verify.
/verify [commit range, plan path, or scope]
Provides an interactive second opinion on completed work.
/tidy-commits
Cleans up unpushed history after showing and confirming the proposed rebase.
/finalize-ticket ABC-123
Commits the solution, updates Linear, attaches the commit, and marks the issue Done.
/explain [topic]
Investigates and explains the issue, decision, severity, or architectural fit at the level needed to act.
/handoff
Writes handoff.md so a fresh session can continue with the original task, completed work, remaining work, failed approaches, and current state.
/reflect [timeframe]
Extracts durable principles from recent commits and Claude Code conversation history, then writes approved findings to memory or project instructions. Its history lookup is Claude Code-specific and needs adaptation on other hosts.
/generate-readme [project path]
Explores a project, asks for missing audience or positioning decisions, and writes a storefront-style README.
/analyze-problem [situation]
Recommends the most relevant framework and whether external research would change the decision.
Twelve focused framework commands are available under commands/consider/:
/consider:first-principles/consider:5-whys/consider:inversion/consider:second-order/consider:pareto/consider:eisenhower-matrix/consider:10-10-10/consider:swot/consider:occams-razor/consider:one-thing/consider:opportunity-cost/consider:via-negativa
hobby-bundle/ is the original goal-driven web-project example. Its reusable worked artifacts include an agent-instructions template, the stack-specific playbook, a judged goal loop, and a goal-writing guide. It also contains 10 optional bundled skills:
agent-browserdeploy-to-verceldiagnosegrill-with-docshumanizerimprove-codebase-architecturereact-view-transitionsvercel-composition-patternsvercel-react-best-practicesweb-design-guidelines
Use bootstrap-goal-project to extract the general contracts for another stack. Install individual hobby skills only when their assumptions match the target project.
business-bundle/ contains 12 offer and business-strategy lenses:
market-researchbusiness-modelproductizedfy-dwy-diyhormozi-offeraudit-offerpricing-strategylanding-page-copyoffer-anglesobjection-destroyervalue-perceptionvalue-accelerator
These are strategy lenses, not market evidence. Check pricing, demand, competitors, and channels against current research.
skills/ 27 primary skills, with bundled references, scripts, assets, and agent metadata
commands/ 21 Claude-style command prompts, including 12 decision frameworks
agents/ the research-subagent definition used by research workflows
hobby-bundle/ goal-driven web-project example and optional web skills
business-bundle/ curated offer and business-strategy skills
docs/guides/ prompt, skill, agent, goal-loop, README, and web research guides
docs/pi/ Pi migration and feature notes; some runtime validation remains incomplete
site/ a small GitHub Pages/Jekyll reference site
- Frontier LLM Prompting Guide: outcome-first prompting, approval boundaries, stop rules, grounding, validation, and legacy-prompt audit criteria.
- GPT-6 Prompting Guide: GPT-6 Astra behavior and prompting patterns for grounding custom skills and instructions.
- GPT-5.6 Prompting Guide: consolidated GPT-5.5/5.6 prompting guidelines.
- Fable 5 Prompting Guide
- Opus 5.5 Prompting Guide
- Prompt Quality Guide
- Skill Prompting Principles
- Subagent Prompting Guide
- Building a Good Vertical Agent
- Finding Your Unknowns
- Building Skills Guide
- Skill Description Guide
- Skill Discovery Pattern
- Goal Loss Functions
- Loop Guide
- Writing Effective CLAUDE.md
- README Guide
- Nano Banana 2 Prompting Guide
- ElevenLabs Prompting Best Practices: official delivery, pronunciation and text-normalization guidance for Eleven v4 text-to-speech.
- The Unreasonable Effectiveness of HTML
- Website Scrape Consolidation Principles
Additional official references, Pi notes, prompt snapshots, browser recording notes, and the YouTube upload-date ADR live under docs/.
- Claude Code is the source format. Many skills refer to
~/.claude,.claude/settings.local.json, Claude hooks, slash commands,Task, orAskUserQuestion. The install prompt asks the target agent to translate them, but some hosts will not have an equivalent. - Pi support is not fully validated.
docs/pi/contains migration notes, andpackage.jsoncontains Pi package metadata, but the declared rootprompts/directory does not exist yet. Treat Pi installation as a guided port, not a verified package install. - Installation is prompt-driven; there is no installer script. Source files reference their own scripts through the harness-neutral
~/.agents/skills/<skill>/...convention, and the installing agent decides per system how to satisfy it — a resolvable shared location, symlinks, or rewritten paths in installed copies. - Confirmation rules vary by resource. Slack sends and schedules, PR-comment triage, and
publish-researchdeployment confirm before writing. Slack edit, delete, react, and status commands run immediately, as do some Linear mutations and Firebase deployment instructions. - Research, image generation, Gmail, Linear, Slack, and EXA rely on credentials or external services. If an optional provider is missing, the skill should report reduced coverage instead of filling the gap with invented results.
- Most Python CLIs use
uv. Some research paths also useyt-dlporclaude -p. App Icon Studio needs Node 18 or newer and uses macOS utilities for presentation. Browser QA needsagent-browserand suitable project fixtures.
For symlink installs, pull from the stable checkout recorded in the installation manifest. Copied resources do not update automatically.
Run the installation prompt again and ask the agent to compare the recorded source revision and checksums with the installed files, preserve local edits, refresh the selected resources, update the manifest, and re-run path and dependency checks.