SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsautomate-task

automate-task

General & other

View repository

Updated 10-15 23:44

About this skill

Source Metadata

Original cangjie-skill frontmatter from the distillation run:

name: automate-task
description: |
  当用户想把某个岗位或流程自动化，需要把宏大目标拆解为具体可执行任务时使用。
  用户在说"替代XX岗位"、"全自动"、"AI取代"、"把X工作交给AI"时激活。
  不适用于: 岗位本身只有单一不可拆分的任务、需要整体流程自动化的场景、创意型工作。
source_book: 《给所有人的AI入门课》 吴恩达 (Andrew Ng)
source_chapter: p14, p13
tags: [task-decomposition, automation, scope, project-selection]
related_skills:
  - slug: cross-functional-brainstorming
    relation: composes-with
  - slug: one-second-rule
    relation: depends-on
  - slug: ml-feasibility
    relation: depends-on
Automate tasks, not roles — task decomposition framework

R — Original text (Reading)

"I think we should focus more on automating tasks rather than roles... by analyzing all the tasks employees perform and selecting one, it can help choose the automation project with the most potential in the near term."

— Andrew Ng, p14

I — Methodological skeleton (Interpretation)

Media narratives often say "AI will replace jobs" — but this is the wrong level of analysis. Any role is not a single task, but a collection of multiple tasks. Some tasks are easy to automate (classification, routing, detection), while others are difficult (empathy, creativity, complex judgment). Trying to "automate a role" is a vague and hard-to-execute goal; but "automating one specific task within a role" is clear and achievable. The way this framework operates is: first list all the tasks of a certain role, then evaluate one by one which tasks meet the conditions for automation (simple concept + has data), and finally pick the most valuable one as the project entry point. It transforms the anxious narrative of "AI replaces people" into constructive action of "AI assists with specific tasks".

A1 — Application in the book (Past Application)

Case 1: Call center customer service

  • Problem: How to use AI to improve customer service work
  • Use of the methodology: Role = customer service; tasks = answering calls, classifying emails, processing refunds, answering common questions... choose "classifying emails" as the entry point
  • Conclusion: Email classification is a simple task and has historical data, making it suitable as the first automation project
  • Result: From the grand goal of "replacing customer service" to the concrete project of "automatically classifying emails"

Case 2: Radiologist

  • Problem: How to use AI to help radiology
  • Use of the methodology: Role = radiologist; tasks = interpreting X-rays, communicating with patients, training interns, writing reports... choose "interpreting X-rays" as the entry point
  • Conclusion: Reading images is a core task and technically feasible, but it does not mean AI can replace the entire radiologist role
  • Result: Medical imaging AI is positioned as an "assisted image-reading tool" rather than a "doctor replacement"

A2 — Trigger scenarios (Future Trigger) ★

In what situations will users need this skill?

  1. A manager says "we want to use AI to replace role X" and needs to be guided toward a more specific and more feasible direction
  2. The team is discussing AI's impact on a certain role and needs a structured analysis framework
  3. The project scope is too large and needs to be broken down into executable small projects
  4. Someone proposes a "fully automatic" goal and needs help setting more realistic expectations

Language signals (activate when these appear in the user's words)

  • "replace role XX"
  • "fully automatic"
  • "AI replaces"
  • "hand X work to AI"
  • "let AI do X's work"
  • "X is no longer needed"

Distinction from adjacent skills

  • Difference from cross-functional-brainstorming : Cross-functional brainstorming is about "who participates in idea discovery"; the task decomposition framework is about "how to specifically break things down once a direction is set."
  • Difference from one-second-rule : The one-second rule judges whether a single task is feasible; task decomposition first breaks the role into multiple tasks and then judges each one.
  • Difference from ml-feasibility : The two-factor framework evaluates the feasibility of a single project; task decomposition completes the breakdown before evaluation.

E — Executable Steps (Execution)

Once the skill is activated, the agent should execute the following steps:

  1. List all tasks of the target role

    • Ask the user: "What does this role/position need to do every day? Please list all the tasks you can think of."
    • Completion criteria: The user can list at least 5-10 specific tasks (such as "reply to customer emails," "review invoices," "schedule meetings")

  2. Evaluate each task one by one

    • For each task, ask:
      • "How fast can a human do this task? Can it be judged within one second?" (refer to one-second-rule)
      • "Is there historical data that can be used for training?" (refer to ml-feasibility)
      • "How much value can automating this task bring?"
    • Completion criteria: Each task has an evaluation across three dimensions: "conceptual simplicity," "data availability," and "business value"

  3. Select the optimal task as the project scope

    • Recommend that the user choose a task that is "simple + has data + high value" as the first automation project
    • Completion criteria: The user has identified a specific, executable task as the project scope, rather than the entire role

B — Boundary ★

Do not use this skill in the following situations

  • The role itself has only one task that cannot be further decomposed (rare, but it exists)
  • The so-called "task" is actually the entire content of the whole job
  • Automating a single task cannot create independent value (such as only doing semi-automation, which instead increases the manual burden)
  • The user only wants to understand AI's impact on employment, rather than actually wanting to do an automation project

Failure modes the author warns about in the book

  • Choosing a task that is technically feasible but has very low business value—automation saves little cost
  • Ignoring dependencies between tasks—automating one task may cause downstream processes to break
  • Oversimplifying the task definition—"replying to emails" may include multiple completely different subtypes

The author's blind spots / limitations of the era

  • Assuming tasks are independent—in reality, there is a great deal of context transfer and dependency between tasks, and important information may be lost after decomposition
  • Not discussing the issue of "task granularity"—the same task can be decomposed coarsely or finely, and the choice of granularity affects feasibility judgments
  • The methodology leans "conservative" (choosing only one task)—when resources are sufficient, sometimes advancing multiple tasks in parallel is more efficient
  • In the LLM era, some work that originally required multi-task collaboration may be solved end-to-end by a model as a whole

Adjacent methodologies that are easily confused

  • Difference from "Business Process Reengineering (BPR)": BPR redesigns the entire process; task decomposition uses AI to replace a certain step in the process
  • Difference from "RPA (Robotic Process Automation)": RPA is rule-driven task automation, whereas this framework discusses AI/ML-driven intelligent task automation

Related skills

  • cross-functional-brainstorming (composes-with): After brainstorming to determine the direction, use the task decomposition framework to break down specific tasks
  • one-second-rule (depends-on): For each decomposed task, use the one-second rule to judge feasibility
  • ml-feasibility (depends-on): After task decomposition, use the two-factor framework to evaluate the data availability of each task

Audit information

  • Verification passed: V1 ✓ / V2 ✓ / V3 ✓
  • Test pass rate: Pending testing
  • Distillation time: 2026-06-29