All authors
Claude Skills by aethrox
github.com/aethrox34 skills0 installs121 views
- Api Design StandardsAPI design discipline grounded in the Microsoft/Google REST guidelines, resource and URL conventions, a chosen versioning strategy, what counts as a backward-compatible vs breaking change, and consumer-driven contract testing. Use when designing a new API endpoint, changing an existing API's request/response shape, deciding how to version an API, or asking whether a change to a public interface is breaking.Votes: 0GitHub stars: 18
- Architecture DiagramProduce a software architecture diagram at the right level of zoom, using diagram as code so it can be shown inline, saved, or committed as the user or active workflow authorizes. Use when the user wants to draw, extract, or visualize a project's architecture, a component or request flow, a data flow, or a decision path a design principle hinges on.Votes: 0GitHub stars: 18
- Code ReviewCode review discipline: the approval bar is \"improves code health,\" not \"perfect,\" Fowler's code-smell catalog gives design/complexity concerns a name instead of a vague feeling, and small PRs keep review depth from degrading. Use when reviewing a pull request or diff, requesting a review, deciding whether a change is blockable, or leaving review feedback.Votes: 0GitHub stars: 18
- Code Style LintDiscipline for code style and static analysis, adopt the ecosystem's established formatter as the non-negotiable source of truth, enforce it at pre-commit and CI rather than in review, and treat linting (real defects) as a separate concern from formatting (appearance). Use when setting up a new project's tooling, when a code review comment is about whitespace/naming/formatting instead of behavior, or when the user asks how to configure a linter or formatter.Votes: 0GitHub stars: 18
- Codebase DesignModule design discipline from John Ousterhout's A Philosophy of Software Design, depth as the metric (a lot of functionality behind a simple interface), information hiding vs. leakage, the concrete red flags that mark a shallow module, and comparing at least two designs before committing. Use when designing a new module or class, deciding where an interface boundary (seam) should go, reviewing a design for unnecessary complexity, or asking whether something should be split or merged.Votes: 0GitHub stars: 18
- Dependency Upgrade ManagementDiscipline for keeping dependencies current and deprecating capabilities safely, an inventory (SBOM) of what's actually shipped, security patches on a fast lane separate from routine/major upgrades, and a stated deprecation window (Sunset/Deprecation headers, N-2 support) before removing anything consumers rely on. Use when upgrading a dependency, triaging a Dependabot/Renovate PR, deciding whether an upgrade is safe to automerge, or planning to deprecate or remove a capability others depend on.Votes: 0GitHub stars: 18
- Diagnosing BugsSystematic debugging discipline based on David Agans' nine rules, understand the system, reproduce reliably, bisect the search space, change one variable at a time, keep an audit trail, and never declare a fix done until it's verified against the original failure. Use when the user reports something broken, throwing, failing, or slow, or says "diagnose" / "debug this".Votes: 0GitHub stars: 18
- Domain ModelingDomain-Driven Design discipline, build a ubiquitous language shared by code and conversation, draw explicit bounded contexts where a term's meaning holds, and record significant decisions as one-page Architecture Decision Records. Use when project vocabulary is inconsistent or ambiguous, when the same word means different things in different parts of a codebase, when onboarding needs a shared glossary, or when a significant architectural decision needs to be captured for later.Votes: 0GitHub stars: 18
- Explain PlainlyDefault to explaining technical work in plain language for a non-technical audience, using an existing project glossary only when a persistent document is already in scope. Use whenever an explanation is aimed at someone outside the technical team, or whenever jargon would otherwise go unexplained. Distinct from wait-what, which is a recovery move after an explanation already failed, not a default posture.Votes: 0GitHub stars: 18
- GrillingInterview the user relentlessly, in rounds, to close the gap between what's known and what's needed before acting on a plan, decision, or idea. Use when the user wants to stress-test their thinking, a plan has unstated assumptions, or a decision keeps getting acted on before it's actually been made.Votes: 0GitHub stars: 18
- HandoffHand off in-progress work, an on-call shift, or an open incident to another person or agent using a fixed four-part structure, so nothing load-bearing is lost between one owner and the next. Use when work needs to change hands mid-flight, an on-call rotation is ending, or an open incident is passing to a new owner. Not for compacting a conversation so a fresh session can resume, which is a session-continuity concern.Votes: 0GitHub stars: 18
- Improve Codebase ArchitectureScan a codebase (or a named area of one) for architectural friction, classify each finding by how it was incurred, and propose deepening opportunities in priority order. Use when the user wants an architecture review, asks where the design is causing pain, wants technical debt surfaced and prioritized, or asks what to refactor next.Votes: 0GitHub stars: 18
- Incident ResponseDiscipline for the full incident lifecycle, declaring and sizing an incident by severity, separating the incident-commander/comms/ops roles, mitigating before root-causing, and writing a blameless postmortem that investigates the system rather than a person. Use when a production incident is happening or just resolved, when the user asks to declare an incident, run an incident response, write a postmortem, or asks who's in charge during an outage.Votes: 0GitHub stars: 18
- ObservabilityDiscipline for making a service's health answerable without reading its code, structured logging, the four golden signals (latency, errors, traffic, saturation), and an SLI/SLO/error-budget definition with alerts that link a runbook. Use when adding logging to a service, instrumenting metrics or tracing, defining what "healthy" means for a service, setting up alerts, or when the user asks how to monitor, debug in production, or know if something is broken.Votes: 0GitHub stars: 18
- Project GroundworkCheck an existing draft specification or README against a fixed set of quality characteristics, batch only the genuinely blocking gaps into one round of questions, and write each resolved decision into the source document plus the repository's existing decision-recording artifact when one exists. Use when a draft spec or architecture doc has sections that disagree with each other, still carries TBDs, or needs its open points settled before implementation starts.Votes: 0GitHub stars: 18
- PrototypeBuild a throwaway spike solution to answer one design or technical question before committing to an approach. Use when the user wants to sanity-check whether a state model, logic, or UI direction feels right, is unsure an approach will work, or wants to explore options before writing production code.Votes: 0GitHub stars: 18
- Release VersioningDiscipline for release classification, version bumps, and changelogs, Conventional Commits classify the release range, SemVer computes the version from those commits, Keep a Changelog renders the result. Use when the user asks to cut a release, bump a version, write a changelog, decide if a change is a major/minor/patch, or choose a branching model for versioned releases.Votes: 0GitHub stars: 18
- Repo SecureAudit and enable a GitHub repository's own recommended security settings, confirming with the maintainer which ones actually apply before turning anything on. Use when the user wants a repo hardened, asks to enable secret scanning or branch protection, wants a SECURITY.md written, or references GitHub's maintainer security checklist.Votes: 0GitHub stars: 18
- Repo ShipSplit existing repository work into commits by intent as it happens, or give a new repository its name, visibility, description, and topics at creation. Use the matching path when work is about to be committed or pushed, before a push that would otherwise land as one large commit, or when a new repository is being created.Votes: 0GitHub stars: 18
- ResearchInvestigate a technical question against primary sources and capture the findings, with citations, as a file in the repo. Use when the user wants a topic researched, docs or API facts gathered, a claim verified before it's relied on, or reading legwork delegated to a background agent.Votes: 0GitHub stars: 18
- Resolving Merge ConflictsDiscipline for resolving an in-progress git merge or rebase conflict, a conflict marker names two divergent intents from a shared ancestor, resolved by tracing each side back to what it was trying to accomplish, never by blindly picking one side's raw text. Use when a merge or rebase has stopped with conflict markers, when deciding whether to resolve with --ours/--theirs, or when choosing between merge and rebase for integrating a branch.Votes: 0GitHub stars: 18
- Safe DeploymentDiscipline for shipping changes reversibly, decouple deploy (code reaches production) from release (users see it) with feature flags, roll out progressively, and define the automated rollback trigger before shipping, not during the incident. Use when the user asks how to deploy a risky change, choose between canary/blue-green/rolling deployment, ship behind a feature flag, plan a rollback strategy, or asks "how do we ship this safely."Votes: 0GitHub stars: 18
- Secure CodingSecure-coding discipline mapped to the OWASP Top 10, checked at the point of writing code, not after. Covers input validation and injection classes, broken access control, secrets handling, dependency/supply-chain risk, and safe error handling/logging. Use when writing code that crosses a trust boundary (handles user input, auth, payments, file paths, external commands, or third-party dependencies), when reviewing a diff for security issues, or when the user asks for a security review, threat...Votes: 0GitHub stars: 18
- Spec To TicketsTurns an already-discussed plan into a written spec and a set of tracer-bullet tickets, synthesizing rather than re-interviewing, slicing work end-to-end rather than by layer, and gating entry/exit with a written Definition of Ready and Definition of Done rather than by feel. Use when the user asks to turn a conversation or plan into a spec, break work into tickets, or size and sequence a set of tasks before implementation starts.Votes: 0GitHub stars: 18
- TddTest-driven development discipline: the red-green-refactor cycle, the testing pyramid's proportion of unit/integration/e2e, Fowler's test-double taxonomy, and the FIRST properties of a test worth keeping. Use when building a feature or fixing a bug test-first, mentions \"TDD\" or \"red-green-refactor\", or when deciding what kind of test to write, whether to mock a dependency, or how a test suite should be shaped.Votes: 0GitHub stars: 18
- TeachTeach a concept or skill by pitching it at the right cognitive level and fading from a fully worked example to independent practice. Use when the user wants something explained so it's actually understood and retained, not just told once, or asks to be taught rather than simply given an answer.Votes: 0GitHub stars: 18
- Test StrategySuite-level testing decisions that sit above individual tests, where test data comes from (synthetic factories vs anonymized production snapshots), the flaky-test quarantine policy, and where the integration/e2e boundary actually belongs. Use when deciding how a test suite should source its data, what to do with a flaky test, or whether a given seam needs a full integration test, a contract test, or a unit test with a double is enough. Does not cover the red-green-refactor cycle or test-doubl...Votes: 0GitHub stars: 18
- To QuestionnaireTurn a decision that can't be answered alone into a written questionnaire for the person who actually holds the missing knowledge. Use when a decision is blocked on facts or judgment only one specific person has, and that person needs to be asked async or in a structured meeting rather than interviewed live.Votes: 0GitHub stars: 18
- TriageClassify and prioritize an incoming bug report or feature request using Impact × Urgency, and route it to the right next step. Use when the user wants a backlog triaged, an issue prioritized, or asks whether something is worth working on now versus later.Votes: 0GitHub stars: 18
- Wait WhatRecognize when the last explanation didn't land, and re-pitch it rather than repeating it. Use when the user's response signals confusion (a follow-up that shows they missed the point, silence, or a direct "wait, what?") right after an explanation was given.Votes: 0GitHub stars: 18
- WayfinderPlan a piece of work too large or too foggy for one sitting as a staged sequence of written decisions, resolved one at a time until the path to done is clear. Use when a loose idea needs to become a plan before implementation starts, when several open questions block each other, or when work is too big to spec in a single pass.Votes: 0GitHub stars: 18
- WizardGenerate an interactive script that walks a human, step by step, through a manual procedure only they can perform. Use when provisioning infrastructure, setting up credentials or CI secrets, navigating an unfamiliar third-party dashboard, or running a one-off migration or cutover that needs a human's hands or authority at each step.Votes: 0GitHub stars: 18
- Writing For AgentsClassify and structure content going into a document an agent reads (a skill, AGENTS.md, CLAUDE.md, a linked doc) so procedure, facts, and rationale don't get tangled together. Use when creating or editing a skill, or writing/editing AGENTS.md or CLAUDE.md.Votes: 0GitHub stars: 18
- Capacity EstimationTurn a vague performance requirement into arithmetic before the architecture is chosen, size concurrency with Little's Law, and label every input as measured, derived, or assumed. Use when a design calls itself "scalable" or "fast" without a number, when choosing between one machine and a distributed system, when sizing a thread pool, connection pool, queue, or instance count, or when someone asks how much traffic, storage, or bandwidth a system will need.Votes: 0GitHub stars: 18