@aksp/opencrew 1.10.0 → 1.12.0

package/templates/_opencrew/core/prompts/build.prompt.md

@@ -70,52 +70,24 @@ Generate these files. Use the Write tool for all file creation — never use Bas
 
 ### Files to generate:
 
-1. **`crews/{code}/crew.yaml`** — Crew definition with pipeline
-   - Include a `skills:` section listing all skills:
-     ```yaml
-     skills:
-       - web_search
-       - web_fetch
-       # Add any skills from design.yaml:
-       # - apify
-       # - canva
-     ```
-   - Include a `data:` section listing all reference materials:
-     ```yaml
-     data:
-       - pipeline/data/research-brief.md
-       - pipeline/data/domain-framework.md
-       - pipeline/data/quality-criteria.md
-       - pipeline/data/output-examples.md
-       - pipeline/data/anti-patterns.md
-       - pipeline/data/tone-of-voice.md  # for content crews
-      ```
-    - Include a `fontes:` section with the project sources from `discovery.yaml →
-      project_sources` (omit it only if that list is empty). The Pipeline Runner reads them at the
-      start of every run and checks they still exist:
-      ```yaml
-      fontes:
-        - caminho: Memoria/01_Decisoes.md      # relative to the project root
-          para_que: decisões de público e posicionamento
-      ```
+**Read `_opencrew/core/formato-da-crew.md` before writing any file.** It is the single definition
+of `crew.yaml`, `pipeline.yaml`, the step frontmatter and the agent id, with a complete example of
+each. Write every file in that format; what follows here only adds what is specific to the Build.
+
+1. **`crews/{code}/crew.yaml`** — the crew: the `crew:` block (`code`, `name`, `description`,
+   `icon` and `tier`, all from `design.yaml`), `pipeline:`, `skills:`, `data:`, `fontes:`,
+   `agent_dependencies:` (only when the format file says so) and `max_review_cycles:`.
+    - `skills:` lists every skill from `design.yaml`; `data:` lists every reference material you
+      wrote in `pipeline/data/`.
+    - `fontes:` carries the project sources from `discovery.yaml → project_sources` (`path` →
+      `caminho`, `purpose` → `para_que`); omit it only if that list is empty. The Pipeline Runner
+      reads them at the start of every run and checks they still exist.
     - **Paths to the user's project files** — in `crew.yaml`, step files and tasks — are always
-      written as a caminho relativo à raiz do projeto (relative to the project root), between
-      backticks, e.g. `` `Ativos/Identidade Visual/logo.png` ``. NEVER write absolute paths
+      written as a caminho relativo à raiz do projeto (relative to the project root); in the
+      prose of step files and tasks, between backticks, e.g. `` `Ativos/Identidade Visual/logo.png` ``. NEVER write absolute paths
       (`C:/…`, `J:/…`, `/Users/…`): they break as soon as the user moves or syncs the folder.
-    - Include an `agent_dependencies:` section (OPTIONAL — enables runtime
-      Pre-Execution Agent Selection):
-      ```yaml
-      agent_dependencies:      # OPTIONAL — enables Pre-Execution Agent Selection at runtime
-        copywriter: [researcher]   # copywriter consumes researcher's output
-        designer: [copywriter]     # designer consumes copywriter's output
-        reviewer: [copywriter]     # reviewer consumes copywriter's output
-      ```
-      - `agent_dependencies` is OPTIONAL. ALWAYS emit it for crews that should show the
-        runtime agent-selection step — even as an empty map `agent_dependencies: {}` (the
-        selection step triggers on field presence, so an empty map enables selection with
-        no dependency warnings). Derive entries from the pipeline step order: for each
-        agent step, list the agent(s) whose output it reads via `inputFile`. Omit the field
-        entirely to keep the legacy behavior (run all agents, no selection step).
+    - `agent_dependencies:` — derive the entries from the step order: for each agent step, list
+      the agent(s) whose output it reads, via `inputFile` or in its "Context Loading" list.
 
 2. **`crews/{code}/crew-party.csv`** — Agent manifest
    - The header row MUST be EXACTLY these columns, in this order:
@@ -134,7 +106,7 @@ Generate these files. Use the Write tool for all file creation — never use Bas
      render the agent's name in "🤖 {name} is working…" announcements, and the Escritório
      (the optional live view) shows the same column. If `displayName` is missing, empty, or set
      to the role/title instead of the persona name, the crew renders with functions but no names.
-   - `id` = the `path` basename with `./agents/` and `.agent.md` stripped
+   - `id` = the agent id: the agent file name without `.agent.md`
      (e.g. `./agents/researcher.agent.md` → `researcher`).
    - `title` = the agent's `title:` frontmatter (the role/function label). This is a
      SEPARATE column from `displayName` — never merge or swap them.
@@ -145,7 +117,8 @@ Generate these files. Use the Write tool for all file creation — never use Bas
    - For ALL agents that include `tasks:` in their frontmatter, ALSO generate the task files:
      `crews/{code}/agents/{agent-id}/tasks/{task}.md` — one per entry in the `tasks:` list
 
-4. **`crews/{code}/pipeline/pipeline.yaml`** — Pipeline entry point
+4. **`crews/{code}/pipeline/pipeline.yaml`** — the order of the steps: one `step` + `file` entry
+   per step file, as in the format file
 
 5. **Step files** — `crews/{code}/pipeline/steps/step-NN-{name}.md` — one per pipeline step
 
@@ -185,7 +158,7 @@ Every agent file MUST contain ALL of the following sections. Target 120-200 line
 
 ```markdown
 ---
-id: "crews/{code}/agents/{agent}"
+id: "{agent-id}"                    # the file name without `.agent.md`
 name: "{Agent Name}"
 title: "{Agent Title}"
 icon: "{emoji}"
@@ -392,10 +365,10 @@ Every step file begins with YAML frontmatter followed by the markdown body. The
 ```yaml
 ---
 execution: subagent   # subagent = runs in background via Task tool; inline = runs in the main conversation
-agent: {agent-id}     # the agent's id (matches the id field in their .agent.md frontmatter)
-format: {format-id}   # OPTIONAL — e.g., "instagram-feed". Pipeline Runner auto-injects from _opencrew/core/best-practices/
-                      # Use for content creation steps where platform-specific rules should guide the agent
-                      # Omit for non-content steps (research, analysis, review without platform context)
+agent: {agent-id}     # the agent id: the agent file name without `.agent.md`
+format: {format-id}   # e.g., "instagram-feed". Pipeline Runner auto-injects from _opencrew/core/best-practices/
+                      # REQUIRED on every step whose text the checker measures (from the `on_reject` step up to the review)
+                      # Omit for non-content steps (research, analysis, the review itself)
 inputFile: crews/{code}/output/{filename}.{ext}   # path to input file from previous step — MUST use output/ prefix
 outputFile: crews/{code}/output/{filename}.{ext}  # path where this step saves its output — MUST use output/ prefix
                                                     # NEVER use pipeline/data/ for outputFile — that folder is for static
@@ -410,8 +383,9 @@ side_effects: irreversible  # REQUIRED for any step that publishes, posts, sends
                             # distributes outside the project (it cannot be undone). The Pipeline
                             # Runner never retries these automatically, and Gate 2c places them last.
                             # Omit for every other step.
-max_review_cycles: {N}  # ONLY for the review step: write it next to its `on_reject`.
-                        # By crew tier (`crew.tier` in design.yaml): Express 1, Standard 2, Full 3.
+on_reject: {N}        # ONLY for the review step: the number of the step the pipeline goes back to
+                      # (the first writing step). `max_review_cycles` goes in `crew.yaml`, by crew
+                      # tier (`crew.tier` in design.yaml): Express 1, Standard 2, Full 3.
 ---
 ```
 
@@ -428,7 +402,8 @@ agent: {agent-id}   # OPTIONAL — ties this checkpoint to an agent; if that age
 ---
 ```
 
-For **research focus checkpoints** (where the user's response is saved to a file), use extended frontmatter with `outputFile`:
+For a **checkpoint whose answer the next step needs** (the research focus, the chosen angle, the
+request to be worked on), use extended frontmatter with `outputFile`:
 ```yaml
 ---
 type: checkpoint
@@ -437,7 +412,7 @@ agent: {agent-id}   # OPTIONAL — same semantics as above
 ---
 ```
 The Pipeline Runner writes the user's response to this file before proceeding.
-The next step (researcher) reads it as `inputFile: crews/{code}/output/research-focus.md`.
+The next step reads it as `inputFile: crews/{code}/output/research-focus.md`.
 Using `output/` ensures the path transformation applies and the file lands in the run_id folder.
 
 Every pipeline step file MUST contain ALL of the following sections. Target 60-120 lines per step.
@@ -475,7 +450,7 @@ that the agent knows exactly what to produce.]
 
 [A COMPLETE, realistic example of what this step should produce.
 This is not a template — it's a fully realized output with realistic content.
-Must be 20+ lines and demonstrate the expected quality, depth, and formatting.
+Must be 15+ lines and demonstrate the expected quality, depth, and formatting.
 The agent uses this as a reference for what "good" looks like.]
 
 ## Veto Conditions
@@ -593,7 +568,7 @@ For EACH agent step in the pipeline that produces visuals, renders images, or pu
 If ANY check fails:
 1. Insert a new `type: checkpoint` step immediately before the offending agent step
 2. Renumber all subsequent steps (e.g. step-05 becomes step-06, etc.)
-3. Add the new step to the `checkpoints:` list in pipeline.yaml
+3. Add the new step to `pipeline.yaml`
 4. Generate a step file for the new checkpoint that asks the user to review and approve the preceding agent's output before the visual/publish step runs
 5. Re-validate Gate 2b. Max 2 fix attempts — after that, present to user for manual decision.
 
@@ -602,7 +577,8 @@ If ANY check fails:
 For EACH step that publishes, posts, sends email or distributes outside the project:
 - [ ] Its frontmatter declares `side_effects: irreversible` and `execution: inline`
 - [ ] It comes AFTER the Review step (the reviewer has already approved the final content)
-- [ ] The IMMEDIATELY preceding step is a `type: checkpoint` (Final Approval) that itself comes after the Review
+- [ ] The IMMEDIATELY preceding step is a `type: checkpoint` (Final Approval) that itself comes
+      after the Review, or another irreversible step (two in a row share the same Final Approval)
 - [ ] Only other irreversible steps follow it (nothing is created, rendered or reviewed after publishing)
 
 If ANY check fails:
@@ -631,7 +607,7 @@ Additional programmatic checks — read the filesystem to verify:
 - [ ] Every `agent_dependencies` key and value references a real agent `id` from crew-party.csv
 - [ ] All task files referenced in agent frontmatter exist
 - [ ] All step files referenced in `pipeline.yaml` exist
-- [ ] Skills listed in `crew.yaml` are installed in `skills/`
+- [ ] Skills listed in `crew.yaml` are installed in `skills/` (the native ones, `web_search` and `web_fetch`, need no folder)
 - [ ] Best-practices files referenced by `format:` fields in steps exist in `_opencrew/core/best-practices/`
 
 ---

package/templates/_opencrew/core/prompts/design.prompt.md

@@ -81,7 +81,7 @@ Compile all research into a structured research brief document. This will feed P
 
 After research completes, determine the crew's tier:
 
-1. If a template was used (check `discovery.yaml` → `tier` field is present and not null) → use the template's tier.
+1. If a template was used (`discovery.yaml` has the `template:` field, which the Discovery writes only in that case) → use the `tier` recorded there.
 2. Otherwise, read the default tier from `_opencrew/_memory/preferences.md` → `Default Tier` field.
 3. If neither is set, default to `standard`.
 
@@ -107,10 +107,10 @@ Present the three tiers with concrete trade-offs:
 | Aspect | ⚡ Express | 🎯 Standard | 🔬 Full |
 |--------|-----------|-------------|---------|
 | Agent count | 2-3 | 3-5 | 5-7 |
-| Reviewer | Writer self-reviews | 1 dedicated reviewer | Reviewer + cross-review |
+| Reviewer | The writer does the review step (no reviewer agent) | 1 dedicated reviewer | Reviewer + cross-review |
 | Sherlock | Never | Only if user provided URLs | Always (social + web + trends) |
 | Checkpoints | Final approval only | Research focus + content approval + final | All checkpoints + angle selection |
-| model_tier per step | All `fast` | Mix (research=fast, create=powerful) | All `powerful` |
+| model_tier (subagent steps only) | `fast` | Mix (research=fast, create=powerful) | `powerful` |
 | Cross-review | None | None | Reviewer + second reviewer cross-check |
 | On-reject loops | 1 max | 2 max | 3 max |
 
@@ -182,7 +182,7 @@ From the crew's purpose and domains (in `discovery.yaml`), identify what human r
 | Domain / Need | Possible Roles |
 |---|---|
 | Research, fact-finding, market analysis | 🔎 Pesquisador — finds trends, maps keywords, does market research |
-| Writing, copy, content creation | ✍️ Redator — writes strategic text based on research, including captions and hooks |
+| Writing, copy, content creation, documents | ✍️ Redator — writes strategic text based on research, including captions and hooks; in a document crew, writes the minutes, the letter, the contract or the proposal |
 | Strategy, positioning, planning | 🧠 Estrategista — defines angles, editorial calendar, competitive positioning |
 | Visual design, image creation | 🎨 Designer — creates visual content aligned with brand identity |
 | Quality review, accuracy check | 🔍 Revisor — validates quality, tone, accuracy against criteria |
@@ -219,7 +219,7 @@ Para {crew purpose}, sugiro este time:
   - Simple crews (1 format, 1 platform): 2-3 roles
   - Medium crews (content + review): 3-4 roles
   - Complex crews (multi-platform, multi-format): 4-6 roles
-- **Every crew needs a reviewer** — mandatory quality gate
+- **Every crew needs a review step** — mandatory quality gate (Express: done by the writer; Standard and Full: by a reviewer role)
 - **Allow editing** — after presenting roles, ask:
   > "Quer adicionar, remover ou modificar algum papel? Ou o time está bom?"
 
@@ -229,7 +229,7 @@ Never suggest fewer than 2 roles. The minimum viable crew has:
 - One creator/executor (the person who produces the output)
 - One reviewer (the person who checks quality before delivery)
 
-For very simple tasks, these two roles can be the same person with a self-review step — but the user must explicitly approve this simplification.
+In the Express tier these two roles are the same agent: the writer also does the review step. The step still exists (with `on_reject`), so the automatic checker runs before it.
 
 ---
 
@@ -244,7 +244,7 @@ For each approved role, consult this mapping to determine which skills and best-
 | Role | Typical Skills | Typical Best-Practices |
 |------|---------------|----------------------|
 | Pesquisador (Researcher) | `web_search`, `web_fetch` (native) | `researching.md` |
-| Redator (Writer/Copywriter) | `web_search` (native, for fact-checking) | `copywriting.md` + platform-specific format file |
+| Redator (Writer/Copywriter) | `web_search` (native, for fact-checking) | `copywriting.md` + platform-specific format file; for a text to print, sign or file: `documento-oficial.md`; for a text with no channel and no Word file (proposal, draft that becomes HTML or PDF, plan): `texto-livre.md` |
 | Estrategista (Strategist) | `web_search` (native) | `strategist.md` |
 | Designer (Visual Designer) | `image-creator`, `image-ai-generator`, `canva` | `image-design.md` |
 | Revisor (Reviewer) | None required | `review.md` |
@@ -342,7 +342,7 @@ Based on discovery answers + company context + research findings + extracted art
 
 Before designing any agent from scratch, check the shared registry at `_opencrew/agents/`:
 
-1. List available base agents: `ls _opencrew/agents/` — each `.agent.md` file is a reusable base agent
+1. List the files of `_opencrew/agents/` (with your folder-listing tool, no command) — each `.agent.md` file is a reusable base agent
 2. For each role approved in Phase D, check if a matching base agent exists:
    - Pesquisador → `_opencrew/agents/researcher.agent.md`
    - Redator → `_opencrew/agents/copywriter.agent.md`
@@ -365,7 +365,7 @@ execution: inline
 skills: []
 ---
 ```
-The Build phase copies the base agent from `_opencrew/agents/copywriter.agent.md` and the local file only needs to specify what's DIFFERENT — a different tone, specific output examples for this crew, or additional anti-patterns. The runner merges: base first, local overrides on top.
+The Build phase copies the base agent from `_opencrew/agents/copywriter.agent.md` and the local file only needs to specify what's DIFFERENT — a different tone, specific output examples for this crew, or additional anti-patterns. The Build phase does the merge (base first, local overrides on top) and writes a complete file; the Pipeline Runner never merges.
 
 ### Design Philosophy
 
@@ -380,9 +380,9 @@ Guidelines:
 
 Design the crew with appropriate agents:
 - Follow the deep `.agent.md` format with full sections: Persona (Role, Identity, Communication Style), Principles, Operational Framework, Voice Guidance, Output Examples, Anti-Patterns, Quality Criteria, Integration
-- Design each agent from scratch, informed by the relevant best-practices files read in Phase A
+- Use `extends:` when the Shared Agent Registry Check found a base agent that fits; design from scratch only the agents with no base, informed by the relevant best-practices files read in Phase A
 - Each agent has exactly one clear responsibility
-- Every crew needs a reviewer agent for quality control
+- Every crew needs a review step for quality control (a reviewer agent in Standard and Full)
 - YAGNI — never create agents that aren't strictly necessary
 
 ### Agent Naming Convention (MANDATORY — never skip)
@@ -428,8 +428,7 @@ The name should make someone smile — it's a pun tying a common name to the pro
 
 ### Agent Composition Rules
 
-- One clear responsibility per agent; reviewer agent mandatory; YAGNI strictly applied
-- Research/data steps → `execution: subagent`; creative/writing steps → `execution: inline`
+- One clear responsibility per agent; review step mandatory (reviewer agent in Standard and Full); YAGNI strictly applied
 - Content crews must include `pipeline/data/tone-of-voice.md` and instruct the writer to ask tone before producing
 - Every agent uses `.agent.md` format with all sections: Persona, Principles, Operational Framework, Voice Guidance, Output Examples, Anti-Patterns, Quality Criteria, Integration
 
@@ -441,9 +440,9 @@ The name should make someone smile — it's a pun tying a common name to the pro
 
 - **Research/data-gathering steps** → `execution: subagent` (runs in background via Task tool)
 - **Creative/writing steps** → `execution: inline` (runs in the main conversation)
-- Always include reviewer agent before final output
 - Add checkpoints at every user decision point
-- Include `on_reject` loops from reviewer back to writer
+- The files the Build phase will write follow `_opencrew/core/formato-da-crew.md` (fields of `crew.yaml`, of `pipeline.yaml` and of each step): design nothing that format cannot hold
+- Always include a review step before final output (see the tier table for who does it), with `on_reject`: the number of the first writing step
 - A step whose result is a document to print, sign or file (minutes, official letter, statement, contract, formal report) gets `format: documento-oficial`, in any kind of crew: the writer follows that guide, and the text becomes a Word document in the delivery of the run (or with `/opencrew documento <arquivo>`)
 
 ### Research Focus Checkpoint (MANDATORY for crews with a researcher)
@@ -603,6 +602,7 @@ crew:
   code: "{code}"
   name: "{Crew Name}"
   description: "{one-line description}"
+  icon: "{emoji}"
   tier: "express" | "standard" | "full"
 
 agents:
@@ -656,7 +656,7 @@ pipeline:
   - step: 2
     name: "checkpoint-name"
     type: "checkpoint"
-    output_file: "{path}"        # optional, for research focus checkpoints
+    output_file: "{path}"        # optional, when the next step needs the user's answer
 
 investigation:                   # only if investigation ran
   enriched: true

package/templates/_opencrew/core/prompts/discovery.prompt.md

@@ -7,7 +7,7 @@ You are a strategic systems thinker and patient crew architect. You help users a
 ## Communication Style
 
 - One question at a time — never present two questions in the same message
-- Use numbered lists whenever options are available; tell the user to reply with a number
+- Use numbered lists whenever options are available (the user knows what to do: never add "reply with a number")
 - Adapt follow-up questions based on what the user says, not a fixed script
 - Confirm understanding before moving to the next topic
 - Maximum 8 questions total across the entire discovery flow
@@ -70,7 +70,7 @@ If exactly 1 template exists, still offer option 1 ("Começar do zero") as a sec
 Ask:
 > "What do you want this crew to do? Describe the end result you want."
 
-This is always the first question. Accept any answer — a sentence, a paragraph, bullet points. Do NOT assume any domain. Do NOT suggest options at this stage.
+This is always the first question — except when the command already carried the description (`/opencrew create <description>`): then do not ask it again; repeat the description in one sentence and ask only "É isso? Quer acrescentar alguma coisa?". Accept any answer — a sentence, a paragraph, bullet points. Do NOT assume any domain. Do NOT suggest options at this stage.
 
 ---
 
@@ -80,25 +80,35 @@ After the user answers Step 1, classify their intent into one of the following d
 
 | Domain | Signals in the user's answer |
 |---|---|
+| `document` | minutes (ata), official letter (ofício), contract, proposal, bylaws (estatuto), legal opinion (parecer), formal report, statement: a text to print, sign or file |
 | `content` | posts, articles, videos, captions, social media, campaigns, copy, newsletter, creative, reels, threads |
 | `research` | data, analysis, reports, competitor, market, insights, scraping, summarizing, monitoring |
 | `automation` | workflows, triggers, scheduling, notifications, integrations, pipelines, bots, recurring tasks |
 | `analysis` | metrics, dashboards, KPIs, performance, trends, tracking, visualization |
 | `mixed` | answer spans two or more domains above |
 
+When the request is a text to print, sign or file, the domain is `document` even if the words also fit `content` or `research`.
+
 Save the detected domain as `domain`.
 
 ---
 
 ### Step 3 — Context Exploration (adaptive, ONE question at a time)
 
-Based on the detected domain, ask the most relevant contextual question first. Wait for the answer before asking the next one. Ask at most 2–3 questions in this step.
+Based on the detected domain, ask the most relevant contextual question first. Wait for the answer before asking the next one. Ask at most 3 questions in this step, not counting the project sources question below, which is always asked.
 
 **If domain = `content`:**
 1. Who is this content for? (multiple choice: current customers / potential leads / general audience / other)
 2. What platforms or formats? (wait for answer — do not list formats yet, that comes in Step 6)
 3. What tone or personality should the content have? (multiple choice: professional / casual / educational / entertaining / other)
 
+**If domain = `document`:**
+1. Which documents should the crew produce? (open-ended: ata, ofício, contrato, proposta…)
+2. Who signs each document, and who receives it? (open-ended)
+3. Must the text become a Word file, to print, sign or file? (yes / no — "no" is the proposal or the draft that is read in the chat and laid out by hand later: nothing is converted. Only on a "yes", ask in the same message whether the organization has letterhead — logo, header lines, footer; the letterhead itself is set up later, the first time a Word document is generated)
+
+The project sources question below matters most here: ask which files of the project rule the text (bylaws, previous minutes, price table, contract template).
+
 **If domain = `research`:**
 1. What sources will the crew draw from? (multiple choice: public websites / internal documents / social media / databases / other)
 2. What is the output format? (multiple choice: summary report / structured data / slide deck / raw export / other)
@@ -143,7 +153,9 @@ Do NOT ask the user about tools. Instead:
 
 ### Step 5 — Investigation (optional)
 
-Offer the investigation option to the user. The investigation is powerful but consumes tokens and time — make the trade-off clear:
+**If domain = `document`, skip this step entirely** (set `investigation.enabled: false`): a document crew follows the project's own sources, not reference profiles.
+
+For every other domain, offer the investigation option to the user. The investigation is powerful but consumes tokens and time — make the trade-off clear:
 
 > "Want to investigate reference profiles before building the crew? The investigation analyzes real content from profiles you admire to extract patterns, hooks, and styles. It uses extra tokens and takes a few minutes, but can significantly improve the final quality."
 >
@@ -194,7 +206,8 @@ Set `investigation.enabled: false` and continue.
 
 ### Step 6 — Target Formats (content crews ONLY)
 
-Skip this step entirely for non-content domains.
+If domain = `document`, do not ask: save `target_formats: ["documento-oficial"]` when the text must become a Word file (question 3 of Step 3), or `["texto-livre"]` when it must not. When the crew also produces a short piece for a channel (a WhatsApp notice, an e-mail to the members), add that format id to the list — pick it from the filenames of `_opencrew/core/best-practices/` — and go on.
+Skip this step entirely for the other non-content domains.
 
 If domain = `content`, ask:
 > "Para quais formatos/plataformas esse crew vai produzir conteúdo?"
@@ -254,7 +267,8 @@ project_sources:                     # relative to the project root; becomes `fo
   - path: "{e.g. Memoria/01_Decisoes.md}"
     purpose: "{what the crew uses it for}"
 purpose: "{user's description from Step 1}"
-domain: "{content | research | automation | analysis | mixed}"
+domain: "{document | content | research | automation | analysis | mixed}"
+template: "{template folder name}"    # ONLY when a template was chosen in Step 0; omit the line otherwise
 # When a template was used (Step 0), these fields are populated from discovery.template.yaml:
 domains: []                          # list of domain tags from template (e.g., [content-marketing, seo])
 tier: "standard"                     # from template or preferences Default Tier
@@ -272,6 +286,12 @@ company:
 language: "{user's preferred language}"
 
 context:
+  # For document crews:
+  documents: "{answer from Step 3}"
+  signer: "{who signs}"
+  recipients: "{who receives}"
+  word_file: "{yes | no}"
+  letterhead: "{yes | no | not sure — only when word_file is yes}"
   # For content crews:
   audience: "{answer from Step 3}"
   platforms: "{answer from Step 3}"
@@ -299,7 +319,7 @@ investigation:
       platform: "{instagram | youtube | twitter | linkedin}"
       investigation_mode: "{single_post | profile_1 | profile_3}"
 
-target_formats:  # content crews only; empty list for others
+target_formats:  # content and document crews; empty list for others
   - "{format-id}"
 ```
 
@@ -317,7 +337,7 @@ The `crew_code` must be a short, URL-safe slug derived from the crew's purpose (
 - **NEVER ask more than 8 questions total** — respect the user's time
 - **NEVER ask about tools** — auto-detect from installed skills and include in the summary
 - **NEVER ask about performance mode** — crews are always built lean and agile
-- **Investigation is always offered** — Step 5 presents the option for all domains, not just content
+- **Investigation is offered to every domain except `document`** — Step 5 presents the option; a document crew skips it
 - **Target formats are content-only** — Step 6 is skipped entirely for non-content crews
 - **One question at a time** — never combine two questions in one message, even if they feel related
 - **Domain detection is silent** — do not announce "I detected your domain is X"; just use the classification internally

package/templates/_opencrew/core/prompts/documento.prompt.md

@@ -37,10 +37,12 @@ Este projeto ainda não tem papel timbrado configurado. Quer configurar agora (l
   1. Run, from the project root: `node _opencrew/core/scripts/documento.mjs --criar-perfil`
      Its last line is `PERFIL:CRIADO` (the file was created from the model) or `PERFIL:JA-EXISTE`
      (it was already there and was not touched).
-  2. Ask the user for: the logo (a PNG file of up to 2 MB that is inside the project, with its
-     path from the root — or none), the three lines of the header (the name of the organization;
-     a second line; a third line, such as site and e-mail) and the text of the footer. Any of them
-     may stay empty: what is empty does not appear in the document.
+  2. Ask the user three questions, one at a time, with these words (the logo is a PNG file of up
+     to 2 MB inside the project, given by its path from the root):
+     - "Qual é o arquivo do logotipo? (PNG, dentro do projeto. Pode responder 'sem logotipo'.)"
+     - "Quais são as linhas do cabeçalho? Até três: nome da entidade, CNPJ ou registro, endereço."
+     - "Quer um texto no rodapé, além de 'Página X de Y'?"
+     Any of them may stay empty: what is empty does not appear in the document.
   3. Fill the file `_opencrew/_memory/documento-oficial.md` with the answers: write only the value
      after the colon of `logotipo`, `cabecalho_1`, `cabecalho_2`, `cabecalho_3` and `rodape`, each
      exactly as the user gave it. Leave every other line as it is (comments, margins, font).
@@ -103,7 +105,9 @@ one message in PT-BR and stops, with nothing written). Show the message to the u
 
 - **The message points to something in the command you wrote** (an option, a path, more than one
   file): fix the command and run it once more.
-- **The message starts with "Perfil, linha {n}:"** (an unknown key, a value out of range, a logo
+- **"Não encontrei {arquivo}." or "Só converto texto…"**: the file is not there, or it is not a
+  `.md` or `.txt`. Show the message and go back to the question of Step 1.
+- **The message starts with "Perfil, linha {n}:"** (an unknown or misspelled key, a value out of range, a logo
   that is missing, is not a PNG or is over 2 MB): the document is not generated with a wrong
   letterhead. Show the message, ask the user for the right value of that line, write it in the
   profile and run again. Do not switch to `--sem-perfil` by yourself.

package/templates/_opencrew/core/prompts/entrega.prompt.md

@@ -69,7 +69,8 @@ without the `ENTREGA:` line. Do not rewrite it and do not add files it does not
 the report of the check made at delivery time (it is not part of the delivery).
 
 - `ENTREGA:OK` → go on with the run (Step 5 first, when it applies). When the summary has a line
-  `
+  that starts with "Sem papel timbrado:", the Word documents came out with no letterhead: say so
+  and offer to set it up (`/opencrew documento`); after the profile exists, deliver again.
 - `ENTREGA:COM_RESSALVA` → everything that was missing is a ressalva the user accepted: the
   `LEIA-ME.md` opens with it and the channel is "Pronto, com ressalva"; go on as with `ENTREGA:OK`.
 - `ENTREGA:INCOMPLETA` → a channel is not ready, the destination was refused or a file could not be
@@ -103,7 +104,11 @@ the report of the check made at delivery time (it is not part of the delivery).
     "Não consegui gravar …"): show the message as it came and ask for another folder (Step 5, with
     the new answer) or for a new attempt, which is the same command again. A file of the list that
     does not exist: ask for it, or take it out of the list.
-  - **A Word document that was not generated** (the line `
+  - **A Word document that was not generated** (the line "Não consegui gerar o Word de
+    {arquivo}: …"): show the message as it came; this is never accepted with option 2. When the
+    reason starts with "Perfil, linha {n}:", the letterhead profile has a wrong line: ask the user
+    for the right value, write it in `_opencrew/_memory/documento-oficial.md` and run the same
+    command again.
   The first call never has `--aceitar-pendencias`. Outside option 2 it goes only when the user
   already chose "Aceitar assim mesmo" in the review loop of this run and what is missing is only
   what was accepted there: then run the command again with it, without asking.