yuri-semenenko
- 37 skills
- 0 followers
- 6 hours ago last updated
- ▌ Adr 2 · yuri-semenenkoScaffold an Architecture Decision Record (ADR) for a concrete decision that's already been made or is being made now. Use when the user says "ADR for X", "write up that decision", "ADR по <решение>", or wants to record a choice for future readers. Different from /rfc — RFC explores options; ADR commits to one.
- ▌
- ▌ Start 2 · yuri-semenenkoOnboarding entrypoint for this kit. Explains what the persona wizard does and hands you the exact command to generate your own persona (persona.md, CLAUDE.md, recommended-skills.md) from the shared templates. Use when the user says "/start", "get started", "onboard me", "set up my persona", or is new to the workspace. Does not run the wizard or edit files unless you explicitly ask.
- ▌
- ▌ Humanizer 2 · yuri-semenenko bundleRewrite text to remove the telltale patterns of AI-generated writing. Use only when the user explicitly asks to humanize / de-AI a piece of text ("humanize this", "убери признаки AI", "make it sound less AI / more natural", "this sounds robotic") — not on every text edit. Covers five pattern families: inflation (fake significance, promo tone, vague authority), diction (AI-frequent vocabulary, copula avoidance, hedging, filler), structure (rule of three, negative parallelism, false ranges, signposting), formatting (em dashes, bold labels, emoji, title case), and chat residue (helper phrases, disclaimers, sycophancy). Ends with an adversarial self-audit pass.
- ▌ Pr Comment 2 · yuri-semenenkoGenerate a pull-request description (the "PR comment") that fills the repo's own PR template, then output it as a copy-pasteable raw markdown code block. Use when the user asks to "prepare a PR comment / description", draft the body for `gh pr create`, or "подготовь PR-коммент".
- ▌ Pr Recheck 2 · yuri-semenenkoSecond-pass re-review of a PR that already has review comments. Re-reads the diff and new commits against the existing open threads, marks each as addressed / partial / not addressed, resolves the addressed ones, and then either approves (only when everything is clean) or drafts new inline comments. Use when the user asks to "re-review", "recheck the PR", "перепроверь PR после фиксов", or do a follow-up pass. Different from pr-classify, which is the first-pass review.
- ▌ Pr Classify 2 · yuri-semenenkoReview a pull request and classify every finding as Critical / Important / Optional per the user's persona framework. Use when the user asks for a "PR review", "review this PR", "проревьюй PR", or wants PR-level triage. Different from /review (generic GitHub PR review) and from /code-review (working-diff bug scan) — this skill enforces the 3-tier classification and filters nitpicks.
- ▌
- ▌
- ▌ Migration Plan 2 · yuri-semenenkoTurn a risky migration or refactor into a safe, incremental, reversible plan that keeps user-visible behavior stable — framework upgrades, design-system swaps, API version migrations, legacy-to-modern replacement. Produces the invariant, the current-to-target seam, a migration shape (strangler / adapter / expand-contract / branch-by-abstraction), independently shippable slices each gated by before/after verification, and a rollout plus rollback plan. Use for "plan this migration", "how do I migrate X to Y safely", "refactor plan for", "strangler plan", "migrate from A to B", "спланируй миграцию", "как безопасно перейти на". Different from /rfc (decides whether and what to migrate; its Migration Strategy section hands off to this) and /module-design (shapes the target interface; this sequences getting there safely). Pairs with both.
- ▌ Testing Checklist 2 · yuri-semenenkoTesting checklist — test pyramid, what to test vs skip, DAMP over DRY, the TDD red-green-refactor loop for new code, failing-test-first for bug fixes, Vitest / React Testing Library patterns. Use when writing or reviewing tests, deciding test coverage for a change, driving new code test-first, fixing a bug (regression test), or when the user asks "what should I test here", "покрой тестами", "review the tests". Pairs with /verify (runtime verification) and the persona's Verification Exit Criterion. Sibling of /web-security-checklist and /web-performance-checklist.
- ▌ Adr · yuri-semenenko bundleScaffold an Architecture Decision Record (ADR) for a concrete decision that's already been made or is being made now. Use when the user says "ADR for X", "write up that decision", "ADR по <решение>", or wants to record a choice for future readers. Different from /rfc — RFC explores options; ADR commits to one.
- ▌ Rfc · yuri-semenenko bundleDraft an architecture RFC using the user's canonical 10-section format (Problem → Context → Constraints → Assumptions → Options → Trade-offs → Recommendation → Risks → Migration Strategy → Open Questions). Use when the user asks for an "RFC", "design doc", "architectural proposal", or "RFC по <теме>". Optimized for the user's Codex persona.
- ▌ Debug · yuri-semenenko bundleUse when behavior is broken, tests fail, errors appear, production behavior regresses, or the user asks why something is failing, падает, сломалось, or needs root-cause analysis.
- ▌ Start · yuri-semenenko bundleOnboarding entrypoint for this kit. Explains what the persona wizard does and gives the exact command to generate your own persona (persona.md, CLAUDE.md, recommended-skills.md) from the shared templates. Use when the user wants to get started, onboard to the workspace, or set up their persona. Does not run the wizard or edit files unless explicitly asked.
- ▌
- ▌ Architect · yuri-semenenko bundleUse for architectural decisions, RFCs, ADRs, system design, trade-off analysis, migration planning, and complex technical decisions that need Staff-level reasoning. Returns a structured recommendation rather than implementation code.
- ▌ Humanizer · yuri-semenenko bundleUse when editing or reviewing text that should sound natural, human-written, less promotional, less AI-generated, or closer to the user's own voice.
- ▌ Pr Comment · yuri-semenenko bundleUse when drafting a pull-request description or the body for `gh pr create`. Fills the repository's own PR template and returns it as a copy-pasteable raw markdown block.
- ▌ Pr Recheck · yuri-semenenko bundleUse for a second pass on a PR that already has review comments and new commits since. Marks each open thread addressed, partial, or not addressed, then either clears the PR or drafts new comments. The first-pass review is pr-classify.
- ▌ Pr Classify · yuri-semenenko bundleUse when reviewing a PR, triaging code-review feedback, or deciding what is worth commenting on. Classifies every finding as Critical, Important, or Optional and ends with a verdict. The follow-up pass after fixes is pr-recheck.
- ▌
- ▌ Context Brief · yuri-semenenko bundleUse when preparing a compact handoff, task brief, implementation context, or review packet before a complex change, PR review, debugging session, or agent delegation.
- ▌ Module Design · yuri-semenenko bundleUse when designing or reviewing a module or interface boundary, extracting a helper or wrapper, or deciding whether an abstraction is worth it. Favors deep modules, information hiding, and composition over speculative layering.
- ▌ Migration Plan · yuri-semenenko bundleUse when planning a risky migration or refactor — framework upgrades, design-system swaps, API version migrations, legacy-to-modern replacement — into a safe, incremental, reversible sequence that keeps user-visible behavior stable. Produces the invariant, a seam, a migration shape, verified slices, and a rollout plus rollback plan.
- ▌ Prompt Engineer · yuri-semenenko bundleUse when creating, rewriting, or reviewing prompts for AI agents, copilots, reusable workflows, RFC/review prompts, or ambiguous tasks that need stronger context, constraints, success criteria, and output structure.
- ▌ Testing Checklist · yuri-semenenko bundleUse when writing or reviewing tests, deciding coverage for a change, driving new code test-first, or fixing a bug that needs a regression test. Covers what to test, the TDD loop, and failing-test-first.
- ▌ Lazy · yuri-semenenkoApply the "laziest solution that actually works" enforcement ladder when writing or proposing code — question whether the work needs to exist (YAGNI), reach for stdlib / native platform / already-installed deps before custom code, prefer one line over fifty. Supports intensity lite | full (default) | ultra. Use when implementing a feature, scaffolding, or whenever the user wants the minimal viable change ("the lazy way", "minimal diff", "do the least that works"). Different from /simplify (which cleans up an existing diff after the fact) — /lazy runs the ladder before the code is written. Aligned to the persona's simplicity bias.
- ▌ Spec · yuri-semenenkoWrite a minimal spec — goal, non-goals, acceptance criteria, open questions — before implementing a feature or change. Use when the user asks to "spec this", "напиши спеку", "what does done mean here", "acceptance criteria for X", or before starting a non-trivial implementation without a clear definition of done. Different from /rfc (explores architecture options, 10 sections) and /adr (records a decision already made) — /spec pins down what "done" means for one concrete change, in five to twenty lines. Its acceptance criteria become the input for /verify.
- ▌ Project Onboarding · yuri-semenenko bundleUse when initializing, auditing, or updating a project's AGENTS.md, onboarding an agent to a repository, capturing repo-specific commands, or turning sparse project context into high-signal agent instructions.
- ▌ Commit · yuri-semenenkoPlan and create small, logically-grouped git commits per the persona's git conventions — propose a commit plan first, wait for approval, then commit in atomic units. Use when the user asks to "commit", "закоммить", "make commits", "split this into commits", "сделай коммиты", or "commit plan". Enforces the no-Co-Authored-By rule and the ask-before-branch/push/PR gate.
- ▌
- ▌ Security Pass · yuri-semenenkoRun a security hardening pass using the persona's validated workflow — recon, then a numbered remediation checklist for approval, then atomic commits with a typecheck gate after each task. Use when the user asks for a "security pass", "harden this", "security hardening", "пройди по безопасности", or a staged remediation (not a one-shot scan). Different from the built-in /security-review (single-pass diff scan) — this is the multi-task remediation loop with an approval gate.
- ▌ Complexity Audit · yuri-semenenkoScan an entire codebase (or a chosen subtree) for over-engineering — premature abstraction, speculative generality, needless layering, wrapper-only modules, dead config/flags, indirection without payoff — and return a prioritized, deletion-oriented report. Use for "audit complexity", "find over-engineering", "where are we over-built", "complexity-audit". Complements the per-diff /code-review and /simplify (which look at the current change); this looks at the whole tree. Aligned to the persona's anti-pattern list.
- ▌ Web Security Checklist · yuri-semenenkoWeb application security checklist — OWASP Top 10 + LLM Top 10, threat modeling (STRIDE), auth/authz, input validation, secrets, security headers, CORS, data protection, and supply-chain hygiene. Use when reviewing security, hardening a feature, threat-modeling, or before merging security-sensitive changes (auth, user input, secrets, external or LLM-derived data). Pairs with /security-review.
- ▌ Web Performance Checklist · yuri-semenenkoWeb performance checklist — Core Web Vitals (LCP/INP/CLS), TTFB diagnosis, and frontend levers (JS/CSS/fonts/images/network/rendering) plus backend (DB N+1, API latency, caching, infra). Use when optimizing performance, diagnosing a slow page or unresponsive interaction, setting a performance budget, or reviewing a perf-sensitive change.