growth-launch

Files (2)

• LIMITATIONS.md
• SKILL.md

SKILL.md (first lines)

# growth-launch

Orchestrate one growth campaign through the four growth-studio role subagents,
evaluate every draft, and hold the bundle at a founder approval gate.
This skill drafts and reviews; it never publishes.
The mechanical guards that make that true are the subagents' bounded tool lists
(no Bash, no Task, no WebSearch, no WebFetch, no MCP tool) and the unchanged
approval authority; this prose is documentation, not a control.

The flow is fixed-round, never convergent: exactly one draft round and at most
one revision round.
There is no "until green" condition anywhere, so a persistently failing draft
costs a bounded two dispatches and then stops.

## 1. Activation gate

Run `fno config plugins ls`.
If growth-studio is absent or not active, print the activate command for this
pack's `plugin.yaml` and stop with a non-zero exit, creating no campaign
directory and falling back to nothing. The path is the pack's source manifest:
in this (dogfood) checkout that is `plugins/growth-studio/plugin.yaml`; in a consuming project it is wherever that project installed the pack:

    fno config plugins activate plugins/growth-studio/plugin.yaml

A failing or non-zero `fno config plugins ls` is a refusal, never an assume-active.
Print the underlying error and stop.
This gate is the whole reason the faucet is gated: bundling made the skill
present unconditionally at session start, activation is what makes it permitted.

## 2. Objective intake

Take the free-text objective and a campaign slug from the invocation.
Reject the slug if it is empty or contains a path separator, a traversal
component (`..`), or a NUL: it becomes a filesystem path under
`.fno/campaigns/`. Create `.fno/campaigns/<slug>/`.
If that directory already exists, refuse and name it rather than interleaving
into a prior campaign.

Parse the `byline` argument from the invocation: `auto` (the default when absent), `on`, or `off`. It controls whether drafts carry the founder byline, read from the `byline:` form under `## Founder` in brand-identity, so the name is per-project and the skill never free-texts one. The byline belongs to published founder-voice prose and never to internal artifacts: the campaign-plan and the rendered-mock carry none in every mode. Under `auto`, the press-draft and the social LinkedIn post carry the byline (the founder-voice surfaces) and the social X/Threads posts carry none. `on` puts the byline on every published text draft (press-draft and all social posts), and `off` strips it everywhere. Write the resolved byline mode to `.fno/campaigns/<slug>/byline`.

Derive the activated pack's root from its receipt so paths resolve whether the
pack is the in-tree dogfood copy or an installed pack in another project:

```bash
PACK_ROOT="$(dirname "$(fno config plugins inspect growth-studio --json \
  | python3 -c 'import json,sys;print(json.load(sys.stdin)["manifest_path"])')")"
```

The roles read three artifacts, all resolved through the project's context catalog (`[context.artifacts]` in `.fno/config.toml`):

- `product-truth`: project-supplied product facts (sensitivity `public`).
- `brand-voice`: the pack-supplied voice contract. Voice is a property of the
  pack, so the project configures this entry to point at the pack's
  `$PACK_ROOT/assets/brand-voice.md` (sensitivity `internal`).
- `brand-identity`: project-supplied brand identity (the brand name, founder,
  and positioning a draft speaks from). A second consumer points this entry at
  its own identity file; the pack's `$PACK_ROOT/assets/brand-identity.md` is
  the Footnote dogfood default (sensitivity `internal`).

Build the catalog and confirm all three are present and readable:

```bash
fno agents roles context --json > .fno/campaigns/<slug>/catalog.json
```

If any of `product-truth`, `brand-voice`, or `brand-identity` is absent from
the catalog or `readable: false`, stop and name the missing artifact and its
config key (resolution would block with MISSING_CONTEXT or UNREADABLE_CONTEXT).

## 3. Resolution gate

Before dispatching any subagent, resolve each role for this work order so the
capability and context gates are enforced at launch, not bypassed. Stamp one
shared revision - the plugin role layer's snapshot revision - on the catalog,
the facts, and the resolve call so they agree (a mismatch blocks with
MIXED_REVISION):

```bash
REV="$(fno agents roles show marketing --json \
  | python3 -c 'import json,sys;d=json.load(sys.stdin);print(d[-1]["raw_definition"]["snapshot_revision"])')"
fno agents roles context --json --snapshot "$REV" > .fno/campaigns/<slug>/catalog.json
```

For each role, write a capability-facts JSON covering that role's
`required_capabilities` (marketing: `growth.draft`, `growth.research`;
communications: `growth.draft`, `growth.statement`; design: `growth.render`,
`growth.accessibility`; social: `growth.draft`, `growth.schedule`). The grant
is the founder's: running `/fno:growth-launch` authorizes this campaign's work
order, and each fact RECORDS that authorization (`source_id` names the founder's
launch, `available: true`); it does not assert a capability from the manifest.
If the work order is not authorized, refuse before dispatch. Each fact carries
every required field, scoped to this work order:

```json
[{"capability": "growth.draft", "available": true,
  "source_id": "founder-launch/<slug>", "snapshot_revision": "<REV>",
  "work_order_scope": {"node_id": "<slug>", "attempt_id": "<attempt>", "role_id": "<role>"}}]
```

Then resolve, passing the shared revision explicitly:

```bash
fno agents roles resolve <role> --work-order <slug> --attempt <attempt> --snapshot "$REV" \
  --capabilities .fno/campaigns/<slug>/<role>-capabilities.json \
  --context .fno/campaigns/<slug>/catalog.json --json
```

A role that returns `RoleResolutionBlocked` (`MISSING_CAPABILITY`,
`MISSING_CONTEXT`, or `UNREADABLE_CONTEXT`) is recorded as blocked and NOT
dispatched; the campaign continues with the roles that resolved. This is the
only place the gates can be enforced at launch: bundling made the subagents
present, activation permitted the roles, and this step proves the work order is
authorized and the context is configured before any draft is written.

## 4. One draft round

Before dispatching, check the declared width against the route's provider budget (the four role subagents are the fan-out). This is a declaration check, not a cap the Task tool enforces:

```

From bllshttng/fno, Apache-2.0.

More from bllshttng/fno