All authors
Claude Skills by awcameron
github.com/awcameron15 skills0 installs0 views
- Choose SubagentPick a subagent's type and model by whether the task writes anything, not by its topic. Use when about to spawn a subagent, or when the user asks "which agent should I use for X", "read-only agent or write agent", or "what model should this subagent run on".Votes: 0GitHub stars: 2
- Create PrTake local changes through a repo's real branch, commit, push, and PR workflow, using the naming conventions it finds in the repo's docs and git/GitHub history, and confirm before each visible step. Use when the user asks to "open a PR", "create a PR", "ship this branch", "push this up", or "get this reviewed" -- or reports a PR is merged ("it's merged", "that's in now") and the branches need cleaning up.Votes: 0GitHub stars: 2
- Create TddWrite a technical design document (TDD) -- a design doc, RFC, architecture spec, or engineering proposal -- from the user's or repo's own template, falling back to a bundled one. Covers greenfield designs and retroactively documenting an existing codebase. Use when the user asks to draft, write, or generate a design doc, RFC, or architecture spec. Not for test-driven development or writing tests (`write-tests`).Votes: 0GitHub stars: 2
- Diagnose BugFind the confirmed root cause of failing, throwing, crashing, hanging, flaky, or slow code -- one falsifiable hypothesis at a time, tested the cheapest way (the real error or stack trace, a minimal repro, one targeted log) before any fix. Use when the user says "this is broken", "diagnose this", "why is X happening", "I get an error when I do Y", "this test fails intermittently", "this got slow", or "debug this". Produces a root cause with evidence, not a fix (see `fix-bug`).Votes: 0GitHub stars: 2
- Doc Fact CheckCheck a doc's factual claims -- deploy targets, stack choices, architecture rules, conventions, file paths, CLI commands -- against the current codebase and git/GitHub history, and flag anything stale. The repo's canonical docs can be the stale ones, and agent-skill files count as docs. Use when the user asks whether a doc "is still accurate" or "still matches" how things are done, or to "check this doc for staleness". Not for Markdown formatting (`format-docs`) or code review.Votes: 0GitHub stars: 2
- Fix BugImplement a fix for a bug whose root cause is confirmed -- handed over from `diagnose-bug` or already known -- targeting the cause, not the symptom. Use when the user says "fix this", "here's the root cause, go implement the fix", or "go ahead and fix what the diagnosis found". If the cause isn't confirmed, run `diagnose-bug` first. Stops at a verified fix; coverage, review, and shipping are separate steps.Votes: 0GitHub stars: 2
- Format DocsFormat a repo's Markdown docs (README, AGENTS.md/CONTRIBUTING.md, docs/**) with whatever formatter it already uses -- applying whitespace, list indentation, and table fixes directly, and proposing heading, wording, or wrap-style changes for confirmation. Use when the user asks to "format the docs", "lint the docs", "clean up the formatting", "fix markdown formatting", or "check this markdown". Not for fact-checking a doc (`doc-fact-check`) or reviewing code.Votes: 0GitHub stars: 2
- Fullstack Feature SliceBuild or extend one feature end to end across a monorepo's layers -- a shared types/contract package, a backend handler, and a frontend -- deriving each layer's type from the shared contract instead of duplicating it. Use when adding a feature, endpoint, or contract that spans the shared-types package and both apps, or when the user says "vertical slice", "feature slice", "shared types", or "add a migration" / "add a table/column" as part of a feature. Not for a change inside one package.Votes: 0GitHub stars: 2
- Review CodeReview code changes against the repo's own coding standards -- its conventions docs, lint config, ADRs, observability and security practices -- and report findings by severity without fixing them. Use when the user says "review this", "code review", "review my changes", "review the diff", "check this code", "does this diff look right", "anything wrong with this", or "sanity check this", including before merging. Posts one PR summary comment only when explicitly asked.Votes: 0GitHub stars: 2
- Rollout CompatibilityKeep a contract change safe while old and new versions coexist during a deploy -- adding, renaming, or dropping a database column/table, changing an API response shape, deprecating a field, or evolving an event schema (Kafka, SQS, webhooks). Use when the user says "add a column", "add a migration", "rename this field", "is it safe to drop this", or "version this or change it in place", or mentions a rolling, blue-green, or canary deploy. Not for a brand-new contract with no consumer, or an at...Votes: 0GitHub stars: 2
- Terse ReportsReport status updates, summaries, and answers in terse, telegraphic style -- every fact kept, grammar and filler dropped. Opt-in: use when the user asks for it ("keep it short", "be terse", "just the facts", "how many passed, no whole paragraph"). Not for code, comments, or anything written for someone else to read later.Votes: 0GitHub stars: 2
- Ts Best PracticesStaff-level judgment calls for writing and reviewing TypeScript/JavaScript that a linter can't enforce -- comments, type casts, function and class design, error handling, async, naming, immutability, imports, narrowing, and enum/interface-vs-type choices. Use when writing new TS/JS, refactoring, or when the user asks "clean this up", "is this idiomatic", "review this for best practices", or calls code messy or hard to follow.Votes: 0GitHub stars: 2
- Upgrade DependencyBump a dependency the repo already uses to a target or latest version through the repo's own package manager -- reading release notes across the whole version range, checking which breaking changes the code actually touches, and running the tests. Use when the user asks to "upgrade X", "bump this dependency", "update to the latest version", "is it safe to upgrade", or to update an outdated or vulnerable package. Not for adding a new dependency.Votes: 0GitHub stars: 2
- Write TestsWrite or scaffold tests for a change using the repo's own test runner, layout, and mocking conventions, and prove each new test can fail. Use when the user asks to "write tests", "add tests", "test this", "scaffold a spec", or "add test coverage", or asks "does this have tests" / "what's untested here". Covers unit, integration/e2e, and schema/contract tests. Not for general code review (`review-code`).Votes: 0GitHub stars: 2
- Zero Trust ArchitectureEnforce Zero Trust authorization: never trust a caller because of where it came from or which layer already ran -- verify identity and resource ownership explicitly. Use when adding or changing an auth guard, a handler touching a user's or org's data, how an internal service authenticates, a background job or queue consumer, row-level security, or session-token storage, or when auditing authorization gaps -- e.g. "add an endpoint to delete a room" or "why does this user see another org's data".Votes: 0GitHub stars: 2