TSH Product Management

tsh-product-management carries TSH's business-analysis workflow: discovery material goes in, and a reviewed backlog and a client-facing roadmap come out, with every irreversible step behind an approval the workflow records in a file. Materials can be transcripts, Figma, PDFs and codebase context. The output is Jira-ready epics and user stories, a per-product domain dictionary and an outcome-based delivery roadmap. It can also import an existing Jira backlog for local iteration and controlled push-back.

Read-only worker subagents keep the heavy reading out of the main conversation: transcript cleaning, discovery analysis, epic extraction, quality review, roadmap planning, Jira formatting and terminology extraction each have one.

The plugin has a second job. It sets up and reads a project's knowledge base: a <project>-context repository that every code repository and every role reads with cited sources, and that changes only through a branch and a pull request (a knowledge base with no remote yet is the one exception). That part is the project-context skills: initializing-project-context, navigating-project-context, writing-project-knowledge, adding-project-context-workspace and repairing-project-context-links. They are the one part of this plugin that people outside product management use, so initializing-project-context enables the plugin in every repository it connects, and an engineer or tester gets them without installing anything, together with the rest of this plugin, including both hooks.

Install and scope

Install at user scope: this plugin travels with you, not with a repository. The commands are in Installation.

Start here

Both entry points take a transcript path, a Figma or FigJam link, a PDF, or a folder of documents. analyze-materials also takes Jira issue keys or a project key, to import an existing backlog instead.

• /tsh-product-management:analyze-materials runs the full workflow: materials or an existing Jira backlog in, reviewed epics and stories out.
• /tsh-product-management:explore-materials runs Explore Mode: a business-context summary that deliberately stops short of any backlog item.

/tsh-product-management:domain-dictionary starts the per-product domain dictionary workflow, and initializing-project-context starts the knowledge base. These commands, like the two above, are disable-model-invocation: true: commands, not routing surfaces, so they cost nothing until you type them. Every other skill is model-invocable and routes on how people describe the work.

What it ships

Skill	Invoke	What it does
adding-project-context-workspace	/tsh-product-management:adding-project-context-workspace	Creates a new workspace in a project's `<project>-context` knowledge base — the folder, its README index, its CLAUDE.md with exactly one named owner, and its row in the area map, all in one change. Use when a new layer or area of such a project needs its own place: a new delivery layer, a workstream, an integration package.
analyze-materials	/tsh-product-management:analyze-materials (on request only)	Entry point for the full business-analysis workflow: processes discovery workshop materials into Jira-ready epics and user stories, or imports an existing Jira backlog to iterate on. Run /tsh-product-management:analyze-materials with a transcript path, Figma link, PDF path, folder, Jira issue keys, or a project key.
analyzing-discovery-context	/tsh-product-management:analyzing-discovery-context	Gathers and expands the business context around a task or workshop topic: pulls what is known from task trackers, knowledge bases, documents and designs, finds the gaps, resolves them with the user, and writes a research report. Use before committing to a backlog, when a request is ambiguous, or when comparing new material against an existing baseline.
domain-dictionary	/tsh-product-management:domain-dictionary (on request only)	Entry point for producing, reviewing and maintaining a per-product domain dictionary — the canonical business-term glossary, not domain-driven design. Run /tsh-product-management:domain-dictionary with a project name, a workshop directory of transcripts, PDFs or designs, a repository path to reconcile against, or nothing.
explore-materials	/tsh-product-management:explore-materials (on request only)	Entry point for Explore Mode: reads discovery workshop materials and produces a business-context summary with likely epic candidates and open questions, without creating any backlog items. Run /tsh-product-management:explore-materials with a transcript path, Figma link, PDF path, or folder of workshop assets.
extracting-epics-and-stories	/tsh-product-management:extracting-epics-and-stories	Turns processed workshop materials into a business-oriented backlog: an approved intent brief first, then epics as independently demonstrable vertical slices with a delivery contract, and user stories with source traceability and GIVEN/WHEN/THEN acceptance criteria. Use after transcripts and materials are processed, before any Jira formatting.
formatting-jira-issues	/tsh-product-management:formatting-jira-issues	Transforms an approved epic and story list into Jira-ready issues against a benchmark template — field mapping, Jira markdown, completeness validation, the formatting review and the Gate 2 push approval — and imports an existing Jira backlog into the same local format for iteration. Use before creating or updating any Jira issue from a workshop backlog.
initializing-project-context	/tsh-product-management:initializing-project-context (on request only)	Sets up a project's context repository — a knowledge base with named owners per project and delivery layer, one folder for all decision records, a quality gate, and a Claude Code marketplace for the project's own Markdown skills — as a local git repository it can publish to Bitbucket, GitHub or any git host after asking; connects code repositories to it, committed for the team's own repositories and local-only for a client's; and publishes a knowledge base started without a remote. Run /tsh-product-management:initializing-project-context in the folder where the project should live, or in a code repository to connect.
managing-domain-dictionaries	/tsh-product-management:managing-domain-dictionaries	Produces, reviews and maintains a per-product domain dictionary — canonical business terms, their source-language surface forms, and where a UI label differs from the identifier — through Harvest, Reconcile and Interview modes, checked by eleven review passes and reconciled against a live codebase without ever editing it.
navigating-project-context	/tsh-product-management:navigating-project-context	Reads a project's knowledge base — the `<project>-context` repository: scope, accepted decisions, vocabulary, who owns what — before work that depends on it, wherever the clone sits, and cites the file, its last change and its owner behind every project fact. Use when a task in a repository of such a project needs project facts: what was decided, what a term means, who owns an area, where a document lives.
orchestrating-business-analysis	/tsh-product-management:orchestrating-business-analysis	Runs the business-analysis workflow end to end from the main conversation: turns discovery workshop material — transcripts, Figma, PDFs, codebase context — into Jira-ready epics and user stories and a delivery roadmap, behind five human review gates, delegating the heavy reading to read-only worker subagents. Also imports an existing Jira backlog for local iteration and controlled push-back.
planning-delivery-roadmaps	/tsh-product-management:planning-delivery-roadmaps	Reconciles approved epics, accepted quality findings, a project baseline and any existing roadmap into one Markdown-only, per-project roadmap: client-facing outcome waves and an internal coordination view, linked by project-scoped stable epic IDs. Use after the task list is confirmed and before Jira formatting; it creates no Jira data and changes no statuses.
processing-workshop-transcripts	/tsh-product-management:processing-workshop-transcripts	Cleans a raw workshop or meeting transcript into a structured, business-relevant document — small talk and filler removed, content grouped by discussion topic, with decisions, action items and open questions extracted. Use before any backlog extraction when the input is a raw transcript, meeting notes, or a recording export.
repairing-project-context-links	/tsh-product-management:repairing-project-context-links	Finds and repairs broken references in a project's `<project>-context` knowledge base — relative links that no longer resolve, filenames that are not kebab-case, and markdown tables that render wrongly — using the repository's own checker scripts. Use when those scripts report violations, before opening a pull request there, or after moving or deleting documents.
reviewing-backlog-quality	/tsh-product-management:reviewing-backlog-quality	Systematically reviews an approved epic and story list for gaps, missing edge cases and delivery-readiness problems, then produces individually accept-or-reject suggestions that refine the backlog before Jira formatting. Runs Lite or Full analysis passes over a domain model built from the tasks themselves, optionally enriched with Jira board context.
writing-project-knowledge	/tsh-product-management:writing-project-knowledge	Adds or updates a document in a project's knowledge base — the `<project>-context` repository — picking the owning workspace, applying the state-of-today rule, updating the workspace index, and naming the owner who reviews it. Use when something learned or changed on such a project should be written down.

Agent	Mention	Model	What it does
backlog-extractor	@tsh-product-management:backlog-extractor	sonnet	Drafts intent briefs and extracts epics and user stories from approved workshop context — with delivery contracts, source traceability and GIVEN/WHEN/THEN acceptance criteria — and returns them as a report. Use one agent per epic to extract a large backlog in parallel.
backlog-quality-reviewer	@tsh-product-management:backlog-quality-reviewer	opus	Runs assigned Lite or Full quality-review passes over an approved epic and story list and returns structured, confidence-scored suggestions — lifecycle gaps, missing edge cases, delivery-readiness problems. Use to split a review across several agents, one batch of passes each, before the Gate 1.5 disposition.
discovery-analyst	@tsh-product-management:discovery-analyst	sonnet	Synthesizes workshop materials — transcripts, PDFs, supplied design and backlog context — into a structured business summary with likely epic candidates, baseline overlap, contradictions and open questions. Use for Explore Mode and for the material-analysis phase before extraction, including one agent per document across a large bundle.
jira-formatter	@tsh-product-management:jira-formatter	haiku	Applies the Jira benchmark template to extracted epics and stories, produces the completeness table, and prepares post-push verification diffs and baseline-refresh content. Use to keep bulk formatting work out of the main conversation; it performs no Jira calls and writes no files.
roadmap-planner	@tsh-product-management:roadmap-planner	opus	Reconciles approved epics, accepted quality findings, a project baseline and any existing roadmap into one validated, in-memory roadmap proposal — stable epic IDs, client-facing outcome waves and an internal coordination view. Use as a single agent before the Roadmap Review gate; never split the work across several.
terminology-extractor	@tsh-product-management:terminology-extractor	sonnet	Extracts domain-term candidates and source-language surface forms from supplied material, and sweeps a codebase's identifiers for Reconcile mode. Use for the harvest reading pass of managing-domain-dictionaries and for the identifier sweep that reconciling-with-code diffs against the term table.
transcript-cleaner	@tsh-product-management:transcript-cleaner	haiku	Cleans and structures a raw workshop or meeting transcript — removing small talk and filler, grouping by discussion topic, extracting decisions, action items and open questions — and returns it as a report. Use to process transcript material without spending the main conversation's context on the raw text.

The five gates

Human review gates stand between raw material and a Jira backlog. Approvals are written to specifications/<workshop-name>/.gates.md before the action they unlock, because a long session gets summarized and a remembered approval does not survive that.

Gate	After	You decide
0	The intent brief	Is this the right scope?
1	Extraction	Is this the right breakdown?
1.5	Quality review	Which suggestions land?
1.75	The roadmap proposal	Are these the right waves?
2	Jira formatting	Push, to this project, now?

The procedure behind them is orchestrating-business-analysis. The end-to-end flow is described in Business analysis, and the knowledge base in Project context.

The Jira-write gate hook

Gate 2 is enforced, not merely stated. The plugin registers a PreToolUse hook in hooks/hooks.json. Its matcher is mcp__.*([Aa]tlassian|[Jj]ira|[Rr]ovo|[Cc]onfluence).*, and it runs hooks/guard-jira-write.mjs with Node. It is active for anyone who installs the plugin, whichever way the workflow is entered, including a direct /tsh-product-management:formatting-jira-issues that never touches the orchestrator. Confirm it is live with /hooks.

The hook reads the tool call and the files on disk and returns one of three outcomes: stay silent so normal permission rules apply, deny the call, or ask the user.

What it checks, in order:

1. Not a Jira write. A tool that is not an Atlassian, Jira, Rovo or Confluence tool is ignored. A Confluence tool whose name does not also carry jira is left to the normal permission prompt, because both policies are about Jira issues. Publishing a domain dictionary or a page is therefore not gated.
2. Reads are never gated. The bare tool name (the part after the last __) is classified by its leading verb. Names starting with get, search, list, read, fetch, lookup, view, find, query, describe, count, export or download are reads, as are a few exact names such as atlassianUserInfo. This is why the status check the workflow requires before an update is never blocked.
3. Stands down outside BA sessions. It scans the working directory (depth 6, skipping node_modules, .git, dist, build and dot-directories other than .claude) for live BA artifacts: .gates.md, jira-tasks.md or extracted-tasks.md. If none exists, it allows the call, so ordinary Jira work in other repositories is unaffected. Anything under a sessions directory is archived history and is invisible to the guard.
4. Protected Status Policy. A task in a live jira-tasks.md is protected when its task heading (## to ####, ### in the template) carries 🔒 or the word PROTECTED, or its Status line names Done, Cancelled or PO APPROVE. A line that carries both the issue key and 🔒 also protects that key. A write that targets the issue key of a protected task is denied whether or not the gate is approved.
5. Gate 2 approval. There must be a live .gates.md with a row numbered 2 that says approved. The row must name the target project key, such as project ACME, and every project the write targets must be named by an approved row. Approval for one project does not unlock another. The hook reads the target project from the call's issue-key fields (issueIdOrKey, issueKey, key, issues, issueKeys) and its project fields (projectKey, projectKeyOrId, projectIdOrKey, project). A write whose payload names no project in those fields is allowed by any approved Gate 2 row in a live ledger. A missing ledger, or one with no approved Gate 2 row, is treated as not approved.

Classification of writes. A tool whose bare name starts with a recognised write verb (create, edit, update, transition, delete, add, comment, link and similar) that fails a policy is denied. A tool the hook cannot classify as a read or a write is treated as a potential write: if it fails one of the policies above it is held with ask instead of being denied, and otherwise it is allowed, so an unfamiliar server version stops for a human rather than failing open or hard-blocking the session. If the hook cannot parse its payload, resolve the working directory, or hits an internal error, it also falls back to ask.

Why the row number matters. The hook matches the Gate 2 row by number. That is why Roadmap Review is numbered 1.75 and the Jira gate is never renumbered.

Known residual. Two live, unarchived workshops that push to the same project share gate state, because a tool call carries no signal of which workshop it serves. Archiving the session right after post-push verification, which the workflow already requires, takes its ledger out of play.

The project-context hook

A second hook in the same hooks.json runs hooks/guard-project-context-block.mjs only for Edit and Write calls on a file named CLAUDE.md or CLAUDE.local.md. It denies an edit whose result would remove or change the tsh:project-context block, which tells every session in a code repository where the project's knowledge base is. Any internal error allows the call, so a broken guard cannot lock people out of their own CLAUDE.md. It does not cover a shell command that rewrites the file. initializing-project-context writes the block through its own script, never through Edit or Write, so it is never blocked by this hook.

Prerequisites

• Jira needs the Atlassian MCP server, and tsh-core bundles it. Install tsh-core alongside this plugin and run /mcp once to authenticate; every call then runs under your own Atlassian account. This plugin ships no MCP server of its own. Tool names vary by Atlassian server version, so the workflow discovers what is available before the first push, and nothing here pins an mcp__atlassian__* name in a tool allowlist. See Atlassian.
• Figma needs the Figma MCP server, and tsh-core bundles it too. Run /mcp once and pick figma. Until that sign-in happens, design analysis is reported as blocked rather than silently skipped. See Figma.
• PDFs need nothing. They are read with the standard Read tool.

Where the output goes

Session artifacts live in specifications/<workshop-name>/: the gate ledger, the cleaned transcript, the intent brief, the extracted tasks, the quality review, the roadmap draft and the Jira-ready tasks.

These artifacts outlive the session, in specifications/projects/<project-name>/: the approved roadmap.md, the task-baseline.md that gives the next workshop its continuity context, and domain-dictionary.md, which keeps its own gate ledger, .dictionary-gates.md, at that same project scope.

Not covered here

Implementation and code review are tsh-product-engineering, and E2E and manual QA are tsh-product-testing. Those plugins may not be installed, so this one names the gap instead of linking into them.