Start with Zentrik MCP

We are preparing a Zentrik workspace from first-party product material.

Inspect the current workspace and all supplied product sources. Identify the exact products or product lines that should exist in Zentrik.

Treat something as a separate product only when it has a distinct buyer or budget owner, can be implemented independently, has distinct success metrics or roadmap ownership, or is marketed as a standalone solution.

Keep something inside an existing product when it is mainly a workflow, module, shared utility, input/output dependency, or supporting service.

Return:
- proposed product names and exact product boundaries
- the primary users, buyers, and operators for each product
- the major workflows and value areas
- shared capabilities that should not be duplicated across products
- cross-product references that need review
- unresolved boundary questions
- the source excerpt supporting every decision

Do not create or update anything yet. Do not force ambiguous material into the first product you inspect.

Build or repair the approved Zentrik product surface.

First read the existing product, features, personas, KPIs, tech stack, and questions. Propose a patch rather than regenerating the product from scratch.

Create a feature map that mirrors how users get value from the product:
- root nodes are real product areas, workflow stages, surfaces, modules, or capability groups
- the product itself is not a feature root
- parent nodes are concise signposts
- child nodes are actionable capabilities with meaningful detail
- use depth only when the product genuinely has nested workflows, states, data flows, or sub-services
- a focused product may be shallow; a complex product may need several levels
- do not target an arbitrary feature count or make every product have the same shape
- use the product's own vocabulary
- merge duplicate or overlapping nodes
- do not create features for documents, setup steps, screens copied from a source, deployment details, browser behavior, storage mechanisms, generic architecture, or technology names

For every proposed leaf feature, explain:
- the user job or problem
- who uses it and when
- what the user does
- what the product produces or enables
- what success looks like
- how it connects to adjacent capabilities

Also propose only source-supported changes to:
- product description, mission, and type
- personas with goals, pain points, and use cases
- measurable KPIs
- concrete technologies in the tech stack
- unresolved product questions

Use the available product read tools to inspect the current state. After approval, use the feature and persona mutation tools only for approved changes, preserving parent relationships and existing IDs. Return any other product-field changes as a reviewable proposal that can be applied in Zentrik.

Create a proposed context library for the approved Zentrik products.

Read the product surface and supplied first-party material. Create context-unit proposals only for durable, reusable guidance such as:
- terminology and definitions
- product and portfolio boundaries
- strategy and product principles
- business rules and constraints
- security, compliance, and trust requirements
- customer or operating models
- deployment, implementation, and service models
- integration assumptions
- competitive differentiation
- market or adoption constraints
- durable decisions

Each context unit must have:
- a short, specific name
- a concise description of when an agent should retrieve it
- product or workspace scope
- a focused Markdown body
- supporting source excerpts

Keep each unit about one reusable concept. Do not duplicate the product description, feature map, persona fields, or KPI list. Do not create units for raw customer evidence, ordinary document summaries, source inventories, temporary notes, or setup instructions. Preserve the original documents separately for retrieval.

Show the proposed units, duplicates, conflicts, scope decisions, and evidence. Wait for approval before writing. If context-unit changes are unavailable through MCP, return the exact content and scope for review in Zentrik instead of misclassifying it as a Signal or Idea.

Propose the outcome objectives that should guide product decisions in this Zentrik workspace.

Use first-party product strategy, mission, customer outcomes, current product pressures, and approved context units. Propose the smallest useful set of objectives, normally one to three, with measurable key results only when the source material supports them. If no objective is defensible yet, explain the missing strategic input instead of inventing one.

Objectives must describe outcomes, not feature delivery. Key results must use measurable metric shapes without inventing baselines or precision. Scope each objective to the correct product or portfolio.

Return:
- strategy reading
- candidate objectives and source basis
- recommended objectives and why each is needed
- unresolved assumptions

Do not create or update objectives unless a supported write surface is available and I explicitly approve the final version.

Import the approved first-party evidence into the connected Zentrik workspace.

First identify the exact product, account, source, date, and logical evidence unit. Split distinct sources into separate Signals. Do not create a daily summary Signal when the underlying sources should remain separately traceable.

Use the correct Signal type:
- transcript
- support_ticket
- review
- feedback_record
- discovery_report

Choose the most specific context available, such as user_interview, feature_feedback, support_request, problem_discovery, competitive_evaluation, usability_testing, or discovery_report.

Before writing:
- search for likely duplicates
- confirm the product and account links
- if the source names a customer, search existing accounts by exact name, domain, or external ID; use the matching account ID
- when the source supplies trustworthy participant emails, propose whether to match existing People or create missing external People
- keep missing Account creation separate; enable it only after explicit approval and only from an unambiguous professional participant domain
- if no account matches and Account creation was not approved, leave the Person unassigned; do not infer an Account from prose
- split a multi-customer source when account attribution would otherwise be ambiguous
- preserve the original source wording
- preserve a stable external ID when available
- preserve a source URL or reference when available; if it cannot be stored, report it as missing rather than inventing one
- separate what the source says from our interpretation

Show the proposed Signal metadata and source body, then wait for approval. After approval, ingest the Signal using the supported MCP fields, return its public ID and workflow handle, and poll until processing finishes or fails.

After processing, read the result and report the generated Insights, supporting evidence, missing links, source-quality limits, and duplicate risks. Do not create Opportunities, Ideas, or Initiatives during ingestion.

Build a reviewed evidence chain from the processed Zentrik Signals.

Use discovery.search, discovery.get_entity_context, signals.get_evidence_pack, and discovery.audit_traceability to inspect the evidence before creating downstream entities.

Prefer the Insights generated by Signal processing. If a manual Insight is needed because the generated result is missing or unusable, show how its evidence will remain traceable. Do not claim that a link was created unless it is visible in Zentrik.

For each candidate Insight:
- express one source-backed learning
- identify the product or workflow
- state the product decision it could change
- link the supporting Signal IDs
- distinguish evidence from interpretation

For each Opportunity:
- describe an unmet need, product problem, or decision area
- group related Insights
- do not describe a solution or a Zentrik workflow

For each Idea:
- describe a feasible solution path for the existing product
- link the supporting Opportunity and Insight IDs
- identify affected users, accounts, features, and outcomes
- do not invent priority, effort, impact, or account value

Return a proposed Insight -> Opportunity -> Idea graph with duplicate and missing-evidence checks. Wait for approval before writing. After approval, create only the selected entities and read them back to verify every link and product assignment.

Turn the approved Zentrik Idea into one initiative-quality work item.

Read the Idea, its Opportunity, supporting Insights and Signals, the affected product feature nodes, personas, objectives, and relevant context units.

Use teams.list to resolve the accessible team or teams that will own the work. Check canEdit for each team. Include the approved team IDs when creating the initiative; do not copy a team ID from an unrelated record.

Create a concise initiative proposal with:
- problem and affected users
- why this matters now
- measurable outcomes
- MVP scope
- explicit non-goals
- functional requirements
- dependencies and risks
- success metrics
- related product feature nodes
- evidence and decision lineage

Keep the initiative inside the customer's actual product surface. Do not create a Zentrik-process initiative unless Zentrik is the product being modeled. Do not invent integrations, data sources, technical capabilities, or customer commitments.

Show the proposal first. After approval, create the initiative with the supported tools, then read back its questions, documents, user stories, and status. Report any relationship that the MCP cannot represent directly rather than implying that it was linked.

Run a final read-only quality audit of this Zentrik workspace.

Check:
- product names and boundaries match first-party sources
- product descriptions and missions are concise and canonical
- feature maps have meaningful roots, valid parent links, useful depth, no duplicates, and no setup or architecture noise
- leaf features explain user job, action, output, success, and adjacent connections
- personas are real product roles with useful goals, pain points, and use cases
- KPIs are measurable and tech-stack rows are concrete
- context units are durable, focused, correctly scoped, and not duplicates of product fields or source documents
- Signals have correct types, product/account links, provenance, stable IDs, and completed processing
- Insights are source-backed and unitary
- Opportunities describe problems rather than solutions
- Ideas are feasible, linked, and supported by evidence
- initiatives trace to approved Ideas and real feature areas
- record names and descriptions are clear to their intended audience

Use discovery.audit_traceability and the available product, context, Signal, Discovery, and initiative read tools. Return:
- current counts and relationship health
- duplicate, orphan, stale, or unsupported records
- missing source links or product assignments
- readiness: ready for ongoing product work, ready with named gaps, or not ready
- the smallest correction plan

Do not mutate anything during this audit.

Find the pending tasks in my team's current sprint. Show priority, owner and
status, then load the selected task's instructions and linked Idea or Evidence.
After implementing and testing the work, attach its PR and move the task to
review. When the work is delivered, update the Idea if its full scope is complete
and mark the specific evidence records it addressed as acted on.

What recurring customer or product themes appear in this Zentrik workspace?
Group them by theme, include supporting signals or quotes, and call out where
evidence is weak or missing.

Find the ideas or opportunities with the clearest evidence trails. For each one,
summarize the linked signals, insights, accounts, and what decision it supports.

Compare open opportunities using available ARR or account impact, evidence
strength, linked insights, linked ideas, and status. Return a table with a
recommended next action and note any missing data.

Get context for [initiative name or ID] and draft a concise PRD brief with
problem, users, evidence, scope, non-goals, risks, and open questions.

If I approve changes to the Initiative or answer its open questions, update
those source fields first. Then regenerate the existing PRD from current
Initiative state with initiative_documents.regenerate. Inspect the returned
job with initiative_documents.get_regeneration until it is completed or failed,
and report the document ID and final status. Do not use update_html for this
workflow; that is a direct overwrite, not a source-grounded rebuild.

Review the existing Studies linked to [Idea or Initiative name or ID].

We need to learn: [specific learning need or decision].

Tell me whether an existing Study already covers this question, its current
status, response coverage, and what remains unresolved. Do not create or update
anything yet.

Create one private self-guided Study draft linked to [Idea or Initiative name or ID].

We need to learn: [specific learning question].
Audience: [who should participate and relevant screening context].
Decision: [what the team will decide with the result].
Success looks like: [the evidence threshold or behavior that would be sufficient].

Use this selected excerpt only to shape the plan:
[paste the relevant excerpt]

If one learning need and one context are clear, create one private Study draft
linked to that Idea or Initiative without asking me to confirm the same action
again. Use a stable idempotency key for retries. If the decision or context is
materially ambiguous, ask one focused question and create nothing yet.

Then read the Study back and report whether it was created or reused, its public
ID, audience, decision, learning question, full activity plan, setup blockers,
and Zentrik link. If I ask for a revision, preserve the returned activity and
option IDs and update the response-free draft using its latest concurrency
timestamp.

After responses arrive, show aggregate evidence and feedback ratings with the
participant name, email, and account when known. Do not include raw research
answers, notes, or transcripts. Generate draft findings only when I explicitly
ask, then report the evidence strength, open questions, and Zentrik review link.

Do not publish the Study, create a participant link, invite anyone, turn the
meeting into findings, or create evidence as a side effect. Do not treat draft
findings as reviewed. If the excerpt
should become durable evidence, propose a separate Signal workflow.

Revise [STUDY-ID] so [specific change]. Keep the existing activity and option
IDs for unchanged parts of the plan, use the latest version you just read, and
report the complete updated plan and any remaining launch blockers.

Create one private Live Interview Study linked to [Idea or Initiative name or ID].

We have [30] minutes with [audience]. We need to understand [learning question]
so we can decide [decision]. Build a conversational guide with an opening,
focused topics, probes, what to listen for, and completion criteria. Keep it to
the available time. Then report the guide, its total duration, setup blockers,
and Zentrik link. Do not start the Study or add completed interviews.

For [STUDY-ID], summarize response coverage, completion, and aggregate feedback.
Compare the available coverage with the Study's stated sufficiency criteria.
Show feedback ratings with participant name, email, and account when known.
Do not infer answer quality from counts alone. Do not include raw research
answers, notes, or transcripts, and do not generate findings yet.

Generate draft findings for [STUDY-ID]. Report each claim's evidence strength,
sample count and evidence-reference count, recommended next step, unresolved
questions, and the Zentrik review link. Keep every finding in draft review state.

Review [idea name or ID] and its linked Initiative before changing anything.

First call discovery.describe_taxonomy when taxonomy fields matter. Use the
exact active group and option keys. Use analytics.aggregate_entities with
entity: idea and groupBy: taxonomy when I ask for counts by an Idea taxonomy
field; do not download and count raw Ideas yourself.

For the selected Idea:
- use idea_questions.list to show planning questions and current answers
- wait for my approval before using idea_questions.answer
- use ideas.create or ideas.update classifications only for the taxonomy groups
  I approve; omitted groups must remain unchanged
- use ideas.update projectId to attach it to one Initiative, or projectId: null
  to detach it; if it is linked elsewhere, detach it first instead of moving it
  implicitly
- for a status-only edit, use ideas.set_status with the exact configured status
  label and pass expectedCurrentStatus when confirming a previously read Idea;
  do not use it for the promoted-role status
- if I ask to remove a comment, identify the exact comment and wait for explicit
  confirmation before using ideas.delete_comment

For the selected Initiative:
- use teams.list before proposing a team change; do not guess team IDs
- show the complete current and proposed team sets
- wait for my approval before using initiatives.set_teams
- keep at least one team assigned, and report when my workspace role cannot make
  the change

When approved Initiative or question changes make an Initiative Brief, PRD, or
TDD stale, use initiative_documents.regenerate with INITIATIVE_BRIEF, PRD, or
TDD. Poll initiative_documents.get_regeneration until it completes or fails.
Do not substitute initiative_documents.update_html; that directly overwrites
stored HTML instead of rebuilding from current Initiative state.

Return the public IDs, changed taxonomy groups or relationship, and final job
receipt. Do not imply that a write succeeded unless you read back its result.

What did [person name] change in Zentrik through [Claude, Claude Code, ChatGPT,
the Zentrik workspace assistant, or @Zentrik in Slack] in the last [24 hours / 7 days]? Show confirmed product
changes separately from retries, failures, unfinished work, or results that
could not be verified. Summarize duplicates, state whether the requested time
and channel are fully covered, name any coverage gaps, and do not change anything during this review.