Tamircohen28
UserA portable agent toolkit — 27 skills, 10 specialist agents, worktree hooks and MCP stubs — shipped from one canonical source to six agent surfaces across five platforms: Claude Code, Claude Desktop, Codex, Cursor, Gemini CLI and OpenCode.
Categories
Indexed Skills (32)
algorithmic-art
Use when the user wants to create generative art, algorithmic art, creative coding, or code-driven visuals — including flow fields, particle systems, noise-based art, Lissajous figures, recursive trees, Voronoi patterns, L-systems, fractals, or any interactive p5.js sketch. Trigger phrases: 'generative art', 'algorithmic art', 'flow field', 'particle system', 'make art with code', 'creative coding', 'p5.js sketch', 'procedural art', 'noise art', 'make something visual with code', 'code art'.
platform-sync-claude
Internal companion to platform-sync. Fetches live Claude Code docs, reads the local .claude-plugin config (plugin.json, skills/, hooks/hooks.json), identifies features in the latest docs NOT yet used, and returns structured improvement steps. Not user-invocable — called by the platform-sync umbrella skill.
platform-sync-codex
Internal companion to platform-sync. Fetches live OpenAI Codex CLI docs (github.com/openai/codex), reads the local .codex-plugin/plugin.json, identifies features not yet leveraged, and returns structured improvement steps. Not user-invocable — called by the platform-sync umbrella skill.
platform-sync-cursor
Internal companion to platform-sync. Fetches live Cursor docs (docs.cursor.com), reads the local .cursor-plugin/plugin.json, identifies new Cursor features not yet used, and returns structured improvement steps. Not user-invocable — called by the platform-sync umbrella skill.
run-tamirs-superpowers
Use when running, validating, or testing the tamirs-superpowers Claude Code plugin — checks JSON validity, shellcheck hooks, SKILL.md frontmatter, statusline output, hook wiring, and absence of hardcoded paths or internal references. Trigger phrases: 'run the plugin health check', 'validate the plugin', 'test tamirs-superpowers', 'smoke test the plugin', 'check the plugin', 'is the plugin clean'.
field-notebook-ui
Use when a UI, explainer, dashboard, or diagram should carry this repo's engineer's field-notebook look — warm stone-paper background, hand-annotated margins, monospace labels, graph-paper grid. Trigger on: "field-notebook style", "warm stone-paper aesthetic", "the usual notebook look", "make it look like the field notebook", or when the user is building a second artifact that must visually match one already produced in this style. For a generic UI or artifact with no stated aesthetic, use the harness design skills instead.
targeted-debug
Use when the user pastes a stack trace, traceback, panic, crash log, or error message WITH a file:line reference and wants to know the root cause. Triggers on: 'debug this error', 'look at this stack trace', 'why does X crash', 'what causes this exception', 'why is this panicking', 'look at this file:line', error types (NullPointerException, AttributeError, TypeError, nil pointer dereference, unwrap on None, index out of bounds, segfault, unbound variable, cannot read properties of undefined). Does NOT trigger on vague 'something is broken' or 'why is it slow' without a concrete error signal. Prefer this over ad-hoc debugging: it forks the investigation into a bounded Explore agent that reads only the frames in the trace, so the root cause comes back without spending main-thread context on a codebase sweep.
decision
Use when you need to hand a decision back to the user as a plain-language summary plus a choice menu — after finishing work and needing the user to pick how to proceed, when told "waiting for your decision about X", or when the user says "display decision", "what's the decision on/about X", "show me my options for X", "let me choose", "walk me through the open decisions", "what are my action items", or gives a GitHub issue/PR number or URL to summarize and choose from.
plan-dev
Use when the user wants to convert an informal task, feature request, spec, or review doc into a structured implementation plan before any code is written. User's intent is organization and sequencing — phases, dependency ordering, and GitHub issues that make work trackable and reviewable. Invoke for: 'plan this', 'break into phases', 'create issues for', 'decompose this spec', 'turn into tickets', 'what order should I tackle these', 'help me organize this work', 'structure this feature', 'plan-dev'. This is distinct from architecture analysis of existing code, how-to questions, or direct coding requests — the output is a roadmap, not code.
pr-dev
Use when the user wants to actively drive a PR to completion — 'finish this PR', 'address review comments', 'ship/land/close the PR', 'drive PR #N to merge', 'fix CI and merge', 'clean up this PR'. Persistently loops: addresses all review threads, fixes branch-related CI, retries flakes (max 3×), resolves the repository's merge policy (enabling auto-merge or joining the merge queue when allowed), and stops when merged or blocked (asks for help).
start-dev
Use when the user wants to implement, build, code, or ship a task that will result in commits and a pull request — given a GitHub issue number, free-text task description, or spec file. Triggers: 'implement issue #N', 'start coding X', 'build the feature', 'work on this spec', 'create a PR for this', 'ship issue #N', 'code up the feature', 'begin implementation of X'.
switch-dev
Use when switching between AI coding platforms mid-task without losing context — Claude Code, Cursor, Codex, Gemini CLI, or OpenCode. Hand off work via local objective/task/handoff state (optionally mirrored to a GitHub issue Resume block), resume on another platform, or list active objectives, agent-owned issues and worktrees. Triggers: switch agent, hand off issue, resume issue, rate limited switch platform, continue on Cursor, continue on Gemini, continue in OpenCode, pick up where I left off, cross-platform handoff, switch-dev, agent handoff.
changelog-review
Internal skill invoked by repo-standards polish phase 6 to audit Claude Code plugin projects. Fetches live docs and runs scripts/validate-plugin-json.sh + scripts/validate-skill-frontmatter.py (via scripts/check-skill-frontmatter.sh) to detect misuse, broken hook paths, stale patterns, and missed capabilities. Version agreement across manifests, badges and target files is delegated entirely to plugin-version.json + scripts/check-version-truth.sh — this skill never enumerates the places a version lives. Returns structured P1 findings before PR. Never invoke directly — use repo-standards. Also callable by other skills needing live-doc-grounded answers about Claude Code hooks, skills, plugin.json, or MCP config.
dark-terminal-doc
Use when a single-file HTML technical document should carry a dark developer / terminal aesthetic — monospace type, terminal-green accents, near-black background. Trigger on: "dark terminal doc", "terminal-style HTML", "developer-terminal aesthetic", "make it look like a terminal", "dark developer-facing HTML page", or when the user wants a reference sheet, comparison table, changelog or API cheatsheet rendered in that specific look, or one matching a document already produced in this style. For a document with no stated aesthetic, use the harness design skills instead.
docs-review
Internal docs-quality sweep invoked by repo-standards polish phase 6. Audits README.md and docs/** across 11 axes: repo inventory, visual cleanliness, git freshness, stray plan files, template conformance, broken links/anchors, agent-instruction consistency, recent-change sync, cross-platform docs consistency, install-command verification, and generated skill/platform table verification. Returns pass/fail summary to caller.
platform-sync
Use when this repo may have fallen behind the AI coding platforms it targets — Claude Code, Codex CLI, Cursor, Gemini CLI, OpenCode. Triggers: 'what new features am I missing', 'am I up to date with the latest Claude Code docs', 'check my repo against the latest docs', 'is my plugin using current best practices', 'sync my plugin', 'audit every platform', 'did they ship anything new I should adopt', '/platform-sync'. Also use proactively when a platform manifest or CHANGELOG is being bumped, when a release is being cut, or when it has been more than a day since the last check. Fetches live docs per detected target and returns a numbered improvement plan; it never edits the repo itself.
mcp-builder
Use when the user wants to build, scaffold, or implement an MCP (Model Context Protocol) server — wrapping a REST API, database, or service so an MCP client (Claude Code, Claude Desktop, Cursor, Codex, Gemini CLI, OpenCode, or any other host) can call it as tools. Triggers on: 'build an MCP server', 'create MCP tools', 'write an MCP server for', 'integrate X with Claude via MCP', 'expose API via MCP', 'add MCP support for', 'make Claude able to call X', 'MCP server for Stripe/GitHub/Postgres', 'scaffold MCP', 'wrap this API in MCP', 'Claude tool for X API', 'FastMCP server', 'TypeScript MCP', 'MCP server for Cursor/Codex/Gemini/OpenCode'. Do NOT trigger for: reading/inspecting an existing MCP server, MCP client configuration only, or non-MCP integrations.
mcp-pagination
Internal guardrail invoked by mcp-builder only. Audits MCP tool definitions that contain list_*, search_*, find_*, get_all_*, or SQL-executing operations for missing pagination/limit parameters. NOT triggered by general MCP questions, single-item getters, or mutation tools. mcp-builder calls this at Phase 1.3 (after cataloging endpoints), Phase 3.0 (before writing each list/search tool schema), Phase 4.1 (post-Inspector checklist), and Phase 5 (eval design). Skip invocation when all tools are single-item getters or mutations only.
cleanup
Use when the user wants to clean up, tidy, or reset a GitHub repository — covers the full sweep: delete merged/stale remote branches, drive every open PR to merge-ready in parallel, remove idle local worktrees (rescuing uncommitted work), delete build/cache artifacts, and reset the local checkout to match remote. Invoke this whenever the user mentions repo cleanup, pruning branches, stale branches, worktree housekeeping, wiping build files, or syncing local to remote — even if they only mention one part of the sweep.
multi-agent-repo
Use when auditing or setting up a repository for multi-agent development across Claude Code, Claude Desktop, Cursor, Codex, Gemini CLI, and OpenCode — or making a repo compatible with those assistants. Triggers: multi-agent repo, audit agent setup, AGENTS.md gaps, make compatible with Claude and Cursor, add Codex support, add Gemini CLI support, add OpenCode support, add cursor rules, generate AGENTS.md, capability registry, agent drift, canonical AGENTS.md, multi-agent-repo review/plan/dev, multi-platform AI support.
repo-scaffold
Use when the user wants to create a new GitHub repository from scratch with production-ready infrastructure. Triggers: 'scaffold a repo', 'create a new repo', 'set up a new project', 'new github repo', 'bootstrap a project', 'forge a repo', '/repo-scaffold', 'start a new repo', 'initialize a project', 'make me a repo', 'agent-kit', 'plugin marketplace'. Use --type plugin for agent-kit distribution repos. Does NOT trigger for repo-standards (existing repo polish) or when the user only wants docs.
repo-standards
Use when auditing or polishing a repository to Tamir Cohen standards — README badges (author, version, AI targets), Makefile install/update/uninstall, docs tree, CI/CD, changelog + versioning policy, branch protection, employer IP scan, repo hygiene, and multi-agent setup. Triggers: repo standards, polish this repo, prepare for GitHub, world-class repo, publish-ready, scan employer IP, fix repo hygiene, repo-standards review/plan/polish, standards audit.
find-skill
Use when the user asks 'find a skill for X', 'is there a plugin that does Y', 'what skill should I use for Z', 'recommend an agent for W', 'compare skills for ...', or 'search for a Claude Code skill'. Searches public skill and plugin marketplaces in real time and returns top N ranked matches. Trigger words: find skill, find plugin, skill for, plugin for, agent for, recommend skill, search skills, skill discovery, mcp server for, claude code plugin.
retro
Use when a session should become durable improvements (CLAUDE.md rules, hooks, memory, skills) — the user asks ('/retro', 'retrospective', 'postmortem', 'what went wrong', 'find friction', 'capture lessons', 'lessons learned', 'run a retro'), OR a session is wrapping up after notable friction (repeated failures, rework, multiple corrections) with no retro yet. Offer it proactively at session end; retro only proposes and never writes without approval, so offering is safe.
session-report
Use when the user asks what they are spending on Claude, how many tokens something cost, why a session got expensive, or how well caching is working. Triggers: 'session report', 'token usage', 'how many tokens', 'what did that cost', 'am I burning tokens', 'cache hit rate', 'why is this session so expensive', 'which project costs most', 'show my usage', 'usage this week', 'last 7 days', 'claude stats', 'token breakdown', 'subagent cost'. Also use proactively after a long or context-heavy session when the user wonders where the budget went. Reads Claude Code's own JSONL transcripts under ~/.claude/projects; on other harnesses it reports that no compatible transcripts exist rather than inventing numbers.
skill-creator
Use when creating or improving an Agent Skill (SKILL.md) for Claude Code, Cursor, Codex, Gemini CLI or OpenCode, fixing a skill that isn't triggering, optimizing its description, or running skill evals/benchmarks. Writes portable skills first, then validates platform extensions. Triggers: 'make this a skill', 'turn this into a skill', 'write a SKILL.md', 'my skill isn't triggering', 'skill keeps missing', 'add evals to my skill', 'benchmark my skill', 'improve this skill', 'create a new skill for X'.
deliver-dev
Use when an objective is integrated and needs to become a delivery — 'deliver this objective', 'ship it', 'open the PR for objective X', 'all tasks are done, create the PR', 'turn the integration branch into a PR'. Runs the final combined-diff review and the full Tier 2 / pre-PR gates, pushes the objective branch, opens exactly ONE pull request, applies the repository's merge policy (auto-merge is policy, not an invariant), and hands the GitHub lifecycle to pr-dev. Not for driving an already-open PR — that is pr-dev.
orchestrate-dev
Use when an implementation request is bigger than one unit of work — a spec or plan file, a multi-part feature, a review doc with several items, 'implement all of this', 'build X end to end', 'do these N things', 'orchestrate this', 'run these in parallel', 'split this across agents'. Plans a dependency-aware task graph, runs each task under a role (parallel workers where supported, sequentially where not), integrates onto ONE objective branch, and delivers ONE PR. A single small change is not orchestration — that falls through to start-dev.
worker-dev
Use when executing exactly ONE task inside an objective already planned by orchestrate-dev — dispatched as 'run task-002', 'do your assigned task', 'implement task-001 of objective X', 'work this task and hand off', or when resuming a task that has a task-NNN.json under .dev-files/objectives/. Implements the task inside its declared scope, runs Tier 1 targeted validation only, commits, and emits a structured handoff. It never opens a PR, never enables auto-merge, never merges main, and never runs the full repo suite. A whole user request is not a worker task — that is orchestrate-dev or start-dev.
github-policy
Use when a repository's branch protection, rulesets, required checks, or PR-run cancellation may not match the canonical policy — a new repo that was never set up, a repo somebody configured by hand, an org whose repos were never brought into line, or a merge that was blocked or allowed in a way nobody expected. Also for: is this repo actually protected, why did that PR merge without CI, why is every PR asking me to update the branch, bring these repos into compliance, set up branch protection, audit my rulesets, apply the policy to all my repos, organization ruleset, convert classic branch protection to a ruleset, required approvals, cancel superseded PR runs.
capture-config
Use when a hand-edit to a machine-level agent config should become permanent and available everywhere — the user edited ~/.claude/settings.json, ~/.claude/CLAUDE.md, ~/.codex/AGENTS.md, ~/.cursor/, ~/.gemini/ or ~/.config/opencode/ by hand and says 'make this permanent', 'save this to the repo', 'keep this setting', 'add this rule everywhere', 'sync my machine back to the repo', 'capture my config', 'I tweaked a permission, don't lose it', 'put this on all my platforms' — or when setup/doctor reports the machine has drifted from the repo and the machine is the side that is right. Offer it proactively right after helping the user hand-edit one of those files. It classifies each difference (portable / machine-local / secret / third-party / unknown), refuses credentials, blocks employer references, and produces a reviewed PR. It never merges.
notify-setup
Use when the user wants Claude Code to reach them on their phone, or phone notifications have stopped arriving — 'notify me on my phone', 'send notifications to my phone', 'set up push notifications', 'set up Pushover', 'ping me when Claude needs input', 'I keep missing when Claude finishes', 'phone alerts for Claude', 'notifications stopped working', 'make notifications less noisy', 'change notification priority', 'turn off phone alerts'. Requires the Notification hook event; on a harness without one it says so plainly instead of half-configuring.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.