Create delivery artifacts without losing the product decision

Start from an initiative whose decision context is ready enough to support downstream work:

• the problem and affected user are explicit
• linked evidence supports the problem
• the opportunity and idea history remain visible
• in-scope and out-of-scope boundaries are recorded
• constraints, risks, dependencies, and open questions are visible
• a success check is defined

If the team is still comparing solution directions, return to the idea or study. A longer document does not make an unresolved decision ready.

Owners and Admins can use Settings → Definition to configure how the workspace drafts requirements, documentation, and user stories.

Use templates for durable standards:

• required sections and terminology
• audience and level of detail
• examples of acceptable output
• acceptance-criteria format
• security, privacy, accessibility, rollout, or QA checks that should be considered

Do not paste secrets, customer-private data, or a one-off initiative decision into a reusable template. Keep source-specific facts on the initiative.

Choose the artifact that supports the next decision:

• an executive brief for intent, impact, tradeoffs, and commitment
• a product requirements document for problem, scope, behavior, and outcomes
• an engineering specification for constraints, dependencies, interfaces, and failure states
• a QA plan for acceptance checks, edge cases, environments, and rollout risk
• a prototype path or study brief when the solution still needs validation

Generate from the initiative so the draft can use the same approved context. Name the audience and purpose; avoid asking one artifact to serve every reader.

Review the draft against the source, not just for writing quality:

1. Verify every material claim against linked evidence or an explicit decision.
2. Remove invented requirements, outcomes, dates, integrations, or technical behavior.
3. Confirm in-scope and out-of-scope boundaries.
4. Resolve contradictions between the artifact and initiative.
5. Make acceptance checks observable and testable.
6. Assign open questions and decisions.
7. Record the accountable reviewer.

If a review changes the actual product decision, update the initiative first and then refresh the artifact. Do not hide a scope change inside a document edit.

Break the approved scope into work that can be reviewed and delivered:

• each story should express a user or system outcome
• acceptance checks should describe observable behavior
• tasks should be small enough to assign and verify
• dependencies and ordering should be explicit
• technical notes should clarify constraints without replacing engineering judgment
• excluded work should remain excluded

Review the complete hierarchy before creating issues in another system. A clean hierarchy is easier to sync and maintain than a batch of disconnected generated tickets.

Choose the delivery path that matches the team:

• Jira for issue hierarchy and delivery synchronization
• Linear for Linear work items
• GitHub for repository and pull-request traceability
• MCP for reviewed context in Codex, Cursor, Claude, ChatGPT, and other compatible agents
• a purpose-built handoff such as Cursor, v0, or Lovable

Before writing downstream, confirm the destination, project, hierarchy, field mapping, and permissions. Review destructive or duplicate-prone operations separately.

When scope or delivery changes:

1. Record the decision and reason on the initiative.
2. Update the affected requirement, story, task, or artifact.
3. Re-run review for acceptance criteria, dependencies, and risk.
4. Sync or communicate the approved delta downstream.
5. Preserve the prior rationale when it matters for audit or learning.

Do not regenerate every artifact automatically after a small edit. Refresh only what is affected and review the change.

The handoff is ready when:

• one initiative remains the source of the approved decision
• each artifact has a clear audience and purpose
• claims, constraints, and scope are traceable to evidence or explicit decisions
• generated material has an accountable human reviewer
• stories and tasks form a coherent hierarchy with testable acceptance checks
• the destination and field mapping were reviewed before sync
• later changes have a defined path back through the source