rsc-universal 0.1.1

package/skills/procurement/references/sourcing-requests.md

@@ -0,0 +1,116 @@
+# Sourcing requests — copy-ready skeletons
+
+These force *comparable* bids. The non-negotiable sections in every one: spec +
+quantity, delivery terms, disclosed evaluation criteria + weights, a hard
+deadline, and a required response format. Drop any of those and the responses
+come back impossible to score side by side.
+
+## RFI — request for information (non-binding, scope the field)
+
+Use when requirements are still fuzzy and you're narrowing a shortlist.
+
+```text
+RFI: <category> — <your company>
+Purpose: market scan, non-binding. We are NOT awarding from this.
+
+1. About us            — who we are, rough annual volume, why we're sourcing.
+2. What we're exploring — the problem/need in plain terms (not yet a hard spec).
+3. Questions to you    — capabilities, capacity, lead times, certifications,
+                         reference customers, typical commercial model.
+4. Response format     — fill the attached table; max 3 pages of supporting text.
+5. Deadline            — responses due <date>. Shortlisted suppliers advance to
+                         an RFQ/RFP.
+6. Contact             — single point of contact + how to ask clarifying questions.
+```
+
+## RFQ — request for quotation (specs locked, price decides)
+
+Use when the need is fully specified and suppliers are directly comparable.
+
+```text
+RFQ: <item> — <your company>            Issued <date>   Responses due <date>
+
+1. Specification       — exact spec sheet / part numbers / quality standard.
+2. Quantity            — units, cadence (one-off vs recurring), MOQ tolerance.
+3. Delivery            — destination, required date, Incoterm if cross-border.
+4. Pricing requested   — unit price, freight, any tooling/setup, volume breaks,
+                         and ALL recurring lines (support, maintenance, licences)
+                         so we can compute total cost of ownership, not sticker.
+5. Payment terms       — your standard terms + any early-payment discount.
+6. Evaluation criteria — DISCLOSED weights (sum to 100), e.g.
+                         price/commercial 40 · capability 30 · viability/risk 30.
+7. Response format     — fill the quote table; deviations listed explicitly.
+8. Validity            — quote valid through <date>.
+```
+
+## RFP — request for proposal (the *how* is open)
+
+Use when the supplier designs part of the answer and you evaluate approach *and*
+price.
+
+```text
+RFP: <project/need> — <your company>     Issued <date>   Responses due <date>
+
+1. Background & objective — the outcome we want, constraints, success measures.
+2. Scope of work          — what's in, what's out, deliverables, milestones.
+3. Requirements           — functional + non-functional, must-have vs nice.
+4. Proposal contents      — proposed approach, team, timeline, assumptions,
+                            references, and a fully-loaded price (TCO lines).
+5. Evaluation criteria    — DISCLOSED weights (sum to 100), e.g.
+                            approach/capability 40 · price 30 · viability 30.
+6. Process & timeline     — Q&A window, shortlist, demo/clarification, award.
+7. Response format        — section order fixed; page limits; pricing in the
+                            supplied table.
+8. Deadline & contact     — hard due date, single point of contact.
+```
+
+## Phased flow
+
+A mature buy runs **RFI → RFP → RFQ**: learn the market, evaluate solutions,
+then lock price on the finalists. A well-defined commodity buy skips straight to
+**RFQ**. Don't run an RFP for something you can fully spec — that's an RFQ.
+
+## Invite email (shortlist → bid)
+
+```text
+Subject: Invitation to quote — <item/project>, responses due <date>
+
+Hi <name>,
+
+We're sourcing <item> (approx <volume>) and would like a quote from <supplier>.
+The attached RFQ has the full spec, delivery requirement, and the evaluation
+criteria with weights so you can see exactly how bids are scored.
+
+Please return the filled quote table by <date>. Questions to <contact> by <date>.
+
+Thanks,
+<you>
+```
+
+## Award note
+
+```text
+Subject: <item> sourcing — award
+
+Hi <name>,
+
+Thank you for your quote. We're awarding this to <supplier> based on our scored
+evaluation (capability, total cost of ownership, and supplier risk). We'd like to
+proceed to contracting — next steps and terms to follow.
+
+<you>
+```
+
+## Regret note
+
+```text
+Subject: <item> sourcing — outcome
+
+Hi <name>,
+
+Thank you for the time on your quote. We've awarded this round to another
+supplier on our weighted evaluation. Your bid was competitive on <dimension>;
+we'd welcome you in the next cycle and will keep your details on file.
+
+<you>
+```

package/skills/procurement/scripts/verify.sh

@@ -0,0 +1,280 @@
+#!/usr/bin/env bash
+#
+# verify.sh — structural-consistency gate for the `procurement` skill.
+#
+# WHAT IT DOES (read-only; never edits a file)
+#   Static lint over generated procurement artifacts. It checks SHAPE and
+#   ARITHMETIC, never which supplier is the right pick (that is the capability
+#   eval's job). For each candidate file found:
+#
+#   On a SCORECARD (a CSV/markdown table with a `weight` column):
+#     1. Weights are present and SUM TO 100 (tol via --tol, default 1%).
+#     2. Every supplier column has a score on every weighted criterion (no blanks).
+#     3. If a weighted_total / total row is declared, recompute Σ(weight×score)
+#        per supplier and assert it matches.
+#
+#   On a TCO comparison (a block mentioning unit/acquisition price):
+#     4. It contains MORE than a unit line — at least one of
+#        delivery/freight/maintenance/support/training/downtime/exit/disposal.
+#
+#   On a SOURCING REQUEST (an RFI/RFQ/RFP document):
+#     5. It names evaluation criteria AND a deadline/due date — else warn.
+#
+#   Anywhere:
+#     6. A line marked "single source" / "sole source" on a critical/strategic
+#        item with NO accompanying backup/contingency line -> warn.
+#     7. Placeholder tokens (TBD, XX, #REF, [supplier], ???) -> fail.
+#
+#   A missing/empty target is a SKIP, never a failure.
+#
+# HOW TO RUN (inside YOUR project, not the skills repo)
+#   ./verify.sh                          # scan ./ for procurement artifacts
+#   ./verify.sh --path scorecard.csv     # check one file
+#   ./verify.sh --path build/            # scan a directory
+#   ./verify.sh --tol 0.02               # widen weight-sum / recompute tolerance
+#   ./verify.sh --strict                 # treat warnings as failures (CI gate)
+#
+# EXIT CODES
+#   0  clean, empty target, or warnings only without --strict
+#   1  a real failure (weights off 100, blank score, total mismatch, placeholder)
+#   2  bad usage
+#
+# 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
+
+usage() { sed -n '2,46p' "$0" | sed 's/^# \{0,1\}//'; }
+
+SCAN_PATH="."
+STRICT=0
+TOL="0.01"
+while [ $# -gt 0 ]; do
+  case "$1" in
+    --path)    SCAN_PATH="${2:?--path needs a value}"; shift 2 ;;
+    --tol)     TOL="${2:?--tol needs a value}"; shift 2 ;;
+    --strict)  STRICT=1; shift ;;
+    -h|--help) usage; exit 0 ;;
+    *) printf '%sUnknown argument: %s%s\n\n' "$RED" "$1" "$NC"; usage; exit 2 ;;
+  esac
+done
+
+emit() { printf '%s\n' "$1"; }   # findings go to stdout, tallied at the end
+
+if [ ! -e "$SCAN_PATH" ]; then
+  printf '%s[skip]%s path not found: %s — nothing to check\n' "$YELLOW" "$NC" "$SCAN_PATH"
+  printf '\nok=0 skip=1 warn=0 fail=0\n'
+  exit 0
+fi
+
+have() { command -v "$1" >/dev/null 2>&1; }
+if ! have awk; then
+  printf '%s[skip]%s awk not found — cannot parse; install awk\n' "$YELLOW" "$NC"
+  printf '\nok=0 skip=1 warn=0 fail=0\n'
+  exit 0
+fi
+
+# Collect candidate files: csv/md/txt that look like procurement artifacts.
+FILES=""
+if [ -f "$SCAN_PATH" ]; then
+  FILES="$SCAN_PATH"
+else
+  FILES="$(find "$SCAN_PATH" -type f \( -name '*.csv' -o -name '*.md' -o -name '*.txt' \) \
+            \( -iname '*scorecard*' -o -iname '*supplier*' -o -iname '*vendor*' \
+               -o -iname '*tco*' -o -iname '*rfq*' -o -iname '*rfp*' -o -iname '*rfi*' \
+               -o -iname '*sourcing*' -o -iname '*procure*' -o -iname '*quote*' \) \
+            2>/dev/null || true)"
+fi
+
+if [ -z "$FILES" ]; then
+  printf '%s[skip]%s no procurement artifact found under %s — nothing to check (clean)\n' "$YELLOW" "$NC" "$SCAN_PATH"
+  printf '\nok=0 skip=1 warn=0 fail=0\n'
+  exit 0
+fi
+
+OUT="$(mktemp -t proc_verify.XXXXXX 2>/dev/null || echo /tmp/proc_verify.$$)"
+trap 'rm -f "$OUT" 2>/dev/null || true' EXIT
+
+check_one() {
+  f="$1"
+  [ -s "$f" ] || { emit "SKIP empty file: $f"; return; }
+  emit "HEAD —— $f"
+
+  # 6/7 — whole-file lints (placeholders + silent single source).
+  if grep -niE 'TBD|#REF|\[supplier\]|\[vendor\]|\?\?\?|(^|[,;[:space:]])XX([,;[:space:]]|$)' "$f" >/dev/null 2>&1; then
+    emit "FAIL $f: placeholder token (TBD/XX/#REF/[supplier]/???) present"
+  else
+    emit "OK $f: no placeholder tokens"
+  fi
+
+  if grep -niE 'single[ -]?source|sole[ -]?source' "$f" >/dev/null 2>&1; then
+    if grep -niE 'backup|contingenc|secondary supplier|dual[ -]?sourc|alternate supplier|fallback' "$f" >/dev/null 2>&1; then
+      emit "OK $f: single/sole source named with a backup/contingency line"
+    else
+      emit "WARN $f: 'single/sole source' present but no backup/contingency line found"
+    fi
+  fi
+
+  # 5 — sourcing request: needs criteria + a deadline.
+  if grep -niE 'RF[IQP]\b|request for (information|quotation|proposal)|sourcing request' "$f" >/dev/null 2>&1; then
+    has_crit=0; has_dead=0
+    grep -niE 'evaluation criteria|criteria.*weight|weights?.*(sum|100)|scoring' "$f" >/dev/null 2>&1 && has_crit=1
+    grep -niE 'deadline|due (by|date)|responses? due|valid through|submit by' "$f" >/dev/null 2>&1 && has_dead=1
+    [ "$has_crit" -eq 1 ] && emit "OK $f: sourcing request discloses evaluation criteria" \
+                          || emit "WARN $f: sourcing request names no evaluation criteria"
+    [ "$has_dead" -eq 1 ] && emit "OK $f: sourcing request states a deadline" \
+                          || emit "WARN $f: sourcing request states no deadline/due date"
+  fi
+
+  # 4 — TCO: more than a unit line.
+  if grep -niE 'tco|total cost of ownership|acquisition' "$f" >/dev/null 2>&1 \
+     || grep -niE 'unit price' "$f" >/dev/null 2>&1; then
+    if grep -niE 'freight|delivery|shipping|maintenance|support|training|downtime|disposal|exit|residual|true[ -]?up' "$f" >/dev/null 2>&1; then
+      emit "OK $f: cost comparison includes more than unit price"
+    else
+      emit "WARN $f: looks like a cost comparison but only a unit line — TCO needs freight/support/etc."
+    fi
+  fi
+
+  # 1/2/3 — scorecard arithmetic (CSV-shaped tables with a weight column).
+  #
+  # SCOPING: a scorecard is ONE contiguous table. A blank line or a code-fence
+  # marker (```) ends the current table; we evaluate it, then reset all state so
+  # the next fenced block starts clean. Without this, a file that holds both a
+  # scorecard CSV and a TCO comparison (e.g. references/scorecard-and-tco.md)
+  # would let the parser keep `seen_header` set across blocks and treat TCO rows
+  # (acquisition/freight/tco) as zero-score criteria — ~10 spurious failures.
+  out="$(awk -v tol="$TOL" '
+    function norm(s){ gsub(/^[ \t"|]+|[ \t"|]+$/,"",s); return tolower(s) }
+    function num(s){ gsub(/[ \t"$,%|]/,"",s); if(s=="") return ""; if(s+0==s) return s+0; return "" }
+    # Evaluate the table accumulated so far, then clear all per-table state.
+    function flush_table(   k,d,diff,base){
+      if(have_weight && wsum>0){
+        found=1
+        d = (wsum>100)?(wsum-100):(100-wsum)
+        if (d > tol*100) printf "FAIL weights sum to %g, not 100\n", wsum
+        else             printf "OK weights sum to %g (~100)\n", wsum
+        if (has_total){
+          for(k=1;k<=ns;k++){
+            if(decl[k]=="") continue
+            diff=(decl[k]>acc[k])?(decl[k]-acc[k]):(acc[k]-decl[k])
+            base=(acc[k]<1)?1:acc[k]
+            if (diff/base > tol*5)
+              printf "FAIL %s weighted total %g != recomputed %g\n", sname[k], decl[k], acc[k]
+            else
+              printf "OK %s weighted total %g matches recompute %g\n", sname[k], decl[k], acc[k]
+          }
+        }
+      }
+      # reset every table-local accumulator
+      seen_header=0; have_weight=0; wcol=0; ccol=0; ns=0; wsum=0; has_total=0
+      delete scol; delete sname; delete acc; delete decl
+    }
+    BEGIN{ FS=","; have_weight=0; found=0 }
+    # A blank line or a fence marker closes the current contiguous table.
+    /^[ \t]*$/ || /^[ \t]*```/ { flush_table(); next }
+    {
+      line=$0
+      # support markdown pipe tables too: convert | to , for parsing
+      if (index(line,"|")>0 && index(line,",")==0){ gsub(/\|/,",",line); $0=line }
+    }
+    # header row: find the weight column + supplier columns
+    !seen_header {
+      for(i=1;i<=NF;i++){
+        h=norm($i)
+        if(h=="weight"||h=="weights"){ wcol=i; have_weight=1 }
+        if(h=="criterion"||h=="criteria"){ ccol=i }
+      }
+      if(have_weight){
+        seen_header=1
+        # supplier columns = numeric-data columns that are not weight/criterion
+        for(i=1;i<=NF;i++){
+          if(i==wcol||i==ccol) continue
+          h=norm($i)
+          if(h!=""){ scol[++ns]=i; sname[ns]=h }
+        }
+        next
+      }
+      next
+    }
+    {
+      crit = (ccol? norm($(ccol)) : "")
+      w = num($(wcol))
+      # the declared-total row (criterion says total/weighted_total)
+      if (crit ~ /total/){
+        for(k=1;k<=ns;k++){ decl[k]=num($(scol[k])) }
+        has_total=1
+        next
+      }
+      if (w=="") next
+      wsum += w
+      for(k=1;k<=ns;k++){
+        v=num($(scol[k]))
+        if(v==""){ printf "FAIL blank score for %s on criterion %s\n", sname[k], (crit?crit:NR) }
+        else { acc[k]+=w*v }
+      }
+    }
+    END{
+      flush_table()        # close the last table if the file did not end on a boundary
+      if(!found){ print "NOSCORE" }
+    }
+  ' "$f" 2>/dev/null)"
+
+  if [ "$out" = "NOSCORE" ] || [ -z "$out" ]; then
+    : # not a scorecard table; other checks already ran
+  else
+    printf '%s\n' "$out" | while IFS= read -r l; do
+      [ -z "$l" ] && continue
+      case "$l" in
+        FAIL*) emit "FAIL $f: ${l#FAIL }" ;;
+        OK*)   emit "OK $f: ${l#OK }" ;;
+        WARN*) emit "WARN $f: ${l#WARN }" ;;
+      esac
+    done
+  fi
+}
+
+printf 'Checking procurement artifacts under: %s (tol=%s)\n\n' "$SCAN_PATH" "$TOL"
+
+: > "$OUT"
+printf '%s\n' "$FILES" | while IFS= read -r f; do
+  [ -z "$f" ] && continue
+  check_one "$f"
+done >> "$OUT" 2>&1 || true
+
+# Render findings with color, tally as we go.
+while IFS= read -r line; do
+  case "$line" in
+    HEAD*) printf '%s%s%s\n' "$YELLOW" "${line#HEAD }" "$NC" ;;
+    OK*)   printf '%s[ ok ]%s %s\n' "$GREEN"  "$NC" "${line#OK }" ;;
+    WARN*) printf '%s[warn]%s %s\n' "$YELLOW" "$NC" "${line#WARN }" ;;
+    FAIL*) printf '%s[fail]%s %s\n' "$RED"    "$NC" "${line#FAIL }" ;;
+    SKIP*) printf '%s[skip]%s %s\n' "$YELLOW" "$NC" "${line#SKIP }" ;;
+  esac
+done < "$OUT"
+
+tally() { { grep -c "^$1" "$OUT" 2>/dev/null || true; } | tr -dc '0-9'; }
+ok_count=$(tally 'OK');     ok_count=${ok_count:-0}
+warn_count=$(tally 'WARN'); warn_count=${warn_count:-0}
+fail_count=$(tally 'FAIL'); fail_count=${fail_count:-0}
+skip_count=$(tally 'SKIP'); skip_count=${skip_count:-0}
+
+printf '\nok=%d skip=%d warn=%d fail=%d\n' "$ok_count" "$skip_count" "$warn_count" "$fail_count"
+
+cat <<'EOF'
+
+Note: this gate proves the artifact is STRUCTURALLY SOUND (weights total 100, no
+blank scores, totals recompute, TCO has more than a unit line, a sourcing request
+names criteria + a deadline, a single source carries a backup). It does NOT judge
+which supplier is correct — that is the capability eval's job. Re-run --strict to
+gate CI on a clean pass.
+EOF
+
+if [ "$fail_count" -gt 0 ]; then exit 1; fi
+if [ "$STRICT" -eq 1 ] && [ "$warn_count" -gt 0 ]; then exit 1; fi
+exit 0

package/skills/project-ops/SKILL.md

@@ -0,0 +1,130 @@
+---
+name: project-ops
+description: "Use when an operator wants to run a small or mid project from a flat file — dated milestones each with one named owner and a binary done-test, RAG status driven by rules, a RAID log, slippage detection, and a 2-minute weekly status report — instead of standing up Jira/Asana. Triggers: 'set up milestones with owners and due dates', 'write this week's status report', 'who do I chase if the launch slips', 'everything is green and I don't trust it — what should be amber', 'which milestones are trending late before they miss', 'start a RAID log', 'munta'm un seguiment de projecte amb fites i estat RAG', 'informe d'estat setmanal', 'qui és l'owner de cada fita', 'estado del proyecto en rojo/ámbar/verde'. NOT sequencing the engineering work inside one approved plan (that is tasks)."
+tags: [project-management, milestones, status-tracking]
+recommends: [tasks, decision-records, meeting-notes, sop-builder, dashboard]
+origin: risco
+---
+
+# project-ops
+
+You run a project from one flat file, not a PM tool. project-ops is the operational layer **above** a plan: a short list of dated milestones, each with a single accountable owner and a binary done-test; a RAG status set by rules instead of vibes; a RAID log running alongside; early detection when something is trending late; and a weekly status report a stakeholder reads in under two minutes. Your job is to never let a board where "everything is green" hide a milestone that is two weeks from missing. You do not sequence engineering tasks (that is `../tasks/SKILL.md`) and you do not write the architecture plan (that is `../plan/SKILL.md`) — you keep the whole project honest above both.
+
+## The artifact comes first
+
+Before any process, there is one file. Everything else updates it. A milestone table:
+
+```markdown
+| id | milestone | owner | target | status | done_test | depends_on |
+|----|-----------|-------|--------|--------|-----------|------------|
+| M1 | Pricing copy approved | @ana | 2026-06-10 | done | Final copy signed off in doc | |
+| M2 | Pricing page built | @ben | 2026-06-18 | amber | URL returns 200 with new copy | M1 |
+| M3 | Page live in prod | @ben | 2026-06-24 | green | prod URL 200, analytics firing | M2 |
+```
+
+Columns are a fixed contract — `id | milestone | owner | target | status | done_test | depends_on`. CSV with the same header is equivalent and is what `scripts/verify.sh` lints. This file is the single source of truth; the status report is a *view* of it, never a second copy that drifts.
+
+Rules for the contract, each with its why:
+- **`id` is unique and stable** — `depends_on` references it, so renaming breaks the graph.
+- **`owner` is exactly one person, with an `@handle`** — "accountability without a named owner defaults to no accountability." Never a team (`@marketing`) or two people.
+- **`target` is an ISO date** (`YYYY-MM-DD`) — so "trending late" is arithmetic, not opinion.
+- **`status` is one of `{green, amber, red, done}`** — a closed set the report and the linter both trust.
+- **`done_test` is binary and verifiable** — you can point at it and say yes/no, no "improve" or "work on".
+- **`depends_on` is a comma-separated list of real ids** — the dependency edges that reveal the critical path.
+
+## Milestone discipline
+
+A milestone is a **checkpoint that marks a significant achievement** — it has a target date but no duration. The smaller actionable steps that get you there are *tasks*; track milestones at the project level, not every task. Each milestone proves a SMART-shaped goal (the done-test is the "Measurable").
+
+Bad → Good, because most plans fail right here:
+
+```text
+Bad:  "Marketing improvements"          (no owner, no date, not testable)
+Good: | M7 | Landing page live | @ana | 2026-06-15 | green | prod URL returns 200 with new hero | M6 |
+
+Bad:  "Ben & Ana own the launch"        (accountability split = no accountability)
+Good: owner @ben on M2; @ana is named in done_test as reviewer if needed — still one A.
+
+Bad:  done_test = "page is better"       (not binary — never finishable)
+Good: done_test = "Lighthouse perf >= 90 on /pricing, checked in CI"
+```
+
+If the operator hands you a loose goal, decompose it into 3–8 milestones with one owner and a binary done-test each, then draw `depends_on` edges. More than ~10 milestones means you are tracking tasks — push those down to `../tasks/SKILL.md`.
+
+## RAG status from rules, not vibes
+
+Set status by the table below and write the *reason* next to any non-green item. Re-evaluate every milestone at each update.
+
+| Condition | Status |
+|-----------|--------|
+| On track; on or ahead of date; dependencies met | `green` |
+| Trending late: days of slip accumulating, OR a blocking `depends_on` has shifted, OR past ~halfway to target with little visible progress | `amber` |
+| Missed its target, OR critically late with no credible recovery, OR a hard blocker with no owner-driven mitigation | `red` |
+| Done-test satisfied and verified | `done` |
+
+Two rules that do the real work:
+- **Amber is an early warning, not a soft red.** Flag amber *before* the due date passes — the whole point is to course-correct while there is still time. A milestone that only turns red on its due date was mis-tracked.
+- **All-green is a smell.** A board that is always green means you are either not tracking closely or not being honest. On any real project at least one item is usually amber. If everything is genuinely green, say so explicitly so it is a claim, not a default.
+
+## Slippage and the critical path
+
+The **critical path** is the longest chain of `depends_on` edges that sets the finish date — its milestones have zero buffer, so any slip there slips the whole project. Mark which milestones are on it. Watch **near-critical** paths too: a small slip there can promote them onto the critical path.
+
+At every update: re-confirm which milestones are critical (the path moves as dates change), track **days of slip** per milestone (today minus target for anything late), and surface any milestone whose amber rule just tripped. The full early-warning decision table and a worked slippage example live in `references/raid-and-rag.md`.
+
+## RAID log
+
+Run a RAID log alongside the milestone table from project initiation. Four buckets — keep them distinct, because the confusion between a risk and an issue is where projects rot:
+
+- **Risk** — *might* happen; plan a mitigation ahead of time. (likelihood × impact)
+- **Assumption** — believed true but unverified; if it breaks, a milestone breaks.
+- **Issue** — already happening, needs action now (a risk that materialized).
+- **Dependency** — a handoff or relationship that can bottleneck (often the cross-team `depends_on` edges).
+
+Each item carries: description, likelihood, impact/severity, owner, and a review date. Review the log **at least weekly and at every phase transition** — phase boundaries are exactly when hidden risks surface and old assumptions break. Example rows and the RACI-on-milestones note are in `references/raid-and-rag.md`.
+
+## The weekly status report
+
+A status report is scannable in **under 2 minutes** and takes you **under 15 minutes to write**. It is a delta view, not a re-dump of the plan. Structure:
+
+```markdown
+## Status — Pricing launch — week of 2026-06-02
+**Overall: AMBER** — M2 slipped 3 days; recovery in place, finish date still 2026-06-24.
+
+### Hit this week
+- M1 Pricing copy approved (@ana) — done, signed off.
+
+### Next steps
+- M2 Pricing page built — @ben — due 2026-06-18 (was 06-15; +3 days)
+- M3 Page live — @ben — due 2026-06-24
+
+### Blockers / escalations
+- M2: design assets arrived 2 days late (dependency). Mitigation: @ben cut scope of v1 hero. No decision needed.
+
+### RAID changes
+- New RISK: analytics tag may not fire on prod CDN (owner @ben, review 06-16).
+- Moved to ISSUE: staging deploy flaky → now blocking M2 testing.
+```
+
+The honesty rule, non-negotiable: **name at least one amber/red item with its mitigation**, and if a milestone slipped, **lead with it and the recovery plan**. Stakeholders who discover problems late lose trust permanently; a credible report surfaces the bad news first. The fill-in template and a fully worked example are in `references/status-report-template.md`.
+
+## Anti-patterns
+
+| Anti-pattern | Why it fails | Do instead |
+|--------------|--------------|------------|
+| Owner is a team (`@marketing`) or two people | Accountability splits to nobody; nobody chases the slip | Exactly one named `@owner` per milestone |
+| Status set by gut feel | Two people disagree; amber never trips early | Apply the RAG rule table; write the reason |
+| Tracking every task as a milestone | The board becomes a to-do list, signal drowns | 3–8 milestones; tasks go to `../tasks/SKILL.md` |
+| `done_test` = "improve X" / "work on Y" | Never binary, so never finishable | A yes/no check: "URL 200", "signed off in doc" |
+| Board is always green | You are not tracking, or not honest | Expect ≥1 amber; state "all green" explicitly if true |
+| Only flag red on the due date | Too late to recover | Trip amber early on the trending-late rule |
+| RAID created once, never reviewed | Stale risks, broken assumptions go unseen | Review weekly + at every phase transition |
+| Status report re-dumps the whole plan | Nobody reads 3 pages; the delta is buried | Report deltas only: hit / next / blockers / RAID changes |
+| `depends_on` points at a deleted id | Critical path is wrong; slip propagation invisible | Keep ids stable; `verify.sh` catches dangling refs |
+
+## References
+
+- `references/status-report-template.md` — the fill-in weekly report, a worked Good example, and the artifact column contract `verify.sh` enforces.
+- `references/raid-and-rag.md` — RAID bucket definitions with example rows, the full RAG + early-warning decision table, and the RACI-on-milestones note for teams that need it.
+
+Run `scripts/verify.sh` against the milestone file to lint structure (unique ids, one owner, parseable date, allowed status, non-empty done-test, resolvable `depends_on`) and to audit the status-report honesty rule. It is a structural lint, never a judgement of whether the plan is good.

package/skills/project-ops/evals/README.md

@@ -0,0 +1,3 @@
+# Evals — project-ops
+
+`cases.yaml` is a routing + capability harness, not an automated test runner. To run it, feed each `should_trigger` prompt to the skill router and confirm `project-ops` loads, then feed each `should_not_trigger` prompt and confirm the router instead routes to the named sibling (`tasks`, `plan`, `decision-records`, `meeting-notes`, `sop-builder`, `dashboard`). For the `capability` case, give the scenario to an agent with this skill loaded and grade the resulting transcript by hand against the `must_include` rubric — each bullet is pass/fail. Separately, you can run `scripts/verify.sh` against a produced milestone file to confirm the structural contract holds (unique ids, one owner, parseable date, allowed status, non-empty done-test, resolvable depends_on); it exits 0 on a clean or empty target.

package/skills/project-ops/evals/cases.yaml

@@ -0,0 +1,71 @@
+skill: project-ops
+
+# project-ops owns the operational layer ABOVE a plan: a flat-file set of dated
+# milestones, each with ONE named owner and a binary done-test; RAG status by
+# rules; a RAID log; slippage/early-warning; and the weekly status report. It is
+# NOT engineering-task sequencing (tasks), NOT plan authoring (plan), NOT a single
+# ADR (decision-records), NOT single-meeting capture (meeting-notes), NOT a
+# repeatable runbook (sop-builder), NOT a metrics dashboard (dashboard).
+
+should_trigger:
+  - prompt: "Set up milestones for our Q3 launch with an owner and a due date for each."
+    why: "Shaping dated milestones each with one accountable owner is the skill's core job."
+
+  - prompt: "Write me this week's project status report — what's on track and what's at risk."
+    why: "The weekly 2-minute status report (overall RAG, accomplishments, blockers) is owned here."
+
+  - prompt: "Everything on my plan is marked green but I don't trust it — what should actually be amber?"
+    why: "Non-obvious: tests the all-green-is-a-smell rule and the early-warning amber criteria, not a generic dashboard."
+
+  - prompt: "Munta'm un seguiment de projecte amb fites, owners i estat RAG."
+    why: "Catalan phrasing for the core milestone+owner+RAG tracking artifact."
+
+  - prompt: "Start a RAID log for this project and tell me what counts as a risk versus an issue."
+    why: "RAID log creation and the risk-vs-issue distinction is a named project-ops job."
+
+  - prompt: "Which of my milestones are trending late before they actually miss their date?"
+    why: "Non-obvious: slippage early-warning detection on the critical path, the defining discipline of the skill."
+
+  - prompt: "Qui és l'owner de cada fita i quines van endarrerides?"
+    why: "Catalan: one-owner-per-milestone accountability plus slippage detection — both core jobs."
+
+should_not_trigger:
+  - prompt: "Break this approved implementation plan into ordered dev tasks with done-checks."
+    route_to: tasks
+    why: "Per-task engineering sequencing inside one approved plan, not cross-cutting milestones above it."
+
+  - prompt: "Write the technical implementation plan and architecture for this feature."
+    route_to: plan
+    why: "Authoring the how/architecture of a feature is the plan phase, not milestone status tracking."
+
+  - prompt: "Record the decision we made about the database choice with the options and rationale."
+    route_to: decision-records
+    why: "Capturing a single durable ADR with context/options/rationale, not running a project."
+
+  - prompt: "Turn today's meeting into notes with action items."
+    route_to: meeting-notes
+    why: "Single-meeting capture of notes and action items, not a project-level milestone/RAID layer."
+
+  - prompt: "Document the repeatable steps for our monthly close so anyone can run it."
+    route_to: sop-builder
+    why: "A repeatable runbook/process, not a finite project with dated milestones and slippage."
+
+  - prompt: "Build me a dashboard charting our weekly signups and revenue."
+    route_to: dashboard
+    why: "Charting arbitrary metrics is dashboard/kpi-framework, not milestone status tracking."
+
+capability:
+  - scenario: >
+      Operator gives a loose goal — "launch the new pricing page by end of quarter" — plus three rough
+      milestones (copy approval, page build, go-live), where the build milestone is already a few days
+      past where it should be. They ask for a tracking setup and a status report. The agent must produce
+      a milestone table and a weekly status report that obeys the discipline.
+    must_include:
+      - "A milestone table with the exact column contract: id, milestone, owner, target, status, done_test, depends_on."
+      - "Each milestone has exactly one named owner (an @handle, not a team or two people)."
+      - "Each milestone has a binary, verifiable done_test (not 'improve' or 'work on')."
+      - "The already-late milestone is marked red, or amber WITH an explicit recovery plan — never green."
+      - "RAG statuses are justified by a rule, and at least one non-green item carries a mitigation."
+      - "A scannable status report: overall RAG, accomplishments, next steps with owner+date, blockers, RAID deltas."
+      - "At least one RAID entry that distinguishes a risk (future/conditional) from an issue (happening now)."
+      - "depends_on edges reference real milestone ids so the critical path is visible."

package/skills/project-ops/references/raid-and-rag.md

@@ -0,0 +1,58 @@
+# RAID buckets, the RAG decision table, and RACI on milestones
+
+## RAID log
+
+Create at project initiation; review at least **weekly and at every phase transition** — phase boundaries are where hidden risks surface and old assumptions break. Keep the four buckets distinct.
+
+| Bucket | Definition | When it moves |
+|--------|------------|---------------|
+| **Risk** | Might happen; plan a mitigation ahead of time | Becomes an **Issue** when it materializes |
+| **Assumption** | Believed true but unverified; a milestone rests on it | Becomes an **Issue** (or new Risk) when it breaks |
+| **Issue** | Already happening, needs action now | Closes when resolved |
+| **Dependency** | A handoff/relationship that can bottleneck | Often the cross-team `depends_on` edges; closes when the handoff completes |
+
+Each item carries: **description, likelihood, impact/severity, owner, review date.**
+
+### Example rows
+
+```markdown
+| type | description | likelihood | impact | owner | review |
+|------|-------------|------------|--------|-------|--------|
+| RISK | Analytics tag may not fire behind prod CDN | med | high | @ben | 2026-06-16 |
+| ASSUMPTION | Design team delivers hero assets by 06-12 | — | high | @ana | 2026-06-12 |
+| ISSUE | Staging deploy flaky, blocks M2 testing | — | high | @ben | today |
+| DEPENDENCY | Legal sign-off on pricing copy before launch | med | high | @ana | 2026-06-09 |
+```
+
+Risk vs Issue is the distinction people get wrong: a **risk is conditional and future** ("the CDN *might* drop the tag"); an **issue is happening now** ("staging *is* broken"). When a risk materializes, move it to Issue rather than leaving a stale risk row.
+
+## RAG + early-warning decision table
+
+Set status by condition, not by feel. Write the reason next to any non-green item.
+
+| Condition | Status | Note |
+|-----------|--------|------|
+| On or ahead of target; dependencies met; visible progress | `green` | The default only when earned |
+| Days of slip accumulating (target shifting later) | `amber` | Trending late — act now |
+| A blocking `depends_on` milestone has shifted its date | `amber` | Inherited slip |
+| Past ~halfway to target with little visible progress | `amber` | Burn-rate warning |
+| Target date missed | `red` | Late, full stop |
+| Critically late with no credible recovery plan | `red` | Needs immediate intervention |
+| Hard blocker, no owner-driven mitigation | `red` | Escalate |
+| `done_test` satisfied and verified | `done` | Stop tracking it |
+
+Two operating rules:
+- **Amber fires before the due date**, not on it. The whole value is course-correcting while time remains.
+- **All-green is a smell** — on a real project at least one item is usually amber. If everything is truly green, state it explicitly so it is a claim, not a default.
+
+### Worked slippage example
+
+M2 has `target 2026-06-15`. On 2026-06-08 its blocking dependency (design assets) shifts from 06-10 to 06-12. M2 was already at the halfway mark with the page not started → trip **amber** on 06-08, target revised to 06-18 (+3 days). Because M2 sits on the critical path (M1 → M2 → M3 sets the finish date), the project overall goes amber too, and the recovery (reduced v1 hero) protects the 06-24 end date. Had you waited until 06-15 to notice, the only status available would have been red with no time to recover.
+
+## Critical path
+
+The critical path is the **longest chain of `depends_on` edges** — it sets the finish date and has zero buffer. Re-confirm it at every update; the path moves as dates change. Watch **near-critical** chains, since a small slip can promote them onto the critical path. Mark critical milestones in the file (e.g. a `*` after the id or a note) so a reader sees instantly where a slip is fatal.
+
+## RACI on milestones (for teams that want it)
+
+Keep roles unambiguous: each milestone or decision has **exactly one Accountable** and **at least one Responsible**. On a small team one person can be both R and A — that is fine. The failure mode is spreading **A** across people. Set roles during planning and review them at phase transitions. Do not clutter the matrix with admin items like recurring status meetings; RACI is for deliverables, not calendar events.