haiku-method 2.2.0

package/studios/libdev/stages/inception/phases/ELABORATION.md

@@ -0,0 +1,45 @@
+# Library Inception Stage — Elaboration
+
+Library inception is a **research / distillation** stage. Its units are knowledge topics covering both **discovery** (problem, target consumers, competitive landscape) and **API shape** (public surface, semver policy, extension points, error model). Unlike application development, the library API *is* the product, so the API shape is part of the inception knowledge set.
+
+## What a unit IS in this stage
+
+One investigable knowledge topic. Examples:
+- "Target consumer profile and primary use case"
+- "Competitive library landscape with API styles, install size, license, and ecosystem fit"
+- "Public API surface — exported types, function signatures, error variants"
+- "Semver policy and extension-point design"
+- "Error model: error variants, recovery paths, recoverability classification"
+- "Cross-runtime / cross-platform support matrix and constraints"
+
+What a unit is **NOT** in this stage:
+- ❌ Implementation source code (those belong in `development`)
+- ❌ Detailed test plans or test code (those belong in `development`)
+- ❌ Release operational runbooks (those belong in `release`)
+
+## What "completion criteria" means here
+
+Knowledge-artifact criteria are about **substance and accountability**, plus — for API-shape units — concrete signature-level decisions.
+
+### Good criteria — substantive and checkable
+
+- "Public API surface §3 names every exported function/type with full signature and a one-paragraph rationale per name"
+- "Semver policy §4 specifies what counts as major/minor/patch with concrete examples for the API surface in §3"
+- "Error model §5 enumerates ≥3 distinct error variants with recovery path or `(unrecoverable; document)` annotation"
+- "Competitive landscape §2 names ≥3 alternatives with API style, ecosystem position, and the gap this library addresses"
+- "Open questions section: each entry has a proposed default for veto-style approval OR `(needs human escalation)`"
+
+### Bad criteria — vague or wrong-stage language
+
+- ❌ "API is good" (no check; "good" by what measure?)
+- ❌ "Test coverage is at least 80%" (build-stage language; no implementation exists yet)
+- ❌ "Each unit has 3-5 verify-commands" (build-stage language)
+- ❌ "Library is performant" (no implementation; can't measure)
+
+## Anti-patterns
+
+- **Drafting implementation in inception.** API surfaces are signatures + rationales, not function bodies. Stop at the signature.
+- **Specifying tests during inception.** Tests follow implementation. Inception specifies what behaviors must exist; development authors test specs against those behaviors.
+- **Single-document syndrome.** One giant "library design doc" defeats per-topic units; the API surface, semver policy, and error model should be separate units even if they cross-reference.
+
+> Note on the universal FSM_CONTRACTS_ELABORATE_BLOCK: the orchestrator currently injects build-class rules (`depends_on:` cycles, executable `quality_gates:`, criteria-with-verify-commands) into every elaborate dispatch. Those rules are correct for build-class stages but do not apply to this stage's knowledge-artifact units. Treat the build-class rules as defaults the framework hasn't yet split — author your units to the substance/accountability shape above, not to executable verify-commands. (Architecture §7 known issue tracking the split.)

package/studios/libdev/stages/inception/review-agents/api-stability.md

@@ -0,0 +1,11 @@
+---
+interpretation: lens
+---
+**Mandate:** The agent **MUST** challenge the proposed API surface for long-term stability risk. Public APIs are contracts — this review exists to stop bad contracts before consumers depend on them.
+
+**Check:**
+- The agent **MUST** flag any API that leaks internal implementation types into consumer code (returning internal classes, framework primitives)
+- The agent **MUST** flag any API with parameters or return types that would naturally grow over time and force breaking changes (e.g., positional args instead of options objects)
+- The agent **MUST** flag any API that conflates stable and experimental concerns in the same entry point
+- The agent **MUST** flag any API that depends on caller-side type inference for correctness
+- The agent **MUST** verify that the error model is stable — error types are part of the contract, and ad-hoc errors are breaking changes in disguise

package/studios/libdev/stages/inception/review-agents/completeness.md

@@ -0,0 +1,11 @@
+---
+interpretation: lens
+---
+**Mandate:** The agent **MUST** verify that discovery and API surface documents fully cover what downstream stages need to proceed.
+
+**Check:**
+- The agent **MUST** verify that the discovery document identifies target consumers concretely, not generically
+- The agent **MUST** verify that every exported symbol in the API surface has a full signature
+- The agent **MUST** verify that the error model is complete — no "and more errors TBD"
+- The agent **MUST** verify that the semver policy answers the non-obvious cases (behavior changes, error type changes)
+- The agent **MUST** verify that non-goals are explicit — scope boundaries must be visible

package/studios/libdev/stages/inception/review-agents/feasibility.md

@@ -0,0 +1,10 @@
+---
+interpretation: lens
+---
+**Mandate:** The agent **MUST** challenge whether the proposed library is technically achievable given the target language, runtime, and dependency constraints.
+
+**Check:**
+- The agent **MUST** verify that the proposed API surface is implementable in the target language without exotic runtime features
+- The agent **MUST** verify that dependencies are compatible with the library's intended license and distribution model
+- The agent **MUST** verify that the ecosystem has no existing library that would trivially absorb this one's scope (don't reinvent existing mature libraries)
+- The agent **MUST** surface any consumer integration that would require the consumer to adopt unrelated dependencies

package/studios/libdev/stages/release/STAGE.md

@@ -0,0 +1,23 @@
+---
+name: release
+description: Publish, changelog, documentation, and deprecation policy
+hats: [release-engineer, doc-writer, verifier]
+fix_hats: [release-engineer, feedback-assessor]
+review: auto
+elaboration: autonomous
+inputs:
+  - stage: inception
+    discovery: discovery
+  - stage: inception
+    discovery: api-surface
+  - stage: development
+    output: code
+---
+
+# Release
+
+Publishing to the target registry (npm, PyPI, crates.io, Maven Central, etc.),
+generating changelogs, updating the documentation site, and managing the
+deprecation lifecycle. Libraries don't deploy — they publish. There is no
+on-call, no rollback in the traditional sense; a broken release means a new
+patch version, not a redeployment.

package/studios/libdev/stages/release/hats/doc-writer.md

@@ -0,0 +1,6 @@
+**Focus:** Update the library's public documentation to reflect the release: API reference, migration guides for breaking changes, and consumer guidance surfaced from the security review.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST** update docs before announcing the release, not after
+- The agent **MUST NOT** ship breaking changes without a migration guide
+- The agent **MUST** integrate security guidance into the relevant API sections, not bury it in a security page consumers won't read

package/studios/libdev/stages/release/hats/feedback-assessor.md

@@ -0,0 +1,11 @@
+---
+agent_type: general-purpose
+model: haiku
+---
+**Focus:** Independently verify that a fix addresses the feedback finding as written. You are the terminal hat in this stage's fix-hat sequence — the workflow engine trusts your closure decision.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** edit any file — you are a verifier, not a fixer
+- The agent **MUST NOT** close a finding that isn't actually resolved — that is how drift hides
+- The agent **MUST NOT** reject a finding because "it's not worth fixing" — that is the human's decision, not yours; either close when resolved, leave open when not, or reject when genuinely invalid
+- The agent **MUST NOT** expand the scope beyond the one feedback item you were dispatched against

package/studios/libdev/stages/release/hats/release-engineer.md

@@ -0,0 +1,7 @@
+**Focus:** Publish the library to its target registry with a correct semver version, a complete changelog, and operational release metadata (tags, signed artifacts, provenance). Publishing is one-shot — once a version is out, it's out. Get it right before hitting publish.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** publish if the version number doesn't match the semver impact of changes
+- The agent **MUST NOT** skip the changelog entry — consumers depend on it
+- The agent **MUST NOT** publish if the security review has unresolved high-severity findings without consumer guidance
+- The agent **MUST** tag the git commit matching the published artifact

package/studios/libdev/stages/release/hats/verifier.md

@@ -0,0 +1,26 @@
+**Focus:** Validate the per-unit operational artifact for the release stage of libdev. Units here are release step — operational steps with concrete preconditions, actions, and post-condition checks. Validation rules check that preconditions are stated, the action is unambiguous, the post-condition has a verifiable check, and rollback is named where applicable.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** read or interpret unit frontmatter for any mechanical purpose. workflow engine territory per architecture §1.1.
+- The agent **MUST NOT** validate against frontmatter schema, `depends_on:` resolution, status-field shape, or any other FM-driven check — those are workflow engine responsibilities.
+- The agent **MUST NOT** advance a unit whose body is a placeholder, contains TODO markers, or has empty sections.
+- The agent **MUST NOT** reject for stylistic preferences. Substantive gaps only.
+- The agent **MUST** name a specific failed criterion in any rejection.
+- The agent **MUST NOT** invent rules not in this mandate. Stage scope is the contract.
+
+## What you check (BODY ONLY)
+
+### 1. Preconditions, action, post-condition all stated
+The unit body MUST have three concrete sections: preconditions (what must be true before the action runs), the action itself (one unambiguous procedure), and post-condition checks (how to confirm the action succeeded). Reject if any of the three is missing or vague.
+
+### 2. Verifiable post-condition
+The post-condition section MUST name a check that produces a clear pass/fail signal — a metric to read, a query to run, a screen to inspect with named expected values. "Verify by eye that things look good" is a reject.
+
+### 3. Rollback / recovery named where applicable
+Operational units MUST declare a rollback procedure OR explicitly state "no rollback — forward-fix only" with a rationale. Silent absence of rollback is a reject for any unit whose action is not idempotent.
+
+### 4. Decision-register consistency
+The unit must not propose an operational approach contradicting a recorded Decision (e.g., blue-green deploy when Decision N chose canary). Cite the Decision ID.
+
+### 5. Open questions accounted for
+Every "Open Questions" entry must be answered, defaulted, OR flagged `(needs human escalation)`. Operational open questions left to runtime are how outages happen.

package/studios/libdev/stages/release/outputs/RELEASE-ARTIFACTS.md

@@ -0,0 +1,27 @@
+---
+name: release-artifacts
+location: (registry + git tag)
+scope: repo
+format: artifact
+required: true
+---
+
+# Release Artifacts
+
+The published outputs of a library release: the version tag, the registry publication, the changelog entry, and the updated documentation. This is not a document in the intent directory; it is the state of the outside world after release.
+
+## Content Guide
+
+A release is complete when:
+- **Registry publication** is live and installable by consumers (`npm install foo@X.Y.Z`, `pip install foo==X.Y.Z`, etc.)
+- **Git tag** exists matching the published version and points at the commit that was built
+- **Changelog** in the repo reflects the release with all user-visible changes
+- **Documentation site** reflects the released version (if the project has one)
+- **Migration guide** exists for any breaking change
+
+## Quality Signals
+
+- The published artifact matches the commit at the git tag
+- The version in the registry matches the version in the changelog
+- Consumers can install and run a hello-world example of the new version without further steps
+- The release announcement (if any) links to changelog and migration guide

package/studios/libdev/stages/release/phases/ELABORATION.md

@@ -0,0 +1,46 @@
+# Release Stage — Elaboration
+
+Release is an **operational** stage. Its units are operational steps in the publish-to-registry pipeline — discrete actions with preconditions, an action procedure, and post-condition checks. Libraries publish; they don't deploy. There is no on-call rotation; a broken release is corrected with a new patch version.
+
+## What a unit IS in this stage
+
+One operational step in the publish pipeline. Examples:
+
+- "Version bump and changelog generation — semver decision, CHANGELOG.md entry"
+- "Registry publish — npm/PyPI/crates.io/Maven Central publish action with credentials"
+- "Tag and release notes — git tag, GitHub/GitLab release with assets attached"
+- "Documentation site deploy — docs build, site preview, prod swap"
+- "Deprecation notice — for any removed API, ship the deprecation in the prior minor first"
+- "Post-publish smoke install — new project pulls the published version and runs a hello-world script"
+
+What a unit is **NOT** in this stage:
+
+- ❌ A new feature (that belongs in `development`)
+- ❌ A security audit (that belongs in `security`)
+- ❌ An API surface decision (that belongs back in `inception`)
+
+## What "completion criteria" means here
+
+Operational-step criteria specify **preconditions, action, post-condition check, and rollback** (or explicit "no rollback — patch forward" rationale).
+
+### Good criteria — concrete and verifiable
+
+- "Registry publish post-condition: `npm view <pkg>@<version>` returns the new version within 5 minutes of `npm publish`"
+- "Smoke-install post-condition: a new throwaway project can `npm install <pkg>@<version>` AND import + call the documented hello-world API without errors"
+- "Changelog post-condition: CHANGELOG.md has a `## [<version>] - <YYYY-MM-DD>` heading with at least one entry under Added/Changed/Fixed; CI lints this"
+
+### Bad criteria — vague or wrong-stage
+
+- ❌ "Library is published" (no check against the registry)
+- ❌ "Version is correct" (correct by what rule?)
+- ❌ "API works" — wrong stage; that's a `development` concern
+
+## How verification happens
+
+Release artifacts are validated by the verifier hat (`hats/verifier.md`). The verifier checks **preconditions stated, action unambiguous, post-condition mechanically decidable, deprecation policy honored where applicable** — body-content checks only, no frontmatter interpretation.
+
+## Anti-patterns
+
+- **Skipping the smoke install.** "Published successfully" with no post-publish install test is how you find out later that the package was published with the wrong files / missing entry point / bad shape.
+- **Skipping the deprecation step.** Removing a public API in a major without a deprecation in the prior minor is a contract break. The verifier should reject any release unit that removes API without a recorded deprecation in the prior version.
+- **Treating registry publish as atomic.** Publish + tag + docs + smoke-install are separate operational steps; lumping them as "ship it" loses the audit trail when one of them silently fails.

package/studios/libdev/stages/release/review-agents/changelog-quality.md

@@ -0,0 +1,11 @@
+---
+interpretation: lens
+---
+**Mandate:** The agent **MUST** verify the changelog entry for this release is complete, accurate, and useful to consumers deciding whether to upgrade.
+
+**Check:**
+- The agent **MUST** verify every public API change has a changelog line
+- The agent **MUST** verify breaking changes are clearly marked (e.g., under a "Breaking" section or with a badge)
+- The agent **MUST** verify security-relevant changes are labeled
+- The agent **MUST** verify entries describe the change in consumer terms, not internal refactoring language
+- The agent **MUST** verify the changelog follows the project's prior format (Keep a Changelog, custom, etc.)

package/studios/libdev/stages/release/review-agents/semver-correctness.md

@@ -0,0 +1,12 @@
+---
+interpretation: lens
+---
+**Mandate:** The agent **MUST** verify the release version number correctly reflects the semver impact of changes since the prior release.
+
+**Check:**
+- The agent **MUST** diff the current API surface against the prior released version
+- The agent **MUST** verify a major bump is used when the diff contains any removed, renamed, or signature-changed public symbol
+- The agent **MUST** verify a major bump is used when error types were removed or their meaning changed
+- The agent **MUST** verify a minor bump is used for additions-only changes
+- The agent **MUST** verify a patch bump is used only when no public API changed
+- The agent **MUST** flag any behavior change to an existing API that would be observable and require a major bump even if signatures are unchanged

package/studios/libdev/stages/security/STAGE.md

@@ -0,0 +1,27 @@
+---
+name: security
+description: Supply chain, dependency audit, and consumer-misuse threat model
+hats: [threat-modeler, security-reviewer]
+fix_hats: [threat-modeler, feedback-assessor]
+review: [external, ask]
+elaboration: autonomous
+inputs:
+  - stage: inception
+    discovery: discovery
+  - stage: inception
+    discovery: api-surface
+  - stage: development
+    output: code
+---
+
+# Security
+
+Library security focuses on three surfaces: supply chain (transitive
+dependencies, known CVEs, build reproducibility), public API attack surface
+(what can a malicious consumer do with this library), and injection vectors
+relevant to the library's domain (path traversal for filesystem libs,
+prototype pollution for JS utilities, SSRF for HTTP clients).
+
+Unlike application security, library security has to consider the library as
+a potential *source* of vulnerabilities in downstream applications — the
+threat model is "what if my consumer misuses this."

package/studios/libdev/stages/security/hats/feedback-assessor.md

@@ -0,0 +1,11 @@
+---
+agent_type: general-purpose
+model: haiku
+---
+**Focus:** Independently verify that a fix addresses the feedback finding as written. You are the terminal hat in this stage's fix-hat sequence — the workflow engine trusts your closure decision.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** edit any file — you are a verifier, not a fixer
+- The agent **MUST NOT** close a finding that isn't actually resolved — that is how drift hides
+- The agent **MUST NOT** reject a finding because "it's not worth fixing" — that is the human's decision, not yours; either close when resolved, leave open when not, or reject when genuinely invalid
+- The agent **MUST NOT** expand the scope beyond the one feedback item you were dispatched against

package/studios/libdev/stages/security/hats/security-reviewer.md

@@ -0,0 +1,9 @@
+---
+interpretation: lens
+---
+**Focus:** Evaluate the library against the threat model and determine whether findings are resolved, mitigated, or accepted with documented justification.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** accept "low severity" as a resolution — either mitigate or justify with consumer guidance
+- The agent **MUST** ensure consumer guidance lands in public docs, not just internal notes
+- The agent **MUST** verify dependency audit findings are actually addressed, not just acknowledged

package/studios/libdev/stages/security/hats/threat-modeler.md

@@ -0,0 +1,7 @@
+**Focus:** Model threats specific to this library: supply chain risks, misuse by consumers, injection surfaces, and the downstream impact of vulnerabilities in library code. Library threat modeling differs from app threat modeling because the library is a *source* of risk for downstream applications, not a direct victim.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST** model the library as a potential source of vulnerability for downstream apps, not just as a target
+- The agent **MUST** verify that unsafe defaults are flagged — libraries inherit blame for consumer misuse when defaults are bad
+- The agent **MUST NOT** dismiss "consumer would never do that" — consumers will do that
+- The agent **MUST** surface transitive dependency risks, not just direct ones

package/studios/libdev/stages/security/outputs/SECURITY-REPORT.md

@@ -0,0 +1,37 @@
+---
+name: security-report
+location: .haiku/intents/{intent-slug}/knowledge/SECURITY-REPORT.md
+scope: intent
+format: text
+required: true
+---
+
+# Security Report
+
+Record of the security review for this intent: threats modeled, findings, mitigations, and accepted risks. This report is consumed by the release stage as part of the release readiness check.
+
+## Content Guide
+
+### Threats Modeled
+- Supply chain
+- Consumer misuse
+- Data handling
+- Injection surfaces
+
+### Findings
+For each finding: severity, location, description, status (mitigated/accepted/deferred), and mitigation or justification.
+
+### Dependency Audit
+- Tool used and version
+- Date run
+- Summary of findings and their resolution
+
+### Consumer Guidance
+- Any security guidance that MUST land in public documentation for consumers to use the library safely
+
+## Quality Signals
+
+- Every threat in the model has a documented status
+- Accepted risks include justification, not just "acceptable"
+- Consumer guidance is explicit and actionable, not vague warnings
+- Dependency audit findings are linked to CVE identifiers where applicable

package/studios/libdev/stages/security/phases/ELABORATION.md

@@ -0,0 +1,49 @@
+# Security Stage — Elaboration
+
+Security is an **adversarial** stage. Its units are attack surfaces — public API attack surface, supply-chain surface, and consumer-misuse surface. Each unit specifies the surface, threat actors, attack vectors, mitigations, and verification approach.
+
+## What a unit IS in this stage
+
+One attack surface or threat boundary. Examples:
+
+- "Public API attack surface — what can a malicious consumer pass to each exported function"
+- "Supply chain — transitive dependency CVE scan, build reproducibility, signed releases"
+- "Injection vector class — domain-specific (path traversal for fs libs, prototype pollution for JS utility libs, SSRF for HTTP clients, ReDoS for regex-heavy libs)"
+- "Consumer-misuse surface — what does this library do if a downstream app misuses it (e.g., passes user input where developer input is expected)"
+- "Resource-exhaustion surface — algorithmic complexity, large-input handling, memory bounds"
+
+What a unit is **NOT** in this stage:
+
+- ❌ A new feature (those belong in `development`)
+- ❌ A general code-quality concern (that's `development` review-class work)
+- ❌ A user-deployment / runtime concern (libraries don't have runtime ops; that's an application concern downstream)
+
+## What "completion criteria" means here
+
+Adversarial-stage criteria specify **threats considered, mitigations declared, and verification approach for each mitigation**. Pass means the surface is named, exercised by a documented attack chain or analysis, and the mitigations have a verifiable check.
+
+### Good criteria — concrete and adversarial
+
+- "API surface unit lists every exported function, names ≥1 plausible misuse per function, and declares whether the misuse is acceptable (documented contract), defended (input validation + test), or out-of-scope (with rationale)"
+- "Supply chain unit lists current dependency tree, runs `npm audit` / `pip-audit` / `cargo audit` and records HIGH/CRITICAL findings, names a remediation plan for each non-deferred finding"
+- "Injection vector unit demonstrates the attack with a failing test, then ships the fix and shows the test passing"
+- "ReDoS / algorithmic complexity unit names the worst-case input class and demonstrates bounded behavior under a 10s timeout"
+
+### Bad criteria — vague or non-adversarial
+
+- ❌ "Library is secure" (not a check)
+- ❌ "No vulnerabilities found" (no methodology cited)
+- ❌ "Code review passed" — wrong stage; that's `development` reviewer
+
+## How verification happens
+
+Security artifacts are validated by the verify-class hat declared in `STAGE.md` (currently `security-reviewer`). Per architecture §3.5, adversarial hats are exempt from the body-only rule, but a stage that is ENTIRELY adversarial (no plan-do-verify front loop) is an architecture violation worth flagging in a separate restructure proposal.
+
+The verifier checks **threats considered against the surface scope, mitigations declared with verification approach, decision-register accountability** — body-content checks. Frontmatter is not interpreted; workflow engine owns DAG and lifecycle.
+
+## Anti-patterns
+
+- **Adversarial without a verify gate.** A stage with two adversarial-do hats and no verifier produces findings that nobody validated. The chain needs a terminal hat that decides "this surface is closed enough to ship".
+- **Dependency-only security.** Running `npm audit` once and calling the stage done misses the public-API misuse surface — which is the harder, more library-specific work.
+- **Threats without exploitability.** Listing 30 hypothetical attacks without ranking exploitability inflates risk theater. Each named attack should have an exploitability assessment + mitigation status.
+- **Skipping the consumer-misuse lens.** Library security is unique because the *consumer* is a potential attack source on their own users. "What if my consumer passes user input here" is the question that distinguishes library threat models from application threat models.

package/studios/libdev/stages/security/review-agents/misuse-resistance.md

@@ -0,0 +1,10 @@
+---
+interpretation: lens
+---
+**Mandate:** The agent **MUST** verify the library's public API is resistant to unsafe use by consumers. Libraries that are easy to misuse are effectively insecure regardless of the internal code quality.
+
+**Check:**
+- The agent **MUST** verify unsafe defaults are flagged and either fixed or documented with consumer guidance
+- The agent **MUST** verify injection-prone entry points have explicit documentation on safe usage
+- The agent **MUST** verify error messages and serialization do not leak sensitive data to downstream code
+- The agent **MUST** verify the library does not silently trust inputs that consumers would naturally pass from untrusted sources

package/studios/libdev/stages/security/review-agents/supply-chain.md

@@ -0,0 +1,11 @@
+---
+interpretation: lens
+---
+**Mandate:** The agent **MUST** verify the library's dependency tree is audited and free of known-vulnerable dependencies before release.
+
+**Check:**
+- The agent **MUST** verify the dependency audit tool (npm audit, pip-audit, cargo audit, etc.) has been run and findings addressed
+- The agent **MUST** verify no direct dependency has a known high/critical CVE without documented mitigation
+- The agent **MUST** verify transitive dependency risks are assessed, not just direct ones
+- The agent **MUST** verify dependency licenses are compatible with the library's license
+- The agent **MUST** flag any dependency with no maintenance activity in 12+ months as a supply-chain risk

package/studios/marketing/STUDIO.md

@@ -0,0 +1,11 @@
+---
+name: marketing
+description: Marketing campaign lifecycle from audience research through launch and measurement
+stages: [research, strategy, content, launch, measure]
+category: go-to-market
+default_model: sonnet
+---
+
+# Marketing Studio
+
+Campaign and content marketing lifecycle. Covers audience research, strategy development, content creation, multi-channel launch, and performance measurement. Works for product launches, content campaigns, and brand initiatives.

package/studios/marketing/examples/pricing-page-relaunch/intent.md

@@ -0,0 +1,17 @@
+---
+title: pricing-page-relaunch
+studio: marketing
+stages: [research, strategy, content, launch, measure]
+status: complete
+---
+
+# Pricing Page Relaunch
+
+Relaunch the public pricing page. The current page buries Enterprise in an afterthought row; the new page surfaces it as a full tier with a contact-sales path. Growth is renamed to Team with per-seat + platform-fee pricing and usage add-ons.
+
+## Goals
+
+- Three-tier layout: Free, Team, Enterprise (Growth renamed and repriced)
+- Explicit Enterprise row with capability matrix and contact-sales CTA
+- Team tier pricing: per-seat + platform fee with usage add-ons for storage and API calls
+- Launch with A/B test against current page, lift target +15% enterprise contact-sales clicks

package/studios/marketing/examples/pricing-page-relaunch/pre-intent.yml

@@ -0,0 +1,17 @@
+related:
+  - product-strategy
+  - sales
+  - documentation
+turns:
+  - role: user
+    text: "Relaunch the pricing page. The current one buries enterprise."
+  - role: agent
+    text: "Three tiers like today, or restructure the plans too?"
+  - role: user
+    text: "Three tiers, but rename Growth → Team, and add a real Enterprise tier with a contact-sales CTA."
+  - role: agent
+    text: "Per-seat, flat, or usage-based for the Team tier?"
+  - role: user
+    text: "Per-seat with a platform fee. Usage add-ons for storage and API calls."
+  - role: agent
+    text: "Got it — three-tier page with a real Enterprise row and per-seat + usage Team pricing."

package/studios/marketing/fix-hats/reconciler.md

@@ -0,0 +1,10 @@
+---
+agent_type: general-purpose
+---
+**Focus:** Reconcile cross-stage artifacts against studio-wide standards. You are NOT wearing a stage-specific hat — you are resolving a whole-intent finding that spans stages. Your mandate is alignment, not fresh authoring.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** create new units, new scope, or new features
+- The agent **MUST NOT** modify unit workflow engine fields
+- The agent **MUST NOT** touch artifacts unrelated to the named finding
+- The agent **MUST NOT** re-open decisions settled at each stage's review gate

package/studios/marketing/fix-hats/validator.md

@@ -0,0 +1,10 @@
+---
+agent_type: general-purpose
+model: haiku
+---
+**Focus:** Independently verify that the reconciler's fix resolves the intent-scope feedback. You are the terminal hat — the workflow engine trusts your closure decision.
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** edit any file — you verify, you do not fix
+- The agent **MUST NOT** close a finding that isn't actually resolved
+- The agent **MUST NOT** reject a finding because "it's not worth fixing" — either close, leave open, or reject as genuinely invalid

package/studios/marketing/operations/attribution-audit.md

@@ -0,0 +1,20 @@
+---
+name: attribution-audit
+type: scheduled
+owner: agent
+schedule: "0 9 1 * *"
+runtime: node
+---
+
+**Purpose:** Verify tracking and attribution are working correctly. Bad attribution leads to bad decisions.
+
+**Procedure:**
+- Test all UTM parameters and tracking links
+- Verify conversion pixels are firing on target pages
+- Check that attribution model is producing sensible results
+- Compare attributed conversions against actual transactions
+
+**Signals:**
+- Monthly audit cadence
+- After any tracking code changes
+- After any landing page redesign

package/studios/marketing/operations/content-calendar.md

@@ -0,0 +1,19 @@
+---
+name: content-calendar
+type: scheduled
+owner: human
+frequency: "weekly"
+---
+
+**Purpose:** Maintain the content publication schedule. Consistency matters more than volume.
+
+**Procedure:**
+- [ ] Review upcoming scheduled publications
+- [ ] Verify assets are ready for scheduled dates
+- [ ] Identify gaps in the calendar
+- [ ] Adjust schedule based on performance data from last period
+
+**Signals:**
+- Weekly planning meeting
+- Content asset delayed or pulled
+- Performance data suggests topic pivot

package/studios/marketing/operations/performance-dashboard.md

@@ -0,0 +1,20 @@
+---
+name: performance-dashboard
+type: scheduled
+owner: agent
+schedule: "0 8 * * 1"
+runtime: node
+---
+
+**Purpose:** Generate weekly campaign performance snapshots. Trends matter more than individual data points.
+
+**Procedure:**
+- Pull KPIs defined in the strategy stage
+- Compare current period to previous period and baseline
+- Identify statistically significant changes (not just noise)
+- Flag metrics trending below target thresholds
+
+**Signals:**
+- Weekly reporting cadence
+- Campaign launch or major asset change
+- Spend threshold exceeded

package/studios/marketing/reflections/audience-insights.md

@@ -0,0 +1,17 @@
+---
+name: audience-insights
+studio: marketing
+---
+
+**Analyze:** Audience segment performance, engagement patterns, conversion paths.
+
+**Look for:**
+- Segments that responded differently than expected from research
+- Unexpected audience segments that engaged strongly
+- Conversion path patterns (which touchpoints matter most)
+- Whether audience research predictions held up
+
+**Produce:**
+- Segment performance comparison
+- Research accuracy assessment
+- Recommendations for audience definition refinement

package/studios/marketing/reflections/campaign-effectiveness.md

@@ -0,0 +1,17 @@
+---
+name: campaign-effectiveness
+studio: marketing
+---
+
+**Analyze:** KPI achievement vs targets, channel performance, content engagement rates, spend efficiency.
+
+**Look for:**
+- Channels that over/underperformed relative to spend
+- Content types that drove disproportionate engagement
+- Whether the messaging framework resonated (engagement vs impressions)
+- Attribution gaps that make measurement unreliable
+
+**Produce:**
+- Channel ROI ranking
+- Content format effectiveness assessment
+- Recommendations for budget reallocation and messaging refinement

package/studios/marketing/review-agents/cross-stage-consistency.md

@@ -0,0 +1,17 @@
+---
+scope: intent
+interpretation: lens
+---
+**Mandate:** Verify the intent's artifacts are internally consistent across stages. You are the only reviewer that sees the whole intent at once — your job is to catch seams that per-stage reviewers miss.
+
+**Check:**
+- The agent **MUST** verify that each stage's outputs align with what upstream stages specified — no dropped requirements, no silent scope expansion
+- The agent **MUST** verify that naming is consistent across stages — a concept named one thing upstream should carry the same name downstream
+- The agent **MUST** verify that stages' declared outputs exist at the paths their unit frontmatter promised
+- The agent **MUST** verify that the stages collectively deliver the intent's stated goal (read `intent.md`) — partial delivery is a finding
+- The agent **MUST** verify that concerns raised by any stage's review were actually addressed (not silently ignored)
+
+**Anti-patterns (RFC 2119):**
+- The agent **MUST NOT** re-litigate decisions already approved at each stage's gate
+- The agent **MUST NOT** propose new features or scope additions
+- The agent **MUST NOT** flag stylistic preferences — concrete divergence only