You need to publish a documentation portal for your product. You have a product brief and no plan yet. This example shows how documents, projects, issues, the Plan section, and specialists divide that work - and where judgment has to stay yours.

​
The setup

The brief goes in Docs: the objective, the audience, editorial principles, success criteria, and known risks. The project is the status home for the launch. One issue carries the deliverable, with a definition of done that names real acceptance checks: verified workflows, useful screenshots, navigation that works at every width, accessibility, light and dark modes, and a QA pass. Nothing runs until the brief has been reviewed. That review is where judgment lives.

​
Use each surface for a different job

  • Docs hold the objective, audience, editorial principles, success criteria, and risks. This is what every other surface points back to.
  • The project is where the launch’s status lives: its issues, its Plan section, and its updates.
  • The issue is the executable contract: the deliverable, the definition of done, and links to the brief.
  • The Plan section turns the issue into sub-issues once the product decisions are settled - not before.
  • Specialists are reviewers and builders, and each one needs its scope written down in the prompt.

​
Have the brief reviewed before anything runs

Bring in a specialist to critique the brief itself: which requirements are testable, which are missing, which conflict. Ask it to label every statement as observed, inferred, or proposed, and to cite the section it came from. A critique that cannot point to a line in the brief is opinion, and you want the opinions separated from the readings.
Fluent output is not evidence: a polished review can still assert specifics the brief never states. The citation labels are how you catch it. If a claim matters, ask for the section before you accept it.

​
Plan only when the decisions are settled

When the review has resolved what the portal must do, hand the issue to planning. Sub-issues become the trackable pieces: drafts per section, the walkthrough, screenshots, accessibility, QA. Each sub-issue carries its own properties and its own Plan and Build actions, so pieces can be reviewed and dispatched separately. Reopen the issue and confirm the sub-issues exist before you treat planning as done.

​
Approve durable writes one by one

Agents write documents, create issues, and run plans through tool approvals. Allow once while the workflow is new; the approval card shows what will run before it runs. After a run, check that what was promised actually exists: the draft documents are in Docs, the sub-issues are on the issue, the QA report is linked.

​
What good looks like

  • Every brief requirement is either testable or explicitly parked as an open question.
  • The review’s claims carry citations you can check in seconds.
  • Planning started after the decisions, and its sub-issues exist on the issue.
  • Every durable write was approved, and everything promised is findable in the workspace.