Brainstorm Session

Workflow Brainstorm Session

agent starscribe

tags

workflowbrainstorm

context

agents/starscribe/domain.createagents/starscribe/feature.createagents/starscribe/role.create

A brainstorm session captures the why before any what. The output is one or more .manifest.mdoc files plus a list of new domain, new feature, and new role commands that the user can run next. Do not produce feature or domain documents in this session — capture intent only.

Phase 1 — Initiative Scope

Ask:

1. What initiative, product area, or milestone is this brainstorm for?
2. Is this a new product, a new product area, or an extension of something that already exists?
3. How many manifests are needed? (One per initiative is the default — split if concerns are clearly separate.)

Name each manifest now: the file id will be {name}.manifest.mdoc under content/manifests/.

Phase 2 — Problem Space

Open-ended capture — no structure yet, no filtering:

Ask the user to describe:

• What problem are we solving?
• Who is affected and why does it matter to them?
• What is broken, missing, or painful today?
• What does “solved” look like — what changes for the user?

Capture everything as raw notes. Do not compress yet.

Phase 3 — Actor Discovery

From the problem description, identify who is involved:

• Who takes action? (these become roles)
• Who is acted upon or notified?
• Are there system actors (schedulers, external integrations)?

Produce a candidate role list. For each role ask: “Does this role already exist in content/roles/? If not, we will add it to the backlog.”

Phase 4 — Values

What principles or values should guide every decision made during this initiative?

Ask:

• What must never be sacrificed, even under deadline pressure?
• What distinguishes this product from alternatives?
• Are there existing values in content/manifests/ that apply here?

Capture as raw statements. Distill into value entries: short id, descriptive label, one-paragraph body explaining the value and why it matters.

Phase 5 — Principles

Principles are rules of thumb derived from values — they translate “what we believe” into “how we decide”.

Ask:

• What architectural or design constraints follow from the values?
• What have we learned from past mistakes that should become standing rules?

Distill into principle entries.

Phase 6 — Goals

Goals are measurable outcomes that define success for this initiative.

Ask:

• What does success look like at launch?
• What metrics or observable states confirm it?
• Are there phased goals (v1 vs. later)?

Assign a short id (G1, G2, …) and a label to each. Mark initial status="pending".

Phase 7 — Non-Functional Requirements

NFRs are system-wide constraints that cut across all features.

Ask:

• Are there performance, security, accessibility, or reliability constraints?
• Are any of these hard constraints (must) vs. aspirational (should)?

Capture as requirement entries with priority and appropriate tags (performance, security, etc.).

Phase 8 — Implied Backlog

From phases 2–7, identify the domains, features, and roles implied by this initiative.

For each item ask: “Does this already exist in content/? If not, add to the backlog.”

Produce a structured backlog:

Roles to create:
  new role <name>

Domains to create:
  new domain <name>

Features to create:
  new feature <name>

This backlog is NOT written to disk — present it alongside the manifest draft so the user can queue up the next sessions.

Phase 9 — Draft & Confirm

Present each manifest draft for confirmation before writing. Output: content/manifests/{id}.manifest.mdoc

If multiple manifests were scoped in Phase 1, draft and confirm each one separately before writing any.

---

Do’s and Don’ts

Do:

• Capture everything in the problem space without filtering or structure first
• Identify actors from the problem description and check if they already exist as roles
• Distill raw statements into structured entries with short ids and labels
• Produce an implied backlog of domains, features, and roles for the user to queue
• Draft and confirm each manifest separately before writing any

Don’t:

• Don’t produce feature or domain documents in the brainstorm session — capture intent only
• Don’t compress or filter during the problem space capture phase
• Don’t duplicate values or principles already captured in existing manifests
• Don’t skip the actor discovery phase; roles are often missed early
• Don’t write the implied backlog to disk — present it alongside the draft for the user to action

Definition of Done

• Draft presented to user for confirmation (each manifest separately)
• Document(s) written as content/manifests/{id}.manifest.mdoc with correct frontmatter and root tag
• Values, principles, and goals have unique short ids and descriptive labels
• Implied backlog of roles, domains, and features is presented to the user
• No contradictions with existing manifests
• All cross-references resolve to existing documents
• pnpm compile succeeds

linktag > manifest