dreamcontext 0.5.0

package/dist/skill-packs/meta-marketing/platform-state.md

@@ -0,0 +1,63 @@
+---
+title: "Meta Platform State"
+purpose: "Time-stamped Meta UI and algorithm facts that change over time. Separate from operator rules — these describe what Meta's platform looks like RIGHT NOW, not how to use it. Update this file when Meta changes a default, removes a feature, or shifts algorithm behavior."
+last_verified: "2026-04-25"
+---
+
+# Meta Platform State (as of 2026-04-25)
+
+These are facts about Meta's current platform behavior — UI defaults, algorithm changes, and known shifts. They are distinct from operator rules (which are in `account-ops.md`) and creative rules (which are in `copy-formulas.md`).
+
+**When reading this file:** Check `last_verified` date. If it is more than 60 days ago, treat entries as potentially stale and verify in Ads Manager before relying on them.
+
+---
+
+## Current Defaults (may differ from what operators remember)
+
+| Setting | Current default | Changed from | Date confirmed | Source |
+|---|---|---|---|---|
+| Attribution window | **1-day view** | Previously 7-day click + 1-day view | 2026 | mistakes-report-2026 |
+| Campaign type recommendation | Advantage+ campaigns | Manual campaigns (ABO/CBO) | 2025 | Ben Heath (`dAJyqo6wnq4`), mistakes-report-2026 |
+| Targeting | Advantage+ Audience (suggestions, not hard constraints) | Interest targeting as hard filters | 2024–2025 | Ben Heath (`JLlcwojiVtw`), mistakes-report-2026 |
+| Placements | Advantage+ placements (all placements auto-selected) | Manual placement selection | 2024 | Ben Heath (`JLlcwojiVtw`), Moonlighters (`FYUR8ZL4_xY`) |
+
+**Operator implication — attribution window:** Meta now reports on a shorter window by default. Your reported ROAS may appear lower than before even if real performance is unchanged. Always compare apples-to-apples when benchmarking: same attribution window, same date ranges.
+
+---
+
+## Known Algorithm Behavior (current)
+
+| Behavior | Detail | Date confirmed | Source |
+|---|---|---|---|
+| Meta uses ads within one adset in funnel sequences | Meta may show ad A first (top-funnel), then ad B (conversion). Ad A will have low ROAS but is doing real work. | 2026-04-25 | Ben Heath (`13s-G9Uj51A`, `kuSq-pmNfnM`) |
+| Targeting inputs are suggestions, not constraints | Even if you set interests or custom audience targeting, Meta may deliver outside those boundaries unless you explicitly force hard constraints via hidden settings. | 2025–2026 | Ben Heath, Charlie, Moonlighters (all 3 speakers) |
+| Advantage+ Shopping YoY improvement | Meta reported ~70% YoY improvement in Advantage+ Shopping campaign performance in Q4 2024 | Q4 2024 | mistakes-report-2026 |
+| Andromeda algorithm rollout | Meta's new AI delivery system (Andromeda) rolled out broadly. Affects targeting, delivery sequencing, and optimization. Heavily favors broad signals over narrow ones. | 2025-12 | mistakes-report-2026 |
+| Andromeda creative-pool reweighting | Andromeda rewards larger creative pools per adset (15–30 ads) over the pre-Andromeda 3–10 norm. Smaller pools starve the algorithm of optimization signal. The 3–10 figure in older corpus sources predates this shift. | 2026 | SKILL.md §III update 2026-04-26; user-flagged gap |
+
+---
+
+## Known UI Changes
+
+| Change | Detail | Date | Source |
+|---|---|---|---|
+| Exclude custom audiences is now a hard exclusion | Previously "exclude" was treated as a soft signal; Meta could override it. As of 2026, exclusions are enforced as hard boundaries. | 2026-04-25 | Ben Heath (`13s-G9Uj51A` §1) |
+| Learning phase threshold | ~50 conversions/week per adset to exit learning phase. This number has been consistent since 2023 but worth verifying if Meta updates guidance. | 2023–2026 | mistakes-report-2026, Ben Heath |
+
+---
+
+## Deprecations / Removed Features
+
+| Feature | Status | Last seen | Notes |
+|---|---|---|---|
+| Interest-based targeting as primary strategy | Effectively deprecated — Meta ignores or overrides in most cases | 2023 | Still available in UI but corpus consensus is it no longer performs |
+| Manual bidding as default approach | Still available but not recommended for most accounts | 2024 | Use auto-bid unless you have a specific bid strategy rationale |
+
+---
+
+## What to check when this file feels stale
+
+1. Open Ads Manager → any campaign → verify the attribution window shown in column settings
+2. Check Meta's "What's New" in Business Help Center for algorithm updates
+3. Run a test campaign and check whether interest targeting is being overridden in Delivery Insights
+4. Update `last_verified` date after verification

package/dist/skill-packs/multi-review/REVIEWER_SHARED.md

@@ -0,0 +1,143 @@
+# REVIEWER_SHARED — rules every specialist obeys
+
+This file is the shared contract for the multi-reviewer system. The router and
+every specialist read it. Do not duplicate its content into specialist files;
+reference it.
+
+---
+
+## 1. Severity rubric (use these exact labels)
+
+| Label | Meaning | Coordinator action |
+|---|---|---|
+| **🔴 Critical** | Will cause data loss, security breach, outage, or wrong results in production under plausible conditions. | Blocks merge. |
+| **🟠 Major** | Real bug or measurable regression under plausible conditions. Should fix before merge. | Blocks unless explicitly accepted with a reason. |
+| **🟡 Minor** | Correctness or maintainability concern worth addressing but not blocking. | Advisory. |
+| **⚪ Nit** | Style / preference. Include sparingly. | Advisory. Main agent drops if >5 across all specialists. |
+
+**Calibration**: if everything a specialist finds is `nit`, the specialist
+should say `PASS` and stop, not invent issues to look thorough.
+
+---
+
+## 2. What every specialist MUST flag (within their domain)
+
+- **Logic and correctness bugs** — off-by-one, inverted conditions, swapped
+  arguments, null/empty handling, default mismatches across layers.
+- **Cross-file ripple** — caller not updated after a signature/contract change,
+  renamed field still referenced elsewhere, new required parameter unhandled.
+- **Their specialty's named hazards** — listed in each specialist's own file
+  under `## Known hazards`.
+
+## 3. What every specialist MUST NOT flag
+
+- Pure formatting / whitespace (linter's job).
+- Naming style when consistent with the surrounding file.
+- "You could refactor this differently" without a concrete defect.
+- Theoretical risks with no plausible trigger ("what if the OS clock changes?").
+- Defense-in-depth suggestions when defense already exists upstream.
+- Anything a `nit` could capture but a Critical/Major couldn't — drop it.
+
+If a specialist is unsure whether something is real, it goes in the **Open
+questions** section, not in Findings.
+
+---
+
+## 4. Output format (every specialist returns exactly this shape)
+
+```markdown
+## Executive Summary
+<≤120 words. Lead with the verdict in one sentence (PASS / CONCERNS / FAIL).
+Then 2–3 lines naming the top concerns. The main agent reads only this section.>
+
+## Verdict
+PASS | CONCERNS | FAIL
+
+## Findings
+
+### 🔴 Critical
+1. **`path/to/file.ext:LINE`** — <short title>
+   <Explanation (1–3 sentences).>
+   *Why it matters:* <consequence under plausible conditions>
+   *Suggested fix:*
+   ```<lang>
+   <code snippet>
+   ```
+
+### 🟠 Major
+<same format>
+
+### 🟡 Minor
+<same format>
+
+### ⚪ Nits
+- `path:line` — <one-liner, no code block>
+
+## What looks good
+<1–3 bullets. Optional. Skip if nothing genuine to say.>
+
+## Open questions
+<Only if you genuinely couldn't determine something from the diff + loaded
+skills. Don't manufacture questions.>
+```
+
+Omit empty severity sections entirely (don't write "None.").
+
+---
+
+## 5. Verdict mapping
+
+- `PASS` — no Critical, no Major, ≤2 Minor.
+- `CONCERNS` — no Critical, some Major OR many Minor.
+- `FAIL` — at least one Critical.
+
+The **main agent** re-applies this mapping across all specialist reports to
+produce the final verdict, which uses different labels:
+
+- `READY_TO_MERGE` — every specialist returned `PASS`.
+- `NEEDS_ATTENTION` — any specialist returned `CONCERNS`, none returned `FAIL`.
+- `NEEDS_WORK` — any specialist returned `FAIL`.
+
+---
+
+## 6. Skill-loading discipline
+
+Each specialist file declares `skills:` in its YAML frontmatter. Those skills
+are auto-loaded when the specialist is dispatched. The specialist must **use**
+them — quote concrete rules from the skill in findings where applicable. A
+finding that contradicts a loaded skill's rule without justification is a bug
+in the specialist, not a finding.
+
+---
+
+## 7. Context discipline
+
+Specialists receive only their scoped files from the router. They may Read
+adjacent files if needed to verify a cross-file ripple finding, but should not
+Read the whole repository. If they need to read >5 files outside their scope to
+verify one finding, the finding probably isn't load-bearing — drop it or move
+it to Open questions.
+
+---
+
+## 8. Bounded output
+
+- Executive Summary: ≤120 words.
+- Full report: ≤1000 words total. Findings are tight; not essays.
+- Code snippets in suggested fixes: ≤15 lines per finding.
+
+If a specialist would exceed these bounds, it has found too many issues OR is
+writing too much per issue. Pick the top findings by severity and ship those.
+
+---
+
+## 9. Hard rules
+
+- **No fabrication.** If the specialist cannot verify a claim from the diff +
+  scoped files + loaded skills, it goes in Open questions, not Findings.
+- **No padding.** Three real findings beats fifteen suggestions.
+- **No re-reviewing other specialists' domain.** Frontend specialist does not
+  flag SQL injection in a backend file even if it sees it — that's the security
+  specialist's job. Cross-domain leakage is what the main agent dedupes.
+- **Cite the skill** in the finding when a rule it loaded backs the call
+  (e.g. "Per `engineering:firebase-cloud-functions` §retries, …").

package/dist/skill-packs/multi-review/SKILL.md

@@ -0,0 +1,182 @@
+---
+name: multi-review
+description: >
+  Multi-agent code review with a router and niche specialists.
+  Load when the user invokes `/multi-review`, says "multi-reviewer", "review with
+  a team", "review this PR with specialists", "team review", "thorough review",
+  or otherwise asks for a multi-aspect code review (security + cloud-functions
+  + frontend + edge-cases) of a diff or branch. Routes the diff to relevant
+  specialist sub-agents in parallel, then the main agent synthesizes findings
+  into one greptile-style report.
+tags: [review, multi-agent, sub-agents, orchestration, code-review]
+alwaysApply: false
+---
+
+# Multi-Reviewer — orchestrated specialist code review
+
+You are orchestrating a **multi-reviewer team**: a small cast of niche specialist
+sub-agents that each review the diff from a single angle. **You** read the full
+specialist reports, dedupe findings, and produce the final report directly.
+Specialists run **in parallel**.
+
+This skill is distinct from the existing single-reviewer `reviewer` agent and the
+pre-implementation `three-reviewer-parallel-mandates-pattern` knowledge entry:
+
+- **Use `reviewer` agent** for tiny diffs (≤10 lines, single domain).
+- **Use three-reviewer parallel-mandates** for **pre-implementation** plan review
+  (critic / pragmatist / security against a draft plan — no code yet).
+- **Use multi-reviewer (this skill)** for **post-implementation** code review of a
+  non-trivial diff that touches multiple domains.
+
+## When to invoke
+
+Trigger phrases / explicit invocations:
+- `/multi-review` (slash command — primary entry)
+- "multi-reviewer"
+- "review with the team"
+- "review this PR with specialists"
+- "team review"
+- "thorough review of my changes"
+- "review my branch with all the reviewers"
+
+**Use it for**: non-trivial diffs spanning multiple domains (e.g. Cloud Functions
++ frontend + security implications), pre-merge safety on critical paths,
+production-bound changes touching auth/payments/data.
+
+**Do NOT use it for**:
+- Tiny diffs (≤10 lines, one file) — use the existing `reviewer` agent.
+- Plan/spec review (no code written yet) — use `three-reviewer-parallel-mandates`.
+- Style/formatting passes — those aren't worth specialist time.
+
+## Flow (follow this exactly)
+
+### 0. Identify the diff
+
+Default: `git diff main...HEAD` on the current branch. If the user named a PR,
+branch, or commit range, use that instead. Confirm the diff scope back to the
+user in one line before dispatching anything (file count, line count, base ref).
+
+If there are no changes, say so and stop.
+
+### 1. Dispatch the router
+
+Dispatch **one** `review-router` sub-agent with the diff in its prompt. It returns
+a dispatch plan (JSON) with:
+
+```json
+{
+  "tier": "trivial | lite | full",
+  "specialists": ["security", "cloud-functions", "frontend", "edge-cases"],
+  "scope": {
+    "security": ["functions/auth/login.ts", "..."],
+    "cloud-functions": ["functions/triggers/onUserCreate.ts"],
+    "frontend": ["web/src/components/Login.tsx"],
+    "edge-cases": ["functions/triggers/onUserCreate.ts", "web/src/components/Login.tsx"]
+  },
+  "rationale": "one-line why this set was picked"
+}
+```
+
+**Short-circuit rules:**
+- If `tier == "trivial"` and only one specialist is named → dispatch that one
+  specialist alone, present its report directly.
+- If `tier == "trivial"` and the router judges no specialist is needed →
+  fall through to the existing `reviewer` agent and stop here.
+- If `tier == "lite"` → dispatch the named specialists (usually 2–3) in parallel.
+- If `tier == "full"` → dispatch all four specialists in parallel.
+
+**Hot-path override**: any file under `auth/`, `crypto/`, files matching
+`*.env*`, or migration files (`*.sql`, `migrations/**`) forces `security` to be
+in the specialist set regardless of tier.
+
+### 2. Dispatch specialists in parallel
+
+In a single message, fire one `Agent` call per named specialist:
+`review-security`, `review-cloud-functions`, `review-frontend`,
+`review-edge-cases`. Pass each one only the files in *its* scope from the
+dispatch plan (do not give every specialist every file — niche is the point).
+
+Each specialist returns a full report (bounded, greptile-style markdown ≤1000
+words) with an executive summary up top. You read the full reports to
+synthesize the final report in step 3.
+
+### 3. Synthesize the final report
+
+Read every specialist's full report. Dedupe, re-rank, and produce one final
+report yourself — no coordinator sub-agent. Apply these rules:
+
+**Deduplicate**: for each (file, line, ~topic) flagged by multiple specialists,
+keep one finding from the specialist whose domain best fits, cite all sources.
+
+**Re-rank severity**: a specialist's `Major` may downgrade to `Minor` in the
+full diff context (e.g. already rate-limited upstream). Downgrades need a
+one-line justification. Upgrades are fine without justification.
+
+**Drop false positives**: if a finding contradicts the diff context or loaded
+skills, drop it. Note all drops in **Coordinator notes** so the user can verify.
+
+**Compute verdict** per `REVIEWER_SHARED.md` §5:
+- **`READY_TO_MERGE`** — every specialist returned PASS, no Critical, no Major.
+- **`NEEDS_ATTENTION`** — any specialist returned CONCERNS, no Critical.
+- **`NEEDS_WORK`** — any specialist returned FAIL (at least one Critical).
+
+**Emit the report** inline using this structure:
+
+```markdown
+# Multi-Reviewer Report — <verdict>
+
+**Verdict:** READY_TO_MERGE | NEEDS_ATTENTION | NEEDS_WORK
+**Diff:** <files_changed> files, +<added>/-<deleted> lines, <base>...<head>
+**Specialists ran:** <list>
+**Dispatch tier:** <trivial|lite|full>
+
+## Summary
+<2–4 sentences.>
+
+## Findings
+### 🔴 Critical / ### 🟠 Major / ### 🟡 Minor / ### ⚪ Nits
+<deduped findings, each with source tag e.g. *(security, edge-cases)*>
+
+## What looks good
+<1–3 bullets aggregated across specialists.>
+
+## Open questions
+<Aggregated, deduped. Only real questions.>
+
+## Coordinator notes
+<Drops, downgrades, upgrades and why. ≤5 bullets. Skip if none.>
+```
+
+**Critical never gets dropped silently** — downgrade explicitly with a reason.
+Report ≤2000 words total.
+
+If the user wants to act on findings, follow up by editing the relevant files
+(do not auto-fix without confirmation on Critical findings).
+
+## Hard rules
+
+- **You read full specialist reports and synthesize yourself.** No coordinator
+  sub-agent — you have full context and produce the final report directly.
+- **Specialists run in parallel** in a single message with multiple Agent calls.
+  Sequential dispatch defeats the architecture.
+- **The router is mandatory** for tier ≥ lite. Skipping it means every specialist
+  sees every file, which is exactly the noise this design eliminates.
+- **Hot paths always get security**, regardless of tier.
+- **Use `dreamcontext` skill** to look up the active task before starting — the
+  review is scoped to what the task actually asked for, not a generic "things I'd
+  prefer."
+
+## Slash command wiring
+
+The `/multi-review` command (configured in `.claude/settings.json` or wherever
+slash commands are registered) invokes this skill. Skill-based fallback triggers
+on the natural-language phrases listed in **When to invoke**.
+
+## Relationship to other review surfaces
+
+| Surface | When | This skill's relationship |
+|---|---|---|
+| `reviewer` agent (built-in, single) | Tiny diffs, final go/no-go gate | Standalone. Multi-reviewer can hand off to it for the final merge gate after fixes. |
+| `greptile-style-review` skill | Generalist single-pass review | Becomes the **output spec** all specialists conform to (severity tags, format). |
+| `three-reviewer-parallel-mandates-pattern` (knowledge) | Pre-implementation plan review | Different stage. Multi-reviewer is post-implementation. |
+| `sub-agent-iterative-reviewer-pattern` | Single holistic post-impl review | Superseded by multi-reviewer for non-trivial diffs; still fine for tiny ones. |