Menü
SkillsMP hat 27 Skills aus avidrucker/yegor-pm-skills gesammelt. Öffne einen Skill, um Quelle und Details zu prüfen.
Es werden 27 von 27 gesammelten Skills angezeigt.
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…
Quellsprache: Englisch
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,…
Quellsprache: Englisch
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,…
Quellsprache: Englisch
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,…
Quellsprache: Englisch
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…
Quellsprache: Englisch
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…
Quellsprache: Englisch
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,…
Quellsprache: Englisch
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…
Quellsprache: Englisch
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;…
Quellsprache: Englisch
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…
Quellsprache: Englisch
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…
Quellsprache: Englisch
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…
Quellsprache: Englisch
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…
Quellsprache: Englisch
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…
Quellsprache: Englisch
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…
Quellsprache: Englisch
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,…
Quellsprache: Englisch
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,…
Quellsprache: Englisch
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,…
Quellsprache: Englisch
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,…
Quellsprache: Englisch
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…
Quellsprache: Englisch
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…
Quellsprache: Englisch
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…
Quellsprache: Englisch
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…
Quellsprache: Englisch
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…
Quellsprache: Englisch
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…
Quellsprache: Englisch
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…
Quellsprache: Englisch
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…
Quellsprache: Englisch