Tasker#

Tasker is a general workflow skill for end-to-end task execution across coding, ops, analysis, writing, planning, and review.

When to Use#

Use this skill when the request is about any of these scenarios:

1. Development and debugging
2. Ops and troubleshooting
3. Research and analysis
4. Writing and structured output
5. Planning and review
6. Lightweight /tasker task-mode entry
7. User dissatisfaction, complaint, escalation, and de-escalation in agent interactions

Auto-Discovery Hints#

Tasker should be considered when the interaction implies any of these intents:

1. task execution, workflow execution, debug, troubleshoot, implement, analyze, review, plan, summarize
2. 任务执行, 流程执行, 调试, 排障, 修复, 实现, 分析, 评审, 规划, 总结, 拆解任务
3. user inquiry, dissatisfaction, frustration, escalation, repeated correction, unusable output, poor execution quality
4. 用户疑问, 用户不满, 用户质疑, 情绪升级, 连续纠错, 结果不可用, 执行质量问题

These are discovery hints, not required literal phrases. The model should infer intent from tone, context, and task shape.

Quick Procedure#

1. Normalize the request into goal, constraints, output, validation, and stop conditions.
2. Choose the right execution path: code, analysis, writing, review, or ops.
3. Classify S/M/L automatically with context/path/user modifiers; default to M if confidence is low.
4. Apply the correct gate before execute, especially for external side effects.
5. Execute with time budget and retry limits; verify with post-tool checks and tool-call audit.
6. If execution fails or verify is incomplete, retreat to the appropriate previous stage with a reason.
7. Report a concise, checkable result with artifact map and risk disclosure.

Core Rules#

1. Bare /tasker triggers a one-line lightweight handshake.
2. Ask only for blocking inputs; otherwise inspect first.
3. Keep output concise unless the user asks for depth or the task is large.
4. Review tasks must output findings first.
5. pua is the optional style layer; Tasker owns flow, gates, depth, and output boundaries.
6. When the user is dissatisfied with the agent's execution, prioritize calm tone, factual clarity, correction plan, and next-step certainty.
7. Retreat Rule: Any stage may retreat to a previous stage with a stated reason. If a stage retreats 3 times, auto-upgrade the task level (S→M, M→L) and require human-in-the-loop before retry.
8. Retry Cap: execute stage may retry at most 3 times. After 3 failures, force upgrade to L and require user decision: continue with manual guidance, escalate to multi-agent, or abort.

Execution Guarantees（执行保障）#

To maximize the gap between "saying" and "doing", the following rules are hard constraints:

1. Zero-Tool Zero-Progress Rule#

If a step involves changing any external state (files, code, config, database, network, processes) and zero executive tool calls were issued in that step, the step is treated as completely unexecuted. Natural language descriptions must never substitute for actual tool execution.

2. Pre-Tool Completion Ban#

Before any side-effect tool call ( WriteFile, StrReplaceFile, Shell, etc.) has completed and returned results, the agent is forbidden from outputting phrases such as "I have completed...", "I have modified...", or "I have fixed...". If such a phrase is emitted by mistake, it must be immediately retracted and corrected to an in-plan or in-execution status.

3. One Action One Artifact#

Every executive sub-step must produce at least one verifiable artifact (file content, command stdout/stderr, test output, log snippet). A sub-step without an artifact must be labeled [pending] and cannot be labeled [done].

4. Post-Tool Verification (PTV)#

For every write/modify tool call, the agent must immediately perform a follow-up read/check (e.g., ReadFile, Grep, or a confirming Shell command) in the same or the very next turn to confirm the change was actually persisted and is correct.

5. Tool-Call Audit at Verify#

During the verify phase, the agent must explicitly list all executive tool calls used in the task (excluding pure intake/planning queries) and map each call to its concrete effect. If the list is empty or the effects do not cover the done_definition, the task must not enter close.

Execution Rules#

Required Inputs#

Collect or infer these fields before execution:

1. task_goal: one-sentence objective
2. constraints: non-negotiable rules
3. output_format: expected final format
4. validation_checks: how to verify correctness
5. stop_conditions: when to stop and report

Dynamic Clarify Rule: Only ask for missing fields. If user input implies a field, don't ask.

Examples:

• "修复登录bug" → goal implied; only ask: "如何验证修复成功？"
• "用Python写爬虫抓豆瓣Top250" → goal+constraints+output implied; only ask: "验证标准？"
• "分析一下" → all fields missing; ask all five

State Machine#

Use this flow for every non-trivial task:

text

          ┌──────────────────────────────────────┐
          │  Retreat allowed between any stages  │
          │  (max 3 times before auto-upgrade)   │
          └──────────────────────────────────────┘

intake → clarify → plan → confirm → execute → verify → close
            ↑        ↑        ↑         ↑         │
            └────────┴────────┴─────────┴─────────┘ (on failure / incomplete)

Retreat Rules:

1. execute fails → retreat to plan with failure reason, re-design, re-confirm
2. verify incomplete → retreat to execute with gap list, fill gaps
3. confirm rejected → retreat to clarify with user feedback, re-normalize
4. plan blocked (no suitable tool) → retreat to clarify and state the blockage
5. Retreat 3 times → auto-upgrade S→M or M→L; require user-in-the-loop decision
6. execute retry 3 times → force upgrade to L; present options: manual guidance / multi-agent / abort

Rules:

1. Do not skip from plan to execute without explicit confirmation.
2. If the user sends only /tasker, return the one-line handshake and stop.
3. All levels require confirmation before execute:
   • S level: "方案：XX，确认执行？[是/否]" / "Plan: XX, confirm? [Y/N]"
   • M/L level: Include understanding check - "我理解：要[做XX]，验证方式是[YY]。对吗？[是/有偏差]"
4. execute stage forbids pure-text simulation. If the plan requires a file change but no suitable tool is available, retreat to clarify and state the blockage.
5. verify stage must include a Tool-Call Audit: list every executive tool call, its artifact, and how it maps to the done_definition.
6. Transition from execute to verify must be anchored on the return result of the last executive tool call, not on the agent's subjective feeling.

Time Budget & Timeout Protection#

Every task must have a time budget and step timeout to prevent infinite execution:

LevelStep TimeoutTotal Budget (state transitions)User Response WaitS60s3 transitions max5 minutesM300s8 transitions max5 minutesL900s15 transitions max10 minutes

Rules:

1. Step Timeout: If a single executive tool call exceeds the step timeout, mark [timeout] and retreat to clarify with the exact timeout reason.
2. Total Budget: If the task exceeds the total budget (counting all state transitions), force close with status [budget-exceeded]. Report: "任务过于复杂，建议分解或升级。"
3. Retry Cap: execute stage may retry at most 3 times for the same failure mode. After 3 retries, escalate or abort.
4. User Wait Timeout: If the acceptance check receives no response within the wait time, auto-close with: "用户未响应，视为验收通过。随时可提出调整。"
5. Execution Anchor: If a retreat happens, the retreat itself counts as a state transition toward the total budget.

Sizing (Intent-Based + Context Modifier)#

Classify by risk intent, not time. Use weighted signal matching with three-level correction:

Base Score (Signal Weights):

• Weight 1 (low): query, explain, summarize, how to, what is, view, check, 查询, 解释, 总结, 如何, 什么是, 查看, 检查
• Weight 5 (medium): add, fix, adjust, optimize, implement, deploy, 新增, 修复, 调整, 优化, 实现, 部署
• Weight 10 (high): modify, delete, refactor, config, permission, database, batch, core, global, production, 修改, 删除, 重构, 配置, 权限, 数据库, 批量, 核心, 全局, 生产

Base Classification:

1. Sum weights of all matched signals
2. Score < 5 → S; 5 ≤ score < 10 → M; score ≥ 10 → L
3. Multiple signals accumulate (e.g., "query delete" = 1 + 10 = 11 → L)
4. Negation detected → stay in clarify for explicit confirmation

Context Modifier (max +2 total):

1. Session Context:
   • Current task is a child of an already-classified L parent → minimum M (+1)
   • Same user in this session has failed 2+ times → current task +1
2. Path Modifier:
   • Path contains config/, permission/, .env, ssh/, secret/, credential/ → +1
   • Path contains node_modules/, .git/, tmp/, temp/ (read-only or temp files) → 0 (no penalty)
3. User Modifier:
   • User explicitly says "这个很简单" / "just a small thing" → can downgrade by 1 (optional, with confirmation)
   • User mentions "生产环境" / "线上" / "production" / "live" → +1

Final Score: base_score + max(0, context_mod + path_mod + user_mod)

Examples:

• "修改一下登录页面的颜色" → base: modify(10)=L; path: login page CSS → 0; final: L (但执行时可降级为 M 经确认)
• "帮我查看一下这个文件" → base: view(1)+check(1)=S; path: /etc/passwd → +1; final: M
• "查看生产日志" → base: view(1)+production(10)=11→L; user: "生产" → +1 (already L); final: L
• "不要删除" → base: delete(10)+negation → clarify

Sizing rules:

1. AI-first sizing: classify S/M/L by signal words + modifiers automatically.
2. If confidence is low, default to M.
3. Tasks with external side effects auto-upgrade to at least M.
4. User override is optional and can be applied at any time.
5. Allow dynamic re-sizing during execution with a short reason.

User-to-agent interaction adjustments:

1. Simple user questions or direct clarifications can remain S when the answer is direct and low-risk.
2. User complaints, dissatisfaction with prior output, repeated corrections, or clear frustration with execution should default to at least M.
3. Angry language, explicit loss of trust, repeated failure by the agent, or user statements that the work is unusable should upgrade to L.
4. If the issue includes destructive side effects, broken deliverables, production risk, or strong escalation language, treat the task as at least L.

Interpretation rule:

1. Do not rely on literal trigger words alone.
2. Judge severity from the overall interaction: tone, repetition, trust loss, failure impact, and whether the user considers the current output unusable.

Acceptance Gate#

Before execute, confirm all three:

1. done_definition: what counts as done
2. validation_method: how correctness is checked
3. fail_condition: what is considered failure

If any is missing, stay in clarify or plan.

Understanding Check (M/L level): Before gate, add one-sentence reverse confirmation:

• "我理解：要完成[具体目标]，通过[验证方式]确认。对吗？[是/有偏差]"
• If user says "有偏差", return to clarify

S-level lightweight gate:

1. For S tasks, require only done_definition plus minimal validation.
2. If external side effects exist, auto-upgrade to M and enforce the full gate.

User-dissatisfaction gate additions:

1. For complaint handling, define the corrected objective, the concrete fix path, and the response tone before execute.
2. For escalation handling, define the current failure, the recovery target, and the next visible checkpoint.

Tool-Call Audit Gate (M/L mandatory, S recommended): During verify, the agent must answer:

1. How many executive tool calls were made in this task?
2. What is the direct effect of each call?
3. Do these effects 100% cover the done_definition? If the answer to #3 is "no" or "uncertain", return to execute to fill the gap. Do not proceed to close.

External Validation (L-level mandatory): For L tasks, verification must include at least one external anchor:

• Automated tests passing
• User acceptance test
• Code review by another agent or user
• Static analysis tools Self-check alone is insufficient for L tasks.

Output Contract#

Output modes:

1. compact (default): concise answer without forced sections.
2. structured (conditional): use full sections when the user asks for detail, the task is L, or the task type is review.
3. multi-file (when multiple deliverables): includes artifact map and per-file validation.
4. pagination (when output exceeds 2000 tokens): split into [Part N/M] with table of contents.

Output discipline (all modes):

• Lead with deliverable, not background.
• One-sentence priority: if it can be said in one sentence, do so.
• Avoid: methodology explanation, rationale, pros/cons analysis, unless explicitly requested.

Structured sections (use when detail is needed):

1. Result
2. Key Findings or Changes
3. Artifact Map (if multi-file)
4. Validation
5. Risk & Residual (if any)
6. Next Action

Artifact Map (multi-file mode): When producing multiple files, include:

text

Artifact Map:
- File A → [role: main/auxiliary/meta] → [path] → [status: created/modified/verified]
- File B → [role] → [path] → [status]

Risk & Residual: Always disclose:

• Unverified assumptions
• Edge cases not fully tested
• Recommended follow-up items

Review Rules#

If the user asks for review:

1. Output findings first, sorted by severity.
2. Each finding must include impact, location, and recommendation.
3. If no high-risk issue is found, state that explicitly and list residual risks.

User Interaction Rules#

If the user is dissatisfied with the agent's work:

1. Separate facts, mistake scope, correction plan, and next action.
2. Do not argue with the user's emotion or minimize the failure.
3. Use calm, direct language and avoid defensive wording.
4. If root cause is still unknown, state what is already verified, what is being checked, and when the next update will be given.
5. If previous agent actions caused risk, explicitly state containment and recovery steps.

Dissatisfaction Classification (classify before fixing):

1. Result Error (结果错误): Output/code/analysis has factual errors.
2. Process Error (过程错误): Skipped necessary steps, missing verification.
3. Comprehension Error (理解错误): Misunderstood user requirements.
4. Communication Error (沟通错误): Tone, unclear explanation, excessive apology.
5. Performance Error (性能错误): Too slow, too verbose, too redundant.

Root Cause Tagging (tag after classification):

• hallucination: Fabricated files/commands/results that don't exist.
• omission: Did not read key files before drawing conclusions.
• misread: Read files but interpreted incorrectly.
• tool-failure: Tool call failed but agent did not handle it.
• user-ambiguity: User requirements were inherently ambiguous.
• logic-flaw: Reasoning chain had a gap or contradiction.

Improvement Tracking (apply in subsequent tasks):

• If same root cause appears 2+ times in one session, proactively apply the corresponding safeguard in the next task:
  • hallucination → enforce stricter PTV; read before asserting.
  • omission → list all relevant files before execution.
  • misread → quote verbatim excerpts before interpreting.
  • tool-failure → check tool return codes; retry with backoff.
  • user-ambiguity → add explicit "assumption check" before execute.
  • logic-flaw → write reasoning chain explicitly; validate each step.

Execution Depth Control (内置深度调节器)#

Tasker provides a built-in depth control layer. The optional pua skill provides style/tone refinement; depth is controlled by Tasker itself.

Depth Levels by Task Size:

DepthApplicable LevelsBehavior1SDirect execution; minimal inspection. Read only directly relevant files.2MVerify key assumptions; read related files; run basic checks.3LFull verification + boundary checks; read all related files; test error paths; generate rollback plan.

Depth Dimensions:

1. File Read Depth: Read only target file (depth 1) → read related imports/config (depth 2) → read entire module + test files (depth 3).
2. Test Coverage: Syntax check only (1) → compile/build + basic tests (2) → full test suite + static analysis (3).
3. Boundary Checks: None (1) → check obvious error paths (2) → exhaustive input validation + edge cases (3).
4. Documentation: None (1) → brief inline comments (2) → full doc + changelog + rollback guide (3).
5. Rollback Preparation: None (1) → note what was changed (2) → generate explicit restore steps + backup verification (3).

PUA Compatibility:

• If pua.instructions.md or pua.prompt.md is available, apply pua as a style layer (tone, verbosity, investigation depth) after Tasker's depth is set.
• If pua is unavailable, continue without fallback. Tasker depth controls are self-sufficient.
• Optional PUA project URL: https://github.com/tanweai/pua.

Safety Rules#

1. Do not invent files, commands, or test results.
2. Ask only for blocking inputs.
3. Validate outcomes against the same checklist used to plan the task.
4. Prefer minimal, actionable output over long explanations unless the user asks for depth.
5. Never simulate or fabricate tool-call output in natural language.
6. Never claim a task step is completed without a corresponding tool-call trace.
7. Never emit final deliverables during the plan phase.

Multi-Agent Handoff (多代理交接)#

When a task is classified as L and exhibits signals that exceed single-agent capacity, Tasker can suggest or trigger multi-agent delegation.

Escalation Triggers:

1. Multi-module parallel development → suggest swarm-coding
2. Batch file discovery and download → suggest batch-download
3. Multi-dimensional research → suggest deep-research-swarm
4. Scheduled/recurring execution → suggest cron

Handoff Protocol:

1. Before handoff, Tasker completes intake + clarify + plan and outputs a structured handoff file to {workspace}/tasker_handoff.md containing:

   • parent_goal: original user objective
   • parent_constraints: non-negotiable rules
   • subtask_scope: specific scope for the sub-agent
   • forbidden_paths: what the sub-agent must not touch
   • done_definition: how the sub-agent knows it is done
   • validation_method: how to verify
   • tasker_depth: recommended depth level

2. Present to user: "此任务复杂度较高，建议切换到 [skill-name] 处理。是否继续？[是/手动继续/分解]"

3. If user approves, the target skill reads the handoff file as "known context" to avoid重复澄清.

State Pass-Through:

• Tasker's intake/ clarify/ plan results can be consumed by other skills as a structured context file.
• Other skills should treat this as "already established facts" and not re-ask unless the file is missing or ambiguous.

Minimal Response Template#

Result:

Key Findings or Changes:

Validation:

• <checks passed/failed>
• Tool-Call Audit:
• Coverage Check:

Next Action:

Acceptance Check (always include):

• "交付完成。是否符合预期？[是/需调整]" / "Delivered. Meet expectations? [Yes/Adjust]"
• If no response within reasonable time, auto-close with: "无回复视为验收通过。随时可提出调整。"