Product Knowledge Workbench
Menu

The product

Fits your workflow

The workbench does not replace your wiki, your design tool, or your tracker. It sits between them: it reads from where your knowledge already lives, works from your design system, and hands engineering files in the shape their method reads. It meets your team at three hand-offs, and each one leaves a record you can check later.

Where it sits

Picture the path an idea takes today: someone reads the wiki and the policies, writes a brief, sketches screens in a design tool, argues it through review, and types stories into the tracker. The workbench takes the reading, the drafting, and the checking in the middle. Your wiki stays the source of what the organization knows; your design system stays the source of how screens look; your tracker and your engineers' tools stay where the work is planned and built.

Hand-off one: knowledge in

Sources are connected once and kept in step. Nothing is moved or copied by hand, and nothing is used until a reviewer approves it.

  • Your wiki and shared folders

    Confluence Cloud spaces and shared folders sync on a schedule; a page edited at its source comes back for re-review while the approved version stays in use.

  • Your public websites

    Pages from the domains you allow, within the depth and page limits you set, respecting each site's robots rules.

  • Files and spreadsheets

    Word, PDF with a text layer, Markdown, plain text, Excel, CSV, and OpenDocument spreadsheets, uploaded from the browser.

  • What people know

    Manual entries for the knowledge nobody wrote down, reviewed like any other document. New kinds of source are plugins written against a published contract.

Hand-off two: decisions recorded

The decisions people make along the way are kept on the artifact they shaped, so nobody has to remember why a requirement reads the way it does.

  • Answers to the stage interviews

    Each answer sits beside its question on the version it informed, with who answered and when. A skipped question is shown as an assumption.

  • Open questions decided

    A conflict between two documents is decided by a person, with a note, and the decision travels to the bundle.

  • Ready marks

    A reviewer marks a stage ready, and the owner's own self-check is shown as a different kind of mark. A later change shows the mark as outdated.

  • Responses to change

    Regenerate, keep as is with a note, or merge. A decision to keep an artifact against a newer source is recorded and shown to engineering.

Beside it, your design system

A visual design in the sandboxed frame, built from the registered design system, with its screen and state switchers and the requirements it implements beside it.
A visual design in the sandbox, built from a registered design system, with the requirements it implements beside it.

Register your design system by uploading a token file in the Design Tokens Format (the common file format for colors, type, and spacing), an export of your Figma variables, or by entering tokens by hand. You confirm how its tokens map to the components, and the workbench checks the contrast of every color pair. Visual designs and mockups use only those tokens. Designs come out as HTML and CSS you can open anywhere, with PNG screenshots when a browser is installed; they are not exported back into Figma.

Hand-off three: bundle out

The handoff bundle is a zip of bundle.json, its Markdown rendering, the mockup as one HTML file, screenshots, flows, tokens, and design checks. Engineering can read it in the product with a read-only account or work from the files. The structure is a versioned JSON Schema, so a team can build its own import into its tracker.

  • Export profiles for spec-driven methods

    The same bundle written into the folder layouts spec-driven development methods read: a product requirements document with a front-end specification and one file per story, a single specification file, or a requirements file and a design file. Chosen at export; same content and citations in each.

  • Planning prompts for engineering

    A prompts/ folder with the prompts engineering runs for what the product leaves to them, the architecture document, the task breakdown, and the test plan, each pointing at the bundle files it draws on.

Around it, how your team already works

  • One owner per initiative

    An initiative has one owner who does the work. Reviewers read every initiative and mark stages ready; admins can transfer ownership. Several people work at once, each on their own initiatives.

  • Reviews that fit a review habit

    Reviewers work one queue, filtered by source, kind, and age, with a diff for every re-review and a bulk approve for a source's first load that still records one approval per document.

  • Roles that combine

    One person can be product and reviewer; an engineering reader sees only bundles and approved knowledge.

  • Your models

    OpenAI, Anthropic, or any OpenAI-compatible endpoint, chosen per task, with your own keys, and a local embedding service that runs beside the database.

What it is not

It is not a chat assistant: runs are structured work you can steer, and the questions it asks are short and recorded, not a conversation. It does not generate application code, connect mockups to live data, or let you edit a mockup's HTML directly; you change a screen by pointing at it, and the change goes through the screen specification so the sandbox and the checks hold.