Write an idea issue

For: Balsam CoE members

What this playbook does

Turn a loose idea — in whatever shape it arrived — into a well-formed GitHub issue in the CoE repo (goosegroup/balsam-coe) that a cohort member or operator can pick up and start working. The playbook does this in four stages that blur into each other, not a strict sequence:

1. Understand the idea. Interview like a product manager paired with a domain expert. Pull the problem, not just the solution.
2. Ground in Balsam context. Pull related existing material — cohorts, intakes, resources, prior ideas, Jira/Confluence — via MCP. Anchor the idea in what already exists.
3. Iterate with the user. Surface tensions, adjust, confirm. Don’t rush to the issue.
4. Draft and file. Produce the issue. Apply the strict label scheme. Share the URL.

This pipeline is iterative, not linear. Context discovered in Stage 2 reframes Stage 1’s questions. Tensions in Stage 3 may send us back to Stage 2. Don’t force the order.

Pre-flight — check the user’s MCP connectivity

Before you start, ask the user which MCP servers they have connected to this Claude. You will gracefully degrade without any of them, but what you can fetch changes depending on what’s there.

Ask briefly, something like:

Before I dig in, quick check — which MCPs do you have connected? I can ground this idea more thoroughly the more of these you have:

• CoE repo MCP (mcp.coe.goosegroup.co) — lets me read the CoE’s cohorts, intakes, resources, workflows, existing ideas.
• Atlassian MCP (your Jira + Confluence) — lets me check if anyone at Balsam has already worked on this.
• Granola MCP — lets me find past call transcripts on the same topic.

If you don’t have any of these, that’s fine — just tell me what you know and we can paste things as we go.

If the user doesn’t have a given MCP, don’t stop. Ask them to paste links, IDs, or summaries instead. Flag the gap in the final issue under “Open questions” so someone can follow up.

Stage 1 — Understand the idea

Wear two hats at once:

• Product manager. What problem does this actually solve? Whose? Why now? What’s the smallest useful version? What would you measure to know it worked?
• Domain expert. Match the hat to the idea’s territory — SEO, content marketing, physical product design, merchandising, inventory planning, customer service, order-to-delivery, creative ops, whatever. Ask the questions someone who actually does that work would ask. If the idea is about SEO, ask about canonical strategy, agent-era search, channel-specific descriptions. If it’s about product design, ask about vendor workflows, sampling cycles, trade-show capture. If it’s about marketing, ask about attribution, reallocation cycles, channel-specific creative.

How to interview:

• Start with what the user brought. If it’s a transcript, read it first. Don’t front-load your questions.
• Be conversational, not a survey. One good follow-up beats ten prepared questions.
• When the user says something concrete, quote it back and ask them to expand. Direct language matters; turning it into consultant-speak loses the signal.
• Identify the theme(s) this touches: product-data, content, marketing, order-to-delivery. Multi-label if it spans. (These are the four core Balsam workflows — see src/content/workflows/.)
• Identify the size: a 1-hour experiment? a week-long prototype? a multi-week “real product” other people could use? Issues should be scoped to their actual size; don’t force every idea into the same template. A small experiment gets a short issue.
• Identify the contributor: whose idea is this? Does this person have an intake file at src/content/operators/intakes/<slug>.md? If not, flag — they may need one; that’s a follow-up, don’t block.

You’re done with Stage 1 when you can say in one or two sentences: “This idea solves [problem] for [audience] by [approach]. It touches [theme(s)]. The contributor is [name].”

Stage 2 — Ground in Balsam context

The idea doesn’t exist in isolation. Before drafting the issue, check what it relates to.

Via the CoE repo MCP (list, get, search on this repo’s content):

• Cohorts (list("cohorts")) — is this already someone’s cohort scope? Is the contributor already in a cohort?
• Intakes (get("operators", "intakes/<slug>")) — has this person already raised related ideas in their intake? Have colleagues?
• Resources (list("resources"), search) — does a tool already exist for this job, even a partial one? Don’t file an idea that duplicates an existing resource — link to the resource and flag the gap instead.
• Workflows (get("workflows", "<theme>")) — where in the workflow map does this idea land? “Where it gets stuck” rows on the workflow page may already name this friction.
• Research (list("research")) — has a prior discovery scan covered this ground?
• Existing idea issues — gh issue list --label idea --state open on goosegroup/balsam-coe. Scan titles and Problem statements for near-duplicates. If one exists, the right move is probably a comment on the existing issue, not a new one.

Via the Atlassian MCP (Jira + Confluence), if connected:

• Jira — search for tickets in the user’s domain. Has dev already scoped this? Is there a ticket in “backlog” or “done”? The CoE’s job is not to refile engineering work; if it belongs on a Balsam backlog, route it there (see issue #27).
• Confluence — search for docs on the topic. If there’s prior documentation, reference it in the issue’s “Related” section.

Via Granola, if connected:

• Search for past calls on the workflow or with the same people. If this idea surfaced before, the prior call may have context worth preserving.

If an MCP isn’t connected, ask the user to paste links/IDs. If they can’t, note the gap under “Open questions” in the final issue so a follow-up can fill it.

Stage 3 — Iterate

Now show the user what you’ve found and what you’re thinking:

• “This looks related to issue #X by Y — is this the same idea refined, a distinct next step, or something else?”
• “Z in Jira looks adjacent — is this upstream, downstream, or orthogonal?”
• “The [workflow] page already notes [friction Y] — is your idea about fixing that specific friction, or something different?”
• “Should [colleague] be tagged as a co-contributor, or is this squarely your idea?”

Push back if the problem statement is still fuzzy. Push back if the proposal is too ambitious for a first issue — ask what the smallest useful version is. Push back if the user is proposing a solution when the problem isn’t clear yet.

Refine the four core elements:

• Problem statement — in the user’s words, 1–2 sentences.
• Contributor(s) — name + intake link.
• Proposal — what to actually do; the smallest useful version first.
• Open questions — what you don’t know yet; what needs to be decided before starting.

Stage 4 — Draft and file

Issue body shape (per CLAUDE.md → “GitHub issue labels (strict)”)

The body MUST open with:

**Problem it solves:** [1–2 sentences in their words]
**Contributor:** [Name] — [/operators/intakes/<slug>]

Then, in whatever order makes sense for this specific idea:

• Proposal — what to build / try. Lead with the smallest useful version. If there’s a natural v2/v3, mention them but don’t commit.
• Why now — what’s true today that makes this worth picking up.
• Open questions — unknowns; decisions that need to happen before starting.
• Related — links to similar ideas, PRs, resource entries, Jira tickets, Confluence pages. Anchor in the context you found in Stage 2.

Scale the body to the idea’s size. A 1-hour experiment gets a 150-word issue. A multi-week product may warrant 500+ words. Don’t pad.

Labels (strict — per CLAUDE.md)

• Primary (required): idea.
• Cohort (required if cohort-scoped): cohort-<n> — only if the cohort exists. Don’t create future-cohort labels.
• Contributor (required): person:<slug> — slug matches src/content/operators/intakes/<slug>.md. If the label doesn’t exist, create it: gh label create "person:<slug>" --color "F9D0C4" --description "Idea surfaced by <Name> (<Department>)."
• Theme (required if it touches a workflow): theme:<workflow> — theme:product-data, theme:content, theme:marketing, theme:order-to-delivery. Multi-label when it spans.

Do not apply idea to site-build or infra work. If the user’s “idea” is really “the CoE site should have feature X,” that’s a site issue, not an idea. If it’s a Jira ticket disguised, route it per issue #27, don’t file it here.

Verification before filing

Run through this mental checklist (from balsam-coe/CLAUDE.md):

• Name-check — the contributor’s full name is in the Balsam org chart (GG Swerk → Balsam Internal → Full Directory). Any other named colleagues in the issue body also verified.
• Invitational framing — no adversarial language, no “you should,” no pattern that implies a gatekeeper. Ideas are invitations to explore, not mandates.
• No named individuals in hero copy — intake-file bodies and issue bodies are fine, but nothing that would leak a person’s name into site-wide headings.
• Scope check — this is cohort work product (an experiment, a prototype, a piece of craft), not site-build work and not ambient engineering backlog.

File it

gh issue create --repo goosegroup/balsam-coe --title "<concise title>" --label "<labels>" --body-file /tmp/idea-issue.md

Share the URL with the user. Offer to post a comment on a related existing issue if one was found.

When to stop and ask the user

• When you can’t verify a name — ask before writing it into the issue.
• When the idea duplicates an existing issue — ask whether to comment on the existing one instead.
• When the idea feels like site-build work or dev-team work — ask before applying idea. The right home may be site or (per issue #27) a Balsam Jira project.
• When an MCP you need isn’t connected — ask the user to paste the equivalent info or decide to ship without that context.

Good examples (real filed issues)

Each of these was produced from a similar starting point (intake call transcript) and follows the Problem/Contributor opening block + scaled-to-size body:

• #34 Brand-grounded product image generator — Priscilla Spicer.
• #38 Amazon product-description auto-drafter — Clint Borrill. Note the scope: he has a growth-team meeting booked to scope this next week.
• #41 Child-level SKU data enrichment for agent-era search — Clint Borrill. Larger scope; more “Related” links; explicit connection to other ideas.
• #9 Cohort 1 project: Training Material Generator — Kate Hollywood. Bigger ideas get proportionally bigger bodies.

Anti-patterns to avoid

• Idea + site design in one issue. #9 originally contained a “projects within a cohort UX” site-design question on top of Kate’s training-material generator. We had to split it after the fact. Don’t combine.
• Filing an idea that’s actually site-build work. “The ideas page should let me filter by theme” — that’s a site issue (see #33), not idea.
• Filing an idea that’s actually engineering backlog. “Balsam should upgrade its PIM” — that’s a Jira backlog ticket, not a CoE idea. Route per issue #27.
• Skipping the contributor attribution. person:<slug> is required. If you can’t attribute, stop and ask.
• Creating cohort-N labels for cohorts that don’t exist yet. Only file against an active cohort.
• Letting the issue be a solution in search of a problem. If you can’t state the problem in one sentence in the user’s own words, go back to Stage 1.

Done

You’re done when:

• An issue is filed on goosegroup/balsam-coe with correct labels and the Problem/Contributor opening block.
• The user has seen the final draft and given a thumbs-up.
• Any gap the conversation surfaced — missing intake file, missing MCP connection, ambiguous cohort scope — is captured either in the issue’s “Open questions” or as its own follow-up issue.
• You shared the URL with the user.