Skip to main content

avidrucker/yegor-pm-skills

SkillsMP 已收集 avidrucker/yegor-pm-skills 中的 27 个 Skill。打开任一 Skill 可查看来源和详情。

最近记录的来源活动
SkillsMP 收录数据更新
已收集 skills
27
GitHub 星标
0
GitHub Forks
0

这个仓库中的 skills

已展示 27 / 27 个已收集 Skill。

职业分类
项目管理专家
描述

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…

原文语言:英语

更新
已展示 27 / 27 个已收集 Skill。