All authors
Claude Skills by okgrit
github.com/okgrit15 skills0 installs0 views
- Acceptance DesignDefine executable acceptance for a bounded task before work or dispatch. Use when writing a worker brief, selecting success checks, or repairing an acceptance contract that cannot test the intended outcome.Votes: 0GitHub stars: 33
- Checking DeliveryVerify an artifact at its actual delivery destination and distinguish send attempts, acknowledgements, publication and consumer checks. Use when reporting a file, message, export or deployment as delivered; creating a local draft alone does not imply delivery.Votes: 0GitHub stars: 33
- Collecting Worker ResultsInspect a stopped worker's returned work and evidence before accepting it, retrying it or handing it to an integration owner. Use when a worker finishes, records disagree, or a green result has no visible change. Collection does not authorize merging.Votes: 0GitHub stars: 33
- Debugging With EvidenceDiagnose unexpected behavior with a reproduction, competing explanations and experiments that separate them before fixing. Use for bugs, failed checks or repeated unsuccessful fixes; attribute branch failures only with suitable comparison evidence.Votes: 0GitHub stars: 33
- Evidence FreshnessBind a check or action to the input snapshot it actually used. Use before relying on cached verification, consuming a reviewed batch, acting while inputs may change, or retrying an operation with an ambiguous result.Votes: 0GitHub stars: 33
- Executing PlansCarry an actionable change plan through implementation, checks, review and an evidence-backed report. Use when executing several planned steps or integrating bounded worker returns, within existing authorization.Votes: 0GitHub stars: 33
- Implementing With TestsImplement runtime behavior changes and bug fixes with meaningful before-and-after checks, preserved behavior and relevant regression evidence. Use while editing code; prose-only changes do not need a failing test.Votes: 0GitHub stars: 33
- Planning ChangesPrepare a compact, executable plan for a substantial change with acceptance, file ownership, dependencies and expected observations. Use when several steps or collaborators need coordination; tiny clear edits can proceed directly.Votes: 0GitHub stars: 33
- Public ClaimsWrite and fact-check public copy so that every figure, credential, promise and command has a receipt - a source with a locator, a command that re-derives it, or the author's own words - and remove any claim without one instead of softening it. Use when drafting or reviewing a README, release notes, a launch post or thread, slides, or a website page; and whenever a draft states a number, a ranking, a credential, a promised result or a command.Votes: 0GitHub stars: 33
- Reading MeasurementsRead a number without being fooled by it: an exit code, a passing result file, a test count, a list size, a control run, a red or a green. Use before reporting any figure, before turning a test run into a verdict, before acting on 'N items are broken', and whenever two outputs or two counts of the same thing disagree.Votes: 0GitHub stars: 33
- Responding To ReviewResolve incoming code-review feedback against the current revision and user contract. Use to assess comments, implement authorized fixes, explain supported disagreement and verify item status; review does not authorize posting replies.Votes: 0GitHub stars: 33
- Resuming WorkResume a saved task after a session, context or machine change by checking its checkpoint, artifacts and current ownership. Use when receiving unfinished work or reconciling a stop; ordinary uninterrupted edits do not need a handoff.Votes: 0GitHub stars: 33
- Reviewing ChangesReview an actual candidate against the user's acceptance and scope, then carry findings through fixes, affected checks and rereview. Use before claiming a substantive change complete or accepting a worker's implementation.Votes: 0GitHub stars: 33
- Using Done Is A ClaimChoose an evidence-first path for a development task, from acceptance through execution, review and completion. Use when starting substantive work or deciding the next step; clear tiny edits can proceed directly.Votes: 0GitHub stars: 33
- Whose RedInvestigate whether a failing test run is caused by a change, was already broken on main, or is inconclusive, using matched branch and clean-main runs. Use when tests fail on a branch or PR, when an agent says 'this failure is pre-existing', or before retrying or reverting a fix.Votes: 0GitHub stars: 33