Menu
SkillsMP has collected 27 skills from avidrucker/yegor-pm-skills. Open a skill to review its source and details.
Showing 27 of 27 collected skills.
Diagnose whether an incoming work-request — a casual task handed to an agent, a ticket, or an ask handed to a teammate — is clear enough to act on, before guessing. Runs a gate (request vs goal vs question vs complaint), counts how many materially-different…
Project management and engineering-discipline skill set distilled from Yegor Bugayenko's XDSD methodology. Meta-orchestrator for 17 sub-skills (yegor-pdd, yegor-spikes, yegor-bdd, yegor-microtasks, yegor-tickets, yegor-architect, yegor-velocity,…
Apply Yegor-style velocity discipline by measuring progress primarily as verified closed tickets per time window, not commits, hours, or lines of code. Use when Codex is reviewing project progress, answering "how is it going?", checking stale work,…
Apply documentation-first NoHelp discipline: reusable project knowledge belongs in repo docs and tracker artifacts, not in chat, memory, or private explanations. Use when Codex is answering project-specific questions, debugging non-obvious behavior,…
Separate architect mode from courier mode: design in writing first, then execute the accepted design without redesigning midstream. Use when Codex is starting fuzzy work, encountering a design question during implementation, reviewing whether a change matches…
Apply ticket-as-conversation discipline by making the issue tracker the primary record for project decisions, assumptions, blockers, status changes, and direction changes. Use when Codex is about to answer a project-specific question, make or record a design…
Apply Yegor-style microtasking by keeping work bounded to small, independently finishable units with a hard 60-minute ceiling and a practical 30-minute default. Use when Codex is estimating, planning, starting implementation, reviewing a large-looking ticket,…
Apply Bug Driven Development by shaping work as a neutral complaint: have X, should have Y, with repro or evidence. Use when Codex is filing, reviewing, rewriting, or closing issues; when a user describes work as a request, suggestion, question, or vague…
Apply Puzzle Driven Development by turning deferred implementation sub-problems into bounded, tracker-linked puzzle comments at the exact code site. Use when Codex is about to write a stub, placeholder, partial implementation, TODO, or "handle later" note;…
Project-management and engineering-discipline router distilled from Yegor Bugayenko's XDSD methodology for Codex agents. Use when planning or triaging project work, decomposing tasks, filing or reviewing issues, deciding whether to spike/design/code, handling…
Separate architect mode (design in writing) from courier mode (execute agreed design). One person decides, others deliver. Never mix the two modes in one session. When tempted to redesign mid-implementation, stop and drop a puzzle. The architect's only boss…
Apply Bug Driven Development. Frame every piece of work as a complaint with shape "have X / should have Y / repro". No feature requests, no suggestions, no questions. The complaint is best expressed as a failing/disabled test that proves the bug. A bug title…
Knowledge sharing happens through documentation, not by tapping experts. Questions become tickets; answers land in docs (NOTES.md minimum). When you'd search or ask twice, write it down. Docs are kept short, ordered, and non-duplicative (a README is ≤~2 pages…
Council-of-personas decision evaluator. When facing a non-trivial call (a design choice, "should this be a bug?", a label/scope dispute, an approach decision), run it through the strict lens of each relevant yegor-* skill — each persona giving its picky…
Code-review discipline from Yegor Bugayenko. The reviewer's job is to REJECT, not to bless — burden of proof is on the reviewer. Apply the Four NOs (no fear, no compromise, no bullshit, no offense), find the 3 most critical problems, never run the code (a…
All meaningful project communication lives in the issue tracker. No Slack, DMs, or meetings as the primary channel. Decisions don't exist until written as a ticket comment. Use when making a design decision, changing direction, answering a project question,…
Unit-test quality discipline from Yegor Bugayenko. A checklist of named anti-patterns (Liar, Inspector, Mockery, Happy Path, Giant, Free Ride, ...) plus the positive rules — descriptive names, real assertions, test boundaries not just the happy path,…
Velocity is closed tickets per week, full stop. Commits don't count. Hours don't count. Lines don't count. Reporter verifies; closure comment names the deliverable. For a richer picture, a multi-dimensional scorecard (PRs merged, bugs fixed, bugs reported,…
One build can't serve every need — use a tiered set. From Yegor Bugayenko's "Four Builds" — a Fast build (seconds, local, unit-only) for the inner loop, a Cheap build (minutes, on every PR, +integration/style), a Preflight build (the slow pre-merge gate,…
The trunk (master/main) is read-only and the author never blesses their own merge. From Yegor Bugayenko — no one merges by hand; an automated gate runs the full suite in a clean environment and merges only if green. The gate is zero-tolerance — any single…
Forecast from measured delivery rate, not from a spec-derived guess. From Yegor Bugayenko's "How to Estimate Software Cost" — up-front estimates are dishonest because software has no fully-knowable finish line; instead make projections from observed velocity…
Cap work-in-progress and back every status claim with evidence. From Yegor Bugayenko's SIMBA (Simplified Management By Artifacts) — manage by artifacts each with an owner and a reviewer, enforce hard caps on how many things are in flight at once, and require…
Prefer many small single-purpose repositories over one monorepo. From Yegor Bugayenko's "Monolithic Repositories Are Evil" and "Smaller Repository, Higher Quality" — a repo capped around ~50k lines, one language/technology, one problem scope, builds in under…
What to do when you're blocked, stuck, or tempted to grind heroically or fabricate a fix. The cut-corners protocol from Yegor Bugayenko — your duty is to REVEAL the problem, not heroically conceal it. An escalating ladder of honest, principled ways to stop…
Apply Puzzle Driven Development. Convert deferred sub-problems into structured @todo puzzle comments at the code site. Use when writing stubs, reviewing TODO comments, or deferring sub-problems during implementation. Each puzzle references a parent ticket and…
Research/scope spikes for large or fuzzy issues. Run a bounded ≤60min investigation session to discover code sites, current state, open questions, and ROI before writing any @todo puzzle. Use when a GH issue is too vague or too large to add a meaningful @todo…
Cap every task at ~60 minutes (default 30). Budget is fixed at creation. If overrun, stop, split leftover work into @todo puzzles, close the original with what's done. Use when estimating, planning, starting work, or when a task is running longer than…