@damiangilgonzalez/harness 1.3.7

package/skills/community/evals/README.md

@@ -0,0 +1,3 @@
+# Evals — community
+
+`cases.yaml` is a judging harness, not an executable test suite. Run it with a human or an LLM judge. The `should_trigger` and `should_not_trigger` cases check routing discipline: each `should_trigger` prompt should pull in this skill (including the non-obvious "graveyard" and Catalan phrasings), and each `should_not_trigger` prompt should route to the named sibling (`retention`, `newsletter`, `social-publisher`, `webinar`) instead of here. The `capability` case is run end-to-end against a real session: give the agent the scenario and score the response against the `must_include` rubric — every bullet must be satisfied (purpose+north-star gate, platform rationale, onboarding path, 3-layer moderation, a ritual with cadence, the metrics, and the emitted artifact validated by `scripts/verify.sh`). Structural defects in the emitted `moderation-config` are caught mechanically by `scripts/verify.sh`; the rubric covers the process rigor that no script can check.

package/skills/community/evals/cases.yaml

@@ -0,0 +1,40 @@
+skill: community
+
+should_trigger:
+  - prompt: "Set up our Discord server for the SaaS user community — channels, roles, and rules."
+    why: Core stand-up job — structure + onboarding + moderation for a persistent two-way space.
+  - prompt: "Our Telegram group is a graveyard, nobody posts anymore. How do we revive it?"
+    why: Non-obvious — no setup words, but it is a dead two-way space needing rituals + re-activation, the heart of this skill.
+  - prompt: "We keep getting spam raids and scam-DM waves in our community — lock it down."
+    why: Moderation / incident response (native + bot + human stack, raid runbook) is owned here.
+  - prompt: "Should we run our paid membership on Circle or just use Discord?"
+    why: Platform decision including monetization — the decision table routes this.
+  - prompt: "La comunitat de Discord està morta, ningú escriu — com la reactivem?"
+    why: Catalan phrasing for a graveyard re-activation; rituals + growth loops.
+  - prompt: "How do I get the lurkers in our community to actually post something?"
+    why: Lurker-to-contributor growth (90-9-1 is a range, move members up a tier) is a core job.
+
+should_not_trigger:
+  - prompt: "Our SaaS users keep cancelling in month 2 — build a win-back and churn-reduction flow."
+    route_to: retention
+    why: Paying-customer churn of a product, not activity in a shared member space.
+  - prompt: "Write this week's broadcast email to our subscriber list."
+    route_to: newsletter
+    why: One-to-many opted-in email, not a two-way persistent space.
+  - prompt: "Schedule and cross-post our launch announcement across X, LinkedIn, and Instagram."
+    route_to: social-publisher
+    why: Public-feed posting, not a community space.
+  - prompt: "Run our product-launch webinar end-to-end: registration page, speakers, and replay."
+    route_to: webinar
+    why: A single timed live event, not a persistent two-way space.
+
+capability:
+  - scenario: "Stand up a Discord community for an indie game-dev audience whose business goal is converting free players into paying supporters."
+    must_include:
+      - States or extracts a one-line purpose AND one north-star business metric before designing anything (Step 0 gate).
+      - Justifies Discord over Telegram and Circle for this audience using the decision rules.
+      - Minimal channel set (no sprawl) + role-on-join + an onboarding "first meaningful action" path with the rules/membership gate.
+      - 3-layer moderation — native AutoMod + a verification level, a bot, and human mods — sized to expected scale.
+      - At least one weekly ritual with an explicit cadence.
+      - Names the one business metric plus at least one health metric (e.g. TTFR or DAU/MAU ≥20% floor).
+      - Emits a community-plan.md + moderation-config artifact and references scripts/verify.sh.

package/skills/community/references/metrics-and-rituals.md

@@ -0,0 +1,58 @@
+# Metrics & rituals
+
+The health scorecard and the operating-rhythm library. Use this with the Metrics and Rituals sections of `../SKILL.md`. Facts carry source + access date.
+
+## The metric clusters
+
+Metrics cluster into three groups plus exactly one business metric tied to your Step-0 purpose.
+
+### Cluster 1 — activation / retention
+- **DAU / WAU / MAU** and **stickiness = DAU/MAU**. Benchmark band for social/messaging products is **~50–80%**; treat **≥ 20% as a floor** for a healthy community. Below 20% the room is decaying.
+- **30 / 60 / 90-day cohort retention** — track each join-cohort's survival; it is the truest read on whether onboarding actually activates.
+- **Returning-member ratio** — share of members who came back this period; the direct signal that rituals are working.
+
+### Cluster 2 — member value
+- **Time-to-first-response (TTFR)** — how long until a newcomer's first post gets a reply. Lower is better; this is the newcomer's first lived experience of the room.
+- **Answered rate** — share of questions that get any answer. Drive toward 100%; unanswered questions teach members not to ask.
+
+### Cluster 3 — exactly ONE business metric
+Pick **one** that matches the purpose, and only one:
+- **Support deflection** — questions answered by members vs tickets filed.
+- **Retention uplift** — product retention of members vs non-members.
+- **Expansion revenue** — upgrades/supporter conversions sourced from the space.
+- **Qualified referrals** — warm intros / leads the community generates.
+
+Source: Bevy *Top 11 Community Engagement Metrics for 2025*, Discourse *20 Community Metrics Explained* (2025-04), Geckoboard *DAU/MAU*, accessed 2026-06-02.
+
+## The 90-9-1 reality
+
+- **Participation inequality / "1% rule":** ~**90% lurk, 9% contribute occasionally, 1% drive most activity** — but this is a **range, not a law**.
+- Healthier communities skew far more active: observed profiles like **55-30-15** and **17-57-26**.
+- Design implication: **do not accept 90% lurkers as fixed.** Move lurkers up a tier with prompts, one-tap reactions, and direct asks.
+- Source: NN/g *Participation Inequality* (Nielsen) + Higher Logic *90-9-1 … Officially Outdated*, accessed 2026-06-02.
+
+## Ritual template library
+
+Predictable cadence beats sporadic effort. Run each on time, every time; consistency is the whole point.
+
+| Ritual | Cadence | Friction | What it produces |
+|---|---|---|---|
+| "What are you working on?" thread | Weekly (Mon) | Low — one reply | Re-engagement hook, surfaces who's active |
+| Office hours / AMA | Weekly (Wed) | Medium — opt-in | High-value 1:1-in-public, answered-rate boost |
+| "Wins of the week" | Weekly (Fri) | Low — a reaction counts | Positive loop, social proof |
+| Monthly show-and-tell / demo day | Monthly | Medium | Deepens the 1%/9%, content for announcements |
+| Onboarding "intro Tuesday" round-up | Weekly | Low | Pulls new members into threads day one |
+| Poll of the week | Weekly | Very low — one tap | Cheap participation for lurkers |
+
+### Sample weekly calendar
+```text
+Mon  WIP thread posted 09:00 local
+Wed  Office hours 17:00–18:00 (opt-in @office-hours role)
+Fri  Wins thread + react-to-celebrate
+Sun  (mod) scorecard glance: TTFR, answered rate, new-member activation
+```
+
+### Low-friction participation rules
+- Prefer **reactions and polls** over "write a paragraph" — every tier can participate.
+- Use **opt-in role pings** for ritual reminders; never `@everyone` for routine beats (over-pinging trains mutes, and a muted member is functionally gone).
+- Reserve `@everyone` for genuine all-hands moments only.

package/skills/community/references/platform-playbooks.md

@@ -0,0 +1,64 @@
+# Platform playbooks
+
+Per-platform setup depth. Pick the platform with the decision table in `../SKILL.md`; this file is the build manual for each. Every load-bearing fact carries its source + access date.
+
+## Discord — the real-time default
+
+### AutoMod (native layer)
+- **Keyword filters**: one **Commonly-Flagged-Words preset rule** (`KEYWORD_PRESET`: Insults & Slurs, Sexual Content, Severe Profanity), **1 per guild**, **plus up to 6 custom keyword rules** (`KEYWORD` trigger), each filter holding **up to 1,000 terms** (60 chars each). Use a custom rule for your scam-phrase blocklist and link patterns. Note: the "1,000" is the per-rule *filter* size; do not confuse it with the 100-entry cap on a `KEYWORD` rule's per-rule *allow_list* (exception terms).
+- **Mention-spam cap** (`MENTION_SPAM`, 1 per guild): configurable up to **50 unique role/user mentions per message** before AutoMod acts. Set this low (e.g. 5) for raid resistance.
+- Actions per rule: block message, alert a mod channel, timeout the author. Always route a copy to a private `#mod-log`.
+- Source: Discord — *Auto Moderation* developer docs (docs.discord.com/developers/resources/auto-moderation) + *AutoMod FAQ* (support.discord.com), accessed 2026-06-02.
+
+### Verification levels
+- Set **Medium** as the baseline: verified email + member for >5 minutes before talking. **High** adds a 10-minute server-tenure requirement; **Highest** requires a verified phone. Raise the level temporarily during a raid (the "lockdown" lever).
+
+### Rules Screening / Membership Screening
+- Gates **talking and DMs** until a new member explicitly acknowledges the rules. This both stops drive-by spam and forces the first deliberate click of the onboarding funnel.
+- Pair with **Onboarding** (role/interest selection on join) so the rules-ack flows straight into role-on-join → personalized channels.
+- Source: Discord — *Rules Screening FAQ* + community-building playbooks, accessed 2026-06-02.
+
+### Layered defense by size (Discord's own guidance)
+| Size | Recommended stack |
+|---|---|
+| Small (< 1,000) | Native AutoMod + Medium verification |
+| > 1,000 | Add a specialized moderation bot + custom keyword rules |
+| > 10,000 | Robust multi-tool bots + Commonly-Flagged filters on |
+| > 100,000 | Multiple specialized bots + tiered human mod org |
+- Canonical 3-layer stack everywhere: **native tools → bot automod → human mods**.
+- Source: Discord safety guidance summarized in friendify.net *Discord Moderation & AutoMod Complete Guide (2025)*, accessed 2026-06-02.
+
+## Telegram — mobile-first, broadcast-heavy
+
+### The hybrid pattern (2026 standard)
+- **Groups = two-way conversation; channels = one-way broadcast.** A bare group has no clean announce lane; a bare channel has no conversation. Run a **channel for announcements + a linked discussion group** so each post can spawn a thread.
+- Source: Metricgram — *Telegram Group vs Channel*, accessed 2026-06-02.
+
+### Native anti-spam + slow-mode
+- **Native ML anti-spam activates for groups > 200 members**, with an **"Aggressive" mode** that auto-deletes suspected spam. Below that threshold it is unavailable.
+- For low-traffic groups (**≤ 30 messages/hour**), **slow-mode alone** is the recommended zero-setup control — no bot needed.
+- Source: Metricgram — *Best Telegram Anti-Spam Bots* / *Supergroups Explained*, accessed 2026-06-02.
+
+### Raid gate
+- **CAPTCHA-on-join** is the standard raid wall: button / math / question challenge (e.g. **Shieldy**). New accounts must pass before they can post.
+- Source: Metricgram — *Anti-Spam Bots*, accessed 2026-06-02.
+
+## Circle — the paid / monetized end
+
+### Spaces and structure
+- Content is organized into **Spaces**, which structure **tiered membership** and bundle **courses and events**. This is the monetization primitive — gate Spaces by paid tier.
+
+### 2026 plan ladder + fees
+Circle **discontinued the old "Basic" tier** — **Professional is now the entry plan**.
+
+| Plan | Approx monthly | Circle transaction fee |
+|---|---|---|
+| Professional (entry) | ~$89 annual / ~$129 monthly | 2% |
+| Business | ~$199 annual / ~$219 monthly | 1% |
+| Circle Plus (Enterprise, custom) | ~$419+ | 0.5% |
+- The transaction fee is **tiered 0.5%–2%** (2% Professional, 1% Business, 0.5% Circle Plus) and is charged by Circle **on top of Stripe's standard 2.9% + $0.30** per transaction — budget both layers when modeling take rate.
+- **Real-time chat is weaker than Discord** — choose Circle for monetized membership + content bundling, not for fast live conversation.
+- Source: Circle.so *Pricing* (circle.so/pricing) summarized in SchoolMaker *Circle.so Pricing 2026*, accessed 2026-06-02.
+
+### Monetization gating
+- Do **not** monetize before activation works. Charging for a dead room produces instant churn. Prove rhythm + cohort retention on the free or trial tier first, then gate the high-value Spaces.

package/skills/community/scripts/verify.sh

@@ -0,0 +1,83 @@
+#!/usr/bin/env bash
+# verify.sh — structural check for a community moderation-config artifact.
+# Read-only. Validates required keys, a non-empty north-star, all 3 moderation
+# layers, and at least one ritual with a cadence. Exits 0 on a clean/empty target.
+#
+# Usage: scripts/verify.sh [path/to/moderation-config.yaml|.json]
+# If no path is given, scans the working tree for moderation-config.{yaml,yml,json}.
+# No target found => nothing to check => exit 0 (no false failure).
+
+set -euo pipefail
+
+fail() { echo "FAIL: $1" >&2; exit 1; }
+ok()   { echo "OK: $1"; }
+
+# --- resolve targets -------------------------------------------------------
+targets=()
+if [ "$#" -ge 1 ]; then
+  for arg in "$@"; do
+    [ -f "$arg" ] || fail "no such file: $arg"
+    targets+=("$arg")
+  done
+else
+  while IFS= read -r f; do targets+=("$f"); done < <(
+    find . -type f \( -name 'moderation-config.yaml' -o -name 'moderation-config.yml' -o -name 'moderation-config.json' \) 2>/dev/null
+  )
+fi
+
+if [ "${#targets[@]}" -eq 0 ]; then
+  echo "OK: no moderation-config artifact found — nothing to verify."
+  exit 0
+fi
+
+# --- per-file checks -------------------------------------------------------
+check_file() {
+  local file="$1"
+  local body
+  body="$(cat "$file")"
+
+  # Parse-only sanity for JSON; YAML is checked line-wise via grep below.
+  case "$file" in
+    *.json)
+      if command -v python3 >/dev/null 2>&1; then
+        python3 -c "import json,sys; json.load(open(sys.argv[1]))" "$file" \
+          || fail "$file is not valid JSON"
+      fi
+      ;;
+  esac
+
+  # required top-level / nested keys (token presence is enough for the structural gate)
+  local required=(platform purpose north_star_metric onboarding_path moderation rituals)
+  local k
+  for k in "${required[@]}"; do
+    grep -Eq "(\"$k\"[[:space:]]*:|^[[:space:]]*$k[[:space:]]*:)" <<<"$body" \
+      || fail "$file is missing required key: $k"
+  done
+
+  # north_star_metric must be non-empty (the no-purpose defect)
+  local nsm
+  nsm="$(grep -E "(\"north_star_metric\"|north_star_metric)[[:space:]]*:" <<<"$body" \
+        | head -n1 | sed -E 's/.*north_star_metric"?[[:space:]]*:[[:space:]]*//' \
+        | tr -d '",' | sed -E 's/^[[:space:]]+//; s/[[:space:]]+$//')"
+  [ -n "$nsm" ] || fail "$file has an empty north_star_metric"
+
+  # moderation must declare all three layers
+  local layer
+  for layer in native bot human; do
+    grep -Eq "(\"$layer\"[[:space:]]*:|^[[:space:]]*$layer[[:space:]]*:)" <<<"$body" \
+      || fail "$file moderation does not declare the '$layer' layer"
+  done
+
+  # at least one ritual with a non-empty cadence
+  grep -Eq "(\"cadence\"|cadence)[[:space:]]*:[[:space:]]*[\"']?[[:alnum:]]" <<<"$body" \
+    || fail "$file has no ritual with a non-empty cadence"
+
+  ok "$file passed all structural checks."
+}
+
+for t in "${targets[@]}"; do
+  check_file "$t"
+done
+
+echo "OK: all ${#targets[@]} artifact(s) verified."
+exit 0

package/skills/competitor-watch/SKILL.md

@@ -0,0 +1,183 @@
+---
+name: competitor-watch
+description: "Use when an already-named set of rivals is watched on a cadence — pricing, features, positioning and changelog diffed into a maintained tracker plus an append-only, classified change log. NOT sizing the market or choosing who the rivals are (that is `market-research`), NOT one-off page extraction (that is `data-scraper`)."
+tags: [competitive-intelligence, monitoring, pricing-tracking, feature-tracking, marketing-ops]
+recommends: [market-research, pricing, sales-pipeline, brand-voice, data-scraper, automation-flows, seo-geo]
+origin: risco
+---
+
+# competitor-watch
+
+You run a **standing watch**, not a one-shot study. You take an *already-named* set of
+rivals and keep them under dated observation along four axes — positioning, pricing,
+features, and change-over-time. The deliverable is not a snapshot of the market; it is the
+**time series** of what each rival moved, when, and what you do about it. Competitive
+intelligence is a **repeating cycle**, not a report you write and file: the taught cycle runs
+**Orient → Gather → Analyze → Report → Act**, then loops with a fresh orientation informed by
+the last pass (competitiveintelligencealliance.io, accessed 2026-06-02).
+
+Two near-misses decide the routing (the rest are in **Handoffs**, below). `../market-research/SKILL.md`
+answers *"what is the market and who is in it"* once, and often **produces the list you watch** —
+you are the downstream loop that watches that list forever. `../data-scraper/SKILL.md` owns the
+generic mechanics of pulling data off a page on demand; you *use* change detection as a means, but
+your identity is the maintained tracker + classified change log + cadence. "Extract this one table
+once" → data-scraper. "Keep watching these five companies" → you.
+
+## Ethics gate — runs FIRST, before any capture
+
+Legitimate CI is **legal + ethical collection from public, observable sources** with your
+identity disclosed. SCIP's Code of Ethics is the industry line (scip.org, accessed 2026-06-02).
+The practical gate is the **front-page test**: would you be comfortable if your collection
+method were reported on the front page of the news? If not, don't do it.
+
+- **Public/observable sources only** — their own site, public filings, trade-show material,
+  published reviews (G2/Capterra), public social. *Why:* anything else is not CI, it's a legal risk.
+- **Never pose as a customer** to extract non-public info (no fake demo requests, no false
+  pretenses, no misrepresenting who you are). *Why:* it's a Code-of-Ethics violation and it taints the data.
+- **Never bypass access controls, paywalls, or rate limits / "no-scrape" terms.** *Why:*
+  circumventing access is the bright line between intelligence and intrusion.
+
+If a request needs any of those, **refuse and reframe to the legal equivalent**: instead of
+"get their internal pricing," watch their *public* pricing page on a cadence and log the moves.
+
+## Ground & scope before you watch anything
+
+1. **Get the competitor list.** If there is none, or it's unvalidated guesswork → STOP and
+   route to `../market-research/SKILL.md`. *Why:* watching the wrong rivals forever is worse
+   than not watching. You are not the one who decides who the competitors are.
+2. **Pick the vital few, then the watch-axes.** The 3–7 rivals that move your roadmap, and only
+   the surfaces (below) that change your decisions. *Why:* watching 30 companies on every axis
+   produces noise nobody reads; depth on the few beats breadth on the many.
+3. **Persist the tracker of record** under `docs/wiki/competitors/` (one profile per rival
+   + a shared change log); keep raw captures under `docs/raw/competitors/`. *Why:* the
+   tracker is a maintained artifact, not a chat answer — it has to live somewhere re-runnable.
+4. **Every price/feature cell carries a `source_url` + `date`, or it stays blank.** *Why:*
+   this is the single highest-value guard against inventing a rival's number. If you didn't
+   see it on a dated public page, you don't know it — leave the cell empty and say so.
+
+```text
+Bad:  Acme Pro tier — $79/mo                          (no source, no date — invented)
+Good: Acme Pro tier — $79/mo  [acme.com/pricing, 2026-05-28]   (seen, sourced, dated)
+```
+
+## Watch-list → config: map each surface
+
+This is the real branch — different surfaces want different cadences and different selector
+types, so the table earns its place. Cadence is tiered by how fast the surface moves: time-
+sensitive surfaces want **5–15 min** checks, general competitor surfaces **hourly–daily**,
+slow/compliance surfaces **daily** (visualping.io / scrapx.io cadence guidance, accessed
+2026-06-02). Over-frequent on a slow page is just cost and noise; under-frequent on pricing is a missed move.
+
+| Axis (surface) | What you watch | Cadence | Selector type |
+|---|---|---|---|
+| Pricing / packaging | the price node, tier names, promo banner | **5–15 min** | CSS on the price element, or JSONPath if pricing comes from an API |
+| Features / changelog | release-notes / "what's new" list | daily | CSS on the release list (first N items) |
+| Positioning / homepage | hero headline + subhead copy | daily–weekly | CSS on the hero text block |
+| Launches / partnerships | press / blog index | daily | CSS on the post list |
+| Careers / hiring | open-roles count + titles | weekly | CSS on the jobs list (signals strategy) |
+| Customer reviews | G2 / Capterra recent reviews | weekly | CSS on the review feed |
+| Social | public profile / posts | daily–weekly | platform-dependent; public only |
+
+That mapping — **URL + selector + cadence per surface** — *is* the monitoring config. Write
+it down as config, don't hold it in your head.
+
+## The change loop
+
+Each pass on a watched URL: **capture → diff vs last → classify → score → log → flag.**
+
+1. **Capture** the watched node (not the whole page — the selector keeps the diff signal-clean).
+2. **Diff** against the last stored capture for that URL.
+3. **Classify** the change into exactly one axis: `pricing | feature | positioning | messaging | team | other`.
+4. **Score materiality**: `high` (changes our roadmap or pricing), `medium` (worth knowing),
+   `low` (cosmetic / noise). *Why:* a diff with no classification and no materiality is noise — it
+   tells you something moved but not whether to care.
+5. **Append a dated change-log row.** Never overwrite; the log is the time series.
+6. **Flag the `high` rows** for action and route them — a price move to whoever owns *our*
+   pricing decision, a feature ship to product. You log and flag; you don't make those calls.
+
+```text
+Bad:  "They changed their website."
+      (no date, no axis, no old/new, no materiality, no action — unactionable)
+
+Good: 2026-05-20 · pricing · Acme · acme.com/pricing
+      Pro tier $49→$59/mo · high · revisit our mid-tier vs theirs
+      (dated, classified, old→new, scored, with a next step)
+```
+
+## The tracker artifacts
+
+Three structured files. Required fields named here; full schema + a filled end-to-end example
+competitor live in `references/tracker-schema.md`. The profile is a `.md` page under the
+`docs/wiki/` OKF v0.1 bundle, so its YAML frontmatter carries a non-empty `type: competitor`
+(plus the OKF-recommended `title`/`description`/`tags`/`timestamp`) alongside the domain keys;
+its body uses standard markdown links, never wikilinks. The two CSVs are data files, not OKF
+documents.
+
+- **Competitor profile** (one per rival): OKF frontmatter (`type: competitor`, …) + the domain
+  keys `name`, `positioning_line`, `segment`, pricing tiers (each with `amount`, `currency`,
+  `source_url`, `date`), feature-matrix rows, watched URLs.
+- **Feature matrix** (CSV): rows = features, columns = competitors, each cell sourced + dated.
+- **Change log** (CSV, append-only): `date,competitor,axis,url,old_value,new_value,materiality,action`.
+
+```csv
+date,competitor,axis,url,old_value,new_value,materiality,action
+2026-05-20,Acme,pricing,https://acme.com/pricing,$49/mo,$59/mo,high,revisit our mid-tier
+2026-05-22,Acme,feature,https://acme.com/changelog,,SSO on Team plan,medium,note for product
+```
+
+## Tooling — what you can actually run
+
+The runnable default is **`changedetection.io`** (open-source, self-hosted): it does text/
+visual / **XPath/CSS-selector** and **JSON-API (JSONPath / jq)** change detection, checks as
+often as ~1 minute, notifies via Slack/Discord/Telegram/email/API, and ships AI change
+summaries like "Price dropped from \$89.99 to \$67.00" (github.com/dgtlmoon/changedetection.io,
+accessed 2026-06-02). Prefer this when you must *produce a config you can run* rather than
+recommend a SaaS. Full docker-compose + per-axis watch recipe is in `references/monitoring-config.md`.
+
+- **The Wayback Machine is an archive, not a monitor.** It captures *some* snapshots (a
+  pricing page may be archived once in months, or never) and **does not tell you when something
+  changed**; its "Changes" diff (added=blue, deleted=yellow) only compares two existing
+  captures (archive.org "Compare two versions", accessed 2026-06-02). Use it to **reconstruct
+  historical positioning**, never as the live alerting layer.
+- **The paid CI-suite tier** exists and sets the feature bar — quote real numbers, don't
+  over-prescribe: Crayon median ≈\$28.7K/yr, Klue ~\$16K–\$42.7K/yr (priced by seats), Kompyte
+  ~\$20K avg ARR (entry from ~\$300/yr), lightweight page-monitors Visualping from ~\$10/mo,
+  ChangeTower from ~\$9/mo (vendr.com, autobound.ai, kompyte.com, accessed 2026-06-02). These
+  auto-update battlecards — but the **battlecard is a sales artifact owned by `../sales-pipeline/SKILL.md`**,
+  not you. A self-host config covers most teams; the suite is overkill until you're tracking
+  many rivals across social + filings 24/7 with a dedicated CI owner.
+- **The recurring run** (cron / webhook scheduling) is wiring, not watching → `../automation-flows/SKILL.md`.
+
+## Handoffs
+
+| Request | Route to |
+|---|---|
+| Size the market, produce/validate the competitor list, TAM/SAM/SOM, buyer/JTBD | `../market-research/SKILL.md` |
+| Set OUR price / packaging / tiers (a decision, not an observation) | `../pricing/SKILL.md` |
+| Build the sales battlecard / objection handling / "why we win" | `../sales-pipeline/SKILL.md` |
+| Define OUR positioning / value prop / messaging | `../brand-voice/SKILL.md` |
+| One-off "extract this page/table once" with no cadence or tracker | `../data-scraper/SKILL.md` |
+| Wire the recurring run as a cron/webhook automation | `../automation-flows/SKILL.md` |
+| Track OUR own SEO / AI-search visibility vs rivals on one page | `../seo-geo/SKILL.md` |
+
+## Anti-patterns
+
+| Anti-pattern | Why it's wrong | Do instead |
+|---|---|---|
+| Treating it as a one-shot study | The value is the delta over time; a snapshot is stale on arrival | Set a cadence, append to a change log every pass |
+| Inventing a rival's price/feature | Unsourced "facts" pollute the tracker and mislead decisions | Every cell gets `source_url` + `date`, or stays blank |
+| Posing as a customer / bypassing a paywall | Fails the front-page test; not CI, it's a legal risk | Public observable sources only; refuse and reframe |
+| Using the Wayback Machine as the live monitor | It doesn't tell you *when* something changed and may never capture the page | Wayback for historical reconstruction only; changedetection.io for live alerts |
+| 5-min cadence on a careers page / weekly on pricing | Over-frequent = noise + cost; under-frequent = a missed move | Tier the cadence by axis volatility (see the table) |
+| Logging a raw diff with no axis/materiality | "Something changed" is unactionable | Classify the axis, score materiality, add a next step |
+| Watching 30 competitors | Breadth produces noise nobody reads | Watch the vital 3–7 that move your roadmap |
+| Building the battlecard inside this skill | That's sales enablement, a different owner | Hand off to `../sales-pipeline/SKILL.md`; you supply the tracker |
+
+## Verify
+
+After you emit a tracker / change log / config, run `scripts/verify.sh` against your project
+docs. Read-only lint: required tracker columns present; **every pricing/feature row has a
+non-empty `source_url` and `date`** (the anti-invention guard); change-log `axis` and
+`materiality` in the allowed sets, with a `url` + `date` on every row; and a **warning** when a
+monitoring-config entry pairs a slow axis with a sub-15-min cadence, or pricing with a
+slower-than-daily one. It exits 0 on an empty/clean target — no false failures.

package/skills/competitor-watch/evals/README.md

@@ -0,0 +1,19 @@
+# Evals — competitor-watch
+
+`cases.yaml` has three blocks. **should_trigger** and **should_not_trigger** are routing
+checks: feed each `prompt` to the router and confirm it selects `competitor-watch` for the
+triggers (including the non-obvious "keep the matrix updated" and "how their positioning
+shifted over 6 months" framings and the Catalan phrasing) and the named real sibling for each
+near-miss — `market-research` (list/sizing), `pricing` (our price), `sales-pipeline` (the
+battlecard), `data-scraper` (one-off extraction), `automation-flows` (scheduling). A near-miss
+passes only when the router prefers the named sibling over `competitor-watch`. The
+**capability** block is an LLM- or human-graded rubric: run the scenario with the skill loaded
+and check the produced plan hits every `must_include` line — ethics gate first, tracker
+persisted under `docs/` with a `source_url`+`date` on every price/feature cell (no invented
+numbers), each surface mapped to URL+selector+tiered cadence, the change-log axis+materiality
+schema, `changedetection.io` as the runnable default with Wayback flagged as archive-only, and
+the handoffs to automation-flows and sales-pipeline. There is no automated runner and no live
+network call — the agent produces the tracker, watch config, and change-loop process as
+artifacts; grade by reading the output against the list, or wire it into your eval harness of
+choice. `scripts/verify.sh` separately lints an emitted tracker/change-log for sourcing and
+schema (see its header).

package/skills/competitor-watch/evals/cases.yaml

@@ -0,0 +1,54 @@
+skill: competitor-watch
+
+# Prompts that MUST load `competitor-watch`. The skill owns the STANDING WATCH over a
+# named set of rivals: a maintained tracker (pricing/features/positioning), a classified
+# change log over time, and the monitoring config (URL + selector + cadence). It does NOT
+# size the market or build the list (market-research), set our price (pricing), build the
+# sales battlecard (sales-pipeline), or do a one-off extraction (data-scraper).
+should_trigger:
+  - prompt: "Set up monitoring on our top 3 competitors' pricing and feature pages."
+    why: "Core watch: named set, watched surfaces, ongoing cadence — the skill's whole job."
+
+  - prompt: "Did Competitor X change their pricing or ship anything new this month?"
+    why: "Change-loop ask — capture, diff, classify the move, report what changed over a period."
+
+  - prompt: "Build a feature comparison matrix versus our rivals and keep it updated."
+    why: "Non-obvious: reads like a one-off table, but 'keep it updated' makes it the maintained matrix + change log, not a snapshot."
+
+  - prompt: "monitoritza els competidors i avisa'm quan canviïn de preu."
+    why: "Catalan: monitor competitors and alert me on price changes — the watch loop with notification, phrased without the skill name."
+
+  - prompt: "Track how their positioning has shifted over the last 6 months."
+    why: "Non-obvious time-series framing — no 'monitor/competitor' keyword in the obvious slot, but it's the dated change-over-time the skill produces (Wayback reconstruction + change log)."
+
+should_not_trigger:
+  - prompt: "How big is this market and who are the main players we should worry about?"
+    route_to: market-research
+    why: "Sizing the market and producing the landscape/list is upstream; competitor-watch watches an already-named set, it doesn't build the list."
+
+  - prompt: "What price should we charge for our new mid-tier plan?"
+    route_to: pricing
+    why: "Setting OUR price is a decision, not an observation of a rival; pricing owns it."
+
+  - prompt: "Write the sales battlecard for beating Competitor X on calls."
+    route_to: sales-pipeline
+    why: "The sales-enablement battlecard / objection handling is a sales artifact; competitor-watch only supplies the tracker behind it."
+
+  - prompt: "Scrape this one page and give me the table once."
+    route_to: data-scraper
+    why: "A one-off extraction with no cadence, tracker, or change log — that's the generic scraping primitive, not the standing watch."
+
+  - prompt: "Schedule the competitor monitor to run every morning and post to Slack via webhook."
+    route_to: automation-flows
+    why: "Cron/webhook scheduling and reliable delivery is automation wiring; competitor-watch defines the watches, automation-flows makes them run."
+
+capability:
+  - scenario: "We have a validated list of 3 competitors. Set up a competitor watch: the tracker of record, the watch config, and a repeatable change-loop process."
+    must_include:
+      - "Applies the ethics gate first: public/observable sources only, transparent identity, the front-page test; never pose as a customer or bypass access controls/paywalls."
+      - "Persists the tracker under docs/ (wiki/competitors + raw/competitors) as a maintained artifact, not a chat answer — or STOPs and routes to market-research if the list were not validated."
+      - "Requires a source_url + date on every price/feature cell and refuses to invent a rival's number (blank cell when unconfirmed)."
+      - "Maps each watched surface to URL + selector + tiered cadence: pricing 5-15 min, features/changelog daily, positioning/careers daily-weekly."
+      - "Defines the change-log schema with axis classification (pricing|feature|positioning|messaging|team|other) and materiality (high|medium|low), append-only over time."
+      - "Recommends changedetection.io (CSS/JSONPath selectors, ~1-min capable, notify) as the runnable default and flags the Wayback Machine as archive-only, not a live monitor."
+      - "Routes the recurring run to automation-flows and the battlecard to sales-pipeline; does not build either inside this skill."

package/skills/competitor-watch/references/monitoring-config.md

@@ -0,0 +1,124 @@
+# Monitoring config: the runnable stack
+
+The default you can actually run is **`changedetection.io`** — open-source, self-hosted, no
+vendor lock-in. It does text/visual, **XPath/CSS-selector**, and **JSON-API (JSONPath / jq)**
+change detection; checks as often as ~1 minute; notifies via Slack/Discord/Telegram/email/API;
+and ships AI change summaries like "Price dropped from \$89.99 to \$67.00"
+(github.com/dgtlmoon/changedetection.io, accessed 2026-06-02).
+
+## Self-host: docker-compose
+
+```yaml
+# docker-compose.yml — changedetection.io + a Playwright fetcher for JS-heavy pages
+services:
+  changedetection:
+    image: ghcr.io/dgtlmoon/changedetection.io
+    container_name: changedetection
+    ports:
+      - "5000:5000"
+    volumes:
+      - ./datastore:/datastore
+    environment:
+      - PLAYWRIGHT_DRIVER_URL=ws://playwright-chrome:3000
+      - BASE_URL=https://watch.internal.example.com
+    restart: unless-stopped
+  playwright-chrome:
+    image: dgtlmoon/sockpuppetbrowser:latest
+    container_name: playwright-chrome
+    restart: unless-stopped
+```
+
+Bring it up with `docker compose up -d`, open `http://localhost:5000`, and add one watch per
+watched URL from the competitor profile.
+
+## Per-axis watch definitions
+
+Each watch = URL + selector + cadence. Map straight from the watch-list table in `SKILL.md`.
+
+```text
+# Pricing (time-sensitive → 5–15 min)
+URL:       https://acme.com/pricing
+Filter:    css:.price-amount          # CSS selector for the price node only
+Cadence:   00:10:00                   # 10 minutes
+Notify:    tgram://<token>/<chat_id>  # Telegram on change
+
+# Features / changelog (daily)
+URL:       https://acme.com/changelog
+Filter:    css:.changelog li:nth-child(-n+5)   # first 5 release items
+Cadence:   1 day
+
+# Positioning / homepage (weekly)
+URL:       https://acme.com
+Filter:    css:h1.hero-title, css:.hero-subtitle
+Cadence:   7 days
+```
+
+### JSON-API pricing (when price comes from an endpoint, not HTML)
+
+If the pricing page hydrates from an API, watch the API and pin the exact field with JSONPath
+— far more stable than scraping rendered HTML.
+
+```text
+URL:       https://acme.com/api/v2/plans
+Filter:    json:$.plans[?(@.id=='pro')].monthly_price
+Cadence:   00:10:00
+```
+
+### AI change summary (optional)
+
+changedetection.io can attach an LLM that turns a raw diff into one line ("Pro monthly went
+from \$49 to \$59"). Enable it per-watch when the page is noisy and you want the classification
+pre-chewed — but you still own the axis + materiality call; the summary is an input, not the log.
+
+## Notification wiring
+
+Point the notify URL at where your team already lives. Common targets:
+
+```text
+tgram://<bot_token>/<chat_id>          # Telegram
+slack://<token_a>/<token_b>/<token_c>  # Slack
+discord://<webhook_id>/<webhook_token> # Discord
+post://watch.internal.example.com/hook # your own webhook → automation-flows
+```
+
+The *scheduling and downstream routing* of those webhooks (cron, retries, fan-out into a
+tracker write) is automation wiring → `../automation-flows/SKILL.md`. This skill defines the
+watches; that skill makes them run reliably on a schedule.
+
+## Wayback Machine — historical reconstruction ONLY
+
+The Wayback Machine is a **passive archive, not a monitor**. It captures *some* snapshots (a
+pricing page may be archived once in months, or never) and **does not tell you when something
+changed**. Use it to reconstruct what a rival's page said in the past — never as the live
+alerting layer.
+
+Its "Changes" diff compares two existing captures (added = blue, deleted = yellow):
+
+```text
+# Compare two captured timestamps of the same URL
+https://web.archive.org/web/diff/<TS1>/<TS2>/https://acme.com/pricing
+# e.g. TS = 20260101000000 (YYYYMMDDhhmmss)
+https://web.archive.org/web/diff/20260101000000/20260501000000/https://acme.com/pricing
+```
+
+(archive.org "Compare two versions", accessed 2026-06-02.) Good for "how did their positioning
+read 6 months ago"; useless for "alert me when it changes."
+
+## Self-host vs paid SaaS — when each is the right call
+
+| Option | Price (accessed 2026-06-02) | Right call when |
+|---|---|---|
+| **changedetection.io** (self-host) | free / infra cost only | Default. You want a config you run, full selector control, no vendor. |
+| Visualping | from ~\$10/mo | A few pages, want zero ops, visual diffs. |
+| ChangeTower | from ~\$9/mo | Same — lightweight page monitor, hosted. |
+| Kompyte | ~\$20K avg ARR (entry ~\$300/yr, 1–2wk setup) | You need site+social+filings 24/7 and a dedicated CI owner. |
+| Crayon | median ≈\$28.7K/yr (~\$12K–\$47K, 7–8wk setup) | Many rivals, auto-updated battlecards, priced by # competitors. |
+| Klue | ~\$16K–\$42.7K/yr (Basic/Standard/Premium, by seats) | Large CI team splitting "curators" vs "consumers." |
+
+(vendr.com/marketplace/crayon, autobound.ai "Top 15 CI tools 2026", kompyte.com comparison,
+visualping.io — accessed 2026-06-02.)
+
+The paid suites also auto-update **battlecards** — but the battlecard itself is a sales
+artifact owned by `../sales-pipeline/SKILL.md`, not this skill. A self-host config covers most
+teams; reach for a suite only when breadth (many rivals, many surfaces, 24/7) outgrows what one
+config + one owner can maintain.