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.

The recommended workflow has two separate passes:

  1. Build or repair the feature hierarchy from the running product, codebase, and approved documentation.
  2. Capture safe product screenshots and attach them to the approved features.

The agent can inspect source material in its existing environment. It should send only the approved product context and screenshots needed in 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 product truth in this order:

  1. Running, shipped behavior
  2. Routes, navigation, domain models, permissions, feature flags, and tests
  3. Official product docs, help content, API docs, and release notes
  4. Approved requirements and internal 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

Code48 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, routes, domain
models, permissions, feature flags, tests, release notes, help content, API
documentation, and approved first-party product material. Keep source analysis
inside the approved environment. Do not send source files, code excerpts,
credentials, internal URLs, personal data, or unapproved customer data to
Zentrik.

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, implementation narration,
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. source basis for material changes
5. unresolved or source-limited areas

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 a short judgment on whether a product teammate could understand the
product without narration.

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.

Capture screenshots separately

Stabilize the tree before capturing images. Use Playwright when the agent can run the application or reuse an authenticated browser storage state. A browser-control tool is also suitable for a small manual pass.

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 a stable desktop viewport, meaningful populated data, and semantic filenames such as product-feature-state.jpg. Add mobile only when responsive behavior is part of the capability.

js4 lines
await page.setViewportSize({ width: 1440, height: 900 });
await page.goto(featureUrl, { waitUntil: 'networkidle' });
await page.getByText(expectedContent, { exact: false }).waitFor();
await page.screenshot({ path: screenshotPath, fullPage: false });

Review every image at full resolution. Exclude secrets, personal data, password UI, unrelated browser tabs, and unapproved customer information.

Copy-ready screenshot prompt

Code29 lines
Populate screenshots for the approved Zentrik feature tree.

- Product: <exact product name>
- Application: <local, staging, or hosted URL>
- Authentication: use the approved browser session or storage state
- Output directory: <local path>

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 Playwright or an authenticated browser tool to open the route, wait for the
meaningful populated state, dismiss temporary overlays, and capture one stable
desktop viewport. Capture mobile only when responsive behavior is part of the
feature. Use approved data and exclude secrets, personal data, password UI,
internal browser tabs, and unapproved customer information.

Save semantic filenames and prepare a local mapping with exact product name,
exact feature name, filename, product route, and capture date. Show the mapping
before upload and wait for approval.

After approval, attach each image with attach_product_feature_image using the
exact product and feature names, matching MIME type, and raw base64 bytes without
a data URL prefix. Do not retry without checking whether the first call
succeeded, and do not attach the same filename twice.

Preserve the returned image ID, feature ID, filename, size, and timestamp.
Inspect the feature panels in Zentrik and report missing images, repeated
filenames, irrelevant images, stale states, or privacy concerns.

MCP and API tools

attach_product_feature_image accepts an exact product name, exact feature name, filename, MIME type, and raw base64 data. Supported formats are PNG, JPEG, WebP, and GIF up to 10 MB. Attachment is not idempotent, so verify before retrying.

The External API provides the same feature workflow when MCP is unavailable:

text4 lines
GET    /external/v1/products/:productId/features
POST   /external/v1/products/:productId/features
PATCH  /external/v1/products/:productId/features/:featureId
POST   /external/v1/products/:productId/features/:featureId/images

Image upload uses multipart field file and products:write. Keep the API key in an environment variable:

bash4 lines
curl -sS -X POST \
  -H "Authorization: Bearer $ZENTRIK_API_KEY" \
  -F "file=@screenshots/example-feature.jpg" \
  "$ZENTRIK_API_BASE/external/v1/products/$PRODUCT_ID/features/$FEATURE_ID/images"

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 unapproved data
  • attachment responses match the local mapping
  • source limits are stated 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 route, shipped behavior, test, or first-party 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.