Use AIMake as the project management source of truth for product and growth execution. AIMake vocabulary: - Projects are products or businesses, not single technical components. - Wins are stakeholder-visible deliverables on the board. - Tasks are the ordered work inside a win. - Proof is the evidence that work actually landed: PRs, docs, screenshots, demos, builds, logs, metrics, alarms, runbooks, dashboards, or links. **Operating Rules:** - Check existing wins and docs before creating new work. - Create wins for stakeholder-visible outcomes, not raw tickets. - Break wins into ordered design and engineering tasks. - Design tasks define interaction contracts: flows, states, edge cases, copy obligations, tradeoffs, accepted behavior, deferred scope, and acceptance criteria. - Engineering tasks implement, test, migrate, integrate, or verify the accepted behavior. - Put proof requirements on tasks before implementation starts. - Attach proof as work lands: PRs, tests, screenshots, logs, docs, metrics, alarms, runbooks, dashboards, or demo links. - For engineering tasks that affect production behavior, include outcome-based observability proof: the expected outcome, the metric/log/health check proving it, and the alarm/threshold that alerts when it is not happening. - Move a win to done only when the expected proof exists or is explicitly waived. - Do not invent project facts. If docs are missing, state the assumption and capture the open question. - If you cannot connect directly to AIMake, ask the user for the relevant project, win, docs, and current board state before changing code. - After work lands, summarize exactly what should be updated in AIMake: task status, proof links, docs, screenshots, tests, metrics, and follow-up wins. **Task Shape:** ``` [Design] Task title -- One sentence defining the accepted behavior or decision. Proof: acceptance criteria, user flow, copy review, or deferred-scope record. [Engineering] Task title -- One sentence describing implementation or verification work. Proof: PR link, tests, screenshots, logs, metrics, alarms, dashboard/runbook updates, demo path, migration output, or docs. ``` **Example Workflow:** 1. Read the current AIMake win and project docs. 2. Confirm the stakeholder-visible outcome and proof requirements. 3. Implement the smallest coherent change. 4. Run the relevant checks. 5. Report proof links and the AIMake task updates that should be made. 6. Call out missing context or follow-up wins instead of silently inventing scope.