All authors
Claude Skills by theonly1me
github.com/theonly1me17 skills0 installs0 views
- Choose By ConsequenceUse when code must decide what happens on an unusual or failing path. Also use it when the user says "just handle that case", "skip it if it fails", or "is this the best way?". Compares the easy route with each alternative by what it does to the user''s files, data, and output. Picks the option that fails loudly and keeps every count and exit code true. Never writes through a file that the change does not own. Not for checking finished work against the real command output (use `verify-and-rev...Votes: 0GitHub stars: 9
- Design Deep ModulesUse when designing or reshaping a module, or when callers coordinate too many steps. Also use it when the user says "this is hard to test", "callers know too much", or "simplify this interface". Puts related state and decisions behind a small interface that states what the caller wants. Tests then use that interface instead of the internal steps. Not for typing values at a boundary (use `typescript-type-safety`).Votes: 0GitHub stars: 9
- Diagnose Before EditingUse when behavior fails, flakes, or slows down, and nobody knows the cause yet. Also use it when the user says "why does this fail?", "it worked yesterday", or "this got slow". Reproduces the failure, makes it smaller, and tests one cause at a time until one cause predicts the symptom. Then fixes the cause at its origin, not the symptom. Not for scoping a fix whose cause you already know (use `scope-confirmed-changes`).Votes: 0GitHub stars: 9
- Plan With Review PageUse before a change that touches many files, needs many steps, or has open design choices. Also use it when the user says "plan this first", "what is your approach?", or "do not code yet". Explores the code read-only, asks one round of decisions with the recommended option first, and writes one plan. Builds a self-contained HTML review page from a template, and checks the page with a validator. Not for checking finished work (use `verify-and-review`).Votes: 0GitHub stars: 9
- Research Primary SourcesUse when a decision depends on how a library, platform, protocol, or tool behaves, and that behavior can change by version. Also use it when the user says "check the docs", "is this still true?", or "what does the spec say?". Finds the first-party source for the installed version and reads it. Separates what the source guarantees from what you infer. Not for debugging a failure in your own code (use `diagnose-before-editing`).Votes: 0GitHub stars: 9
- Resolve Conflicts By IntentUse when Git reports conflicts during a merge, a rebase, or a cherry-pick. Also use it when the user says "fix the merge conflicts", "rebase onto main", or "the merge broke the build". Traces each side of a conflict to the change that it came from. Keeps both intents when they fit together, and asks when they do not. Then runs the checks on the combined result. Not for choosing what a new behavior should be (use `choose-by-consequence`).Votes: 0GitHub stars: 9
- Scope Confirmed ChangesUse when fixing a bug, a regression, or a confirmed review finding. Also use it when the user says "fix this bug", "it is broken", or "keep the change small". Reproduces the issue before any fix, with a test, a real command, or the real interface. After the fix, the same reproduction must pass. Keeps the change to confirmed, reachable behavior. Not for checking review comments before a fix (use `verify-review-findings`).Votes: 0GitHub stars: 9
- Shadowclone Build PreferencesRead before acting for the selected working preferences.Votes: 0GitHub stars: 9
- Shadowclone ReviewUse when the user asks for a review of a pull request, or when a review packet from `shadowclone review` arrives. Also use it when the user says "review PR 123", "find bugs in this pull request", or "is this PR safe to merge?". Runs a strict adversarial review for correctness, security, performance, reliability, and compatibility. Each claim quotes its evidence, a fresh refuter tests each finding, and code drops any finding whose quote does not match. Not for checking review comments that som...Votes: 0GitHub stars: 9
- Shadowclone WorkUse when the user asks to implement a change and open a pull request, or to get a pull request ready to merge. Also use it when the user says "fix the red PR", "address the review comments", or "restack my PRs". Covers CI failures and flakes, bot and human review threads, conflicts with a moving base, and stack restacks. Takes the work to a pull request that is ready for review, and keeps it there without merging. Not for checking review comments before you act on them (use `verify-review-fin...Votes: 0GitHub stars: 9
- Tests That Catch BugsUse when adding, changing, or reviewing tests. Also use it when the user says "add a regression test", "write the test first", or "make sure this cannot break again". Writes a few tests that each name a bug and check the result where the user sees it. Expected values come from an independent source, and each test fails without the change. Test first is an ordering choice inside this skill. Not for checking finished work against the real command output (use `verify-and-review`).Votes: 0GitHub stars: 9
- Typescript Type SafetyUse when changing TypeScript types, parsing input that enters typed code, or removing unsafe casts. Also use it when the user says "fix the types", "remove the as casts", or "make invalid states impossible". Models each valid state with types, so that invalid combinations fail to compile. Checks outside input with a type guard or a schema instead of an assertion. Not for designing module boundaries (use `design-deep-modules`).Votes: 0GitHub stars: 9
- Verify And ReviewUse before you say that work is done, fixed, or ready for review. Also use it when the user says "make sure it works", "verify this", or "is it ready?". Runs the command or page that the user will use, and reads every count, status line, and exit code. Reviews the whole diff, and labels each claim as measured, inferred, or not verified. This catches a wrong count or a buried warning before handoff. Not for writing or proving tests (use `tests-that-catch-bugs`).Votes: 0GitHub stars: 9
- Write Plain EnglishUse when writing or editing prose that people read, such as documents, pull requests, commit messages, review comments, chat replies, or skills. Also use it when the user says "make this clearer", "simplify the wording", or "this is a wall of text". Rewrites the text in plain technical English, with one idea in each sentence and no dashes. Then runs a checker that reports long sentences and dashes. Not for checking code behavior (use `verify-and-review`).Votes: 0GitHub stars: 9
- Data HandlingRead before changing capture, indexing, redaction, learning, profiles, skill publication, engine execution, or any path that stores or sends user data.Votes: 0GitHub stars: 9
- Setup ShadowcloneInstall and configure Shadowclone for the user from start to finish. Use it when the user asks to "set up", install, configure, or start Shadowclone with Claude Code, Codex, Cursor, Pi, Antigravity, or another coding agent.Votes: 0GitHub stars: 9
- Verify Review FindingsUse when a pull request has review comments or bot findings to check. Also use it when the user says "are these comments right?", "triage the review", or "check what the bot found". Checks each finding against the code at the head of the pull request, and confirms the file, the line, and the claim. Asks what each suggested fix would break, reports a verdict for each finding, and waits. Not for writing the fix (use `scope-confirmed-changes`).Votes: 0GitHub stars: 9