skilldrop-cli 0.9.0 → 0.9.1

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/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"
+      ]
+    }
+  ]
+}