---
name: workflow-code-builder
description: Use when creating, implementing, editing, or explicitly migrating source-first Tela workflows using @meistrari/workflow-code, workflow-code.config.ts, or *.workflow.ts files.
---

# Workflow Code Builder

## Non-Negotiable Rules

- Only the checksummed `tela workflow docs` bundle sourced from
  `@meistrari/workflow-code-page` is authoring truth.
- No verified docs: no implementation mapping or source edit. No successful compile: no lifecycle
  handoff.
- Ignore memory, README/types, copied references, group help, web docs, and checkouts.
- Edit only requested source-first files; never substitute direct Tela API graphs or Workflow V3
  payloads.

## Routing

- Proposal or Mermaid only: **REQUIRED SUB-SKILL:** Invoke Skill(workflow-code-builder-framework),
  then stop before edits.
- Non-trivial implementation without an agreed flow: invoke the framework first, then resume here.
- Lifecycle/setup work: after compile, use `workflow-code-operations` if available; otherwise stop
  at compiled source and state the boundary. Its absence does not block implementation.
- Direct Tela API authoring is outside this skill.
- Ask one focused question only when a required input, target, or business rule is missing.

If "workflow" is ambiguous, ask only:

```text
Voce quer Workflow Code source-first no repo ou criacao direta via Tela API?
```

## Load the Installed Documentation

Before implementation mapping or source edits:

1. Run `tela --version`.
2. Run `tela workflow docs --json`. Verify `packageName: @meistrari/workflow-code`,
   `packageVersion`, `sourcePackage: @meistrari/workflow-code-page`, and the complete page catalog.
3. Load only relevant pages with `tela workflow docs <page> --json`: `api-reference` (authoring),
   `quick-start` (first workflow), `config`, `cli` (compile/diagnostics), or `guides`
   (troubleshooting).
4. Derive commands and version-sensitive choices from returned content, never conversation examples.
5. Inspect target config, workflow, and nearby `*.workflow.ts`; preserve style and scope.
6. Map the agreed flow to documented capabilities; never change business behavior silently.
7. Implement narrowly; compile from the `cli` page with structured diagnostics until successful.
8. Report changed files, useful provenance, and compile result.

Docs commands are local/read-only. Reload after CLI-version or contract-area changes.

## Documentation Failure

On a missing, unreadable, checksum-invalid, or wrongly sourced catalog/page:

1. Preserve the exact `code`, `severity`, `message`, and `hint`.
2. Use only `tela --version` and `tela workflow --help`; group help proves registration/syntax only.
3. Do not probe nested `--help`, edit source, or mutate remotely.
4. Recommend CLI repair/update and retry discovery.

## Quick Reference

| Need | Action |
| --- | --- |
| Conceptual flow | Invoke framework |
| Author or compile | Load `api-reference` and `cli` |
| Lifecycle operation | Optional operations handoff after compile |

## Common Rationalizations

| Thought | Correction |
| --- | --- |
| “The types show it.” | Not the availability contract. |
| “Help lists the command.” | Not authoring support. |
| “Compile can wait.” | Compile is the local completion gate. |

Red flags: remembered helpers, concrete APIs before docs, direct graph fallback, remote work before
compile, or claiming completion in a response-only simulation.

## Examples

<good-example>
Read catalog/pages, map the proposal, edit narrowly, compile, then hand off.
</good-example>

<bad-example>
Import a remembered helper or run lifecycle commands before documented compile succeeds.
</bad-example>