Plugin Architecture & Your Product Context
Every AI command you run in this chapter is only as good as the context it runs against. A /brief command that does not know your product, your personas, or your current priorities produces a generic PM artifact that you will spend more time correcting than it saved. A /brief command that knows InsightFlow is a B2B SaaS analytics platform at Series B, that your primary persona is Analyst Alex who spends three days waiting for reports, and that your biggest strategic bet is workflow automation — that command produces a brief that sounds like it was written by someone who has been on your team for two years.
The difference between those two outputs is not the command. It is the configuration.
This lesson has two objectives. First: install both plugins that power the chapter. Second: configure product.local.md — the context file that tells every subsequent command what it needs to know about your product. By the end, you will have the foundation that all twelve remaining exercises build on.
The Two-Plugin Architecture
Chapter 36 uses two plugins that together cover the full PM workflow cycle. Understanding which commands come from which plugin helps you understand why the architecture is split the way it is.
Layer 1: Official product-management Plugin
Maintained by: Anthropic
Install: claude plugins add knowledge-work-plugins/product-management
Or in Cowork: Cowork sidebar → Customize → Browse Plugins → "Product Management"
| Command | What it does |
|---|---|
/write-spec | Write a feature specification or PRD from a problem statement |
/roadmap-update | Create, update, or reprioritise your roadmap |
/synthesize-research | Turn interview notes, surveys, and tickets into structured insights |
/stakeholder-update | Draft updates for executives, engineering, or customers |
/competitive-brief | Create a competitive analysis brief |
/metrics-review | Analyse product metrics and surface actionable insights |
/sprint-planning | Plan sprints by scoping work against team capacity |
These are the universal PM commands — every product team writes specs, manages roadmaps, synthesises research, and communicates with stakeholders. The official plugin handles these efficiently and reliably.
Layer 2: Custom product-strategy Plugin
Maintained by: Panaversity (agentfactory-business-plugins)
Install in Cowork: Cowork sidebar → Customize → Browse plugins → Personal → + → "Add marketplace from GitHub" → enter https://github.com/panaversity/agentfactory-business-plugins → find "Product Strategy" → Install
| Command | What it does |
|---|---|
/brief | Create problem briefs, discovery briefs, and initiative briefs |
/interview | Generate user interview guides with JTBD-aligned question structure |
/prd | Produce multi-team Product Requirements Documents |
/stories | Decompose PRDs into user stories with acceptance criteria |
/prioritise | Apply RICE, MoSCoW, or weighted scoring to a backlog |
/retro | Structure product retrospectives and post-mortems |
This plugin fills the workflow gaps the official plugin does not cover. It also encodes specific craft principles — like "never propose a solution in a problem brief" — as enforced structural rules, not just suggestions.
How They Complement Each Other
Custom /brief → Frame the problem
Custom /interview → Design the research
Official /synthesize-research → Turn research into insights
Official /write-spec → Write the feature spec
Custom /prd → Wrap it in a multi-team PRD
Custom /stories → Decompose into user stories
Custom /prioritise → Score and rank the backlog
Official /roadmap-update → Update the roadmap
Official /sprint-planning → Scope the sprint
Official /stakeholder-update → Communicate progress
Official /metrics-review → Review the outcomes
Custom /retro → Evaluate the full cycle
When you install a plugin in Cowork, you install its commands and skills. For the product-strategy plugin, the installable structure looks like this:
product-strategy/
├── .claude-plugin/
│ └── plugin.json
├── skills/
│ ├── brief/
│ ├── interview/
│ ├── prd/
│ ├── stories/
│ ├── prioritise/
│ └── retro/
└── README.md
The product.local.md Configuration File
product.local.md is the context file that calibrates every plugin command to your specific product. Without it, commands produce generic PM artifacts. With it, outputs reflect the specific personas, constraints, stakeholder dynamics, and quality standards of your product.
The file lives in your Cowork skills root directory. Every command that runs in that Cowork session automatically has access to it.
Here is what each section does and why it matters:
Product Identity
Product name, description, stage, business model, pricing tiers, core value prop
Why it matters: Commands like /write-spec and /competitive-brief need to understand what kind of product they are writing for. A B2B SaaS spec has different structural requirements than a consumer app spec. The business model changes what "success" looks like for every feature.
Product Vision and Strategy
Vision (3-5 year direction), current strategy (1-2 year focus), current themes
Why it matters: Acceptance criteria, prioritisation decisions, and roadmap updates all require understanding what the product is optimising for right now. A spec for a feature that serves the wrong strategic theme is a well-written document for the wrong problem.
Personas
Primary persona: name, role, company size, primary goal, biggest frustration, "10/10 week"
Secondary and tertiary personas: same structure, abbreviated
Why it matters: This is the highest-leverage section. The primary persona description changes the tone, specificity, and focus of nearly every command output. A persona described as "data analysts at 100-500 person companies who build dashboards without SQL, whose biggest frustration is that report requests take 3+ days" produces fundamentally different output than "users who need analytics."
Engineering Team
Team size, sprint length, cadence, velocity, backlog tool, spec location, working agreements
Why it matters: Sprint planning commands, story decomposition, and acceptance criteria quality all depend on understanding how your engineering team works. A 2-week sprint team needs different story granularity than a 1-week sprint team.
Stakeholder Map
Name, role, what they care about, communication style, alert threshold
Why it matters: Stakeholder updates are the only PM artifact that must be written differently for every audience. Without the stakeholder map, the update command produces a single generic version. With it, you can run the command three times and get three audience-calibrated updates from the same source.
Exercise: Configure product.local.md for InsightFlow
Plugin: Both (this exercise installs and verifies both)
Command: /brief (verification test)
Time: 20 minutes
Step 1 — Install both plugins
Open Cowork. Install the official product-management plugin:
Cowork sidebar → Customize → Browse Plugins → "Product Management" → Install
Install the custom product-strategy plugin:
Cowork sidebar → Customize → Browse plugins → Personal → + →
"Add marketplace from GitHub" → https://github.com/panaversity/agentfactory-business-plugins →
"Product Strategy" → Install
Verify both are active by typing / in the Cowork chat — you should see both plugin command sets in the autocomplete list.
Step 2 — Copy the template and fill Product Identity
Create a new file called product.local.md in your Cowork skills root directory. Fill in the Product Identity section for InsightFlow:
# InsightFlow — Product Management Configuration
# Version: 1.0 | Last Updated: 2026-03-18 | Owner: [Your Name]
---
## Product Identity
Product name: InsightFlow
Product description: B2B SaaS analytics platform that helps data analysts at
100-500 person companies build dashboards and reports
without writing SQL.
Stage: Series B SaaS — 50 employees, 200 customers
Business model: B2B SaaS
Pricing tiers: Free / Pro ($49/user/mo) / Business ($99/user/mo) /
Enterprise (custom)
Core value prop: "InsightFlow turns raw data into decisions without
requiring a data team"
Step 3 — Add Vision and Personas
Add the Vision and Personas sections:
## Product Vision and Strategy
Vision: "Every business decision backed by real-time data intelligence"
Current strategy: Expand from analytics into workflow automation while
maintaining the simplicity that makes InsightFlow accessible
to analysts without SQL skills
Current themes: 1. Workflow automation MVP 2. Enterprise security (SOC 2 compliance) 3. Self-serve onboarding improvement
---
## Personas
### Primary Persona
Name: Analyst Alex
Role: Data analyst
Company size: 100-500 person company
Primary goal: Build dashboards and reports without writing SQL
Biggest frustration: Report requests take 3+ days; Alex is constantly
blocked waiting for data team availability
"10/10 week": Alex builds three new dashboards for different teams,
receives no "when will this be ready?" Slack messages,
and sees two of the dashboards get referenced in a
team meeting without anyone asking who built them
Behavioral signals: Daily logins; heavy use of drag-and-drop builder;
low use of SQL editor; shares dashboards with 3+ colleagues
### Secondary Persona
Name: VP Priya
Role: VP Engineering
Primary goal: Access team performance metrics without asking the data team
Key difference: Needs automated reports and cross-team visibility,
not dashboard authoring capability
### Tertiary Persona
Name: CFO Marcus
Role: CFO
Primary goal: Revenue dashboards for board meetings
Key difference: Cares about accuracy, audit trail, and exporting to
board-ready formats — not daily usage
Step 4 — Add Engineering Team and Stakeholder Map
## Engineering Team
Team size: 12 engineers + 3 designers
Sprint length: 2 weeks (Monday start, Friday end)
Sprint cadence: Planning on Mondays, retro every other Friday
Velocity: ~40 story points per sprint
Backlog tool: Linear
Spec location: Notion (link: [team Notion workspace])
Engineering working agreements:
- Specs must be REVIEW status before sprint planning
- Engineering estimates happen in sprint planning, not before
- No spec may enter a sprint in DRAFT status
---
## Stakeholder Map
| Name | Role | Cares Most About | Communication Style | Alert Threshold |
| ------------ | ------------- | -------------------------- | -------------------------- | ----------------------------- |
| Sarah Chen | CEO | Revenue + market position | Executive summary, 1 page | Any AT RISK status |
| David Park | CPO | Product strategy + quality | Detailed; technical OK | Watch item or above |
| Maria Santos | CTO | Technical architecture | Technical precision | Platform dependencies |
| James Wilson | Head of CS | Customer commitments | Practical; customer impact | Any customer-committed change |
| Aisha Patel | Head of Sales | Deal-blocking features | Short; commercial framing | Any enterprise deal blocker |
Step 5 — Test by running /brief
Save product.local.md and run this prompt in Cowork:
/brief
type: "problem"
context: "Our analysts keep abandoning the report builder before
completing their first dashboard. We think onboarding might be
the problem."
Reframe this as a problem brief. Do not propose solutions.
Evaluate the output against these criteria:
- Does it name InsightFlow by name?
- Does it reference Analyst Alex (or "data analysts") as the affected persona?
- Does it connect to the onboarding or self-serve theme from current priorities?
- Does the problem statement avoid solution proposals?
If the output does not reflect InsightFlow context, review your product.local.md for missing or inaccurate sections — likely the Personas section is the culprit.
Lessons 3-14 build one continuous product management cycle for InsightFlow. Keep your Cowork session and your product.local.md file throughout the chapter. Every command you run from Lesson 3 onward uses this context.
What You Built
You have configured the foundation artifact for the entire chapter: a product.local.md that encodes InsightFlow's identity, personas, engineering context, and stakeholder map. Every plugin command you run from here through Lesson 14 will use this context to calibrate its output to InsightFlow — producing documents that sound specific, not generic.
You also verified that both plugins are installed and active. The command map is now clear: official plugin for foundational PM workflows, custom plugin for workflow gaps and craft enforcement.
Try With AI
Use these prompts in Cowork or your preferred AI assistant.
Prompt 1 — Reproduce (apply what you just learned):
I am setting up product.local.md for a B2B project management tool.
The product is called TaskFlow. It helps remote engineering teams
track sprint progress without switching between Jira and Slack.
The team is 8 engineers, 1-week sprints, and the primary persona
is an engineering manager who currently spends 2 hours every Monday
manually building sprint reports.
Draft the Product Identity and Personas sections of product.local.md
for TaskFlow.
What you're learning: Practising the product.local.md format with a different product solidifies what each section requires — and reveals which sections are hardest to fill for a product you do not yet know deeply.
Prompt 2 — Adapt (change the context):
A PM has filled in product.local.md but the Personas section
only says:
"Primary persona: software developers who want to ship faster"
Run /brief with this context on the following request:
"We want to add a dark mode."
What quality of output do you expect? What is missing from the
persona description that would change the brief significantly?
Now rewrite the persona description to be more specific and show
how the brief output would differ.
What you're learning: The contrast between a vague and a precise persona description makes the leverage of the Personas section concrete. A persona that describes behavior, not just role, changes the output qualitatively.
Prompt 3 — Apply (connect to your domain):
Draft the Personas section of product.local.md for a product you
work on or have worked on recently.
For each persona, fill in all five fields:
- Name (give them a real-sounding name)
- Role (job title and context)
- Primary goal (the job they are trying to do with your product)
- Biggest frustration (their top current pain)
- "10/10 week" (what a perfect week looks like for them)
After drafting, run /brief with a recent feature request from your
backlog. Does the output sound like it was written for your actual
users? What is still missing?
What you're learning: Building a product.local.md persona for a product you know deeply reveals whether your team's shared understanding of your users is precise enough to generate useful AI output — or whether the personas are vaguer than you thought.
Flashcards Study Aid
Continue to Lesson 3: Discovery Briefs — Framing the Right Problem →