writing-plans

النجوم٨

التفرعات٠

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

Use when you have a spec or requirements for a multi-step task, before touching code

التثبيت

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

المصدر

yaront1111

yaront1111/Moe-s-Tavern

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

تنزيل

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

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

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

مستكشف الملفات

2 ملفات

SKILL.md

readonly

name	writing-plans
description	Use when you have a spec or requirements for a multi-step task, before touching code

Writing Plans

Write plans assuming the engineer has zero context for our codebase. Document everything they need: which files to touch, code blocks per step, exact commands with expected output, what to test.

DRY. YAGNI. TDD. Frequent commits.

Scope check

If the spec covers multiple independent subsystems, suggest breaking it into one plan per subsystem. Each plan should produce working, testable software on its own.

File structure

Before defining tasks, map files: which created, which modified, what each is responsible for. Smaller focused files over large ones. Files that change together live together. Follow existing codebase patterns — don't unilaterally restructure.

Bite-sized tasks

Each step is one action (2-5 minutes):

Write the failing test
Run it to confirm it fails
Write minimal code to pass
Run again to confirm it passes
Commit

Plan header (every plan)

# [Feature Name] Implementation Plan
**Goal:** [one sentence]
**Architecture:** [2-3 sentences]
**Tech Stack:** [key technologies]
---

Task structure

### Task N: [Component Name]
**Files:**
- Create: `exact/path/to/file.py`
- Modify: `exact/path/existing.py:123-145`
- Test: `tests/exact/path/test.py`

- [ ] Step 1: Write the failing test
  ```python
  def test_specific_behavior(): ...

Step 2: Run test, expect FAIL with ""
Step 3: Write minimal implementation (code block)
Step 4: Run test, expect PASS
Step 5: Commit (exact git add + commit message)


## No placeholders

These are plan failures — never write them:
- "TBD", "TODO", "implement later", "fill in details"
- "Add appropriate error handling" / "handle edge cases"
- "Write tests for the above" with no actual test code
- "Similar to Task N" — repeat the code; the engineer may read tasks out of order
- Steps that say what without showing how (code blocks required for code steps)

Every step contains the actual content the engineer needs.

## Self-review

After writing, re-read the spec with fresh eyes:
1. **Coverage:** every requirement maps to a task? List gaps.
2. **Placeholder scan:** any of the failure patterns above? Fix them.
3. **Type consistency:** types and method names match across tasks? `clearLayers()` in Task 3 vs `clearFullLayers()` in Task 7 is a bug.

Fix issues inline. No re-review pass.

---

## Moe integration

In Moe, the architect's plan becomes `implementationPlan.steps` via `moe.submit_plan`. Each step in this skill maps to one Moe step:
- **Title** → step `title`
- **Files** + **code blocks** → step `description` (paste code so the worker doesn't re-derive it)
- **Test files** → step `affectedFiles`
- **Run commands** → in `description` ("Run X, expect Y")

Use `moe-planning` for the higher-level 8-phase template; use this skill for inside-the-step granularity.

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

نفس المستودع

adversarial-self-review

yaront1111/Moe-s-Tavern

Use before calling moe.complete_step on the final step of a task, and again before moe.complete_task. Forces you to read your own diff as an attacker, not an author. Catches concurrency bugs, null-deref, embarrassing assumptions before QA does.

2026-07-258

cpp

yaront1111/Moe-s-Tavern

Use when writing, reviewing, or debugging modern C++ (C++11 and beyond) — .cpp/.cc/.cxx/.h/.hpp files, CMake builds, smart pointers, RAII, move semantics, templates, STL, or concurrency.

2026-07-258

explore-before-assume

yaront1111/Moe-s-Tavern

Use before referencing any function, model, method, relationship, constant, or import in a plan or implementation. Verifies things actually exist in the codebase before building on top of them. Eliminates an entire class of hallucinated-API bugs.

2026-07-258

moe-epic-breakdown

yaront1111/Moe-s-Tavern

Use when an architect is turning an epic into a set of tasks (moe.create_task), before planning any single one. Covers where to cut the seams, how to size and order tasks, what each task's Definition of Done must carry, and the mandatory final integration-and-hardening task. Distinct from moe-planning, which plans the steps inside one task.

2026-07-258

moe-planning

yaront1111/Moe-s-Tavern

Use when an architect is turning a Moe task into an implementation plan via moe.submit_plan. Provides the canonical 8-phase template (plan, explore, tests, minimum impl, verify, document, adversarial review, QA loop), rules for when to skip phases on trivial tasks, and where the verification gate belongs — once at the end of a task, and at full scope only on the epic's final task.

2026-07-258

moe-qa-loop

yaront1111/Moe-s-Tavern

Use when reviewing a task in REVIEW status as the QA agent. Provides the structured decision flow for moe.qa_approve vs moe.qa_reject, with rejectionDetails that drive a clean fix on the worker side.

2026-07-258

Writing Plans

Write plans assuming the engineer has zero context for our codebase. Document everything they need: which files to touch, code blocks per step, exact commands with expected output, what to test.

DRY. YAGNI. TDD. Frequent commits.

Scope check

If the spec covers multiple independent subsystems, suggest breaking it into one plan per subsystem. Each plan should produce working, testable software on its own.

File structure

Bite-sized tasks

Each step is one action (2-5 minutes):

Write the failing test

Run it to confirm it fails

Write minimal code to pass

Run again to confirm it passes

Commit

Plan header (every plan)

# [Feature Name] Implementation Plan **Goal:** [one sentence] **Architecture:** [2-3 sentences] **Tech Stack:** [key technologies] ---

Task structure

### Task N: [Component Name] **Files:** - Create: `exact/path/to/file.py` - Modify: `exact/path/existing.py:123-145` - Test: `tests/exact/path/test.py` - [ ] Step 1: Write the failing test ```python def test_specific_behavior(): ...

Step 2: Run test, expect FAIL with ""

Step 3: Write minimal implementation (code block)

Step 4: Run test, expect PASS

Step 5: Commit (exact git add + commit message)

## No placeholders These are plan failures — never write them: - "TBD", "TODO", "implement later", "fill in details" - "Add appropriate error handling" / "handle edge cases" - "Write tests for the above" with no actual test code - "Similar to Task N" — repeat the code; the engineer may read tasks out of order - Steps that say what without showing how (code blocks required for code steps) Every step contains the actual content the engineer needs. ## Self-review After writing, re-read the spec with fresh eyes: 1. **Coverage:** every requirement maps to a task? List gaps. 2. **Placeholder scan:** any of the failure patterns above? Fix them. 3. **Type consistency:** types and method names match across tasks? `clearLayers()` in Task 3 vs `clearFullLayers()` in Task 7 is a bug. Fix issues inline. No re-review pass. --- ## Moe integration In Moe, the architect's plan becomes `implementationPlan.steps` via `moe.submit_plan`. Each step in this skill maps to one Moe step: - **Title** → step `title` - **Files** + **code blocks** → step `description` (paste code so the worker doesn't re-derive it) - **Test files** → step `affectedFiles` - **Run commands** → in `description` ("Run X, expect Y") Use `moe-planning` for the higher-level 8-phase template; use this skill for inside-the-step granularity.