Prepare documents and delivery work

Start with an initiative that has an owning team, a clear problem, linked evidence, scope boundaries, constraints, and a success check. Resolve or assign open questions before drafting.

Confirm every team that needs access. Initiative tasks follow those team assignments; standalone tasks and cycles each require a team. See Team roles and work access.

Owners and Admins can configure templates in Settings → Definition. Include required sections, terminology, audience, acceptance criteria, and relevant review checks. Keep initiative-specific decisions on the initiative and secrets out of reusable templates.

Choose the output for its reader:

Generate from the initiative. If the solution still needs testing, prepare a prototype or study first.

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.

Open Delivery → Tasks and choose Work map. Each row is a role, and tasks run left to right in the order they can happen: a task sits one step after the latest task it waits on. A task that has not started reads Can start or Waits on a number. Cards are coloured by effort; choose Status to colour them by progress.

To change the plan on the map:

• drag from a card's edge to another card to say one waits on the other
• click a line, then Remove link, to take a dependency away
• drag a card up or down to move it to another role

Every change saves at once and offers Undo. A link that would make a loop is refused before you let go. Change tasks synced from Linear in Linear.

An initiative and an idea have an owner, who is accountable for the outcome. A task has an assignee, who is doing it now. Only people who can work on the record are offered.

The person you choose gets one email a minute or two later, unless they turned those emails off. On Home, For you lists the questions waiting on them, what was handed to them this week and their open tasks. Owners and assignees do not change who can see or edit the work; team roles do.

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.

The external delivery link does not change Zentrik team access. Confirm the owning team in Zentrik and the destination team or project before the first sync.

Check that the initiative, reviewed documents, stories, and tasks describe the same scope. Confirm the destination and field mapping before creating downstream work. Every generated output needs a named reviewer.

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.