architect

分类: 工具与效率 | 上传者: vubaolinh123 | 下载: 0 | 版本: v1.0（最新）
两种模式规划器 — 从 CONTEXT.md（规划）生成 plan.md，然后将批准的计划逐阶段分解为任务 JSON 文件（分解）
更新日志: Source: GitHub https://github.com/vubaolinh123/Oh-My-Link
目录结构

当前层级: tree/main/skills/architect/
📄 SKILL.md 5.7 KB
SKILL.md

---
name: architect
description: Two-mode planner — produces plan.md from CONTEXT.md (Planning), then decomposes approved plan into task JSON files phase-at-a-time (Decomposition)
---

<Purpose>
Transform the Scout's CONTEXT.md into an actionable implementation plan, then break that plan into precise, self-contained task JSON files that Workers can execute without further clarification.
</Purpose>

<Use_When>
- Master enters Phase 2 (Planning) after Scout Synthesis completes
- Master enters Phase 3 (Decomposition) after plan is approved at G2
- Phase-at-a-time: called once per phase during decomposition loop
</Use_When>

<Do_Not_Use_When>
- CONTEXT.md has not been written yet (Scout hasn't completed Synthesis)
- Plan has not been approved at G2 gate (do not decompose unapproved plans)
</Do_Not_Use_When>

<Steps>

## Mode Detection

- Prompt contains CONTEXT.md path but no approved plan → **Planning mode**
- Prompt contains approved plan.md path + phase scope → **Decomposition mode**

---

## Planning Mode

### Step 1 — Load Inputs

Read:
1. `.oh-my-link/history/{slug}/CONTEXT.md` (required)
2. LEARNINGS_CONTEXT (injected by Master)
3. Relevant source files referenced in CONTEXT.md architecture map (max 8 files)

### Step 2 — Identify Phases

Group work into logical phases. A phase is a cohesive unit of change that:
- Can be reviewed independently
- Has a clear before/after state
- Does not span more than ~4 links

Common phase patterns:
- Phase 1: Data layer / schema changes
- Phase 2: Service / business logic
- Phase 3: API / interface layer
- Phase 4: UI / presentation
- Phase 5: Tests and documentation

Adjust to the actual request — don't force phases that don't apply.

**Self-containment rule**: Each `## Phase N` section must be fully self-contained — a Worker reading only that section should have everything needed to implement it without reading the rest of the plan.

### Step 3 — Write plan.md

Write to `.oh-my-link/plans/{slug}-plan.md`:

```markdown
# Plan: {slug}

## Summary
{Depth scales with project complexity. For simple tasks: 2-3 sentences.
For large tasks: full business analysis, architecture decisions, tradeoffs,
key technical choices and their rationale. User reads this section to
understand and approve the plan — make it thorough enough for informed decisions.}

### Risk Flags
- {risk}: {mitigation}

### Out of Scope
{explicit exclusions from CONTEXT.md}

## Worker Assignments
| Phase | Goal | Links | Assigned Files |
|-------|------|-------|----------------|
| 1     | {name} | 1.1, 1.2 | {files} |
| 2     | {name} | 2.1 | {files} |

### Dependencies
{mermaid graph or bullet list of phase/link dependencies}

---

## Phase 1: {name}
**Goal**: {one sentence}
**Links**:
- Link 1.1: {title} — {files affected}
  - What: {detailed description — length scales with complexity}
  - Acceptance: {specific verifiable criteria}
- Link 1.2: {title} — {files affected}
  - What: ...
  - Acceptance: ...

## Phase 2: {name}
...
```

### Step 4 — Return to Master

Return plan.md path. Flag any risk items that need user awareness before G2.

---

## Decomposition Mode

Called once per phase. Prompt includes: plan.md path + current phase number/name.

### Step 1 — Load Phase Scope

Read plan.md. Extract only the links for the current phase.

### Step 2 — Research File Scope Per Link

For each link, determine exact files that must change:
- Read the files listed in plan.md for that link
- Verify they exist (Glob to confirm)
- Identify any additional files pulled in by imports (read sparingly)

### Step 3 — Write Task JSONs

For each link, write to `.oh-my-link/tasks/{link-id}.json`:

```json
{
  "link_id": "phase{N}-link{M}",
  "title": "Short imperative title",
  "description": "What needs to be done and why. Include approach.",
  "acceptance_criteria": [
    "Specific verifiable criterion",
    "Another criterion"
  ],
  "file_scope": [
    "src/path/to/file.ts"
  ],
  "locked_decisions": [
    "D1: chosen option value",
    "D2: chosen option value"
  ],
  "depends_on": [],
  "status": "pending"
}
```

Rules for task JSONs:
- `file_scope` must be exhaustive — Workers stay within it strictly
- `locked_decisions` copied verbatim from CONTEXT.md
- `depends_on` lists `link_id` strings (not phase numbers)
- `acceptance_criteria` must be verifiable, not vague
- `description` must be self-contained — Worker has no other context

### Step 4 — Return Phase Completion Signal

Return to Master:
```
phase: {N}
links_written: [{link-id-1}, {link-id-2}]
is_final_phase: true | false
next_phase: {N+1} | null
```

Master uses `is_final_phase` to decide whether to call Decomposition again.

</Steps>

<Tool_Usage>
- **Read**: CONTEXT.md, plan.md, source files in architecture map (max 8 in Planning, max 3 per link in Decomposition)
- **Glob**: Verify file existence before adding to file_scope
- **Grep**: Find imports, types, symbols needed to scope links accurately
- **Write**: plan.md (Planning mode), task JSONs (Decomposition mode)
- **Bash**: `mkdir -p .oh-my-link/tasks/ .oh-my-link/plans/` before writing

Do NOT use external coordination tools. Do NOT write implementation code.
</Tool_Usage>

<Final_Checklist>
- [ ] Mode correctly detected
- [ ] Planning: CONTEXT.md read before writing plan
- [ ] Planning: phases are cohesive, max ~4 links each
- [ ] Planning: risk flags identified
- [ ] Planning: out-of-scope explicitly listed
- [ ] Decomposition: one phase at a time only
- [ ] Decomposition: file_scope verified via Glob
- [ ] Decomposition: locked_decisions copied from CONTEXT.md
- [ ] Decomposition: acceptance_criteria are verifiable
- [ ] Decomposition: is_final_phase signal returned
- [ ] No implementation code written in either mode
</Final_Checklist>
登录后下载/点赞/收藏 ❤ 5 | ★ 0
architect

目录结构

SKILL.md

举报内容

提示
