garyld1962
- 231 skills
- 0 followers
- 11 hours ago last updated
- ▌ Process Tune 3 · garyld1962 bundleRead accumulated postmortems or run evidence, group repeated workflow failures, and propose concrete edits to skills, rubrics, templates, or rules.
- ▌ Feature Sweep 4 · garyld1962 bundleAudit installed skills against verified current platform releases and propose or apply targeted improvements. Use after a Codex or Copilot release, or to find useful new integrations; use a skill quality audit for ordinary wording and trigger problems.
- ▌ Validate Plan 6 · garyld1962 bundleValidate a task graph plan's YAML, dependencies, write ownership and acceptance before execution, then review semantic readiness. Use for plan checks; do not execute or rewrite the plan unless requested.
- ▌ Audit Existing 3 · garyld1962 bundleRead-only audit of an existing implementation before planning or extending it. Produces implemented, missing, duplicated, broken, and risky findings without editing files.
- ▌ Refactor Brief 4 · garyld1962 bundleInvestigate a refactoring problem and produce an RFC with preserved behavior, interface decisions, characterization tests and small working commits. Use for refactor planning or an issue brief, not for applying a refactor that is already specified.
- ▌ Review Gauntlet 3 · garyld1962 bundleMeta-review of an existing code review. Tests whether review findings are accurate, actionable, complete, and severity-calibrated.
- ▌ Code Investigate 3 · garyld1962 bundleEvidence-backed code investigation across one or more repos. Use for durable reports about where behavior lives, how a pattern is implemented, or whether a behavior exists.
- ▌ What Is It About 3 · garyld1962 bundleFind the central thesis of a video, article, talk, or content idea, then produce an outline where every segment serves that thesis.
- ▌ Review Adversarial 4 · garyld1962 bundleHigh-stakes adversarial code review after normal review. Challenges assumptions with distinct reviewer lenses and optional configured external model/CLI reviewers.
- ▌ Ubiquitous Language 3 · garyld1962 bundleBuild or refresh a domain glossary from interviews, specs, code, and docs. Flags ambiguous terms and writes UBIQUITOUS_LANGUAGE.md when asked.
- ▌ Spec Review Adversarial 3 · garyld1962 bundleAdversarially review PRDs, stories, requirements, acceptance criteria, or AERS drafts for ambiguity, contradiction, unverifiability, and scope traps.
- ▌ Code Review Professional 3 · garyld1962 bundleSeniority-calibrated craft review after a normal code review. Grades code quality across maintainability, clarity, design, tests, operability, and professional judgment.
- ▌ Pr 3 · garyld1962Full PR lifecycle: branch, commit, checkpoint, push, create PR, and optionally squash-merge. Automates the entire pull request workflow with quality gates.
- ▌ Ship 4 · garyld1962 bundleShip completed work through the repo's actual delivery flow: checkpoint, commit, push, PR, and release steps. Reads project-specific delivery commands from config.
- ▌ Test Plan 4 · garyld1962 bundleUse before implementing a feature to generate it.todo() stubs from requirements (TDD-first). Supports plan, validate, and refresh modes. TypeScript monorepos.
- ▌ Code Review 2 · garyld1962 bundleDomain-based PR review controller. Use when you need a structured, multi-lens review of a pull request or code change. Supports two profiles: 'breakpoint' (light mid-flow review covering security, correctness, and tests only) and 'full' (comprehensive PR-boundary review covering all 11 domains). Conditional domains fire only when triggers match: data-integrity fires when the diff touches persistence (migrations, schemas, SQL, repositories, ORM models); api-contract fires when the diff touches a public surface (API routes, controllers, handlers, .proto files, OpenAPI/Swagger specs, library surface, message schema, CLI, or SDK). Do NOT use for trivial changes (typo fixes, mechanical refactors, dependency bumps with no logic changes). Do NOT use when you want professional craft grading or seniority assessment — use the code-review-professional skill instead.
- ▌ Hotfix 3 · garyld1962Apply an expedited fix for a critical production issue: branch from main, apply a scoped fix, run targeted tests, and fast-track merge.
- ▌ Execute Plan 7 · garyld1962 bundleExecute a written implementation plan with staged reviews, per-task build/test cycles, milestone breakpoints, and optional parallel agent lanes.
- ▌ Code Investigate 4 · garyld1962 bundleSearch one or more repos for a code pattern or behavior and produce a versioned Markdown investigation report. Supports literal, regex, and semantic (behavioral) search across multi-repo scope.
- ▌ Review Adversarial 5 · garyld1962 bundleCross-model adversarial code review via Codex/Gemini. Use for high-stakes diffs (auth, payments, migrations) or diffs over 200 lines after code-review passes.
- ▌ Kickoff 3 · garyld1962Use for standard feature work to autonomously ship a PRD/story/AERS: readiness → plan → implement → review. Does not produce audit-grade governed artifacts.
- ▌ Test Writer 2 · garyld1962Test file generator — converts TestSpecification objects into valid Vitest .test.ts files with it.todo() stubs.
- ▌ State Lifecycle 2 · garyld1962State machine analyst — tests every valid transition, rejects every invalid one, verifies side effects of status changes.
- ▌ Boundary Validation 2 · garyld1962Input validation analyst — tests required field enforcement, Zod constraint boundaries, NOT_FOUND handling, error code specificity, soft-delete behavior.
- ▌ Contract Compliance 2 · garyld1962Requirements analyst — decomposes task description into testable requirements. Maps Zod schema fields to assertions. Verifies CRUD completeness and return type coverage.
- ▌ Integration Surface 2 · garyld1962Integration analyst — tests router-to-service wiring, Zod schema binding, query vs mutation assignment, auth requirements, and cross-boundary contracts.
- ▌ Pr 2 · garyld1962Full PR lifecycle: branch, commit, checkpoint, push, create PR, and optionally squash-merge. Automates the entire pull request workflow with quality gates.
- ▌ Goal 2 · garyld1962Clarify and validate a development goal before writing a PRD. Use when the user has an idea or intent but hasn't shaped it into requirements yet — phrases like 'I want to build X', 'I'm thinking about adding Y', 'we should improve Z', 'what should we work on next', 'help me think through this idea'. Separates outcomes from solutions before any implementation work begins. When NOT to Use: requirements already written (use /prd-validate); specific bug to fix (use /triage); design decision to explore (use /design-twice).
- ▌ Ship 2 · garyld1962 bundleShip completed work through the repo's actual delivery flow: checkpoint, commit, push, PR, and release steps. Reads project-specific delivery commands from config.
- ▌ Vault 2 · garyld1962Search, create, and manage notes in the Obsidian vault at /data/obsidian. Use when user wants to find, create, link, or organize notes — phrases like 'find my note on X', 'create a note about', 'add this to the vault', 'search my notes', 'open the vault'.
- ▌ Drawio 2 · garyld1962Generate native .drawio diagram files (flowcharts, ER, sequence, class, architecture diagrams) as draw.io XML, with optional export to PNG/SVG/PDF or a browser URL that opens in app.diagrams.net. No MCP setup required. Triggers on '/drawio', 'create a diagram', 'draw.io', 'flowchart', 'sequence/ER/class diagram'. When NOT to use: for Azure resource-group / cloud-architecture diagrams, use create-diagram instead.
- ▌ Hotfix 2 · garyld1962Apply an expedited fix for a critical production issue: branch from main, apply a scoped fix, run targeted tests, and fast-track merge.
- ▌ Ideate 2 · garyld1962Use before superpowers:writing-plans or brainstorming to shape a rough ask, doc, or folder into a direction. Three modes: idea (general), ba (business-analysis), tech (technical options).
- ▌ Thesis 2 · garyld1962Interrogate to discover the single-sentence product or architectural thesis, then audit all planned features and decisions against it.
- ▌ Triage 2 · garyld1962Investigate a bug from reproduction through root cause analysis and produce a structured triage report (classification, risk, recommended next step) — the deliverable is the report, not a fix. Preferred over superpowers:systematic-debugging when the goal is a handoff document for /hotfix, /execute-prd, or a human decision rather than an in-session fix.
- ▌ Goal 3 · garyld1962Turn a rough idea into a clear outcome, problem statement, success measures and scope before requirements work. Use for goal discovery, not an already written PRD or an implementation request whose outcome is clear.
- ▌ Kickoff 2 · garyld1962Use for operator-supervised feature work from a PRD/story/AERS: readiness → plan → implement → review, with the operator at the keyboard. Does not produce audit-grade governed artifacts; for an unattended run use /execute-prd.
- ▌ Vault 3 · garyld1962Search, read, create or organize Markdown notes in a configured Obsidian vault, including wiki links and backlinks. Use when the user names their vault or Obsidian notes; do not assume a personal filesystem path or use it for ordinary repository docs.
- ▌ Grill Me 2 · garyld1962Use when user says 'grill me', wants to stress-test a plan, or validate assumptions. Walks the decision tree one question at a time, exploring the codebase when it can.
- ▌ Simplify 2 · garyld1962 bundleExplain dense progress reports, task or wave summaries, blockers and decision requests in plain language. Use /simplify, 'explain that simply', or before user-facing PRD/plan execution updates. Simplifies explanations, not code.
- ▌ Drawio 3 · garyld1962 bundleCreate or edit editable draw.io diagrams, optionally export PNG/SVG/PDF with embedded diagram data, or produce a diagrams.net URL. Use when draw.io format is requested; use native text diagrams for simple explanations that need no draw.io artifact.
- ▌ Changelog 2 · garyld1962Use to generate a release from Conventional Commits. Groups commits since the last tag, auto-bumps the version, updates CHANGELOG.md, tags, and releases.
- ▌ Configure 2 · garyld1962 bundleUse when a skill's pre-flight says config is missing, or with no arg to see what needs configuring. Interviews the user and writes the config file.
- ▌ Dep Audit 2 · garyld1962Audit project dependencies: check for vulnerabilities, outdated packages, unused deps, and license compliance. Use periodically or before releases.
- ▌ Env Check 2 · garyld1962 bundleDetect the current shell environment and choose safe command routing. Use when working across different shells, OSes, or remote hosts. Reads user-specific shell config from ~/.claude/env.config.md.
- ▌ Modernize 2 · garyld1962Audit a codebase against current AI toolchain capability and produce a prescriptive refactor plan. Use when revisiting an older project (months of dormancy or older-AI-era patterns) to identify structural improvements — abstraction, separation of concerns, types, error handling, tests, infra organization — that newer models can now execute safely. Default --handoff invokes /execute-prd --type=refactor on the resulting plan. Trigger phrases: 'modernize this codebase', 'refresh the code', 'what would this look like today', 'AI-time refresh', 'modernization audit'. Strictly within the current platform/stack — does not propose framework changes, language switches, or public-API rewrites.
- ▌ Sync Main 2 · garyld1962Sync current branch with main: fetch, rebase, resolve conflicts. Use when your branch is behind main or before creating a PR.
- ▌ Test Plan 2 · garyld1962 bundleUse before implementing a feature to generate it.todo() stubs from requirements (TDD-first). Supports plan, validate, and refresh modes. TypeScript monorepos.
- ▌ Work Item 2 · garyld1962Retrieve a work item from Azure DevOps or Linear. Extracts title, description, acceptance criteria, status, assignee, and tags. Presents in clean markdown format for use by other skills.
- ▌
- ▌ Checkpoint 2 · garyld1962Quality gate: discovers project tooling, runs linter, typecheck/build, and tests for changed packages. Use before pushing or creating PRs.
- ▌ K8S Verify 2 · garyld1962Post-deploy verification for Kubernetes: checks pod health, service endpoints, recent events, log errors, and rollout status. Use after any K8s deployment to verify it succeeded.
- ▌ Postmortem 2 · garyld1962Structured retrospective over a completed execute-plan run. Reads the run folder, writes postmortem.md + postmortem.json, and appends to the postmortem index.
- ▌ Prd Create 2 · garyld1962 bundleCreate a PRD, ONTOLOGY.md and AERS from an idea, goal, thesis or codebase via interview. Modes: greenfield, feature, refresh, rewrite. Not for an existing artifact (use /prd-validate).
- ▌ Skill Help 2 · garyld1962List available skills or show detailed help for a specific skill. Use when the user asks 'what skills are available', 'help with a skill', 'what can you do', 'list skills', or '/skill-help'.
- ▌ Simplify 4 · garyld1962 bundleExplain dense progress reports, task or wave summaries, blockers and decision requests in plain language. Use 'simplify this update', 'explain that simply', or before user-facing PRD/plan execution updates. Simplifies explanations, not code.
- ▌ Bug Session 2 · garyld1962Interactive bug-reporting session: user describes problems conversationally, agent explores the codebase for domain context, and files durable GitHub issues. Use when user wants to report bugs, do QA testing, capture defects — phrases like 'let's do a bug session', 'I found some issues', 'QA session', 'help me file these bugs'. When NOT to Use: single known bug to investigate (use /triage); existing issue to fix (use /hotfix or /execute-prd).
- ▌ Dep Migrate 2 · garyld1962Plan a dependency migration: analyze breaking changes, assess impact on your codebase, produce a step-by-step migration plan. Use when upgrading Node, TypeScript, frameworks, or major dependencies.
- ▌ Execute Prd 2 · garyld1962 bundleUse when a written requirements source exists (PRD, RFC, prompt.md, spec file, or ADO/Linear ticket) and the user wants it planned and built — phrases like 'build this PRD', 'execute prompt.md', 'turn this RFC into a plan and run it'. Not for vague ideas (use superpowers:brainstorming) or when a validated plan already exists (use /execute-plan).
- ▌ Repo Status 2 · garyld1962Reports live repo state: branch, working tree, unpushed commits, stashes, and open PRs. Read-only snapshot for orienting at the start of a session or after a long break.
- ▌ Skill Audit 2 · garyld1962Use periodically or when setting up a new project to audit Claude Code skills/plugins/agents, research marketplaces, gap-analyze, and implement recommendations.
- ▌ Configure 3 · garyld1962Resolve missing configuration for Copilot workflows, including execution environment and an Obsidian vault. Use when a workflow preflight reports missing fields; preserve existing user-owned settings.
- ▌ Design Twice 2 · garyld1962Explore multiple radically different API/module designs using parallel agents before committing. Use when designing a new interface, module API, or public surface — phrases like 'design it twice', 'explore the design space', 'what are my options for this interface', 'compare API shapes', 'how should this module look'. When NOT to Use: implementation details inside an existing interface (use superpowers:writing-plans); evaluating existing code (use /code-review).
- ▌ Execute Plan 2 · garyld1962 bundleUse when the user has a written implementation plan file (typically produced by /execute-prd, in the plan-format contract) and wants it executed — phrases like 'execute the plan', 'run docs/plans/X.md', 'resume the plan'. Not for writing plans (use /execute-prd) or trivial single-file edits.
- ▌ Gh Readiness 2 · garyld1962Verify GitHub CLI (gh) is installed, authenticated, and able to reach github.com before running skills that create PRs, issues, or releases. Use before /pr, /ship, /hotfix, /issue-slices, /bug-session, or /changelog when gh status is unknown.
- ▌ Issue Slices 2 · garyld1962Break a PRD into independently-grabbable GitHub issues as vertical tracer-bullet slices. Use when user wants to convert a PRD to tickets, create implementation issues from a PRD — phrases like 'break this PRD into issues', 'create tickets from the PRD', 'slice the PRD into work items'. When NOT to Use: want the PRD executed end-to-end automatically (use /execute-prd); rough idea not yet a PRD (use /goal → /prd-create first); want a plan doc not issues (use /execute-prd step 1).
- ▌ Prd Validate 2 · garyld1962Turn an existing story, BRD, PRD, or AERS draft into an implementation-ready AERS. Interviews the author, closes structural and semantic ambiguity against the AERS and ontology rubrics, generates missing sections. Use before planning, /kickoff, or /execute-prd. When NOT to Use: vague intent without a problem statement yet (use /goal first to validate the outcome before writing requirements); no artifact at all (use /prd-create, which owns the blank start and writes the PRD folder).
- ▌ Process Tune 2 · garyld1962Read accumulated postmortems, group taxonomy-tagged recommendations, and propose edits to skills, rubrics, closed decisions, or plan templates.
- ▌ K8S Verify 3 · garyld1962Post-deploy Kubernetes verification checklist for namespace detection, rollout health, endpoints, events, and optional log analysis.
- ▌ Prd Create 3 · garyld1962 bundleCreate a PRD, ONTOLOGY.md and AERS from an idea, goal, thesis or codebase via interview. Modes: greenfield, feature, refresh, rewrite. Not for an existing artifact (use /prd-validate).
- ▌
- ▌ Domain Review 2 · garyld1962 bundleDomain-based PR review controller (formerly code-review). Preferred over the built-in /code-review when you need the 11-domain controller/worker review with per-domain findings; use the built-in for a fast single-pass diff review or the ultra cloud review. Supports two profiles: 'breakpoint' (light mid-flow review covering security, correctness, and tests only) and 'full' (comprehensive PR-boundary review covering all 11 domains). Conditional domains fire only when triggers match: data-integrity fires when the diff touches persistence (migrations, schemas, SQL, repositories, ORM models); api-contract fires when the diff touches a public surface (API routes, controllers, handlers, .proto files, OpenAPI/Swagger specs, library surface, message schema, CLI, or SDK). Do NOT use for trivial changes (typo fixes, mechanical refactors, dependency bumps with no logic changes). Do NOT use for reviewing a GitHub PR by number where a standard pass suffices — the built-in /review handles that. Do NOT use when you want prof
- ▌ Feature Sweep 2 · garyld1962Audit installed skills against the latest Claude Code and API releases, then propose and optionally apply surgical integrations. Use when you want to capitalize on a new model release or Claude Code update — phrases like 'what new features can improve our skills', 'sweep for new integrations', 'update skills for the new model', 'what Claude features are we not using'. When NOT to Use: improving skill quality or fixing bugs in a single skill, or adding a new skill from scratch (use superpowers:writing-skills).
- ▌ Validate Plan 2 · garyld1962 bundleLightweight readiness gate for a plan file: checks structure, task discreteness, acceptance criteria, milestones, and forbidden placeholders.
- ▌ Execute Prd 4 · garyld1962 bundleUse when a written requirements source exists (PRD, RFC, prompt.md, spec file, or ADO/Linear ticket) and the user wants it planned and built — phrases like 'build this PRD', 'execute prompt.md', 'turn this RFC into a plan and run it'. Not for vague ideas (use superpowers:brainstorming) or when a validated plan already exists (use /execute-plan).
- ▌ Bug Session 3 · garyld1962Capture several reported bugs, inspect relevant code, and turn them into distinct actionable GitHub issues. Use for a bug intake session; use triage to diagnose one existing bug and execute-plan to implement fixes.
- ▌ Execute Prd 5 · garyld1962Turn a PRD, RFC, prompt, story or ticket into an audited, readiness-scored task graph, validate it and implement when requested. Includes lightweight kickoff; use execute-plan for an existing execution plan.
- ▌
- ▌ Audit Existing 2 · garyld1962Audit a repository before planning or extending it. Produces an implemented/missing/duplicated/broken checklist without editing files.
- ▌ Prd Acceptance 2 · garyld1962Validate implementation against PRD acceptance criteria. Reads a PRD, extracts checkboxes, verifies each with evidence, produces a pass/fail scorecard.
- ▌ Refactor Brief 2 · garyld1962Plan a refactor through structured interview, then file it as a GitHub issue RFC with a tiny-commit sequence and decision record. Use when user wants to plan a refactor before implementing — phrases like 'plan a refactor', 'create a refactor issue', 'refactor RFC', 'break this refactor into safe steps'. When NOT to Use: refactor already planned and ready to execute (use /execute-plan); quick code cleanup (make focused edits directly); feature work disguised as a refactor (use /prd-validate first).
- ▌ Execute Plan 4 · garyld1962 bundleUse when the user has a written implementation plan file (typically produced by /execute-prd, in the plan-format contract) and wants it executed — phrases like 'execute the plan', 'run docs/plans/X.md', 'resume the plan'. Not for writing plans (use /execute-prd) or trivial single-file edits.
- ▌ Design Twice 3 · garyld1962Compare at least three contrasting module or API interfaces before committing to architecture. Use for unresolved interface design in feature/refactor work; skip settled designs, small bug fixes, and implementation-only requests.
- ▌ Execute Plan 5 · garyld1962Execute or resume a written task graph plan with ownership checks, acceptance proof, milestone reviews, bounded retries and final-head gates. Use for an existing plan; use execute-prd when requirements still need planning.
- ▌ Gh Readiness 3 · garyld1962Check GitHub access, target repository and required capabilities before creating issues, PRs, releases or other GitHub changes. Use when access is unknown or changed; avoid repeated probes once this session established the needed capability.
- ▌ Issue Slices 3 · garyld1962Break a PRD or parent issue into demonstrable vertical GitHub issues with acceptance and dependency links. Use to create an implementation backlog; use execute-prd for a local execution plan and bug-session for unrelated bug reports.
- ▌
- ▌ Review Gauntlet 2 · garyld1962Use when a code review's conclusions need scrutiny. Reviews THE REVIEW via 3 lenses (Skeptic, Architect, Pragmatist). Returns SOLID / MIXED / UNRELIABLE.
- ▌ Validate Plan 4 · garyld1962 bundleLightweight readiness gate for a plan file: checks structure, task discreteness, acceptance criteria, milestones, and forbidden placeholders.
- ▌ Feature Sweep 3 · garyld1962Audit installed skills against verified current platform releases and propose or apply targeted improvements. Use after a Codex or Copilot release, or to find useful new integrations; use a skill quality audit for ordinary wording and trigger problems.
- ▌ Validate Plan 5 · garyld1962 bundleValidate a task graph plan's YAML, dependencies, write ownership and acceptance before execution, then review semantic readiness. Use for plan checks; do not execute or rewrite the plan unless requested.
- ▌ Code Investigate 2 · garyld1962 bundleSearch one or more repos for a code pattern or behavior and produce a versioned Markdown investigation report. Supports literal, regex, and semantic (behavioral) search across multi-repo scope.
- ▌ What Is It About 2 · garyld1962Interrogate to discover the single central thesis of a planned YouTube video, then produce an outline where every segment serves that thesis.
- ▌ Prd Acceptance 3 · garyld1962Verify delivered behavior against PRD/AERS criteria with a per-criterion evidence scorecard. Use for acceptance validation, not implementation or a general code-quality review.
- ▌ Refactor Brief 3 · garyld1962Investigate a refactoring problem and produce an RFC with preserved behavior, interface decisions, characterization tests and small working commits. Use for refactor planning or an issue brief, not for applying a refactor that is already specified.
- ▌ Repo Delivery 2 · garyld1962Declarative schema every repo must satisfy so execute-plan, checkpoint, and review-adversarial don't have to guess. Not user-invokable.
- ▌ Review Adversarial 2 · garyld1962 bundleCross-model adversarial code review via Codex/Gemini. Use for high-stakes diffs (auth, payments, migrations) or diffs over 200 lines after domain-review passes.
- ▌ Ubiquitous Language 2 · garyld1962 bundleUse when you need a domain glossary. Derives UBIQUITOUS_LANGUAGE.md from the PRD's ONTOLOGY.md; falls back to extracting terms from conversation when no ontology exists.
- ▌ Review Adversarial 3 · garyld1962Cross-model code review rubric for challenging changed code through skeptic, architect, and minimalist lenses after switching models in GitHub Copilot.
- ▌ Parallel Optimization 2 · garyld1962Analyze a PRD or plan and produce a parallel-agent execution map with dependency barriers, write scopes, and task ownership for LLM code generation. TRIGGER on: 'parallelize the plan', 'parallel execution map', 'concurrency shape', 'optimize task ownership', 'parallel-safe lanes', 'split this plan into waves', 'after I draft the plan run parallel-optimization', 'add a Parallel Execution section'. Auto-invoked by /execute-prd step 6 — humans rarely need to call this directly except when reshaping a sequential plan into parallel before re-running /execute-plan.