跳到正文
cccskills
免费在 GitHub 公开

pm-planning

Decomposition methodology for pm agent — turns an approved ARCH document into a Beads task list with explicit dependencies, time-boxes, and acceptance criteria. The pipeline can only orchestrate work it can see; this skill defines what "seeable work" looks like.

中文简介正在准备中。当前显示原文说明。

查看安装方法

包含的文件(1)

  • SKILL.md5.0 KB

SKILL.md(原文)

安装前可以查看交给 AI 代理的指令内容。

PM planning — decompose ARCH into tasks

The pm agent's job is to take the architect's ARCH document and produce 2 things:

  1. A PLAN-<feature>.md for humans
  2. A sequence of bd create tasks for senior-dev to claim

The plan is good if a fresh senior-dev (no prior context) can pick up the bd tasks and ship without coming back for clarification.

The decomposition rules

Rule 1. Tasks ≤ 4 hours

Anything bigger gets split. If the task is "build the auth system", split into:

  • Schema migration for user table
  • Signup endpoint with hashing
  • Login endpoint with JWT issuance
  • Logout / token revocation
  • Tests

Each ≤ 4h. If you can't split, the task is unclear — go back to ARCH and clarify.

Rule 2. Single output artefact per task

Each task produces ONE of:

  • A code file (new or modified)
  • A database migration
  • A test file
  • A documentation update
  • A config change

If a task produces multiple unrelated artefacts, split it.

Rule 3. Explicit dependencies via --blocks

When task B requires task A's output:

bd create "Task A: schema migration" -p P1
# returns id: my-proj-001-abc

bd create "Task B: signup endpoint" -p P1 \
  --blocks-on my-proj-001-abc \
  --label senior-dev

The pipeline orchestrator reads bd ready --assignee senior-dev to know what's claimable. Tasks blocked on incomplete predecessors don't appear.

Rule 4. Acceptance criteria — what does "done" mean?

Every task description ends with a bulleted "Done when:" section.

## Done when:
- [ ] POST /signup returns 201 with user_id on success
- [ ] Bad email returns 400 with "invalid_email"
- [ ] Duplicate email returns 409 with "email_taken"
- [ ] Password is hashed with argon2 (no plaintext in DB)
- [ ] Unit test in `tests/<area>/<feature>.test.ts` covers all 4 cases
- [ ] `npm test` passes

Senior-dev knows EXACTLY what to ship and when to stop.

Rule 5. Owners and parallelism

If 3 tasks can run in parallel, mark each with the agent it goes to. Don't bundle them.

bd create "..." --label senior-dev
bd create "..." --label senior-dev   # parallel
bd create "..." --label devops       # parallel, different agent

The PLAN-*.md template

# PLAN — <feature>

Date: <ISO>
Architect ARCH: docs/architecture/ARCH-<feature>.md
Owner: pm

## Summary

2-3 sentences. What problem, what solution. Reference ARCH for detail.

## Cost estimate

(Follow skill: cost-model)

## Tasks

1. **<title>** [P1, ≤2h, senior-dev]
   - Goal: <one-sentence>
   - Done when: <bulleted criteria>
   - bd id: <ID after create>

2. **<title>** [P1, ≤4h, senior-dev]
   - Blocked on: 1
   - Goal: ...
   - Done when: ...

3. **<title>** [P2, ≤1h, qa-engineer]
   - Blocked on: 1, 2

## Pre-mortem

(Follow skill: pre-mortem)

## Gates

(Follow GATES_BY_ARCHETYPE for this archetype + project_size)
- [ ] gate:plan — after pm finishes, before senior-dev starts
- [ ] gate:qa — after qa-engineer, before ship
- [ ] gate:ship — after security-officer, before devops

When pm should push back instead of plan

The pm agent is allowed — and EXPECTED — to refuse a plan if the ARCH is incomplete. Specifically:

❌ ARCH is missing acceptance criteria for the feature itself. Push back: "ARCH says 'build webhook handler' but doesn't specify what counts as success. Re-architect with explicit success criteria."

❌ ARCH doesn't specify the failure mode. Push back: "ARCH says 'handle errors gracefully' but doesn't say what 'graceful' means. Define: log + ack? log + retry? log + alert?"

❌ ARCH conflicts with existing ADRs. Push back: "ARCH proposes Postgres but ADR-005 mandated DynamoDB. Resolve before plan."

Push-back goes to the architect with bd update + label re-arch. The plan is BLOCKED until ARCH is refined.

Anti-patterns

❌ Tasks named after components, not goals. "Build UserService" is ambiguous. "Add POST /signup endpoint that hashes password with argon2" is clear.

❌ No dependencies declared. Two tasks editing the same file with no --blocks-on will conflict. Always declare.

❌ Estimating without doing one task. If you genuinely don't know how long task 1 takes, ask senior-dev to do task 1 first and report back. THEN estimate 2–N.

❌ Tasks > 8 hours. Split. No exceptions.

评价

还没有评价。欢迎分享你的使用感受。

评论

无需登录即可发表。欢迎分享使用感受、提问,或说明在哪些环境下无法运行。

还没有评论。来写第一条吧。

提交后会立即公开。请勿填写邮箱、电话等个人信息。URL 最多 2 个。

0 / 1000 字

此表单受 reCAPTCHA 保护,适用 Google 的隐私权政策和服务条款。

同一仓库的技能

great_cto's own committed aesthetic — the instrument panel. Dark five-step surface ladder, exactly one accent, two faces divided by MEANING (Geist speaks, Geist Mono is machine-truth), tabular numerals, and a dash that is not a nought. Twelve checkable rules measured from packages/board and greatcto.systems, not designed for this file. Use when building or extending any great_cto surface — the board, the site, a report, a share page.

中文简介正在准备中。当前显示原文说明。

avelikiy/great_cto1052026年10月23日 更新

Catalogue of known SDLC anti-patterns that great_cto agents must actively reject when reviewing architecture, plans, code, or post-mortems. Used by architect (pre-impl), pm (planning), senior-dev (impl), l3-support (post-incident).

中文简介正在准备中。当前显示原文说明。

avelikiy/great_cto1052026年10月23日 更新

anydesign

免费

Analyze images, websites, and Figma files to extract their design and generate a `design.md` with token system, component inventory, and reconstruction notes. Use this skill whenever the user wants to understand, document, replicate, or audit the design of something visual: a screenshot, a URL, a Figma link, a Pinterest reference, a mockup, a competitor's site, a component, a dashboard, a landing page. Also when they ask 'extract the design system from X', 'document the style of Y', 'analyze this visually', 'convert this image into tokens', 'help me replicate this design', 'what palette does this site use', 'how is this built'. Also for single elements: 'copy this navbar', 'recreate this illustration', 'give me a prompt to regenerate this graphic' — element mode outputs a focused element.md, with token-grounded image-model prompts when the element is visual art. If the user brings any visual source and wants to understand it at a design level — this skill should activate.

中文简介正在准备中。当前显示原文说明。

avelikiy/great_cto1052026年10月23日 更新

Shared review framework that every domain reviewer (pci, oracle, gov, edtech, healthcare, mlops, etc.) MUST follow. Defines the output artifact (TM-{slug}.md), mandatory sections, severity scale, verdict format, the workflow scaffold (when-invoked, Step-0 read-inputs, HANDOFF), and the "domain heuristic vs generic check" boundary. Eliminates duplication across the ~30 reviewer prompts.

中文简介正在准备中。当前显示原文说明。

avelikiy/great_cto1052026年10月23日 更新

Structured idea generation + multi-LLM debate for the product-owner stage. Diverge (generate genuinely different bets), debate (a 4-persona panel on 4 models argues over 2 rounds), converge (synthesize a recommendation). Used by product-owner before architect; available to architect for design-space exploration.

中文简介正在准备中。当前显示原文说明。

avelikiy/great_cto1052026年10月23日 更新

Run the great_cto controlled Codex lifecycle with controller-owned writes, verifier evidence, human gates and optional artifact release.

中文简介正在准备中。当前显示原文说明。

avelikiy/great_cto1052026年10月23日 更新

查看 avelikiy 的全部技能

报告此技能的问题