@rune-kit/rune 2.1.1

package/skills/dependency-doctor/SKILL.md

@@ -0,0 +1,235 @@
+---
+name: dependency-doctor
+description: Dependency health management. Detects package manager, checks outdated packages and vulnerabilities, and produces a prioritized update plan.
+metadata:
+  author: runedev
+  version: "0.2.0"
+  layer: L3
+  model: haiku
+  group: deps
+  tools: "Read, Bash, Glob, Grep"
+---
+
+# dependency-doctor
+
+## Purpose
+
+Dependency health management covering outdated packages, known vulnerabilities, and update planning. Detects the package manager automatically, runs audit commands, analyzes breaking changes for major version bumps, and outputs a prioritized update plan with risk assessment.
+
+## Called By (inbound)
+
+- `rescue` (L1): Phase 0 dependency health assessment
+- `audit` (L2): Phase 1 vulnerability scan and outdated dependency check
+
+## Calls (outbound)
+
+None — pure L3 utility using Bash for package manager commands.
+
+## Executable Instructions
+
+### Step 1: Detect Package Manager
+
+Use `Glob` to find dependency files in the project root:
+
+- `package.json` → Node.js (npm, yarn, or pnpm)
+- `requirements.txt` or `pyproject.toml` → Python (pip or uv)
+- `Cargo.toml` → Rust (cargo)
+- `go.mod` → Go (go)
+- `Gemfile` → Ruby (bundler)
+
+If multiple are found, process all of them. If none found, report NO_DEPENDENCY_FILES and stop.
+
+For Node.js, further detect the package manager:
+- `yarn.lock` present → yarn
+- `pnpm-lock.yaml` present → pnpm
+- `package-lock.json` present → npm
+- None → default to npm
+
+### Step 2: List Dependencies
+
+Use `Read` to parse the dependency file and extract:
+- Package name
+- Current version constraint
+- Whether it is a dev dependency or production dependency
+
+For `package.json`, read both `dependencies` and `devDependencies` sections.
+
+### Step 3: Check Outdated
+
+Run the appropriate command via `Bash` to find outdated packages:
+
+**npm:**
+```bash
+npm outdated --json
+```
+
+**yarn:**
+```bash
+yarn outdated --json
+```
+
+**pnpm:**
+```bash
+pnpm outdated
+```
+
+**pip:**
+```bash
+pip list --outdated --format=json
+```
+
+**cargo:**
+```bash
+cargo outdated
+```
+
+**go:**
+```bash
+go list -u -m all
+```
+
+Parse the output to extract for each outdated package:
+- Current version
+- Latest version
+- Update type: `patch` | `minor` | `major`
+
+### Step 4: Check Vulnerabilities
+
+Run the appropriate audit command via `Bash`:
+
+**npm:**
+```bash
+npm audit --json
+```
+
+**yarn:**
+```bash
+yarn audit --json
+```
+
+**pnpm:**
+```bash
+pnpm audit --json
+```
+
+**pip:**
+```bash
+pip-audit --format json
+```
+
+**cargo:**
+```bash
+cargo audit --json
+```
+
+If the audit tool is not installed, note it as TOOL_MISSING and skip this step (do not fail).
+
+Parse the output to extract:
+- Package name + vulnerable version
+- CVE ID (if available)
+- Severity: `critical` | `high` | `moderate` | `low`
+- Fixed version (if available)
+
+### Step 5: Analyze Breaking Changes
+
+For each package with a **major** version bump (e.g. v2 → v3):
+
+Use `rune:docs-seeker` to look up migration guides if available, or note:
+- "Breaking change analysis required before updating [package] from v[X] to v[Y]"
+
+Do not blindly recommend major updates without flagging migration risk.
+
+### Step 6: Generate Update Plan
+
+Create a prioritized update plan:
+
+Priority order:
+1. **CRITICAL** — packages with critical/high CVEs → update immediately
+2. **SECURITY** — packages with moderate/low CVEs → update in current sprint
+3. **PATCH** — patch version bumps, no breaking changes → safe to batch update
+4. **MINOR** — minor version bumps, new features added → update with testing
+5. **MAJOR** — major version bumps, breaking changes → plan migration separately
+
+For each item in the plan, include:
+- Package name + current → target version
+- Update type and risk level
+- Migration notes (for major updates)
+- Suggested command to run the update
+
+### Step 7: Report
+
+Output the following structure:
+
+```
+## Dependency Report: [project name]
+
+- **Package Manager**: [npm|yarn|pnpm|pip|cargo|go]
+- **Total Dependencies**: [count]
+- **Outdated**: [count]
+- **Vulnerable**: [count] ([critical] critical, [high] high, [moderate] moderate)
+
+### Critical — CVEs (Fix Immediately)
+- [package]@[current] — [CVE-ID] ([severity]): [description]
+  Fix: npm update [package]@[fixed_version]
+
+### Security — CVEs (Fix This Sprint)
+- [package]@[current] — [CVE-ID] ([severity]): [description]
+
+### Outdated — Patch (Safe to Update)
+- [package]@[current] → [latest] (patch)
+
+### Outdated — Minor (Update with Testing)
+- [package]@[current] → [latest] (minor)
+
+### Outdated — Major (Plan Migration)
+- [package]@[current] → [latest] (major) — migration guide required
+
+### Unused Dependencies
+- [package] — no imports found in src/
+
+### Update Plan (Ordered by Risk)
+1. [command] — fixes [CVE-ID]
+2. [command] — patch updates (safe batch)
+3. [command] — requires migration: [notes]
+
+### Dependency Health Score
+- Score: [0-100]
+- Grade: A (80-100) | B (60-79) | C (40-59) | D (<40)
+- Score basis: -10 per critical CVE, -5 per high CVE, -2 per outdated major, -1 per outdated minor
+```
+
+## Output Format
+
+Dependency Report with package manager, counts, CVE findings by severity, outdated packages by risk level, unused dependencies, ordered update plan, and health score (0-100). See Step 7 Report above for full template.
+
+## Constraints
+
+1. MUST check for known vulnerabilities — not just version freshness
+2. MUST NOT auto-upgrade major versions without user confirmation — breaking changes
+3. MUST verify project still builds after any dependency change
+4. MUST show what changed (added, removed, upgraded) in a clear diff format
+
+## Sharp Edges
+
+Known failure modes for this skill. Check these before declaring done.
+
+| Failure Mode | Severity | Mitigation |
+|---|---|---|
+| Recommending major version update without flagging migration risk | CRITICAL | Constraint 2: breaking changes need explicit migration notes and user confirmation |
+| Silently skipping vulnerability check when tool not installed | HIGH | Report TOOL_MISSING explicitly — never skip without logging it |
+| Missing dependency health score (0-100) | MEDIUM | Score is mandatory in every report — it gives callers a quick health signal |
+| Reporting unused dependencies without verifying (false positive) | MEDIUM | Check actual import patterns in src/ before flagging as unused |
+
+## Done When
+
+- Package manager detected (npm/yarn/pnpm/pip/cargo/go)
+- Outdated packages listed with current → latest versions and update type
+- Vulnerability audit run (or TOOL_MISSING noted explicitly)
+- Breaking changes flagged for all major version bumps
+- Prioritized update plan generated (CRITICAL → SECURITY → PATCH → MINOR → MAJOR order)
+- Dependency health score (0-100) calculated
+- Dependency Report emitted in output format
+
+## Cost Profile
+
+~300-600 tokens input, ~200-500 tokens output. Haiku. Most time spent in package manager commands.

package/skills/deploy/SKILL.md

@@ -0,0 +1,174 @@
+---
+name: deploy
+description: "Deploy application to target platform. Use when user explicitly says 'deploy', 'push to production', 'ship it'. Handles Vercel, Netlify, AWS, GCP, DigitalOcean, and VPS with pre-deploy verification and health checks."
+disable-model-invocation: true
+metadata:
+  author: runedev
+  version: "0.3.0"
+  layer: L2
+  model: sonnet
+  group: delivery
+  tools: "Read, Write, Edit, Bash, Glob, Grep"
+---
+
+# deploy
+
+## Purpose
+
+Deploy applications to target platforms. Handles the full deployment flow — environment configuration, build, push, verification, and rollback if needed. Supports Vercel, Netlify, AWS, GCP, DigitalOcean, and custom VPS via SSH.
+
+<HARD-GATE>
+- Tests MUST pass (via `rune:verification`) before deploy runs
+- Sentinel MUST pass (no CRITICAL issues) before deploy runs
+- Both are non-negotiable. Failure = stop + report, never skip
+</HARD-GATE>
+
+## Called By (inbound)
+
+- `launch` (L1): deployment phase of launch pipeline
+- User: `/rune deploy` direct invocation
+
+## Calls (outbound)
+
+- `test` (L2): pre-deploy full test suite
+- `db` (L2): pre-deploy migration safety check
+- `perf` (L2): pre-deploy performance regression check
+- `verification` (L2): pre-deploy build + lint + type check
+- `sentinel` (L2): pre-deploy security scan
+- `browser-pilot` (L3): verify live deployment visually
+- `watchdog` (L3): setup post-deploy monitoring
+- `journal` (L3): record deploy decision, rollback plan, and post-deploy status
+- `incident` (L2): if post-deploy health check fails → triage and contain
+- L4 extension packs: domain-specific deploy patterns when context matches (e.g., @rune/devops for infrastructure)
+
+## Cross-Hub Connections
+
+- `deploy` → `verification` — pre-deploy tests + build must pass
+- `deploy` → `sentinel` — security must pass before push
+
+## Execution Steps
+
+### Step 1 — Pre-deploy checks (HARD-GATE)
+
+Call `rune:verification` to run the full test suite and build.
+
+```
+If verification fails → STOP. Do NOT proceed. Report failure with test output.
+```
+
+Call `rune:sentinel` to run security scan.
+
+```
+If sentinel returns CRITICAL issues → STOP. Do NOT proceed. Report issues.
+```
+
+Both gates MUST pass. No exceptions.
+
+### Step 2 — Detect platform
+
+Use `Bash` to inspect the project root for platform config files:
+
+```bash
+ls vercel.json netlify.toml Dockerfile fly.toml 2>/dev/null
+cat package.json | grep -A5 '"scripts"'
+```
+
+Map findings to platform:
+
+| File found | Platform |
+|---|---|
+| `vercel.json` | Vercel |
+| `netlify.toml` | Netlify |
+| `fly.toml` | Fly.io |
+| `Dockerfile` | Docker / VPS |
+| `package.json` deploy script | npm deploy |
+
+If no config found, ask the user which platform to target before continuing.
+
+### Step 3 — Deploy
+
+Use `Bash` to run the platform-specific deploy command:
+
+| Platform | Command |
+|---|---|
+| Vercel | `vercel --prod` |
+| Netlify | `netlify deploy --prod` |
+| Fly.io | `fly deploy` |
+| Docker | `docker build -t app . && docker push <registry>/app` |
+| npm script | `npm run deploy` |
+
+Capture full command output. Extract deployed URL from output.
+
+### Step 4 — Verify deployment
+
+Use `Bash` to check the deployed URL returns HTTP 200:
+
+```bash
+curl -o /dev/null -s -w "%{http_code}" <deployed-url>
+```
+
+If status is not 200 → flag as WARNING, do not treat as hard failure unless 5xx.
+
+If `rune:browser-pilot` is available, call it to take a screenshot of the deployed URL for visual confirmation.
+
+### Step 5 — Monitor
+
+Call `rune:watchdog` to set up post-deploy monitoring alerts on the deployed URL.
+
+### Step 6 — Report
+
+Output the deploy report:
+
+```
+## Deploy Report
+- **Platform**: [target]
+- **Status**: success | failed | rollback
+- **URL**: [deployed URL]
+- **Build Time**: [duration]
+
+### Checks
+- Tests: passed | failed
+- Security: passed | failed ([count] issues)
+- HTTP Status: [code]
+- Visual: [screenshot path if browser-pilot ran]
+- Monitoring: active | skipped
+```
+
+If any step failed, include the error output and recommended next action.
+
+## Output Format
+
+Deploy Report with platform, status (success/failed/rollback), deployed URL, build time, and checks (tests, security, HTTP, visual, monitoring). See Step 6 Report above for full template.
+
+## Constraints
+
+1. MUST verify tests + sentinel pass before deploying — non-negotiable
+2. MUST have rollback strategy documented before production deploy
+3. MUST verify deploy is live and responding before declaring success
+4. MUST NOT deploy with known CRITICAL security findings
+5. MUST log deploy metadata (version, timestamp, commit hash)
+
+## Sharp Edges
+
+Known failure modes for this skill. Check these before declaring done.
+
+| Failure Mode | Severity | Mitigation |
+|---|---|---|
+| Deploying without verification passing | CRITICAL | HARD-GATE blocks this — both verification AND sentinel must pass first |
+| Platform auto-detected wrongly and wrong command runs | HIGH | Verify config files explicitly; ask user if multiple platforms detected |
+| HTTP 5xx on live URL treated as non-critical | HIGH | 5xx = deployment likely failed — report FAILED, do not proceed to monitoring/marketing |
+| Not setting up watchdog monitoring after deploy | MEDIUM | Step 5 is mandatory — post-deploy monitoring is part of deploy, not optional |
+| Deploy metadata not logged (version, commit hash) | LOW | Constraint 5: log version + timestamp + commit hash in report |
+
+## Done When
+
+- verification PASS (tests, types, lint, build all green)
+- sentinel PASS (no CRITICAL security findings)
+- Deploy command succeeded with live URL captured
+- Live URL returns HTTP 200
+- watchdog monitoring active on deployed URL
+- Deploy Report emitted with platform, URL, checks, and monitoring status
+
+## Cost Profile
+
+~1000-3000 tokens input, ~500-1000 tokens output. Sonnet. Most time in build/deploy commands.