All authors
Claude Skills by StepenkoAnatoli
github.com/StepenkoAnatoli25 skills0 installs0 views
- SkillMakes research a blocking phase before any bot or project is designed or built. Use when the user says "build me a bot", "make a project", "can you build X", when starting a new repository or feature whose design depends on external facts (APIs, pricing, limits, schemas, platform rules), or whenever the honest answer would be "I don't have enough information yet". Produces a Discovery Contract with primary sources and a preflight gate instead of guessing, and enforces a question budget so int...Votes: 0GitHub stars: 2
- Adr WriterRecords an architecture decision record whenever a design choice set an alternative aside - context, the decision, each rejected alternative with the reason a future reader needs to avoid re-suggesting it, and a dated trigger that would reopen it - and adds it to the ADR index. Use when a choice about behaviour, a format, a rule, a module's responsibility or a deferral had a credible alternative, when the user says "record this decision" or "write an ADR", or when a decision supersedes an old...Votes: 0GitHub stars: 2
- Architecture PassRun a local Architecture pass on the code that just changed — read the diff as a design, decide which concerns deserve their own module, who owns each piece of state, and which way data flows, then restructure the changed code to match without changing behavior, verify it, and record the result. Use whenever the user says architecture pass, structure the diff, clean up the structure of this change, make the changed code well-structured, tidy the shape of this feature, or has just finished a f...Votes: 0GitHub stars: 2
- Auto BuildTake a task from idea to a reviewed pull request and an owner-approved merge. Researches external facts through Fetchproof, writes traceable requirements, presents the Mandate for design approval, builds with lead-orchestrator, hardens with break-test and audits with gap-audit. Inside a Fetchproof project, references/fetchproof.md governs owner stops and a separate approval of the completed head; an early GO MERGE or standing preference cannot approve a future commit. Use for "auto-build", "b...Votes: 0GitHub stars: 2
- BrainstormingTurn a request into a design the user has approved before any implementation, or review existing work with fresh eyes for better ideas. Use this before creating features, building components, adding functionality, modifying behavior, or starting a new project — including tasks that look too small to need it. Also use it when asked to review a diff or change for improvement ideas, or when the user asked for something to be built, left its shape open, and wants it made meaningfully better. Cove...Votes: 0GitHub stars: 2
- Break TestAdversarially probe a project for realistic build and test failures (clean-checkout builds, lockfile and dependency drift, stale generated code, missing env vars, toolchain mismatches, order-dependent or flaky tests, races, timezone and locale assumptions, offline installs, permissions, resource limits), prove each one with a repro command, then apply minimal fixes as separate commits, keeping only fixes that demonstrably remove the failure and keep the build green. Use whenever the user asks...Votes: 0GitHub stars: 2
- Brief WriterFinishes a Fetchproof project's handoff - drafts research/BRIEF.md with brief.mjs, answers the two sections the corpus cannot fill (Contradictions, Decision with a concrete first build step and what is out of scope), and declares the review with "Reviewed by: agent". Use on a collector once preflight prints PASS, when brief.mjs --state says draft, or when the user asks for the brief or the handoff.Votes: 0GitHub stars: 2
- Build From BriefStarts phase 2 of a Fetchproof project - checks the corpus arrived (handoff), confirms the gate passes, reads research/BRIEF.md, and builds only from what it verified, naming the E-## row behind every design decision and refusing to fill a gap with a guess. Use when the user says "build it", "start building", "implement the brief", "phase 2", or hands over a project with a research/ folder, on either machine once the gate passes.Votes: 0GitHub stars: 2
- Careful CodingWorking discipline for writing code with fewer mistakes, catching the ones that slip through, reporting them honestly, and fixing the root cause. Use this skill on ANY coding task - writing, editing, refactoring, debugging, or reviewing code in any language or framework - even when the user does not ask for care or verification. Use it especially when the user says things like "be careful", "don't break anything", "make sure it works", "double check", "are you sure?", "did you test it?", "is ...Votes: 0GitHub stars: 2
- Cite In CodeMarks every value in code that came from the research - a rate limit, endpoint, price, quota, timeout, schema field or error code - with a comment naming the evidence row (E-##) and project it rests on, so a wrong number can be traced to its source and re-checked. Use while building from a Fetchproof brief, whenever a literal or schema in the code came from an external fact, or when the user asks where a number came from.Votes: 0GitHub stars: 2
- Commit ReportWrites the five-part commit report the standing protocol requires - what changed, why, what it touched, what was verified, and what was gotten wrong and fixed - with a status word (verified, untested, expected) on every verification claim and six fields per mistake, and the got-wrong line never omitted. Use for every commit or pull request in a Fetchproof project, when the user asks for a commit message, a PR description or a status summary.Votes: 0GitHub stars: 2
- Contract TestsTurns the verified claims in a Fetchproof brief - response shapes, field names, limits, error codes, quoted behaviour - into tests and fixtures, so the code is checked against the research rather than against the builder's memory of it. Use while building from research/BRIEF.md, when writing tests for an integration with an external API or platform, or when the user asks to test against the docs or the brief.Votes: 0GitHub stars: 2
- Day One TasksTurns each KNOWN-UNKNOWN in a Fetchproof project into the first tasks of the build - the day-one verification step its row names becomes a task, a smoke test or a guarded check, done before anything that depends on it. Use at the start of phase 2, when planning the first build steps from research/BRIEF.md, or when the user asks what to do first.Votes: 0GitHub stars: 2
- Fact RequestTurns a fact a builder is missing into a structured request the collector can collect, instead of fetching it, guessing it, or stopping with "insufficient info". Use on a builder machine whenever the brief does not answer something a design depends on, when handoff or preflight fails, when a skill's research step would run on a builder, or when the user asks "can you look that up" on a machine that does not collect.Votes: 0GitHub stars: 2
- Finding RewriterRewrites each auto-extracted Finding cell in a Fetchproof project's research/EVIDENCE.md into a real claim - what the cached page establishes, with the number or rule that proves it and a word-for-word [quote: ...] from the capture - keeping the Raw cell pointing at the capture. Use on a collector after research.mjs collects, when preflight reports quote or finding problems, or when the user asks to rewrite or review the findings.Votes: 0GitHub stars: 2
- Four Dimension AuditGrade completed work honestly and precisely on four dimensions — SPEC, DESIGN, CORRECTNESS, QUALITY — each scored 0–10, to the standard of a demanding principal engineer and product reviewer, without changing anything. Use whenever the user asks to audit, grade, score, review, evaluate, critique, or assess work that was just built or changed, or asks how good it is; triggers include "audit this", "grade the work", "four-dimension audit", "review what was built", "score this", and "how did we ...Votes: 0GitHub stars: 2
- Freshness RecheckRe-collects, on the collector, the pages a Fetchproof brief rests on before a build starts or a release ships, using research.mjs --refresh-days, so a vendor that changed a limit, price or schema is caught in the corpus before it reaches code. Use before a release, when a brief is older than its refreshDays, when a builder reports behaviour that contradicts the brief, or when the user asks whether the research is still current. Collector only.Votes: 0GitHub stars: 2
- Gap AuditRigorous, answer-only audit of an existing project to find the gaps that would stop it producing accurate, complete, and reliable outputs for its stated purpose, benchmarked in repeated passes against real-world equivalents in its domain. Use this whenever the user asks to audit a project, run a gap analysis, find what is missing, check accuracy or completeness or reliability, benchmark against real tools, find weaknesses, ask "is this solid", ask where the outputs will be wrong, or invoke "B...Votes: 0GitHub stars: 2
- Improve Codebase ArchitectureRun the Improve Codebase Architecture workflow — an evidence-backed architecture review that surfaces real friction and proposes deepening opportunities (turning shallow modules into deep ones) for testability and AI-navigability, delivered as a visual HTML report and then worked through with the user one decision at a time. Use whenever the user says architecture review, deepen modules, find shallow modules, improve architecture, architecture friction, deepen this subsystem, make this more t...Votes: 0GitHub stars: 2
- Lead OrchestratorRun substantial work as a lead engineer who plans, researches external facts through Fetchproof before designing, freezes shared contracts, delegates independent units to parallel sub-agents, each on the model most likely to succeed at its role, has fresh-eyed reviewers try to break the result, and ships only what was verified. Use this whenever a task is multi-step or multi-file in any project or language - a plan task or task part, a feature, a batch of bug fixes, a migration, a refactor, a...Votes: 0GitHub stars: 2
- Map ClassifierClassifies every row of a Fetchproof project's research/MAP.md as COVERED (citing U-## rows), DISMISSED (with a reason) or GAP, checking output obtainability first, and adds the topic-specific subtopics the universal checklist misses. Use on a collector after decompose drafts the map, when preflight reports subtopic-coverage findings, or when the user asks to classify, review or finish the map.Votes: 0GitHub stars: 2
- Resume From DiskResumes a Fetchproof project after an interruption - a reset sandbox, a cut turn, a new agent - by reading where it stands from disk (doctor, handoff, preflight, git status, the last commit report, docs/ARCHITECTURE.md) instead of starting over and paying for collected pages twice. Use at the start of any session that continues earlier work, when the user says "continue", "pick up where you left off" or "resume", or when the state is unclear.Votes: 0GitHub stars: 2
- Skill RouterPicks which skill to use next from facts on disk - this machine's role (doctor), whether the corpus arrived (handoff), the research gate (preflight) and the brief - and never sends a builder to a skill that collects evidence. Use at the start of any task in a Fetchproof project, after an interruption, when unsure which skill applies, or when the user says "which skill", "route this", "what next", "start building", "continue", or names a skill that may not fit this machine. Routes skills, not ...Votes: 0GitHub stars: 2
- Source GraderGrades every evidence row in a Fetchproof project as P (primary - the page that owns the fact), S (secondary - context) or L (lead only - forums, video, blogs), and records contradictions between sources with both sides and which one is trusted and why, never averaging them. Use on a collector after collecting, when preflight reports corroboration or source-type findings, or when two sources disagree.Votes: 0GitHub stars: 2
- Subproject DiscoveryEvidence-based research of an existing project to find and rank the three subprojects that would most reduce its manual work, fragility, or repeated effort. Use this whenever the user asks what to build next for a project, which subprojects, tools, or automation would help it, where its bottlenecks or manual steps are, or to audit a repository and recommend improvements — whether they provide a repo, a URL, uploaded files, docs, or an issue tracker, and even if they only say "look at this pro...Votes: 0GitHub stars: 2