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 deltas, preserving parent relationships and existing IDs. Product-level field changes that this MCP cannot write must be returned as an apply-ready proposal for the product UI or API.

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 source basis. Wait for approval before writing. If this MCP connection cannot create or update context units, return the exact content and scope as an apply-ready proposal 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
- if no account matches, stop and propose account creation separately; do not create an account as a side effect of signal ingestion
- 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 in the supported source metadata or additional context; if the current write surface cannot carry it, 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 be represented by the current tool schema. Do not claim that an unsupported direct Signal-to-Insight link was created.

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.

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
- no customer-visible entity contains setup, demo, sandbox, importer, handoff, or unsupported internal language

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.

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.