ceo-orchestration 1.0.0

package/.claude/skills/domains/devrel/pitfalls.yaml

@@ -0,0 +1,74 @@
+# Pitfalls Catalog — DevRel Squad
+# Loaded alongside the universal catalog when the devrel profile is
+# installed. Format mirrors .claude/pitfalls-catalog.yaml:
+# id, rule, whenToUse, agents.
+#
+# ADR-009 §bundle-completeness: ≥10 pitfall entries required.
+# Each id follows DEV-NNN (3-digit zero-padded, monotonic).
+# Exemplars: .claude/skills/domains/edtech/pitfalls.yaml
+#            .claude/skills/domains/trading-hft/pitfalls.yaml
+
+pitfalls:
+  # === DOCUMENTATION ACCURACY + API CONTRACT ===
+  - id: DEV-001
+    rule: "Documentation MUST NOT be published ahead of the corresponding code being shipped. Documenting a parameter, endpoint, or behavior that does not yet exist generates support tickets and erodes developer trust. If code ships after docs, redirect developers to a 'coming soon' page with an ETA."
+    whenToUse: "any documentation update tied to a feature not yet deployed to production; any API reference update"
+    agents: [Sola Adewale]
+
+  - id: DEV-002
+    rule: "Every breaking change MUST have a changelog entry that names the specific change (endpoint removed, parameter renamed, response schema modified) and links to the migration guide. 'Various improvements' or 'bug fixes' changelog entries are forbidden for any change that could break existing integrations."
+    whenToUse: "any API change, SDK release, or documentation update that alters documented behavior"
+    agents: [Sola Adewale, Remy Dubois, Felix Acharya]
+
+  - id: DEV-003
+    rule: "API reference pages MUST include a 'last verified against version' timestamp and the API version they describe. An undated API reference is untestable by the developer and untraceable by support."
+    whenToUse: "any API reference publication, documentation site rebuild, or version-freeze process"
+    agents: [Sola Adewale]
+
+  - id: DEV-004
+    rule: "Migration guides MUST be published simultaneously with the deprecation notice — never after. A deprecation notice with 'migration guide coming soon' gives developers no actionable path and will generate community backlash."
+    whenToUse: "any deprecation notice, API sunset announcement, or major version release"
+    agents: [Sola Adewale, Remy Dubois]
+
+  # === DEPRECATION + BREAKING-CHANGE COMMUNICATION ===
+  - id: DEV-005
+    rule: "Public API deprecations MUST provide at minimum 6 months advance notice before the sunset date. Any exception (security-driven, legal-driven) requires explicit CEO + Owner sign-off with a documented reason. A 30-day deprecation on a widely-used endpoint is a trust-destroying event."
+    whenToUse: "any public API endpoint, SDK method, or documented behavior being deprecated"
+    agents: [Remy Dubois]
+
+  - id: DEV-006
+    rule: "Sunset dates MUST NOT be announced unless telemetry shows < 5% of tracked active integrations still depend on the deprecated surface. Announcing a sunset date while 40% of active integrations are still on the deprecated surface creates a migration crisis."
+    whenToUse: "any sunset date announcement for a deprecated API or SDK version"
+    agents: [Remy Dubois, Felix Acharya]
+
+  - id: DEV-007
+    rule: "Breaking changes MUST be communicated through at least two channels beyond the changelog: a forum/community post AND a direct notification (email or in-platform) to integrations with recent active usage. Changelog-only communication for breaking changes is insufficient."
+    whenToUse: "any breaking change communication plan for a public API or SDK"
+    agents: [Remy Dubois, Jodie Okonkwo]
+
+  - id: DEV-008
+    rule: "The deprecated version of an API MUST continue serving traffic for the full announced deprecation period even if the new version is available. 'We shipped v2 so v1 can be turned off earlier' is a violation of the published sunset date."
+    whenToUse: "any infrastructure decommission plan for a versioned API endpoint"
+    agents: [Remy Dubois, Felix Acharya]
+
+  # === SDK QUALITY + DEVELOPER EXPERIENCE ===
+  - id: DEV-009
+    rule: "SDK releases that remove a method or parameter MUST include a deprecation warning in the PRIOR version before removal. Remove-without-warning is a breaking change regardless of semantic version number. The deprecation warning must appear at runtime, not just in the changelog."
+    whenToUse: "any SDK release that removes, renames, or changes the signature of a public method"
+    agents: [Felix Acharya, Priscilla Tan]
+
+  - id: DEV-010
+    rule: "API error responses MUST include ALL THREE: a machine-readable error code (e.g. 'RATE_LIMIT_EXCEEDED'), a human-readable message ('You have exceeded 100 requests per minute for this endpoint'), and a link to the relevant documentation page. An error with only an HTTP status code forces developers to read source code."
+    whenToUse: "any new API endpoint, error-handling code change, or error response schema modification"
+    agents: [Priscilla Tan, Felix Acharya, Sola Adewale]
+
+  - id: DEV-011
+    rule: "SDK retry logic MUST handle 429 (rate limit) responses with exponential backoff and jitter. Retry-after header MUST be respected when present. An SDK that retries immediately on a 429 response will amplify the rate-limit problem, not solve it."
+    whenToUse: "any SDK retry configuration, rate-limit handling code, or backoff strategy change"
+    agents: [Felix Acharya, Priscilla Tan]
+
+  # === COMMUNITY + SECURITY DISCLOSURE ===
+  - id: DEV-012
+    rule: "Security disclosures received in public community channels (Discord, forum, GitHub issues) MUST be immediately routed to the private security disclosure channel and the security team — NEVER acknowledged or discussed publicly before a fix is available. A public discussion of an unpatched vulnerability is a coordinated attack invitation."
+    whenToUse: "any community moderation, forum post triage, or GitHub issue review that involves a potential security vulnerability"
+    agents: [Jodie Okonkwo, Remy Dubois]

package/.claude/skills/domains/devrel/skills/developer-advocate/SKILL.md

@@ -0,0 +1,382 @@
+---
+name: developer-advocate
+description: >
+  Developer relations and advocacy discipline covering technical content
+  production (tutorials, cookbooks, deep-dives, quickstarts, migration guides),
+  documentation engineering with CI runnability gates, sample app authorship
+  grounded in production patterns, conference and meetup proposal craft,
+  community operations across Discord/Slack/GitHub/forums, developer-experience
+  feedback synthesis routed to product, and internal evangelism including
+  new-feature dogfood and release-note authorship. Distinct from
+  `core/technical-writing` (general documentation craft without community
+  mandate) — this skill governs community-facing relationship work where the
+  proof metric is developer success attributed to the product, not content
+  volume or event attendance. Use when: authoring or reviewing a tutorial,
+  cookbook, or quickstart; evaluating a conference talk proposal; designing
+  community response SLAs; synthesizing developer-experience signals for a
+  product team; or structuring a sample application for first-use clarity.
+owner: Renata Fontes (Developer Advocate, domain persona)
+tier: domain:devrel
+scope_tags: [devrel, developer-relations, technical-content, community-ops, sample-apps, conference-speaking]
+inspired_by:
+  - source: msitarzewski/agency-agents/specialized/specialized-developer-advocate.md@783f6a72bfd7f3135700ac273c619d92821b419a
+    license: MIT
+    relationship: structural_inspiration
+    authored_by: ceo-orchestration framework
+    authored_at: 2026-05-07
+# --- smart-loading fields (PLAN-083 Wave 0b sub-agent 0.7c) ---
+domain: devrel
+priority: 8
+risk_class: low
+stack: []
+context_budget_tokens: 500
+inactive_but_retained: true
+repo_profile_binding:
+  frontend: {active: false, priority: 10}
+  engine: {active: false, priority: 10}
+  fintech: {active: false, priority: 10}
+  trading-readonly: {active: false, priority: 10}
+  generic: {active: false, priority: 10}
+activation_triggers: []
+# --- K1 paths: native file-touch activation (PLAN-135 W3 unit k1a) ---
+paths:
+  - "**/tutorials/**"
+  - "**/cookbooks/**"
+  - "**/quickstarts/**"
+  - "**/samples/**"
+  - "**/examples/**"
+---
+
+# Developer Advocate
+
+## Cardinal Rule
+
+DevRel measured purely in marketing metrics is dressed-up content marketing;
+the only proof is developer-success-attributed-to-the-product.
+
+Page views, follower counts, event attendance, and tutorial publish rates are
+lagging vanity signals. The load-bearing metric is whether developers reached
+a successful outcome — first API call, first deployed sample, first production
+integration — and whether that outcome is traceable to a DevRel artifact or
+interaction. Every content piece, sample app, and community response must be
+evaluated against this criterion. A tutorial with 90% completion rate and a
+clear "time-to-first-success" reduction is a DevRel success. A talk with 400
+attendees that does not change how a single developer uses the platform is
+not.
+
+---
+
+## Fail-Fast Rule
+
+A DevRel work unit MUST NOT start without three confirmed inputs: an audience
+segment definition, a success criterion stated as a measurable developer
+outcome, and a confirmation that any code in the deliverable runs without
+modification on current GA tooling. The following conditions MUST hold before
+content or community output ships:
+
+1. The audience segment is named and distinguished (see Developer-Audience
+   Segmentation below) — content authored for "all developers" is authored
+   for no developer.
+2. The success criterion is stated as a measurable developer outcome: "developer
+   completes first API call in ≤ 15 minutes," not "tutorial is published."
+3. All code in the deliverable has been executed in a clean environment on the
+   current GA release. Untested code in a tutorial, sample app, or GitHub issue
+   response is a credibility liability that compounds across every developer
+   who encounters it.
+
+If any condition is unresolved, the work unit is blocked until it is closed.
+
+---
+
+## When to Apply
+
+Activate this skill when the work involves any of the following:
+
+- Authoring or reviewing a tutorial, cookbook, quickstart, deep-dive, or
+  migration guide.
+- Designing a sample application intended for community distribution.
+- Crafting or reviewing a conference or meetup talk proposal.
+- Establishing or auditing community response SLAs across Discord, Slack,
+  GitHub issues, Stack Overflow, or forum platforms.
+- Synthesizing developer-experience signals — support transcripts, GitHub issue
+  patterns, conference Q&A recurrences — into a product team briefing.
+- Authoring internal evangelism artifacts: release notes, dogfood guides,
+  engineering-team alignment decks for new platform features.
+- Running a DX audit for time-to-first-success reduction.
+
+Skip when: the task is general documentation craft without a community
+mandate — route to `core/technical-writing`; the task is brand messaging or
+campaign copy — route to `domains/marketing-global/skills/content-creator`;
+the task is platform architecture decision — route to
+`core/architecture-decisions`.
+
+---
+
+## Developer-Audience Segmentation
+
+Content, sample apps, and community responses must be calibrated to the
+audience segment. One-size-fits-all DevRel content satisfies no segment fully.
+
+| Segment | Definition | Content calibration |
+|---|---|---|
+| Decision-maker | Engineering lead or architect evaluating the platform for adoption; cares about integration cost, security posture, reliability, and migration risk | Architecture deep-dives; security posture docs; migration guides with real codebase context; case studies with measurable outcomes |
+| Champion | Internal advocate inside a prospective or existing customer org; needs to justify adoption upward; translates technical signals into business language | Comparison guides; TCO analyses; adoption playbooks; internal pitch templates |
+| Power-user | Experienced developer already using the platform; seeks advanced patterns, edge-case handling, and direct access to product roadmap signals | Advanced cookbooks; RFC-style design decision docs; beta program access; direct community engagement with product team |
+| Prospect | Developer in first contact with the platform; needs to form a fast, accurate mental model of what the product does and whether it is worth investing time | Quickstarts; "what is X" explainers; time-to-first-success flow; clear success-state definition before any code |
+| Drive-by | Developer who arrived from a search result or link share; unfamiliar with the platform; may not complete the content | Hook in the first paragraph; self-contained runnable example; no assumed prior context; clear next-step signpost at the end |
+
+---
+
+## Technical Content Production
+
+Each content type serves a distinct developer need. Format selection is driven
+by the developer's current state and the outcome the content is meant to
+produce — not by content calendar convenience.
+
+| Content type | Developer state at entry | Outcome at exit | Structural requirement |
+|---|---|---|---|
+| Quickstart | No prior exposure to the platform; needs to reach first working output fast | Running output in ≤ 15 minutes | Linear; no branches; single success path; tested on clean environment |
+| Tutorial | Aware of the product; needs to build a complete, realistic thing | Completed artifact; understanding of the design decisions made along the way | Narrative arc: problem → approach rationale → step-by-step → what was built + what is next |
+| Cookbook | Proficient user; needs a solution to a specific sub-problem | Copy-pasteable, tested code snippet with context for when and why to use it | Problem-first structure; minimal scaffolding; named prerequisites; failure-mode note |
+| Deep-dive | Power-user; needs to understand the internals or design tradeoffs | Accurate mental model of the subsystem; confidence to make architectural decisions | Explicit scope: what this explains and what it does not; diagrams for complex state flows |
+| Migration guide | Developer on a prior version or competitor product; needs to move to the platform without breaking production | Completed migration with zero regressions | Prerequisite state explicit; before/after code for every changed pattern; rollback instructions |
+
+**Runnable code is mandatory.** Code that cannot be copied from the document
+and executed without modification is wrong by definition, regardless of whether
+it is pedagogically correct. Every code block must be tested on the current GA
+release before publication. Tested-on version and toolchain must be stated in
+the prerequisites section.
+
+**Copy-paste-friendly format discipline:** Code blocks are complete, not
+illustrative. Comments explain the non-obvious — not the syntax. Environment
+variables are explicit. Expected output is shown where it disambiguates
+ambiguous success states.
+
+---
+
+## Documentation Engineering
+
+Documentation is a product surface with its own quality gates and maintenance
+lifecycle. DevRel owns the community-facing documentation — tutorials, sample
+READMEs, API usage examples — and is responsible for keeping that surface
+accurate through breaking-change cycles.
+
+**Docs-as-code:** Documentation source lives in version control alongside the
+product code. PRs that introduce a breaking change MUST include a documentation
+update in the same changeset. The DevRel gate on a breaking-change PR is not
+optional review — it is a required approval from the documentation owner.
+
+**CI runnability gates:** All code examples in documentation must be covered
+by a CI job that executes them against the current GA release. A passing CI
+run is a prerequisite for publishing. A CI failure on an existing example is
+a P1 bug — not a documentation improvement ticket.
+
+**Navigation hierarchy:** Entry-point documentation follows a consistent
+information architecture: concept → quickstart → tutorials → reference →
+cookbook → migration guides. Developers should be able to locate any content
+type from the top-level documentation index in two clicks or fewer.
+
+**Search-aware structure:** Section titles, H2 and H3 headings, and the first
+sentence of each section must reflect the vocabulary developers use when
+searching, not the vocabulary the product team uses internally. Conduct a
+quarterly search query analysis against the documentation search log; revise
+headings that receive zero-click results.
+
+---
+
+## Sample App Discipline
+
+Sample applications are the highest-trust content artifact in a DevRel
+portfolio. A broken or misleading sample app damages developer confidence
+more than no sample app. The following constraints are non-negotiable:
+
+**Real production patterns, not toy demos.** A sample app that uses
+`localhost:3000` with no auth, no error handling, and hard-coded secrets is
+not a sample app — it is a liability. Every sample app must demonstrate the
+security baseline appropriate for its deployment target: credential management
+via environment variables, error handling that does not expose internal state,
+and a dependency tree that does not include known-vulnerable packages.
+
+**Deployable in under 15 minutes.** The README must contain a tested deployment
+path that takes a developer from a clean environment to a running application
+in under 15 minutes. Every step that requires external account creation must
+state the required tier and any associated cost. Every step that differs by
+operating system must document the difference.
+
+**Updated with breaking changes.** Every sample app must have a named owner
+in the DevRel team responsible for updating it when the upstream platform
+introduces a breaking change. A sample app without a named owner and a
+CI-verified runnability gate is deprecated by default — it must be archived
+or transferred before it accumulates inbound links from tutorials.
+
+**Security baseline for sample apps:**
+
+| Concern | Requirement |
+|---|---|
+| Credential management | All secrets via environment variables; no hard-coded API keys in any committed file; `.env.example` committed, `.env` gitignored |
+| Dependency pinning | Lock files committed; dependencies updated on a documented cadence; no packages with known HIGH CVEs at publication time |
+| Error handling | All API errors caught and logged; responses never expose raw stack traces to end-users |
+| Input validation | Any user-supplied input validated before passing to platform APIs |
+
+---
+
+## Conference and Meetup Speaking
+
+Conference talks are a direct developer-trust channel. A talk that delivers
+on its stated outcome builds the DevRel team's credibility with the speaker's
+entire conference cohort. A talk that is a feature dump wrapped in a narrative
+frame wastes that trust.
+
+**Proposal craft.** The abstract must open with the developer's pain or the
+compelling question — not with "In this talk I will." The detailed description
+for reviewers must include: the problem statement supported by evidence
+(GitHub issue counts, Stack Overflow question frequency, community survey
+data), the proposed solution demonstrated via a live example, three specific
+takeaways developers can apply immediately, and the speaker's relevant
+experience stated as what they built, not their job title.
+
+**Story arc over feature dump.** Every conference talk is a narrative: problem
+state → insight that reframes the problem → solution demonstrated → takeaways
+the developer can apply. A talk structured as a feature enumeration does not
+give developers a memorable mental model. The narrative arc does.
+
+**Live demo discipline.** Every live demo requires: a fallback video recording
+in case of network failure, tested execution on venue network topology (or an
+isolated hotspot), and a rehearsed acknowledgment for failure scenarios. A
+demo that fails with no fallback damages the talk's credibility more than no
+demo.
+
+**Q&A as a feedback channel.** Questions asked during Q&A at a conference are
+signal, not noise. Every Q&A session generates a written log of questions
+asked, cataloged by theme. Five developers asking the same question at a
+conference means thousands encountered the same confusion and did not ask.
+That log feeds the feedback loop (see Feedback Loop below).
+
+---
+
+## Community Operations
+
+Community platforms — Discord, Slack, GitHub issues, Stack Overflow, forums —
+are the highest-volume developer touchpoint. Response quality and response
+time in these channels determines whether a developer forms a positive or
+negative relationship with the platform team, independent of product quality.
+
+**Response SLA:**
+
+| Platform | First acknowledgment | Full resolution target | Notes |
+|---|---|---|---|
+| GitHub issues (bug reports with repro) | 24 hours (business days) | Next minor release or documented workaround within 72 hours | Acknowledge receipt; confirm reproduction; state root cause or next step |
+| GitHub issues (feature requests) | 48 hours (business days) | Backlog entry with honest priority assessment within 1 week | No uncommitted roadmap promises; link to related issues |
+| Discord / Slack (community help) | 4 hours (business hours) | Same-thread resolution or escalation handoff within 24 hours | Tag the question with a platform label for weekly synthesis |
+| Stack Overflow | 48 hours | Accepted answer or pointer to documentation | Search for existing question before answering to avoid duplicate threads |
+| Forum (threaded) | 72 hours | Resolution or documented escalation path | Index high-value resolutions in documentation quarterly |
+
+**Moderation and toxicity escalation.** Every community platform requires a
+published code of conduct, a documented escalation path for violations, and a
+named moderator. Toxicity left unaddressed drives away the power-users who
+generate the highest-value knowledge contributions.
+
+---
+
+## Feedback Loop
+
+The developer-experience feedback loop is the mechanism by which developer
+signals in community and support channels reach the product team in a form
+actionable enough to change the backlog. Without a closed feedback loop,
+DevRel operates as a one-way broadcast channel.
+
+**Weekly synthesis cadence.** Every week, the Developer Advocate produces a
+"Voice of the Developer" synthesis: the top five developer pain points by
+evidence volume (GitHub issue count + Stack Overflow question frequency +
+conference Q&A recurrence + support ticket correlation), with a proposed
+action for each. This synthesis is delivered to the product team lead and
+the engineering team lead, not to a shared Slack channel that may or may not
+be read.
+
+**Evidence-based escalation.** A pain point enters the synthesis when it is
+supported by evidence from at least two independent channels. Anecdote from
+a single conference conversation is context, not evidence. "Seventeen GitHub
+issues, four Stack Overflow questions, and two conference Q&As all point to
+the same missing feature" is evidence.
+
+**Attribution at resolution.** When a DX fix ships, the community thread or
+issue that generated the signal must receive a public acknowledgment. Invisible
+fixes do not build trust.
+
+**Product-team boundary.** No roadmap commitment, release date, or
+feature-inclusion statement is made to the community without explicit written
+confirmation from the product owner. Unconfirmed commitments are promises the
+product team did not make — and DevRel bears the credibility cost.
+
+---
+
+## Internal Evangelism
+
+Developer Advocate scope extends inward as well as outward. New platform
+features that the engineering team does not understand, use incorrectly, or
+fail to dogfood before GA are features that will generate community pain at
+launch.
+
+**New-feature dogfood.** For every significant platform feature entering GA,
+the Developer Advocate runs an internal dogfood: builds a sample app or
+integration using the feature from the developer's perspective, against the
+published documentation, without access to the internal implementation team.
+Every friction point encountered is filed as a documentation or DX bug before
+the launch date.
+
+**Release-note authorship.** Release notes are a developer-trust document, not
+an internal changelog. The Developer Advocate authors the public-facing release
+notes with the following structure: impact statement (what changed and why it
+matters to developers), migration note (if breaking), code example (if the
+feature is behavioral), and a link to the full documentation. Release notes
+that lead with implementation detail rather than developer impact are rewritten
+before publication.
+
+**Engineering-team alignment.** When a new feature has DevRel implications,
+the Developer Advocate is included in the feature kickoff, not the launch
+announcement. Post-launch inclusion eliminates the dogfood and DX-review gate.
+
+---
+
+## Anti-Patterns
+
+| Anti-pattern | Description | Correction |
+|---|---|---|
+| Vanity-metrics DevRel | Reporting success as page views, follower counts, or event attendance without a corresponding developer-success metric | Define time-to-first-success, tutorial completion rate, and community DX-fix attribution as primary KPIs; report vanity metrics only as corroborating context |
+| Marketing disguised as DevRel | Publishing content whose primary objective is lead generation or brand impression, framed as developer education | Apply the audience-segment filter: if the content serves the company's marketing funnel more than the developer's outcome, route to marketing; DevRel content must deliver genuine developer value first |
+| Broken sample apps | Shipping or maintaining sample apps with untested code, hard-coded credentials, or outdated dependencies | Require CI runnability gate for every sample app; treat a failing runnability gate as a P1 bug; archive sample apps without a named owner |
+| Ignored community feedback | Collecting developer pain-point signals from GitHub, Stack Overflow, and conference Q&As without routing them to the product team in a structured, recurring cadence | Implement the weekly synthesis cadence; measure whether synthesis items appear in the product backlog within 30 days |
+| Conference-content recycling | Submitting the same talk proposal to multiple conferences without updating the evidence base, demo content, or takeaways to reflect the platform's current state | Treat each conference submission as a new proposal; update the evidence base from the most recent community signals; retire talks that are more than two major versions stale |
+| Uncommitted roadmap promises | Telling community members that a feature "is coming" or "is on the roadmap" without written confirmation from the product owner | Establish and enforce the product-team boundary: no roadmap communication to the community without written confirmation; use "we've logged this as a request" when the status is genuinely unknown |
+
+---
+
+## Cross-References
+
+- `core/technical-writing` — general documentation craft, style guides,
+  information architecture, and writing standards for internal and
+  non-community-facing content. Route when the documentation task does not
+  have a community mandate or a developer-success measurement requirement.
+- `core/architecture-decisions` — ADR authorship and governance for
+  platform-level design decisions. Route when the content task is a design
+  decision document rather than developer-facing education.
+- `domains/marketing-global/skills/content-creator` — organic content
+  authorship, narrative architecture, and distribution strategy for brand and
+  demand-generation content. Route when the content objective is brand or
+  lead generation rather than developer success.
+
+---
+
+## ADR Anchors
+
+- **ADR-058** (Brainstorm gate pre-Plan + two-pass adversarial review): the
+  brainstorm gate maps directly to the Fail-Fast Rule for DevRel work units.
+  Before any tutorial, sample app, or community campaign enters production,
+  the audience segment must be named and the success criterion must be stated
+  as a measurable developer outcome — the DevRel equivalent of ADR-058's
+  spec artifact requirement. The two-pass adversarial review pattern applies
+  to content review: the first pass confirms that code runs and prerequisites
+  are accurate; the second pass applies the target audience segment's
+  perspective (is the content calibrated to the named segment's awareness
+  level and outcome need, or does it assume knowledge the segment does not
+  have?).

package/.claude/skills/domains/devrel/task-chains.yaml

@@ -0,0 +1,129 @@
+# Task chains — DevRel Squad
+# Domain-specific workflows that extend the universal .claude/task-chains.yaml.
+#
+# ADR-009 §bundle-completeness: ≥2 task chain entries required.
+# Each chain id follows devrel-<short-slug> (kebab-case).
+# NOT canonical-guarded — no sentinel required for edits.
+
+task_chains:
+  - id: devrel-api-deprecation-comms
+    title: "Deprecate a public API endpoint — communication and sunset workflow"
+    whenToUse: |
+      Triggered when a public API endpoint, SDK method, or documented behavior
+      is being deprecated. Covers: impact assessment, advance notice period
+      verification (≥6 months), migration guide publication, community
+      announcement, telemetry-gated sunset date, and decommission sign-off.
+      Out of scope: internal-only APIs (use standard engineering decommission),
+      security-driven emergency deprecations (shorter notice period requires
+      CEO+Owner sign-off documented separately before this chain runs).
+    steps:
+      - id: 1
+        owner: "Felix Acharya (SDK / API Reliability Engineer)"
+        action: "Impact telemetry: pull usage data for the deprecated surface (requests per day, unique integration count, language/SDK breakdown). This data gates the sunset date announcement (DEV-006)."
+      - id: 2
+        owner: "Remy Dubois (Developer Advocate)"
+        action: "Advance notice verification: confirm the proposed sunset date is at minimum 6 months from today's deprecation notice date. If < 6 months, escalate to CEO + Owner for documented exception (DEV-005)."
+      - id: 3
+        owner: "Sola Adewale (Technical Writer)"
+        action: "Migration guide authorship: write the full migration guide (old endpoint → new endpoint, parameter mapping, response schema differences, code samples in all supported SDK languages). Migration guide MUST be published simultaneously with the deprecation notice (DEV-004)."
+      - id: 4
+        owner: "Felix Acharya"
+        action: "SDK deprecation warnings: inject in-code runtime deprecation warnings into all official SDKs for any methods that wrap the deprecated endpoint. Bump the SDK to a new minor version with the warning (DEV-009)."
+      - id: 5
+        owner: "Sola Adewale"
+        action: "Documentation update: mark the endpoint as deprecated in the API reference (with the sunset date and migration guide link). Update changelog with a specific entry naming the deprecated endpoint and linking to migration guide (DEV-002, DEV-003)."
+      - id: 6
+        owner: "Remy Dubois"
+        action: "Community announcement: post deprecation notice on forum + send direct notification to integrations with active usage in the past 30 days. Announcement must include: sunset date, migration guide link, and office-hours availability (DEV-007)."
+      - id: 7
+        owner: "Jodie Okonkwo (Community Manager)"
+        action: "Community monitoring: pin the deprecation announcement thread. Set up keyword alerts for the deprecated endpoint name. First-response SLA on migration questions is 4 hours during the first week post-announcement."
+      - id: 8
+        owner: "Staff Code Reviewer"
+        action: "Merge check: migration guide published, SDK deprecation warnings in all official SDKs, changelog entry names the specific endpoint, sunset date ≥ 6 months from notice, community announcement posted."
+    verification: |
+      - Sunset date is ≥ 6 months from deprecation notice date (DEV-005)
+      - Migration guide published simultaneously with notice (DEV-004)
+      - In-code deprecation warnings shipped in all official SDKs (DEV-009)
+      - Changelog entry names the specific deprecated endpoint with migration link (DEV-002)
+      - Community announcement posted via ≥ 2 channels + direct notification (DEV-007)
+      - Deprecated endpoint continues serving traffic until sunset date (DEV-008)
+
+  - id: devrel-sdk-release
+    title: "SDK major or breaking version release"
+    whenToUse: |
+      Any SDK release that increments the major version (breaking changes) or
+      that removes, renames, or changes the signature of a public method.
+      Minor releases without breaking changes use the lightweight SDK patch
+      workflow. This chain covers: DX quality gate, documentation sync,
+      breaking change communication, community notification, and release
+      sign-off. Out of scope: patch releases with no breaking changes
+      (use standard CI/CD release pipeline).
+    steps:
+      - id: 1
+        owner: "Priscilla Tan (DX Engineer)"
+        action: "DX quality gate: run the onboarding test harness (time to first successful API call benchmark). Verify auth flow is ≤ 3 steps for the happy path. Verify all removed methods had in-code deprecation warnings in the prior version (DEV-009)."
+      - id: 2
+        owner: "Felix Acharya (SDK / API Reliability Engineer)"
+        action: "Version bump audit: confirm the semantic version bump matches the change severity (breaking change = major bump). Confirm in-code deprecation warnings for methods removed in this version were present in the prior minor release (DEV-009)."
+      - id: 3
+        owner: "Sola Adewale (Technical Writer)"
+        action: "Documentation sync: verify every new method, removed method, and changed signature is reflected accurately in the API reference and SDK reference before release (DEV-001). Confirm changelog entry is specific and complete (DEV-002)."
+      - id: 4
+        owner: "Priscilla Tan"
+        action: "Error response audit: verify all new API error paths have machine-readable error code + human-readable message + documentation link (DEV-010). Verify retry logic handles 429 with exponential backoff + jitter (DEV-011)."
+      - id: 5
+        owner: "Remy Dubois (Developer Advocate)"
+        action: "Breaking change communication plan: prepare forum post + direct notification to active integrations. If any methods were removed, confirm the deprecation warning has been in place for ≥ 1 major version cycle (DEV-007)."
+      - id: 6
+        owner: "Principal QA Architect"
+        action: "Integration tests: run the full SDK test harness against the live API in the staging environment. Verify auth flow completes end-to-end. Verify 429 handling triggers backoff, not immediate retry. Verify version compatibility matrix is updated."
+      - id: 7
+        owner: "Staff Code Reviewer"
+        action: "Merge VETO check: DX quality gate passed, semantic version bump correct, docs in sync before release, error responses complete, community announcement ready to post."
+    verification: |
+      - DX onboarding benchmark at or better than baseline (time to first call) (DEV-001)
+      - Semantic version bump matches change severity; breaking = major (DEV-009)
+      - API reference + changelog updated and accurate before release (DEV-002, DEV-003)
+      - All new error paths include machine-readable code + message + docs link (DEV-010)
+      - 429 retry handling uses exponential backoff with jitter (DEV-011)
+      - Community announcement ready; direct notifications to affected integrations (DEV-007)
+
+  - id: devrel-new-api-launch
+    title: "Launch a new public API or developer feature"
+    whenToUse: |
+      Any new API endpoint, SDK feature, or developer-facing capability being
+      launched to production for the first time. Covers: documentation
+      completeness gate, DX quality review, beta feedback incorporation,
+      and launch announcement. Also covers re-launching a previously
+      experimental or preview feature to GA. Out of scope: internal-only
+      APIs; breaking changes to existing endpoints (use devrel-api-deprecation-comms).
+    steps:
+      - id: 1
+        owner: "Sola Adewale (Technical Writer)"
+        action: "Documentation completeness: confirm API reference, quickstart guide, and at least one conceptual tutorial are written and accurate against the production implementation. No launch without docs (DEV-001)."
+      - id: 2
+        owner: "Priscilla Tan (DX Engineer)"
+        action: "DX quality gate: run onboarding test harness. Time to first successful API call measured against baseline. Verify auth flow is ≤ 3 steps. Verify all error responses include machine-readable code + message + docs link (DEV-010)."
+      - id: 3
+        owner: "Felix Acharya (SDK / API Reliability Engineer)"
+        action: "SDK coverage: confirm official SDKs (Python, Node.js, Go, Ruby — or whichever are officially supported) have been updated to include the new endpoint/feature. Verify version bump is in the patch or minor range (no breaking change for a new feature)."
+      - id: 4
+        owner: "Remy Dubois (Developer Advocate)"
+        action: "Beta feedback review: if a preview/beta period ran, review all filed issues and feedback. Confirm breaking feedback items are resolved or documented as known limitations before GA launch."
+      - id: 5
+        owner: "Jodie Okonkwo (Community Manager)"
+        action: "Launch announcement: draft forum post + community notification. Coordinate timing with marketing-global if a broader launch campaign is planned. Ensure support team is briefed before announcement goes live."
+      - id: 6
+        owner: "Principal QA Architect"
+        action: "Integration tests: verify the new endpoint is covered in the SDK integration test harness. Verify the quickstart completes end-to-end without requiring external context."
+      - id: 7
+        owner: "Staff Code Reviewer"
+        action: "Merge VETO check: docs complete and accurate, DX quality gate passed, SDK coverage confirmed, beta feedback addressed, community announcement ready."
+    verification: |
+      - API reference + quickstart published before launch; accurate against production (DEV-001)
+      - DX onboarding benchmark met (DEV-001)
+      - All error responses include machine-readable code + message + docs link (DEV-010)
+      - SDK coverage confirmed in all officially supported languages
+      - Beta feedback issues resolved or documented as known limitations
+      - Community announcement coordinated and support team briefed