docs(sdk): Add Linear project description template

develop-docs/sdk/getting-started/playbooks/coordination/managing-linear-projects.mdx

@@ -104,10 +104,72 @@ You **MUST** set all of the following attributes before sharing the project with
 - **Status**: set to the appropriate state (`Planned`, `In Progress`, etc.)
 - **Target date**: realistic delivery date; **MUST** be set before the project moves to **In Progress**
 - **Team**: the owning SDK team
-- **Description**: scope, goals, and non-goals; detailed enough that a new team member can orient themselves without asking
+- **Summary**: one sentence describing what this project ships and why it matters (separate field in Linear, just below the title)
+- **Description**: use the structured template below; it should be detailed enough that a new team member can orient themselves without asking
+
+You should also set:
+
+- **Customers**: link relevant customer accounts or support tickets that motivated the work
+- **Resources**: add relevant references (especially for larger initiatives) — design documents ([RFC](https://github.com/getsentry/rfcs), DACI, PRFAQ), Slack channels, related projects, and so on
+- **Milestones**: define intermediate delivery milestones for longer projects to track progress incrementally
 
 A project without a lead, initiative, or target date **MUST NOT** be moved to **In Progress**.
 
+##### Project Description Template
+
+Use this template as a starting point for the project description. For cross-SDK rollout projects where the initiative already covers the shared context (motivation, scope, outcomes), the per-SDK project description can reference the initiative and only document SDK-specific deviations (e.g., different scope, additional risks, platform-specific dependencies).
+
+```markdown
+## Why are we doing this?
+<!-- 1–3 sentences on motivation — what we know so far and why we're kicking this off -->
+
+## User-facing changes
+<!-- What will developers/users be able to do differently after this ships? -->
+
+## Expected outcomes
+<!-- Be specific: "Reduce P0 support tickets for X", "Unblock platform Y adoption", "Increase metric Z" -->
+
+## In scope
+<!-- What will this project deliver? List the specific features, changes, or outcomes that are included -->
+
+## Out of scope
+<!-- Explicitly parking things here prevents scope creep and sets expectations -->
+
+## Dependencies
+<!-- Who or what must move before or alongside this? Flag blockers early -->
+
+## Risks
+<!-- What's most likely to go wrong? What's the mitigation? -->
+
+## Definition of Done
+
+### Project-specific criteria
+<!-- What must be true for this specific project to be done? -->
+- [ ]
+
+### Have we updated
+<!-- Delete items that don't apply -->
+- [ ] [Public docs](https://docs.sentry.io/)
+- [ ] [Develop Docs](https://develop.sentry.dev)
+- [ ] [Sentry Conventions](https://getsentry.github.io/sentry-conventions/)
+- [ ] [Sentry CLI](https://github.com/getsentry/cli)
+- [ ] [sentry-wizard](https://github.com/getsentry/sentry-wizard)
+- [ ] Public SDK example projects
+- [ ] In-product prompts/onboarding
+- [ ] Internal adoption/usage dashboards
+
+### Have you thought about doing a
+- [ ] [Sentry Product Blog](https://blog.sentry.io/) post
+- [ ] [Sentry Changelog](https://sentry.io/changelog/) entry
+- [ ] [Sentry Engineering Blog](https://sentry.engineering/blog) post
+- [ ] [internal blog post](https://vanguard.getsentry.net/)
+- [ ] S&T video
+
+### Don't forget to create a follow-up issue to
+- [ ] Check how the feature is performing after launch
+- [ ] Promote the feature to GA
+```
+
 #### 2. Add Pre-Implementation Documentation
 
 Before implementation begins, you **MUST** complete all pre-implementation documentation required by the [Design-First Gate](/sdk/getting-started/standards/planning-scoping#design-first-gate) and [Risk Identification](/sdk/getting-started/standards/planning-scoping#risk-identification) standards.
@@ -178,6 +240,8 @@ Run these steps in order when all implementation and documentation is shipped.
 
 Verify closure against the [Definition of Done](/sdk/getting-started/standards/planning-scoping#definition-of-done) standard before setting the project to **Done**.
 
+#### Close-Out Steps
+
 1. Verify all issues in the project are either **Done** or explicitly **Cancelled** with a note.
 2. Post a final update summarizing: what shipped, any known follow-up work, and lessons learned.
 3. Set the project status to **Done**. A project **MUST NOT** be set to **Done** if there are open issues that are not yet resolved or intentionally cancelled.

develop-docs/sdk/getting-started/standards/planning-scoping.mdx

@@ -71,6 +71,8 @@ Issues estimated larger than **M** (or the team's medium equivalent) **MUST NOT*
 
 An issue or project **MUST NOT** be marked done if any of these conditions are unmet. "Mostly done" or "good enough" are not acceptable states — defer remaining work to a follow-up issue or project instead.
 
+For a project description template including an artifact and communication checklist for the Definition of Done, see [Project Description Template](/sdk/getting-started/playbooks/coordination/managing-linear-projects#project-description-template).
+
 #### Enforcement
 
 - Human review