تشغيل أي مهارة في Manus بنقرة واحدة

cm-planning

النجوم٤٧

التفرعات٢٣

آخر تحديث١٣ مايو ٢٠٢٦ في ٠٩:٢٩

You MUST use this before any creative work or multi-step task. Explores intent, requirements, and design before implementation. Then documents the plan before coding.

التثبيت

التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.

تشغيل في Manus

المصدر

tody-agent

tody-agent/codymaster

فتح مستودع GitHub عرض مستودعات المنشئ

تنزيل

تشغيل في Manus

المهن ذات الصلةSOC

استنادا إلى تصنيف SOC المهني

متخصصو إدارة المشاريعمهن الأعمال والعمليات المالية·SOC 13-1082

SKILL.md

readonly

name	cm-planning
description	You MUST use this before any creative work or multi-step task. Explores intent, requirements, and design before implementation. Then documents the plan before coding.
token_budget	1500
compressed	true
deprecated	false

Planning — Brainstorm + Write Plans

TL;DR

Use before any feature, behavior change, or 3+ step task
Phase A (Brainstorm): clarify intent → 2-3 options → recommend → scope
Phase B (Write): emit openspec/changes/<name>/{design.md,tasks.md}
Handoff out: .cm/handoff/plan.json (goal, decisions, first 3 tasks)
Next: cm-tdd or cm-execution

When to Use

Creating features, components, or functionality
Modifying behavior; multi-step tasks; user-visible change
Skip only for trivial single-line edits or pure questions

Full Protocol

Phase A: Brainstorm

Intent — Ask clarifying questions. Don't assume scope. Surface hidden requirements.
Options — List 2-3 approaches with pros/cons. Recommend one with reasoning.
Scope — Must-have vs nice-to-have; edges to handle vs explicitly skip.
Design — Data flow, component boundaries, API contracts. UI work → cm-ui-preview.

Red flags (STOP): code before brainstorm; assuming intent; skipping scope; "it's simple."

Phase B: Write Plan (OpenSpec format)

Write to openspec/changes/<initiative-name>/:

design.md

# Design: [Goal]
## Context & Technical Approach
## Proposed Changes
### [Component/File]
## Verification

tasks.md

# Implementation Checklist
- [ ] 1.1 ...
- [ ] 1.2 ...
- [ ] Verification testing

Plan rules: small testable steps (15-30 min each), order by dependency, verification per step. No vague steps.

Step FINAL: Emit Handoff + Update Continuity

Write .cm/handoff/plan.json:

{
  "schema": "plan@1",
  "goal": "...",
  "decisions": ["..."],
  "first_tasks": ["1.1", "1.2", "1.3"],
  "openspec_path": "openspec/changes/<name>/"
}

Update .cm/CONTINUITY.md:

Active Goal → plan goal
Next Actions → first 3 tasks
Current Phase → "planning"
Working Context → key decisions

Token win: next session reads CONTINUITY (~200 tok) instead of full plan (2000+).

Integration

After planning...	Use skill
Complex initiative	`cm-brainstorm-idea` (run BEFORE)
Need isolated workspace	`cm-git-worktrees`
Execute the plan	`cm-execution`
Tests first	`cm-tdd`
UI/frontend	`cm-ui-preview`

Karpathy Discipline — Think Before Coding

Before writing the plan, surface what's uncertain instead of guessing:

State assumptions explicitly. List them in the plan; mark each as "verified" or "needs confirmation".
Multiple interpretations? Present them side-by-side with tradeoffs. Don't pick silently.
Simpler path exists? Say so. Push back on over-scoped requests.
Confused? Stop. Name the confusion. Ask. Cheaper than building the wrong thing.

Self-test: "Could a reviewer point to anything in this plan I'm guessing about?" If yes, mark it.

Anti-Patterns

❌ Coding before plan exists
❌ Skipping handoff JSON (downstream skills lose context)
❌ Vague tasks ("refactor the code")
❌ Hidden assumptions — pick one interpretation without telling the user

The Bottom Line

Think before you build. Document before you code. Emit handoff so the next skill picks up cold.

المزيد من هذا المستودع

نفس المستودع

cm-how-it-work

tody-agent/codymaster

Complete guide to vibe coding with CodyMaster — from idea to deploy. Read this first if you are new.

2026-06-1247

cm-project-bootstrap

tody-agent/codymaster

Bootstrap any new project: identity, design system, staging+production, i18n, SEO, test infrastructure, 8-gate deploy pipeline. Prevents tech debt from day 0.

2026-06-1247

cm-ux-master

tody-agent/codymaster

Ultimate UI/UX design intelligence: an Anti-Slop layer that kills AI tells (em-dash, AI purple glow, generic names, template layouts), tunable Design Dials (variance/motion/density) and Style Modes (functional, minimalist, brutalist, soft-premium, marketing), 161 industry color palettes in a shadcn-aligned semantic token schema, 48 UX Laws, 37 Design Tests, UX Heuristics (Nielsen + Krug), Harvester extraction, Figma & Google Stitch integration, MCP server, Component Generator, and BM25 search across 17 domains + 19 framework stacks. One command = complete design system. Use when designing or reviewing UI/UX, choosing colors/typography, fixing generic AI-looking designs, or building Web App / SaaS / Mobile screens.

2026-06-1247

cm-browse

tody-agent/codymaster

Fallback local Playwright daemon for real-browser visual QA / screenshots / smoke. Use ONLY when the host platform has no native browser mode — prefer the host browser first.

2026-06-1247

cm-mcp-engineering

tody-agent/codymaster

Use when you need to interact with the MCP engineering bridge tools (cm_plan, cm_review, cm_qa, cm_deploy, cm_search).

2026-06-1247

cm-content-factory

tody-agent/codymaster

Self-learning SEO content pipeline: dashboard, multi-agent queue, token budgets, research → write → audit → publish. StoryBrand/Cialdini/JTBD-style frameworks; config-driven. Use for content factory, batch articles, or scaled publishing.

2026-05-1847

name	cm-planning
description	You MUST use this before any creative work or multi-step task. Explores intent, requirements, and design before implementation. Then documents the plan before coding.
token_budget	1500
compressed	true
deprecated	false

Planning — Brainstorm + Write Plans

TL;DR

Use before any feature, behavior change, or 3+ step task
Phase A (Brainstorm): clarify intent → 2-3 options → recommend → scope
Phase B (Write): emit openspec/changes/<name>/{design.md,tasks.md}
Handoff out: .cm/handoff/plan.json (goal, decisions, first 3 tasks)
Next: cm-tdd or cm-execution

When to Use

Creating features, components, or functionality
Modifying behavior; multi-step tasks; user-visible change
Skip only for trivial single-line edits or pure questions

Full Protocol

Phase A: Brainstorm

Intent — Ask clarifying questions. Don't assume scope. Surface hidden requirements.
Options — List 2-3 approaches with pros/cons. Recommend one with reasoning.
Scope — Must-have vs nice-to-have; edges to handle vs explicitly skip.
Design — Data flow, component boundaries, API contracts. UI work → cm-ui-preview.

Red flags (STOP): code before brainstorm; assuming intent; skipping scope; "it's simple."

Phase B: Write Plan (OpenSpec format)

Write to openspec/changes/<initiative-name>/:

design.md

# Design: [Goal]
## Context & Technical Approach
## Proposed Changes
### [Component/File]
## Verification

tasks.md

# Implementation Checklist
- [ ] 1.1 ...
- [ ] 1.2 ...
- [ ] Verification testing

Plan rules: small testable steps (15-30 min each), order by dependency, verification per step. No vague steps.

Step FINAL: Emit Handoff + Update Continuity

Write .cm/handoff/plan.json:

{
  "schema": "plan@1",
  "goal": "...",
  "decisions": ["..."],
  "first_tasks": ["1.1", "1.2", "1.3"],
  "openspec_path": "openspec/changes/<name>/"
}

Update .cm/CONTINUITY.md:

Active Goal → plan goal
Next Actions → first 3 tasks
Current Phase → "planning"
Working Context → key decisions

Token win: next session reads CONTINUITY (~200 tok) instead of full plan (2000+).

Integration

After planning...	Use skill
Complex initiative	`cm-brainstorm-idea` (run BEFORE)
Need isolated workspace	`cm-git-worktrees`
Execute the plan	`cm-execution`
Tests first	`cm-tdd`
UI/frontend	`cm-ui-preview`

Karpathy Discipline — Think Before Coding

Before writing the plan, surface what's uncertain instead of guessing:

State assumptions explicitly. List them in the plan; mark each as "verified" or "needs confirmation".
Multiple interpretations? Present them side-by-side with tradeoffs. Don't pick silently.
Simpler path exists? Say so. Push back on over-scoped requests.
Confused? Stop. Name the confusion. Ask. Cheaper than building the wrong thing.

Self-test: "Could a reviewer point to anything in this plan I'm guessing about?" If yes, mark it.

Anti-Patterns

❌ Coding before plan exists
❌ Skipping handoff JSON (downstream skills lose context)
❌ Vague tasks ("refactor the code")
❌ Hidden assumptions — pick one interpretation without telling the user

The Bottom Line

Think before you build. Document before you code. Emit handoff so the next skill picks up cold.