Product Knowledge Workbench
Menu

Who it is for

For engineering

A handoff from the workbench is a versioned bundle with a published structure, not a slide deck. You can read it in the product with a read-only account, or download it in the folder layout your own method reads. Every requirement says where it came from, and the bundle says what was skipped, stale, assumed, or knowingly kept.

The readable rendering of a handoff bundle: epics and stories with Given, When, Then scenarios, the citations behind them, and the open questions.
The readable rendering of a handoff bundle, as an engineering reader sees it.

What changes for you

  • Answers already recorded

    The questions a product person would have been asked in refinement were asked before the requirements were drafted, and the answers travel in the bundle's provenance with the artifacts they shaped.

  • Evidence you can read yourself

    Each requirement's citations are resolved at export and embedded with their surrounding section. You read the policy behind a rule without asking for access to anything.

  • A starting point for your plan

    The bundle drops into the folder layout of your spec-driven method and brings prompts for the planning you do yourself, so the plan inherits the evidence.

  • Open items listed

    Open questions, assumptions, stale artifacts, untestable scenarios, and decisions to keep an artifact against a newer source are listed, not smoothed over.

What is in a bundle

  • Stories you can test

    Epics and stories with acceptance criteria as Given, When, Then scenarios. The export checks each scenario against testability rules and lists the ones that fail as warnings.

  • The evidence

    Every citation is resolved when the bundle is exported and embedded with its surrounding section, so you can read the passage without access to the knowledge base.

  • The mockup and its walkthrough

    The clickable mockup as one HTML file that opens offline, with an annotated walkthrough of the main path and a table linking screens to requirements and flow steps.

  • What is not settled

    Open questions with a suggested owner, assumptions with their reasons, the product person's answers to each stage's questions, stage gaps, stale artifacts, and every keep-as-is decision with its note.

Files you can process

The handoff page as an engineering reader sees it: the exported bundles with schema version, size, warnings, and the gap and staleness summary, with no controls to change anything.
The handoff page for an engineering reader, with the bundle list and its warnings, and no controls to change anything.

The bundle is bundle.json, validated against a JSON Schema the product owns and versions, plus a Markdown rendering generated from it the same way every time, the mockup, screenshots where a browser was available, the flows, the design tokens, and the design checks, in one zip.

In the layout your method reads

A spec-driven method is a way of working in which engineers, and the coding agents they use, plan and build from written specification files kept in the repository. At export, choose an export profile and the same content and citations are written into the folder shape such a method consumes: a product requirements document, a front-end specification, and one file per story in the style of BMAD; a single specification file in the style of spec-kit; or a requirements file and a design file in the style of Kiro. Each profile is generated deterministically, so exporting the same versions twice gives the same files.

Every bundle also carries a prompts/ folder with the planning prompts for the work the product leaves to you: the architecture document, the task breakdown per story, and the test plan. Each prompt points at the bundle files it draws on and carries the open questions and assumptions, so a plan generated from it keeps the provenance.

A read-only seat

The engineering role reads handoff bundles and approved knowledge, and nothing else. Every control to change something is absent, not just disabled. You can also search approved knowledge yourself and open any cited document at the passage cited.

The mockup, with the path explained

The walkthrough playing in the sandboxed mockup.

The mockup is shown in a sandbox that cannot reach the application. Its walkthrough highlights one element at a time, with a note and the requirement and flow step it shows. Beside the frame, each screen lists what it implements, and the must requirements no screen implements are listed as gaps.

What it does not do

It does not write application code, and it does not connect mockups to live data. The mockup's runtime is a fixed script that only navigates between screens and switches states. It does not create issues in your tracker; the stories are files your team imports in its own way.