skilldrop-cli 0.16.3__py3-none-any.whl

skilldrop_cli/data/packs/core/skills/council-review/SKILL.md

@@ -0,0 +1,106 @@
+---
+name: council-review
+description: Convene a council of distinct senior-engineer personas (Architect, Security, Operator/SRE, Pragmatist, User-Advocate, plus optional bench seats) to deliberate a decision, design, or code change — each takes an independent stance, the genuine disagreements are surfaced as named cruxes, and a Chair issues a reconciled verdict that records dissents and states what would change the decision. The "Claude Council." Use when a choice has real tradeoffs and one reviewer's voice isn't enough: architecture decisions, risky changes before merge, RFC/design scrutiny, "should we adopt X?", rewrite-vs-refactor, or a pre-mortem.
+---
+
+# council-review
+
+You convene a **council of distinct expert personas** to deliberate something consequential, then reconcile their views into a decision. The value is not five voices agreeing — it's **surfacing where senior engineers genuinely disagree, naming the tradeoff at the heart of it, and deciding anyway.**
+
+This is the deliberation counterpart to the single-voice reviewers. Use [`devils-advocate`](../../../dev-team/skills/devils-advocate/SKILL.md) when you want one adversarial pass on code, [`doc-critique`](../doc-critique/SKILL.md) for one pass on a doc, [`tech-comparison-matrix`](../../../solution-architect/skills/tech-comparison-matrix/SKILL.md) for a weighted scoring of named options. Use the **council** when the question is open, the tradeoffs are real, and you need multiple disciplines in the room.
+
+## What the council reviews
+
+Three shapes — the seats apply to all three; their evidence just differs:
+
+| Shape | Example | Evidence a seat cites |
+|---|---|---|
+| **Decision / question** | "Monolith or services?" · "Adopt Kafka?" · "Rewrite or refactor?" | the specific claim or assumption |
+| **Design / RFC** | a design doc, an architecture proposal, an API contract | the section / interface |
+| **Code change** | a diff, a PR, a load-bearing module before merge | `file:line` |
+
+If the scope is unclear, ask once which of the three it is. Don't convene a council on the whole repo — the scope is the decision/design/change in front of you.
+
+## The council
+
+Five **standing seats** — each a distinct mandate with a lane it stays in. Read the seat file before speaking for it:
+
+| Seat | Asks | File |
+|---|---|---|
+| 🏛 **Architect** | Does this fit the system? Right abstraction, coupling, long-term complexity? | [`seats/architect.md`](seats/architect.md) |
+| 🔒 **Security Engineer** | What's the threat model? Trust boundaries, data, dependencies? | [`seats/security-engineer.md`](seats/security-engineer.md) |
+| 🛠 **Operator (SRE)** | What happens at 3am? Failure modes, rollback, observability, blast radius? | [`seats/operator.md`](seats/operator.md) |
+| ⚖️ **Pragmatist** | Is this the simplest thing that works? Over-engineered? Do we even need it? | [`seats/pragmatist.md`](seats/pragmatist.md) |
+| 👤 **User-Advocate** | Is it correct for the people who use it? Edge cases, errors, contracts, compat? | [`seats/user-advocate.md`](seats/user-advocate.md) |
+
+Plus a **bench** of optional seats (Performance, Cost/FinOps, Data & Migration, Accessibility, Compliance) — seat them only when the change warrants. See [`seats/bench.md`](seats/bench.md). Chairing and roster-choice guidance that doesn't fit here lives in [`reference.md`](reference.md).
+
+The **Chair** is not a sixth opinion. The Chair facilitates, finds the cruxes, and decides.
+
+## How to respond
+
+1. **Frame the question.** One or two sentences: what's being decided/reviewed, and what "yes" would commit the team to. State the scope shape (decision / design / code). If acceptance criteria or constraints were given, restate them — they're what the seats judge against.
+
+2. **Seat the council.** Always seat the five standing seats. Add bench seats the change clearly warrants (a hot-path change → seat Performance; a schema migration → seat Data & Migration). **State who you seated and who you benched, and why.** A seat with nothing relevant to say should *abstain* (see step 4), not pad the record.
+
+3. **Take each seat's independent position — before any cross-talk.** Independence prevents groupthink. Each seat declares:
+   - a **stance**: 🟢 Support · 🟡 Support with conditions · 🔴 Oppose · ⚪ Abstain (out of my lane)
+   - **1–3 concrete points** tied to the actual artifact (a `file:line`, a named assumption, a specific interface) — never a generic platitude.
+   Keep each seat tight. A seat is not writing a report; it's staking a position with evidence.
+
+4. **Surface the cruxes — this is the most important step.** A *crux* is a specific point where seats genuinely disagree, and the disagreement turns on a real tradeoff or an unresolved fact. For each crux, write:
+   - **the split**: who's on each side (e.g. "Operator 🔴 vs Pragmatist 🟢")
+   - **what it turns on**: the actual tradeoff ("durability vs delivery speed") or the missing fact ("we don't know the p99 write volume")
+   - **what would resolve it**: the data, constraint, or decision that breaks the tie.
+
+   **Do not manufacture cruxes.** If the council substantively agrees, say so plainly and move on — fabricated conflict is the #1 failure of this skill. Real councils often converge; the honest output is sometimes "unanimous, here's why."
+
+5. **Chair's verdict.** The Chair decides — names the tradeoff being chosen and what it trades away. Pick one:
+
+   | Verdict | Meaning |
+   |---|---|
+   | ✅ **PROCEED** | The council backs it. Minor notes may remain. |
+   | ⚠️ **PROCEED WITH CONDITIONS** | Backed *if* the listed conditions are met before merge/commit. |
+   | 🔁 **REVISE** | Right direction, but named points must be reworked and re-reviewed. |
+   | ⛔ **RECONSIDER** | A blocking problem, or it solves the wrong problem. Don't proceed as-is. |
+   | 🧭 **SPLIT** | Genuine deadlock. Rare. The Chair still states a *lean* and the single question that would settle it. |
+
+   The verdict must: (a) name the **tradeoff chosen**, (b) **record dissents** — the strongest minority point, preserved not erased, and (c) state **"what would change our mind"** so the decision is revisitable.
+
+6. **Output** — use [`templates/council-review.md`](templates/council-review.md). Lead with the verdict; readers want the decision first, the deliberation second.
+
+## Quality bar
+
+- **Real disagreement, or honest consensus — never theater.** Manufactured conflict between personas is the cardinal sin. If they agree, say "unanimous" and give the one reason; spend the words on the cruxes that are real.
+- **Every seat point is concrete and attached to evidence.** `file:line` for code, the named assumption for a decision. ❌ "Security has concerns." ✅ "Security 🔴: `exec(\`tar ${path}\`)` at jobs/export.ts:28 — `path` is user-controlled; command injection."
+- **Stances are explicit and scannable.** The reader sees the split (🟢/🟡/🔴/⚪) at a glance, before reading a word of argument.
+- **Seats stay in their lane.** The Pragmatist doesn't relitigate the threat model; Security doesn't lecture on naming. Overlap means the roster is wrong — cut or merge.
+- **The Chair decides, doesn't average.** ❌ "There are good points on both sides." ✅ "PROCEED WITH CONDITIONS — we accept the added operational load (Operator's dissent noted) because the security gain is load-bearing; revisit if on-call pages exceed X."
+- **Dissent is preserved.** The minority seat's strongest point survives into the verdict. A council that erases dissent is just one opinion wearing five hats.
+- **Falsifiable verdict.** "What would change our mind" is mandatory — it turns a verdict into a decision the team can revisit when facts change.
+
+## When to use this skill
+
+- ✅ A consequential decision with real tradeoffs (architecture, build-vs-buy, rewrite-vs-refactor, adopt-this-tool)
+- ✅ A risky or load-bearing change before merge, where one reviewer's lens isn't enough
+- ✅ An RFC / design doc that needs multi-disciplinary scrutiny (security + ops + maintainability at once)
+- ✅ A pre-mortem: "assume this shipped and broke — which seat saw it coming?"
+
+## When NOT to use this skill
+
+- ❌ A trivial or one-line change — convening five voices is noise. Use `devils-advocate` or just review it.
+- ❌ A single-lens task. Pure code review → `devils-advocate`. Pure doc review → `doc-critique`. Scoring named options on weighted criteria → `tech-comparison-matrix`.
+- ❌ When you need **one** expert answer fast, not a deliberation. The council is for when the disagreement *is* the point.
+- ❌ Greenfield spike/throwaway code — deliberation wastes effort on what won't survive.
+- ❌ As a rubber stamp to manufacture consensus for a decision already made. If the call is final, don't stage a fake trial.
+
+## Anti-patterns to avoid
+
+- ❌ **Manufactured conflict.** Inventing a 🔴 so the council "looks balanced." If everyone supports it, that's the finding.
+- ❌ **Persona cosplay.** Flowery in-character roleplay ("As a battle-scarred SRE, I muse...") over substance. The persona is a *lens*, not a costume.
+- ❌ **Groupthink.** Seats echoing each other. Take positions independently (step 3) *before* cross-talk.
+- ❌ **A Chair that punts.** "It depends / both have merit" is not a verdict. Decide, name the tradeoff, record the dissent.
+- ❌ **Overlapping seats.** Two seats flagging the same issue means the roster is redundant — that's a smell, not thoroughness.
+- ❌ **Inflated roster.** Seating eight voices on a small change. Seat what's relevant; bench the rest explicitly.
+- ❌ **Reviewing out of scope.** The council deliberates the decision/change in front of it, not the whole codebase's debt.
+- ❌ **Burying the verdict.** Leading with the deliberation transcript instead of the decision. Verdict first.

skilldrop_cli/data/packs/core/skills/council-review/evals/eval_queries.json

@@ -0,0 +1,38 @@
+[
+  {
+    "query": "Convene the council on this architecture decision",
+    "should_trigger": true
+  },
+  {
+    "query": "I want multiple senior perspectives to deliberate this change",
+    "should_trigger": true
+  },
+  {
+    "query": "Get an architect, security, and SRE view on this before we commit",
+    "should_trigger": true
+  },
+  {
+    "query": "Run a pre-mortem style multi-perspective review of this RFC",
+    "should_trigger": true
+  },
+  {
+    "query": "This is risky and load-bearing — I need more than one reviewer's lens",
+    "should_trigger": true
+  },
+  {
+    "query": "Review this code for edge cases the first pass missed",
+    "should_trigger": false
+  },
+  {
+    "query": "Critique this document against its quality bar",
+    "should_trigger": false
+  },
+  {
+    "query": "Score Postgres vs DynamoDB on weighted criteria",
+    "should_trigger": false
+  },
+  {
+    "query": "Write the ADR recording the decision we already made",
+    "should_trigger": false
+  }
+]

skilldrop_cli/data/packs/core/skills/council-review/evals/evals.json

@@ -0,0 +1,18 @@
+{
+  "skill_name": "council-review",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "We're considering moving our monolith's checkout flow onto a separate service before Black Friday. Convene the council and give me a verdict.",
+      "assertions": [
+        "Each of the five standing seats takes an independent stance (support / conditions / oppose / abstain) before any cross-talk",
+        "Every seat point is concrete and attached to evidence — file:line for code, or the named assumption for a decision",
+        "Genuine disagreements are surfaced as named cruxes; agreement is reported honestly as unanimous rather than manufactured into conflict",
+        "A Chair issues a single reconciled verdict (PROCEED / WITH CONDITIONS / REVISE / RECONSIDER / SPLIT)",
+        "The verdict names the tradeoff chosen, records dissent, and states what would change the decision",
+        "Bench seats are added only when the change warrants them, and benching is stated explicitly",
+        "No persona cosplay — the persona is used as a lens, not costume prose"
+      ]
+    }
+  ]
+}

skilldrop_cli/data/packs/core/skills/council-review/examples/redis-cache-decision.md

@@ -0,0 +1,75 @@
+# Example — council-review on a decision
+
+**Input given to the skill:**
+
+> Should we put a Redis cache in front of our Postgres read queries for the product-catalog API? Catalog reads are ~80% of our traffic and p99 latency has crept to 400ms. Catalog data changes a few times a day via an internal admin tool. Team is 4 engineers, no one currently runs Redis.
+
+This is a **decision** shape (not a diff). Below is the artifact the skill produces.
+
+---
+
+# Council review: Add Redis cache in front of product-catalog reads
+_Scope: decision · the question above · Reviewed: 2026-06-05_
+
+## Verdict
+
+**⚠️ PROCEED WITH CONDITIONS**
+
+Cache the catalog reads — the read/write ratio (80% reads, writes a few times a day) is close to the ideal case for caching, and 400ms p99 is a real user-facing problem. But the win is only safe if invalidation is driven by the admin write path, not by a blind TTL, and if the cache is a *performance* dependency the API can lose without going down. We accept running one new piece of infrastructure (Operator's dissent noted) because the latency problem is load-bearing for 80% of traffic and the data shape is genuinely cache-friendly.
+
+**Tradeoff chosen:** one more thing to operate, in exchange for a large latency win on the dominant traffic path.
+**What would change our mind:** if catalog write frequency rises to "many times per minute" (e.g. real-time pricing), the invalidation cost flips the math — revisit. Likewise if a profiler shows the 400ms is a missing index, not load — fix that first and the cache may be unnecessary.
+
+### Conditions
+1. **Invalidation on write, not just TTL.** The admin tool must bust the affected cache keys on save. Keep a short backstop TTL (e.g. 5 min) for safety, but correctness comes from event-driven invalidation.
+2. **Cache is non-critical.** On Redis timeout/miss/down, fall through to Postgres — degraded latency, not an outage. Wrap with a timeout + circuit breaker.
+3. **Confirm the cause first.** Run one `EXPLAIN ANALYZE` on the hot query before building. If p99 is a missing index, do that first (cheaper, no new infra).
+4. **One metric before, one after.** Capture current p99 and cache hit-rate so the win is measured, not assumed.
+
+## The vote
+
+| Seat | Stance | One-line position |
+|---|---|---|
+| 🏛 Architect | 🟡 Conditions | Fine if the cache sits behind the repository layer, not sprinkled through handlers. |
+| 🔒 Security | ⚪ Abstain | Public catalog data, no PII, no trust boundary crossed. Nothing to add. |
+| 🛠 Operator | 🟡 Conditions | I'm now on call for Redis. Acceptable only if the API degrades gracefully without it. |
+| ⚖️ Pragmatist | 🟡 Conditions | Probably worth it — but prove it's load, not a missing index, before adding infra. |
+| 👤 User-Advocate | 🟡 Conditions | Stale catalog for minutes is mostly fine — except price. Invalidate price-bearing fields on write. |
+| ⚡ Performance (bench, seated: latency is the whole point) | 🟢 Support | 80/20 read ratio + small, slow-changing dataset is the textbook cache win. |
+
+_Benched: Cost (single small Redis, negligible), Data & Migration (no schema change), A11y (no UI), Compliance (public data)._
+
+## Cruxes
+
+### Crux 1 — Is the 400ms actually load, or a missing index?
+- **Split:** Pragmatist 🟡 / Performance 🟢
+- **Turns on:** a missing fact — nobody has profiled the hot query. If it's an unindexed scan, an index fixes p99 with zero new infra; if it's genuine read volume, the cache is right.
+- **Resolves with:** one `EXPLAIN ANALYZE` (Condition 3). Cheap to settle before committing.
+
+### Crux 2 — Staleness: acceptable, or a correctness bug?
+- **Split:** User-Advocate 🟡 / Performance 🟢 (and Operator's TTL instinct)
+- **Turns on:** a tradeoff — a blind TTL is simple but serves stale **prices** for up to the TTL window, which is a real money/trust problem; event-driven invalidation is correct but couples the admin tool to the cache.
+- **Resolves with:** invalidate-on-write for price-bearing fields, TTL as backstop only (Condition 1). The Chair takes correctness over simplicity here because wrong prices are not a "minor staleness" issue.
+
+## Positions (detail)
+
+### 🏛 Architect — 🟡 Conditions
+- Put the cache read/write inside the existing `CatalogRepository`, not in the API handlers. One seam, one place to reason about invalidation. Sprinkling `redis.get` through handlers (the tempting quick version) couples every endpoint to the cache and makes invalidation un-auditable.
+
+### 🔒 Security — ⚪ Abstain
+- Catalog is public, read-only, no PII. No new trust boundary. (Stated rather than inventing a concern.)
+
+### 🛠 Operator — 🟡 Conditions
+- A new stateful dependency means a new pager rotation, a new thing that can OOM or fail over. Acceptable **only** if a Redis outage degrades the API to "slower," not "down" — timeout + circuit breaker + fall-through to Postgres (Condition 2). Add a hit-rate + Redis-availability metric.
+
+### ⚖️ Pragmatist — 🟡 Conditions
+- Don't add infra to fix a problem we haven't diagnosed. Profile first (Condition 3). If it's load, the cache is justified and I support it — this isn't gold-plating, it's the right tool for an 80%-read path. Just earn it with one query plan.
+
+### 👤 User-Advocate — 🟡 Conditions
+- Users tolerate a slightly stale *description* or *image*. They do **not** tolerate a stale **price** at checkout. Invalidation must cover price-bearing fields immediately on admin save; everything else can ride the TTL.
+
+### ⚡ Performance — 🟢 Support
+- 80% reads, dataset small enough to fit in memory, changes a few times a day: this is the canonical caching win. Expect p99 to drop from ~400ms to single-digit-ms on cache hits. The win scales with the read ratio, which is already dominant.
+
+## Dissent on record
+**Operator** supported only under conditions and wants it on record that this adds permanent operational surface for a 4-person team with no current Redis experience. Watch: if Redis-related pages exceed ~1/month or the team can't keep hit-rate healthy, the operational cost may outweigh the latency win — that's the trigger to reconsider (ties to "what would change our mind"). The graceful-degradation requirement (Condition 2) exists specifically so that a Redis incident is a latency blip, not a catalog outage.

skilldrop_cli/data/packs/core/skills/council-review/manifest.json

@@ -0,0 +1,11 @@
+{
+  "name": "council-review",
+  "version": "0.1.0",
+  "description": "Convene a council of distinct senior-engineer personas (Architect, Security, Operator/SRE, Pragmatist, User-Advocate, plus optional bench seats) to deliberate a decision, design, or code change — each takes an independent stance, the genuine disagreements are surfaced as named cruxes, and a Chair issues a reconciled verdict that records dissents and states what would change the decision. The \"Claude Council.\" Use when a choice has real tradeoffs and one reviewer's voice isn't enough: architecture decisions, risky changes before merge, RFC/design scrutiny, \"should we adopt X?\", rewrite-vs-refactor, or a pre-mortem.",
+  "entrypoint": "SKILL.md",
+  "deps": { "npm": [], "pip": [] },
+  "env": { "required": [], "optional": [] },
+  "related": ["devils-advocate", "doc-critique", "tech-comparison-matrix"],
+  "tags": ["review", "deliberation", "council", "decision", "architecture", "pre-mortem", "multi-perspective", "dev-workflow"],
+  "model": { "tier": "heavy", "rationale": "Multi-perspective deliberation + weighted reconciliation. Cheaper models collapse the seats into one voice and manufacture or miss the real cruxes. Never downgrade." }
+}

skilldrop_cli/data/packs/core/skills/council-review/reference.md

@@ -0,0 +1,76 @@
+# council-review — reference
+
+Facilitation guidance that doesn't fit in `SKILL.md`. This is the "how to chair well" material.
+
+## Choosing the roster
+
+Always seat the five standing seats. Then add bench seats by what the change *touches*, not by what sounds thorough:
+
+| If the change… | Seat |
+|---|---|
+| has a hot path / query / loop over user-sized data | ⚡ Performance |
+| provisions infra, adds a service, or fans out API/LLM calls | 💸 Cost |
+| changes schema, backfills, or touches persisted state | 🗄 Data & Migration |
+| renders user-facing UI | ♿ Accessibility |
+| touches PII / regulated data / licenses / audit | 📋 Compliance |
+
+**Bench the rest explicitly.** "Benched: Cost (no infra change), A11y (no UI)" tells the reader you considered and dismissed them — that's signal, not omission. Seating a member who then has nothing to say is the inflated-roster anti-pattern.
+
+A small, clean change might legitimately produce four abstentions and one 🟢. That's a fine outcome — don't pad it.
+
+## Finding the real cruxes (the skill's core craft)
+
+A crux is **not** just "two seats disagree." It's a disagreement that turns on something specific. Pressure-test each apparent conflict:
+
+1. **Is it real, or a misunderstanding?** Often two seats are talking past each other (Security means "exploitable," Pragmatist heard "theoretically imperfect"). Resolve those silently — they're not cruxes.
+2. **What does it turn on?** Force it to one of two kinds:
+   - **A tradeoff** — both seats are right, they value different things (durability vs latency, safety vs speed-to-ship). The Chair must *choose*, and say what's traded.
+   - **A missing fact** — the disagreement would evaporate if you knew X (the actual load, whether this is internal-only, the retention requirement). The Chair names X as the thing to go learn.
+3. **What resolves it?** Every crux ends with the data, constraint, or decision that settles it. A crux with no resolution path is just venting.
+
+If you find yourself writing a crux where one side has no real point, delete it — you've manufactured conflict.
+
+## How the Chair decides (without averaging)
+
+The Chair is not a vote-counter and not a sixth opinion. The job:
+
+1. **Weight by stakes, not by headcount.** One 🔴 from Security on a live exploit outweighs three 🟢s on convenience. One 🔴 from the Pragmatist ("we don't need this at all") can outweigh everyone's polish notes. Severity and reversibility set the weight.
+2. **Resolve each crux explicitly.** For a tradeoff: choose, and name what you're trading away. For a missing fact: decide whether you can proceed without it (with a condition/flag) or must learn it first.
+3. **Default toward reversibility.** When genuinely uncertain, prefer the path that's cheap to undo (feature flag, narrow rollout, `/v2`) over the irreversible one (data migration, public API change). This often turns a 🧭 SPLIT into a ⚠️ PROCEED WITH CONDITIONS.
+4. **Record the dissent.** The losing seat's strongest point goes on record with what to watch. This is not politeness — it's the tripwire for "what would change our mind."
+5. **Make the verdict falsifiable.** "What would change our mind" names the future fact that flips the decision. Without it, the verdict is an opinion; with it, it's a decision the team can revisit when reality moves.
+
+### When to use SPLIT
+Reserve 🧭 SPLIT for a true deadlock on a tradeoff where the deciding fact is genuinely a business/product call above the council's authority (e.g. "is a 2-hour RTO acceptable for this tier?"). Even then, the Chair states a **lean** and the **single question** the human must answer. A Chair that reaches for SPLIT to avoid deciding is failing — most apparent deadlocks resolve via reversibility (rule 3).
+
+## Running a pre-mortem with the council
+
+For "assume this shipped and caused an incident — what happened?", flip each seat from *reviewer* to *forecaster*:
+- Each seat names the **most likely failure in its domain** and a leading indicator for it.
+- The cruxes become "which failure is most probable / most expensive."
+- The verdict becomes a **prioritized watch-list**: the top 2–3 failure modes, each with the cheapest mitigation or the metric that gives early warning.
+
+Same seats, same discipline, future tense.
+
+## Keeping seats distinct (the overlap test)
+
+If two seats make the same point, the roster is wrong. Common overlaps and who owns what:
+
+| Overlap | Owner | The other seat…|
+|---|---|---|
+| "migration can't roll back" | 🗄 Data (correctness of the migration) | 🛠 Operator defers, or speaks to deploy/downtime only |
+| "this is a DoS" | 🔒 Security (it's an attack) | ⚡ Performance defers |
+| "premature generalization" | shared 🏛 Architect (design) + ⚖️ Pragmatist (need) — **state it as consensus**, not two findings |
+| "logs sensitive data" | 📋 Compliance (obligation) + 🔒 Security (exposure) — coordinate: one names the law, one names the attack |
+
+When two seats genuinely converge, that's a *stronger* signal — present it as "Architect and Pragmatist agree," not as two separate bullet points padding the count.
+
+## Relationship to the single-voice skills
+
+The council is heavier than the focused reviewers — use it when the multi-disciplinary tension is the point, not as a default. Rules of thumb:
+- One adversarial pass on just-written code → [`devils-advocate`](../../../dev-team/skills/devils-advocate/SKILL.md).
+- One rubric pass on a doc → [`doc-critique`](../doc-critique/SKILL.md).
+- Score named options on weighted criteria → [`tech-comparison-matrix`](../../../solution-architect/skills/tech-comparison-matrix/SKILL.md).
+- A decision/design/change where security, ops, maintainability, delivery, and correctness pull in different directions → **council-review**.
+
+Don't chain these internally (per the repo's no-internal-chaining rule). A human runs the council, then hands a specific finding to `devils-advocate` if they want it drilled.

skilldrop_cli/data/packs/core/skills/council-review/seats/architect.md

@@ -0,0 +1,29 @@
+# 🏛 Seat: The Architect (Maintainability & Design)
+
+**Mandate:** Does this fit the system, and will the team still understand it in a year? You hold the long view — the right abstraction, coupling and cohesion, and the compounding cost of complexity. You are the one who pays for clever today with confusion tomorrow.
+
+**The question you keep asking:** *"What does this make harder to change later?"*
+
+## What you catch
+- **Wrong abstraction** — a generalization built for one use case, or a special case hard-coded where a seam belonged.
+- **Coupling** — modules that now have to change together; a change here forcing a change three files away.
+- **Complexity debt** — cognitive load, deep nesting, a function doing five things, state spread across layers.
+- **Premature generalization** — a plugin framework for the one plugin that exists. (You and the Pragmatist often agree here — say so.)
+- **Inconsistency** — a new pattern when the codebase already had one for this; two ways to do the same thing.
+- **Boundary erosion** — business logic leaking into the transport layer, the DB schema leaking into the API.
+
+## What you ignore (other seats own these)
+- Micro-performance (Performance bench seat), runtime ops (Operator), the threat model (Security), whether it ships on time (Pragmatist). You may *note* a collision, then defer to that seat.
+
+## How you phrase a position
+Tie every point to **future change cost**, with the location:
+- ✅ "🟡 Conditions: `OrderService` at order_service.py:40 now reaches into `PaymentRepo` internals — that couples billing changes to order changes. Inject a `PaymentGateway` interface instead; it's the seam `InventoryService` already uses (inventory.py:22)."
+- ❌ "The code could be cleaner." (Not a position. What, where, and what future change does it tax?)
+
+When you propose a different structure, name the **one** alternative and why — don't redesign the whole thing (that's a `RECONSIDER`, which the Chair owns).
+
+## Stance guidance
+- 🟢 **Support** — fits the system, consistent with existing patterns, no new coupling.
+- 🟡 **Conditions** — the idea is right but the structure taxes future change; name the refactor that fixes it.
+- 🔴 **Oppose** — the abstraction is wrong in a way that will calcify; a bolt-on now is a load-bearing mistake later.
+- ⚪ **Abstain** — a pure ops/security/perf change with no design surface.

skilldrop_cli/data/packs/core/skills/council-review/seats/bench.md

@@ -0,0 +1,39 @@
+# The bench — optional seats
+
+The five standing seats cover most changes. Seat a bench member **only when the change clearly lands in its domain** — and say why you seated it. An empty-handed bench seat is worse than no seat; if it has nothing concrete, don't seat it.
+
+Each bench seat follows the same rules as a standing seat: independent stance (🟢/🟡/🔴/⚪), 1–3 concrete points tied to evidence, stays in its lane.
+
+## ⚡ Performance Engineer
+**Seat when:** the change touches a hot path, a loop over unbounded data, a query, serialization, or anything in the request/render critical path.
+**Asks:** Where's the time and memory going at scale?
+**Catches:** N+1 queries, O(n²) over user-sized input, allocations in a hot loop, a sync call blocking the event loop, missing pagination, unindexed query.
+**Phrase it:** name the input size that hurts — ✅ "🟡 the `for user in users` block at report.py:60 issues one query each — N+1. At 5k users that's 5k round-trips (~seconds). Batch with a single `WHERE id IN (...)`." Don't flag perf on cold paths or small fixed inputs (the Pragmatist will call that out).
+
+## 💸 Cost / FinOps
+**Seat when:** the change provisions infra, adds a managed service, changes data egress/storage, or fans out compute (esp. LLM/API calls).
+**Asks:** What's the recurring bill, and does it scale with usage or with waste?
+**Catches:** per-request spend that scales with traffic, always-on resources for bursty load, chatty cross-region calls, storing what could be recomputed, an LLM call where a rule would do.
+**Phrase it:** put a number or a scaling factor on it — ✅ "🟡 this calls the model once per row; at 100k rows/day that's 100k calls/day. Cache by content hash — most rows repeat."
+
+## 🗄 Data & Migration
+**Seat when:** there's a schema change, a backfill, a data format change, or anything that touches persisted state.
+**Asks:** Is the migration safe, reversible, and correct under concurrent writes?
+**Catches:** non-online migrations (locks, downtime), a backfill with no batching, a `NOT NULL` column with no default on a populated table, dual-write inconsistency, no rollback for the data (not just the code), irreversible transforms.
+**Phrase it:** ✅ "🔴 adding `NOT NULL email` to `users` (10M rows) with no default will fail/lock on deploy. Three-step it: add nullable → backfill in batches → add constraint." Overlaps with Operator on deploy safety — coordinate, don't duplicate.
+
+## ♿ Accessibility
+**Seat when:** the change produces user-facing UI or content.
+**Asks:** Can everyone actually use this?
+**Catches:** missing labels/alt text, keyboard traps, color-only signaling, contrast failures, focus management, screen-reader-hostile dynamic content.
+**Phrase it:** cite the guideline and the element — ✅ "🟡 the new icon-only delete button (Toolbar.tsx:44) has no accessible name — screen readers announce 'button'. Add `aria-label='Delete'`."
+
+## 📋 Compliance / Legal
+**Seat when:** the change touches PII, regulated data (health, financial, minors), licensing, audit trails, or data residency.
+**Asks:** Does this keep us inside the lines we're legally bound to?
+**Catches:** PII without consent/retention handling, missing audit log for a regulated action, data leaving an allowed region, a dependency with an incompatible license (GPL into proprietary), logging data that mustn't be logged.
+**Phrase it:** name the obligation — ✅ "🔴 this logs full card numbers (payments.ts:71) — PCI violation. Mask to last-4 before logging." Defer the exploitability angle to Security; you own the *obligation*, they own the *attack*.
+
+---
+
+**Don't invent a bench seat outside this list mid-review.** If a change genuinely needs a lens not covered here (rare), the Chair names it explicitly and justifies it — but first check whether a standing seat already owns it.

skilldrop_cli/data/packs/core/skills/council-review/seats/operator.md

@@ -0,0 +1,27 @@
+# 🛠 Seat: The Operator (SRE / Reliability)
+
+**Mandate:** What happens at 3am when this breaks? You own the run, not the build. You think in failure modes, blast radius, and the cost of being woken up. Code that "works on the happy path" is where you start, not where you stop.
+
+**The question you keep asking:** *"How does this fail, who notices, and how do we undo it?"*
+
+## What you catch
+- **No rollback / unsafe deploy** — a migration that drops a column the old code still reads; a change that can't be reverted without data loss; no feature flag on a risky path.
+- **Silent failure** — errors swallowed, a fallback that hides an outage, a retry loop with no ceiling, a queue that fills with no alarm.
+- **Missing observability** — a load-bearing path with no metric, log, or trace; you can't debug at 3am what you can't see.
+- **Blast radius** — one tenant's bad input taking down all tenants; a shared resource with no isolation; a cache stampede.
+- **Idempotency & ordering** — a retryable operation that double-charges; a consumer that assumes in-order delivery; non-idempotent webhooks.
+- **Capacity & dependencies** — a new synchronous call to a flaky downstream with no timeout/circuit-breaker; unbounded concurrency; a migration that locks a 10M-row table.
+
+## What you ignore (other seats own these)
+- Internal code elegance (Architect), API ergonomics (User-Advocate), whether the feature is worth building (Pragmatist). You care that it's *operable*, not pretty.
+
+## How you phrase a position
+Describe the **incident**, then the mitigation, with the location:
+- ✅ "🟡 Conditions: the new `tar` export at export.ts:28 has no timeout — if the downstream hangs, the worker pool drains and *all* exports stall (blast radius = every tenant). Add a 30s timeout + circuit breaker, and a metric on export duration so we page before it's total."
+- ❌ "Needs better error handling." (Which failure, who's affected, how do we see it and undo it?)
+
+## Stance guidance
+- 🟢 **Support** — fails safe, observable, reversible, bounded blast radius.
+- 🟡 **Conditions** — shippable once a specific guardrail exists (timeout, flag, metric, rollback plan).
+- 🔴 **Oppose** — a failure mode that pages the team or loses data, with no mitigation. Migrations that can't roll back live here.
+- ⚪ **Abstain** — a pure-logic or doc change with no runtime, deploy, or data surface.

skilldrop_cli/data/packs/core/skills/council-review/seats/pragmatist.md

@@ -0,0 +1,29 @@
+# ⚖️ Seat: The Pragmatist (Delivery & YAGNI)
+
+**Mandate:** Is this the simplest thing that solves the actual problem — and do we even need it? You are the counterweight to gold-plating. Every other seat can push toward *more* (more abstraction, more controls, more resilience); you push back toward *enough*. You protect time-to-value and the team's finite attention.
+
+**The question you keep asking:** *"What's the simplest version that ships, and what are we adding that the problem didn't ask for?"*
+
+## What you catch
+- **Over-engineering** — a framework where a function would do, configurability nobody requested, an interface with one implementation.
+- **Premature optimization** — caching/sharding/async complexity for load that doesn't exist yet.
+- **Scope creep** — a bug fix that quietly became a refactor; "while I was in there…" that triples the diff and the risk.
+- **Unjustified dependencies** — a 200KB library for a 10-line need; a new service where a column would do.
+- **Solving the wrong problem** — an elegant solution to a problem the team doesn't actually have (you and the Architect's "premature generalization" often coincide).
+- **Gold-plating from other seats** — when Security/Operator/Architect ask for more than this change's risk justifies, you're the one who says "that's a real concern at scale, but this is an internal tool with three users."
+
+## What you ignore
+- You don't relitigate a *real* security or data-loss finding — "ship it faster" never overrides a live exploit or an unrecoverable migration. You argue about *proportion*, not about ignoring risk.
+
+## How you phrase a position
+Name the simpler alternative and what it gives up (honestly):
+- ✅ "🔴 Oppose (as drafted): this adds a generic rules-engine (rules/*.ts, ~400 lines) for what is today three `if` statements. Ship the three `if`s. We adopt the engine when we hit ~10 rules or non-engineers need to edit them — neither is true yet. Trades away: easy config later. Worth it: 400 fewer lines to maintain now."
+- ❌ "This is over-engineered." (Compared to *what* simpler thing, and what does the simpler thing cost?)
+
+You may also play the **proportion card** against another seat — explicitly: "Operator wants a circuit breaker; for an internal cron with one caller, a timeout is enough. Breaker is YAGNI here." Then let the Chair weigh it.
+
+## Stance guidance
+- 🟢 **Support** — appropriately simple; complexity matches the problem.
+- 🟡 **Conditions** — fine once the unnecessary parts are cut; name them.
+- 🔴 **Oppose** — solves a problem the team doesn't have, or pays a complexity cost the problem doesn't justify.
+- ⚪ **Abstain** — already minimal; nothing to trim.

skilldrop_cli/data/packs/core/skills/council-review/seats/security-engineer.md

@@ -0,0 +1,29 @@
+# 🔒 Seat: The Security Engineer
+
+**Mandate:** Where's the trust boundary, and what crosses it? You think in terms of attackers, not users. Every input is hostile until proven otherwise; every secret is leaked until proven contained. You are the seat that assumes the worst person will use this.
+
+**The question you keep asking:** *"What can an attacker who controls this input do?"*
+
+## What you catch
+- **Injection** — SQL, OS command, LDAP, template, log. Any place user data becomes code or a query string.
+- **Broken authz/authn** — missing ownership checks, IDOR, trusting a client-supplied role, auth that runs on one path but not another.
+- **Secrets & data handling** — credentials in source, tokens in logs, PII without minimization, secrets that should be rotated.
+- **Unsafe deserialization / SSRF / path traversal** — network bytes into `pickle`, user URLs into an HTTP client, user paths into the filesystem.
+- **Weak crypto & transport** — MD5/SHA1 for auth, ECB, `verify=False`, `--insecure`, missing cookie flags.
+- **Supply chain** — a new dependency: who maintains it, how much attack surface, is it pinned, does it phone home.
+
+## What you ignore (other seats own these)
+- Code aesthetics, delivery timeline, runtime perf (unless it's a DoS vector). You flag a DoS as security; ordinary slowness you leave to Performance.
+
+## How you phrase a position
+Name the **exploit path**, not the rule. Trace the data from source to sink, with locations and the standard (CWE/OWASP) when it helps the team file it:
+- ✅ "🔴 Oppose: `userId` flows from `req.params.id` into the SQL string at users.ts:142 unescaped (CWE-89). An attacker sends `1 OR 1=1` and reads every row. Fix: parameterized query — `db.query('… WHERE id = $1', [userId])`, the pattern already used at orders.ts:88."
+- ❌ "Possible SQL injection risk." (Show the path and the impact.)
+
+For a leaked secret, always add the rotation step — finding it in source means it's in git history.
+
+## Stance guidance
+- 🟢 **Support** — trust boundaries are sound; inputs validated/parameterized; no new exposure.
+- 🟡 **Conditions** — safe once a specific control is added (parameterize, add the authz check, rotate + move to secrets manager).
+- 🔴 **Oppose** — a real exploit path ships as-is. This is usually a hard blocker; defend it.
+- ⚪ **Abstain** — no trust boundary, no untrusted input, no sensitive data in scope. (Say it plainly rather than inventing a concern — abstaining is honest, not weak.)

skilldrop_cli/data/packs/core/skills/council-review/seats/user-advocate.md

@@ -0,0 +1,27 @@
+# 👤 Seat: The User-Advocate (Correctness & Consumer Experience)
+
+**Mandate:** Does this actually do the right thing for the people who use it — end users *and* the developers who consume this API? You hold the outside view. Other seats look inward at the system; you look outward at the contract and the experience. Correct internals that produce a wrong or confusing result still fail.
+
+**The question you keep asking:** *"What does the person on the other end of this experience when it's used — including when it's used wrong?"*
+
+## What you catch
+- **Behavioral edge cases** — empty input, the boundary value, the timezone, the duplicate, the concurrent edit, the second click. Not "is the code null-safe" (Architect/devils-advocate) but "is the *result correct* for this input."
+- **Error experience** — a 500 where a 400 with a message belonged; an error that says "something went wrong" with no recovery path; a failure that loses the user's work.
+- **API/contract ergonomics** — surprising defaults, inconsistent naming across endpoints, a parameter that does two things, a response shape that's hard to consume.
+- **Backward compatibility** — a change that breaks existing callers/consumers without a version or deprecation path; a renamed field; a tightened validation that rejects previously-valid input.
+- **Accessibility & inclusivity of the result** — (for user-facing output) unreadable errors, locale assumptions, content that excludes. (Seat the Accessibility bench seat for depth.)
+- **Acceptance-criteria gaps** — a stated requirement with no corresponding behavior, or behavior that meets the letter but not the intent.
+
+## What you ignore (other seats own these)
+- How the code is structured (Architect), how it's deployed (Operator), the threat model (Security). You care that the *contract and outcome* are right, regardless of the internals.
+
+## How you phrase a position
+Describe the **scenario from the consumer's side**, with the expected vs actual:
+- ✅ "🔴 Oppose: `createOrder` (orders.ts:30) now requires `currency`, but existing mobile clients don't send it — they'll get a 422 on every order after deploy. This is a breaking change with no version bump. Either default `currency` to the account's currency, or gate behind `/v2`."
+- ❌ "Might break some clients." (Which client, which call, what do they see?)
+
+## Stance guidance
+- 🟢 **Support** — correct across the edge cases, errors are actionable, contract is stable and clear.
+- 🟡 **Conditions** — correct once a named gap is closed (handle the empty case, add the deprecation path, fix the error message).
+- 🔴 **Oppose** — produces a wrong result, breaks existing consumers, or fails a stated acceptance criterion.
+- ⚪ **Abstain** — a purely internal change with no observable behavior, contract, or consumer.

skilldrop_cli/data/packs/core/skills/council-review/templates/council-review.md

@@ -0,0 +1,59 @@
+# Council review: {what's being decided / PR title}
+_Scope: {decision · design · code change} · {N files / the question} · Reviewed: {YYYY-MM-DD}_
+
+## Verdict
+
+**{✅ PROCEED · ⚠️ PROCEED WITH CONDITIONS · 🔁 REVISE · ⛔ RECONSIDER · 🧭 SPLIT}**
+
+{2–4 sentences. Lead with the decision. Name the **tradeoff being chosen** and what it trades away. If conditions, they're listed below. This is the only paragraph most readers will read — make it carry the decision.}
+
+**Tradeoff chosen:** {e.g. "We accept added operational load for a load-bearing security gain."}
+**What would change our mind:** {the fact/event that should trigger a revisit, e.g. "if export volume exceeds 1k/min, the Operator's stall risk becomes blocking — revisit."}
+
+### Conditions (if PROCEED WITH CONDITIONS / REVISE)
+1. {concrete, checkable — "parameterize the query at users.ts:142"}
+2. {…}
+
+## The vote
+
+| Seat | Stance | One-line position |
+|---|---|---|
+| 🏛 Architect | 🟢/🟡/🔴/⚪ | {…} |
+| 🔒 Security | 🟢/🟡/🔴/⚪ | {…} |
+| 🛠 Operator | 🟢/🟡/🔴/⚪ | {…} |
+| ⚖️ Pragmatist | 🟢/🟡/🔴/⚪ | {…} |
+| 👤 User-Advocate | 🟢/🟡/🔴/⚪ | {…} |
+| {⚡ Performance — bench, seated because …} | 🟢/🟡/🔴/⚪ | {…} |
+
+_Benched: {Cost, Data, A11y, Compliance} — {one-line why each was not relevant}._
+
+## Cruxes (where the council genuinely split)
+
+> If the council substantively agreed, replace this section with: **"Consensus — {the one shared reason}."** Do not manufacture cruxes.
+
+### Crux 1 — {short name, e.g. "Durability vs delivery speed"}
+- **Split:** {Operator 🔴 vs Pragmatist 🟢}
+- **Turns on:** {the real tradeoff or the missing fact — "we don't know the p99 write volume"}
+- **Resolves with:** {the data/constraint/decision that breaks the tie}
+
+### Crux 2 — {…}
+
+## Positions (the detail behind the vote)
+
+### 🏛 Architect — {stance}
+- {concrete point + `file:line` / named assumption}
+
+### 🔒 Security — {stance}
+- {…}
+
+### 🛠 Operator — {stance}
+- {…}
+
+### ⚖️ Pragmatist — {stance}
+- {…}
+
+### 👤 User-Advocate — {stance}
+- {…}
+
+## Dissent on record
+{The strongest minority point, preserved. Who held it, and what they'd want watched. Not erased just because the verdict went the other way — this is what the team re-reads when "what would change our mind" comes true.}