Workflow Model

Do not start from a domain lifecycle such as research -> create -> publish -> analyze. Start from the user’s final result and current starting point. Add only the intermediate conditions that must actually exist for this result.

Two requests containing the same domain word may need completely different flows. “Learn about a platform,” “publish once,” “run an account every week,” and “build a tool for creators” are not variants of one fixed template.

Derive backward, validate forward

Ask internally:

1. What observable result would make the user say this is done?
2. What must be true immediately before that result can exist?
3. What input, decision, permission, or transformation makes that condition possible?
4. Repeat until reaching something the user already has or can provide.
5. Walk forward once to confirm that every step produces the next step’s input.

Do not ask the user every internal question. Ask only when different answers would change the stack, cost, permissions, or deliverable.

Detect the shape instead of choosing a template

Infer properties independently:

• one-off or recurring;
• creation, decision, transformation, coordination, or monitoring;
• local-only, external read, or external write;
• human-led, agent-assisted, or automated;
• single system or multi-system;
• reversible or hard to undo;
• low or high consequence when wrong.

These properties guide decomposition without imposing a predetermined list of stages.

Split and stop rules

Split a step when it contains:

• two independently replaceable actions;
• both reading and external writing;
• different accounts or permissions;
• an approval decision and the action after approval;
• outputs with different success conditions;
• a risky action mixed with a safe action.

Stop splitting when the step has:

• one action a non-technical user can understand;
• one main result;
• one access or side-effect boundary;
• one observable success condition.

Internal capability card

Keep this technical representation internal unless the user asks for details:

Present the same information to a novice as a simple sentence: 先用已有资料确认需求，再生成可审核的结果；只有你确认后才会写入外部系统。

Cross-cutting needs

For each derived step, consider only the helpers that matter:

Match helpers through their capability signature. A Skill that transforms a rough draft into natural writing may support any writing outcome without naming the user’s domain.

Sufficiency check

The flow is detailed enough when every required step has:

• a clear result;
• at least one meaningful search formulation;
• an access and approval classification;
• a yes/no success condition;
• a reason to use an existing Skill, a new Skill, another tool, or no extra capability.

If the generated flow looks suspiciously similar to a prior example, discard it and derive again from the current outcome.