oleg494

@oleg494 source repo

37 skills
0 followers
6 hours ago last updated

▌
Yagni · oleg494 bundle
Always-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.

0
installs
▌
Dev Wiki · oleg494 bundle
Always-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.

0
installs
▌
Ponytail · oleg494 bundle
Use 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.

0
installs
▌
Fable Judge · oleg494 bundle
Adversarial 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>".

0
installs
▌
Superpowers · oleg494 bundle
Always-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.

0
installs
▌
Fable Method · oleg494 bundle
A 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).

0
installs
▌
Web Research · oleg494
Use 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.

0
installs
▌
Brainstorming · oleg494
Use 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.

0
installs
▌
Design System · oleg494
Use when creating or refactoring a product UI system, shared components, themes, tokens, or dashboard styling. Keeps color, typography, spacing, states, and responsive rules coherent without introducing a large component abstraction prematurely.

0
installs
▌
Writing Plans · oleg494
Use when you have a spec or requirements for a multi-step task, before touching code

0
installs
▌
Autonomous Work · oleg494 bundle
Use when the user broadly authorizes autonomous work selection and continuation ("do useful work", "choose what is worth doing", "keep going without asking", "work autonomously", "работай сам", "делай что полезно", "продолжай без вопросов") — not for ordinary bounded requests, which keep their existing scope. Covers evidence-backed work selection, verify-then-continue loops, durable mission/progress/handoff state, immediate stop and revocation, and the optional foreground supervisor CLI. Never implies authorization for outward, destructive, or spending actions.

0
installs
▌
Skill Authoring · oleg494 bundle
Use 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).

0
installs
▌
Dashboard Design · oleg494
Use 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.

0
installs
▌
Reasoning Engine · oleg494
Always-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.

0
installs
▌
Code Graph Review · oleg494
Use 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.

0
installs
▌
Money Path Safety · oleg494 bundle
Use 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 for pure CRUD without value semantics and for debugging incidents (that is debug-incident-protocol).

0
installs
▌
Testing Discipline · oleg494 bundle
Use 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.

0
installs
▌
Engineering Persona · oleg494
Always-on. Response format rules (not a persona): direct engineering tone, result first, evidence-based, no fluff, no "I would recommend". Code > words. Observation > assumption.

0
installs
▌
Shipping And Launch · oleg494
Prepares 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.

0
installs
▌
Using Git Worktrees · oleg494
Use 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 fallback

0
installs
▌
Systematic Debugging · oleg494 bundle
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes

0
installs
▌
Receiving Code Review · oleg494
Use 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 implementation

0
installs
▌
Requesting Code Review · oleg494
Use when completing tasks, implementing major features, or before merging to verify work meets requirements

0
installs
▌
Security And Hardening · oleg494 bundle
Hardens 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.

0
installs
▌
Windows Encoding Fixes · oleg494 bundle
Use 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.

0
installs
▌
Architecture Simplicity · oleg494
Use 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. Do not use for money (money-path-safety).

0
installs
▌
Code Review And Quality · oleg494 bundle
Conducts 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.

0
installs
▌
Debug Incident Protocol · oleg494
Use 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 (testing-discipline).

0
installs
▌
Spec Driven Development · oleg494
Creates 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.

0
installs
▌
Test Driven Development · oleg494
Drives 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.

0
installs
▌
Incremental Implementation · oleg494
Delivers 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.

0
installs
▌
Production First Decisions · oleg494
Use 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.

0
installs
▌
Dispatching Parallel Agents · oleg494
Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies

0
installs
▌
Git Workflow And Versioning · oleg494 bundle
Structures 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.

0
installs
▌
Finishing A Development Branch · oleg494
Use when implementation is complete, all tests pass, and you need to decide how to integrate the work

0
installs
▌
Verification Before Completion · oleg494
Use 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 always

0
installs
▌
Observability And Instrumentation · oleg494
Instruments 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.

0
installs

37 published skills