1. Choose the workspace and define the outcome
Select the workspace that should own the new Project. Name the initiative “Reviewable export” and write the objective: authorized reviewers can export the exact reviewed walkthrough with its evidence provenance. Choose the PM feature initiative template, or skip all optional structure.
Record open questions about audience, source boundaries and failure recovery. Link an existing research or review Resource using the authorized picker. Keep its original identity; if source access is denied, request access from the owner or choose an accessible artifact.
2. Use only the work structure you need
Start with three records: clarify export scope, implement the export, review the result. Use execution status and an owner only if useful. Save a list for narrative work and a board for status; both read the same records.
Add dates before choosing calendar or timeline. Use view diagnostics to correct mappings. A “done” execution record is a report about work, so leave review, evidence and acceptance dimensions independently visible.
3. Publish the walkthrough and pin the review
The agent writes a package with an overview, implementation detail and limitations. Validate it before publication. Include safe static assets and only exact authorized source references; do not run package scripts.
Compose a Review Session from the exact package and source revisions. State the outcome and acceptance scope. A mutable link to “latest” is not a substitute for the Session manifest.
4. Comment in context and correct the work
Read the rendered overview, inspect selected source, and comment on the export failure behavior. Ask the assigned agent to explain how revoked source access is handled. App-native comments and the contextual Interaction preserve the discussion.
The agent corrects the implementation and publishes a new package revision, then revises the Session with exact targets. Reopen current feedback and compare the exact revisions. If a conditional save conflicts, retain the draft and reconcile against the latest version.
5. Assess each evidence item within its limits
Attach the agent's report as reported evidence. Request an independent provider observation for the exact authorized commit when available. Read which suite ran, what it assessed and whether its source revision matches the claim.
Missing CI, revoked access or an unavailable source capture remains a gap. Do not convert a report into verification or treat a passing check as human approval.
6. Request the exact human decision
Request review for the current immutable Session manifest and requirement scope. The eligible human can inspect the request and make their own Decision. The agent waits or revises; it cannot accept on their behalf.
Until that person decides, the state is awaiting_human. After acceptance, retain the receipt for that exact scope. A later material change can require renewed review while preserving the earlier history. This tutorial itself records no real human acceptance.
Continue with the tested surface
Public technical documentation covers installation, current scopes, canonical request fixtures, compatibility and recovery. Read OpenAPI or discover MCP tools before enabling a client. The skills integration guide describes supported installation targets and their limits.
Projects, Trackers and Agentic Engineering Review explain the candidate product surfaces.