skilldrop-cli 0.9.0 → 0.9.2

package/skills/migration-plan/evals/evals.json

@@ -0,0 +1,16 @@
+{
+  "skill_name": "migration-plan",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Plan the migration from our single-tenant Postgres schema to a multi-tenant one, with no downtime.",
+      "assertions": [
+        "The plan is phased expand-migrate-contract by default",
+        "Every phase is reversible, or is explicitly named as the point of no return — a reader can answer 'how do we get back from here?' for every phase",
+        "Every gate is observable with a bake time and a threshold, not 'looks good'",
+        "Each phase carries exactly one change, so a failed phase implicates one thing",
+        "Rollback steps are stated per phase rather than as a single end-of-plan afterthought"
+      ]
+    }
+  ]
+}

package/skills/nfr-spec/evals/eval_queries.json

@@ -0,0 +1,34 @@
+[
+  {
+    "query": "What are the non-functional requirements for this service?",
+    "should_trigger": true
+  },
+  {
+    "query": "Sweep the NFRs — latency, availability, privacy, accessibility, operability",
+    "should_trigger": true
+  },
+  {
+    "query": "Set performance and availability targets for this feature",
+    "should_trigger": true
+  },
+  {
+    "query": "We keep forgetting the -ilities; give me the full NFR ledger",
+    "should_trigger": true
+  },
+  {
+    "query": "Write the functional requirements and user stories",
+    "should_trigger": false
+  },
+  {
+    "query": "Draft the OpenAPI contract for this service",
+    "should_trigger": false
+  },
+  {
+    "query": "Design the dashboards, SLOs, and alerts we should build",
+    "should_trigger": false
+  },
+  {
+    "query": "Model the capacity and cost for this workload",
+    "should_trigger": false
+  }
+]

package/skills/nfr-spec/evals/evals.json

@@ -0,0 +1,16 @@
+{
+  "skill_name": "nfr-spec",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Sweep the non-functional requirements for our new checkout service.",
+      "assertions": [
+        "Every category in the catalog lands in one of three states — a target, not-applicable with a reason, or a tagged default; silence in any category is a failure",
+        "Every target states a percentile, a load condition, and how it will be verified — a latency number with no load condition is rejected",
+        "The availability target matches the honest answer to what an hour of downtime costs, not a marketing instinct",
+        "Privacy and retention are given concrete periods rather than 'per policy'",
+        "The output is a reviewable ledger covering all categories, not a prose paragraph about quality"
+      ]
+    }
+  ]
+}

package/skills/observability-plan/evals/eval_queries.json

@@ -0,0 +1,34 @@
+[
+  {
+    "query": "Design an observability plan for this service",
+    "should_trigger": true
+  },
+  {
+    "query": "What SLIs and SLOs should we define, and what should page us?",
+    "should_trigger": true
+  },
+  {
+    "query": "Set up burn-rate alerting with error budgets",
+    "should_trigger": true
+  },
+  {
+    "query": "We alert on CPU and it's useless — design symptom-based alerting",
+    "should_trigger": true
+  },
+  {
+    "query": "Sweep the full non-functional requirements catalog",
+    "should_trigger": false
+  },
+  {
+    "query": "Write the operational runbook for the on-call team",
+    "should_trigger": false
+  },
+  {
+    "query": "Model our capacity and infrastructure cost",
+    "should_trigger": false
+  },
+  {
+    "query": "Write the postmortem for last week's outage",
+    "should_trigger": false
+  }
+]

package/skills/observability-plan/evals/evals.json

@@ -0,0 +1,16 @@
+{
+  "skill_name": "observability-plan",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Design the observability plan for our checkout service — what should we measure, alert on, and page for?",
+      "assertions": [
+        "SLIs measure user experience as good-over-valid events, not resource utilization",
+        "Latency SLIs are threshold counts at a percentile, never averages",
+        "Every SLO carries an error budget stated in human terms plus a policy for when it is spent",
+        "Pages are symptom-based, actionable, and runbook-linked; anything not actionable is a ticket, not a page",
+        "The plan makes a deliberate metrics-vs-logs-vs-traces choice rather than proposing everything"
+      ]
+    }
+  ]
+}

package/skills/postmortem-generator/evals/eval_queries.json

@@ -0,0 +1,34 @@
+[
+  {
+    "query": "Write a blameless postmortem for this incident",
+    "should_trigger": true
+  },
+  {
+    "query": "Turn this pager timeline and Slack thread into a postmortem",
+    "should_trigger": true
+  },
+  {
+    "query": "We resolved the outage — document what happened and why",
+    "should_trigger": true
+  },
+  {
+    "query": "Generate the incident review doc with impact and action items",
+    "should_trigger": true
+  },
+  {
+    "query": "We're still in the incident — draft the customer update",
+    "should_trigger": false
+  },
+  {
+    "query": "Extract the decisions and owners from this thread",
+    "should_trigger": false
+  },
+  {
+    "query": "Write the runbook so this is handled better next time",
+    "should_trigger": false
+  },
+  {
+    "query": "Summarize the incident for the executive team",
+    "should_trigger": false
+  }
+]

package/skills/postmortem-generator/evals/evals.json

@@ -0,0 +1,17 @@
+{
+  "skill_name": "postmortem-generator",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Write the postmortem from this pager timeline and Slack thread for last Tuesday's checkout outage.",
+      "assertions": [
+        "Impact is quantified — duration, users or requests affected, SLO burn, revenue where known — or explicitly marked [missing]; 'significant impact' is rejected",
+        "No person is named in a causal sentence; roles appear only in response actions",
+        "Detection and mitigation gaps are computed and stated as numbers",
+        "The timeline is in UTC",
+        "Contributing factors are listed rather than a single root cause",
+        "Action items carry owners as roles and are derived from the contributing factors"
+      ]
+    }
+  ]
+}

package/skills/prd-draft/evals/eval_queries.json

@@ -0,0 +1,34 @@
+[
+  {
+    "query": "Draft a PRD for this feature",
+    "should_trigger": true
+  },
+  {
+    "query": "Write the product requirements document from this idea",
+    "should_trigger": true
+  },
+  {
+    "query": "I need testable requirements with MoSCoW priorities and non-goals",
+    "should_trigger": true
+  },
+  {
+    "query": "Turn this feature idea into a PRD engineering can build from",
+    "should_trigger": true
+  },
+  {
+    "query": "Write the press release before the product exists",
+    "should_trigger": false
+  },
+  {
+    "query": "Draft the engineering design doc for this",
+    "should_trigger": false
+  },
+  {
+    "query": "Split this epic into INVEST user stories",
+    "should_trigger": false
+  },
+  {
+    "query": "Write interview questions for our stakeholders",
+    "should_trigger": false
+  }
+]

package/skills/prd-draft/evals/evals.json

@@ -0,0 +1,17 @@
+{
+  "skill_name": "prd-draft",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Draft a PRD for a saved-search feature in our analytics product — users keep re-running the same filters every morning.",
+      "assertions": [
+        "The problem statement contains zero solution language and passes the alternative-solution test — more than one solution could follow from it",
+        "Every requirement is verifiable — a tester can demo it pass or fail; adjective requirements and implementation choices are rejected",
+        "Requirements are MoSCoW-prioritized",
+        "The won't-have list is non-empty and names specific excluded things",
+        "Each goal carries a success line stating how it will be measured",
+        "Claims that need evidence are marked rather than asserted as fact"
+      ]
+    }
+  ]
+}

package/skills/requirements-interview/evals/eval_queries.json

@@ -0,0 +1,34 @@
+[
+  {
+    "query": "Build interview questions for our stakeholders on this feature",
+    "should_trigger": true
+  },
+  {
+    "query": "Who should we talk to for this discovery, and what should we ask them?",
+    "should_trigger": true
+  },
+  {
+    "query": "Create a discovery interview kit per stakeholder",
+    "should_trigger": true
+  },
+  {
+    "query": "I need non-leading questions that would actually change the design",
+    "should_trigger": true
+  },
+  {
+    "query": "Draft the PRD for this feature",
+    "should_trigger": false
+  },
+  {
+    "query": "Structure this existing raw input into a brief",
+    "should_trigger": false
+  },
+  {
+    "query": "Map the customer's journey through onboarding",
+    "should_trigger": false
+  },
+  {
+    "query": "Write the design doc for the billing migration",
+    "should_trigger": false
+  }
+]

package/skills/requirements-interview/evals/evals.json

@@ -0,0 +1,16 @@
+{
+  "skill_name": "requirements-interview",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "We're scoping a billing-migration feature. Build interview kits for the stakeholders we should talk to.",
+      "assertions": [
+        "Each stakeholder script has at most 7 questions, ranked by how much the answer changes the design",
+        "Every question is annotated with the decision it informs and how the answer moves the design",
+        "No leading questions in discovery position — nothing answerable with a polite yes",
+        "Every script contains a kill-question, and the kit states what a kill-answer would mean",
+        "Stakeholders are chosen and named by role, with a reason each one is on the list"
+      ]
+    }
+  ]
+}

package/skills/reverse-architecture/evals/eval_queries.json

@@ -0,0 +1,34 @@
+[
+  {
+    "query": "Reverse-engineer the architecture from this repo",
+    "should_trigger": true
+  },
+  {
+    "query": "Work out our system diagram from the Terraform and k8s manifests",
+    "should_trigger": true
+  },
+  {
+    "query": "What does our actual architecture look like based on the code?",
+    "should_trigger": true
+  },
+  {
+    "query": "Build a diagram from our existing infrastructure-as-code",
+    "should_trigger": true
+  },
+  {
+    "query": "Draw a diagram from this written description of the system",
+    "should_trigger": false
+  },
+  {
+    "query": "Read our Figma file and list the frames",
+    "should_trigger": false
+  },
+  {
+    "query": "Write an ADR for the architecture we chose",
+    "should_trigger": false
+  },
+  {
+    "query": "Review this code for bugs",
+    "should_trigger": false
+  }
+]

package/skills/reverse-architecture/evals/evals.json

@@ -0,0 +1,16 @@
+{
+  "skill_name": "reverse-architecture",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Reverse-engineer the architecture of this repo — it has Terraform, Kubernetes manifests, and an OpenAPI spec.",
+      "assertions": [
+        "Every node carries a source-of-truth file path as evidence; nothing appears in the diagram without a reference",
+        "Inferred components are marked as inferred rather than asserted as fact",
+        "Edges carry direction and, where the source reveals it, protocol",
+        "Nodes are grouped by deployment boundary as the artifacts reveal it",
+        "The output is derived from the supplied artifacts, not from a written description of intent"
+      ]
+    }
+  ]
+}

package/skills/runbook-generator/evals/eval_queries.json

@@ -0,0 +1,34 @@
+[
+  {
+    "query": "Write an operational runbook for this service",
+    "should_trigger": true
+  },
+  {
+    "query": "We're launching a service — what does on-call need documented?",
+    "should_trigger": true
+  },
+  {
+    "query": "Document deploy, rollback, and incident response for this system",
+    "should_trigger": true
+  },
+  {
+    "query": "Generate the runbook covering escalation and common failures",
+    "should_trigger": true
+  },
+  {
+    "query": "Design our SLIs, SLOs, and burn-rate alerts",
+    "should_trigger": false
+  },
+  {
+    "query": "We're in an incident right now — draft the status page update",
+    "should_trigger": false
+  },
+  {
+    "query": "Write the postmortem for the outage",
+    "should_trigger": false
+  },
+  {
+    "query": "Sweep the full non-functional requirements catalog",
+    "should_trigger": false
+  }
+]

package/skills/runbook-generator/evals/evals.json

@@ -0,0 +1,17 @@
+{
+  "skill_name": "runbook-generator",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Write the operational runbook for our new payments service — it deploys via Argo, pages the payments team, and depends on Stripe and Postgres.",
+      "assertions": [
+        "Ownership is expressed as roles and rotations rather than individual names that go stale",
+        "Every alert listed has a corresponding 'what to do when this fires' response — no alert is left without one",
+        "Rollback is one command or at most three steps",
+        "Dependencies are listed with what breaks when each is unavailable",
+        "Escalation names the path and the trigger for escalating, not just a team name",
+        "Facts not supplied (dashboard links, SLO values) are marked missing rather than invented"
+      ]
+    }
+  ]
+}

package/skills/slide-outliner/evals/eval_queries.json

@@ -0,0 +1,34 @@
+[
+  {
+    "query": "Outline the slides for my architecture review",
+    "should_trigger": true
+  },
+  {
+    "query": "Give me slide titles, key points, and speaker notes for this pitch",
+    "should_trigger": true
+  },
+  {
+    "query": "Structure this into a deck outline I can build from",
+    "should_trigger": true
+  },
+  {
+    "query": "What slides do I need for this technical presentation?",
+    "should_trigger": true
+  },
+  {
+    "query": "Generate the actual .pptx file for me",
+    "should_trigger": false
+  },
+  {
+    "query": "Write a one-page executive summary of this doc",
+    "should_trigger": false
+  },
+  {
+    "query": "What are the structural rules for presenting to a board?",
+    "should_trigger": false
+  },
+  {
+    "query": "Draw the architecture diagram for this system",
+    "should_trigger": false
+  }
+]

package/skills/slide-outliner/evals/evals.json

@@ -0,0 +1,16 @@
+{
+  "skill_name": "slide-outliner",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Outline an architecture review deck for our proposed move to event-driven order processing — the audience is staff engineers plus one VP.",
+      "assertions": [
+        "Every slide title asserts a claim rather than labelling a topic ('We can ship this in two quarters', not 'Timeline')",
+        "No single slide mixes high-level overview with deep technical detail — where both are needed it becomes two slides",
+        "Speaker notes carry the narrative while the slide carries the evidence; the script is not dumped onto the slide",
+        "The output is a structured outline the user can paste into their own tool — no .pptx file is produced",
+        "Slide count and depth are matched to the stated audience"
+      ]
+    }
+  ]
+}

package/skills/sonar-onboard/evals/eval_queries.json

@@ -0,0 +1,34 @@
+[
+  {
+    "query": "Set up Sonar for this repo",
+    "should_trigger": true
+  },
+  {
+    "query": "Scaffold sonar-project.properties and the CI workflow",
+    "should_trigger": true
+  },
+  {
+    "query": "Onboard this project onto SonarCloud with a blocking quality gate",
+    "should_trigger": true
+  },
+  {
+    "query": "We want Sonar checks on every PR — configure it",
+    "should_trigger": true
+  },
+  {
+    "query": "Run the Sonar scan and tell me if the gate passes",
+    "should_trigger": false
+  },
+  {
+    "query": "Adversarially review this diff for edge cases",
+    "should_trigger": false
+  },
+  {
+    "query": "Gate my change with lint, tests, and the reviewer panel",
+    "should_trigger": false
+  },
+  {
+    "query": "Design our SLOs and alerting",
+    "should_trigger": false
+  }
+]

package/skills/sonar-onboard/evals/evals.json

@@ -0,0 +1,16 @@
+{
+  "skill_name": "sonar-onboard",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Set this Python repo up for Sonar compliance — we use SonarCloud and run CI on GitHub Actions.",
+      "assertions": [
+        "sonar.projectKey, sonar.sources, sonar.tests and the coverage path reflect what is actually on disk, not generic example values",
+        "The generated CI workflow blocks merge on a quality-gate failure rather than merely running a scan",
+        "SonarCloud vs SonarQube server is chosen explicitly and the generated config matches that choice",
+        "The coverage report path matches the language's real tooling output",
+        "Setup steps that require a token or server-side action are named for the operator rather than silently assumed"
+      ]
+    }
+  ]
+}

package/skills/sonar-review/evals/eval_queries.json

@@ -0,0 +1,34 @@
+[
+  {
+    "query": "Run a Sonar review on this branch",
+    "should_trigger": true
+  },
+  {
+    "query": "What does the quality gate say about my changes?",
+    "should_trigger": true
+  },
+  {
+    "query": "Give me the Sonar findings for the files I changed",
+    "should_trigger": true
+  },
+  {
+    "query": "Check Sonar compliance before I open the PR",
+    "should_trigger": true
+  },
+  {
+    "query": "Set up Sonar in this repository",
+    "should_trigger": false
+  },
+  {
+    "query": "Review this code adversarially for edge cases the first pass missed",
+    "should_trigger": false
+  },
+  {
+    "query": "Run the full pre-merge gate and reviewer panel",
+    "should_trigger": false
+  },
+  {
+    "query": "Write the postmortem for last night's incident",
+    "should_trigger": false
+  }
+]

package/skills/sonar-review/evals/evals.json

@@ -0,0 +1,16 @@
+{
+  "skill_name": "sonar-review",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Run a Sonar review on my current branch before I open the PR.",
+      "assertions": [
+        "The verdict is taken from the quality gate itself, not from the reviewer's own judgment — PASS is reported as PASS even if other issues are visible",
+        "Findings are scoped to files changed on the branch; pre-existing repo debt is not dumped into the report",
+        "Findings are severity-tagged and each carries file:line, the Sonar rule ID, why it matters, and a concrete fix",
+        "Findings are grouped into the lenses (bugs, vulnerabilities, security hotspots, code smells, coverage/duplication)",
+        "Server vs cloud is auto-detected from sonar-project.properties rather than assumed"
+      ]
+    }
+  ]
+}

package/skills/test-plan-generator/evals/eval_queries.json

@@ -0,0 +1,34 @@
+[
+  {
+    "query": "Write a test plan for this feature",
+    "should_trigger": true
+  },
+  {
+    "query": "What should we test before this release, ranked by risk?",
+    "should_trigger": true
+  },
+  {
+    "query": "Map these acceptance criteria to test cases",
+    "should_trigger": true
+  },
+  {
+    "query": "Generate a risk-based QA plan for this PR",
+    "should_trigger": true
+  },
+  {
+    "query": "Split this epic into user stories with acceptance criteria",
+    "should_trigger": false
+  },
+  {
+    "query": "Review my code and tell me which tests are missing",
+    "should_trigger": false
+  },
+  {
+    "query": "Run the Sonar scan on my branch",
+    "should_trigger": false
+  },
+  {
+    "query": "Draft the PRD for this feature",
+    "should_trigger": false
+  }
+]

package/skills/test-plan-generator/evals/evals.json

@@ -0,0 +1,16 @@
+{
+  "skill_name": "test-plan-generator",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Write the test plan for this release — a new discount-code feature touching checkout, pricing, and the orders API.",
+      "assertions": [
+        "A risk table ranked by likelihood times impact precedes the test cases, and depth of coverage tracks that ranking rather than being uniform",
+        "Every test case states a concrete expected result — a specific status code, error code, or value, not 'an appropriate error is shown'",
+        "Every acceptance criterion appears in a coverage table, with uncovered ACs listed explicitly rather than omitted",
+        "Each test is pushed to the lowest pyramid level that would catch the failure",
+        "Out-of-scope areas are named rather than silently skipped"
+      ]
+    }
+  ]
+}

package/skills/threat-model/evals/eval_queries.json

@@ -0,0 +1,34 @@
+[
+  {
+    "query": "Threat model this design",
+    "should_trigger": true
+  },
+  {
+    "query": "Run STRIDE on this architecture before we build it",
+    "should_trigger": true
+  },
+  {
+    "query": "What could an attacker do to this system as designed?",
+    "should_trigger": true
+  },
+  {
+    "query": "Security review of this design doc, with trust boundaries and attack scenarios",
+    "should_trigger": true
+  },
+  {
+    "query": "Review this diff for exploitable security bugs",
+    "should_trigger": false
+  },
+  {
+    "query": "Threat model my AI agent's tool and data access",
+    "should_trigger": false
+  },
+  {
+    "query": "Audit this UI for accessibility barriers",
+    "should_trigger": false
+  },
+  {
+    "query": "Convene a council to deliberate this architecture",
+    "should_trigger": false
+  }
+]

package/skills/threat-model/evals/evals.json

@@ -0,0 +1,18 @@
+{
+  "skill_name": "threat-model",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Threat model this design: a multi-tenant reporting service where customers upload CSVs, we process them in a worker, and results are served from an S3 bucket via signed URLs.",
+      "assertions": [
+        "Assets, entry points, and trust boundaries are established before any threat is listed",
+        "Every threat is anchored to a named trust-boundary crossing or asset — unanchored checklist residue is cut",
+        "Every threat narrates a scenario with actor, path, and result; 'X is possible' is not accepted as a finding",
+        "STRIDE is applied per boundary crossing rather than as a flat checklist",
+        "Severity is calibrated to this system's assets rather than CVSS theater — not everything is critical",
+        "Existing mitigations are credited as verified or assumed, and every recommendation carries a verification step",
+        "The authorization sweep (tenant-to-tenant, authn is not authz) and the insider/compromised-credential sweep are both run"
+      ]
+    }
+  ]
+}