Playbook and Reusable Epic Development Plan

1. Context Summary

PR #239 (github.com/brainforge-ai/brainforge-platform/pull/239) introduces:

EP audit SOP v1.7 with client-grouped summaries and per-client risks
Playbook memo examples: Amplitude ramp-up, dbt ramp-up, Omni ramp-up
Vault client memos: LMNT Omni accelerator, Urban Stems forecast and tooling
Consolidation of linear-audit into ep-audit command

Notion references (Data Playbooks, Product Analytics Playbook): This plan assumes those Notion pages define internal data and product analytics procedures that should be codified in the playbook repo.

Existing playbook landscape (from agents.md, README.md, KNOWLEDGE_AND_STANDARDS_GUIDE.md):

Location	Contents
`standards/02-writing/Memos/`	4 templates: Data Findings, Technical Assessment, RCA, Metrics Definition
`standards/02-writing/Memos/examples/`	Hedra ARR, Snowflake Cortex ramp-up; (PR 239) Amplitude, dbt, Omni ramp-ups
`standards/02-writing/SOWs/`, `PRDs/`, `SOPs/`	SOW/PRD templates, SOP template
`standards/03-knowledge/`	sales-playbook, tech-due-diligence-playbook, engineering setup
`standards/04-prompts/`	tickets (linear-board-audit-sop, linear-ticket-agent), meetings, prd, review
`knowledge/sales/agents/playbooks/`	mutual-intro, cold-outbound, event-follow-up, linkedin-connection, metrics-teardown
`knowledge/sales/services/`	Offers, SOPs, Demos per service; service catalog and rate card

2. Proposed Playbook Structure and Categorization

2.1 Taxonomy

flowchart TB
    subgraph domain [Domain]
        Delivery[Delivery]
        GTM[GTM]
        Data[Data]
        Ops[Ops]
    end
    subgraph artifact [Artifact Type]
        Memo[Memo]
        SOP[SOP]
        Template[Template]
        Playbook[Playbook]
    end
    subgraph frequency [Frequency]
        Daily[Daily]
        Weekly[Weekly]
        PerEngagement[Per Engagement]
    end
    domain --> artifact
    artifact --> frequency

Primary categorization dimensions:

Domain
- Delivery — EP audit, meeting prep, ticket creation, client syncs
- GTM — Sales, marketing, outreach (mutual intro, cold outbound, event follow-up)
- Data — Data platform doc, metrics definition, ramp-up memos (Amplitude, dbt, Omni, Snowflake Cortex)
- Ops — SOPs, runbooks, internal processes
Artifact type
- Memo — Findings, assessment, RCA, metrics, ramp-up
- SOP — Linear board audit, ticket creation, review process
- Template — SOW, PRD, discovery wiki, meeting agenda
- Playbook — End-to-end guide (e.g. mutual intro, tech due diligence)
Run frequency
- Daily / Weekly — EP audit, meeting prep
- Per engagement — Ramp-up memos, SOWs, technical assessments
- Per campaign/event — GTM playbooks

2.2 Directory Structure

Extend the current layout with clearer naming and indexes:

standards/
├── 02-writing/
│   ├── Memos/                    # existing
│   │   ├── examples/             # by type: findings, assessment, rca, ramp-up
│   │   ├── MEMO_SELECTION_GUIDE.md  # NEW: decision tree for memo type
│   │   └── [templates]
│   ├── SOWs/                     # existing
│   ├── PRDs/                     # existing
│   ├── SOPs/                     # existing
│   └── PLAYBOOK_INDEX.md         # NEW: index of all playbooks + "when to use"
├── 03-knowledge/
│   ├── delivery/                 # NEW: delivery-specific playbooks
│   │   ├── ep-audit-playbook.md
│   │   └── meeting-prep-playbook.md
│   ├── data/                     # NEW: data playbooks (align with Notion Data Playbooks)
│   │   ├── product-analytics-playbook.md
│   │   ├── ramp-up-memos/
│   │   │   ├── amplitude.md
│   │   │   ├── dbt.md
│   │   │   ├── omni.md
│   │   │   └── snowflake-cortex.md
│   │   └── ...
│   ├── engineering/              # tool setup + delivery workflow playbooks
│   │   ├── setup/                # CLI/API setup (e.g. Omni CLI, Rill, Snowflake)
│   │   └── workflows/            # standard implementation plans (e.g. Omni zero-to-one)
│   ├── gtm/                      # consolidate GTM playbooks from vault
│   │   └── [mutual-intro, cold-outbound, etc.]
│   └── [existing: sales-playbook, tech-due-diligence-playbook]
├── 04-prompts/                   # existing
└── PLAYBOOK_DEVELOPMENT_PLAN.md  # this plan + roadmap

2.3 PLAYBOOK_INDEX Schema

Every playbook added to the repo must have a row in standards/02-writing/PLAYBOOK_INDEX.md. Minimum required fields:

Field	Description
Name	Title of the playbook (title case)
Domain	Delivery / GTM / Data / Ops
Artifact type	Memo / SOP / Template / Playbook
Frequency	Daily-Weekly / Per engagement / Per campaign
Path	Relative path from `standards/`
When to use	1-sentence trigger condition
Owner	DRI who maintains it
Status	Draft / Active / Deprecated

A playbook is considered published when it has an Active row in PLAYBOOK_INDEX and has passed at least one internal review.

2.4 Definition of Done (for a playbook)

A playbook is done when:

Content follows the relevant template (SOP, memo, or playbook scaffold)
Reviewed by at least one person other than the author
Added to PLAYBOOK_INDEX with all required fields (if PLAYBOOK_INDEX exists; otherwise add to this plan’s Tier 1/2 table and register in PLAYBOOK_INDEX when it is created)
agents.md or KNOWLEDGE_AND_STANDARDS_GUIDE.md updated if agents need to reference it
PR merged to standards/

3. Transcript and Client Work Audit (Discovery Phase)

Before or in parallel with writing playbooks, run a systematic audit to surface additional play opportunities.

Owner: Delivery Lead | Time-box: 2 weeks | Output: Play discovery log (table) + backlog additions

3.1 Scope

Past transcripts — knowledge/clients/*/transcripts/, knowledge/clients/unassigned/transcripts/, knowledge/meeting/transcripts/
Past client work — knowledge/clients/*/resources/, knowledge/clients/*/meeting-notes/, knowledge/clients/*/meeting-agendas/
GTM and ops material — knowledge/sales/, knowledge/engineering/, knowledge/ops/

3.2 Audit Process

Keyword and pattern search across transcripts for recurring workflows: “playbook,” “how we do,” “template,” “standard process,” “SOP,” “run through,” “walk me through,” “same as last time,” “follow the same approach,” “repeatable,” “handoff.”
Client folder scan — For each active client, list resources and deliverables; identify patterns (e.g. weekly sync format, discovery wiki structure, ramp-up memo style) that could become playbooks.
Meeting type clustering — Group transcripts by meeting type (standup, discovery, kickoff, retro, renewal prep, etc.); for each type with 5+ instances, capture implied process and outputs.
Gap analysis — Compare discovered plays to the current playbook inventory; flag undocumented or ad-hoc processes that should be formalized.

3.3 Outputs

Play discovery log — Table: play name, source (transcript path / client resource), frequency, domain, suggested artifact type
Backlog additions — New playbook candidates for Tier 2/3, feeding into the reusable epic creation pattern

3.4 Suggested Tooling

Semantic search over knowledge/ for workflow-related phrases
Grep for explicit references to templates, playbooks, and standard processes
Lightweight tagging or spreadsheet to track discoveries across the audit

4. Most Frequently Run Plays (Prioritization)

Based on Cursor rules, commands, vault usage, and findings from the transcript/client work audit (Section 3):

Rank	Play	Frequency	Location / Trigger	Owner	Status
1	Linear board audit	Daily / weekly	`/linear-audit` command, linear-board-audit-sop.md	Delivery	Strong (SOP v1.8)
2	Meeting prep	Per meeting	meeting-prep skill, meeting-prep.md	Delivery	Skill + prompt
3	Ramp-up memos	Per new tool/engagement	Amplitude, dbt, Omni, Snowflake Cortex examples	Data	Examples in PR 239
4	Memo (findings, assessment, RCA)	Per incident / evaluation	Memos	Delivery	Templates exist
5	SOW / PRD	Per deal / project	SOW/PRD templates; services	GTM / CSO	Templates + composable packages (§8)
6	GTM playbooks (mutual intro, event follow-up, etc.)	Per campaign	vault GTM agents	GTM	In vault → moving to playbook (Tier 1)
7	Composable offering package	Per new engagement	services	CSO / Delivery	In progress (§8)
8	Ticket creation	Per action item	linear-ticket-agent, linear-ticket-generation-from-transcript	Delivery	Prompts exist
9	Tech due diligence	Per M&A / partnership	tech-due-diligence-playbook.md	Sales	Exists
10	Product analytics	Per client / project	Notion Product Analytics Playbook	Data	To be codified
11	Data platform documentation	Per engagement	data-platform-documentation-template-guide.md	Data	Exists

5. Immediate Playbooks to Write

Prioritize by frequency, alignment with PR 239, Notion, and the composable service catalog (§8):

Tier 1 — Write first (high frequency, partial coverage)

#	Playbook	Path	Owner	Target
1	Composable offering structure — `implementation-plan.md` and `linear-template.md` templates for `knowledge/sales/services/`; service hierarchy restructure	`knowledge/sales/services/templates/`	CSO / Delivery Lead	Week 1–2
2	GTM playbook consolidation — Move mutual-intro, cold-outbound, event-follow-up from vault into `standards/03-knowledge/sales/` as canonical playbooks	`standards/03-knowledge/sales/`	GTM Lead	Week 1–2
3	Product Analytics Playbook — Codify Notion Product Analytics Playbook. Covers Amplitude/PostHog setup, event taxonomy, dashboards, adoption paths	`standards/03-knowledge/data/product-analytics-playbook.md`	Data Lead	Week 2–3
4	Data Playbooks index — Codify Notion Brainforge Data Playbooks as an index + link to existing memos and templates	`standards/03-knowledge/data/`	Data Lead	Week 3
5	Ramp-up memo playbook — Single playbook referencing Amplitude, dbt, Omni, Snowflake Cortex examples; defines when/how to use each	`standards/03-knowledge/data/ramp-up-memo-playbook.md`	Data Lead	Week 3–4
6	EP audit playbook — Lightweight wrapper pointing to SOP and Cursor command; adds “when to run” and “output destinations”	`standards/03-knowledge/delivery/ep-audit-playbook.md`	Delivery Lead	Week 4

Tier 2 — Write next (medium frequency, good ROI)

#	Playbook	Path	Owner
1	Meeting prep playbook — Extend the skill with explicit steps, context sources, and output format	`standards/03-knowledge/delivery/meeting-prep-playbook.md`	Delivery Lead
2	Memo selection guide — One-page decision tree: Data Findings vs Technical Assessment vs RCA vs Metrics Definition vs Ramp-up	`standards/02-writing/Memos/MEMO_SELECTION_GUIDE.md`	Delivery Lead
3	PLAYBOOK_INDEX — Index of all playbooks with fields defined in §2.3	`standards/02-writing/PLAYBOOK_INDEX.md`	Ops

6. Reusable Epic Creation Plan

Epic structure in Linear:

Epic: “Playbook & Reusable Epic Development”
Child issues: Transcript and client work audit; one per Tier 1 playbook; structural tasks (PLAYBOOK_INDEX, MEMO_SELECTION_GUIDE, knowledge/sales/services/ restructure)
Labels: playbook, documentation, sales (or appropriate team label)
Cycle: Current or next cycle

Reusable pattern for future playbooks:

Discovery — Identify play from usage: audit past transcripts and client work (§3), Cursor usage, Notion. For service-level plays, check knowledge/sales/services/ for an existing offering definition first.
Categorize — Domain, artifact type, frequency; assign DRI
Draft — Use sop-template.md or memo template as scaffold. If the play is a client-facing offering, also create implementation-plan.md and linear-template.md in knowledge/sales/services/{line}/{subservice}/{offering-slug}/. For delivery-heavy offerings, add a standard implementation plan or workflow doc in standards/03-knowledge/engineering/workflows/ (or standards/03-knowledge/data/) and link it from the offering’s sop.md and implementation-plan.md.
Review — Internal review by at least one other person; add to PLAYBOOK_INDEX with required fields (or to this plan’s table until PLAYBOOK_INDEX exists)
Publish — Merge to standards/; update agents.md / KNOWLEDGE_AND_STANDARDS_GUIDE if needed; update Linear canonical project if applicable

7. Execution Steps

7.1 Create Linear ticket (Sales team)

Title: Playbook and Reusable Epic Development Plan

Description:

Summary: Establish playbook structure, categorization, and prioritization; audit past transcripts and client work to discover additional play opportunities; create immediate playbooks (Product Analytics, GTM consolidation, Data Playbooks index, ramp-up memos, EP audit); define reusable epic creation pattern; build composable service catalog (§8).
Changes: Run transcript and client work audit; add standards/03-knowledge/data/ and delivery/ and gtm/ structure; create product-analytics-playbook, ramp-up-memo-playbook, ep-audit-playbook, GTM playbooks; add MEMO_SELECTION_GUIDE and PLAYBOOK_INDEX; restructure knowledge/sales/services/ to three-line hierarchy; add implementation-plan.md and linear-template.md templates.
Impact: Delivery, GTM, and Data teams get a single source of truth for playbooks; CSOs can compose a full offering package (SOW + implementation plan + Linear starter tickets) from one folder; new plays can be added via a repeatable epic pattern.
Related: PR #239 (memo examples, EP audit v1.7); Notion: Brainforge Data Playbooks, Product Analytics Playbook; knowledge/sales/services/ (service catalog)

Team: Sales | Assignee: assignee | Labels: playbook, documentation

7.2 Create branch

Use Linear-suggested branch name once the ticket exists, e.g. uttam/sal-XXX-playbook-development-plan, or manually: uttam/sales-playbook-development-plan.

8. Composable Service Catalog

This is the highest-leverage addition to this plan. When someone on the delivery or GTM team says “a client just asked for X,” they should be able to pull one folder and get everything they need: pitch, delivery plan, Linear starter kit.

8.1 Service Hierarchy

Three service lines → subservices → offerings (projects). This is the permanent backbone — offerings will be added, retired, or renamed, but the three-line structure stays.

Workflow Automation → Insurance Lead Processor, Intake Optimizer, N8N Workflow Builder
Knowledge Engineering → Custom Context Graph, Brainforge OS Setup, MCP Development, Cursor Workshop
Copilots & Agents → AI Copilot Integration Sprint, Embedded Assistant Build, Voice Agent Implementation, Custom Deployment & Hosting

Current proposal status: These AI offers are a Head of Delivery proposal and should transition to Service Lead ownership for validation, packaging, and ongoing maintenance. Copilots & Agents is the preferred display name; Linear subservice label is copilots-agents (vault folder may still be ai-infrastructure/ until renamed).

Data

Data Platform → Full Data Platform, Data Warehouse & dbt, Data Platform Transition & Management, DataOps Program, Source Integration & Ingestion Build
Data Modeling → Product Analytics Platform, Omni Zero-to-One, Business Data Model / Mart Build, Semantic Layer Implementation, Modeling Modernization

Current proposal status: These Data offers are a Head of Delivery proposal and should transition to Service Lead ownership for validation, packaging, and ongoing maintenance. Audits remain cross-cutting offer variants (Data Platform Audit, Data Modeling Audit) rather than a standalone subservice.

When adding a new offering: Create the folder under the right subservice and add one line to this Service Hierarchy so the catalog stays discoverable.

Strategy & Analytics

Data Strategy → Data Strategy Sprint, Data Roadmap, Architecture Advisory, Tool Selection
Measurement & KPIs → Metrics Definition & Dictionary, KPI Framework, Measurement Plan, Attribution Design
Reporting & Insights → Executive Dashboard Design, Recurring Insights Retainer, Business Review Reporting, Decision Support Analysis

Current proposal status: These Strategy & Analytics offers are a Head of Delivery proposal and should transition to Service Lead ownership for validation, packaging, and ongoing maintenance. Technical Due Diligence remains in the catalog as an offering / engagement type rather than a core subservice.

Training & Enablement is a delivery model add-on, not a standalone subservice. Tool-specific training (dbt, Cursor) lives as an add-on within the relevant offering’s sop.md.

Retainers are a delivery model tag (fixed-scope / T&M / retainer / hybrid) on offer.md, not a subservice. “Recurring Insights Retainer” under Reporting & Insights is the exception where the retainer IS the offering.

Verticals (Insurance, Health, E-commerce) are metadata — variants/ subfolder or variants section in offer.md. They do not add a hierarchy level.

8.2 Full Atomic Chain (Service Line → Ticket)

Service Line  →  Subservice  →  Offering  →  Phase  →  Deliverable  →  Ticket
(Initiative)     (grouping)     (Project)    (Milestone) (Epic)         (Issue)

Subservice has no Linear equivalent — navigation/grouping only
Phase = Linear Milestone (e.g. Phase 0 — Audit / Phase 1 — Pilot / Phase 2 — Scale)
Every offering must have at least one Phase; every Phase has Deliverables; every Deliverable breaks into Tickets
implementation-plan.md and linear-template.md templates encode this chain for each offering

8.3 Naming Conventions

Layer	Convention	Example
Service Line	Short, title case	`AI` / `Data` / `Strategy & Analytics`
Subservice	2–3 word descriptor, title case	`Workflow Automation` / `Data Platform`
Offering	Outcome-first noun phrase, title case	`Product Analytics Platform` / `dbt Audit`
Phase	`Phase {N} — {Name}`	`Phase 0 — Audit` / `Phase 1 — Pilot`
Vault folder slug	kebab-case	`product-analytics-platform` / `dbt-audit`
SOW file	`sow-{line-slug}-{offering-slug}-{client}.md`	`sow-data-dbt-audit-cta.md`
Linear canonical project	`{Line} — {Offering} (Canonical)`	`Data — dbt Audit (Canonical)`
Delivery model tag	lowercase	`fixed-scope` / `T&M` / `retainer` / `hybrid`

8.4 Vault Folder Structure

knowledge/sales/services/
├── README.md                              ← updated system overview
├── templates/
│   ├── offer-template.md                  ← existing
│   ├── sop-template.md                    ← existing
│   ├── demo-template.md                   ← existing
│   ├── implementation-plan-template.md    ← NEW
│   └── linear-template.md                 ← NEW
├── ai/
│   ├── workflow-automation/
│   │   └── insurance-lead-processor/
│   ├── knowledge-engineering/
│   │   ├── custom-context-graph/
│   │   └── cursor-workshop/
│   └── ai-infrastructure/
│       └── custom-deployment/
├── data/
│   ├── assessment-audit/
│   │   ├── dbt-audit/
│   │   ├── digital-ads-visibility-audit/
│   │   ├── marketing-data-audit/
│   │   ├── product-analytics-audit/
│   │   └── snowflake-audit/
│   ├── data-infrastructure/
│   │   ├── dataops-program/
│   │   ├── full-data-platform/
│   │   └── data-warehouse-dbt/
│   ├── analytics-bi/
│   │   ├── omni-zero-to-one/
│   │   └── product-analytics-platform/
│   └── activation-attribution/
│       └── edge-to-activation/
└── strategy-analytics/
    ├── data-strategy/
    ├── metrics-kpis/
    ├── reporting-insights/
    └── technical-due-diligence/

Linear labels: Issue subservice tags in Linear use canonical kebab slugs (data-platform, data-modeling, copilots-agents, measurement-kpis, …), not necessarily these vault folder names — see linear-cleanup-taxonomy.md §4.

8.4.1 Adding a new offering

When introducing a new offering (e.g. Omni Zero-to-One, a new audit type):

Place — Choose service line and subservice; create knowledge/sales/services/{line}/{subservice}/{offering-slug}/ (kebab-case).
Four artifacts — Add all four files from templates: offer.md, sop.md, implementation-plan.md, linear-template.md.
Playbook link — If delivery needs a reusable runbook (phases, checklists, tool setup), add a workflow or setup doc in standards/03-knowledge/engineering/workflows/ or standards/03-knowledge/data/ and link it from the offering’s sop.md and implementation-plan.md.
Hierarchy — Add one line to the Service Hierarchy (§8.1) so the offering is discoverable.
PLAYBOOK_INDEX — When PLAYBOOK_INDEX exists, add a row for any new playbook doc created in step 3.

8.5 Per-Offering Package (Four Artifacts)

Each {offering-slug}/ folder must contain all four artifacts to be a complete, composable offering:

Artifact	Purpose	Audience	Status
`offer.md`	Pitch: scope, pricing, proof points	Sales, CSO	Existing template
`sop.md`	How delivery runs it: phases, DRIs, handoffs, risks	Delivery	Existing template
`implementation-plan.md`	Week-by-week phases, milestones, dependencies	CSO + delivery	New template
`linear-template.md`	Starter epics + tickets by phase (“clone this”)	Delivery Lead	New template

When a client asks for X:

CSO opens knowledge/sales/services/{line}/{subservice}/{offering}/
offer.md → scope and pricing for the proposal/SOW
implementation-plan.md → phases and milestones drop into the SOW and kickoff deck
linear-template.md → clone the canonical Linear project into the client’s workspace
Delivery team gets sop.md → knows exactly how to run it

8.6 Linear Canonical Projects

One read-only Project per offering in Linear: Data — dbt Audit (Canonical)
Grouped under an Initiative per service line: Data / AI / Strategy & Analytics
Labeled canonical in Linear; delivery team is DRI for keeping it current
CSOs clone the project when spinning up a new client engagement — tickets become the starting backlog
linear-template.md in vault is the source of truth (so the Linear project can be recreated from scratch if needed)
When to create the canonical project: The offering is complete with just linear-template.md; the canonical Linear project can be created when the first engagement is kicked off (or earlier if the team wants a live template). Until then, delivery uses the template file to create [Client] — [Offering] projects.

8.7 Offering Maintenance Workflow

An offering’s canonical package should be reviewed when:

A real engagement completes (retro learnings → update sop.md and linear-template.md)
Pricing or scope changes (update offer.md)
A new phase or workstream is added (update implementation-plan.md and Linear canonical project)

DRI: Delivery Lead for the relevant service line. Reviews happen at the end of each engagement retro, not on a fixed schedule.

9. Next Steps After Plan Approval

Create the Linear ticket in Sales and assign to owner
Create branch uttam/sal-XXX-playbook-development-plan (or manual name)
Restructure knowledge/sales/services/ to three-line hierarchy; add implementation-plan-template.md and linear-template.md (§8.4)
Run the transcript and client work audit (§3); produce play discovery log and backlog additions
Implement Tier 1 playbooks per §5; incorporate high-value discoveries from the audit
Build out Linear canonical projects per §8.6, starting with the three highest-volume offerings (dbt Audit, Product Analytics Platform, Full Data Platform)
Open PR with description following .cursor/rules/github-pr-description.mdc (four sections); link Linear issue in Related

Brainforge Knowledge

Explorer

PLAYBOOK_DEVELOPMENT_PLAN