Claude Skills by HECer

Use when turning a product idea or change into a loop-ready continuous backlog with small stories and executable behavioral evidence.

Design or improve deep modules, small interfaces, real seams, and public-interface tests. Use when shaping a module, placing a dependency seam, evaluating shallow pass-through layers, improving testability, or comparing architecture alternatives; do not force unrelated refactors.

Post-ship documentation update. Runs after ship (code committed, PR exists) but before the PR merges. Updates every documentation file to reflect the changes in the diff: README, CHANGELOG, ARCHITECTURE, CONTRIBUTING, TODOS.md, VERSION. Use when asked to "update docs", "document the release", or "update the changelog".

Build or sharpen a project's domain language and durable decisions. Use when terminology is fuzzy or contradictory, relationships need scenario testing, the code disagrees with the stated model, or a glossary or ADR-class decision must be updated; do not trigger merely to read existing context.

Code Quality Dashboard. Runs the project's type-checker, linter, test runner, and dead-code detector, scores each category 0-10, and presents a dashboard with trends. Use when asked for a "health check", "code quality report", or "quality dashboard".

Use at the start of any substantial task and whenever you make a non-obvious decision or learn a reusable fact — keeps .yoke/context/ (PROJECT, DECISIONS, KNOWLEDGE) the durable source of truth so fresh-context work never drifts.

Use before writing any code — write the least code that fully solves the task (YAGNI, stdlib-first, no unrequested abstractions) to save tokens and reduce maintenance.

Edit prose into clearer, more direct writing while preserving the writer's voice, or detect named AI-slop patterns without rewriting or guessing authorship. Use for documentation, release notes, product copy, or prose audits; do not trigger for code-only work.

Use when a task has efficiency requirements or touches a hot path — make performance a measured requirement (benchmarks as tests, budgets as gates), keep interfaces clean and optimizations local, and version the WHY so future agents don't "clean up" fast code back to slow.

Mega plan review from a product/CEO perspective. Challenges premise, challenges scope, maps alternatives, reviews architecture through 11 sections, and offers an outside voice. Use when asked to "CEO review", "mega plan review", "product review this plan", or when shipping a significant new product feature.

Engineering plan review. Reviews a plan document for architecture, code quality, test coverage, and performance before implementation begins. Produces a coverage diagram, failure modes map, and parallelization strategy. Use when asked to "review this plan", "eng review", or "architecture review".

Resolve an in-progress Git merge or rebase conflict by tracing both sides to commits and available issue or spec evidence, preserving compatible intent, and running project checks. Use only when a merge or rebase is currently conflicted.

Weekly engineering retrospective. Analyzes commit history, work patterns, and code quality metrics for the time window. Team-aware: identifies the user, then analyzes every contributor with per-person praise and growth opportunities. Use when asked for a "retro", "engineering retrospective", or "weekly summary".

Pre-merge code review — the single canonical review of a change before it lands. Covers BOTH diff safety/structure (SQL safety, LLM trust-boundary violations, conditional side effects) AND engineering quality (architecture fit, edge cases, test coverage, performance). Use when asked to "review this PR", "code review", "pre-landing review", "check my diff", or before merging. (For plan-time review use plan-eng-review or plan-ceo-review instead.)

Fully automated ship workflow. Merges the base branch, runs tests, audits coverage, reviews the diff, generates a CHANGELOG entry, bumps the version, commits, pushes, and creates the PR. Use when asked to "ship", "create a PR", or "open a pull request".

Use when building or reviewing any UI — detect and remove the visual "tells" of AI-generated/vibecoded design (AI-purple gradients, gradient hero text, neon glow, emoji-as-icons, untouched shadcn defaults, centered-hero-plus-three-cards) so the result looks deliberately designed, not machine-default.

Use for any UI/web project — make the verify gate cover more than unit tests by composing a pipeline (types → unit → design-scan → flow-smoke) and running the built-in yoke flow-smoke gate (landmark + zero console errors + screenshot proof to .yoke/proof/<story>/, video kept on failure). Catches the unwired-page / runtime-crash / AI-slop bugs unit tests miss.

Use at the start of any non-trivial task — the default order of operations for shipping quality work, from idea to deploy.

Create or edit agent-facing instructions such as AGENTS.md, CLAUDE.md, skills, roles, and workflow documents. Use when triggers, completion criteria, context pointers, instruction hierarchy, or duplication affect whether an agent can execute the document reliably.

Use when asked to "retrofit", "yoke this project", or set up the Yoke harness in a project — runs the shared setup wizard and configures the same behavior for Claude, Codex, and Gemini.

Use when the user asks Yoke to plan and build a feature, run stories autonomously, continue a Yoke loop, or only interrupt for major decisions.