skilldrop-cli 0.16.12 → 0.16.14

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/pack.json

@@ -38,7 +38,7 @@
       {
         "skill": "source-synthesis",
         "you_do": "Hand it the sources you collected, as text, with the plan's question.",
-        "you_get": "Findings with every claim cited to a source and page, agreement and disagreement made explicit, a strength rating per finding, the gaps, and a citation check report."
+        "you_get": "What the sources support on the question, each claim traceable to its source, with disagreements and echoes made explicit, the sources' own sums checked, labelled estimates where a figure is needed, and the gaps. Ask for a cited literature review to get page-level citations and strength ratings."
       },
       {
         "skill": "hypothesis-comparison",
@@ -47,6 +47,6 @@
         "decide": "Act on the leading explanation, or run the next observation first."
       }
     ],
-    "you_end_with": "A decision-led plan, a cited synthesis you can check line by line, and, for why-questions, a ranked set of explanations with the next test to run."
+    "you_end_with": "A decision-led plan, a synthesis that keeps what the sources say apart from everything else, and, for why-questions, a ranked set of explanations with the next test to run."
   }
 }

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": [
     {