Claude Skills by bobtat

This skill should be used whenever work is being recorded or retold for career purposes — when the user asks to "log this", "note this accomplishment", "what did I do this quarter", "write my self-assessment", "help with my performance review", "build my promo packet", "update my resume", "turn this into a resume bullet", "write my brag document", "summarize my week for standup" — and whenever Claude has just finished a substantial piece of work that will be invisible in six months. Provides ...

Use when reconstructing a past period into journal entries — mining git, pull requests, reviews given, and the plugin's own session digests across every repository, reconciling what is found against entries that already exist, clustering the remainder into candidate accomplishments, and interviewing the user about the ones that look significant. Invoked by /accomplishments:sweep. Runs against a deadline: while a session transcript still exists it can be upgraded to a written summary, and afte...

Use when turning journal entries into a finished career document — a performance self-assessment, a promotion packet, resume or LinkedIn bullets, or a weekly rollup — by clustering entries into themes, mapping them to the reader's framework, drafting in the user's voice, and verifying that every claim and every number traces back to a dated entry. Invoked by /accomplishments:review.

Use when turning work that just happened into a journal entry — capturing what was accomplished while the context is still live, interviewing for the impact facts that exist only in the user's head, and writing a dated entry with every number traced to its source. Invoked by /accomplishments:log; also useful directly when a session has just produced something that will be invisible in six months.

This skill should be used whenever running or invoking a live QA walkthrough — e.g. "walk through ticket ABC-123", "verify this PR works end to end against staging" — via the interactive /agentic-qa:walkthrough command, an agent-invoked run through agentic-qa:qa-runner, or a direct Skill call. Carries the safety posture, evidence discipline, and escalation mechanism shared across every phase of the pipeline — the umbrella rules the phase-specific skills assume are already loaded.

Use when turning a validated ticket into a behavior spec for a live walkthrough — spawning agentic-qa:behavior-extractor to draft it and agentic-qa:behavior-coverage-critic to pair with it live, arguing findings out directly rather than reporting back. Governs the grounding split between what the acceptance criteria asked for and everything else, the round cap, and the Critique Exchange log. Invoked as the Extract Behaviors phase by /agentic-qa:walkthrough, between Intake and Plan Steps.

Use when building the walkthrough report — spawning agentic-qa:qa-reporter alongside agentic-qa:step-executor to write a live, incrementally-updated report and render the finished, self-contained HTML deliverable at finalization. Governs the report template, the Traceability table, the report-destination sync, the finalization self-check, and screenshot embedding. Invoked by /agentic-qa:walkthrough alongside agentic-qa:step-execution.

Use when running an approved step plan against a live system — spawning agentic-qa:step-executor to drive the browser, API, and CLI. Governs the four verdicts (pass/fail/blocked/skipped), which evidence is required by surface, the choice between the claude-in-chrome and playwright browser drivers, the backoff retry policy for environment failures, the irreversible-step check, and the rule against adapting an action to force a pass. Invoked by /agentic-qa:walkthrough after the User Gate, along...

Use when turning a resolved behavior spec into an ordered, executable step plan — spawning agentic-qa:step-planner to draft it and agentic-qa:step-plan-critic to pair with it live. Governs surface selection (browser vs. API vs. CLI), the reversibility and containment classification, blocked/cascade marking, and the Critique Exchange log. Invoked by /agentic-qa:walkthrough between Extract Behaviors and the User Gate.

Domain-driven design guidance for C# applications. Use whenever designing, building, implementing, refactoring, or reviewing domain models — including aggregate design, bounded contexts, value objects, domain events, module structure, or any domain concept.

Use when running a full edit over a specific draft — establishing what the document is for and who reads it, deleting noise before restructuring fog, holding every change against the never-invent rules, and reporting each cut so the author can veto it. Invoked by /editing:edit; also useful directly when a README, design doc, or long reply needs revision rather than a fresh draft.

This skill should be used whenever Claude is writing or revising prose that a person will read — a chat reply explaining a finding, a README, a design doc or ADR, a PR description, release notes, a docstring — and whenever the user asks to "edit this", "tighten this", "cut the fluff", "make this less AI", "rewrite this paragraph", "review my writing", or says a draft is "too wordy", "too corporate", "repetitive", or "reads like ChatGPT". Provides the catalog of tells that mark machine-written...

Use when turning a dirty working tree into a sequence of atomic commits — surveying what changed, grouping hunks by intent rather than by file, screening for secrets and contamination, verifying each prospective commit builds on its own, and creating the commits after user approval. Invoked by /git-workflow:commit; also useful directly when a session has produced several unrelated changes that should not land as one commit.

This skill should be used whenever Claude is about to run `git commit`, `git push`, `git rebase`, `git reset`, `git cherry-pick`, or `gh pr create` — and when the user asks to "commit this", "write a commit message", "split these changes", "squash my commits", "clean up the history", "rebase onto main", "amend", "undo that commit", "open a PR", "push this branch", "fix the merge conflict", "I committed a secret", or "I lost my work". Provides the atomicity test for splitting a working tree, C...

Use when reshaping a branch's existing commits into a legible sequence before review — auditing commits against their base, deciding what may be rewritten based on what has been published, executing squashes, reorders, rewords, and splits without interactive rebase, and proving the rewrite changed no code via a tree-identity check. Invoked by /git-workflow:tidy-history.

GraphQL API design guidance and HotChocolate implementation patterns. Use whenever designing, building, implementing, or reviewing GraphQL schemas, queries, mutations, subscriptions, types, or API surface.

MediatR guidance for in-process messaging in .NET. Use whenever implementing request/response dispatching, notification publishing, pipeline behaviors, or any use of the MediatR library.

This skill should be used when the user asks to "refactor" code, "clean up" code, "find code smells", "improve code quality", "simplify this method/class/module", "restructure" existing code, mentions "technical debt", says a function or class is "too long" or "too complicated", asks "is this code well designed?" or "does this need refactoring?", or when modifying existing code whose structure resists the change being made. Provides smell detection heuristics, a smell-to-refactoring index, an...

Use when turning a described behavior — a JIRA ticket, a GitHub PR or issue, a spec document, or free-form text — into a structured, testable behavior specification before any test is planned or written. Produces numbered behaviors in Given/When/Then anchored to quotes from the source, plus an explicit register of what the description leaves unspecified. Invoked by /test-write; also useful on its own when acceptance criteria need to be pinned down before work starts.

Use when checking whether code that was written or pushed actually does what its description said — comparing a PR, branch, or commit range against the ticket, issue, or acceptance criteria that specified it, and returning a per-behavior verdict with code citations rather than a test suite. Answers "does this PR still match the ticket." Invoked by /spec-conformance; distinct from /test-review, which audits test quality, and /test-write, which writes tests for a description.

Use when auditing written tests back against the behavior specification and test plan that produced them — checking traceability in both directions, running the full suite, classifying every failure as a spec/code mismatch versus a test defect versus an environment problem, and reporting which described behaviors appear unimplemented. Invoked by /test-write as the final phase.

Use when implementing an approved test plan — building shared test scaffolding before fanning out, dispatching parallel authoring agents over disjoint files, requiring executed-and-observed-red evidence rather than claims of verification, and running an adversarial review of the resulting test code for simplicity, maintainability, and conformance with the existing suite. Invoked by /test-write after plan approval.

Use when assessing a whole repository's test suite rather than specific test files — finding where protection is weakest, diagnosing systemic problems across the suite, ranking modules by risk against the strength of their tests, and producing a map that says where to spend test effort next. Invoked by /test-audit. For per-test defects in a known set of files, use /test-review instead.

Use when turning a behavior specification and codebase recon into an approved test plan — choosing test cases and coverage depth per behavior, picking the right scope (unit, integration, contract, schema, property, UI, E2E), justifying every choice, running an adversarial critique of the plan, and reviewing it with the user before any test is written. Invoked by /test-write between extraction and authoring.

This skill should be used whenever writing, reviewing, or fixing tests — when the user asks to "write tests", "add tests for X", "test this function/class", "improve test coverage", "review my tests", "why is this test flaky", "should I mock this", "how do I test X", mentions TDD or characterization tests, asks how to test code that has no tests or seems untestable, or when Claude has just written production code and is about to add tests for it. Provides test-design fundamentals, a test-doub...