factoryhub 0.0.0-stage → 0.1.1

package/factories/launch-kit/flow.yaml

@@ -0,0 +1,75 @@
+flow: mindburn.flow/v1
+title: Launch kit
+author: Mindburn Labs
+version: "1.2.0"
+license: MIT
+tags: [marketing, launch]
+time: about 4 minutes
+inputs:
+  product:
+    type: longtext
+    help: "What you are launching, what it does, the price and anything true you can say about results or customers."
+  audience:
+    type: text
+    help: "Who it is for, as specifically as you can, for example \"freelance bookkeepers with 10 to 40 clients\"."
+  site:
+    type: url
+    optional: true
+    help: "Your current website, to match the voice."
+  launch_offer:
+    type: text
+    optional: true
+    help: "Any launch offer and its end condition, for example \"20% off for the first 50 customers\"."
+  market_research:
+    type: longtext
+    optional: true
+    help: "Source-linked market research to inform positioning. Keep product claims grounded in the product facts."
+steps:
+  positioning:
+    title: Find the positioning
+    agent: strategist
+    kind: work
+    tools: [web_fetch]
+    task: |
+      If market_research was given, use its sourced comparisons to explain differentiation without treating competitor facts as facts about this product. If a site was given, read its home page to learn the voice and existing claims. Then write the positioning: the audience and the moment they need this, the problem in their words, the promise in one sentence of under 15 words, three reasons to believe it (each tied to a fact from the product input), what it replaces, and the one objection most likely to stop a purchase with an honest answer. Offer two alternative promise sentences below the main one. Describe the voice in one line. Use no fact that is not in the inputs or on the site.
+  approve_positioning:
+    title: Agree the positioning
+    kind: approve
+    needs: [positioning]
+    shows: positioning
+    task: |
+      Everything else is written from this. Approve it, pick one of the alternative promises, or correct anything that is wrong about your product or audience.
+  landing_page:
+    title: Write the landing page
+    agent: writer
+    kind: work
+    needs: [approve_positioning]
+    task: |
+      Write the landing page from the approved positioning: headline (the promise), a line under it, the main button text, a "how it works" section with three steps, the three reasons to believe as short sections, the objection and its answer, the price and the launch offer if one was given, and a closing call to action. Mark every place where a real testimonial, screenshot or number should go as "[ADD: what belongs here]" instead of inventing one.
+  messages:
+    title: Write the emails and posts
+    agent: writer
+    kind: work
+    needs: [approve_positioning]
+    task: |
+      In the same voice write: a launch email under 180 words with two subject lines; three follow-up emails under 100 words each for days 2, 4 and 6, each making one new point (a reason to believe, the objection answered, the offer ending); and five short posts for social channels, each standing alone and each opening differently. State the launch offer exactly as given, with its end condition.
+  kit:
+    title: Package the kit
+    agent: writer
+    kind: deliver
+    needs: [landing_page, messages]
+    task: |
+      Assemble the kit in this order: **Positioning** (the approved version, one short block), **Landing page** (full draft), **Launch email**, **Follow-up emails** (with the day for each), **Posts**, and **Before you publish**: a checklist of every "[ADD: ...]" placeholder and any claim you should double-check, plus the order to publish the pieces in.
+  check_messages:
+    title: Check the kit
+    agent: reviewer
+    kind: check
+    needs: [kit]
+    checks: kit
+    task: |
+      Review every piece of the assembled kit, including the landing page. Every factual product, price, result, customer or offer claim is supported by the inputs or positioning. Every piece uses the approved promise and voice. No invented testimonial, number, customer name or deadline appears. The offer and end condition match the input. Requested word limits and section counts are met, and every missing asset remains marked and appears in the checklist.
+
+done:
+  - "Every piece uses the approved promise and the same voice."
+  - "No claim appears that the inputs do not support."
+  - "Every gap that needs a real asset is marked, not filled in."

package/factories/meeting-to-actions/CHANGELOG.md

@@ -0,0 +1,7 @@
+# Changes
+
+## 1.1.1
+
+Adds an executable example covering agreed actions, unanswered questions and
+missing owners or deadlines. Includes a model recommendation and a bounded
+short-input cost estimate. The workflow and its six output sections are unchanged.

package/factories/meeting-to-actions/README.md

@@ -0,0 +1,15 @@
+# Meeting to actions
+
+Paste the notes or transcript. You get what was decided, who does what by when, what is still open, and the follow-up message for everyone who was there. It only reports what the notes support, and it tells you where an owner or a date was never agreed.
+
+The included example uses invented notes with an agreed action, an unowned task
+and an undecided question. The result must keep those distinctions; drafting a
+follow-up does not send it. Read the result before sending it.
+
+Run the example on the Hub or with
+`node run.mjs --test --provider anthropic --model claude-haiku-5-5`. Passing text checks are
+a repeatable regression signal, not proof that every transcript will be handled
+correctly. The package includes the model recommendation and the basis of its
+short-input cost estimate; no minimum model has been established. Hosted trials
+used Haiku for writing and Sonnet for review. The local command uses Haiku for
+both, so its quality and cost must be checked separately.

package/factories/meeting-to-actions/agents/analyst/agent.md

@@ -0,0 +1,10 @@
+---
+description: Turns raw material into structured findings that can be checked.
+agentType: CUSTOM
+---
+
+You are the analyst. You take what the person gave and what earlier steps found, and turn it into structured findings: tables, ranked lists, statuses.
+
+- Every finding points at the exact words, file or fact it rests on.
+- You never assume what the material does not show. Where something cannot be told, you say what is missing.
+- You rank by what matters most to the person's goal, and you keep to the counts and shapes the step asks for.

package/factories/meeting-to-actions/agents/reviewer/agent.md

@@ -0,0 +1,10 @@
+---
+description: Checks work against stated criteria and sends weak work back.
+agentType: REVIEW
+---
+
+You are the reviewer. You hold one piece of work against the criteria you are given and decide whether it passes.
+
+- You judge only what is on the page and only against the stated criteria.
+- You fail work for a clear, specific breach you can point to. You never fail it for taste, or for something nobody asked for.
+- When you send work back, each reason is one concrete sentence the author can act on.

package/factories/meeting-to-actions/agents/writer/agent.md

@@ -0,0 +1,11 @@
+---
+description: Writes the finished words the person will use or send.
+agentType: CUSTOM
+---
+
+You are the writer. You write the finished thing the person will use: the brief, the message, the page, the report.
+
+- Plain words, short sentences, the reader's own vocabulary. No filler and no hype.
+- You keep to the sections, word limits and order the step asks for.
+- You add no fact that is not in the inputs or earlier results. Where a real asset or decision is missing, you mark the gap clearly instead of inventing it.
+- What you write should be usable as it stands.

package/factories/meeting-to-actions/factory.yaml

@@ -0,0 +1,11 @@
+schemaVersion: v1alpha1
+name: meeting-to-actions
+description: |
+  Turns rough meeting notes or a transcript into decisions, owned actions with
+  dates, open questions and a follow-up message ready to send. Use right after
+  any meeting where things were agreed.
+repositories: []
+agentDefaults:
+  harness:
+    type: claude
+    model: claude-haiku-5-5

package/factories/meeting-to-actions/flow.yaml

@@ -0,0 +1,53 @@
+flow: mindburn.flow/v1
+title: Meeting to actions
+author: Mindburn Labs
+version: "1.1.1"
+license: MIT
+tags: [operations, productivity]
+time: about 1 minute
+inputs:
+  notes:
+    type: longtext
+    help: "The meeting notes or transcript, as rough as they are."
+  context:
+    type: text
+    optional: true
+    help: "Who met and why, for example \"weekly call with the Halden client about the website launch\"."
+steps:
+  extraction:
+    title: Extract what was agreed
+    agent: analyst
+    kind: work
+    task: |
+      Read the notes and pull out four lists. Decisions: what was decided, in one sentence each. Actions: the task, the owner as named in the notes, and the due date as stated. Open questions: things raised and not settled. Risks: anything someone flagged as a worry.
+
+      Where an action has no owner or no date in the notes, write "owner not agreed" or "date not agreed": never assign one yourself. After each item put a short quote from the notes that supports it. Leave out small talk and anything said but not agreed.
+  followup:
+    title: Write the follow-up
+    agent: writer
+    kind: deliver
+    needs: [extraction]
+    task: |
+      Write the follow-up. Sections, in this order:
+
+      1. **Summary**: two sentences on what the meeting settled.
+      2. **Decisions**: a numbered list.
+      3. **Actions**: a table with columns Action, Owner, Due. Keep "not agreed" where it applies.
+      4. **Still open**: the open questions, and for each the person best placed to answer, if the notes say.
+      5. **To confirm**: every missing owner or date as a direct question.
+      6. **Message to send**: a follow-up message to the attendees under 150 words, covering decisions, actions and the questions to confirm, ready to paste into email or chat.
+
+      Do not include the supporting quotes in the follow-up.
+  check_extraction:
+    title: Check against the notes
+    agent: reviewer
+    kind: check
+    needs: [followup]
+    checks: followup
+    task: |
+      Compare the entire follow-up with the original notes. Every agreed decision and action is included; no owner, due date or fact was invented. Missing owners and dates remain explicit. The action table and message agree. All requested sections are present and the message meets its word limit. Supporting quotes need not appear in the final document.
+
+done:
+  - "Every action has an owner and date, or says plainly that one was not agreed."
+  - "Nothing appears that the notes do not support."
+  - "The message can be sent without editing."

package/factories/meeting-to-actions/mindburn.requirements.yaml

@@ -0,0 +1,8 @@
+models:
+  recommended: claude-haiku-5-5
+expected_cost:
+  currency: USD
+  min: 0.008
+  max: 0.02
+  model: claude-haiku-5-5 (writing) + claude-sonnet-5-5 (review)
+  basis: Short-note hosted trials used two Haiku writing calls and one Sonnet review call, with estimated model costs of USD 0.0088128 and 0.0148114. This range applies to that mixed-model configuration, not a Haiku-only local run. Larger transcripts and retries can cost more. Excludes hosting and tool fees; this is an estimate, not a spending cap.

package/factories/meeting-to-actions/mindburn.tests.yaml

@@ -0,0 +1,16 @@
+version: 1
+cases:
+  missing_commitments:
+    name: Keeps agreed actions and makes missing commitments explicit
+    inputs:
+      notes: |
+        Decision: use the compact onboarding form.
+        Dana agreed to email the revised form to Lee. No deadline was agreed.
+        Someone needs to confirm who maintains the help page. Nobody took that task.
+        The team discussed a free trial but made no decision about offering it.
+      context: Planning for a small product team. These are invented example notes.
+    expect:
+      contains: [Dana, Lee, onboarding, help page, free trial, not agreed]
+      excludes: [sent successfully, already emailed]
+      min_length: 200
+      max_length: 6000

package/factories/newsletter-note/README.md

@@ -0,0 +1,11 @@
+# Newsletter note from the facts
+
+Paste the facts sheet of a video, podcast or talk, and the transcript if you have it. You get a note under 120 words for your newsletter that says what the video is about and points readers to it, with "[ADD: link to the video]" where the link goes. A checker holds every sentence against the facts sheet and sends back anything stronger than what you said.
+
+The facts sheet can come from "Facts from a video", or you can write your own: one fact a line, each with its timestamp or the first words of the line. "Release desk" puts the note together with the other pieces for one approval.
+
+## Try it on the example
+
+The example is invented: Maya, her flat and her video do not exist. Its facts sheet is the one "Facts from a video" should write from her transcript. On the factory page, "Fill in the example" pastes it for you.
+
+The example is in `mindburn.tests.yaml`. With the downloaded folder, `node run.mjs --test` runs it and checks that the note leaves the link for you and makes none of the easy roundings. Passing checks are a repeatable regression signal, not proof that every facts sheet will be handled correctly.

package/factories/newsletter-note/agents/reviewer/agent.md

@@ -0,0 +1,10 @@
+---
+description: Checks work against stated criteria and sends weak work back.
+agentType: REVIEW
+---
+
+You are the reviewer. You hold one piece of work against the criteria you are given and decide whether it passes.
+
+- You judge only what is on the page and only against the stated criteria.
+- You fail work for a clear, specific breach you can point to. You never fail it for taste, or for something nobody asked for.
+- When you send work back, each reason is one concrete sentence the author can act on.

package/factories/newsletter-note/agents/writer/agent.md

@@ -0,0 +1,11 @@
+---
+description: Writes the finished words the person will use or send.
+agentType: CUSTOM
+---
+
+You are the writer. You write the finished thing the person will use: the brief, the message, the page, the report.
+
+- Plain words, short sentences, the reader's own vocabulary. No filler and no hype.
+- You keep to the sections, word limits and order the step asks for.
+- You add no fact that is not in the inputs or earlier results. Where a real asset or decision is missing, you mark the gap clearly instead of inventing it.
+- What you write should be usable as it stands.

package/factories/newsletter-note/factory.yaml

@@ -0,0 +1,12 @@
+schemaVersion: v1alpha1
+name: newsletter-note
+description: |
+  Writes a short newsletter note, under 120 words, that tells your readers
+  what your new video, podcast or talk is about and points them to it, using
+  only the facts sheet. Use after "Facts from a video", or with your own list
+  of what you said, when you want to send your list a note in your voice.
+repositories: []
+agentDefaults:
+  harness:
+    type: claude
+    model: sonnet

package/factories/newsletter-note/flow.yaml

@@ -0,0 +1,45 @@
+flow: mindburn.flow/v1
+title: Newsletter note from the facts
+author: Mindburn Labs
+version: "1.0.0"
+license: MIT
+tags: [social, marketing]
+time: about 1 minute
+inputs:
+  facts:
+    type: longtext
+    help: "The facts sheet from \"Facts from a video\", or your own list of what you said: one fact a line, each with its timestamp or the first words of the line."
+  transcript:
+    type: longtext
+    optional: true
+    help: "The transcript the facts came from. With it, the note can use your exact wording."
+  about_you:
+    type: text
+    optional: true
+    help: "Who you are and who reads your newsletter, for example \"I make short videos about building small apps; most of my readers are students\". It sets the voice, not the facts."
+steps:
+  note:
+    title: Write the newsletter note
+    agent: writer
+    kind: deliver
+    task: |
+      Write a note for the speaker's newsletter that tells readers what the video is about and points them to it, in the speaker's voice and, wherever you can, in the speaker's own words as the facts sheet quotes them. Use about_you only for the voice and the audience, never as a source of facts. Sections, in this order:
+
+      1. **Newsletter note**: under 120 words, with "[ADD: link to the video]" where the link goes.
+      2. **Facts used**: every factual claim the note makes, each with the facts-sheet ID if the sheet has IDs, its timestamp or first words, and the exact words it rests on.
+
+      Every fact comes from the facts sheet. If the transcript is given, you may take the speaker's exact wording from it, but only for facts the sheet has. Never round a number, shorten or lengthen a time span, make a result bigger or more certain, drop a qualifier that keeps a claim modest, state an opinion as a fact, work out a figure the sheet does not state, or name a person the sheet does not name. A fact the sheet marks "unclear" is not stated as settled. Write no link, address or date yourself. Add no hype the speaker did not use, and no exclamation marks or emojis unless the sheet quotes them.
+  check_note:
+    title: Check the note against the facts sheet
+    agent: reviewer
+    kind: check
+    needs: [note]
+    checks: note
+    task: |
+      Compare every sentence of the note with the facts sheet, and with the transcript if it is given. Each number, time span, name, result and quote is on the facts sheet with the same meaning. Send back anything rounded, worked out, made bigger or more certain, a dropped qualifier, an opinion stated as fact, a fact marked "unclear" stated as settled, a quote that is not word for word, and any fact the sheet does not have.
+
+      Then check the shape: both sections are present and in order, the note is under 120 words, "[ADD: link to the video]" appears in it and no other link or address does, and every factual claim appears under "Facts used". When you send work back, quote the note's words and the source's words side by side so the writer can correct them.
+done:
+  - "Every number, time span, name and quote in the note is on the facts sheet, with the same meaning."
+  - "The note is under 120 words and marks the link with \"[ADD: link to the video]\" instead of inventing one."
+  - "Every factual claim is listed under \"Facts used\" with the words it rests on."

package/factories/newsletter-note/mindburn.tests.yaml

@@ -0,0 +1,80 @@
+version: 1
+cases:
+  frying_pan_note:
+    name: Writes a short note that leaves the link for the speaker to add
+    inputs:
+      facts: |
+        ## Facts
+
+        | ID | Where | Fact | Exact words |
+        | --- | --- | --- | --- |
+        | F1 | [0:00] | The video is the story of how a frying pan made the speaker build an app. | "So this is the story of how a frying pan made me build an app." |
+        | F2 | [0:06] | The flat's group chat had 212 messages in one month; the speaker counted them. | "Our flat group chat had 212 messages in one month. I counted." |
+        | F3 | [0:06] | Most of those messages were about one frying pan that nobody would wash. | "Most of them were about one frying pan that nobody would wash." |
+        | F4 | [0:18] | Five people live in the flat. | "There are five of us in the flat." |
+        | F5 | [0:18] | Everyone thought they did the most dishes, and everyone was wrong, the speaker included. | "Everyone thought they did the most dishes. Everyone was wrong, including me." |
+        | F6 | [0:31] | The speaker is not a programmer: one coding course at school, most of it forgotten. | "I'm not a programmer. I did one coding course at school and forgot most of it." |
+        | F7 | [0:31] | The speaker had been using an AI coding assistant for small things. | "But I'd been using an AI coding assistant for small things" |
+        | F8 | [0:47] | The app took two weekends, maybe three counting the weekend spent on the logo. | "It took me two weekends. Maybe three, if you count the weekend I spent on the logo." |
+        | F9 | [0:55] | The speaker's first lesson: a whole Saturday went on a logo, and nobody has ever mentioned it. | "I spent a whole Saturday on a logo, and not one person has ever mentioned the logo. Not one." |
+        | F10 | [1:06] | When something needs washing, you tap one button, and the app messages the one person who has done the fewest dishes this week. | "When something needs washing, you tap one button. The app looks at who has done the fewest dishes this week and sends that one person a message." |
+        | F11 | [1:06] | The app has no points, no leaderboard and no badges. | "No points, no leaderboard, no badges." |
+        | F12 | [1:27] | Points came first and made it worse: one flatmate washed single teaspoons to collect points. | "I tried points first. Points made it worse. One flatmate started washing single teaspoons to collect points." |
+        | F13 | [1:38] | The speaker's opinion, called a hot take: most chore apps fail because they turn chores into a game. | "So here's my hot take: most chore apps fail because they turn chores into a game." |
+        | F14 | [1:38] | Nobody in the flat wanted a game; they wanted the arguing to stop. | "Nobody in my flat wanted a game. We wanted the arguing to stop." |
+        | F15 | [1:50] | The group chat went from 212 messages to 9 messages last month, and three of those were about pizza. | "The group chat went from 212 messages to, I checked last night, 9 messages last month. And three of those were about pizza." |
+        | F16 | [2:04] | After a friend posted about it, people from other flats started asking for it. | "Then a friend posted about it, and people from other flats started asking for it." |
+        | F17 | [2:04] | 38 people signed up in the first week, mostly friends of friends. | "38 people signed up in the first week. Mostly friends of friends, to be fair." |
+        | F18 | [2:04] | 11 of them used it again the next day. | "11 of them used it again the next day, which for an app about dishes I'll take." |
+        | F19 | [2:22] | Running it costs three pounds a month, after a correction. | "It costs me about four, no, three pounds a month to run. Three." |
+        | F20 | [2:28] | What the speaker would do differently: skip the logo, and ask the flatmates what annoyed them before writing a single line. They guessed fairness; it was the frying pan. | "What I'd do differently: skip the logo, and ask my flatmates what annoyed them before writing a single line. I guessed it was fairness. It was the frying pan." |
+        | F21 | [2:42] | The speaker's advice: start with the one message the app sends, and write that message first. | "If you build something like this, start with the one message the app sends. Write that message first. Everything else is decoration." |
+        | F22 | [2:51] | The pan is clean, for now. | "The pan is clean. For now." |
+
+        ## Quotes worth using
+
+        - [0:06] "Our flat group chat had 212 messages in one month. I counted." (F2)
+        - [0:55] "not one person has ever mentioned the logo. Not one." (F9)
+        - [1:06] "No points, no leaderboard, no badges." (F11)
+        - [1:27] "One flatmate started washing single teaspoons to collect points." (F12)
+        - [1:38] "We wanted the arguing to stop." (F14)
+        - [2:28] "I guessed it was fairness. It was the frying pan." (F20)
+        - [2:42] "Write that message first. Everything else is decoration." (F21)
+        - [2:51] "The pan is clean. For now." (F22)
+
+        ## Corrections and unclear
+
+        - [2:22] The running cost: the speaker says "about four, no, three pounds a month", then "Three." The corrected figure, three pounds a month, is the fact (F19).
+        - [0:47] and [0:55] The time on the logo is said two ways: "the weekend I spent on the logo" and "a whole Saturday on a logo". Unclear: quote each where it is said, and do not state how long the logo took.
+
+        ## Names
+
+        No one other than the speaker is named.
+      transcript: |
+        [0:00] So this is the story of how a frying pan made me build an app.
+        [0:06] Our flat group chat had 212 messages in one month. I counted. Most of them were about one frying pan that nobody would wash.
+        [0:18] There are five of us in the flat. Everyone thought they did the most dishes. Everyone was wrong, including me.
+        [0:31] I'm not a programmer. I did one coding course at school and forgot most of it. But I'd been using an AI coding assistant for small things, and I thought, okay, how hard can a dishes app be?
+        [0:47] It took me two weekends. Maybe three, if you count the weekend I spent on the logo.
+        [0:55] And that's my first lesson. I spent a whole Saturday on a logo, and not one person has ever mentioned the logo. Not one.
+        [1:06] Here's how it works, and honestly the trick is how little it does. When something needs washing, you tap one button. The app looks at who has done the fewest dishes this week and sends that one person a message. That's it. No points, no leaderboard, no badges.
+        [1:27] I tried points first. Points made it worse. One flatmate started washing single teaspoons to collect points.
+        [1:38] So here's my hot take: most chore apps fail because they turn chores into a game. Nobody in my flat wanted a game. We wanted the arguing to stop.
+        [1:50] Did it work? The group chat went from 212 messages to, I checked last night, 9 messages last month. And three of those were about pizza.
+        [2:04] Then a friend posted about it, and people from other flats started asking for it. 38 people signed up in the first week. Mostly friends of friends, to be fair. 11 of them used it again the next day, which for an app about dishes I'll take.
+        [2:22] It costs me about four, no, three pounds a month to run. Three.
+        [2:28] What I'd do differently: skip the logo, and ask my flatmates what annoyed them before writing a single line. I guessed it was fairness. It was the frying pan. It's always one frying pan.
+        [2:42] If you build something like this, start with the one message the app sends. Write that message first. Everything else is decoration.
+        [2:51] Anyway. The pan is clean. For now.
+      # Invented sample: Maya, her flat and this video do not exist. The
+      # disclosure stays out of the inputs so it does not leak into the result;
+      # the README carries it.
+      about_you: "I'm Maya. I make short videos about building small apps; most of my viewers are students and first-time builders."
+    # The facts sheet is the reference result of "Facts from a video" on the
+    # same transcript. Contains: the placeholder for the link, never an invented
+    # one. Excludes: the roundings the transcript invites and claims she never made.
+    expect:
+      contains: ["[ADD: link to the video]", "Facts used", "frying pan"]
+      excludes: ["went viral", "in one weekend", "in a weekend", "40 people", "nearly 40", "almost 40", "never coded", "£4", "four pounds a month", "96%", "29%"]
+      min_length: 400
+      max_length: 4000

package/factories/outreach-pack/README.md

@@ -0,0 +1,3 @@
+# Outreach pack
+
+Provide checked research, approved launch materials and optionally a contact role. The factory writes and checks drafts for you to review and send. It does not collect contacts, publish or send messages.

package/factories/outreach-pack/agents/reviewer/agent.md

@@ -0,0 +1,5 @@
+---
+description: Checks claims, evidence and message constraints.
+agentType: REVIEW
+---
+Judge the complete artifact against the stated criteria. Fail unsupported claims and invented personal details with specific reasons.

package/factories/outreach-pack/agents/writer/agent.md

@@ -0,0 +1,5 @@
+---
+description: Writes specific, honest outreach from supplied evidence.
+agentType: CUSTOM
+---
+Write plain messages with one clear ask. Preserve source links and uncertainties. Never imply an email was sent or a campaign was activated.

package/factories/outreach-pack/factory.yaml

@@ -0,0 +1,9 @@
+schemaVersion: v1alpha1
+name: outreach-pack
+description: |
+  Turns checked market research and launch materials into an outreach pack. Use when the positioning is approved and you need messages to review and send yourself.
+repositories: []
+agentDefaults:
+  harness:
+    type: claude
+    model: sonnet

package/factories/outreach-pack/flow.yaml

@@ -0,0 +1,42 @@
+flow: mindburn.flow/v1
+title: Outreach pack
+version: "1.0.0"
+author: Mindburn Labs
+license: MIT
+tags: [sales, launch]
+inputs:
+  research:
+    type: longtext
+    help: Source-linked market research with uncertainties preserved.
+  launch_materials:
+    type: longtext
+    help: Approved positioning and checked launch materials.
+  contact_role:
+    type: text
+    optional: true
+    help: The role you want to reach.
+steps:
+  angles:
+    title: Find the outreach angle
+    agent: writer
+    kind: work
+    task: |
+      Use the supplied launch_materials and research to identify two honest reasons the contact_role might care. Each must tie to a supported problem, the approved promise, and a source when based on market research. Never invent a prospect, a personal fact, a customer result, a contact address or a claim.
+  pack:
+    title: Write the outreach pack
+    agent: writer
+    kind: deliver
+    needs: [angles]
+    task: |
+      Produce a reusable outreach pack with: the chosen angle and evidence; two subject lines of at most four words; a first email under 110 words with one small question; a follow-up under 60 words adding a supported point; a short direct message under 60 words; and a before-sending checklist. Use explicit [ADD: ...] placeholders for the real recipient, their verified situation and missing facts. Preserve the approved product promise. State that no messages have been sent and no contacts have been collected. This is a draft for human review, not an active campaign.
+  review:
+    title: Check the outreach pack
+    agent: reviewer
+    kind: check
+    needs: [pack]
+    checks: pack
+    task: |
+      Every product claim matches launch_materials. Every market claim matches research and keeps its source. No personal detail, email address, customer result or recipient-specific claim is invented. Required sections and word limits are met. Placeholders remain explicit. The pack says messages have not been sent.
+done:
+  - Every claim is supported by the supplied research or launch materials.
+  - Recipient details that are not known remain explicit placeholders.

package/factories/prospect-brief/README.md

@@ -0,0 +1,3 @@
+# Prospect brief and first email
+
+Give it a company and what you sell. It reads the company's own site and recent public news, finds the reasons they might care right now, lets you pick the angle, and writes an email a person would actually answer. Nothing is sent: you get the drafts.

package/factories/prospect-brief/agents/researcher/agent.md

@@ -0,0 +1,11 @@
+---
+description: Finds and reads the sources, and reports only what they say.
+agentType: CUSTOM
+---
+
+You are the researcher. You find the right pages, read them carefully and write down what they actually say.
+
+- Quote headlines, prices and claims exactly, and put the page address after every fact.
+- Read the pages you were asked for before looking further. Stay within the page budget you are given.
+- A gap is a finding. When a page cannot be read or a fact is not published, write that down plainly instead of filling it from memory.
+- You do not judge or recommend. The analyst and the writer do that from your notes.

package/factories/prospect-brief/agents/reviewer/agent.md

@@ -0,0 +1,10 @@
+---
+description: Checks work against stated criteria and sends weak work back.
+agentType: REVIEW
+---
+
+You are the reviewer. You hold one piece of work against the criteria you are given and decide whether it passes.
+
+- You judge only what is on the page and only against the stated criteria.
+- You fail work for a clear, specific breach you can point to. You never fail it for taste, or for something nobody asked for.
+- When you send work back, each reason is one concrete sentence the author can act on.

package/factories/prospect-brief/agents/strategist/agent.md

@@ -0,0 +1,10 @@
+---
+description: Chooses the angle: what to say, to whom, and why it should work.
+agentType: CUSTOM
+---
+
+You are the strategist. From the facts in hand you choose the angle: who this is for, what to promise, and which facts make it believable.
+
+- You offer a clear first choice and real alternatives, and you say which facts you are least sure of.
+- You use only facts from the inputs and earlier steps. A stronger claim that the facts do not support is not an option.
+- The person decides. You make their decision easy to take.

package/factories/prospect-brief/agents/writer/agent.md

@@ -0,0 +1,11 @@
+---
+description: Writes the finished words the person will use or send.
+agentType: CUSTOM
+---
+
+You are the writer. You write the finished thing the person will use: the brief, the message, the page, the report.
+
+- Plain words, short sentences, the reader's own vocabulary. No filler and no hype.
+- You keep to the sections, word limits and order the step asks for.
+- You add no fact that is not in the inputs or earlier results. Where a real asset or decision is missing, you mark the gap clearly instead of inventing it.
+- What you write should be usable as it stands.

package/factories/prospect-brief/factory.yaml

@@ -0,0 +1,11 @@
+schemaVersion: v1alpha1
+name: prospect-brief
+description: |
+  Researches one company you want to sell to and writes a one-page brief plus
+  a first email and follow-up that mention real, checkable facts about them.
+  Use before reaching out to an account that matters.
+repositories: []
+agentDefaults:
+  harness:
+    type: claude
+    model: sonnet

package/factories/prospect-brief/flow.yaml

@@ -0,0 +1,79 @@
+flow: mindburn.flow/v1
+title: Prospect brief and first email
+author: Mindburn Labs
+version: "1.1.0"
+license: MIT
+tags: [sales, research]
+time: about 4 minutes
+inputs:
+  prospect:
+    type: url
+    help: "The website of the company you want to reach."
+  what_you_sell:
+    type: longtext
+    help: "What you offer and who it helps, in a few sentences. Include one real result if you have one."
+  contact_role:
+    type: text
+    optional: true
+    help: "Who you plan to write to, for example \"head of operations\"."
+steps:
+  company_facts:
+    title: Read the company's own site
+    agent: researcher
+    kind: work
+    tools: [web_fetch]
+    task: |
+      Read the prospect's home page and, from its links, the about page and one product or careers page.
+
+      Write: what the company does and for whom, its size signals (team size, locations, customers named), and what it says it cares about now (launches, hiring, expansion, stated priorities). Put the page address after every fact. If you find little, say so; do not pad.
+  recent_news:
+    title: Find recent news
+    agent: researcher
+    kind: work
+    tools: [web_search, web_fetch]
+    needs: []
+    task: |
+      Search for news about the prospect company from the last twelve months and read up to two results. Prefer the company's own announcements and established publications.
+
+      List each item with its date, what happened in one sentence, and the page address. Leave out anything you cannot date or that is about a different company with a similar name. If there is no recent news, say so plainly.
+  angles:
+    title: Find the angle
+    agent: strategist
+    kind: work
+    needs: [company_facts, recent_news]
+    task: |
+      From the company facts, the recent news and what_you_sell, propose three angles for a first message. For each: the trigger (a specific fact about them, with its link), why it plausibly matters to the contact_role, and the one-sentence bridge to what you sell. Rank them, strongest first, and say which facts you are least sure of. If the research supports fewer than three honest angles, give fewer.
+  approve_angles:
+    title: Pick the angle
+    kind: approve
+    needs: [angles]
+    shows: angles
+    task: |
+      Choose the angle to write from. Approve to use the first one, or say which one you want and anything you know about this company that the research missed.
+  email:
+    title: Write the email
+    agent: writer
+    kind: work
+    needs: [approve_angles]
+    task: |
+      Write the first email using the chosen angle. Rules: under 110 words, plain text, no greeting clichés, first sentence is about them and names the trigger fact, one sentence on what you do, one concrete result only if what_you_sell gave one, and one small question as the ask. Then write a follow-up of under 60 words for four days later that adds one new fact instead of repeating. Give two subject lines of four words or fewer.
+  brief:
+    title: Assemble the brief
+    agent: writer
+    kind: deliver
+    needs: [email]
+    task: |
+      Write one page with these sections: **Company in three lines**, **Why now** (the chosen angle and its source link), **Email** (subject lines, first email, follow-up, ready to paste), **If they reply** (three likely questions and a one-line honest answer to each, using only what_you_sell), **Sources** (every page used, as links).
+  check_email:
+    title: Check the brief
+    agent: reviewer
+    kind: check
+    needs: [brief]
+    checks: brief
+    task: |
+      Every fact about the prospect in the entire brief appears in the company facts or recent news and has a source link. Seller claims and answers use only what_you_sell. The chosen angle is preserved. The first email and follow-up meet their word limits, with one ask each and subject lines of four words or fewer. No flattery, greeting cliches or exclamation marks. All requested sections and sources are present.
+
+done:
+  - "Every fact about the prospect has a source link."
+  - "The email could be sent as it stands."
+  - "Nothing claims a result the seller did not state."