@nerdev/skillset 0.2.1

package/skills/workflow/context-restore/SKILL.md

@@ -0,0 +1,69 @@
+---
+name: context-restore
+version: 1.0.0
+description: "Restore working context saved earlier by /context-save."
+triggers:
+  - resume where i left off
+  - restore context
+  - where was i
+  - pick up where i left off
+  - context restore
+---
+
+## When to use
+
+Use when asked to "resume", "restore context", "where was I", or "pick up where I left off". Pair with /context-save.
+
+Do NOT implement code changes. This skill reads saved context files only.
+
+## Restore flow
+
+### Step 1: find saved contexts
+
+```bash
+CONTEXT_DIR=".opencode/contexts"
+if [ ! -d "$CONTEXT_DIR" ]; then
+  echo "NO_CONTEXTS"
+else
+  find "$CONTEXT_DIR" -maxdepth 1 -name "*.md" -type f 2>/dev/null | sort -r | head -20
+fi
+```
+
+### Step 2: load the right file
+
+If the user specified a title fragment or number, find the matching file. Otherwise load the most recent one.
+
+Read the file and present:
+
+```
+RESUMING CONTEXT
+Title:       {title}
+Branch:      {branch}
+Saved:       {timestamp}
+Status:      {status}
+
+### Summary
+{summary from saved file}
+
+### Remaining Work
+{remaining work items}
+
+### Notes
+{notes}
+```
+
+If the current branch differs from the saved context's branch, note it.
+
+### Step 3: offer next steps
+
+Ask: continue working, show full file, or just needed context.
+
+## If no saved contexts exist
+
+"No saved contexts yet. Run `/context-save` first to save your current working state."
+
+## Important rules
+
+- Never modify code. Read saved files and present them only.
+- Prefer the current branch's checkpoint, but keep all branches as fallback.
+- "Most recent" means filename prefix (YYYYMMDD-HHMMSS), not filesystem mtime.

package/skills/workflow/context-save/SKILL.md

@@ -0,0 +1,96 @@
+---
+name: context-save
+version: 1.0.0
+description: "Save working context so any future session can pick up without losing a beat."
+triggers:
+  - save progress
+  - save state
+  - save my work
+  - context save
+---
+
+## When to use
+
+Use when asked to "save progress", "save state", "context save", or "save my work". Pair with /context-restore to resume later.
+
+Do NOT implement code changes. This skill captures state only.
+
+## Save flow
+
+### Step 1: gather state
+
+```bash
+echo "=== BRANCH ==="
+git rev-parse --abbrev-ref HEAD 2>/dev/null
+echo "=== STATUS ==="
+git status --short 2>/dev/null
+echo "=== DIFF STAT ==="
+git diff --stat 2>/dev/null
+echo "=== STAGED DIFF STAT ==="
+git diff --cached --stat 2>/dev/null
+echo "=== RECENT LOG ==="
+git log --oneline -10 2>/dev/null
+```
+
+### Step 2: summarize context
+
+Using the gathered state plus conversation history, write a summary covering:
+
+1. What's being worked on.
+2. Decisions made. Architectural choices, trade-offs, approaches chosen and why.
+3. Remaining work. Concrete next steps, in priority order.
+4. Notes. Gotchas, blocked items, open questions, things tried that didn't work.
+
+### Step 3: write the file
+
+```bash
+CONTEXT_DIR=".opencode/contexts"
+mkdir -p "$CONTEXT_DIR"
+TIMESTAMP=$(date +%Y%m%d-%H%M%S)
+FILE="$CONTEXT_DIR/${TIMESTAMP}-context.md"
+```
+
+File format:
+
+```markdown
+---
+status: in-progress
+branch: {current branch name}
+timestamp: {ISO-8601 timestamp}
+files_modified:
+  - path/to/file1
+  - path/to/file2
+---
+
+## Working on: {title}
+
+### Summary
+{1-3 sentences about the goal and current progress}
+
+### Decisions Made
+{Bulleted list of choices and reasoning}
+
+### Remaining Work
+{Numbered list of next steps}
+
+### Notes
+{Gotchas, blocked items, open questions}
+```
+
+After writing, confirm:
+
+```
+CONTEXT SAVED
+Title:    {title}
+Branch:   {branch}
+File:     {path}
+Modified: {N} files
+
+Restore later with /context-restore.
+```
+
+## Important rules
+
+- Never modify code. Read state and write the context file only.
+- Always include the branch name. It matters for cross-branch restore.
+- Saved files are append-only. Never overwrite existing files.

package/skills/workflow/health/SKILL.md

@@ -0,0 +1,99 @@
+---
+name: health
+version: 1.0.0
+description: "Code quality dashboard. Wraps type checker, linter, test runner, dead code detector. Computes a weighted composite score."
+triggers:
+  - code health check
+  - quality dashboard
+  - how healthy is codebase
+  - health check
+  - quality score
+---
+
+## When to use
+
+Use when asked for a "health check", "code quality", "how healthy is the codebase", "run all checks", or "quality score".
+
+Do NOT fix any issues. Produce the dashboard and recommendations only.
+
+## Step 1: detect health stack
+
+Auto-detect available tools:
+
+```bash
+[ -f tsconfig.json ] && echo "TYPECHECK: tsc --noEmit"
+[ -f biome.json ] || [ -f biome.jsonc ] && echo "LINT: biome check ."
+ls eslint.config.* .eslintrc.* 2>/dev/null | head -1 && echo "LINT: eslint ."
+[ -f .pylintrc ] || [ -f pyproject.toml ] && echo "LINT: ruff check ."
+[ -f package.json ] && grep -q '"test"' package.json && echo "TEST: npm test"
+[ -f pyproject.toml ] && echo "TEST: pytest"
+[ -f Cargo.toml ] && echo "TEST: cargo test"
+[ -f go.mod ] && echo "TEST: go test ./..."
+command -v knip >/dev/null 2>&1 && echo "DEADCODE: knip"
+```
+
+## Step 2: run tools
+
+Run each detected tool sequentially. Record exit code, duration, and last 50 lines of output.
+
+```bash
+START=$(date +%s)
+{command} 2>&1 | tail -50
+EXIT_CODE=$?
+END=$(date +%s)
+echo "TOOL:{name} EXIT:$EXIT_CODE DURATION:$((END-START))s"
+```
+
+## Step 3: score each category
+
+| Category | Weight | 10 | 7 | 4 | 0 |
+|-----------|--------|------|-----------|------------|-----------|
+| Type check | 22% | Clean (exit 0) | <10 errors | <50 errors | >=50 errors |
+| Lint | 18% | Clean (exit 0) | <5 warnings | <20 warnings | >=20 warnings |
+| Tests | 28% | All pass (exit 0) | >95% pass | >80% pass | <=80% pass |
+| Dead code | 13% | Clean (exit 0) | <5 unused | <20 unused | >=20 unused |
+| Shell lint | 9% | Clean (exit 0) | <5 issues | >=5 issues | N/A |
+
+Composite score: `(typecheck * 0.22) + (lint * 0.18) + (test * 0.28) + (deadcode * 0.13) + (shell * 0.09)`
+
+Redistribute weight proportionally for skipped categories.
+
+## Step 4: present dashboard
+
+```
+CODE HEALTH DASHBOARD
+
+Project: <project name>
+Branch:  <current branch>
+Date:    <today>
+
+Category      Tool              Score   Status     Duration   Details
+----------    ----------------  -----   --------   --------   -------
+Type check    tsc --noEmit      10/10   CLEAN      3s         0 errors
+Lint          biome check .      8/10   WARNING    2s         3 warnings
+Tests         bun test          10/10   CLEAN      12s        47/47 passed
+Dead code     knip               7/10   WARNING    5s         4 unused exports
+
+COMPOSITE SCORE: 9.1 / 10
+Duration: 23s total
+```
+
+Status labels: 10 = CLEAN, 7-9 = WARNING, 4-6 = NEEDS WORK, 0-3 = CRITICAL.
+
+## Step 5: recommendations
+
+Rank by impact (weight * score deficit). Only show categories below 10.
+
+```
+RECOMMENDATIONS (by impact)
+1. [HIGH]  Fix 2 failing tests (Tests: 9/10, weight 30%)
+2. [MED]   Address 12 lint warnings (Lint: 6/10, weight 20%)
+3. [LOW]   Remove 4 unused exports (Dead code: 7/10, weight 15%)
+```
+
+## Important rules
+
+1. Run the project's own tools. Don't substitute your own analysis.
+2. Read-only. Never fix issues.
+3. Skipped is not failed. Redistribute weight for unavailable tools.
+4. Show raw output for failures so the user can act without re-running.

package/skills/workflow/learn/SKILL.md

@@ -0,0 +1,95 @@
+---
+name: learn
+version: 1.0.0
+description: "Manage project learnings. Review, search, prune, and export patterns across sessions."
+triggers:
+  - show learnings
+  - what have we learned
+  - manage project learnings
+  - learn
+---
+
+## When to use
+
+Use when asked to "what have we learned", "show learnings", "prune stale learnings", or "export learnings".
+
+Proactively suggest when the user asks about past patterns or wonders "didn't we fix this before?"
+
+Do NOT implement code changes. This skill manages learnings only.
+
+## Commands
+
+- `/learn` shows recent learnings.
+- `/learn search <query>` searches them.
+- `/learn prune` checks for stale or contradictory entries.
+- `/learn export` formats them as markdown.
+- `/learn add` lets you add one manually.
+
+## Show recent
+
+Show the most recent 20 learnings:
+
+```bash
+LEARN_FILE=".opencode/learnings.jsonl"
+if [ -f "$LEARN_FILE" ]; then
+  tail -20 "$LEARN_FILE"
+else
+  echo "No learnings yet."
+fi
+```
+
+Present in a readable format grouped by type: pattern, pitfall, preference, architecture.
+
+## Search
+
+```bash
+grep -i "QUERY" .opencode/learnings.jsonl 2>/dev/null | tail -20
+```
+
+## Prune
+
+Load all learnings and check for:
+1. Stale references. If a learning references files that no longer exist.
+2. Contradictions. Same key with different insights.
+
+Present each flagged entry and ask: remove, keep, or update.
+
+## Export
+
+Format learnings as markdown:
+
+```markdown
+## Project Learnings
+
+### Patterns
+- **[key]**: [insight] (confidence: N/10)
+
+### Pitfalls
+- **[key]**: [insight] (confidence: N/10)
+
+### Preferences
+- **[key]**: [insight]
+
+### Architecture
+- **[key]**: [insight] (confidence: N/10)
+```
+
+## Manual add
+
+Ask the user for: type (pattern, pitfall, preference, architecture, tool), a short key (2-5 words, kebab-case), the insight (one sentence), and confidence (1-10).
+
+Then log it:
+
+```bash
+mkdir -p .opencode
+echo '{"type":"TYPE","key":"KEY","insight":"INSIGHT","confidence":N,"source":"user-stated","ts":"'$(date -u +%Y-%m-%dT%H:%M:%SZ)'"}' >> .opencode/learnings.jsonl
+```
+
+## Automatic logging
+
+After completing any skill, review the session for durable learnings and log each one. A durable learning is a project quirk, command fix, pitfall, or pattern that would save 5+ minutes in a future session. If none, say "No durable learnings this session."
+
+```bash
+mkdir -p .opencode
+echo '{"type":"operational","key":"SHORT_KEY","insight":"DESCRIPTION","confidence":N,"source":"observed","ts":"'$(date -u +%Y-%m-%dT%H:%M:%SZ)'"}' >> .opencode/learnings.jsonl
+```

package/skills/workflow/office-hours/SKILL.md

@@ -0,0 +1,136 @@
+---
+name: office-hours
+version: 1.0.0
+description: "YC office hours. Six forcing questions that reframe your product before you write code. Produces a design doc, not code."
+triggers:
+  - brainstorm this
+  - is this worth building
+  - help me think through
+  - office hours
+  - I have an idea
+---
+
+## When to use
+
+Use when asked to "brainstorm this", "I have an idea", "help me think through this", "office hours", or "is this worth building".
+
+Proactively invoke when the user describes a new product idea, asks whether something is worth building, or wants to think through design decisions before any code exists.
+
+Do NOT write code. Your only output is a design document.
+
+## Voice
+
+- Lead with the point. Be concrete. Name files, functions, line numbers.
+- Sound like a builder talking to a builder.
+- No em dashes. No AI vocabulary: delve, crucial, robust, comprehensive, nuanced, multifaceted, furthermore, moreover, additionally, pivotal, landscape, tapestry, underscore, foster, showcase, intricate, vibrant, fundamental, significant.
+- The user has context you do not: domain knowledge, timing, relationships, taste.
+
+## Phase 1: Context gathering
+
+1. Read CLAUDE.md, TODOS.md if they exist.
+2. Run `git log --oneline -30` and `git diff origin/main --stat` to understand recent context.
+3. Use Grep/Glob to map the codebase areas most relevant to the request.
+
+## Phase 2: Goal detection
+
+Ask the user:
+
+> Before we dig in, what's your goal with this?
+>
+> - **Building a startup** or thinking about it
+> - **Intrapreneurship.** Internal project, need to ship fast.
+> - **Hackathon / demo.** Time-boxed, need to impress.
+> - **Open source / research.** Building for a community.
+> - **Learning.** Teaching yourself, vibe coding.
+> - **Having fun.** Side project, creative outlet.
+
+Startup and intrapreneurship go to Phase 3A. Everything else goes to Phase 3B.
+
+## Phase 3A: Startup mode, YC product diagnostic
+
+Ask these six questions one at a time. After each, reflect back what you heard and push back where the framing is weak.
+
+### Question 1: demand reality
+
+"Who specifically has this problem? How do you know? Have they tried to solve it themselves?"
+
+If the user says "everyone" or "developers in general", narrow it. Specificity is signal.
+
+### Question 2: status quo
+
+"What do these people use today? Why haven't they switched to something better?"
+
+If the answer is "nothing", probe harder. They're using something, even if it's a spreadsheet or their memory.
+
+### Question 3: desperate specificity
+
+"Describe the exact moment when someone hits this pain. What are they doing? What goes wrong?"
+
+Vague pain ("it's annoying") is not a product opportunity. The moment needs to be vivid enough to storyboard.
+
+### Question 4: narrowest wedge
+
+"What's the smallest possible version that would make one person switch? Not a platform. A wedge."
+
+If the answer involves more than 3 features, it's too big for v1. Cut harder.
+
+### Question 5: observation
+
+"What have you personally seen that makes you believe this is a real problem?"
+
+"I think this would be useful" is not an observation. "I watched my co-founder spend 4 hours doing X" is.
+
+### Question 6: future-fit
+
+"If this works perfectly in 12 months, what does the world look like?"
+
+Let them dream, then rein it back to the wedge.
+
+## Phase 3B: Builder mode, design partner
+
+For side projects, hackathons, learning, and open source.
+
+1. What's the spark? What made you think of this? What's exciting about it?
+2. Who's it for? Even if it's for you, describe your ideal user.
+3. What's the wild version? If there were no constraints, what would this become?
+4. What's the MVP? The smallest thing that proves the concept works.
+5. What would make you proud? Ship it tomorrow vs. 3 months from now. What's the minimum you'd be proud to show?
+
+## Phase 4: Alternatives
+
+After understanding the problem, present 2-3 implementation approaches.
+
+For each: what it is (one sentence), effort estimate (days/weeks), what you learn, what you sacrifice.
+
+## Phase 5: Design doc
+
+Write a design doc to `docs/designs/{slug}-design-{date}.md`:
+
+```markdown
+# {Title} Design Doc
+
+## Problem
+What problem are we solving and for whom?
+
+## Context
+What do we know? What observations led here?
+
+## Goal
+What does success look like?
+
+## Non-Goals
+What are we explicitly NOT doing?
+
+## Approach
+2-3 options with tradeoffs.
+
+## Recommendation
+Which option and why.
+
+## Open Questions
+What's still unclear?
+```
+
+## Completion
+
+Report what was discussed, what was decided, where the doc lives. Suggest the next step.

package/skills/workflow/ship/SKILL.md

@@ -0,0 +1,95 @@
+---
+name: ship
+version: 1.0.0
+description: "Ship workflow: detect base branch, run tests, review diff, commit, push, create PR."
+triggers:
+  - ship it
+  - create a pr
+  - push to main
+  - deploy this
+  - let's ship
+---
+
+## When to use
+
+Use when asked to "ship", "deploy", "push to main", "create a PR", or "get it deployed".
+
+Proactively suggest when the user says code is ready or asks about deploying.
+
+## Voice
+
+- Lead with the point. Be concrete.
+- Sound like a builder talking to a builder.
+- No em dashes. No AI vocabulary.
+- Bounded closer: what changed, what was skipped, what to watch.
+
+## Step 0: detect platform and base branch
+
+```bash
+git remote get-url origin 2>/dev/null
+```
+
+GitHub: `gh pr view --json baseRefName -q .baseRefName` or `gh repo view --json defaultBranchRef -q .defaultBranchRef.name`.
+
+GitLab: `glab mr view -F json 2>/dev/null` or `glab repo view -F json 2>/dev/null`.
+
+Fallback: `git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null | sed 's|refs/remotes/origin/||'`, then `main`, then `master`.
+
+## Step 1: pre-flight
+
+1. Check the current branch. If on the base branch, abort. "You're on the base branch. Ship from a feature branch."
+2. Run `git status`. Uncommitted changes are always included.
+3. Run `git diff <base>...HEAD --stat` and `git log <base>..HEAD --oneline`.
+
+## Step 2: run tests
+
+Detect and run the project's test suite:
+
+```bash
+[ -f package.json ] && npm test 2>&1
+[ -f pyproject.toml ] && python -m pytest 2>&1
+[ -f setup.py ] && python -m pytest 2>&1
+[ -f go.mod ] && go test ./... 2>&1
+[ -f Cargo.toml ] && cargo test 2>&1
+```
+
+If tests fail, report the failures and ask whether to proceed or fix first.
+
+## Step 3: review diff
+
+Read the diff and check for:
+- Obvious bugs (null checks, error handling, edge cases)
+- Hardcoded secrets or credentials
+- Files that shouldn't be committed (build artifacts, .env, node_modules)
+- Missing tests for new functionality
+
+Auto-fix obvious issues. Flag ambiguous ones for the user.
+
+## Step 4: commit
+
+Stage changes and commit with a descriptive message:
+
+```bash
+git add -A
+git commit -m "{type}: {description}"
+```
+
+Use conventional commit format: feat, fix, refactor, docs, test, chore.
+
+## Step 5: push
+
+```bash
+git push origin {branch}
+```
+
+## Step 6: create PR
+
+```bash
+gh pr create --base {base} --title "{title}" --body "{description}"
+```
+
+PR body should include what changed, why it changed, how to test it, and any breaking changes.
+
+## Completion
+
+Report the PR URL, number of files changed, and any concerns.

package/vendor.json

@@ -0,0 +1,80 @@
+{
+  "$schema": "./docs/vendor.schema.json",
+  "upstreams": [
+    {
+      "name": "impeccable",
+      "repo": "pbakaus/impeccable",
+      "commit": "e0881d2de397d5e9761d7b35ff5017d8f5ebf69b",
+      "source": ".opencode/skills",
+      "skills": [
+        {
+          "name": "impeccable",
+          "dest": "ui/impeccable",
+          "sha256": "0bf06a4113be945f911e3a64457c923b57b000f5129ab92272db9bcb5289ef7f"
+        }
+      ]
+    },
+    {
+      "name": "taste-skill",
+      "repo": "Leonxlnx/taste-skill",
+      "commit": "c184364c58658b2f131b4ae8bd3d206cabb3deee",
+      "source": "skills",
+      "skills": [
+        {
+          "name": "output-skill",
+          "dest": "quality/output-skill",
+          "sha256": "f07af7f89f8ade4c8e23f7480295b63f5cacae52d3d0524ab8cb2c1707d6951e"
+        }
+      ]
+    },
+    {
+      "name": "emil-skills",
+      "repo": "emilkowalski/skills",
+      "commit": "85e8e2363b713506e1d5b6e07a0eb2da66be1bc3",
+      "source": "skills",
+      "skills": [
+        {
+          "name": "ask-sonner",
+          "dest": "ui/ask-sonner",
+          "sha256": "54fadebaeb6b904ec77ef9d288edde366645f5d93794dc6137e94c196aeb6163"
+        },
+        {
+          "name": "pick-ui-library",
+          "dest": "ui/pick-ui-library",
+          "sha256": "1204b873a8918bed93e125e2d2ef5e479e5cfcb6f1a63068bbd867b07db4f0d1"
+        },
+        {
+          "name": "prototype",
+          "dest": "ui/prototype",
+          "sha256": "fbafb2c083b74232e78dcbd1685cf02d90310d474aa9489a22a46025fbffccad"
+        }
+      ]
+    },
+    {
+      "name": "pstack",
+      "repo": "cursor/plugins",
+      "commit": "b42effe0aa50f59c693d7e2924714e015e00bf7c",
+      "source": "pstack/skills",
+      "skills": [
+        {
+          "name": "unslop",
+          "dest": "quality/unslop",
+          "sha256": "6542a1662aa6be597b22d6ef030598a0c20c7a11f06b3eea7fcaad106ffe817d"
+        }
+      ]
+    },
+    {
+      "name": "brag",
+      "repo": "latent-spaces/brag",
+      "commit": "57ce4c9bb912f01a0078b154318bf67c5cbf780f",
+      "source": "skills",
+      "skills": [
+        {
+          "name": "brag",
+          "dest": "business/brag",
+          "sha256": "8654789421c6215a86200085a98accd8d61350ea5e94800401048d300348effa"
+        }
+      ]
+    }
+  ]
+}