@wrongstack/core 0.6.4 → 0.6.6

package/skills/sdd/SKILL.md

@@ -1,165 +1,123 @@
----
-name: sdd
-description: |
-  Specification-driven development workflow. Covers spec parsing,
-  task graph generation from requirements, dependency tracking,
-  interactive spec building, persistence, visualization, critical
-  path analysis, spec versioning, and auto-execution.
-version: 2.0.0
----
-
-# Spec-Driven Development
-
-Guide the agent through specification-first development workflow.
-
-## Core Principle
-
-Every non-trivial change starts with a spec. The spec is the source of truth. Tasks are derived from specs, not the other way around.
-
-## Workflow
-
-```
-Spec → Analysis → Task Graph → Visualization → Execution → Done
-  ↑                    ↓
-  └── Versioning ──────┘ (incremental updates)
-```
-
-### When to use
-
-- New feature implementation
-- Bug fix with complexity
-- Refactoring with scope
-- Any task requiring more than 1 hour
-
-## Slash Command: /sdd
-
-The `/sdd` command provides the full SDD workflow through the REPL/TUI:
-
-```
-/sdd new [title]         — Interactive spec builder (question-driven)
-/sdd from <template>     — Create from template (feature|bugfix|refactor|infra|integration|cli-command)
-/sdd list                — List saved specs
-/sdd show <id>           — Show spec details + completeness analysis
-/sdd analyze <id>        — Deep spec analysis (gaps, risks, suggestions)
-/sdd tasks <id>          — Generate task graph from spec
-/sdd graph <id>          — ASCII visualization of task graph
-/sdd status <id>         — Compact task list grouped by status
-/sdd critical <id>       — Critical path analysis with bottlenecks
-/sdd execute <id>        — Auto-execute tasks (dependency-aware)
-/sdd templates           — List available spec templates
-/sdd version <id>        — Show spec version history
-```
-
-### Full workflow example
-
-```
-1. /sdd new Auth System
-2. Answer questions (title, overview, requirements, acceptance criteria)
-3. /sdd tasks <id>           → generates task graph
-4. /sdd graph <id>           → visualize dependencies
-5. /sdd critical <id>        → find bottlenecks
-6. /sdd execute <id>         → run tasks autonomously
-```
-
-## Spec Templates
-
-Built-in templates for common scenarios:
-
-| Template | Best for |
-|---|---|
-| `feature` | New feature development |
-| `bugfix` | Bug fix with root cause analysis |
-| `refactor` | Code refactoring with goals |
-| `infra` | Infrastructure/tooling changes |
-| `integration` | External service integration |
-| `cli-command` | New CLI commands/slash commands |
-
-## Spec sections
-
-A good spec includes:
-
-1. **Overview** — What problem does this solve?
-2. **Requirements** — Functional and non-functional requirements with priorities
-3. **Architecture** — High-level design if needed
-4. **API Design** — If applicable
-5. **Data Model** — If applicable
-6. **Security** — Auth, permissions, data handling
-7. **Acceptance Criteria** — How do we know it's done?
-
-### Requirement format
-
-```
-[functional] User can authenticate with OAuth2
-[security] Rate limiting: 100 req/min per user
-[performance] Response time < 200ms p95
-```
-
-Priority markers: `[critical]`, `[high]`, `[medium]`, `[low]`
-
-## Persistence
-
-Specs and task graphs are persisted under `.wrongstack/`:
-
-```
-.wrongstack/
-  specs/
-    _index.json           — Spec index for fast listing
-    <uuid>.json           — Individual spec files
-  task-graphs/
-    _index.json           — Task graph index
-    <uuid>.json           — Individual graph files (Map-aware JSON)
-```
-
-## Task generation
-
-Tasks are derived from requirements:
-
-- Each requirement → one or more tasks
-- Requirements with acceptance criteria → separate test tasks
-- Critical requirements → tasks marked critical
-- Blocked requirements → blocked tasks
-
-## Task states
-
-```
-pending → in_progress → review → completed
-              ↓
-           blocked (waiting on dependencies)
-              ↓
-           failed
-```
-
-## Critical Path Analysis
-
-The critical path identifies:
-
-- **Bottleneck tasks** that block the most downstream work
-- **Parallel groups** of tasks that can execute concurrently
-- **Ready tasks** that can start immediately
-- **Execution order** respecting all dependencies
-
-## Spec Versioning
-
-When requirements change:
-
-- Added requirements → new tasks generated
-- Removed requirements → tasks removed
-- Modified requirements → tasks updated (description, priority, dependencies)
-- Version history tracked for audit trail
-
-## Auto-Execution
-
-The auto-executor runs tasks with:
-
-- Dependency-aware ordering (blocked tasks wait)
-- Automatic retry on transient failures (configurable max retries)
-- Deadlock detection (all remaining blocked by failed tasks)
-- Progress tracking and event emission
-
-## Done conditions
-
-A feature is done when:
-1. All critical and high priority tasks completed
-2. Tests written and passing
-3. Documentation updated
-4. No blocked tasks remaining
+---
+name: sdd
+description: |
+  Use this skill when starting a non-trivial implementation, bug fix, or refactor
+  in WrongStack. Triggers: user says "/sdd", "spec", "specification", "task graph",
+  "SDD", "acceptance criteria", or starts a new feature.
+version: 2.1.0
+---
+
+# Spec-Driven Development — WrongStack
+
+Every non-trivial change starts with a spec. The spec is the source of truth.
+
+## When to use
+
+- New feature implementation
+- Bug fix with complexity
+- Refactoring with scope
+- Any task requiring more than 1 hour
+
+## The SDD workflow
+
+```
+1. /sdd new [title]          → Build spec from questions
+2. /sdd tasks <id>           → Generate task graph from spec
+3. /sdd graph <id>           → Visualize dependencies
+4. /sdd critical <id>        → Find bottlenecks
+5. /sdd execute <id>         → Run tasks (or execute manually)
+```
+
+## Task lifecycle commands
+
+| Command | What it does |
+|---------|--------------|
+| `/sdd tasks` | Show task list with progress bar (sorted: in_progress → pending → review → blocked → failed → completed) |
+| `/sdd next` | Show next executable task + blockers |
+| `/sdd done <N>` | Complete a task (by number or fuzzy title match) |
+| `/sdd skip <N>` | Skip a task back to pending |
+| `/sdd fail <N>` | Mark a task as failed |
+| `/sdd review <N>` | Send a task to review |
+| `/sdd edit <N> <text>` | Edit task title (short text) or description (long text) |
+| `/sdd undo` | Undo last task completion |
+| `/sdd graph` | ASCII task dependency visualization |
+| `/sdd critical` | Critical path analysis + bottlenecks |
+
+## Spec templates
+
+| Template | Best for |
+|---|---|
+| `feature` | New feature development |
+| `bugfix` | Bug fix with root cause analysis |
+| `refactor` | Code refactoring with goals |
+| `infra` | Infrastructure/tooling changes |
+| `integration` | External service integration |
+| `cli-command` | New CLI commands/slash commands |
+
+## Spec structure
+
+A complete spec has:
+1. **Overview** — What problem does this solve?
+2. **Requirements** — `[priority] description` format
+3. **Architecture** — High-level design (if needed)
+4. **API Design** — Endpoints, inputs, outputs (if applicable)
+5. **Acceptance Criteria** — How do we know it's done?
+
+### Requirement format
+
+```
+[critical] Users can authenticate with OAuth2
+[high] Rate limiting: 100 req/min per user  
+[medium] Response time < 200ms p95
+[low] Support dark mode
+```
+
+## Task graph generation
+
+Each requirement generates one or more tasks. Tasks have states:
+```
+pending → in_progress → review → completed
+              ↓
+           blocked (waiting on dependencies)
+              ↓
+           failed
+```
+
+## Critical path
+
+The critical path finds:
+- **Bottleneck tasks** blocking the most downstream work
+- **Parallel groups** that can run concurrently
+- **Ready tasks** that can start immediately
+- **Execution order** respecting all dependencies
+
+## Goal & Eternal Mode
+
+`/sdd` pairs with `/goal` for autonomous execution:
+
+| Command | What it does |
+|---------|--------------|
+| `/goal set <text>` | Set an autonomous mission |
+| `/goal pause` | Pause at end of current iteration |
+| `/goal resume` | Resume a paused goal |
+| `/goal journal [N]` | Show recent journal entries |
+| `/goal clear` | Clear goal and stop eternal mode |
+| `/autonomy eternal` | Run goal loop indefinitely |
+| `/autonomy stop` | Stop eternal mode |
+
+**Eternal stage flow:** `decide → execute → reflect → sleep | paused | stopped`
+Stage shown in real-time. Pause stops after current iteration completes.
+
+## Anti-patterns
+
+- **Writing code before the spec** — you'll rewrite it anyway
+- **Spec that's too vague** — "improve auth" is not a spec, "Users authenticate via OAuth2 with PKCE" is
+- **Tasks with no dependencies** — everything is a dependency of something
+- **Spec without acceptance criteria** — how do you know when it's done?
+- **Skipping /sdd for urgent tasks** — the spec is what makes "urgent" possible
+
+## Skills in scope
+
+- `refactor-planner` — when the spec reveals a multi-file refactor
+- `bug-hunter` — when a bugfix spec needs a root cause analysis section
+- `multi-agent` — for executing parallel task groups

package/skills/security-scanner/SKILL.md

@@ -1,117 +1,119 @@
 ---
 name: security-scanner
 description: |
-  Security vulnerability scanning for code and configuration. Covers secret detection,
-  injection vectors, dependency vulnerabilities, and supply chain risks.
-  Use during CI, before releases, or as a standalone audit.
-version: 1.0.0
+  Use this skill when scanning code or configuration for security vulnerabilities
+  in WrongStack. Triggers: user says "security", "vulnerability", "CVE", "secret",
+  "injection", "XSS", "SQL injection", "audit security", "supply chain".
+version: 1.1.0
 ---
 
-# Security Scanner Agent
+# Security Scanner — WrongStack
 
-Scans code, configs, and dependencies for security issues ranging from
-hardcoded secrets to injection vulnerabilities and supply chain risks.
-
-## Capabilities
-
-- Detect hardcoded secrets: API keys, tokens, passwords, private keys
-- Find injection vectors: eval, innerHTML, SQL concatenation, shell injection
-- Identify insecure patterns: weak crypto, hardcoded IVs, disabled TLS verification
-- Scan dependencies for known CVEs (via package audit)
-- Flag supply chain risks: unverified scripts, postinstall hooks, .npmrc issues
+Scans code, configs, and dependencies for security issues.
 
 ## Workflow
 
-1. **Scope** — Accept paths or use sensible defaults
-2. **Secrets Scan** — Regex scan for credential patterns
-3. **Injection Scan** — Pattern match dangerous constructs
-4. **Config Scan** — Check TLS, crypto, auth configurations
-5. **Dependency Scan** — Run audit on package.json
-6. **Report** — Prioritized markdown with remediation
-
-## Input
-
-```json
-{
-  "task": "scan | audit | secrets | dependencies",
-  "paths": ["src", "config"],
-  "depth": "quick | normal | deep",
-  "excludePaths": ["node_modules", "dist"]
-}
+```
+1. Scope:  Accept paths or use sensible defaults
+2. Secrets:  Regex scan for credential patterns
+3. Injection:  Pattern match dangerous constructs
+4. Config:  Check TLS, crypto, auth configurations
+5. Audit:  Run package audit
+6. Report:  Prioritized markdown with remediation
 ```
 
-## Output Format
+## Severity levels
 
-```
-## Security Scan Report — <timestamp>
-
-### CRITICAL: Secrets Found
-1. **[CRITICAL]** `config/keys.ts:8` — AWS Access Key ID exposed
-   ```
-   const awsKey = "AKIAIOSFODNN7EXAMPLE"; // ← remove this
-   ```
-2. **[CRITICAL]** `.env:3` — Private key committed to repo
-   ```
-   PEM_PRIVATE_KEY="-----BEGIN RSA PRIVATE KEY-----\nMIIE..."
-   ```
-
-### HIGH: Injection Vectors
-3. **[HIGH]** `lib/renderer.ts:42` — innerHTML assignment
-   ```ts
-   element.innerHTML = userInput; // ← sanitize or use textContent
-   ```
-4. **[HIGH]** `tools/shell.ts:15` — shell injection via template literal
-   ```ts
-   exec(`echo ${userInput}`); // ← escape or use array form
-   ```
-
-### MEDIUM: Insecure Patterns
-5. **[MEDIUM]** `lib/crypto.ts:9` — MD5 used for hashing (not for passwords)
-6. **[MEDIUM]** `server.ts:22` — TLS certificate verification disabled
-
-### Dependency Issues
-7. **[HIGH]** `lodash < 4.17.21` — CVE-2021-23337
-8. **[MEDIUM]** `minimist < 1.2.6` — CVE-2021-44906
-
-## Summary
-| Severity | Count |
-|----------|-------|
-| Critical | 2     |
-| High     | 4     |
-| Medium   | 3     |
-| Low      | 1     |
+| Level | Meaning | Action |
+|-------|---------|--------|
+| **CRITICAL** | Active exploit possible | Fix immediately |
+| **HIGH** | Vulnerability likely exploitable | Fix before release |
+| **MEDIUM** | Risk exists but harder to exploit | Fix soon |
+| **LOW** | Best practice violation | Consider fixing |
 
-## Remediation Checklist
-- [ ] Remove hardcoded secrets from `config/keys.ts`
-- [ ] Sanitize user input before innerHTML assignment
-- [ ] Update lodash to >= 4.17.21
-- [ ] Enable TLS verification in production
+## Secret patterns
+
+```
+| Pattern | Example | Level |
+|---------|---------|-------|
+| GitHub token | `ghp_[a-zA-Z0-9]{36}` | CRITICAL |
+| AWS Access Key | `[A-Z0-9]{20}` | CRITICAL |
+| AWS Secret | base64 40-char | CRITICAL |
+| Private Key PEM | `-----BEGIN.*PRIVATE KEY-----` | CRITICAL |
+| JWT | `eyJ[a-zA-Z0-9_-]+` | HIGH |
+| Generic API Key | 32+ random chars | MEDIUM |
+| Bearer token | `Authorization: Bearer xxx` | HIGH |
 ```
 
-## Secret Pattern Reference
+## Real examples
+
+```typescript
+// ❌ CRITICAL — hardcoded AWS credentials
+const awsKey = "AKIAIOSFODNN7EXAMPLE";
+
+// ❌ CRITICAL — private key committed
+const pem = "-----BEGIN RSA PRIVATE KEY-----\nMIIE...";
+
+// ❌ HIGH — JWT in code
+const token = "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...";
+
+// ❌ HIGH — XSS via innerHTML
+element.innerHTML = userInput;
+
+// ❌ HIGH — shell injection
+exec(`find . -name ${userInput}`);
+
+// ❌ HIGH — SQL injection
+const query = "SELECT * FROM users WHERE id = " + userId;
 
-| Pattern | Example | Severity |
-|---------|---------|----------|
-| AWS Access Key | `AKIAIOSFODNN7EXAMPLE` | critical |
-| AWS Secret Key | `[a-zA-Z0-9/+=]{40}` base64 | critical |
-| GitHub Token | `ghp_[a-zA-Z0-9]{36}` | critical |
-| Private Key PEM | `-----BEGIN.*PRIVATE KEY-----` | critical |
-| JWT | `eyJ[a-zA-Z0-9_-]+` | high |
-| Generic API Key | `[a-zA-Z0-9]{32,}` | medium |
+// ✅ SAFE — parameterized query
+db.query("SELECT * FROM users WHERE id = $1", [userId]);
 
-## Injection Patterns
+// ✅ SAFE — escape user input
+element.textContent = userInput;
+```
+
+## Injection vectors
 
-| Construct | Safe Alternative |
-|-----------|-----------------|
-| `eval(str)` | `new Function()` or parse |
-| `innerHTML = x` | `textContent` or sanitize |
+| Construct | Safe alternative |
+|-----------|-------------------|
+| `eval(str)` | `new Function()` or parse then evaluate |
+| `innerHTML = x` | `textContent` or DOMPurify.sanitize |
 | `exec(\`cmd ${input}\`)` | `execFile` with args array |
 | `SQL = "SELECT * FROM " + table` | parameterized query |
 | `fs.readFile(path + userInput)` | `path.resolve` + allowlist |
 
+## Configuration checks
+
+```
+- TLS verification disabled? → CRITICAL for production
+- HTTP instead of HTTPS? → MEDIUM for production
+- Secrets in env vars logged to console? → CRITICAL
+- Hardcoded credentials in config? → CRITICAL
+- Overly permissive CORS? → MEDIUM
+- Missing rate limiting? → MEDIUM-HIGH
+```
+
 ## Anti-patterns
 
-- Don't scan node_modules — noise, use `npm audit` instead
-- Don't report without remediation — "found X" is useless without "do Y"
-- Don't ignore false positives — verify before flagging (especially regex-based secrets)
-- Don't skip dependency scanning — supply chain is a real attack vector
+- **Don't scan `node_modules`** — use `npm audit` instead
+- **Don't report without remediation** — "found X" is useless without "do Y"
+- **Don't ignore false positives** — verify regex matches before flagging (especially generic patterns)
+- **Don't skip dependency scanning** — supply chain is a real attack vector
+- **Don't flag test fixtures** — mock credentials in tests are ok, but not in production code
+
+## Remediation template
+
+```
+## Remediation Checklist
+- [ ] Remove hardcoded credentials from `src/config.ts`
+- [ ] Move secrets to environment variables, add to .gitignore
+- [ ] Use parameterized queries in `src/db/` files
+- [ ] Add rate limiting to `src/api/` routes
+```
+
+## Skills in scope
+
+- `bug-hunter` — for general code quality bugs found during security scan
+- `audit-log` — for dependency version audit trails
+- `git-flow` — for committing security patches properly

package/skills/skill-creator/SKILL.md

@@ -1,17 +1,16 @@
 ---
 name: skill-creator
 description: |
-  Use this skill when the user wants to create a new AI skill.
-  Covers skill format, file structure, naming conventions,
-  and the interactive creation workflow.
-version: 1.0.0
+  Use this skill when the user wants to create a new AI skill in WrongStack.
+  Triggers: user says "create a skill", "new skill", "add a skill", "skill definition".
+version: 1.1.0
 ---
 
-# Skill Creator
+# Skill Creator — WrongStack
 
-Guide the user through creating a new AI skill. You are the wizard — ask questions, validate answers, write the file.
+Guide the user through creating a new skill. You are the wizard — ask questions, validate answers, write the file.
 
-## Skill Format
+## Skill format
 
 Every skill is a Markdown file with YAML frontmatter:
 
@@ -19,8 +18,8 @@ Every skill is a Markdown file with YAML frontmatter:
 ---
 name: my-skill-name
 description: |
-  First sentence is the trigger — when should this skill activate?
-  Rest describes what the skill covers.
+  Use this skill when <trigger situation>.
+  Triggers: user says "keyword", "another keyword".
 version: 1.0.0
 ---
 
@@ -35,10 +34,14 @@ What this skill does.
 
 ## Patterns
 ### Do
-```code example```
+\`\`\`ts
+// good example
+\`\`\`
 
 ### Don't
-```anti-pattern example```
+\`\`\`ts
+// bad example
+\`\`\`
 
 ## Workflow
 1. Step one
@@ -51,23 +54,42 @@ Skills live in directories under these paths (priority order):
 
 1. **Project**: `<project>/.wrongstack/skills/<name>/SKILL.md`
 2. **User global**: `~/.wrongstack/skills/<name>/SKILL.md`
-3. **Bundled**: `packages/core/skills/<name>/SKILL.md` (read-only)
+3. **Bundled**: `packages/core/skills/<name>/SKILL.md` (read-only, for core team)
 
-For user-created skills, always use path 1 (project level).
+For user-created skills: always use path 1 (project level).
 
 ## Naming Rules
 
-- kebab-case: `my-skill`, `docker-deploy`, `api-testing`
+- **kebab-case**: `my-skill`, `docker-deploy`, `api-testing`
 - Lowercase letters, numbers, hyphens only
 - No spaces, no underscores, no uppercase
 - Directory name = skill name
 
-## Description Rules
+## The Trigger — the most important part
+
+The **first sentence** of the `description` is the trigger. This is the **only** thing the skill loader matches on.
+
+```
+# ✅ Good — specific trigger that can be matched
+Use this skill when deploying Docker containers to a production cluster.
+
+# ❌ Bad — vague, can't be matched
+This skill is about Docker deployment.
+
+# ✅ Good — pattern-matchable
+Use this skill when writing or reviewing React 19+ code.
+
+# ❌ Bad — too broad
+This skill is about code.
+```
+
+After the trigger sentence, add `Triggers: user says "X", "Y", "Z".` so agents know when to delegate.
 
-- First sentence = trigger condition. This is when the skill activates.
-  - Good: "Use this skill when deploying Docker containers."
-  - Bad: "This skill is about Docker."
-- Be specific about scope — what technologies, what situations
+## Description rules
+
+- First sentence = trigger condition
+- Second sentence = what it covers
+- Triggers list = specific keywords or phrases
 - Multi-line descriptions use YAML block scalar (`|`)
 
 ## Content Guidelines
@@ -76,16 +98,14 @@ For user-created skills, always use path 1 (project level).
 - **Patterns**: actual code examples, not pseudocode
 - **Anti-patterns**: show what NOT to do with real code
 - **Workflows**: step-by-step, actionable, not theoretical
-- Keep it focused — one skill = one concern
+- **Skills in scope**: list related skills at the bottom for delegation
 
 ## Creation Workflow
 
-When the user wants to create a skill:
-
 1. **Ask the name** — suggest kebab-case, validate format
-2. **Ask the description** — guide them to write a good trigger sentence
-3. **Ask what to cover** — rules, patterns, workflows they want in the body
-4. **Generate the SKILL.md** — write the file to `.wrongstack/skills/<name>/SKILL.md`
+2. **Ask the trigger** — "What situation should activate this skill?"
+3. **Ask the coverage** — what rules, patterns, workflows?
+4. **Generate the SKILL.md** — write to `.wrongstack/skills/<name>/SKILL.md`
 5. **Confirm** — show the path, remind them to use `/skill` to list skills
 
 ## Validation Checklist
@@ -96,3 +116,16 @@ Before writing the file, verify:
 - [ ] Description has a clear trigger sentence
 - [ ] Content is actionable (rules, patterns, not just prose)
 - [ ] File will be placed in `.wrongstack/skills/`
+
+## Existing skills (don't collide)
+
+```
+audit-log, bug-hunter, git-flow, multi-agent, node-modern,
+prompt-engineering, react-modern, refactor-planner, sdd,
+security-scanner, skill-creator, typescript-strict
+```
+
+## Skills in scope
+
+- `prompt-engineering` — for crafting the skill description and prompt text
+- `git-flow` — for committing the new skill file