skilldrop-cli 0.16.11 → 0.16.13

package/packs/data-analytics/pack.json

@@ -1,7 +1,7 @@
 {
-  "description": "For analysts and the people who rely on their numbers: define a metric once so everyone gets the same figure, review SQL for the bugs that quietly inflate it, and spec dashboards around a decision instead of every chart that was easy to make.",
+  "description": "For analysts and the people who rely on their numbers: review SQL for the bugs that quietly inflate a figure, and spec dashboards around a decision instead of every chart that was easy to make.",
   "display_name": "Data and analytics",
-  "keywords": ["metrics", "sql", "dashboard", "semantic-layer", "dbt", "bi", "analytics"],
+  "keywords": ["metrics", "sql", "dashboard", "dbt", "bi", "analytics"],
   "links": {
     "documentation": "https://sananthanarayan.github.io/skilldrop/packs/data-analytics/"
   },
@@ -23,35 +23,29 @@
     "when": "A number matters (a board metric, a finance figure, a team KPI) and people either disagree about it or are about to build a dashboard on it.",
     "you_bring": [
       "the metric name and the question it answers",
-      "the tables it comes from, and any SQL or dashboard already computing it",
+      "the SQL or dashboard already computing it, and the tables it reads",
       "who reads it and what they decide",
       "the database engine (Postgres, BigQuery, Snowflake, …)"
     ],
     "steps": [
-      {
-        "skill": "metric-definition",
-        "you_do": "Give it the metric, the sources, and any existing SQL.",
-        "you_get": "One written definition: exact formula, grain, window and timezone, exclusions with predicates, allowed dimensions, edge cases, owner, reference SQL and sanity checks.",
-        "decide": "Confirm the open decisions (timezone, exclusions, lock period) with the metric's owner."
-      },
       {
         "skill": "sql-review",
-        "you_do": "Run it on the definition's reference SQL, or on any query that already reports the number.",
+        "you_do": "Run it on the query that reports the number, with the engine and what one output row should represent.",
         "you_get": "A verdict and line-by-line findings, each with the wrong result and corrected SQL, plus the full corrected query and verification queries.",
-        "decide": "Certify the metric, or fix the SQL and review again."
+        "decide": "Trust the number, or fix the SQL and review again. If the findings turn on what the number should mean (timezone, exclusions), settle that with the metric's owner first."
       },
       {
         "skill": "dashboard-spec",
         "you_do": "Give it the audience, the decision and the list of requested charts.",
-        "you_get": "A one-page spec: questions in priority order, one chart per question built on your defined metrics, filters, freshness SLA, layout, and a cut list."
+        "you_get": "A one-page spec: questions in priority order, one chart per question with its metric named and any undefined one flagged as a build blocker, filters, freshness SLA, layout, and a cut list."
       },
       {
         "skill": "doc-critique",
-        "you_do": "Run it on the metric spec or dashboard spec before sharing it with the BI team.",
+        "you_do": "Run it on the dashboard spec before sharing it with the BI team.",
         "you_get": "A verdict and severity-tagged findings with a fix for each.",
         "decide": "Hand the spec to the builder, or revise it."
       }
     ],
-    "you_end_with": "A certified metric definition with reviewed reference SQL, and a dashboard spec a BI developer can build without guessing."
+    "you_end_with": "Reviewed SQL whose number you can defend, and a dashboard spec a BI developer can build without guessing."
   }
 }

package/packs/data-analytics/skills/dashboard-spec/SKILL.md

@@ -27,7 +27,7 @@ Writes the one-page brief a BI developer builds from, so the dashboard answers t
 
    ✅ *"Sorted horizontal bar, because the question is which queue is worst and a ranked bar answers that at a glance."* No pies for more than three parts, no dual axes, no 3D. Every number tile shows a comparison (against target, last period, or the same period last year). A bare number can't tell anyone whether to act.
 
-5. **Name the metric behind each chart by its `metric-definition` name**, with the grain, the time window and the comparison. ✅ `first_response_hours_p90` · daily · last 8 weeks · vs target 4h. A metric with no written definition is flagged `undefined: needs a spec before build`. That's a build blocker, not a detail for the BI developer to settle by guessing.
+5. **Name the metric behind each chart by its defined name**, with the grain, the time window and the comparison. ✅ `first_response_hours_p90` · daily · last 8 weeks · vs target 4h. A metric with no written definition is flagged `undefined: needs a spec before build`. That's a build blocker, not a detail for the BI developer to settle by guessing.
 
 6. **Set the filters**, at most four global ones with their default values. Only offer a filter on a dimension each affected metric can be sliced by. A filter that fans out a metric (product category on order-level revenue) is left off with a note saying why.
 
@@ -66,7 +66,7 @@ Writes the one-page brief a BI developer builds from, so the dashboard answers t
 
 ## When NOT to use this skill
 
-- ❌ Defining how one metric is calculated (formula, filters, timezone) — that's `metric-definition`
+- ❌ Defining how one metric is calculated (formula, filters, timezone) — that's the metric owner's call; this skill flags the gap, it doesn't fill it
 - ❌ Choosing which metric judges a feature, with targets and a decision rule — that's `success-metrics`
 - ❌ Service health dashboards, SLOs and alerting — that's `observability-plan`
 - ❌ A report on AI tool usage from telemetry logs — that's `ai-usage-report`

package/packs/data-analytics/skills/dashboard-spec/examples/support-staffing.md

@@ -79,6 +79,6 @@ Left off as filters: channel and tag. A ticket can carry several tags, so a tag
 
 ## Open questions
 
-- [ ] Incoming tickets needs a `metric-definition` spec (created time, merged and spam tickets). Owner: support operations lead.
+- [ ] Incoming tickets needs a written definition (created time, merged and spam tickets). Owner: support operations lead.
 - [ ] Tickets handled per agent-week needs a spec (what "handled" means, part-time agents). Owner: support operations lead.
 - [ ] Confirm the dashboard owner.

package/packs/data-analytics/skills/dashboard-spec/manifest.json

@@ -1,6 +1,6 @@
 {
   "name": "dashboard-spec",
-  "version": "0.1.0",
+  "version": "0.1.1",
   "description": "Spec a dashboard before anyone builds it — the audience and the decision it serves, the questions in priority order, one chart per question with the chart type and why, the defined metric behind each chart, filters, refresh cadence and freshness SLA, and a list of what is deliberately left off, with vanity metrics cut. Use when the user says \"spec a dashboard\", \"what should go on our KPI dashboard\", \"the BI team needs requirements for a dashboard\", \"our dashboard has 40 charts and nobody uses it\", or \"design the exec dashboard\".",
   "entrypoint": "SKILL.md",
   "deps": {
@@ -13,18 +13,9 @@
   },
   "related": [
     "ai-usage-report",
-    "metric-definition",
     "observability-plan",
     "success-metrics"
   ],
-  "handoff": [
-    {
-      "to": "metric-definition",
-      "when": "a chart's metric has no written definition",
-      "purpose": "Define the metric's formula, grain, window and exclusions so the BI developer doesn't guess.",
-      "fallback": "If metric-definition is absent, mark the metric undefined in the chart table and list the definitional questions (numerator, denominator, timezone, exclusions) under open questions."
-    }
-  ],
   "tags": [
     "dashboard",
     "bi",

package/packs/data-analytics/skills/dashboard-spec/templates/dashboard-spec.md

@@ -51,5 +51,5 @@ Left off as filters: <dimension> — <why, e.g. fans out order-level metrics>
 
 ## Open questions
 
-- [ ] <undefined metric> — needs a `metric-definition` spec, owner <role>
+- [ ] <undefined metric> — needs a written definition (numerator, denominator, timezone, exclusions), owner <role>
 - [ ] <data gap or unconfirmed target>

package/packs/data-analytics/skills/sql-review/SKILL.md

@@ -67,8 +67,8 @@ Reviews a query the way a skeptical analyst would before trusting its output: fi
 
 ## When NOT to use this skill
 
-- ❌ Deciding what a metric should mean (formula, filters, owner) — that's `metric-definition`; this skill checks that SQL computes it correctly
-- ❌ Designing tables, keys and indexes from access patterns — that's `db-schema-design`
+- ❌ Deciding what a metric should mean (formula, filters, owner) — that's the metric owner's call; this skill checks that SQL computes it correctly
+- ❌ Designing tables, keys and indexes from access patterns — this reviews queries against a schema, not the schema
 - ❌ Agreeing a dataset's schema, quality SLAs and change policy with its consumers — that's `data-contract`
 - ❌ General application code review, including SQL built in application code for security — that's `pre-merge-review`
 

package/packs/data-analytics/skills/sql-review/manifest.json

@@ -1,6 +1,6 @@
 {
   "name": "sql-review",
-  "version": "0.1.0",
+  "version": "0.1.1",
   "description": "Review a SQL query for correctness first and performance second — join fan-out inflating sums, NULL traps in filters and NOT IN, timezone and date-boundary errors, integer division, DISTINCT hiding a bad join, window-frame defaults, implicit casts, non-sargable predicates and missing partition filters — with each finding tied to a line, the wrong number it produces, and corrected SQL for the named dialect. Use when the user pastes a query and asks \"is this right\", \"review my SQL\", \"why is this number too high\", \"check this before it goes in the dashboard\", or \"make this query faster\".",
   "entrypoint": "SKILL.md",
   "deps": {
@@ -13,18 +13,8 @@
   },
   "related": [
     "data-contract",
-    "db-schema-design",
-    "metric-definition",
     "pre-merge-review"
   ],
-  "handoff": [
-    {
-      "to": "metric-definition",
-      "when": "the review finds the query's filters or formula disagree with what the business means, and no written definition exists",
-      "purpose": "Agree the metric's formula, grain, window and exclusions before fixing the SQL to match.",
-      "fallback": "If metric-definition is absent, list the definitional questions (numerator, denominator, timezone, exclusions) in the review's assumptions and mark the affected findings as pending a decision."
-    }
-  ],
   "tags": [
     "sql",
     "analytics",

package/packs/dev-team/skills/migration-plan/SKILL.md

@@ -53,7 +53,7 @@ Plans the road from current state to target state so that at every moment the sy
 ## When NOT to use this skill
 
 - ❌ A change deployable in one reversible step — normal deploy, no plan needed
-- ❌ Choosing the target ("should we move to DynamoDB?") — that's `tech-comparison-matrix`; this skill starts after the decision
+- ❌ Choosing the target ("should we move to DynamoDB?") — this skill starts after the decision
 - ❌ The test depth itself — emit gates here, hand verification design to `test-plan-generator`
 - ❌ Organizational/process migrations with no system state — different problem
 

package/packs/dev-team/skills/migration-plan/manifest.json

@@ -1,11 +1,11 @@
 {
   "name": "migration-plan",
-  "version": "0.1.0",
+  "version": "0.1.1",
   "description": "Generate a phased migration or rollout plan (schema change, API version, datastore swap, platform move, auth-provider switch) — expand→migrate→contract by default, every phase reversible or its point of no return named, observable gates between phases, idempotent backfill with parity checks. Use when the user needs a migration plan, cutover plan, rollout strategy, or asks \"how do we get from X to Y without downtime\".",
   "entrypoint": "SKILL.md",
   "deps": { "npm": [], "pip": [] },
   "env": { "required": [], "optional": [] },
-  "related": ["council-review", "tech-comparison-matrix", "test-plan-generator"],
+  "related": ["council-review", "test-plan-generator"],
   "tags": ["migration", "rollout", "cutover", "backfill", "zero-downtime", "deployment"],
   "model": { "tier": "standard", "rationale": "Phased plan synthesis with a strong template. Ordering judgment is bounded by the expand/migrate/contract pattern; escalate via ambiguous-input on contested, high-stakes cutovers." }
 }

package/packs/product-manager/skills/business-case/SKILL.md

@@ -5,7 +5,7 @@ description: Build a business case for a build/buy/defer investment decision —
 
 # business-case
 
-Produces the document a sponsor can approve, challenge, or kill on its merits — because every benefit shows its arithmetic, every option includes the one nobody advocates for (doing nothing), and the case names the single assumption that flips the recommendation. Decides *whether to invest*; `tech-comparison-matrix` picks between technologies after, `prd-draft` captures requirements after, `exec-summary` compresses this doc for a board.
+Produces the document a sponsor can approve, challenge, or kill on its merits — because every benefit shows its arithmetic, every option includes the one nobody advocates for (doing nothing), and the case names the single assumption that flips the recommendation. Decides *whether to invest*; picking between technologies comes after, `prd-draft` captures requirements after, `exec-summary` compresses this doc for a board.
 
 ## How to respond
 
@@ -49,7 +49,7 @@ Produces the document a sponsor can approve, challenge, or kill on its merits
 ## When NOT to use this skill
 
 - ❌ The investment decision is already made — go to `prd-draft`
-- ❌ Choosing between technologies for an approved initiative — `tech-comparison-matrix`
+- ❌ Choosing between technologies for an approved initiative — the investment is already decided; compare the options directly
 - ❌ Compressing an existing case for execs — `exec-summary`
 - ❌ Trivial cost ("should we buy a $400/yr tool") — the case costs more than the decision; just decide
 

package/packs/product-manager/skills/business-case/manifest.json

@@ -1,11 +1,11 @@
 {
   "name": "business-case",
-  "version": "0.1.0",
+  "version": "0.1.1",
   "description": "Build a business case for a build/buy/defer investment decision — do-nothing always included as the baseline, benefits quantified as re-runnable calculations with confidence tags, full costs (build + run + opportunity), ranges instead of false precision, and the flip-assumption named. Use when the user needs to justify an investment, write a business case, compare build vs buy vs defer, or get budget/sponsor approval for an initiative.",
   "entrypoint": "SKILL.md",
   "deps": { "npm": [], "pip": [] },
   "env": { "required": [], "optional": [] },
-  "related": ["exec-summary", "prd-draft", "tech-comparison-matrix"],
+  "related": ["exec-summary", "prd-draft"],
   "tags": ["business-case", "investment", "build-vs-buy", "roi", "cost-benefit", "decision"],
-  "model": { "tier": "heavy", "rationale": "Weighted multi-option judgment with a committal recommendation — same failure mode as tech-comparison-matrix: cheaper models mis-weight costs, inflate benefits, and miss the flip-assumption. Never downgrade." }
+  "model": { "tier": "heavy", "rationale": "Weighted multi-option judgment with a committal recommendation: cheaper models mis-weight costs, inflate benefits, and miss the flip-assumption. Never downgrade." }
 }

package/packs/product-manager/skills/strategy-analysis/SKILL.md

@@ -5,7 +5,7 @@ description: Run a strategy framework — SWOT/TOWS, Porter's Five Forces, or PE
 
 # strategy-analysis
 
-Runs the classic strategy frameworks the way a good strategist does and a bad deck doesn't: the framework is chosen to fit the question, every cell carries evidence and an implication, and the output ends in ranked, committal so-whats — not a filled-in grid. The grid is the working, never the deliverable. Sibling of `tech-comparison-matrix` (tech selection between named options) and `business-case` (a costed invest/defer decision); this skill is for the strategic question *before* options are named.
+Runs the classic strategy frameworks the way a good strategist does and a bad deck doesn't: the framework is chosen to fit the question, every cell carries evidence and an implication, and the output ends in ranked, committal so-whats — not a filled-in grid. The grid is the working, never the deliverable. Sibling of `business-case` (a costed invest/defer decision); this skill is for the strategic question *before* options are named.
 
 ## How to respond
 
@@ -36,7 +36,7 @@ Runs the classic strategy frameworks the way a good strategist does and a bad de
 
 4. **Rank the implications and commit.** End with **Implications, ranked** — 3–5 entries ordered by impact on the named decision, each an action-shaped sentence with an owner-shaped subject: ✅ *"Price the enterprise tier before Q3: supplier power is rising (🟥) and the S×O attack window closes when the incumbent's contract cycle renews"*. Then a one-paragraph **verdict** answering the user's actual question, taking a side, and naming what evidence would change it.
 
-5. **Emit in one message**: evidence base (tag summary), the framework grid(s), ranked implications, verdict. Flag every `[assumption]` that appears in a top-3 implication — those are the validation targets. Hand off: options now named and comparable → `tech-comparison-matrix`; investment decision to cost → `business-case`; product direction to test → `prfaq`.
+5. **Emit in one message**: evidence base (tag summary), the framework grid(s), ranked implications, verdict. Flag every `[assumption]` that appears in a top-3 implication — those are the validation targets. Hand off: investment decision to cost → `business-case`; product direction to test → `prfaq`.
 
 ## Quality bar
 
@@ -56,7 +56,7 @@ Runs the classic strategy frameworks the way a good strategist does and a bad de
 
 ## When NOT to use this skill
 
-- ❌ Choosing between named technologies or vendors — `tech-comparison-matrix`
+- ❌ Choosing between named technologies or vendors — the strategic question is already answered; compare the options directly
 - ❌ A costed build/buy/defer decision — `business-case`
 - ❌ Testing a specific product concept — `prfaq`
 - ❌ Quarterly goal-setting — `okr-cascade`

package/packs/product-manager/skills/strategy-analysis/evals/evals.json

@@ -11,7 +11,7 @@
         "Implications section is ranked (3-5 entries) and each is action-shaped, tied to the two-quarter focus decision",
         "A verdict paragraph takes a side and names what evidence would change it",
         "Assumptions appearing in top-ranked implications are flagged as validation targets",
-        "A hand-off to tech-comparison-matrix, business-case, or prfaq is offered where apt"
+        "A hand-off to business-case or prfaq is offered where apt"
       ]
     },
     {

package/packs/product-manager/skills/strategy-analysis/manifest.json

@@ -1,13 +1,12 @@
 {
   "name": "strategy-analysis",
-  "version": "0.1.2",
+  "version": "0.1.3",
   "description": "Run a strategy framework — SWOT/TOWS, Porter's Five Forces, or PESTLE — on a product, company, or market question, choosing the right framework for the question and forcing every cell to carry evidence and a so-what. Use when the user asks for a SWOT, a competitive/market analysis, \"should we enter this market\", \"what's our position against X\", or a macro-environment scan.",
   "entrypoint": "SKILL.md",
   "deps": { "npm": [], "pip": [] },
   "env": { "required": [], "optional": [] },
-  "related": ["business-case", "okr-cascade", "prfaq", "tech-comparison-matrix"],
+  "related": ["business-case", "okr-cascade", "prfaq"],
   "handoff": [
-    { "to": "tech-comparison-matrix", "when": "the options are named and need comparing on stated criteria", "purpose": "Score the named options against weighted criteria.", "fallback": "If tech-comparison-matrix is absent, build a plain criteria-by-option table inline and state the weights." },
     { "to": "business-case", "when": "the direction is chosen and needs costing before approval", "purpose": "Cost the chosen option against a do-nothing baseline.", "fallback": "If business-case is absent, state option 0 and the three cost layers (build, run, opportunity) inline." }
   ],
   "tags": ["strategy", "swot", "tows", "five-forces", "pestle", "competitive-analysis", "market-analysis"],

package/packs/research/skills/hypothesis-comparison/SKILL.md

@@ -12,8 +12,8 @@ and keep the hypothesis with the **least evidence against it**. Evidence that fi
 hypothesis feels persuasive and proves nothing, so the matrix makes that visible. The output
 is a ranked matrix, the evidence the ranking rests on, and the next observation to make.
 
-This skill explains a past or current observation. To choose between options going forward,
-use `tech-comparison-matrix` (technology) or `strategy-analysis` (market position). To gather
+This skill explains a past or current observation. It does not choose between options going
+forward; for market position, use `strategy-analysis`. To gather
 the evidence in the first place, plan it with `research-plan` and summarise sources with
 `source-synthesis`.
 
@@ -121,7 +121,7 @@ generated per step 2 and tagged `[assumption]`. If the user supplied no evidence
 
 ## When NOT to use this skill
 
-- ❌ Choosing between technologies, vendors or approaches for the future — `tech-comparison-matrix`
+- ❌ Choosing between technologies, vendors or approaches for the future — this ranks explanations, not options
 - ❌ Market or competitive position, SWOT, Five Forces — `strategy-analysis`
 - ❌ Planning what evidence to collect before you have any — `research-plan`
 - ❌ Summarising what a set of sources says — `source-synthesis`

package/packs/research/skills/hypothesis-comparison/manifest.json

@@ -1,6 +1,6 @@
 {
   "name": "hypothesis-comparison",
-  "version": "0.1.1",
+  "version": "0.1.2",
   "description": "Compare rival explanations for an observation with analysis of competing hypotheses (ACH) — list the hypotheses and the evidence, build a consistency matrix (consistent / inconsistent / neutral), rank hypotheses by how little evidence contradicts them rather than how much supports them, name the diagnostic evidence and the linchpins, and say which next observation would tell the leaders apart. Use when the user asks \"why did X happen\", \"which explanation fits the evidence\", \"what's really causing this\", wants to stop arguing over a favourite theory, or says \"compare these hypotheses\", \"competing explanations\", \"ACH\".",
   "entrypoint": "SKILL.md",
   "deps": {
@@ -16,8 +16,7 @@
     "postmortem-generator",
     "research-plan",
     "source-synthesis",
-    "strategy-analysis",
-    "tech-comparison-matrix"
+    "strategy-analysis"
   ],
   "handoff": [
     {

package/packs/research/skills/research-plan/SKILL.md

@@ -106,7 +106,6 @@ budgets become tagged assumptions (default: two weeks, 15 hours).
 - ❌ Ranking rival explanations for something that already happened — `hypothesis-comparison`
 - ❌ Writing the interview scripts for stakeholders — `requirements-interview`
 - ❌ A strategy framework such as SWOT or Five Forces on a market — `strategy-analysis`
-- ❌ Comparing named technologies or vendors — `tech-comparison-matrix`
 - ❌ Turning a messy thread into a brief for another skill — `brief-intake`
 
 ## Anti-patterns to avoid

package/packs/research/skills/research-plan/manifest.json

@@ -1,6 +1,6 @@
 {
   "name": "research-plan",
-  "version": "0.1.1",
+  "version": "0.1.2",
   "description": "Turn a vague research question into a research plan — the decision the research serves, the precise question and sub-questions, what finding would change the decision, a method per sub-question (desk research, interviews, data pull, experiment), source types with inclusion and exclusion criteria, ready-to-run search strings, a stopping rule for when you have enough, and the deliverable. Starts by asking what decision the research is for. Use when the user says \"I need to research X\", \"help me scope this research\", \"how should I investigate…\", \"what should I look into before deciding…\", or wants a research or discovery plan.",
   "entrypoint": "SKILL.md",
   "deps": {
@@ -16,8 +16,7 @@
     "hypothesis-comparison",
     "requirements-interview",
     "source-synthesis",
-    "strategy-analysis",
-    "tech-comparison-matrix"
+    "strategy-analysis"
   ],
   "handoff": [
     {

package/packs/skill-engineering/skills/skill-author/SKILL.md

@@ -123,7 +123,7 @@ derived from the task wording, no siblings checked, every tool targeted.
 
 ## When NOT to use this skill
 
-- ❌ Adding a skill to the skilldrop catalogue itself, with its manifest, pack and `validate.py` rules: use `contribution-wizard`
+- ❌ Adding a skill to the skilldrop catalogue itself, with its manifest, pack and `validate.py` rules: follow that repo's `AGENTS.md` and run `python3 validate.py`
 - ❌ Auditing a skill that already exists: use `skill-review`
 - ❌ Adding evals to an existing skill without changing it: use `eval-harness-generator`
 - ❌ Repo-wide always-on rules for agents (commands, conventions, forbidden actions): use `agents-md-generator`

package/packs/skill-engineering/skills/skill-author/manifest.json

@@ -1,6 +1,6 @@
 {
   "name": "skill-author",
-  "version": "0.1.0",
+  "version": "0.1.1",
   "description": "Write a new portable Agent Skill (a SKILL.md folder) from a described task, for Claude Code, Codex, Copilot, Cursor, Kiro or Antigravity in any repo — a description that leads with the artifact and ends with trigger phrases, decisive steps, a quality bar, when and when-not sections naming near-miss siblings, anti-patterns, a non-interactive rule, reference files and scripts that work in every tool, acceptance evals and trigger queries, and the install path for each tool. Use when the user says \"turn this into a skill\", \"write a SKILL.md for…\", \"make an agent skill that…\", or wants a repeatable task packaged so their coding agent does it the same way every time.",
   "entrypoint": "SKILL.md",
   "deps": {
@@ -13,7 +13,6 @@
   },
   "related": [
     "agents-md-generator",
-    "contribution-wizard",
     "eval-harness-generator",
     "skill-review"
   ],

package/packs/skill-engineering/skills/skill-review/SKILL.md

@@ -115,7 +115,7 @@ against the skills named in the folder itself.
 ## When NOT to use this skill
 
 - ❌ Writing a new skill from a task description: use `skill-author`
-- ❌ Adding a skill to the skilldrop catalogue itself, which has its own manifest and `validate.py` rules: use `contribution-wizard`
+- ❌ Adding a skill to the skilldrop catalogue itself, which has its own manifest and `validate.py` rules: follow that repo's `AGENTS.md` and run `python3 validate.py`
 - ❌ Generating more eval cases for a skill whose only gap is coverage: use `eval-harness-generator`
 - ❌ Reviewing a repo's always-on AGENTS.md policy file: use `agents-md-generator`
 - ❌ Threat-modelling the agent deployment that runs skills (its tools, data and egress): use `agent-threat-model`

package/packs/skill-engineering/skills/skill-review/manifest.json

@@ -1,6 +1,6 @@
 {
   "name": "skill-review",
-  "version": "0.1.0",
+  "version": "0.1.1",
   "description": "Audit an existing Agent Skill folder (SKILL.md plus its scripts, references and evals) for Claude Code, Codex, Copilot, Cursor, Kiro or Antigravity, and return a READY / FIX FIRST / REWRITE verdict with severity-tagged findings across five areas — whether a router would pick it and whether it collides with a sibling, portability, safety (mapped to the OWASP Agentic Skills Top 10), structure, and eval coverage — backed by a stdlib lint script for the mechanical checks. Use when the user says \"review this skill\", \"is my SKILL.md any good\", \"why doesn't my skill trigger\", \"is this skill safe to install\", or wants a skill checked before sharing or publishing it.",
   "entrypoint": "SKILL.md",
   "deps": {
@@ -14,7 +14,6 @@
   "related": [
     "agent-threat-model",
     "agents-md-generator",
-    "contribution-wizard",
     "doc-critique",
     "eval-harness-generator",
     "skill-author"

package/packs/solution-architect/skills/api-contract-draft/SKILL.md

@@ -55,7 +55,7 @@ Produces the contract *before* the code — a valid OpenAPI 3.1 document two tea
 ## When NOT to use this skill
 
 - ❌ Documenting an API that already exists — that's `guide-builder` (reference archetype)
-- ❌ Choosing REST vs GraphQL vs gRPC — that's `tech-comparison-matrix`; this skill starts after
+- ❌ Choosing REST vs GraphQL vs gRPC — this skill starts after that choice is made
 - ❌ Reviewing a contract someone else drafted — `doc-critique` or `council-review`
 - ❌ Generating server/client code from the spec — hand the frozen contract to the codegen tool
 

package/packs/solution-architect/skills/api-contract-draft/manifest.json

@@ -1,11 +1,11 @@
 {
   "name": "api-contract-draft",
-  "version": "0.1.0",
+  "version": "0.1.1",
   "description": "Draft an OpenAPI 3.1 contract from a feature brief or story — resource-oriented paths, a full error catalog (RFC 9457), pagination/idempotency/versioning decided not deferred, examples on every operation, plus a decisions log so review argues choices instead of YAML. Use when the user wants to design an API, draft an OpenAPI/Swagger spec, define request/response shapes, or agree a contract between frontend/backend or two teams before code.",
   "entrypoint": "SKILL.md",
   "deps": { "npm": [], "pip": [] },
   "env": { "required": [], "optional": [] },
-  "related": ["council-review", "doc-critique", "guide-builder", "tech-comparison-matrix", "user-story-splitter"],
+  "related": ["council-review", "doc-critique", "guide-builder", "user-story-splitter"],
   "tags": ["api-design", "openapi", "contract-first", "rest", "swagger", "asyncapi"],
   "model": { "tier": "standard", "rationale": "Schema synthesis against fixed conventions. The resource modeling needs judgment; the conventions bound it. Escalate via ambiguous-input on contested multi-team contracts." }
 }

package/packs/data-analytics/skills/metric-definition/SKILL.md

@@ -1,92 +0,0 @@
----
-name: metric-definition
-description: Write a metric spec precise enough for a semantic layer or dbt metric to implement and for two analysts to get the same number — name, business question, exact numerator and denominator, grain, time window and timezone, filters and exclusions (test accounts, refunds), allowed dimensions, edge cases (NULLs, late data, currency), owner, reference SQL, and the sanity checks that catch it going wrong. Use when the user says "define this metric", "how exactly do we calculate X", "finance and product get different numbers for X", "write the metric spec for our semantic layer", or "what counts as an active user".
----
-
-# metric-definition
-
-Turns a metric name that people already argue about ("active customers", "net revenue", "refund rate") into one written definition that produces one number. Most metric disputes are not about the data: they're two queries with different filters, windows or timezones answering under the same name. This skill pins every one of those choices down, writes the reference SQL, and adds the checks that catch the number drifting. It defines **how a metric is computed**. Choosing **which metric** judges a feature is `success-metrics`; that skill picks the primary, guardrails and decision rule, and this one makes any of those metrics exact.
-
-## How to respond
-
-**Four rules come before the steps and outrank them:**
-
-- **Answer what was asked, first.** Open with the answer, the decision or the artifact, in plain words. Scores, matrices, frameworks and tags come after it, and anything that doesn't change the answer is cut.
-- **Use only what you were given.** Don't add facts, names, numbers, incidents, history, steps or sections the input doesn't contain. What you need and don't have is left out of the artifact and listed once at the end under "To confirm".
-- **Deliver from what you have.** When the request gives you something to work on, state your assumptions in a line and produce the result. When it gives you nothing to work on, ask for it in one or two plain sentences and say what you will do once you have it.
-- **Write for someone who has never heard of this skill.** No skill names, no paths or scripts from this folder, no internal terms, and nothing about how the run was set up. A next step is one plain sentence at the end that describes the work.
-- **For this skill:** Give one definition. Check the SQL against the warehouse the user named: each function against the column's type, and a calendar period against a rolling one. A parameter the user has to fill in is listed under "To confirm", not left in the query.
-
-1. **Pin the question and the sources, asking once.** Ask at most 2 questions in one message: *"What decision does this number inform, and who reads it?"* and *"Which tables or models hold the data, and is there SQL or a dashboard already computing something under this name?"* Existing SQL is the best input you can get: it shows the definition people actually use today, including its bugs. If the user gave both, don't ask.
-
-**Non-interactive runs** (subagent, CI, headless): derive the business question and sources from the input and tag each `[assumption]`. Choices the input doesn't settle (timezone, exclusions, late-data policy) get a stated default tagged `[assumption]` and are listed under open decisions. No metric name and no business question in the input → emit `BLOCKED: need the metric name and the question it answers`.
-
-2. **Name it so one name means one formula.** `snake_case`, noun phrase, qualified where variants exist: ✅ `net_revenue_usd`, `gross_revenue_usd` — ❌ `revenue` covering both. If two teams compute it differently and both versions are legitimate, they get two names, not one name with a footnote. State the business question in one sentence: ✅ *"What share of last month's orders were refunded, by region?"* — ❌ *"Track refunds."*
-
-3. **Write the exact formula.** Numerator and denominator, each in words and as an aggregation over named columns: ✅ *"Numerator: count of distinct `order_id` with at least one non-reversed refund. Denominator: count of distinct `order_id` created in the window."* Name the metric type (count, sum, distinct count, ratio, average, percentile, cumulative), the unit and the display format (%, USD, decimals). A ratio is always **ratio of sums**, never an average of per-row or per-day ratios. See [`reference.md`](reference.md) for the types and their traps.
-
-4. **Fix the grain and the time.** Write down:
-   - **Entity**: what one unit is (order, customer, account, session).
-   - **Time column**: which timestamp decides membership in a period (created, paid, shipped, event or load time) and why.
-   - **Window**: calendar month, ISO week (Monday start), rolling 28 days, trailing 7 complete days.
-   - **Timezone**: the reporting zone, with the IANA name, e.g. `America/New_York`, not "EST".
-   - **Partial periods**: whether the current period is shown, and how it's marked.
-   - **Additivity**: whether the metric can be summed across days, regions or segments. Distinct counts and ratios can't (four weekly active-user counts don't add up to monthly active users), so say how it rolls up: recompute from the base, don't sum.
-
-5. **List every filter and exclusion with its predicate and reason.** Always ask about the usual suspects: test and internal accounts, refunds and cancellations, fraud, deleted or merged records, free or zero-value transactions, and staff discounts. ✅ *"Exclude test accounts: `NOT EXISTS (SELECT 1 FROM test_accounts t WHERE t.customer_id = o.customer_id)`. Reason: QA places real orders in production."* An exclusion without a predicate gets implemented three different ways.
-
-6. **Name the dimensions it can be sliced by, and the ones it can't.** For each allowed dimension, give the source column, the join path and whether the join is one-to-one. A dimension that fans out (product category on order-level revenue, when an order has many categories) is either disallowed or comes with an allocation rule. Say which.
-
-7. **Settle the edge cases explicitly.** NULLs in each column the formula uses (counted, excluded or defaulted), zero denominators (show NULL, not 0), late-arriving data (how many days a closed period may still change, and when it locks), currency (rate source and which date's rate), DST days, duplicates and replays, backfills, and timezone changes. Each gets a one-line rule, not a "be careful".
-
-8. **Assign an owner and a change policy.** The owner is a role and a team (✅ *"Finance analytics lead"*), not "data team". Status: `draft` or `certified`. Changing the formula is a new version with a change log entry and a dated cutover, never a silent edit, because a silent edit breaks every trend line that crosses the change date.
-
-9. **Write the reference SQL** in the user's dialect: one CTE per step (base population, exclusions, numerator, denominator), half-open time windows (`>= start AND < end`), boundaries converted to the reporting timezone, and `NULLIF` on the denominator. The reference SQL is the tie-breaker when the prose and an implementation disagree. Recommend the user runs `sql-review` on it before it's certified.
-
-10. **Add the sanity checks** that would catch the metric being wrong, each runnable: reconciliation with a system of record (the finance ledger, the billing system), hard bounds (a rate stays within 0 to 1), additivity (regions sum to the total, for additive metrics only), join row counts (the base population's count doesn't change after dimension joins), a period-over-period alert threshold, and a hand-computed fixture of 5–10 rows with the expected answer.
-
-11. **Emit with [`templates/metric-spec.md`](templates/metric-spec.md)** in one message, ending with **open decisions**: each choice made by default, with the person who should confirm it.
-
-## Useful references in this skill
-
-- [`reference.md`](reference.md) — metric types and their traps, additivity rules, the exclusion and edge-case checklist, the sanity-check catalogue, and how the spec's fields map to a semantic layer (dbt MetricFlow and similar)
-- [`templates/metric-spec.md`](templates/metric-spec.md) — the spec skeleton
-- [`examples/refund-rate.md`](examples/refund-rate.md) — worked example: an order refund rate disputed between finance and support, defined end to end
-
-## Quality bar
-
-- **One name, one formula.** The numerator and denominator are written as aggregations over named columns, so two analysts would write the same SQL.
-- **Grain, time column, window and timezone are all explicit**, with an IANA timezone name and a half-open window.
-- **Every exclusion has a predicate and a reason.** No "exclude test data" without the SQL for it.
-- **Additivity is stated**, with the roll-up rule for non-additive metrics.
-- **Every allowed dimension has a join path and its cardinality**, and fan-out dimensions are disallowed or carry an allocation rule.
-- **Edge cases get one-line rules**, including late data with a lock date and zero denominators.
-- **The reference SQL runs as written** in the named dialect and matches the prose.
-- **At least three runnable sanity checks**, including one reconciliation with a system of record where one exists.
-- **Nothing is invented.** Table names, columns and business rules not given are marked `[assumption]` and listed in open decisions.
-
-## When to use this skill
-
-- ✅ Two teams report different numbers under the same metric name
-- ✅ Putting a metric into a semantic layer, dbt metrics or a BI tool's model, and it needs one definition
-- ✅ "What counts as an active user / a churned customer / net revenue?"
-- ✅ Certifying a metric before it goes on an exec dashboard or into a board pack
-
-## When NOT to use this skill
-
-- ❌ Choosing which metric judges a feature, with targets, guardrails and a decision rule — that's `success-metrics`
-- ❌ Checking that an existing query computes its number correctly — that's `sql-review`
-- ❌ Deciding which charts and metrics go on a dashboard — that's `dashboard-spec`
-- ❌ Agreeing a dataset's schema, freshness and quality guarantees with its consumers — that's `data-contract`
-- ❌ Service health indicators, SLOs and error budgets — that's `observability-plan`
-
-## Anti-patterns to avoid
-
-- ❌ **The footnoted metric.** One name, three formulas, and a footnote on each dashboard. Split it into named variants.
-- ❌ **Average of ratios.** `AVG(daily_refund_rate)` weights a quiet Sunday like Black Friday. Divide the sums.
-- ❌ **"Monthly" with no timezone.** The UTC month and the New York month differ by hours of orders at each boundary, and the number won't match finance's.
-- ❌ **Summing distinct counts.** Adding weekly active users to get monthly active users counts every returning user four times.
-- ❌ **Exclusions in prose only.** "Excludes test accounts" with no predicate gets implemented three different ways.
-- ❌ **Silent redefinition.** Changing the formula in place, so last quarter's trend line now compares two different metrics.
-- ❌ **No owner.** A metric "owned by the data team" is owned by nobody when finance and product disagree about it.
-- ❌ **Specs with no checks.** A definition that nobody tests drifts the first time an upstream table changes.

package/packs/data-analytics/skills/metric-definition/evals/eval_queries.json

@@ -1,34 +0,0 @@
-[
-  {
-    "query": "Define exactly how we calculate monthly active users so every dashboard agrees",
-    "should_trigger": true
-  },
-  {
-    "query": "Finance and product get different churn numbers. Write one definition with the SQL",
-    "should_trigger": true
-  },
-  {
-    "query": "Write the metric spec for net revenue for our dbt semantic layer",
-    "should_trigger": true
-  },
-  {
-    "query": "What should count as an active customer? Test accounts, refunds, timezone, all of it",
-    "should_trigger": true
-  },
-  {
-    "query": "How will we know the new onboarding flow worked? Pick the KPIs and targets",
-    "should_trigger": false
-  },
-  {
-    "query": "Write a data contract for the events table other teams consume",
-    "should_trigger": false
-  },
-  {
-    "query": "Set SLOs and error budgets for the checkout API",
-    "should_trigger": false
-  },
-  {
-    "query": "Spec the executive sales dashboard before the BI team builds it",
-    "should_trigger": false
-  }
-]