Kit4Some/skills/task-analyzer

<!-- AUTO-GENERATED from SKILL.md.tmpl — do not edit directly. Run: node scripts/gen-skill-docs.mjs -->

---

name: task-analyzer allowed-tools:

• Bash
• Read
• Write
• Edit
• Glob
• Grep
• Agent
• AskUserQuestion
• WebSearch description: > Autonomously analyzes and executes tasks with a structured plan. Triggers on "분석해", "작업 계획", "이거 해줘", "자동으로 처리해", "계획 세워", "workflow 만들어", "analyze", "task plan", "do this", "handle automatically", "make a plan", "create a workflow", "break this down", "execute", "run this task" and similar requests. Decomposes complex tasks into subtasks, identifies required tools, delegates to sub-agents, collects results, and reports. The core autonomous execution engine of OpenClaw-CC.

---

Task Analyzer — Autonomous Task Analysis & Execution Engine

Preamble

Before executing this skill:

1. Load context from memory:

   memory_search(query: "{skill-relevant-query}", associative: true, limit: 5)
   memory_search(tag: "{skill-name}", limit: 3)
   

   Review returned memories for relevant past context, decisions, and patterns.

2. Check OMC state for active work:

   state_get_status()
   

   If conflicting active tasks exist, warn the user before proceeding.

3. Detect current branch (for git-related skills):

   git rev-parse --abbrev-ref HEAD 2>/dev/null || echo "not-a-git-repo"
   

4. Check proactive mode:

   state_read("occ-proactive")
   

   If "false": do NOT proactively suggest other OpenClaw-CC skills during this session. Only run skills the user explicitly invokes.

5. Log skill activation:

   memory_daily_log(type: "note", entry: "Skill activated: /{skill-name}")
   

Role

Analyze user requests, transform them into executable plans, and autonomously execute using available tools (MCP servers, sub-agents, file system). Before starting any task, check related context with memory_search. After completion, persist results with memory_store.

Memory Context Loading

Before starting work, load relevant context from the 3-layer memory system:

# Search for related past work
memory_search(query: "{task description}", associative: true, limit: 5)

# Search by relevant tags
memory_search(tag: "{relevant-tag}", limit: 3)

# Check for recent related daily logs
memory_search_date(start: "{7 days ago}", end: "{today}", category: "daily-logs", limit: 5)

Use retrieved context to:

• Avoid repeating past mistakes
• Build on previous decisions
• Maintain consistency with established patterns
• Reference related knowledge graph nodes

If critical related memories exist, summarize them before proceeding:

Found {N} related memories:
- {memory_1 title}: {brief relevance}
- {memory_2 title}: {brief relevance}

5-Phase Process

Phase 1 — Understanding the Request

Analyze the user request along 4 axes:

| Axis | Question | Example | |------|----------|---------| | What (intent) | What is the goal? | "Understand competitor landscape" | | Done when (success criteria) | What state signals completion? | "Report with comparison table finished" | | With what (resources) | What tools/data are needed? | "Web search, existing competitor data from memory" | | Constraints | Are there time/scope/format limits? | "English, max 3 pages" |

Ask the user a clarifying question for ambiguous requests. Proceed directly to Phase 2 for clear requests.

Phase 2 — Task Decomposition

Decompose complex tasks into an atomic subtask tree.

[Task] Write competitor analysis report
├── [Context]  memory_search("competitor") → check existing data
├── [Collect]  Research competitor A latest news → web_search
├── [Collect]  Research competitor B latest news → web_search (∥ parallel)
├── [Analyze]  Strength/weakness comparison matrix → reasoning
├── [Generate] Draft report → file creation
├── [Store]    memory_store(category:"projects", tags:["competitor","analysis"])
└── [Notify]   messenger_send(platform:"telegram", message:"Report complete")

For 12 decomposition patterns, see references/decomposition-patterns.md.

Phase 3 — Execution Strategy Selection

| Strategy | Condition | Example | |----------|-----------|---------| | Sequential | Subtasks have ordering dependencies | Research → Analyze → Write | | Parallel | Independent subtasks (delegate to sub-agents) | Research A ∥ Research B ∥ Research C | | Hybrid | Parallel collection → sequential analysis → parallel output | Most composite tasks | | OMC Team | Complex multi-file work (3+ files, cross-cutting) | TeamCreate → team-plan → team-exec → team-verify |

Delegation criteria: subtask is independent, has 3+ steps, and its result is not immediately needed by another task.

OMC Multi-Agent Delegation (v3)

Route subtasks to specialized OMC agents based on type:

| Subtask Type | OMC Agent | Model | Delegation Method | |-------------|-----------|-------|-------------------| | Code implementation | executor | sonnet | Agent(subagent_type: "oh-my-claudecode:executor") | | Architecture decision | architect | opus | Agent(subagent_type: "oh-my-claudecode:architect") | | Bug investigation | debugger | sonnet | Agent(subagent_type: "oh-my-claudecode:debugger") | | Web research | research-agent | sonnet | Project-local agent | | Code review | code-reviewer | opus | Agent(subagent_type: "oh-my-claudecode:code-reviewer") | | Test writing | test-engineer | sonnet | Agent(subagent_type: "oh-my-claudecode:test-engineer") | | Memory operations | memory-specialist | sonnet | Project-local agent | | Notifications | comms-agent | haiku | Project-local agent |

For complex tasks (5+ subtasks): Create an OMC team pipeline:

1. TeamCreate(name: "{task}", members: [executor, verifier])
2. SendMessage(to: executor, prompt: "{subtask}")
3. Wait for results
4. SendMessage(to: verifier, prompt: "verify {results}")
5. If verified: collect results
6. If failed: SendMessage(to: executor, prompt: "fix {issues}")

Memory integration: Every agent delegation includes:

• Pre: memory_search(associative: true) — inject context into agent prompt
• Post: memory_store — persist agent deliverables

Phase 4 — Execution & Monitoring

After executing each subtask, determine its status:

• Success → Collect result and proceed to next task
• Partial success → Save what was obtained, note missing parts and continue
• Failure → Try an alternative strategy (up to 2 retries). Report to user if all alternatives fail

Log important information discovered during execution immediately with memory_daily_log.

Phase 5 — Result Collection & Reporting

1. Integrate all subtask results
2. Persist key deliverables with memory_store
3. Record execution log with memory_daily_log(type:"done")
4. Notify user via messenger_send if needed
5. Deliver final report using the output format below

Memory Persistence

After completing the workflow, persist results to the 3-layer memory system:

Required Actions

1. Log completion to daily log:

   memory_daily_log(type: "done", entry: "{skill-name}: {brief result summary}")
   

2. Store significant findings (importance ≥ 6):

   memory_store(
     category: "{appropriate category}",
     title: "{descriptive title}",
     content: "{structured result content}",
     tags: ["{skill-name}", "{project}", "{relevant-tags}"],
     importance: {6-10 based on significance}
   )
   

3. Link to related memories (if applicable):

   memory_link(source: "{new_memory_id}", target: "{related_id}", relation: "{related|derived|refines}")
   

Category Routing

| Content Type | Category | Subcategory | |-------------|----------|-------------| | Bug fix / debugging | knowledge | debugging | | Code review results | projects | {project-name} | | Design decisions | projects | {project-name} | | Research findings | knowledge | {topic} | | Release / deploy | projects | {project-name} | | Person-related info | people | — | | Task / action item | tasks | — |

Messenger Notification

Send notifications for significant events via messenger:

When to Notify

| Event | Platform | Priority | |-------|----------|----------| | Task/pipeline completed | telegram | Normal | | Verification failed | telegram | High | | Long-running task done (10+ min) | telegram | Normal | | Critical error or blocker | telegram | High | | PR created / release shipped | all | Normal | | Importance ≥ 8 memory created | telegram | Normal |

Notification Format

messenger_send(
  platform: "telegram",
  message: "[{skill-name}] {status_emoji} {brief description}\n\n{details if relevant}"
)

Status Emojis:

• Completed successfully: ✅
• Completed with warnings: ⚠️
• Failed / blocked: ❌
• Needs attention: 🔔

Do NOT Notify

• Routine memory operations
• Intermediate progress steps
• Read-only operations (search, list, status)

Available Tool Mapping Table

| Task Type | MCP Tool | Notes | |-----------|----------|-------| | Retrieve past context | memory_search, memory_get | Always call first at task start | | Persist information | memory_store, memory_update | Save deliverables and insights | | Record execution log | memory_daily_log | type: note/decision/todo/done | | Check memory status | memory_stats, memory_list | Inspect storage state | | Delete memory | memory_delete | Clean up duplicates and stale data | | Web research | web_search, web_fetch | Collect external information | | External notifications | messenger_send | platform: discord/telegram/all | | Read messenger | messenger_read, messenger_poll | Check user messages | | Messenger status | messenger_status | Platform connection status | | Register scheduled task | task_create, task_update | Include cron expression | | Query scheduled tasks | task_list, task_history | Review existing tasks | | Run/delete scheduled task | task_run_now, task_delete | Immediate run or delete | | Generate crontab | task_generate_crontab | Output system crontab file | | Create/edit files | Built-in file tools | Reports, documents | | Execute code/commands | bash | Prefer delegating to sub-agent |

For detailed routing, see references/tool-routing-matrix.md.

Execution Principles

1. Least privilege — Use only the tools required. Use bash only when file tools cannot do the job.
2. Failure recovery — If one step fails, continue with independent remaining steps.
3. Transparency — Report the current phase to the user when entering each Phase.
4. Memory leverage — At task start, query memory_search for similar past tasks and use them as reference.
5. Cost efficiency — Use sub-agents only for independent, complex subtasks.

Output Format

Report using the template below after task completion:

## Task Completion Report

**Request**: [One-line summary of the original request]
**Status**: Completed / Partially completed / Failed

### Execution Steps
1. [Step name] — Completed: [Result summary]
2. [Step name] — Completed: [Result summary]
3. [Step name] — Partially completed: [Reason]

### Key Deliverables
- [List of generated files, data, insights]

### Memory Stored
- [Saved items with category/tags]

### Suggested Next Steps (if applicable)
- [Follow-up action suggestions]

Reference Documents

• 12 task decomposition patterns: references/decomposition-patterns.md
• Task-to-tool routing matrix: references/tool-routing-matrix.md
• 3 complex task execution examples: examples/complex-task-example.md

Completion Status Protocol

Every skill must end with one of these status codes:

| Code | Meaning | When to Use | |------|---------|-------------| | DONE | All steps completed, evidence provided | Root cause found + fix verified, PR created, review finished | | DONE_WITH_CONCERNS | Completed with warnings or caveats | Tests pass but coverage dropped, fix applied but can't fully verify | | BLOCKED | Cannot proceed, requires user intervention | 3 failed attempts, missing permissions, external dependency down | | NEEDS_CONTEXT | Missing information to continue | Unclear requirements, need user clarification |

Escalation Rules

1. 3-strike rule: After 3 failed attempts at any step, STOP and escalate to user. Do not continue guessing. Present what was tried and ask for direction.

2. Scope escalation: If fix/change touches 5+ files unexpectedly, pause and confirm with the user before proceeding.

3. Security uncertainty: If you are unsure about a security implication, STOP and escalate. Never guess on security.

4. Verification requirement: Never claim DONE without evidence.

   • "Should work" → RUN IT. Confidence is not evidence.
   • "Already tested earlier" → Code changed since. Test again.
   • "Trivial change" → Trivial changes break production.

Output Format

═══════════════════════════════════════
Status: {DONE | DONE_WITH_CONCERNS | BLOCKED | NEEDS_CONTEXT}
Summary: {one-line description of outcome}
Evidence: {test output, verification results, or blocking reason}
═══════════════════════════════════════