All authors

Claude Skills by zoolok17
github.com/zoolok1727 skills0 installs25 views
- Agenttalk ChallengeBefore major work starts, ask an independent agent whether it should be done at all. Send a blind brief (outcome, trigger, size - never the pitch), get a typed verdict (proceed / reshape / probe / replace / defer / stop / unassessed), and record what you did with it. Use before dispatching, proposing or starting major work, whoever asked for it.Votes: 0GitHub stars: 13
- Agenttalk ConsultConfer with a named agent BEFORE answering the user. Send your draft answer + uncertainty, wait for critique, then write a concise final answer that names where you agree/disagree and makes a recommendation. Use for high-impact ambiguous calls and explicit second-opinion requests.Votes: 0GitHub stars: 13
- Agenttalk HandoffSend a structured handoff, typically a review request, to a named agent and block until the reply arrives. Works for mission/work-item-tagged reviews and ad-hoc cross-reviews; the receiver mode-detects from meta.Votes: 0GitHub stars: 13
- Agenttalk LeadCoordinate a named multi-agent team over agenttalk as a lead. Use when Codex should decompose work, dispatch to named agents or groups, track replies with threads, and report back without spawning worker processes.Votes: 0GitHub stars: 13
- Agenttalk ListenEnter listen mode as a Codex agent - repeatedly wait for messages from named agents and handle reviews, proposals, broadcast questions, consults, wake signals, or cross-review requests.Votes: 0GitHub stars: 13
- Agenttalk ProposeSend a concrete proposal to a named agent over agenttalk and wait for an accept, reject, or counter response. Use when Codex should propose a specific design, plan, scope, or decision for agreement before proceeding.Votes: 0GitHub stars: 13
- Agenttalk SendSend a single message to a named agent, or broadcast a note/question to a group, over agenttalk. Use when the request does not require waiting for a reply. Requires `python -m agenttalk init` in the project root.Votes: 0GitHub stars: 13
- SharedShared reference material for the devkit skills (the canonical evidence profiles, the routing index and the plain-language voice). This is NOT an invocable capability skill - do not run it; the other devkit skills link to its references/ files.Votes: 0GitHub stars: 13
- Assurance ScanProduce codebase-adaptive assurance scan evidence for release gates, milestone closes, security reviews, and release readiness. Use when Codex needs to detect a repo stack, run applicable installed quality, security, dependency, packaging, encoding, and hygiene checks, emit a normalized JSON artifact, or feed ASSURANCE.md. This skill is an evidence producer, not a gate approver. Do NOT use to decide GO/HOLD, approve a release, auto-install scanners, or run network scans by default.Votes: 0GitHub stars: 13
- Craft CodeWrite the smallest, simplest, most readable correct change that matches the surrounding codebase. Use when implementing a feature, fixing a bug, refactoring production code, writing interface text (labels, buttons, empty states, error messages, tooltips), or adding, fixing or rewording only code comments. Do NOT use for writing tests (use test-coverage), reviewing an existing diff (use review-code), or documentation (use write-docs).Votes: 0GitHub stars: 13
- Fix CiDiagnose and fix a failing local or CI check by reading the failing command and logs first, classifying the root cause, applying or proposing the smallest fix, and verifying the result. Use when a concrete test, lint, build, security, or CI job is red. Do NOT use for general feature work, broad cleanup after CI is green, or guessing at failures without logs.Votes: 0GitHub stars: 13
- Qa StrategyPlan the QA strategy for a change: identify risk areas, recommend test levels and review lenses, state which checks are not needed and why, include cost notes, and identify required close evidence. Use when deciding which tests/checks/lenses are necessary before implementation, review, or release gating. Do NOT use for writing tests directly or replacing test-coverage.Votes: 0GitHub stars: 13
- Refactor CodeRestructure existing production code while preserving behavior: simplify boundaries, reduce duplication, improve names/layout, extract or inline abstractions, and make code easier to maintain without changing the observable contract. Use when Codex is asked for behavior-preserving cleanup, internal restructuring, simplification, or refactoring after scope is clear. Do NOT use for feature work, bug fixes or product changes that alter behavior (use craft-code), writing tests directly as the pri...Votes: 0GitHub stars: 13
- Review CodeReview a code diff for code health in priority order, grounding every finding in the actual code and severity-tagging each one. Use when asked to review a PR/diff/change or to self-review code before merging. Do NOT use for writing new code (use craft-code), reviewing documentation (use review-docs), or general code questions unrelated to a specific diff.Votes: 0GitHub stars: 13
- Review Contract DriftReview a change that retires, renames, or alters a CONTRACT (schema, config/settings key, public API, serialized format, renderer/output, CLI flag) for parity across all the places that must move together — code, tests, docs, migrations, and callers. Use when a feature/field/flag is removed, renamed, defaulted differently, or its shape changes. Do NOT use for new-feature review (use review-code), pure failure-path review (use review-failure-injection), or release packaging (use review-release...Votes: 0GitHub stars: 13
- Review DocsAdversarially review documentation: verify every claim against the current code, run the examples, and check it serves its reader. Use when reviewing a README, guide, reference, or doc change, or after a code change that touched user-facing docs. Do NOT use for writing/updating docs (use write-docs) or reviewing code logic (use review-code).Votes: 0GitHub stars: 13
- Review Failure InjectionAdversarially review a change for how it behaves when things go WRONG — malformed input, IO/network errors, partial writes, resource exhaustion, and teardown. Use when reviewing parsers, file/IO, persistence, untrusted input, long-running or resource-holding code, or any error/failure path. Do NOT use for general code health (use review-code), documentation (use review-docs), contract/rename parity (use review-contract-drift), or release packaging (use review-release-readiness).Votes: 0GitHub stars: 13
- Review Release ReadinessReview whether a change (or a tag/release candidate) is SAFE TO RELEASE and conclude HOLD or GO — CI triggers, build artifacts, manifests/permissions, package type, version/docs/changelog drift, and barrier/gate readiness. Use before a release, tag, publish, deploy, or milestone close. Do NOT use for ordinary diff review (use review-code), failure paths (use review-failure-injection), or contract parity (use review-contract-drift).Votes: 0GitHub stars: 13
- System Review ProtocolRun a MILESTONE or FULL-REPO adversarial review and drive it to a HOLD/GO close. Use ONLY when explicitly asked to run a system/milestone/release review or to open and drive an `agenttalk close` across multiple review lenses. Do NOT use for a single PR/diff review (use review-code or a specific review-* lens), an implementation handoff (use agenttalk-handoff), team routing (use agenttalk-lead), or anything that is not a multi-lens close. This skill ORCHESTRATES the existing `agenttalk close` ...Votes: 0GitHub stars: 13
- Test CoverageCover every applicable behavior with deterministic, behavior-focused tests, including a failing-first regression test for any bug fix. Use when writing or strengthening tests, right after implementing/fixing code, or when asked whether a change is "fully tested". Do NOT use to chase a coverage percentage as a goal, or to write production code (use craft-code).Votes: 0GitHub stars: 13
- Test DocsProduce executable documentation-check evidence by running docs examples, doctests, link checks, command snippets, generated-reference drift checks, and code-vs-doc assertions. Use when documentation needs QA evidence for commands or generated content actually executed. Do NOT use for writing docs (use write-docs), adversarial documentation accuracy, audience, or prose review (use review-docs), integrated code review, or green claims based only on reading documentation.Votes: 0GitHub stars: 13
- Test IntegrationValidate behavior across real integration boundaries such as CLI plus store, filesystem behavior, config loading, migrations, multiple modules, or process/supervisor interactions. Use when confidence depends on exercising a real boundary with isolated temp roots and deterministic commands. Do NOT use for pure-function or low-level behavior tests where test-coverage is enough, full user journeys that require unstable sleeps or external services, fixing an already-failing check (use fix-ci), pr...Votes: 0GitHub stars: 13
- Test PerformanceProduce executed performance-testing evidence for a concrete workload, budget, baseline, or suspected regression. Use when performance is a risk, a regression is suspected, or a close needs benchmark evidence with workload, dataset, environment, warmup, repetitions, variance policy, threshold, commands, artifacts, and residual risk. Do NOT use for speculative optimization, product implementation, architecture review, or performance tuning without measured evidence; route production changes to...Votes: 0GitHub stars: 13
- Test SecurityProduce executable security-testing and abuse-case evidence for a touched surface. Use when a change needs threat-model-backed tests or checks for authz, input validation, injection, path/env/command handling, unsafe deserialization, secrets/log hygiene, dependency or supply-chain exposure, or abuse cases. Do NOT use as a second review-code security pass, for general code review, for speculative vulnerability hunting without scoped tests, or for production fixes without an assigned implementa...Votes: 0GitHub stars: 13
- Tester QaAct as a first-class QA/tester persona — design, write, RUN, and triage tests for a change, and report what was ACTUALLY executed versus merely referenced. Use when asked to QA/test a change, produce test evidence for a close, or serve as the tester lens in a review. Do NOT use to chase a coverage percentage or mandate production tests (use test-coverage), to review code health (use review-code), or to write product code. This is an evidence-producing workflow, not a coverage rubric.Votes: 0GitHub stars: 13
- Write DocsWrite or update documentation as a first-class artifact — one Diataxis mode per page, audience named, examples of current behavior runnable, zero drift from the code, in the shared plain-language voice. Use when writing or updating a README, guide, reference, manual, specification, design document, or any user-facing doc, or when a code change alters how users build/configure/call the software. Do NOT use for inline code comments (use craft-code) or for reviewing existing docs (use review-docs).Votes: 0GitHub stars: 13
- Write For HumansWrite release notes, changelog entries, pull request descriptions, issue and review comments, and status reports so that someone who does not program understands what changed, why it matters and what they will notice. Same facts, explained in plain words, with the technical detail moved to the end. Use only for those kinds of text. Do NOT use for answering questions, plans or design discussions, for code comments (use craft-code), for reference, tutorial or how-to documentation pages (use wri...Votes: 0GitHub stars: 13