iamakbarsha1
- 25 skills
- 0 followers
- 17 hours ago last updated
- ▌ Distill The Scar · iamakbarsha1Use 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 into a skill", and any moment you catch yourself saying "I'll remember this next time."
- ▌ Publish Oss Repo · iamakbarsha1Use 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".
- ▌ Safe Data Export · iamakbarsha1Use 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.
- ▌ Spike Falsification · iamakbarsha1Use 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.
- ▌ Test Fixture Realism · iamakbarsha1Use 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 key in test", "automock", and building any non-trivial test's setup.
- ▌ Grep The Blast Radius · iamakbarsha1Use 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 than one module.
- ▌ Inject Ambient Inputs · iamakbarsha1Use 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 testable", "pure function".
- ▌ Verify Absence Claims · iamakbarsha1Use 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 any negative finding you didn't verify yourself.
- ▌ Audit Before You Build · iamakbarsha1Use 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".
- ▌ Prove The Test Can Fail · iamakbarsha1Use 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.
- ▌ A Memory Is Not A Trigger · iamakbarsha1Use 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. Triggers on "remember to do X every session", "add a memory so it always…", "why didn't it log / run / update", "it was in the instructions but didn't happen", mandatory recurring steps, and any moment you catch yourself trusting recall to fire a must-do.
- ▌ Confirm The Premise First · iamakbarsha1Use 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.
- ▌ Consistency Is Local First · iamakbarsha1Use 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.
- ▌ Negative Invariant Testing · iamakbarsha1Use 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 future edit could quietly violate.
- ▌ Plan Cross Encoding Review · iamakbarsha1Use 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.
- ▌ Read The Real Failing Call · iamakbarsha1Use 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.
- ▌ Running Long Background Jobs · iamakbarsha1Use 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", "unattended run", "overnight job".
- ▌ Verify Through The Real Path · iamakbarsha1Use 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.
- ▌ Manufacture Review Independence · iamakbarsha1Use 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 findings.
- ▌ Findings List Is Not A Todo List · iamakbarsha1Use 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.
- ▌ Diff Each Side Against Merge Base · iamakbarsha1Use 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.
- ▌ Know Your Aggregate Command Scope · iamakbarsha1Use 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.
- ▌ Measure The Delta Not The Absolute · iamakbarsha1Use 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 clearing a diff on a noisy suite.
- ▌ Scan Generated Files For Artifacts · iamakbarsha1Use 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", "wrote a doc", "wrote a README", "tool artifact", "stray tag", "harness residue", "content past EOF".
- ▌ Validate The Users Proposed Mechanism · iamakbarsha1Use 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.