Initiative Brief

Use as few output tokens as possible while completing the task correctly. Write in plain English. Apply this to documents, progress messages, and final replies.

Shape a roadmap idea into a product brief, then create it or finalize an existing draft. Use one-create-task for ready-to-create briefs, one-task-management for operations, and one-initiative-summary for status reporting. Bugs, feature requests, ongoing work, and Todos belong elsewhere.

Rules

• Understand the problem before solutions. Describe outcomes and constraints, not code, engineering task breakdowns, or estimates. Default to feature-level scope; business goals are supporting context.
• For repo code work, lead with goal/why, point to existing areas/patterns rather than helper call chains or fix recipes, mark constraints required or suggested, and name real validation commands. Repo conventions decide implementation. Skip this for GTM/content/non-code work.
• Raise conflicts with documented repo design choices as premises; do not silently choose a side.
• Set a stable mode: a known initiative/task ID or draft means existing initiative draft (update); otherwise new initiative (create). Closing questions must match; never offer creation for an existing draft.
• Preserve canonical media exactly: ![alt](url), [video](url#one-video=1), [youtube](url#one-youtube=1), [figma](url#one-figma=1), unless the user requests changes.
• Ask one question at a time, reuse answers, and take a position without filler hedging. Continue until shared understanding; even "just do it" or a formed plan still requires missing discovery and premise challenge. For company/GTM/customer/revenue work, ask harder evidence-based questions.

Discovery and context