All authors
Claude Skills by HECer
github.com/HECer27 skills0 installs11 views
- Authoring PrdUse when turning a product idea or change into a loop-ready continuous backlog with small stories and executable behavioral evidence.Votes: 0GitHub stars: 2
- Codebase DesignDesign 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.Votes: 0GitHub stars: 2
- Document ReleasePost-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".Votes: 0GitHub stars: 2
- Domain ModelingBuild 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.Votes: 0GitHub stars: 2
- HealthCode 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".Votes: 0GitHub stars: 2
- Maintaining ContextUse 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.Votes: 0GitHub stars: 2
- Minimal CodeUse 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.Votes: 0GitHub stars: 2
- No Ai SlopEdit 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.Votes: 0GitHub stars: 2
- PerformanceUse 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.Votes: 0GitHub stars: 2
- Plan Ceo ReviewMega 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.Votes: 0GitHub stars: 2
- Plan Eng ReviewEngineering 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".Votes: 0GitHub stars: 2
- Resolving Merge ConflictsResolve 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.Votes: 0GitHub stars: 2
- RetroWeekly 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".Votes: 0GitHub stars: 2
- ReviewPre-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.)Votes: 0GitHub stars: 2
- ShipFully 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".Votes: 0GitHub stars: 2
- Unslop UiUse 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.Votes: 0GitHub stars: 2
- Visual VerificationUse 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.Votes: 0GitHub stars: 2
- WorkflowUse at the start of any non-trivial task — the default order of operations for shipping quality work, from idea to deploy.Votes: 0GitHub stars: 2
- Writing For AgentsCreate 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.Votes: 0GitHub stars: 2
- Yoke RetrofitUse 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 the supported Yoke harnesses.Votes: 0GitHub stars: 2
- Yoke WorkflowUse when the user asks Yoke to plan and build a feature, run stories autonomously, continue a Yoke loop, or only interrupt for major decisions.Votes: 0GitHub stars: 2
- Executing PlansUse when you have a written implementation plan to execute in a separate session with review checkpointsVotes: 0GitHub stars: 2
- Requesting Code ReviewUse when completing tasks, implementing major features, or before merging to verify work meets requirementsVotes: 0GitHub stars: 2
- Subagent Driven DevelopmentUse when executing implementation plans with independent tasks in the current sessionVotes: 0GitHub stars: 2
- Systematic DebuggingUse when encountering any bug, test failure, or unexpected behavior, before proposing fixesVotes: 0GitHub stars: 2
- TddUse when implementing any feature or bugfix, before writing implementation codeVotes: 0GitHub stars: 2
- Writing PlansUse when you have a spec or requirements for a multi-step task, before touching codeVotes: 0GitHub stars: 2