swe-workflow-skills 0.1.0

package/skills/security-audit/references/owasp-top-10.md

@@ -0,0 +1,167 @@
+# OWASP Top 10 Security Checklist
+
+## Contents
+- A01: Broken Access Control
+- A02: Cryptographic Failures
+- A03: Injection
+- A04: Insecure Design
+- A05: Security Misconfiguration
+- A06: Vulnerable and Outdated Components
+- A07: Identification and Authentication Failures
+- A08: Software and Data Integrity Failures
+- A09: Security Logging and Monitoring Failures
+- A10: Server-Side Request Forgery (SSRF)
+
+## A01: Broken Access Control
+
+The #1 vulnerability. Access control means enforcing that users can only act within their intended permissions.
+
+**What to check:**
+- [ ] Every API endpoint enforces authentication (not just the frontend)
+- [ ] Authorization is checked server-side for every protected operation
+- [ ] Users cannot access other users' data by changing IDs in URLs (IDOR)
+- [ ] Directory traversal is prevented (no `../` in file paths from user input)
+- [ ] CORS is configured to allow only specific trusted origins (not `*`)
+- [ ] JWT tokens are validated properly (algorithm, signature, expiry, issuer)
+- [ ] API rate limiting prevents enumeration attacks
+- [ ] Metadata manipulation is blocked (tampering with JWT, cookies, hidden fields)
+
+**Common patterns to flag:**
+```javascript
+// BAD: Only checks if logged in, not if authorized for THIS resource
+app.get('/orders/:id', authenticate, async (req, res) => {
+  const order = await db.orders.findById(req.params.id);
+  res.json(order); // Any authenticated user can see ANY order
+});
+
+// GOOD: Checks ownership
+app.get('/orders/:id', authenticate, async (req, res) => {
+  const order = await db.orders.findOne({
+    id: req.params.id,
+    userId: req.user.id  // Scoped to the authenticated user
+  });
+  if (!order) return res.status(404).json({ error: 'Not found' });
+  res.json(order);
+});
+```
+
+## A02: Cryptographic Failures
+
+Sensitive data exposure through weak or missing cryptography.
+
+**What to check:**
+- [ ] Passwords hashed with bcrypt, argon2, or scrypt (never MD5, SHA-1, or SHA-256 alone)
+- [ ] Sufficient work factor (bcrypt rounds >= 12, argon2 with recommended params)
+- [ ] TLS 1.2+ enforced for all connections
+- [ ] Sensitive data encrypted at rest (PII, financial data, health data)
+- [ ] Encryption keys managed properly (not hardcoded, rotated periodically)
+- [ ] No sensitive data in URLs (tokens, passwords in query strings)
+- [ ] Proper random number generation (crypto.randomBytes, not Math.random)
+
+## A03: Injection
+
+Untrusted data sent to an interpreter as part of a command or query.
+
+**What to check:**
+- [ ] SQL queries use parameterized statements (never string concatenation)
+- [ ] NoSQL queries use typed parameters (not raw user input in operators)
+- [ ] OS commands use parameterized execution (never shell interpolation)
+- [ ] LDAP queries are parameterized
+- [ ] XPath/XML queries are parameterized
+- [ ] HTML output is escaped to prevent XSS (use framework auto-escaping)
+- [ ] User input in `eval()`, `Function()`, or template literals is blocked
+- [ ] GraphQL queries are depth-limited and complexity-bounded
+
+**Injection types and their signatures:**
+
+| Type | Dangerous Pattern | Safe Pattern |
+|------|------------------|-------------|
+| SQL | `"SELECT * FROM users WHERE id = " + userId` | `db.query("SELECT * FROM users WHERE id = $1", [userId])` |
+| XSS | `innerHTML = userInput` | `textContent = userInput` or framework escaping |
+| Command | `exec("ls " + userPath)` | `execFile("ls", [userPath])` |
+| NoSQL | `{ $where: userInput }` | `{ field: { $eq: userInput } }` |
+| Template | `` `Hello ${userInput}` `` in template engine | Template engine with auto-escaping |
+
+## A04: Insecure Design
+
+Flaws in the design itself, not just the implementation.
+
+**What to check:**
+- [ ] Business logic has server-side enforcement (not just client-side validation)
+- [ ] Rate limiting on resource-intensive operations
+- [ ] Transaction limits enforced server-side
+- [ ] Multi-step processes can't skip steps
+- [ ] File upload validates type, size, and content (not just extension)
+- [ ] No mass assignment vulnerabilities (user can't set `role: 'admin'` by adding fields)
+
+## A05: Security Misconfiguration
+
+Default or incomplete configurations that leave openings.
+
+**What to check:**
+- [ ] No default credentials in any environment
+- [ ] Error messages don't expose stack traces or internal details to users
+- [ ] Unnecessary HTTP methods disabled (TRACE, OPTIONS where not needed)
+- [ ] Security headers configured: CSP, X-Frame-Options, X-Content-Type-Options, HSTS
+- [ ] Directory listing disabled on web servers
+- [ ] Debug mode disabled in production
+- [ ] Cloud storage buckets/blobs are not publicly accessible by default
+- [ ] Database ports not exposed to the internet
+
+## A06: Vulnerable and Outdated Components
+
+Using components with known vulnerabilities.
+
+**What to check:**
+- [ ] `npm audit` / `pip audit` / `govulncheck` shows no critical vulnerabilities
+- [ ] Dependencies are reasonably up to date (no major versions behind)
+- [ ] Unused dependencies are removed (reduce attack surface)
+- [ ] Lock files are committed and used for deterministic builds
+- [ ] Sub-dependencies (transitive) are also checked
+
+## A07: Identification and Authentication Failures
+
+Weaknesses in the authentication mechanism itself.
+
+**What to check:**
+- [ ] Brute force protection (rate limiting, account lockout, CAPTCHA)
+- [ ] No credential stuffing vulnerability (breached password checking)
+- [ ] Session IDs regenerated after login (session fixation prevention)
+- [ ] Session timeout is appropriate (not infinite)
+- [ ] Password reset tokens expire and are single-use
+- [ ] MFA bypass resistance (recovery codes handled securely)
+- [ ] OAuth state parameter used to prevent CSRF
+
+## A08: Software and Data Integrity Failures
+
+Trusting data or code without verification.
+
+**What to check:**
+- [ ] CI/CD pipeline integrity (no unsigned code deployments)
+- [ ] Deserialization of untrusted data is avoided or secured
+- [ ] Software updates verified with signatures
+- [ ] Subresource Integrity (SRI) used for CDN-loaded scripts
+- [ ] Webhook payloads verified with signatures
+
+## A09: Security Logging and Monitoring Failures
+
+Insufficient detection capability.
+
+**What to check:**
+- [ ] Authentication events are logged (login, failed login, logout)
+- [ ] Authorization failures are logged
+- [ ] Input validation failures are logged (potential attack probing)
+- [ ] Sensitive data NOT logged (passwords, tokens, PII)
+- [ ] Logs are tamper-proof (centralized, append-only)
+- [ ] Alerting on anomalous patterns (burst of failures, unusual access patterns)
+
+## A10: Server-Side Request Forgery (SSRF)
+
+The application fetches a remote resource based on user input without validation.
+
+**What to check:**
+- [ ] User-supplied URLs are validated against an allowlist
+- [ ] Internal/private IP ranges are blocked (127.0.0.1, 10.x, 172.16.x, 192.168.x)
+- [ ] URL scheme is restricted (https only, no file://, gopher://, etc.)
+- [ ] Redirects from user-supplied URLs are not followed blindly
+- [ ] DNS rebinding attacks are considered (re-resolve after initial check)

package/skills/security-audit/templates/security-report.md

@@ -0,0 +1,79 @@
+# Security Audit Report Template
+
+```markdown
+# Security Audit Report: [Project Name]
+
+**Date**: [YYYY-MM-DD]
+**Auditor**: [Name / Claude Code]
+**Scope**: [What was reviewed — codebase, specific modules, infrastructure config]
+**Commit**: [Git hash at time of audit]
+
+## Executive Summary
+
+[2-3 sentences: Overall security posture, number of findings by severity,
+most critical issue found.]
+
+**Finding Summary:**
+| Severity | Count |
+|----------|-------|
+| Critical | [N] |
+| High     | [N] |
+| Medium   | [N] |
+| Low      | [N] |
+
+## Attack Surface
+
+[Brief description of entry points, authentication boundaries, and data flows analyzed.]
+
+## Findings
+
+### [SEVERITY]-[NNN]: [Short Title]
+
+**Severity**: Critical / High / Medium / Low
+**Category**: [OWASP category, e.g., A03: Injection]
+**Location**: `[file:line]` or `[endpoint]`
+
+**Description:**
+[What the vulnerability is.]
+
+**Exploit Scenario:**
+[How an attacker could exploit this. Be specific — show a curl command,
+a malicious input, or a sequence of actions.]
+
+**Evidence:**
+```[language]
+// The vulnerable code
+```
+
+**Remediation:**
+```[language]
+// The fixed code
+```
+
+**Effort**: [Low / Medium / High]
+
+---
+
+[Repeat for each finding, ordered by severity]
+
+## Recommendations Summary
+
+### Immediate (fix before next deploy)
+1. [Critical/High finding references]
+
+### Short-term (fix within 1-2 sprints)
+1. [Medium finding references]
+
+### Long-term (address in roadmap)
+1. [Low findings, architectural improvements]
+
+## Out of Scope
+
+[What was NOT reviewed and why — runtime testing, infrastructure, etc.]
+
+## Next Steps
+
+- [ ] Fix Critical and High findings
+- [ ] Schedule follow-up audit after fixes
+- [ ] Consider penetration testing for [specific areas]
+```

package/skills/skill-router/SKILL.md

@@ -0,0 +1,171 @@
+---
+name: skill-router
+description: "Orchestrator and entry point for the swe-workflow skills library — consult FIRST when starting any non-trivial software task; most skills load name-only and only activate when invoked here. Triggers: starting a feature, planning, an architecture or design decision, implementing, debugging, reviewing, refactoring, testing, security, deployment, an incident, shipping, or unsure which skill fits. Routes intent to the right skill(s) and invokes them by name; shows the Golden Path chains."
+model: haiku
+allowed-tools: Read, Grep, Glob, Skill
+---
+
+# Skill Router
+
+This project installs the **swe-workflow skills library** — a set of structured
+SDLC workflows. This skill is the **orchestrator**: most skills are loaded
+**name-only** (listed but not auto-triggering), so they activate by being
+invoked. Use this router to pick the right skill — or skills — quickly and invoke them,
+then hand off and get out of the way. A task that spans several domains or phases
+needs several skills; invoke all that apply, not just the first.
+
+## Activation model (why this skill matters)
+
+To keep the context listing small, only a pinned set auto-triggers (this router
+plus the safety skills: `verification-before-completion`, `tdd-workflow`,
+`bug-investigating`, `incident-response`, `code-reviewing`). Every other skill is
+**name-only** — invocable, but it will not fire on its own. Routing through this
+orchestrator is how those skills get activated. A **role** can promote a working
+set back to auto-triggering; switch roles with the `/role <name>` command
+(`/role` to see options, `/role all` to reset to baseline).
+
+## The rule
+
+Before substantial software work — planning a feature, making a structural or
+data decision, implementing, debugging, reviewing, refactoring, or shipping —
+**check whether a dedicated skill applies, and invoke it.** This is the default,
+not an optional extra. The skills encode the *how* and *why* of doing each
+activity well, so you don't have to re-derive them.
+
+Routing is **not a once-per-session gate.** Re-route whenever the *kind* of work
+changes — analysis → implementation → writing tests → review → shipping — because
+each phase's skill is loaded only when invoked, and the one you need for the new
+phase almost certainly isn't loaded yet. A session that routed for analysis and
+then writes tests an hour later without re-routing silently drops the testing
+skills' guidance.
+
+Do **not** talk yourself out of it because the task "looks like a one-liner,"
+touches only one file, or seems obvious. Small structural changes (renames,
+config edits, dependency bumps) and anything that matches a specific skill's
+domain (accessibility, API design, security, data modeling, migrations,
+performance…) are exactly what the skills are for. When in doubt, route.
+
+Skip **only** for genuinely trivial, conversational, or information-lookup
+requests where no workflow adds value, or when the user tells you not to use a
+skill or to "just do X". **The user's explicit instructions always take
+precedence** over any skill.
+
+## How to route
+
+1. **Get the full catalog.** Read `.catalog.json` from the installed skills
+   directory (the parent of this skill — e.g. `.claude/skills/.catalog.json` or
+   `~/.claude/skills/.catalog.json`). It holds every skill's full description, so
+   you can match precisely even though their descriptions aren't in the listing.
+   If it's absent (e.g. a plugin install), use the phase index below.
+2. **Match** the user's intent to **every** skill that applies — not just the
+   single best fit. A request often spans more than one domain (e.g. "review for
+   accessibility *and* UX" → both `accessibility-design` and `ui-ux-design`) or
+   more than one phase (a feature → planning, then data model, then API, …).
+3. **Invoke them by name** via the Skill tool — name-only skills are fully
+   invocable; the listing just doesn't show their description. When several skills
+   apply, **invoke them all, in workflow order, and integrate each one's guidance
+   — do not stop after the first.** Stating "I'll use both" is not enough; you
+   must actually call each one (invoke the next applicable skill before you finish
+   — e.g. load the UX skill before writing a combined a11y+UX review, and on a
+   Golden Path chain invoke each phase's skill as you reach it). "Hand off" means
+   stop narrating the routing and start the work, NOT "one skill is enough." Route
+   to a single skill only when the task genuinely maps to exactly one.
+4. If a matched skill isn't installed (a subset/plugin install), read its
+   `SKILL.md` inline if present, or tell the user which skill/role to add.
+5. If the work spans several phases, follow the relevant **Golden Path** chain,
+   invoking each skill in the chain as you reach its phase.
+6. If nothing fits, proceed normally — not everything needs a skill.
+
+## Role-scoped routing (optional)
+
+If a role is active (a `.active-role` marker sits beside the skills, or the
+SessionStart hook named one), lead with that role's working set — read
+`.roles.json` for it — then fall back to the rest of the catalog. The user can
+change the promoted set with `/role <name>`. Either way you can invoke any
+installed skill by name, regardless of role.
+
+## Catalog by SDLC phase
+
+### Plan & Define
+- **feature-planning** — break a feature into scoped tasks, acceptance criteria, dependencies
+- **prd-writing** — write a PRD / RFC / tech spec to align on the WHAT and WHY
+- **project-proposal** — business case / budget / go-no-go before a project starts
+- **strategic-review** — vision, positioning, defensible wedge, live competitive/market analysis before going public
+- **effort-estimation** — story points, t-shirt sizing, three-point estimates, capacity
+- **metrics-and-okrs** — define OKRs, KPIs, success metrics, DORA / engineering health
+
+### Design & Architecture
+- **architecture-design** — costly-to-reverse structural decisions, pattern choice, ADRs
+- **architecture-documentation** — C4 diagrams, docs-as-code, runtime/infra views
+- **api-design** — REST/GraphQL contracts, endpoints, errors, pagination, versioning
+- **data-modeling** — schema, relationships, indexes, migration strategy
+- **ui-ux-design** — user flows, wireframes, loading/error/empty states, responsive
+- **frontend-architecture** — component hierarchy, state management, design tokens
+- **accessibility-design** — WCAG, ARIA, keyboard nav, focus, screen readers
+- **configuration-strategy** — env config, secrets management, feature-flag hierarchy
+- **dependency-impact-analysis** — blast radius of a change *before* implementing
+- **dependency-management** — evaluate, audit (CVEs), and upgrade libraries
+
+### Build & Test
+- **tdd-workflow** — NEW code, test-first, red-green-refactor
+- **test-suite-design** — add tests to EXISTING code, coverage strategy
+- **test-data-strategy** — factories, synthetic data, property-based, contract testing
+- **git-workflow** — commit messages, PR descriptions, branching strategy
+- **project-documentation** — README, contributing guide, changelog, docstrings
+
+### Review & Improve
+- **code-reviewing** — structured review enforcing DRY/KISS/YAGNI/SRP & conventions
+- **security-audit** — OWASP Top 10, auth/authz, injection, secrets, dependency CVEs
+- **performance-optimization** — N+1, algorithmic complexity, caching, bundle size
+- **refactoring** — systematic, test-protected code improvement
+- **technical-debt-review** — codebase health, hotspots, remediation roadmap
+- **project-review** — whole-project execution health: scope alignment, roadmap adherence, implementation maturity, evidence-it-works
+
+### Diagnose & Fix
+- **bug-investigating** — systematic debugging, reproduce → isolate → hypothesize → verify
+
+### Ship & Operate
+- **deployment-checklist** — pre-deploy verification and release safety
+- **rollback-strategy** — safe rollback plans, irreversible-change detection
+- **containerization** — Dockerfiles, docker-compose, Kubernetes manifests
+- **cicd-pipeline** — CI/CD pipelines, quality gates (GitHub Actions, GitLab CI)
+- **infrastructure-as-code** — Terraform, CloudFormation, Pulumi, CDK
+- **deployment-repo** — GitOps polyrepo orchestration, version pinning, promotion
+- **gitops-delivery** — ArgoCD / Flux declarative delivery, drift detection
+- **observability-design** — SLI/SLO/SLA, OpenTelemetry, structured logging, alerting
+- **incident-response** — ACTIVE production incident: triage, mitigate, communicate
+
+### Reflect
+- **retrospective** — sprint retros, project / incident post-mortems, action items
+
+### MLOps
+- **ml-pipeline-design** — training & data pipelines, feature engineering, orchestration
+- **ml-experiment-tracking** — MLflow / W&B / DVC, run comparison, reproducibility
+- **ml-model-deployment** — serving, monitoring, drift detection, safe rollouts
+
+## Golden Path workflow chains
+
+When work spans phases, chain skills rather than improvising:
+
+**New feature**
+`feature-planning` → `architecture-design` (if structural) → `data-modeling`
+(if schema) → `tdd-workflow` → `code-reviewing` → `deployment-checklist`
+
+**Bug / incident**
+`incident-response` (if prod is down) → `bug-investigating` → `tdd-workflow`
+(regression test) → `deployment-checklist`
+
+**Continuous improvement**
+`technical-debt-review` → `refactoring` → `dependency-impact-analysis`
+(blast radius) → `test-suite-design` (if coverage is thin)
+
+**Pre-public / pre-milestone review**
+`strategic-review` (vision, positioning, market) → `project-review` (scope,
+roadmap, implementation, evidence) → synthesis → `artifact-design` (interactive
+report). See `strategic-review/templates/full-review-prompt.md` for the combined brief.
+
+## When NOT to route
+
+- Pure questions, explanations, or conversation with no workflow component.
+- The user named a specific skill or explicitly opted out — follow them.
+- Tiny mechanical edits (typo, rename) where a workflow is overhead.

package/skills/skill-router/evals/evals.json

@@ -0,0 +1,39 @@
+{
+  "skill_name": "skill-router",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "We want to add multi-tenant support to our SaaS app. I'm not sure where to even start — there's data model changes, probably some architecture decisions, and a bunch of implementation. How should I approach this?",
+      "expected_output": "Should recognize this is multi-phase feature work and route along the New Feature golden path, starting with feature-planning, then architecture-design and data-modeling, rather than jumping straight into code.",
+      "assertions": [
+        "Identifies that a dedicated skill / chain applies instead of improvising",
+        "Routes to feature-planning as the entry point",
+        "Names the relevant downstream skills (architecture-design, data-modeling) as next steps",
+        "References the New Feature golden path chain",
+        "Hands off to the chosen skill rather than narrating the routing at length"
+      ]
+    },
+    {
+      "id": 2,
+      "prompt": "What's the difference between a stub and a mock?",
+      "expected_output": "A pure conceptual question with no workflow component. The router should NOT force a skill — it should just answer (optionally noting tdd-workflow/test-suite-design exist if the user later wants to apply it).",
+      "assertions": [
+        "Does NOT invoke a workflow skill for a pure question",
+        "Answers the question directly",
+        "Does not over-route or insist on a workflow",
+        "At most lightly mentions relevant skills as optional"
+      ]
+    },
+    {
+      "id": 3,
+      "prompt": "Just write me a quick Dockerfile for a Node app — don't bother with any of your skill workflows, I'm in a hurry.",
+      "expected_output": "User explicitly opted out of the workflow. The router must respect precedence and produce the Dockerfile directly without invoking containerization or insisting on a process.",
+      "assertions": [
+        "Respects the user's explicit opt-out (does not force the containerization skill)",
+        "Produces the requested Dockerfile directly",
+        "Does not lecture about following the workflow",
+        "Treats user instructions as taking precedence over the soft routing rule"
+      ]
+    }
+  ]
+}

package/skills/strategic-review/SKILL.md

@@ -0,0 +1,106 @@
+---
+name: strategic-review
+description: "Review a project's strategic position before going public, launching, or raising — vision, mission, value proposition, scope positioning, the defensible wedge, and a live competitive / market comparative analysis. Triggers: strategic review, positioning, go public, go-to-market, market analysis, competitive landscape, value proposition, is there a moat, who are our competitors, platform absorption risk, market positioning, comparable products. Use project-review for execution/roadmap/implementation health; delegates deep market scans to deep-research."
+model: opus
+allowed-tools: Read, Grep, Glob, WebFetch, WebSearch, Write, Edit
+---
+
+# Strategic Review
+
+Pressure-test whether a project has a defensible strategic position before it goes
+public. The output is an honest read on vision, positioning, and market — what's
+strong, what rests on unproven assumptions, and where the wedge is closing — ending
+in **strategic options with trade-offs and a recommendation** (not flattery, and
+not a single forced verdict unless asked).
+
+This is the **strategy lens**. For what's actually built and whether it works, run
+`project-review`; the two compose into a full pre-public review (see
+[templates/full-review-prompt.md](templates/full-review-prompt.md)).
+
+## Ground rule: a thesis is a claim, not a fact
+
+State the project's strategic thesis in one sentence, then treat every load-bearing
+assumption inside it as a claim to be tested, not granted. The most valuable thing
+this review produces is naming the assumption the whole strategy rests on — and
+whether there's evidence for it. Mark every market finding **confirmed** (cited
+source, dated) or **inferred**, and date-bound everything ("as of <date>") because
+the competitive landscape moves.
+
+## Step 1: Articulate and critique the vision
+
+Extract, from the project's own materials, the core narrative:
+
+- **Vision / mission** — what change in the world, for whom.
+- **Value proposition** — the specific job it does and why someone switches to it.
+- **The thesis** — the one-sentence bet (e.g. "developers will adopt a neutral
+  standard layer because they run multiple tools and feel the lock-in pain").
+
+Then critique it: Is the value proposition concrete or aspirational? Is the target
+user real and reachable? **Which assumption is load-bearing, and is it proven?**
+(How many users actually have the pain? Would they pay / switch / adopt?)
+
+## Step 2: Scope and positioning
+
+- **Positioning** — what band does this compete in, and against what? Where does it
+  sit relative to incumbents and to the platforms it runs on?
+- **The defensible wedge** — what can this do that the obvious larger players
+  won't or can't, and how durable is that? Separate a real moat (standard,
+  network, data, switching cost) from a temporary head start.
+- **Where positioning is strong vs. where it leans on unproven assumptions** — be
+  explicit about the difference.
+
+## Step 3: Market comparative analysis (live)
+
+Survey the field with current evidence, not memory:
+
+- **Refresh the known bands** — for each established competitor band, who's in it
+  now and what shipped recently.
+- **Hunt for new entrants** — date-bound searches for products that appeared
+  recently in this space, adjacent standards, and platform features that may
+  absorb the category.
+- For a deep, multi-source, fact-checked sweep, **delegate to `deep-research`** and
+  fold its cited report in. For a lighter pass, use `WebSearch`/`WebFetch` directly.
+- **Tag each comparable** with its relationship: **competitor**, **complement**,
+  or **integration target** — and what it means for this project.
+- Label every finding confirmed-vs-inferred and date it.
+
+## Step 4: Trajectory and wedge-closure risk
+
+The dangerous competitor is often the platform, not a peer. Assess:
+
+- **Absorption risk** — is a larger platform shipping features that close the
+  wedge? What's the trajectory over the last 6–12 months?
+- **Timing** — is the window opening or closing, and what evidence says so?
+- **What would invalidate the thesis** — name the observable event that would mean
+  "stop."
+
+## Step 5: Synthesis — potential, weak points, strategic forks
+
+Integrate the above into a decision instrument:
+
+- **Potential** — the genuine strengths and the conditions under which the bet pays off.
+- **Weak points, ranked** — lead with the assumption most likely to be false.
+- **Strategic forks** — present 2–4 distinct paths (e.g. double down / narrow scope /
+  reposition / pivot), each with its trade-offs, then **name a recommended path and
+  why**. Configurable: if the user wants options only or a hard go/no-go, honor that —
+  default is options + a recommendation.
+- **A readiness picture** mapped to the project's own gates, if it has them.
+
+For the rendered deliverable (interactive HTML, scorecards, a forks comparison
+panel), hand off to `artifact-design`; default to a gitignored path (e.g. `.local/`).
+
+## Principles Applied
+
+- **Honesty over hype** — surface the uncomfortable finding first; a review that
+  validates the founder's optimism is worse than none.
+- **Assumptions are the product** — the review's value is naming what must be true.
+- **Current and cited** — date-bound, confirmed-vs-inferred, sourced.
+- **Options with a recommendation** — give the decision-maker the forks *and* a view.
+
+## Cross-Skill References
+
+- `project-review` — the execution half of a pre-public review (roadmap, implementation, evidence).
+- `deep-research` — for the deep, fact-checked market fan-out; fold its report into Step 3.
+- `project-proposal` — when the question is a forward-looking go/no-go business case, not a review.
+- `metrics-and-okrs` — to convert the readiness picture into measurable gates.
+- `artifact-design` — to render the review as a polished interactive decision instrument.

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

@@ -0,0 +1,42 @@
+{
+  "skill_name": "strategic-review",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "We're considering taking our open-source developer tool public in a couple of months. Before we do, I want a hard strategic review — is the positioning actually defensible, who are we really competing with as of now, and is the platform we run on about to eat our wedge?",
+      "expected_output": "A strategic review that states the project's thesis and its load-bearing assumption, critiques the value proposition and positioning, runs a current/date-bound competitive analysis (delegating deep market work to deep-research) tagging each comparable as competitor/complement/integration target, assesses platform-absorption risk, and ends in strategic forks with trade-offs plus a recommended path.",
+      "assertions": [
+        "States the project's strategic thesis in one sentence and identifies the load-bearing assumption to test",
+        "Critiques the value proposition / positioning, separating what's strong from what rests on unproven assumptions",
+        "Runs a live, date-bound competitive analysis rather than relying on memory, and delegates a deep sweep to deep-research",
+        "Tags comparables by relationship (competitor / complement / integration target)",
+        "Assesses platform-absorption / wedge-closure risk and names what would invalidate the thesis",
+        "Ends with strategic forks (trade-offs) and a recommended path, labeling findings confirmed vs inferred and dated",
+        "Defers implementation/roadmap/evidence questions to project-review"
+      ]
+    },
+    {
+      "id": 2,
+      "prompt": "Honestly the space we're in feels crowded and I'm not sure what makes us different anymore. Big platforms keep shipping features that overlap with ours. Is there even a defensible wedge here?",
+      "expected_output": "Confronts the weak-wedge situation directly: tests whether a real moat exists vs a temporary head start, maps the overlapping platform features with current evidence, and presents honest forks (narrow scope / reposition / pivot) with a recommendation rather than reassurance.",
+      "assertions": [
+        "Distinguishes a durable moat (standard, network, data, switching cost) from a temporary head start",
+        "Examines the overlapping platform/incumbent features with current, dated evidence",
+        "Does not offer false reassurance — willing to conclude the wedge is thin if that's what the evidence shows",
+        "Presents distinct strategic forks (e.g. narrow / reposition / pivot) with trade-offs and a recommendation",
+        "Names the observable event that would invalidate continuing"
+      ]
+    },
+    {
+      "id": 3,
+      "prompt": "I'm writing the one-line tagline for our landing page. Should it say 'fast' or 'simple'?",
+      "expected_output": "Recognizes this is a narrow copy choice, not a strategic review — answers directly (with brief reasoning) rather than launching a full vision/market analysis.",
+      "assertions": [
+        "Recognizes this is a small copy/messaging question, not a strategic review",
+        "Does not launch the full strategic-review workflow (thesis, market scan, forks)",
+        "Answers the tagline question directly with brief, practical reasoning",
+        "May note that messaging should follow from positioning if a deeper review is ever wanted"
+      ]
+    }
+  ]
+}