All authors
Claude Skills by oleg494
github.com/oleg49437 skills0 installs43 views
- Architecture SimplicityUse when the user wants to: design/redesign modules and layers, choose between a library and your own code, understand why a project became a god file, add an abstraction "just in case", evolve a DB schema without data loss, or review architecture. Covers: YAGNI until second need, stdlib-first, modules by change reason, shared core + thin adapters, config outside repo + defaults in code, schema evolution without DROP, provider fallback chain, unrepresentable invalid states, deleting dead code...Votes: 0GitHub stars: 3
- Autonomous WorkUse for broad autonomous work or recovering a prior project mission on "continue", "resume", "pick up", "продолжи работу". Recover scope and original user grants before selecting work. Bounded tasks stay bounded; continuation does not create outward, destructive, or spending authority.Votes: 0GitHub stars: 3
- BrainstormingUse before designing features, components, new subsystems, or behavior changes. Resolve intent, constraints, interfaces and acceptance before implementation; scale design depth to uncertainty without adding approval gates to authorized work.Votes: 0GitHub stars: 3
- Code Graph ReviewUse BEFORE a commit or change review, when you need to understand "what this N-file change will break": blast radius over the diff, affected execution paths, dead code, architectural hubs/bridges, weak spots, rename with preview. Do not use for code search — CRG is for structural diff analysis, not navigation.Votes: 0GitHub stars: 3
- Code Review And QualityConducts multi-axis code review. Use before merging any change. Use when reviewing code written by yourself, another agent, or a human. Use when you need to assess code quality across multiple dimensions before it enters the main branch.Votes: 0GitHub stars: 3
- Dashboard DesignUse when designing, redesigning, or reviewing marketplace, seller, operations, finance, logistics, or analytics dashboards: information hierarchy, KPIs, filters, charts, tables, honest data visualization, design tokens, responsive behavior, loading/empty/error states, and post-change UI verification in the running app. Not for posters, presentations, or static illustrations.Votes: 0GitHub stars: 3
- Debug Incident ProtocolUse when the user says: «it doesn''t work», «still broken», «hung/stuck», «disappeared after the update», «it used to work», «the metric is zero but the UI is fine» — or when an incident needs to be analyzed, the root cause of a hang found, and whether a process was actually restarted verified. Covers: facts before theories (storage/logs/PID), symptom vs root cause, silent failure, restart ritual, localizing hangs with a progress marker, timeouts, cache masking. Do not use for writing tests (...Votes: 0GitHub stars: 3
- Design SystemUse when creating or refactoring product UI, landing-page styling, visual direction, shared components, themes, or design tokens, or adapting a supplied design reference. Not for software architecture or static illustrations.Votes: 0GitHub stars: 3
- Dev WikiAlways-on. Cross-chat memory (database, not conversation): record decisions, errors, patterns in the global Wiki (~/.memory). Use on "record"/"save"/"remember"/"запиши"/"сохрани"/"запомни"/"в память"/"память" or "what do we know about X"/"напомни". Hierarchy: portable → ~/.memory/Wiki/; project-specific → WORK/<project>/docs/. Cycle: file → index.md → log.md → python ~/.memory/db-tools/build.py → lint.Votes: 0GitHub stars: 3
- Dispatching Parallel AgentsUse when facing 2+ independent tasks that can be worked on without shared state or sequential dependenciesVotes: 0GitHub stars: 3
- Engineering PersonaAlways-on. Response format rules (not a persona): direct engineering tone, result first, evidence-based, no fluff, no "I would recommend". Code > words. Observation > assumption.Votes: 0GitHub stars: 3
- Fable JudgeAdversarial verification of finished work: re-runs the claimed verifications, diffs what changed, detects false "done" claims, delivers an evidence-based verdict (VERIFIED / VERIFIED WITH CAVEATS / REFUTED). Use after any agent or model claims work is complete — "/fable-judge", "judge this work", "verify what it did". Also runs the fable-method trap suite via "/fable-judge suite <target>".Votes: 0GitHub stars: 3
- Fable MethodA step-by-step problem-solving loop (classify the ask, define done, gather evidence, decide, act surgically, verify by observation, report outcome-first). Use when the user says "/fable-method", "use the fable method", or "approach this like Fable", or proactively when starting any multi-step task that no task-specific skill covers. Subcommands - plan (stop after the plan), audit (grade finished work against the loop), report (rewrite an answer outcome-first).Votes: 0GitHub stars: 3
- Finishing A Development BranchUse when implementation is complete, all tests pass, and you need to decide how to integrate the workVotes: 0GitHub stars: 3
- Git Workflow And VersioningStructures git workflow practices. Use when making any code change. Use when committing, branching, resolving conflicts, or when you need to organize work across multiple parallel streams. Use when cutting a release, choosing a semantic version bump, tagging, or writing a changelog.Votes: 0GitHub stars: 3
- Incremental ImplementationDelivers changes incrementally. Use when implementing any feature or change that touches more than one file. Use when you're about to write a large amount of code at once, or when a task feels too big to land in one step.Votes: 0GitHub stars: 3
- Money Path SafetyUse when the user wants to: pay/buy/subscribe, receive or spend a bonus/promo code/referral, check a balance or limit, get a refund, or when any logic for deducting/crediting/quotas changes — even if the request does not name money explicitly («give me more minutes», «why was I charged twice», «enter a promo code»). Checks: idempotency, atomicity, mutation logging, separate buckets, hard gate before expensive work, charge after success, soft delete, compound PK, structured failure. Do not use...Votes: 0GitHub stars: 3
- Observability And InstrumentationInstruments code so production behavior is visible and diagnosable. Use when adding logging, metrics, tracing, or alerting. Use when shipping any feature that runs in production and you need evidence it works. Use when production issues are reported but you can't tell what happened from the available data.Votes: 0GitHub stars: 3
- PonytailUse for coding tasks to minimize implementation weight without reducing requested behavior: reuse existing code, prefer stdlib/native, avoid speculative abstractions, fix root causes and verify the complete observable result.Votes: 0GitHub stars: 3
- Production First DecisionsUse for consequential choices of tools, libraries, standards or production mechanisms. Check existing project constraints first, research unresolved external facts in primary sources, and test unfamiliar mechanisms before integration. No web-search quota for local facts or established repository patterns.Votes: 0GitHub stars: 3
- Reasoning EngineAlways-on evidence-first reasoning for non-trivial tasks: define the outcome, inspect authoritative sources, resolve material uncertainty, act within scope and verify. Scale analysis to consequences rather than fixed step or source counts.Votes: 0GitHub stars: 3
- Receiving Code ReviewUse when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementationVotes: 0GitHub stars: 3
- Requesting Code ReviewUse when completing tasks, implementing major features, or before merging to verify work meets requirementsVotes: 0GitHub stars: 3
- Security And HardeningHardens code against vulnerabilities. Use when handling user input, authentication, data storage, or external integrations. Use when building any feature that accepts untrusted data, manages user sessions, or interacts with third-party services. Use when personal data or privacy compliance (GDPR, CCPA) is involved.Votes: 0GitHub stars: 3
- Shipping And LaunchPrepares production launches. Use when preparing to deploy to production. Use when you need a pre-launch checklist, when setting up monitoring, when planning a staged rollout, or when you need a rollback strategy.Votes: 0GitHub stars: 3
- Skill AuthoringUse when creating or editing any skill: frontmatter rules (name/description), folder structure, script bundling, quality checklist — including converting the current session/procedure/URL into a new reusable skill ("learn", "/learn", "turn this session into a skill", "make a skill from this workflow", "сделай скилл из этой процедуры", "навык из"). Per the Agent Skills specification (Hermes-compatible).Votes: 0GitHub stars: 3
- Spec Driven DevelopmentCreates specs before coding. Use when starting a new project, feature, or significant change and no specification exists yet. Use when requirements are unclear, ambiguous, or only exist as a vague idea. Use when a single requirement spans several independently testable capabilities.Votes: 0GitHub stars: 3
- SuperpowersAlways-on development method: plan, check, implement, verify, report. Use for non-trivial tasks. Define observable acceptance before code, reproduce bugs before fixes, and complete the requested outcome without procedural permission gates.Votes: 0GitHub stars: 3
- Systematic DebuggingUse when encountering any bug, test failure, or unexpected behavior, before proposing fixesVotes: 0GitHub stars: 3
- Test Driven DevelopmentDrives development with tests. Use when implementing any logic, fixing any bug, or changing any behavior. Use when you need to prove that code works, when a bug report arrives, or when you're about to modify existing functionality.Votes: 0GitHub stars: 3
- Testing DisciplineUse when adding/fixing tests, reproducing bugs, checking limits or failures, or deciding what evidence establishes completion. Covers isolated storage, real domain logic, meaningful boundary regressions and verification of the affected runtime/UI surface. Debugging strategy lives in debug-incident-protocol.Votes: 0GitHub stars: 3
- Using Git WorktreesUse when starting feature work that needs isolation from current workspace or before executing implementation plans - ensures an isolated workspace exists via native tools or git worktree fallbackVotes: 0GitHub stars: 3
- Verification Before CompletionUse when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions alwaysVotes: 0GitHub stars: 3
- Web ResearchUse when you need a fact from the outside world: "find out", "look up", "what do they say about", "how it works", "compare", "find information". Protocol: web search → primary sources → cross-check → answer with sources. Do not use for searching the knowledge base (business-wiki) or for facts already in the Wiki.Votes: 0GitHub stars: 3
- Windows Encoding FixesUse when working with Windows (cmd/PowerShell console, MINGW64, script installation): stdout encoding (cp1251 vs UTF-8, UnicodeEncodeError on ✓/Cyrillic), CRLF/LF when writing files (md5 checks of mirrors), UTF-8 BOM for PowerShell 5.1, npm.cmd instead of npm, venv Scripts vs bin, PYTHONIOENCODING/PYTHONUTF8. Verified against 2 Windows 10 bug reports.Votes: 0GitHub stars: 3
- Writing PlansUse when you have a spec or requirements for a multi-step task, before touching codeVotes: 0GitHub stars: 3
- YagniAlways-on. Law of minimalism: don''t build what wasn''t asked for. Abstraction must pay rent via present value or a genuine change-isolation boundary; hypothetical reuse → inline. New dependency → only if the pain is measurable. Dead code → delete. "For the future" → not a reason. Use for ANY code change.Votes: 0GitHub stars: 3