---
name: workflow-code-builder-framework
description: Use when planning, drafting, or diagramming a source-first Tela workflow involving @meistrari/workflow-code, workflow-code.config.ts, or *.workflow.ts before implementation.
---

# Plan a Workflow Code Workflow

Turn a request into a conceptual workflow proposal. Explain responsibilities and data flow. Leave
module, API, and source-shape selection to the builder.

## Hard Rules

- Keep proposal work read-only: do not inspect files or docs, run commands, compile, call APIs, or
  mutate anything.
- Describe behavior, not concrete modules, helpers, options, source syntax, or installed support.
- Treat branches, decisions, iteration, fan-out, fan-in, and every Mermaid edge as desired behavior,
  never as proof of support or compilability.
- Include every heading in `Output Contract` and exactly one fenced `mermaid` block.

## When Not to Use

- Implementation, source edits, or compile validation: **REQUIRED HANDOFF:** Invoke
  Skill(workflow-code-builder).
- Sync, publish, run, watch, installation, or other lifecycle operations: if
  `workflow-code-operations` is available, use it; otherwise state that the task is outside this
  planning skill.
- Direct Tela API authoring: use the appropriate API workflow skill.

If "workflow" is ambiguous, ask only:

```text
Voce quer uma proposta para Workflow Code source-first ou criacao direta via Tela API?
```

## Method

1. Define the goal, required inputs, final output, and constraints so the proposal has clear
   boundaries.
2. Split stages where responsibility, data contract, uncertainty, side effects, or recovery changes;
   combine adjacent work without a useful boundary. Prefer three to five stages.
3. Give each stage one responsibility, consumed data, expected output, and conceptual behavior.
4. Mark semantic work, deterministic processing, tool use, iteration, routing, aggregation,
   validation, review, and structured-output needs without choosing APIs.
5. Explain every connection, including branch criteria, repeated collections, joins, and review
   return paths, so the builder can preserve the business flow.
6. Record assumptions and only blocking questions.
7. Load `references/proposal-format.md` before answering; it contains the complete template,
   Mermaid rules, and example.

## Output Contract

Use these literal headings in order:

````md
Workflow Code proposal:

Implementation boundary:
- conceptual design only; `workflow-code-builder` will resolve modules and APIs from the installed official documentation
- proposed connections and Mermaid topology express desired behavior, not guaranteed Workflow Code support or compilability

Inputs:
Flow:
Connections:
Expected final output:
```mermaid
flowchart TD
  ...
```
Assumptions:
Open questions:
````

## Handoff to Builder

End with a concise implementation question. If approved, **REQUIRED HANDOFF:** Invoke
Skill(workflow-code-builder) and pass the inputs, ordered stages, dependencies, outputs, behavioral
requirements, assumptions, and open questions. Do not select modules during handoff; the builder
must resolve them from the installed official docs sourced from `@meistrari/workflow-code-page`.

```text
Quer que eu implemente esse workflow com Workflow Code agora?
```

## Examples

<good-example>
Propose “classify each row, route high-risk items, aggregate”; label iteration and routing as
required behavior and defer API mapping.
</good-example>

<bad-example>
Propose `map()` and `condition()` or claim the Mermaid compiles. Those choices belong to the builder
after official-doc discovery.
</bad-example>