@wrongstack/core 0.4.1 → 0.5.2

package/skills/sdd/SKILL.md

@@ -2,9 +2,10 @@
 name: sdd
 description: |
   Specification-driven development workflow. Covers spec parsing,
-  task graph generation from requirements, dependency tracking, and
-  done-condition execution. Use when implementing features.
-version: 1.0.0
+  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
@@ -18,7 +19,9 @@ Every non-trivial change starts with a spec. The spec is the source of truth. Ta
 ## Workflow
 
 ```
-Spec → Analysis → Task Graph → Execution → Done
+Spec → Analysis → Task Graph → Visualization → Execution → Done
+  ↑                    ↓
+  └── Versioning ──────┘ (incremental updates)
 ```
 
 ### When to use
@@ -28,7 +31,50 @@ Spec → Analysis → Task Graph → Execution → Done
 - Refactoring with scope
 - Any task requiring more than 1 hour
 
-### Spec sections
+## 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:
 
@@ -50,6 +96,20 @@ A good spec includes:
 
 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:
@@ -69,10 +129,37 @@ pending → in_progress → review → completed
            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
+4. No blocked tasks remaining

package/skills/skill-creator/SKILL.md

@@ -0,0 +1,98 @@
+---
+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
+---
+
+# Skill Creator
+
+Guide the user through creating a new AI skill. You are the wizard — ask questions, validate answers, write the file.
+
+## Skill Format
+
+Every skill is a Markdown file with YAML frontmatter:
+
+```markdown
+---
+name: my-skill-name
+description: |
+  First sentence is the trigger — when should this skill activate?
+  Rest describes what the skill covers.
+version: 1.0.0
+---
+
+# Skill Title
+
+## Overview
+What this skill does.
+
+## Rules
+- Rule 1
+- Rule 2
+
+## Patterns
+### Do
+```code example```
+
+### Don't
+```anti-pattern example```
+
+## Workflow
+1. Step one
+2. Step two
+```
+
+## File Location
+
+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)
+
+For user-created skills, always use path 1 (project level).
+
+## Naming Rules
+
+- 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
+
+- 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
+- Multi-line descriptions use YAML block scalar (`|`)
+
+## Content Guidelines
+
+- **Rules**: concrete do/don't rules, not vague advice
+- **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
+
+## 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`
+5. **Confirm** — show the path, remind them to use `/skill` to list skills
+
+## Validation Checklist
+
+Before writing the file, verify:
+- [ ] Name is valid kebab-case
+- [ ] Name doesn't collide with existing skills
+- [ ] Description has a clear trigger sentence
+- [ ] Content is actionable (rules, patterns, not just prose)
+- [ ] File will be placed in `.wrongstack/skills/`