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:

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.

Check OMC state for active work:
```
state_get_status()
```
If conflicting active tasks exist, warn the user before proceeding.

Detect current branch (for git-related skills):

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

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.

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

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

Memory Persistence

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

Required Actions

Log completion to daily log:

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

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}
)

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

Least privilege — Use only the tools required. Use bash only when file tools cannot do the job.
Failure recovery — If one step fails, continue with independent remaining steps.
Transparency — Report the current phase to the user when entering each Phase.
Memory leverage — At task start, query memory_search for similar past tasks and use them as reference.
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

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.
Scope escalation: If fix/change touches 5+ files unexpectedly, pause and confirm with the user before proceeding.
Security uncertainty: If you are unsure about a security implication, STOP and escalate. Never guess on security.
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}
═══════════════════════════════════════