All authors
Claude Skills by iamakbarsha1
github.com/iamakbarsha125 skills0 installs52 views
- A Memory Is Not A TriggerUse when you're relying on a stored memory, a recalled note, an injected session-start banner, or a description-matched skill to make a required action happen every session or run — especially a recurring logging, bookkeeping, or guardrail step. Passive context is advisory: the agent reads it and can still skip the action. If it must happen every time, gate it with a deterministic mechanism (a hook that executes it, an always-loaded forced invocation), not a note you hope gets recalled. Trigg...Votes: 0GitHub stars: 4
- Audit Before You BuildUse as the FIRST step of any implementation task handed to you from a checklist, ticket, milestone, or spec — the first step is an existence check, not a design. Trackers record conversations, not deliverables, so grep for the item's key nouns and cross-check spec status before writing code, then pivot "build X" to "verify X and close the gaps" when it already exists. Triggers on "implement this ticket", "build feature X", "next milestone item", "from the checklist", "start this task", "add X".Votes: 0GitHub stars: 4
- Confirm The Premise FirstUse during design or brainstorming when a user's choice depends on a technical property they assert or imply — state the ground truth of that property before asking downstream questions built on it. Triggers on "should we use X or Y", design trade-off discussions, privacy/data-egress decisions, and any choice that hinges on local-vs-remote, free-vs-paid, sync-vs-async, or reversible-vs-not.Votes: 0GitHub stars: 4
- Consistency Is Local FirstUse before writing new code in an existing module — match the nearest sibling's pattern first; a repo-wide convention is the default only when the local module has no established pattern of its own. A uniform module beats a globally-conformant outlier. Triggers on "follow the conventions", "match the style", "how do we do X here", "the standard is", "add a new component/form/endpoint", and starting new code beside existing code.Votes: 0GitHub stars: 4
- Diff Each Side Against Merge BaseUse when resolving a merge or rebase conflict, or reviewing a merge commit — conflict markers show where git gave up, not the full semantic delta, and 3-way auto-merge silently drops fields outside the markers. Compare ours/theirs/base by symbol and field inventory before trusting the result. Triggers on "merge conflict", "resolve conflict", "rebase", "git merge", "auto-merge", "cherry-pick", and reviewing a large merge diff.Votes: 0GitHub stars: 4
- Distill The ScarUse when you just hit a real failure worth keeping — a bug, a wrong fix, a wasted hour — and want to turn it into a reusable skill instead of a private lesson. Turns one concrete failure into a Whetstone-shaped SKILL.md: extract the transferable invariant, write it so an agent can apply it without the original context, and gate it with the validator. Triggers on "make this a skill", "turn this into a rule", "capture this lesson", "distill this failure", "add a skill for this", "postmortem int...Votes: 0GitHub stars: 4
- Findings List Is Not A Todo ListUse when re-engaged to "act on" or "fix the rest of" a review, audit, or recommendation list — the list is not a to-do list. Re-read each item's own disposition first and bucket them; some are explicitly marked no-fix, some need a human decision, some are scale-gated. Triggers on "fix the findings", "address the review", "do the rest of the recommendations", "apply the audit", "action these items", and acting on any list you or someone else produced earlier.Votes: 0GitHub stars: 4
- Grep The Blast RadiusUse when changing a shared contract — a flag, column, enum/union member, shared type, exported symbol, endpoint shape, or config key. The retired name is the cheapest complete index of consumers: grep the whole workspace and run every suite that crosses the boundary, not just the package you edited. Triggers on "rename", "change this type", "add/remove a field", "change the API shape", "update shared config", "who uses this", "will this break anything", and editing any code imported by more t...Votes: 0GitHub stars: 4
- Inject Ambient InputsUse when writing or refactoring logic that reads ambient state — the clock (now/today), randomness, environment variables, a DB/HTTP handle, the filesystem, the current user. Ambient reads are the main reason otherwise pure logic becomes un-unit-testable; pass them in as parameters and split the pure decision from the I/O so tests need no mocking machinery. Triggers on "Date.now", "new Date()", "hard to test", "mock the clock", "fake timers", "random in tests", "reads env", "make this testabl...Votes: 0GitHub stars: 4
- Know Your Aggregate Command ScopeUse before trusting a named aggregate command — a `test`, `lint`, `type-check`, or `build` script that wraps a tool. Open it and confirm what it actually runs, how it forwards args, and whether it caches, because a green only means what the command covered. Triggers on "npm run test", "type-check passes", "lint is clean", "the build is green", "run the tests", "--testPathPattern", monorepo/workspace scripts, and citing a script's exit code as proof.Votes: 0GitHub stars: 4
- Manufacture Review IndependenceUse when reviewing your own work, or when the author-equals-reviewer guard is deliberately overridden — real independence is gone, so manufacture it: parallel independently-scoped sub-reviews plus an adversarial re-read of source for every high-severity claim, and treat cross-reviewer disagreement as a pointer to the boundary file that settles it. Triggers on "self-review", "review my own PR", "author is the reviewer", "no one else can review", "code review my changes", and conflicting review...Votes: 0GitHub stars: 4
- Measure The Delta Not The AbsoluteUse when judging whether your change is clean against a red or noisy baseline — failing tests you didn't touch, pre-existing lint/typecheck errors, flaky CI. Innocence is a claim about a delta, so prove it by stash-and-compare or head-vs-base under an identical harness, never by reading which files appear in the failure list. Triggers on "is this failure mine", "pre-existing failures", "red baseline", "did my change break this", "CI was already failing", "flaky", and before blaming or clearin...Votes: 0GitHub stars: 4
- Negative Invariant TestingUse when a system has a load-bearing "never" constraint — never holds funds, never logs secrets, never calls a forbidden API, never writes to a table, never blocks the event loop. Behavioural tests can't observe a capability that isn't exercised yet, so write a STRUCTURAL test that trips on the mere existence of the forbidden mechanism. Triggers on "never does X", "must not", "forbidden", "invariant", "safety constraint", "guardrail", "should not be possible", and hardening a property a futur...Votes: 0GitHub stars: 4
- Plan Cross Encoding ReviewUse when reviewing an implementation plan, spec, or task breakdown before handing it to an implementer — catches the class of bug where one intent is encoded twice and the two encodings silently disagree. Triggers on "review this plan", "check this spec", "self-review the plan", "before I implement", "fixture values", "edge case in the plan", and writing task breakdowns with hardcoded fixtures or guards.Votes: 0GitHub stars: 4
- Prove The Test Can FailUse after writing a test, or before trusting one that passed — a test that has never failed is unverified. Do one sabotage run (break the thing under test, confirm the right assertion fails) and confirm each new branch is actually reachable by the mocks/fixtures. Triggers on "test passes", "added a test", "green on first run", "after-the-fact test", "is this test real", "mock", "coverage", and before claiming a behaviour is tested.Votes: 0GitHub stars: 4
- Publish Oss RepoUse when preparing a repository for public release, or auditing one that already has working code but still reads as neglected to a stranger or to GitHub's own UI — "has the files" is not "reads as maintained". Triggers on "publish a repo", "open source this", "release", "make it look maintained", "license shows Other", "add topics", "GitHub release", "repo badges".Votes: 0GitHub stars: 4
- Read The Real Failing CallUse when hardening against a failure mode or fixing an intermittent/partial failure — instrument the real failing invocation before and after, because a plausible hypothesis is not a diagnosis. Triggers on "why is this failing", "flaky", "intermittent failures", "high failure rate", "harden this", "add retries", "it times out sometimes", and diagnosing a fix that didn't move the failure rate.Votes: 0GitHub stars: 4
- Running Long Background JobsUse before launching any long-running, backgrounded, detached, or nohup'd process (backfills, batch migrations, bulk data processing, multi-hour scrapes, crawls), and again when verifying it finished correctly. Also use when reconciling a batch job against a corpus (files, DB rows, records) that other processes — event hooks, cron, other agents — also write to during the run. Triggers on "background job", "long-running job", "detached process", "backfill", "batch job", "nohup", "disown", "una...Votes: 0GitHub stars: 4
- Safe Data ExportUse when a task's output is sensitive or large data and the destination is a path inside a version-controlled tree — writing the data is not the finish line, an unreviewed commit of it is the failure mode. Triggers on "export the data", "dump the DB", "extract observations", "write it to the repo", "save the logs", "migrate memory", and whenever the destination path resolves inside a git working tree.Votes: 0GitHub stars: 4
- Scan Generated Files For ArtifactsUse when reviewing or signing off on a file an agent produced with a write tool — a doc, README, config, data file, or any non-code output. Passing tests prove nothing about stray harness framing: a leaked closing tag, an XML/markdown-fence fragment, or content past the intended EOF compiles and tests clean, then ships as visible garbage. Grep every agent-written file's head and tail for tool residue before you approve it. Triggers on "review my changes", "code review", "generated file", "wro...Votes: 0GitHub stars: 4
- Test Fixture RealismUse when writing tests against a shared store or with fabricated fixtures — a test only proves something if its fixtures mirror data reality and its assertions can't pass trivially. Covers asserting on rows you created (not aggregate counts), real referential integrity, seeded randomness and pinned time, fail-closed guard fixtures, and mocks that quietly load the real module. Triggers on "test fixtures", "seed data", "test DB", "factory", "mock returns", "flaky test", "assert count", "foreign...Votes: 0GitHub stars: 4
- Validate The Users Proposed MechanismUse when a user specifies a platform, tool, library, or approach as part of a request — their choice is a proposed MECHANISM, not a spec. Grep the built artifact for disqualifying signals before agreeing, separate their intent from the mechanism, and satisfy the intent with a feasible mechanism when the chosen one conflicts. Triggers on "deploy on X", "use library Y", "run it on Z", "switch to", "let's use", and any user-named tech that the existing code may not fit.Votes: 0GitHub stars: 4
- Verify Absence ClaimsUse when you're about to act on a "there is no X / none exists / not found / nothing handles this" claim — especially one from a delegated subagent, research handoff, or a teammate's summary. Positive file:line claims are citable and checkable; absence claims are only as good as the search pattern that produced them. Re-grep every "X does not exist" before building on it. Triggers on "no existing", "none found", "there's no", "doesn't exist", "nothing does X", research/subagent handoffs, and ...Votes: 0GitHub stars: 4
- Verify Through The Real PathUse before claiming something works, is done, is safe, or is fast — verify through the actual trigger, real data, and representative conditions, not a convenient stand-in. Triggers on "verify", "confirm it works", "is it done", "benchmark", "ETA for a long run", "is this edge case reachable", "test the hook", "smoke test", and before declaring a fix complete.Votes: 0GitHub stars: 4
- Spike FalsificationUse when validating a third-party dependency — an API, SDK, contract, or protocol — before designing on top of it, especially onchain/smart-contract dependencies. Triggers on "spike this integration", "validate this contract/SDK before we build on it", "is this really soulbound / non-transferable / read-only", "prove the API behaves like the docs say", "fork the network and test against the deployed contract", or any request to de-risk a dependency before committing to a design.Votes: 0GitHub stars: 4