yuri-semenenko
UserOne engineering workflow across Claude Code, Codex, Copilot, and Gemini CLI. A portable persona canon, process skills, and safety guardrails, kept in sync by design.
Categories
Indexed Skills (24)
commit
Plan 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.
lazy
Apply 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
Write 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.
complexity-audit
Scan 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.
adr
Scaffold 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.
migration-plan
Use 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.
start
Onboarding 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.
pr-classify
Review 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.
pr-recheck
Second-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.
rfc
Draft 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.
security-pass
Run 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.
testing-checklist
Testing 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.
web-performance-checklist
Web 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.
web-security-checklist
Web 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.
failure-investigation
Use when behavior is broken, tests fail, errors appear, production behavior regresses, or the user asks why something is failing, падает, сломалось, or needs root-cause analysis.
pull-request-workflow
Use when reviewing a PR, drafting PR feedback, classifying code-review comments, preparing a pull-request description, or creating copy-pasteable GitHub PR markdown.
humanizer
Use 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
Generate 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-коммент".
architect
Use 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.
context-brief
Use 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
Use 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.
project-onboarding
Use when initializing, auditing, or updating a project's AGENTS.md, onboarding Codex to a repository, capturing repo-specific commands, or turning sparse project context into high-signal agent instructions.
prompt-engineer
Use 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.
test-strategy
Use 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.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.