Feature tree setup

Set up your product feature tree with an agent

Give an approved agent access to your product and first-party documentation, then let it propose, create, and illustrate a feature tree without uploading your codebase to Zentrik.

A useful feature tree gives Zentrik a shared map of what the product already does. It helps evidence, ideas, initiatives, studies, and coding-agent handoffs stay connected to the right product area.

Complete the setup in two passes:

Build or repair the feature hierarchy from the running product, codebase, and approved documentation.
Add safe product images to the features that benefit from a visual reference.

The agent can inspect source material in its existing environment. Send only the product context and images approved for Zentrik, not source files, credentials, or private excerpts.

Prepare safe access

Use an agent that can access the Zentrik MCP connector and the product sources you approve. This may be Codex, Claude Code, Cursor, or another MCP client with codebase and browser access.

Give the agent:

the exact Zentrik workspace and product name
read access to the product codebase
official product, help, API, and release documentation
an approved local, staging, or production browser session
the product areas that are in or out of scope

Keep credentials in environment variables or the browser session. Do not paste API keys, tokens, source files, customer records, internal URLs, or unapproved excerpts into prompts or feature descriptions.

Build the feature tree

Start with the existing Zentrik product and feature hierarchy. Repair the current tree instead of replacing it when existing records already link to evidence or work.

Use these sources in order:

Running, shipped behavior
Routes, navigation, domain models, permissions, feature flags, and tests
Official product docs, help content, API docs, and release notes
Approved requirements and other product material

Root nodes should be real product areas, workflows, modules, or surfaces. Child nodes should be specific capabilities that a teammate or agent could investigate, plan, or build against. Use depth only where the product genuinely has nested workflows, states, or sub-services.

Do not target a fixed number of nodes. Do not turn libraries, architecture, setup steps, or marketing adjectives into features.

Copy-ready feature-tree prompt

Code45 lines

Build or repair the Zentrik feature tree for:

- Workspace: <exact workspace name>
- Product: <exact product name>
- Codebase: <repository or local path>
- Official documentation: <URLs or local paths>
- Scope: <included and excluded product areas>

Confirm the connected workspace and exact product first. Read the current
product context and complete feature hierarchy before proposing changes.

Inspect the running product when available, plus navigation, permissions,
release notes, help content, API documentation, and approved product material.
Keep credentials, source files, private URLs, personal data, and customer data
that is not approved for Zentrik out of feature names and descriptions.

Create a tree that reflects how users get value:
- roots are real product areas, workflows, modules, or surfaces
- the product itself is not a root feature
- parents are concise signposts
- leaves are specific capabilities
- use the product's own vocabulary
- preserve valid existing records and relationships
- merge overlapping meanings
- split broad nodes only when they hide independently useful capabilities
- do not target a fixed count or depth

Write concise leaf descriptions that explain who uses the capability, the job,
what the user can do, what the product enables, and any boundary needed to
prevent confusion. Do not add source inventories, development notes, delivery
status, unsupported outcomes, or filler.

Before writing, return:
1. current-tree assessment
2. proposed final hierarchy
3. compact change list: keep, create, update, move, merge, or remove
4. evidence for material changes
5. areas that still need confirmation

Wait for approval. Then re-read the tree, apply only the approved delta, create
parents before children, and read the complete hierarchy back after each batch.
Never remove or rename linked nodes without explicit confirmation.

Finish with feature and root counts, duplicate names, invalid parents, remaining
overlap, and any part of the product map that still needs clarification.

Review and apply

Use MCP for the normal agent workflow:

get_product_context
get_product_features
create_product_feature and update_product_feature
bulk_create_product_features and bulk_update_product_features for approved batches of up to 50

Create parents before children and use exact product and parent names. Feature names must be unique within the product for reliable name-based updates and screenshot attachment.

Treat removal as a separate decision. Existing feature IDs may already connect to evidence, ideas, studies, or initiatives.

Add feature images

Finish reviewing the tree before adding images. Capture or select images only from product environments and data that your organization has approved for this purpose.

Capture the smallest real product state that proves each capability. One image may support several features when the same screen truthfully shows them. Do not attach a generic dashboard just to fill coverage.

Use meaningful populated data and descriptive filenames such as product-feature-state.jpg. Add a mobile image only when responsive behavior is part of the capability.

Review every image before upload. Exclude secrets, personal data, password screens, unrelated browser content, and customer information that is not approved for this use.

Copy-ready screenshot prompt

Code23 lines

Populate screenshots for the approved Zentrik feature tree.

- Product: <exact product name>
- Product environment: <approved URL>
- Image location: <approved folder or asset library>

Read the complete tree first. For every feature, identify the smallest real
product state that proves the capability. Reuse an image only when the same
screen truthfully demonstrates each linked feature.

Use an approved account and meaningful data. Capture mobile only when responsive
behavior is part of the feature. Exclude secrets, personal data, password
screens, unrelated browser content, and customer information that is not
approved for this use.

Prepare a mapping with the exact product name, exact feature name, and image
filename. Show the mapping for review before upload.

After approval, attach each image to the exact product and feature. Check whether
an upload succeeded before retrying, and do not attach the same image twice.

Inspect the feature panels in Zentrik and report missing, repeated, irrelevant,
stale, or privacy-sensitive images.

Available upload methods

An MCP-connected agent can use attach_product_feature_image after the tree and image mapping are approved. The External API also supports feature creation, updates, and image upload for teams that manage product context through an automated workflow.

Use PNG, JPEG, WebP, or GIF files up to 10 MB. Keep API credentials in your approved secret store, verify each result before retrying, and inspect the finished feature in Zentrik.

Verify the result

The setup is ready when:

product boundaries and names are correct
roots and children reflect the real product
descriptions are specific enough for another agent to use
duplicate names and overlapping meanings are resolved
every parent reference is valid
inspectable capabilities have truthful screenshots
screenshots contain no secrets or data that is not approved for this use
uploaded images match the reviewed mapping
uncertain capabilities are left for review instead of filled with guesses

Troubleshooting

Check these steps against what you see in your workspace. If something differs, note your workspace name and the screen, then contact us.

The proposed tree looks generic

Ask the agent to cite the shipped behavior or product documentation behind each material node. Remove capabilities that could describe any product in the category.

A feature cannot be updated by name

Check for duplicate feature names in the product. Resolve ambiguity before name-based MCP updates or screenshot attachment.

A screenshot may expose private information

Do not upload it. Recreate the state with approved test data, mask the sensitive value in the product when supported, or leave the feature without an image until a safe capture exists.

Continue from here

01Workspace contextFlat context for company and market narrative, plus named records (product, OKRs, personas, KPIs, features) so Discovery and initiatives stay aligned with how you run the product.02Evidence → initiativesHow customer evidence becomes learnings, shared bets, solution ideas, and committed initiatives in Zentrik, with workspace context supporting the flow.03Getting startedSet up a Zentrik workspace, add product context, invite the right teammates, bring in customer evidence, and reach a first evidence-backed product decision.

Did this guide answer your question?

Your response helps us prioritize missing or unclear documentation.

Still stuck?

Send your question to Zentrik support. This guide will be included automatically.

Ask Zentrik support