YosefHayim
UserTypeScript CLI for installing agent skills, hooks, and CI/publish templates for Claude Code and related tools.
Categories
Indexed Skills (40)
agent-session-auditor
Use when the user asks to scan local Claude Code, Codex, Kiro, Kimi, Cursor, Grok, OpenCode, or other agent sessions for repeated prompts, fuzzy-similar requests, workflow patterns, or skill opportunities.
capture-workflow
Use when the user says to reuse what we just did, make a completed workflow repeatable, save the process for next time, automate the successful steps, or turn recent work into a skill, script, template, test, or runbook.
deploy-and-prove
Use when the user asks to deploy, redeploy/redploy, publish a worker/site/service, multi-site or multi-domain deploy, cf:deploy / wrangler deploy, or prove production/live (curl smoke, webhook, e2e production ready, "is it live"). Especially when success must be proven from the production provider and real runtime rather than local state. Do not use for "do not deploy / run local only", or for "promote" meaning lift types/schemas into a shared package.
env-config-contract
Use when the user asks to consolidate, type, validate, migrate, or debug environment variables and configuration, especially duplicate env reads, silent defaults, client/server leakage, or inconsistent build and runtime config.
finish-agent-sessions
Use when the user asks to find, recover, resume, or finish incomplete work across Claude Code, Codex, Kiro, Kimi, Cursor, OpenCode, Grok, or other agent sessions without leaving stale, duplicate, or partially completed tasks.
mcp-oauth-onboarding
Use when the user asks to add, install, configure, authenticate, or troubleshoot an MCP server for Claude Code or another agent, especially global user-scope setup, OAuth login, restart, and real tool verification.
organized-commits
Use when the user asks to organize commits, split or group by intent, write conventional messages, clean up Git history, consolidate branches or worktrees, salvage stale work, or runs $organized-commits / /organized-commits (often then push). Also apply on freeform "git commit push" when they want intent-based commits rather than one dump commit. Commit on a feature-related branch, not main/default by default. Never delete remote branches unless explicitly asked. If they want full verify + handoff + no leftovers after push, also apply finish-and-ship.
preview-and-prove
Use when the user wants a real local or UI proof — launch local, relaunch, run local, "do not deploy / run local", QA via playwright, e2e in browser/app, tunnel for test mode, "did you verify/check it works" on a visible flow, preview, or responsive QA. Prefer this over deploy-and-prove when they say run local or do not deploy. Especially checkout, authentication, onboarding, forms, extensions, or responsive behavior.
reuse-first-audit
Use when the user asks to build or replace a feature and wants existing repository code, platform capabilities, installed dependencies, packages, templates, or official ecosystem options checked before new implementation.
rtl-ui-audit
Use when the user asks to audit, fix, or verify Hebrew, Arabic, Persian, Urdu, or other right-to-left UI behavior, including layout mirroring, mixed-direction content, icons, forms, responsive screens, and accessibility.
sync-agent-skills
Use when the user asks to install, reinstall, update, or synchronize skills globally or per-project across Claude Code, Codex, Kiro, Kimi, Cursor, Gemini, OpenCode, Grok, or every detected coding agent — including proving dual-agent discovery (Codex $skill vs Grok freeform/slash) after copy, not folder existence alone.
agent-benchmark
Use when the user wants a professional, dynamic agent/skill/tool benchmark — compare harnesses, skills, MCPs, CLIs, or workflows on the same tasks with tokens, turns, latency, cost, and success metrics; prove whether a change helps; run ablation-style experiments; or build a reusable bench harness for a repo. Inspired by rigorous same-task evaluation (not GitHub stars).
cloudflare-ops
Use when the user asks for Cloudflare operational work — wrangler config, D1 create/migrate/backup, KV/R2 hygiene, Workers/Pages project wiring, proxy or secrets layout, multi-env CF setup — as distinct from proving a production deploy is live (use deploy-and-prove for that).
fix-bug
Use when the user runs /fix-bug, says "fix this bug", "fix these bugs", "reproduce then fix", "debug this failure", or describes one or more concrete defects and wants senior-engineer proof (env, logs, edge cases, verification) before code changes — never patch from the report alone.
ship-feature-e2e
Use when the user runs /ship-feature-e2e, pastes an existing GitHub issue (#N / URL), or says "ship this feature end to end", "implement this issue fully", "feature to main", "issue to PR to merge", "act then merge reinstall" — one feature or one issue through issue → worktree/branch → implement → unit + e2e happy paths → PR with summary + confidence 1–10 → local act → merge → reinstall. Orchestrate by loading and reusing sdlc-tasks-executions, organized-commits, finish-and-ship (and siblings); do not reimplement those skills. Prefer over finish-and-ship when merge/act/reinstall are in scope; over messy-repo-orchestrator for a single feature/issue.
skill-from-feedback
Use when the user wants to modify, improve, patch, or revise an existing agent skill from feedback — real session failures, “this skill did X wrong”, tighten triggers, fix workflow holes, or turn review notes into SKILL.md changes. Not for creating a brand-new skill from scratch (use capture-workflow / create-skill) and not for scanning all sessions (use agent-session-auditor).
test-gap-ship
Use when the user runs /test-gap-ship, says "test gaps all the way to main", "ship test gaps", "parallel test-gap worktrees merge", "one skill init test coverage campaign", or wants a single orchestrator that scans test gaps (or resumes docs/agent/test-gap/REPORT.md), fans out one sub-agent worktree+issue per feature, TDD-fills unit/mocks/e2e, opens PRs, and merges to default after gates — main stays on topic branches only with a backup first. Artifacts under docs/agent/test-gap/ only (never repo root). Reuses test-gap-tdd, sdlc-tasks-executions, messy-repo-orchestrator, organized-commits, finish-and-ship; does not reimplement them. Default e2e is headless unless user says headed/visible/ui. Prefer over plain test-gap-tdd when merge + parallel lanes are required; over ship-feature-e2e when the job is multi-feature test coverage not one product feature.
test-gap-tdd
Use when the user runs /test-gap-tdd, says "scan test gaps", "find missing tests per feature", "subagents inventory unit mocks e2e", "fill test gaps with TDD", "backend unit and MSW gaps", or wants a framework-agnostic first scan of all test layers (backend unit, client unit, mocks/MSW/fixtures, integration, e2e web/native) via sub-agents, a per-feature missing summary, then TDD implementation of gaps, then e2e runs. Default e2e is headless unless the user says headed/visible. Persist reports under docs/agent/test-gap/ (never repo root). Reuse sdlc-tasks-executions for fan-out; do not invent a second worktree scheme.
workspace-bootstrap
Use when the user asks to duplicate or clone every GitHub repo into a Code folder, sync org repos (e.g. personal + vybekiit + genshot), bulk pnpm install across sibling repos, pull all remotes and report deltas, or bootstrap a multi-repo workspace without installs first.
kill-ports-local-dev
Use when the user asks to kill local ports, free ports, kill all local ports except metro/8081, clear listening ports before relaunch, or stop stray local servers blocking dev.
autorun
Drive the autonomous context loop for this session — arm it to auto-/compact and resume work hands-free, or pause/shut it down. Use when the user types /autorun (optionally with a number or `stop`/`exit`), says "autorun", "autopilot", "take it from here", "keep going hands-off", or asks to pause / stop / shut down / exit the auto-compact loop.
png-to-code
Convert a PNG design into pixel-perfect code — SVG illustrations/logos, HTML/CSS UI, and animations — using a decompose → reuse-or-build → render → screenshot-diff → refine loop that measurably converges to a 1:1 match instead of eyeballing. Use when the user provides a PNG, screenshot, mockup, or inspiration image and wants it turned into SVG, HTML/CSS, a web component, or an animated illustration, or asks to match a design "pixel-perfect" / "1:1".
coordinate-worktrees
Use when the user asks to coordinate, consolidate, merge, salvage, or land work from multiple branches or Git worktrees, especially when they are dirty, overlapping, stale, or being used by concurrent agents.
cws-listing-seo
Optimize Chrome Web Store listing SEO (name, short description/summary, Overview) and marketing-site GEO using official Chrome/Google guidance plus free Google APIs. Use when the user asks for CWS SEO, Chrome Web Store listing optimization, store title/summary/description copy, keyword research for extensions, Featured eligibility copy, or GEO/AEO for an extension landing page.
deslop
Reviews code readability first, then applies approved cleanup that makes the full pipeline understandable in seconds. Use when the user says "deslop" for readability (not structure lean-out), "make this readable", "make this less AI", "second pass", "clean this up", "rename for clarity", "show before and after", or asks to improve code comprehension across React, TypeScript, backend, folders, imports, hooks, or functions. If the real ask is full-repo lean / ban wrappers / kill ceremony / over-engineering, use deslop-v2 (optionally after grill-me-code-style-with-docs).
deslop-v2
Reviews code and repo structure for over-engineering and tool-ceremony, then removes the excess so the code does exactly what it needs and no more. Companion to deslop (readable) — this skill makes it lean. Use when the user says plain "deslop", "full deslop", "0 AI slop", "100% desloped", "make it lean", "ai slop", "deslop-v2", "over-engineered", "too much abstraction", "over-abstracted", "simplify this", "flatten this", "kill ceremony", "tool slop", "delete noisy scripts", ban generic names (payload/result/data/raw/isRecord/resolve*), avoid `??`/nested ternaries, delete stale/single-use files, or cut needless wrappers/layers/folders/typegen/scripts that only shell wrangler/biome/drizzle. After a grill locks CODE-STYLE
grill-me-code-style
Grill the user on how a NEW/greenfield project is built — code style, structure docs, and CLI — then render an HTML plan and, on approval, write CODE-STYLE.md + a formatter config and refresh the AGENTS.md digest. Ensures PROJECT.md/CONTEXT.md/LANGUAGE.md exist (create if missing, validate if present) and grills real code idioms + formatting, not just architecture — including tool-first scripts (only scripts/dev + scripts/production), no house typegen, and structured logging defaults. Use when setting up or reorganizing a new project, when there is little/no code, or when defining coding style, structure, or CLI conventions from scratch. For an existing codebase, use grill-me-code-style-with-docs instead.
grill-me-code-style-coach
Coach the user WHILE building or fixing code in a repo that has a code-style.rules.json — at each real style/structure decision, explain the concept concisely (KISS) in terms they already know, show two concrete variants, make them confirm the direction before writing, then teach the mechanism and link the exemplar it mirrors. High-friction on judgment calls; silent on anything Biome already enforces. Grounds "where the business logic goes" in PROJECT.md / CONTEXT.md. Use when writing a feature/fix and the user wants to LEARN their own architecture as we go, not just delegate — or says "coach me", "teach me as we build", "grill me while we code". For reviewing a finished diff instead, use grill-me-code-style-review; to CREATE the ruleset, grill-me-code-style.
grill-me-code-style-review
Review a large changeset (a branch, working tree, or PR — tens to hundreds of files) against a repo's code-style.rules.json so the user can trust it WITHOUT reading every diff, and LEARN the architecture from a short teaching report instead. Runs Biome (+ its grit plugins) to auto-fix the mechanical/structural channels across all files, then fans out sub-agents over the diff to check only the judgment-channel rules + the user's original intent, and returns a deviations-only report that opens with a layer/flow map of what changed and teaches the "why" behind each finding. Use when reviewing/auditing a big diff, a PR, or an AI-generated changeset, or the user says "review this", "can I trust this diff", "audit these changes". To coach while building, use grill-me-code-style-coach; to create the ruleset, grill-me-code-style.
grill-me-code-style-with-docs
Grill an EXISTING codebase for code style, structure docs, and CLI — using real code as evidence — then render an HTML plan and, on approval, write/update CODE-STYLE.md + formatter config and refresh the AGENTS.md digest. Also runs read-only compliance audit when the user already has docs and wants to check slices/files against CODE-STYLE / PROJECT / AGENTS without rewriting them. Use when: grill-me-code-style-with-docs, $grill, gridme, rebuild CODE-STYLE, audit CODE-STYLE compliance, docs vs code, ban generic names (result/payload), full-repo deslop that starts by deciding style, or "from the beginning" style grill on a repo with meaningful code. Fans out sub-agents for repeated patterns including ceremony/tool-slop; ships deterministic inventory + naming scanners. Greenfield → grill-me-code-style; mass kill after guide exists → deslop-v2.
grill-me-stack
Grill the user on the TECHNOLOGY choices of a project — language, runtime, framework/meta-framework (e.g. React vs Next), and the key services/vendors — one decision at a time, so they can EXPLAIN why, not just accept it. For each: teach the tradeoff space in plain terms (honest cost vs gain, alternatives conceded), make them pick, then explain how that piece's architecture actually works. Writes each outcome to TEACH.md as a lean decision-record + a self-closing, officially-cited glossary with a code snippet per term — deduped against what's already there. Leaves LANGUAGE.md for shared domain vocabulary and hands deep multi-session concept mastery to the `teach` skill. Use when the user asks "why this stack/framework/language/service and not the other", wants to understand or be able to explain their own tech choices, or says "grill me on the stack", "why TS not Python", "why React not Next", "teach me why we chose X". For code-style conventions use grill-me-code-style.
grill-with-docs
Grilling session that challenges your plan against the existing domain model, sharpens terminology, and updates documentation (LANGUAGE.md glossary, CONTEXT.md orientation, PROJECT.md purpose, ADRs) inline as decisions crystallise. Use when user wants to stress-test a plan against their project's language and documented decisions.
make-a-trailer
Direct a cinematic, viral-ready trailer for any project — reads the repo's own docs to derive the story, consults ChatGPT (GPT-5.5 Thinking) over ai-browser-bridge to write the transcript + storyboard, batch-generates the keyframes as ChatGPT images, animates them with Higgsfield or Flow/Veo, produces voiceover + music (ElevenLabs → Higgsfield → local synth), and assembles a 9:16 master + 16:9/1:1/4:5 platform cuts with ffmpeg — behind two planpage approval gates. Use when the user wants a trailer, promo, launch/teaser/hype video, commercial, sizzle reel, or cinematic short for a project to post on LinkedIn/YouTube/Instagram/TikTok, or says "make a trailer", "make a promo", "cinematic video", or "make it go viral". For a portfolio blog cover image use write-a-post; for store/marketing copy use cws-listing-seo.
planpage
Render a skill's plan, review gate, or report as a beautiful, self-contained, INTERACTIVE HTML page — via the open-source planpage package (Preact components → static HTML + a local post-back server so the user can approve / adjust / flip decisions in the browser and the choice comes straight back to the agent). Use whenever a skill needs an approval gate, a decision review, or a shareable before/after report — author with the kit's components instead of hand-rolling HTML each time.
readme-editor
Create or edit a project's landing documentation set — README.md, AGENTS.md, CLAUDE.md, .github/copilot-instructions.md, and llms.txt — by first deciding which artifacts the repo actually needs, then grilling the user one question at a time with recommended defaults, building a compact README map, using official hyperlinks for named tools and technologies, and only then writing. Inspects the repo before asking anything discoverable. Use when the user wants to create, write, edit, rewrite, audit, polish, or "fix up" a README, AGENTS.md, CLAUDE.md, Copilot instructions, llms.txt, or any project landing/onboarding docs.
refresh-agent-docs
Use when refreshing, rewriting, syncing, or creating repository agent instruction files such as AGENTS.md, CLAUDE.md, GEMINI.md, Cursor rules, Kiro steering, Roo rules, Codex instructions, or root project context docs.
web-best-practices
Audits a website or web app against web-platform best practices and ships the fixes, across seven dimensions — semantic HTML + ARIA landmarks, accessibility, images/fonts, performance, security headers (CSP/HSTS), SEO metadata, and machine-readability for AI agents (llms.txt, schema.org JSON-LD, crawler access, Google's agent-ready rules). Runs a zero-dep static scanner over a project, guides the agent's semantic pass, and provides copy-paste fixes (llms.txt + security-header templates) plus authoritative sources (MDN, web.dev, W3C APG, llmstxt.org). Use when the user wants to check or improve a site's best practices, accessibility, security headers, CSP, semantic HTML, SEO/meta tags, structured data, schema.org, or make a site agent-ready or AI-crawler-friendly. For the deep Core Web Vitals CI gate (Lighthouse CI, CrUX), defer to web-perf-ci.
web-perf-ci
Wires automated website-performance gates into CI/CD and enforces Core Web Vitals budgets (LCP, INP, CLS). Sets up a Lighthouse CI budget check on every PR (lab), a Chrome UX Report (CrUX) real-user field check after deploy, and an optional web-vitals RUM snippet. Grills the repo to detect the stack and how the site runs (static build, dev server, or preview URL), then writes lighthouserc, the GitHub Actions workflows, and zero-dep CrUX + PSI checkers. Use when the user wants to add performance testing, Lighthouse, Lighthouse CI, PageSpeed Insights, Core Web Vitals, web-vitals, a performance budget, or a speed/perf gate to a website's CI/CD, or mentions LCP/INP/CLS regressions or a slow site.
write-a-post
Write a new blog post for Joseph Sabag's portfolio in his exact voice, scaffold it into clientV3/src/data/blog.ts via scripts/dev/new-post.mjs, and generate a matching cover image by driving a real ChatGPT browser conversation through ai-browser-bridge (attaching the likeness photo + an existing cover as references). Use when the user wants to write, draft, add, or publish a blog post / portfolio post, or says "write a post", "new blog post", "post in my voice", or hands over a title/theme + body for the blog.
grill-me
Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.