@damiangilgonzalez/harness 1.3.7

package/skills/linkedin-outreach/SKILL.md

@@ -0,0 +1,154 @@
+---
+name: linkedin-outreach
+description: "Use when running LinkedIn social selling as a repeatable motion — Sales Navigator saved searches and trigger alerts, weekly request budgets, fixing a low acceptance rate, turning profile views and post engagers into warm threads, logging every touch. NOT the note or DM copy (that is `cold-outreach`), NOT the deal after a reply (that is `sales-pipeline`)."
+tags: [linkedin, social-selling, sales-navigator, outreach, pipeline]
+recommends: [cold-outreach, lead-gen, sales-pipeline, linkedin-strategy, linkedin-content]
+origin: risco
+---
+
+# Linkedin Outreach — The Loop and Its Ledger
+
+*You run the LinkedIn social-selling motion and keep its score: **who** to touch, **when**, through **what** warm-up, and **how** the loop is run and logged. The thesis is warm-first — engagement before connection, signal before send, ledger before "I'll remember it." The output is a running system plus a touch ledger under `docs/`, never a finished line of copy: when prose is needed you write the brief and hand it off, then stay in the loop.*
+
+## Boundary
+
+The sharpest line is against `../cold-outreach/SKILL.md`, and it splits on message-vs-system:
+
+- **A single message** — the connection note (≤300 chars), the DM bump, its wording and per-inbox send cadence → cold-outreach. If the ask is "write this" or "fix this template," it is not yours.
+- **The system** — who to touch, when, the warm-up, the budget, the ledger → here. When both are in play, this skill drives and delegates the copy.
+
+Also not yours: sourcing / scoring the raw prospect list and ICP definition → `../lead-gen/SKILL.md`; the deal after a reply, i.e. stages, forecast, CRM tasks → `../sales-pipeline/SKILL.md`; writing or scheduling LinkedIn *posts* → `../linkedin-content/SKILL.md`; brand growth and positioning → `../linkedin-strategy/SKILL.md`.
+
+## The loop
+
+Five phases, in order. Each has a *why* and yields one artifact; the artifact gates the next phase. Skipping a phase is how acceptance collapses.
+
+1. **Target** — *why:* outreach timed to a reason beats outreach timed to a calendar. → Yields a Sales Nav saved search + trigger alerts (job change, funding, recent post).
+2. **Warm** — *why:* a cold, context-free request is the worst-accepting move you can make; engaging first is what fixes it. → Yields a logged pre-touch (profile view + one genuine comment/like 1–2 days prior).
+3. **Connect** — *why:* the request is the smallest, most rate-limited move; spend it deliberately. → Yields a sent request inside the weekly budget, note-or-no-note chosen by goal.
+4. **Convert** — *why:* an accept is not a conversation; the choreography turns a signal into a warm 1:1. → Yields a thread with a real reply, copy delegated to cold-outreach when needed.
+5. **Log** — *why:* a motion you can't measure you can't repeat or fix. → Yields a row in the `docs/` ledger with the outcome.
+
+Each phase gets a section below; the last one compresses all five into a day.
+
+## Target with Sales Navigator
+
+Build the saved search from the ICP, not from a name list:
+
+- **Filters that matter:** geography, current job title (use the title field, not keywords, to avoid past-role noise), seniority, company headcount, industry, and `Posted on LinkedIn in past 30 days` (active profiles accept and reply far more). Save it; Sales Nav re-runs it and surfaces new matches.
+- **Trigger alerts worth turning on:** *changed jobs in last 90 days* (new role = new budget, new pain), *company funding events*, and *posted recently* (a fresh post is your warm-up hook). Time the request to a trigger, never to a Tuesday.
+- **InMail reality:** Core and Advanced both ship **50 InMail credits/mo**, rolling over up to 3 months (max 150 accumulated); an InMail that gets a reply within 90 days is **credited back**. Spend InMail on out-of-network leads where a connection request can't reach — not on people you could warm up and connect to for free.
+
+Free vs Core vs Advanced — buy on the job, not the brand:
+
+| You need | Tier | 2025 price | Why |
+| --- | --- | --- | --- |
+| Run the loop on a tight ICP, manual budget | Free | $0 | Works if you stay disciplined; no saved-search alerts. |
+| Saved searches, 40+ filters, lead/account alerts, 50 InMail/mo | Core | $119.99/mo ($1,079.88/yr) | The default for a working social seller. |
+| + TeamLink, Smart Links, buyer-intent, Account/Lead IQ, CRM sync | Advanced | $159.99/mo ($1,799.88/yr) | Only when a team or CRM sync is real. |
+
+Filter recipes per ICP, trigger-alert setup, and the full Core-vs-Advanced buy math → `references/sales-navigator-playbook.md`.
+
+## The connection motion
+
+**Engagement-before-connect ritual.** 1–2 days before the request: view the profile, follow the company page, and drop **one genuine** comment or like on a recent post. This is what moves acceptance from ~20–30% (cold) to ~60%+. Log the pre-touch — it is phase 2, not optional flavor.
+
+**Note or no note — read the paradox correctly.** A personalized note barely moves *acceptance* (26.42% with vs 26.37% without; some 2025/26 datasets show no-note accepting *higher*). But a note with real context nearly **doubles the post-accept reply rate** (9.36% vs 5.44%). So decide by goal:
+
+| Your goal | Note? | Why |
+| --- | --- | --- |
+| Maximize the **accept** (build network, retarget later) | No note (or near-empty) | Notes don't lift acceptance; an empty request often accepts as well or better. |
+| Maximize the **reply** after accept | Short context note | Real context roughly doubles reply; worth the friction only when you have a true hook. |
+| No genuine hook exists | No note | A generic note is worse than none — it reads as a pitch. |
+
+When you do send a note, you do **not** write it here — hand the brief (the hook, the person, the goal) to `../cold-outreach/SKILL.md`.
+
+**Weekly request budget — the cap is a rolling weekly limit, not a daily reset.**
+
+| Account | Realistic weekly cap | Daily target | Health rule |
+| --- | --- | --- | --- |
+| Free | ~100/wk | ~20/weekday, stay under ~80/wk | Pause and warm more if acceptance drops below ~30%. |
+| Premium / Sales Nav | up to ~200/wk | up to ~40/day | Only with strong SSI and acceptance >40%; otherwise treat as free. |
+
+Over the cap, requests get throttled or the account flagged. Below ~30% acceptance you are spraying — go back to phase 2 instead of pushing volume, and withdraw stale pending requests before they pile up.
+
+## Engagement → conversation
+
+A signal is an opening. Match the signal to a play; the play is choreography (timing, sequence, what to reference), never finished prose.
+
+| Signal | Play | Copy? |
+| --- | --- | --- |
+| Connection just accepted | Wait, don't pitch. Reference *why* you reached out (their post/role/trigger), ask one genuine question. | Brief → cold-outreach |
+| Profile viewer (they viewed you) | Soft, warm reply: "Saw you stopped by — noticed [their thing], curious how you handle X?" | Brief → cold-outreach |
+| Post engager (liked/commented your post) | Thank or build on their comment, then DM a related question tied to their work. | Brief → cold-outreach |
+| Comment thread (they engaged a third party's post) | Add value in-thread first, connect with that context the next day. | Brief → cold-outreach |
+
+Worked example — the move, not the words:
+
+```text
+Bad  (pitch-on-accept):
+  Accepted → "Thanks for connecting! We help teams like yours cut reporting
+  time 40% with our analytics platform — open to a 15-min demo Thursday?"
+  Reads as a trap; reply rate craters.
+
+Good (reference-then-ask):
+  Accepted → "Appreciate the connect — your post on attribution gaps in
+  ecommerce hit home. How are you splitting paid vs organic credit right now?"
+  Opens a real thread; the product never comes up until they ask.
+```
+
+## Hand off to pipeline
+
+You run the loop up to a **warm intro or a booked call** — then you stop and hand off.
+
+Buying-signal tells in a thread: they ask about price/timeline, mention an active project or pain, reference budget or a decision date, or say "send me more." When you see one:
+
+1. Book the call or send the warm intro.
+2. Log the outcome (`call_booked`) in the ledger.
+3. Hand the thread + context to `../sales-pipeline/SKILL.md` — the moment a deal exists it is theirs, and you set no stages or forecasts.
+
+## The ledger (docs)
+
+One file. Path: `docs/linkedin-outreach/touches.csv`. The header row is fixed (verify.sh checks it verbatim):
+
+```csv
+date,name,profile_url,channel,trigger,action,stage,outcome,next_touch
+```
+
+- `channel`: `connect` | `inmail` | `dm` | `comment` | `view`.
+- `outcome` (enum, no blanks): `requested` | `accepted` | `replied` | `conversation` | `call_booked` | `dead`.
+- Never leave a literal merge token (`{first_name}`, `[company]`, `XXXX`, `TODO`) in a cell — verify.sh fails on it.
+
+Full column spec, the outcome enum, a filled 5-row example, and the weekly-review formulas → `references/ledger-schema.md`.
+
+**Weekly review ritual** (15 min, same day each week). Compute from the ledger:
+
+- **Acceptance %** = accepted ÷ requested.
+- **Post-accept reply %** = replied ÷ accepted.
+- **Conversations → calls %** = call_booked ÷ conversation.
+- **Touches/week** = rows added this week (is the loop actually running?).
+
+If acceptance < ~30%, warm harder (phase 2). If reply < ~10%, your hooks are weak (better brief to cold-outreach). If touches/week is near zero, the loop stopped — that's the real failure.
+
+## Anti-patterns
+
+| Bad | Why it bites | Do instead |
+| --- | --- | --- |
+| Spray connection requests over the cap | Rolling weekly limit; throttled or account-flagged | Stay under ~80/wk free, ~200 Premium with >40% accept |
+| Pitch the instant a connection accepts | Reads as a trap; reply rate craters | Reference their context, ask one real question first |
+| Automation that ignores the rolling limit | Bursts trip LinkedIn's detection; account at risk | Pace within the budget; warm-up beats volume |
+| Read "notes don't help" as "context never helps" | Notes don't lift *accept*, but context doubles *reply* | Decide note by goal: accept→none, reply→context |
+| Chase SSI as the goal | SSI is a lagging proxy; high SSI ≠ pipeline | Track acceptance/reply/calls; let SSI follow |
+| Run outreach with no ledger | No measurement → no repeatable motion | Log every touch + outcome to `docs/` |
+
+## Daily 30-minute routine
+
+Run this as a checklist; it is the loop compressed into a day.
+
+- [ ] **Engage (10 min):** comment genuinely on 5–8 posts from your saved search and from people you plan to connect with this week (phase 2 warm-up bank).
+- [ ] **Connect (5 min):** send today's requests from the saved search / trigger alerts, inside the weekly budget; note-or-no-note by goal (phase 3).
+- [ ] **Convert (10 min):** progress 2–3 warm threads — accepted connections, profile viewers, post engagers — using the signal→play table; delegate any copy to cold-outreach.
+- [ ] **Hand off (2 min):** any buying signal → book/intro, then route to sales-pipeline.
+- [ ] **Log (3 min):** write every touch and outcome to `docs/linkedin-outreach/touches.csv`.
+
+Weekly, run the review ritual and adjust the next week's targeting. That closes the loop back to phase 1.

package/skills/linkedin-outreach/evals/README.md

@@ -0,0 +1,3 @@
+# Evals — linkedin-outreach
+
+These cases are read by the catalog's routing harness (or by hand); there is no bundled runner. `should_trigger` asserts the SKILL.md description + body are specific enough that the listed prompt loads `linkedin-outreach`. `should_not_trigger` asserts a near-miss prompt routes to the named real sibling instead (each `route_to` id — `cold-outreach`, `lead-gen`, `sales-pipeline`, `linkedin-content`, `linkedin-strategy` — exists in the catalog). `capability` is a rubric: feed the scenario to an agent with this skill loaded and grade the generated motion against every `must_include` bullet (each is pass/fail). To sanity-check a *generated ledger* against the schema and placeholder banlist, run `../scripts/verify.sh path/to/touches.csv` from this directory — it is read-only, defaults to `docs/linkedin-outreach/touches.csv`, and exits 0 cleanly when no ledger exists yet.

package/skills/linkedin-outreach/evals/cases.yaml

@@ -0,0 +1,43 @@
+skill: linkedin-outreach
+
+should_trigger:
+  - prompt: "Set up a Sales Navigator saved search for Series-B fintech RevOps leaders and alert me on job changes."
+    why: Core targeting phase — saved search + trigger alerts, the spine of the loop.
+  - prompt: "My LinkedIn acceptance rate is about 15%. How do I run my connection requests so people actually accept?"
+    why: Non-obvious — names a metric, not the skill; routes to engagement-before-connect + the weekly budget rules.
+  - prompt: "Build me a 30-minute-a-day social-selling routine that turns LinkedIn into pipeline."
+    why: The loop plus the daily checklist — the motion, not any message.
+  - prompt: "Turn everyone who engaged with my last post into a conversation, and log who I've touched."
+    why: Engagement-to-conversation play plus the docs ledger.
+  - prompt: "Someone just viewed my profile and another person liked my post — what's the play?"
+    why: Non-obvious signal-to-play question; the choreography, never the finished copy.
+  - prompt: "Munta'm una rutina de social selling a LinkedIn i porta'm un registre dels contactes."
+    why: Catalan — the loop plus the ledger.
+
+should_not_trigger:
+  - prompt: "Write the actual connection note and the DM bump for these 5 prospects."
+    route_to: cold-outreach
+    why: The message copy and its send cadence, not the motion — the sharpest near-miss.
+  - prompt: "Find me 200 SaaS CTOs with verified profiles to target."
+    route_to: lead-gen
+    why: Sourcing and scoring the raw prospect list.
+  - prompt: "A prospect replied 'interested' — set the deal stage and my follow-up tasks."
+    route_to: sales-pipeline
+    why: Running the deal after the reply.
+  - prompt: "Write and schedule my next 4 LinkedIn posts."
+    route_to: linkedin-content
+    why: Publishing content, not 1:1 outreach.
+  - prompt: "Define my overall LinkedIn positioning and growth strategy for the year."
+    route_to: linkedin-strategy
+    why: Brand growth/positioning, not the outreach loop.
+
+capability:
+  - scenario: "I sell a $20k analytics tool to ecommerce ops leads. Set up my LinkedIn social-selling motion end to end."
+    must_include:
+      - Defines a Sales Navigator saved search with concrete filters plus trigger alerts (job change / funding / recent post).
+      - Specifies the engagement-before-connect ritual (view + one genuine comment/like 1–2 days prior) and the acceptance lift it buys.
+      - Gives a note-or-no-note decision tied to the acceptance-vs-reply goal (the note paradox).
+      - States the weekly connection-request budget and at least one health rule (rolling cap, pause if acceptance drops).
+      - Defines the docs ledger path and its columns.
+      - Delegates the actual message copy to cold-outreach.
+      - Names the pipeline handoff point (booked call / warm intro → sales-pipeline).

package/skills/linkedin-outreach/references/ledger-schema.md

@@ -0,0 +1,48 @@
+# Ledger schema
+
+The touch/outcome ledger is the artifact `scripts/verify.sh` checks. One file:
+`docs/linkedin-outreach/touches.csv`.
+
+## Header (verbatim — verify.sh asserts this exact row)
+
+```csv
+date,name,profile_url,channel,trigger,action,stage,outcome,next_touch
+```
+
+## Columns
+
+| Column | Type | Notes |
+| --- | --- | --- |
+| `date` | ISO date `YYYY-MM-DD` | The day of the touch. |
+| `name` | text | The person. |
+| `profile_url` | URL | LinkedIn profile (de-dupe key). |
+| `channel` | enum | `connect` \| `inmail` \| `dm` \| `comment` \| `view`. |
+| `trigger` | text | The reason you touched: `job_change`, `funding`, `post:<topic>`, `viewed_me`, `referral`. |
+| `action` | text | What you did this touch (e.g. `commented on launch post`, `sent request no-note`). |
+| `stage` | text | Free-text loop stage: `warm`, `requested`, `in_thread`, `handed_off`. |
+| `outcome` | enum (no blanks) | `requested` \| `accepted` \| `replied` \| `conversation` \| `call_booked` \| `dead`. |
+| `next_touch` | ISO date or empty | When to follow up; empty allowed only for terminal outcomes (`call_booked`, `dead`). |
+
+No cell may contain a literal merge token or placeholder (`{first_name}`, `[company]`, `XXXX`, `TODO`) — verify.sh fails on it.
+
+## Filled example
+
+```csv
+date,name,profile_url,channel,trigger,action,stage,outcome,next_touch
+2026-05-26,Marta Ruiz,https://linkedin.com/in/martaruiz,comment,post:attribution,liked + commented on her attribution post,warm,replied,2026-05-28
+2026-05-28,Marta Ruiz,https://linkedin.com/in/martaruiz,connect,post:attribution,sent request no-note,requested,accepted,2026-05-30
+2026-05-30,Marta Ruiz,https://linkedin.com/in/martaruiz,dm,post:attribution,referenced post asked how she splits paid vs organic,in_thread,conversation,2026-06-02
+2026-05-27,Tom Lai,https://linkedin.com/in/tomlai,inmail,job_change,InMail congratulating new RevOps role,requested,accepted,2026-05-30
+2026-06-01,Tom Lai,https://linkedin.com/in/tomlai,dm,job_change,he asked for pricing — booked 20-min call,handed_off,call_booked,
+```
+
+## Weekly-review formulas
+
+Compute over the rows for the period:
+
+- **Acceptance %** = `count(outcome in {accepted,replied,conversation,call_booked}) / count(outcome in {requested,...})` — i.e. accepted-or-better ÷ all requests sent.
+- **Post-accept reply %** = `count(replied|conversation|call_booked) / count(accepted-or-better)`.
+- **Conversations → calls %** = `count(call_booked) / count(conversation|call_booked)`.
+- **Touches/week** = rows whose `date` falls in the week.
+
+Thresholds to act on: acceptance < ~30% → warm harder (phase 2). Reply < ~10% → weak hooks, write a better brief for cold-outreach. Touches/week ≈ 0 → the loop stopped, the real failure.

package/skills/linkedin-outreach/references/sales-navigator-playbook.md

@@ -0,0 +1,61 @@
+# Sales Navigator playbook
+
+Offloaded depth for the **Target** phase. All facts dated 2026-06-02.
+
+## Saved-search filter recipes by ICP archetype
+
+Build from the role and the trigger, not from a name dump. Save the search so Sales Nav re-runs it and surfaces new matches.
+
+| ICP archetype | Core filters to set | Why these |
+| --- | --- | --- |
+| RevOps / Sales Ops leaders at scaling SaaS | Current title = "RevOps", "Sales Operations" (title field, not keyword) · seniority = Manager–VP · headcount 51–500 · `Posted in past 30 days` | Title field avoids matching people who *used to* hold the role; headcount band targets the buy-window. |
+| Ecommerce ops / growth leads | Title = "Ecommerce", "Growth", "DTC" · industry = Retail/Consumer · geography = your serviceable region · `Changed jobs in 90 days` | Job change = new mandate and fresh budget. |
+| Founders / GTM at funded startups | Seniority = Owner/Partner/CXO · `Company funding events` alert on · headcount 11–200 | Funding is the cleanest timing trigger. |
+
+Rule: always add `Posted on LinkedIn in past 30 days`. Active profiles accept and reply at materially higher rates than dormant ones, and a recent post is your warm-up hook.
+
+## Trigger-alert setup
+
+Sales Nav lead/account alerts you should turn on (Core and Advanced):
+
+- **Changed jobs in last 90 days** — new role means new pain and new budget; reach out in the first weeks.
+- **Company funding events** — timing trigger; pair with a relevant, non-salesy congratulations-then-question.
+- **Posted recently** — the post is the thing you engage with in phase 2 before sending the request.
+
+Each alert is a *reason to touch*. Never send a request that can't name its trigger.
+
+## InMail credit economics
+
+- Both Core and Advanced ship **50 InMail credits per month**.
+- Unused credits **roll over up to 3 months** (max **150** accumulated).
+- An InMail that receives a reply **within 90 days** is **credited back** — so a well-targeted InMail can be effectively free.
+
+When InMail beats a connection request:
+
+- The lead is **out of network** and a connection request would sit unseen, or
+- You have **one shot** at a senior buyer and want the longer message format, or
+- The trigger is hot (funding, job change) and you can't afford the 1–2 day warm-up window.
+
+Otherwise prefer the free path: warm up, then send a connection request. InMail credits are scarce; spend them where free reach can't go.
+
+## Advanced-only levers
+
+- **TeamLink** — surfaces warm paths through your colleagues' networks; turns a cold touch into a referral.
+- **Smart Links** — trackable content bundles; you see who opened and how far they read (a buyer-intent signal feeding phase 4).
+- **Buyer-intent signals + Account IQ / Lead IQ** — account-level intent and auto-summaries; useful only at team scale.
+- **CRM sync** — writes activity to the CRM; relevant once sales-pipeline owns the deal.
+
+## Core vs Advanced buy decision (2025 prices)
+
+| | Free | Core | Advanced |
+| --- | --- | --- | --- |
+| Price | $0 | $119.99/mo ($1,079.88/yr) | $159.99/mo ($1,799.88/yr) |
+| 40+ search filters | – | yes | yes |
+| Saved searches + lead/account alerts | – | yes | yes |
+| 50 InMail/mo (rollover→150, reply-refund) | – | yes | yes |
+| Extended profile view | – | yes | yes |
+| TeamLink / Smart Links / buyer-intent / IQ / CRM sync | – | – | yes |
+
+Decision: **Free** if you'll stay disciplined on a tight ICP and don't need alerts. **Core** is the default for a solo working social seller — it pays for itself on saved-search alerts and InMail. **Advanced** only when a team needs TeamLink or a real CRM sync exists; do not buy it for features you won't operate.
+
+*(Sources: business.linkedin.com/sales-solutions/compare-plans; topo.io 2025 price guide; hyperclapper.com Core vs Advanced — accessed 2026-06-02.)*

package/skills/linkedin-outreach/scripts/verify.sh

@@ -0,0 +1,120 @@
+#!/usr/bin/env bash
+#
+# verify.sh — structural guardrail for a LinkedIn-outreach touch ledger.
+#
+# WHAT IT DOES (read-only; never edits or writes a file)
+#   Static, network-free checks over ONE ledger CSV:
+#     1. Header row must equal the required columns EXACTLY:
+#        date,name,profile_url,channel,trigger,action,stage,outcome,next_touch
+#        -> FAIL if it differs.
+#     2. Every data row's `outcome` (column 8) must be in the allowed enum
+#        {requested, accepted, replied, conversation, call_booked, dead}
+#        -> FAIL on any blank or out-of-enum value.
+#     3. No cell may carry a placeholder / merge token:
+#        a "{...}" merge field, a "[...]" slot, "XXXX", or "TODO" -> FAIL.
+#
+#   A missing ledger OR an empty / header-only file exits 0 with a notice
+#   (the skill can be used advisorily before any ledger exists) — never a
+#   false failure.
+#
+# HOW TO RUN (inside YOUR project, not the skills repo)
+#   ./verify.sh                                  # default docs/linkedin-outreach/touches.csv
+#   ./verify.sh path/to/touches.csv              # explicit path
+#
+# EXIT CODES
+#   0  clean, or no ledger / empty ledger to check
+#   1  a structural failure (bad header, bad outcome, or placeholder token)
+#   2  bad usage (path given but is a directory)
+#
+# Runs on stock macOS bash 3.2: no mapfile, no associative arrays.
+
+set -euo pipefail
+
+if [ -t 1 ]; then
+  RED=$'\033[31m'; GREEN=$'\033[32m'; YELLOW=$'\033[33m'; NC=$'\033[0m'
+else
+  RED=''; GREEN=''; YELLOW=''; NC=''
+fi
+
+fail_count=0
+ok()   { printf '%s[ ok ]%s %s\n' "$GREEN"  "$NC" "$*"; }
+warn() { printf '%s[warn]%s %s\n' "$YELLOW" "$NC" "$*"; }
+fail() { printf '%s[fail]%s %s\n' "$RED"    "$NC" "$*"; fail_count=$((fail_count + 1)); }
+
+FILE="${1:-docs/linkedin-outreach/touches.csv}"
+HEADER='date,name,profile_url,channel,trigger,action,stage,outcome,next_touch'
+
+if [ -d "$FILE" ]; then
+  printf '%susage: %s [path/to/touches.csv]%s\n' "$RED" "$0" "$NC"
+  exit 2
+fi
+
+if [ ! -f "$FILE" ]; then
+  warn "no ledger at '$FILE' — nothing to verify (advisory use is fine)"
+  exit 0
+fi
+
+# Strip a possible trailing CR (CRLF files) when reading rows.
+ROW_COUNT="$(awk 'NF{c++} END{print c+0}' "$FILE")"
+if [ "$ROW_COUNT" -eq 0 ]; then
+  warn "ledger '$FILE' is empty — nothing to verify"
+  exit 0
+fi
+
+# --- 1. header row exact match ------------------------------------------------
+ACTUAL_HEADER="$(awk 'NR==1{sub(/\r$/,""); print; exit}' "$FILE")"
+if [ "$ACTUAL_HEADER" = "$HEADER" ]; then
+  ok "header row matches the required schema"
+else
+  fail "header row mismatch"
+  printf '       expected: %s\n' "$HEADER"
+  printf '       found:    %s\n' "$ACTUAL_HEADER"
+fi
+
+DATA_ROWS="$(awk 'NR>1 && NF{c++} END{print c+0}' "$FILE")"
+if [ "$DATA_ROWS" -eq 0 ]; then
+  warn "header-only ledger — no data rows to check yet"
+  printf '\n'
+  if [ "$fail_count" -gt 0 ]; then
+    printf '%s%d failure(s)%s\n' "$RED" "$fail_count" "$NC"; exit 1
+  fi
+  printf '%sall checks passed%s\n' "$GREEN" "$NC"; exit 0
+fi
+
+# --- 2. outcome enum (column 8) -----------------------------------------------
+BAD_OUTCOME="$(awk -F',' '
+  NR>1 && NF>0 {
+    o=$8; gsub(/\r/,"",o); gsub(/^[ \t]+|[ \t]+$/,"",o);
+    allowed="requested accepted replied conversation call_booked dead";
+    if (index(" " allowed " ", " " o " ") == 0) print NR": \""o"\"";
+  }' "$FILE")"
+if [ -n "$BAD_OUTCOME" ]; then
+  while IFS= read -r line; do
+    [ -n "$line" ] && fail "row $line — outcome not in {requested,accepted,replied,conversation,call_booked,dead}"
+  done <<EOF
+$BAD_OUTCOME
+EOF
+else
+  ok "every data row has a valid outcome"
+fi
+
+# --- 3. placeholder / merge-token banlist -------------------------------------
+PLACEHOLDERS="$(grep -nE '\{[^}]*\}|\[[^]]*\]|XXXX|TODO' "$FILE" 2>/dev/null || true)"
+if [ -n "$PLACEHOLDERS" ]; then
+  while IFS= read -r line; do
+    [ -n "$line" ] && fail "placeholder/merge token present at line ${line%%:*} — fill before logging"
+  done <<EOF
+$PLACEHOLDERS
+EOF
+else
+  ok "no placeholder / merge tokens in any cell"
+fi
+
+# --- summary ------------------------------------------------------------------
+printf '\n'
+if [ "$fail_count" -gt 0 ]; then
+  printf '%s%d failure(s)%s\n' "$RED" "$fail_count" "$NC"
+  exit 1
+fi
+printf '%sall checks passed%s\n' "$GREEN" "$NC"
+exit 0

package/skills/linkedin-strategy/SKILL.md

@@ -0,0 +1,179 @@
+---
+name: linkedin-strategy
+description: "Use when a LinkedIn presence — personal brand or company page — needs an account-level decision spanning months: positioning and point of view, three to five content pillars, posting cadence, whether content lives on the founder's profile or the company page, and the social-selling rhythm, read from and written back to the presence's own learning wiki. NOT writing the post copy or hook (that is `linkedin-content`), NOT building a carousel deck (that is `linkedin-carousels`), NOT sending DMs (that is `linkedin-outreach`), NOT pulling raw analytics (that is `linkedin-api`)."
+tags: [linkedin, positioning, content-pillars, cadence, thought-leadership, ssi, social-selling]
+recommends: [linkedin-content, linkedin-outreach, linkedin-api, content-engine, write-adr]
+origin: risco
+---
+
+# LinkedIn Strategy — The Presence as a System, Not the Next Post
+
+*You operate at account/presence altitude.* You decide the **territory** (what this presence is known for, who it is for) and the **system** (pillars, cadence, where content lives, the social-selling rhythm) over months. You never write the post, build the carousel, run the DMs, or hit the API — those are single-asset jobs you route out. Mixing altitudes is the #1 reason LinkedIn advice goes generic: an account-level question answered with a tactic about one post produces noise and regresses to blog-post defaults.
+
+Your spine is a read/write loop with the presence's own history. You **read** the accumulated learnings before deciding and **write** the decision back, so the next session compounds instead of restarting from a generic "post 3 times a week" template.
+
+## Altitude boundary — route single-asset work out
+
+| The ask | Skill | Why it is not you |
+|---|---|---|
+| Post copy, hook, body for one update | `../linkedin-content/SKILL.md` | You set the pillar and POV; content writes inside it. |
+| A carousel / document-post deck | `../linkedin-carousels/SKILL.md` | A single asset's format craft, not the system. |
+| Connection requests, DMs, sequences | `../linkedin-outreach/SKILL.md` | You set the social-selling *rhythm*; outreach runs the individual threads. |
+| Raw analytics, OAuth, rate limits | `../linkedin-api/SKILL.md` | You *consume* the numbers; the API *fetches* them. |
+| Cross-platform calendar / scheduling | `../content-engine/SKILL.md`, `../social-publisher/SKILL.md` | Multi-platform planning/posting, not LinkedIn presence architecture. |
+| Abstract tone/voice rules | `../brand-voice/SKILL.md` | Voice in the abstract; you decide positioning and pillars. |
+
+You are the only LinkedIn skill that operates at account altitude and persists its decisions to the wiki. Every sibling works on a single asset or a single thread.
+
+## 1. Read the wiki FIRST — before any decision
+
+Read `docs/wiki/linkedin/` before you decide anything. Why: a positioning or cadence call made without the account's own dwell-time and SSI history is just generic advice with a name on it. The whole value of this skill is that decisions compound.
+
+Extract, in this order:
+1. **Prior positioning / POV** — what was the presence supposed to be known for, and did it hold?
+2. **Current pillars** — the 3-5 topics in play; which carry engagement.
+3. **Stated cadence + whether it held at quality** — "3/week" that slipped to ~1 is the real signal, not the stated number.
+4. **Top dwell-time / engagement performers** — which specific posts and formats earned the most read time.
+5. **SSI trend** — the 0-100 score's direction over the trailing window.
+6. **Killed pillars / dead experiments** — so you do not re-propose what already failed.
+
+If the directory is empty or absent, **bootstrap it** — create `docs/wiki/linkedin/` with `positioning.md`, `decisions/`, and `what-worked.md`. Do not skip the read because the dir is missing; an empty wiki is a starting state, not a license to free-associate. When you decide, **cite what you grounded in** ("based on the two carousels that earned top dwell time…").
+
+Full file layout and templates: `references/wiki-records.md`.
+
+## 2. Positioning & POV + where content lives
+
+**Niche of authority.** Be known for a clear point of view in one domain. The 2026 algorithm cross-references each post's topic against your title, skills, and background — posting purposefully inside a demonstrated domain builds topical authority; posting about whatever trends suppresses it. Thought leaders post inside a POV; creators just post often. 95% of decision-makers say thought leadership influences purchasing — so the POV is the asset, not the post count.
+
+**Where the content lives — the distribution decision.** Personal profiles out-distribute company pages by a wide margin. Decide with this table, not by habit:
+
+| Goal / stage | Lean | Why |
+|---|---|---|
+| Build reach, inbound, trust | Founder / exec personal profile | Personal content engages ~8x more than the page; profiles get ~65% of feed allocation. |
+| Recruiting, official announcements, ad retargeting base | Company page (secondary) | Pages lost ~60-66% organic reach 2024-2026, now ~5% of feed; useful as a base, not a megaphone. |
+| Scale reach without paying | Employee advocacy | Advocacy yields ~561% greater reach and ~7x more lead conversion than the page alone; CEO/founder posts get ~4x the page's engagement. |
+
+**Rule: humans are the main event.** The page amplifies; it never carries.
+
+```text
+Bad:  All content posted on the company page; the founder reshares occasionally.
+Good: The founder posts the POV from their profile; the page reshares as amplification;
+      5 employees advocate the same week. Reach compounds across human graphs.
+```
+
+## 3. Content pillars — the territory, not the posts
+
+Define **3-5 pillars**. Fewer than 3 is a single-note feed; more than 5 dilutes topical authority and confuses the cross-reference. Each pillar must align to the professional graph — the title, skills, and background LinkedIn already knows — so the 2026 topic match rewards you instead of flagging you off-domain.
+
+Pillars are the **territory**. `../linkedin-content/SKILL.md` writes the individual posts inside them; you do not.
+
+```text
+Bad:  "I post about whatever's trending that week."
+Good: A B2B data-platform founder runs 4 pillars:
+      1. Pipeline reliability war stories   (graph-aligned: their actual job)
+      2. Hiring/scaling a data team
+      3. Build-vs-buy decision frameworks
+      4. Behind-the-scenes founder lessons
+```
+
+Worked pillar sets for a solo consultant and a company page: `references/ssi-and-pillars.md`.
+
+## 4. Cadence — the rate you can hold, not the rate a blog quotes
+
+Pick the **highest rate you can sustain for 8 weeks at quality**. The sweet spot is **2-5 posts/week**, with **3-4/week the highest-ROI band**; consistency beats volume — 8 posts/month for 24 months beats 20/month for 6 months then quitting, because the algorithm rewards a sustained schedule, not a burst. Aim ~20-28h between posts; Tue-Thu is strongest for B2B.
+
+Gate every cadence number through this checklist — answer all YES before you commit:
+
+- [ ] Is the idea backlog deep enough to feed this rate for 8 weeks?
+- [ ] Is there bandwidth to *engage* daily (see §5), not just publish?
+- [ ] Is there format bandwidth for carousels/documents, not only text?
+
+If any answer is NO, lower the cadence. A held 3/week beats an aspirational 5/week that collapses to 1.
+
+**Format weight.** Carousels and document posts earn 2-3x more dwell time than text or image — and dwell time is the primary 2026 quality signal, not likes. Weight the calendar toward them.
+
+**Tie the number to the wiki, not the blog.** If the account's own data shows carousels on one topic earning the best dwell time, the cadence recommendation weights toward that — a number justified by §1's read, never a default.
+
+## 5. The social-selling rhythm — engage-vs-create and SSI
+
+**Engagement outweighs raw posting frequency for inbound.** Accounts posting 3x/week *with* active inbound engagement beat daily-posting-no-engagement accounts by ~4.2x in lead gen. The split that works: roughly **~80% of LinkedIn time engaging** (commenting on others' posts, replying in your own threads), **~20% creating**. "20 min creating + 40 min engaging" beats "60 min creating + 0 engaging." Set this as the rhythm; the individual threads belong to `../linkedin-outreach/SKILL.md`.
+
+**SSI as a habit system, not a vanity number.** The Social Selling Index is a 0-100 score over four 25-point dimensions, refreshed daily on a trailing 90-day window, free at `linkedin.com/sales/ssi`:
+
+| Dimension (25 pts each) | Weekly habit |
+|---|---|
+| Establish a professional brand | Publish inside your pillars; complete profile. |
+| Find the right people | Targeted search + connect within your niche. |
+| Engage with insights | The ~80% engage block — comment with substance. |
+| Build relationships | Convert engagement into 1:1 conversations. |
+
+Targets: **65+** for active B2B sellers, **75+** is thought-leader territory, all-user average ~40-50. SSI is benchmarked relative to your industry (not absolute) and responds within ~90 days to habit changes — which makes it a usable steering metric, not a scoreboard. Deep per-dimension habit breakdown: `references/ssi-and-pillars.md`.
+
+## 6. The review & double-down loop
+
+On a quarterly or monthly review, read §1's what-worked + dwell/SSI trend, then branch:
+
+```text
+Engagement rising while cadence held?
+  RISING     -> a pillar/format is working. Double down: more slots to that pillar,
+                more of that format. Log which one and why.
+  PLATEAUED  -> diagnose, do not just post more. Weak pillar topical fit
+                (off-graph topic suppressed) OR weak format/dwell (text where a
+                carousel would earn read time)?
+  DECLINING  -> sunset the dead pillar. Reallocate its calendar slot to a rising
+                one. Log it KILLED so no future session re-proposes it.
+```
+
+"Post more" never fixes falling engagement — diagnose pillar fit vs format/dwell first.
+
+## 7. Write the decision back — on exit, always
+
+Append a dated decision record under `docs/wiki/linkedin/decisions/`. Every record names the **single metric it bets on** and a **review date** — a decision without a metric is an opinion, not a checkable bet.
+
+```markdown
+---
+type: linkedin-decision
+title: Move distribution to founder profile
+description: Founder profile carries the POV; the company page amplifies; refine to 4 pillars and hold 3/week.
+tags: [linkedin, distribution, positioning, cadence]
+timestamp: 2026-06-02T00:00:00Z
+topic: linkedin
+status: stable
+---
+
+# 2026-06-02 — Move distribution to founder profile
+
+Context read: SSI 48 (flat 90d); top-2 dwell-time posts both carousels on
+"pipeline reliability"; stated cadence 3/week slipped to ~1; company page reach near zero.
+
+Decision: Founder profile carries the POV; company page amplifies; refine to 4 pillars
+weighted toward the reliability carousel topic; hold 3/week with carousels Tue/Thu.
+Social-selling rhythm: 80/20 engage/create.
+
+Bets on metric: SSI 48 -> 65 within 90 days (proxy for inbound).
+Review date: 2026-09-02.
+```
+
+The `type:` field is required (OKF v0.1); `timestamp` is ISO 8601. The dated heading and the `Decision:` / `Bets on metric:` / `Review date:` lines are domain signals `verify.sh` greps for — keep them.
+
+After writing, run `scripts/verify.sh docs/wiki/linkedin/` to confirm the record is structurally complete. Full templates and the what-worked format: `references/wiki-records.md`.
+
+## Anti-patterns
+
+| Anti-pattern | Why it fails | Do instead |
+|---|---|---|
+| Dumping content on the company page | ~5% feed allocation; reach is near dead | Founder/employee profiles carry it; the page amplifies |
+| Chasing daily posting | Hits a quality cliff, no bandwidth to engage | 3-4/week held + the engage split |
+| Posting outside your pillars / domain | 2026 topic cross-reference suppresses authority | Stay inside graph-aligned 3-5 pillars |
+| Optimizing for likes | Misses dwell time, the real 2026 signal | Weight carousels/docs; measure dwell time |
+| Treating SSI as a vanity score | Ignores it as a steerable habit system | Run the four dimensions as weekly habits |
+| Create-only, no engaging | ~4.2x worse inbound | ~80/20 engage-to-create split |
+| Deciding without reading the wiki | Regresses to generic blog advice | READ `docs/wiki/linkedin/` first |
+| Never writing the decision back | No compounding; every session restarts | Append a dated record + metric + review date |
+
+## References & routing
+
+- `references/wiki-records.md` — file layout under `docs/wiki/linkedin/`, decision-record and what-worked templates, and exactly what `verify.sh` checks.
+- `references/ssi-and-pillars.md` — the four SSI dimensions as concrete weekly habits with targets, pillar-design worked examples, and the personal-vs-page + employee-advocacy reach mechanics.
+
+Route single-asset work out: post copy → `../linkedin-content/SKILL.md`; carousels → `../linkedin-carousels/SKILL.md`; DMs/sequences → `../linkedin-outreach/SKILL.md`; raw metrics → `../linkedin-api/SKILL.md`; decision discipline → `../decision-records/SKILL.md`.

package/skills/linkedin-strategy/evals/README.md

@@ -0,0 +1,3 @@
+# Evals — linkedin-strategy
+
+These cases are run by the skill-eval harness (or read by hand) to confirm three things. First, that `linkedin-strategy` loads on account-level prompts — positioning/POV, content pillars, cadence, the personal-vs-company-page distribution choice, and the SSI/social-selling rhythm — including the non-obvious "I post but get no inbound" framing and the Spanish phrasing. Second, that it stays off single-asset and API prompts, routing each to the named sibling (`linkedin-content`, `linkedin-carousels`, `linkedin-outreach`, `linkedin-api`, `social-publisher`) — every `route_to` id is a real skill in the catalog. Third, that the capability scenario exercises the full loop: read `docs/wiki/linkedin/` first, decide positioning/pillars/cadence/distribution/SSI-rhythm grounded in the account's own data, write a dated decision record back naming the metric it bets on and a review date, and route single-asset work out. There is no automated scorer here — judge `must_include` coverage against the model's output, and run `scripts/verify.sh docs/wiki/linkedin/` to confirm any decision record the run produces is structurally complete.