Skill: jzw6/deep-planner (version 1.0.2)

--- name: deep-planner description: | A meta-skill that activates before complex tasks to enforce structured planning, step-by-step execution, and self-reflection. Works like Claude Code's TodoList — generates a visible task plan, persists it to `.todolist/`, checks off steps as they complete, and pauses at critical decision points for user confirmation. Trigger this skill whenever: - The request involves 3+ steps or multiple tools/skills chained together - Keywords like "research", "analyze", "plan", "design", "compare", "write a report" appear - Key variables are undefined (audience, platform, format, scope, constraints) - The domain is unfamiliar or information may be time-sensitive - A task requires coordinating more than one other skill This skill does NOT produce the final output — it plans and supervises execution, then delegates to the appropriate domain skills (e.g. web search, code execution, platform-specific skills). Think of it as the project manager, not the worker. --- # Deep Planner A planning, execution, and self-reflection protocol for complex agent tasks. ## How It Works The TodoList exists in two places simultaneously: - **In the reply** — visible to the user, updated as steps complete - **In `.todolist/`** — persisted to disk, recoverable if context is truncated Both stay in sync. The file is the backup; the conversation is the live view. --- ## Execution Protocol ### Step 0 — Resume or Start Fresh Before anything else, check for interrupted tasks: ``` Scan .todolist/ for any file with status: in-progress Found → Read it, show the user the current state, ask: continue or start new? Not found → Proceed to Step 1 ``` --- ### Step 1 — Parse the Request (internal, not shown to user) Before generating a plan, resolve the following internally: ``` □ What is the core goal? (one sentence) □ What is the final deliverable? (report / code / content / action sequence / ...) □ What tools or skills are needed? (web search / browser / code execution / ...) □ Are there any ambiguities that would lead to completely different execution paths? Yes → Ask the user first, then generate the TodoList No → Make reasonable assumptions; document them in the plan's Assumptions block ``` **Only stop to ask about blockers — not details you can reasonably infer.** Consolidate all questions into a single message. Do not ask one at a time. --- ### Step 2 — Generate the TodoList Once the request is clear, output the plan and write it to disk simultaneously. **Format shown in the reply:** ```markdown ## 📋 Task Plan: {short task name} **Goal:** {one-line description of the final deliverable} **Steps:** {N} --- - [ ] 1. {step description} `{tool or skill}` - [ ] 2. {step description} `{tool or skill}` - [ ] 3. {step description} `internal reasoning` - [ ] ... > 💡 Assumptions: {any assumptions made without user confirmation} --- Starting step 1 → ``` **Write to disk** at `.todolist/YYYYMMDD-{task-name}.md` using the file format below. --- ### Step 3 — Execute Step by Step Work through the TodoList in order. After each step completes: 1. Open the next reply with a status update — mark the step `[x]` 2. Briefly describe what was produced (1–2 sentences) 3. Update the file to reflect the new state 4. Proceed to the next step **Reply header format (concise):** ``` ✅ Step 2 done → Starting step 3... ``` **Pause and ask the user when:** - A step is marked ❓ (critical information is missing) - Reality diverges significantly from the plan and replanning is needed - A tool call fails and there are multiple recovery paths to choose from --- ### Step 4 — Wrap Up When all steps are done: 1. Show the fully checked-off TodoList in the reply 2. Run the post-completion reflection check (see below) 3. Update the file: set `status: completed` — leave the file in place, do not delete --- ## Confidence Levels Only annotate when uncertain. Do not label every step. | Mark | Meaning | Action | |------|---------|--------| | (default) | Confident, proceed | Execute directly | | ⚠️ | May involve inference or outdated info | Execute, flag uncertainty in output | | ❓ | Critical info missing | Pause, ask the user, then continue | --- ## Post-Completion Reflection Run internally after all steps finish. **Only surface issues that actually exist.** ``` □ Was the core goal achieved? □ Did I state anything I believed but didn't verify? → Flag it □ Are there ⚠️ steps whose conclusions need a caveat? □ Is the deliverable complete with nothing skipped? ``` If issues exist, append to the final reply: ``` > ⚠️ Note: {X} is based on inference — consider verifying {specific thing}. ``` --- ## Anti-Hallucination Rules These constraints are non-negotiable: 1. **No fabricated data** — statistics, market figures, and research findings must have a source, or be explicitly labeled as estimates 2. **No fabricated citations** — do not reference papers, reports, or news articles that may not exist 3. **Flag time-sensitive claims** — anything described as "latest", "current", or "now" must note the knowledge cutoff date or recommend the user verify with a live search 4. **Be honest about limits** — if a task is out of scope, say so clearly rather than producing low-confidence output --- ## File Format Path: `.todolist/YYYYMMDD-{task-name}.md` ```markdown # {Task Name} Created: YYYY-MM-DD HH:MM Status: in-progress | completed ## Goal {One-line description of the final deliverable} ## TodoList - [x] 1. {completed step} - [x] 2. {completed step} - [ ] 3. {current step} ← current - [ ] 4. {upcoming step} ## Assumptions & Confirmations - Assumed: {things inferred without user confirmation} - Confirmed: {things the user explicitly answered} ## Progress {done}/{total} steps completed ``` --- ## Task Type Templates For common task types, load the matching template from the reference file: | Task Type | Reference | |-----------|-----------| | Research & analysis | `references/task-types.md#research` | | Content creation (articles, posts) | `references/task-types.md#content` | | Technical design | `references/task-types.md#technical` | | Data processing | `references/task-types.md#data` | | Multi-skill pipelines | `references/task-types.md#multi-skill` | --- ## Skill Coordination This is a **meta-skill**. It plans and monitors; domain skills do the work. ``` User request → [deep-planner] parse + plan + write TodoList to disk → [web search / browser] information gathering steps → [domain skill A] content or processing steps → [domain skill B] platform-specific steps → [deep-planner] reflection + mark file as completed ``` Do not perform content generation, file operations, or network requests inside this skill. Delegate those to the appropriate tools and skills.

path: references/task-types.md
content: # Task Type Templates

Reference templates for common task categories. Load the relevant section before generating a TodoList.

---

## #research — Research & Analysis

Use for: competitive analysis, industry research, trend reports, user research, literature reviews.

**Standard breakdown:**
```
[ ] 1. Define research scope and key questions (avoid scope creep)
[ ] 2. Identify information sources (web search / knowledge base / documents)
[ ] 3. Gather information from each source
[ ] 4. Filter for relevance and credibility — remove duplicates
[ ] 5. Structure findings (categorize, compare, extract key points)
[ ] 6. Synthesize conclusions and insights
[ ] 7. Flag uncertain claims and recommend items for user verification
```

**Hallucination risk:** Steps 3–4. Never substitute "it is generally believed that" for actual sourced findings.

**Key confirmations:** Time range, geographic scope, desired depth (overview vs. deep dive).

---

## #content — Content Creation

Use for: blog posts, social media (LinkedIn, X, Instagram, Xiaohongshu), newsletters, video scripts, emails.

**Standard breakdown:**
```
[ ] 1. Confirm audience, platform, tone, length/duration constraints
[ ] 2. Define core message (max 3 key points)
[ ] 3. Choose content structure (narrative / tips / comparison / story-led / ...)
[ ] 4. Write first draft
[ ] 5. Platform fit check (format, hashtags, character limits, restricted terms)
[ ] 6. Hook quality check (is the title compelling? does the opening grab attention?)
```

**Key confirmations:** Target audience, brand voice constraints, whether visual/media suggestions are needed.

**Note:** For platform-specific tasks (e.g. Xiaohongshu, LinkedIn), load the corresponding platform skill before steps 4–6.

---

## #technical — Technical Design

Use for: system architecture, technology selection, API design, infrastructure planning, code structure.

**Standard breakdown:**
```
[ ] 1. Clarify functional and non-functional requirements (performance, scalability, cost)
[ ] 2. Identify constraints (existing stack, team capabilities, timeline)
[ ] 3. Generate candidate solutions (minimum 2)
[ ] 4. Evaluate trade-offs for each option
[ ] 5. Recommend a solution with clear rationale
[ ] 6. Identify technical risks and mitigation strategies
[ ] 7. Outline an implementation path (phased if applicable)
```

**Hallucination risk:** Steps 3–4. Do not invent non-existent frameworks or cite outdated benchmarks.

**Key confirmations:** Team size, budget range, deadline pressure, legacy system dependencies.

---

## #data — Data Processing & Organization

Use for: data cleaning, format conversion, report generation, information structuring, archiving.

**Standard breakdown:**
```
[ ] 1. Understand source format and target format
[ ] 2. Identify data quality issues (missing values, duplicates, anomalies)
[ ] 3. Define handling rules for each issue type
[ ] 4. Execute transformations
[ ] 5. Validate output (spot-check sample records)
[ ] 6. Deliver output with a summary of decisions and trade-offs made
```

**Key confirmations:** How to handle anomalies (drop vs. fill?), required output format.

---

## #multi-skill — Multi-Skill Pipelines

Use for: tasks requiring 2+ skills chained in sequence (e.g. research → write → publish).

**Standard breakdown:**
```
[ ] 1. Map the skill chain (which skills run in what order)
[ ] 2. Define data handoffs (what does each step receive and produce)
[ ] 3. Identify the critical bottleneck (most likely failure point)
[ ] 4. Plan fallback behavior (what happens if a step fails)
[ ] 5. Execute in sequence — validate output quality at each handoff before proceeding
```

**Key principle:** Each skill does only its own job. Do not start writing content inside a research skill, or trigger searches inside a writing skill.

**Key confirmations:** Final deliverable format, and whether the user wants to review intermediate outputs (fully automated vs. checkpoint-based).


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: clean (LOW)