@leanspec/cli 0.3.0

package/binaries/darwin-arm64/package.json

@@ -0,0 +1,24 @@
+{
+  "name": "@leanspec/cli-darwin-arm64",
+  "version": "0.3.0",
+  "description": "LeanSpec CLI binary for macOS ARM64",
+  "os": [
+    "darwin"
+  ],
+  "cpu": [
+    "arm64"
+  ],
+  "main": "leanspec",
+  "files": [
+    "leanspec",
+    "postinstall.js"
+  ],
+  "scripts": {
+    "postinstall": "node postinstall.js"
+  },
+  "repository": {
+    "type": "git",
+    "url": "https://github.com/codervisor/leanspec.git"
+  },
+  "license": "MIT"
+}

package/binaries/darwin-arm64/postinstall.js

@@ -0,0 +1,17 @@
+#!/usr/bin/env node
+/**
+ * Postinstall script to set execute permissions on the binary.
+ * npm doesn't preserve file permissions, so we need to set them after install.
+ */
+const { chmodSync } = require('fs');
+const { join } = require('path');
+
+const binaryPath = join(__dirname, 'leanspec');
+
+try {
+  chmodSync(binaryPath, 0o755);
+  console.log('✓ Set execute permissions on leanspec binary');
+} catch (err) {
+  console.error('Warning: Could not set execute permissions:', err.message);
+  // Don't fail the install
+}

package/binaries/darwin-x64/package.json

@@ -0,0 +1,24 @@
+{
+  "name": "@leanspec/cli-darwin-x64",
+  "version": "0.3.0",
+  "description": "LeanSpec CLI binary for macOS x64",
+  "os": [
+    "darwin"
+  ],
+  "cpu": [
+    "x64"
+  ],
+  "main": "leanspec",
+  "files": [
+    "leanspec",
+    "postinstall.js"
+  ],
+  "scripts": {
+    "postinstall": "node postinstall.js"
+  },
+  "repository": {
+    "type": "git",
+    "url": "https://github.com/codervisor/leanspec.git"
+  },
+  "license": "MIT"
+}

package/binaries/darwin-x64/postinstall.js

@@ -0,0 +1,17 @@
+#!/usr/bin/env node
+/**
+ * Postinstall script to set execute permissions on the binary.
+ * npm doesn't preserve file permissions, so we need to set them after install.
+ */
+const { chmodSync } = require('fs');
+const { join } = require('path');
+
+const binaryPath = join(__dirname, 'leanspec');
+
+try {
+  chmodSync(binaryPath, 0o755);
+  console.log('✓ Set execute permissions on leanspec binary');
+} catch (err) {
+  console.error('Warning: Could not set execute permissions:', err.message);
+  // Don't fail the install
+}

package/binaries/linux-x64/package.json

@@ -0,0 +1,24 @@
+{
+  "name": "@leanspec/cli-linux-x64",
+  "version": "0.3.0",
+  "description": "LeanSpec CLI binary for Linux x64",
+  "os": [
+    "linux"
+  ],
+  "cpu": [
+    "x64"
+  ],
+  "main": "leanspec",
+  "files": [
+    "leanspec",
+    "postinstall.js"
+  ],
+  "scripts": {
+    "postinstall": "node postinstall.js"
+  },
+  "repository": {
+    "type": "git",
+    "url": "https://github.com/codervisor/leanspec.git"
+  },
+  "license": "MIT"
+}

package/binaries/linux-x64/postinstall.js

@@ -0,0 +1,17 @@
+#!/usr/bin/env node
+/**
+ * Postinstall script to set execute permissions on the binary.
+ * npm doesn't preserve file permissions, so we need to set them after install.
+ */
+const { chmodSync } = require('fs');
+const { join } = require('path');
+
+const binaryPath = join(__dirname, 'leanspec');
+
+try {
+  chmodSync(binaryPath, 0o755);
+  console.log('✓ Set execute permissions on leanspec binary');
+} catch (err) {
+  console.error('Warning: Could not set execute permissions:', err.message);
+  // Don't fail the install
+}

package/binaries/windows-x64/package.json

@@ -0,0 +1,24 @@
+{
+  "name": "@leanspec/cli-windows-x64",
+  "version": "0.3.0",
+  "description": "LeanSpec CLI binary for Windows x64",
+  "os": [
+    "win32"
+  ],
+  "cpu": [
+    "x64"
+  ],
+  "main": "leanspec.exe",
+  "files": [
+    "leanspec.exe",
+    "postinstall.js"
+  ],
+  "scripts": {
+    "postinstall": "node postinstall.js"
+  },
+  "repository": {
+    "type": "git",
+    "url": "https://github.com/codervisor/leanspec.git"
+  },
+  "license": "MIT"
+}

package/binaries/windows-x64/postinstall.js

@@ -0,0 +1,6 @@
+#!/usr/bin/env node
+/**
+ * Postinstall script - no-op on Windows (permissions not needed).
+ * This file exists for consistency across all platform packages.
+ */
+console.log('✓ leanspec.exe ready');

package/package.json

@@ -0,0 +1,48 @@
+{
+  "name": "@leanspec/cli",
+  "version": "0.3.0",
+  "description": "Specification-driven development made simple",
+  "type": "module",
+  "bin": {
+    "leanspec": "./bin/leanspec.js",
+    "lean-spec": "./bin/lean-spec.js"
+  },
+  "scripts": {
+    "typecheck": "echo 'No TypeScript source to check'"
+  },
+  "keywords": [
+    "spec",
+    "specification",
+    "documentation",
+    "ai",
+    "agent",
+    "sdd"
+  ],
+  "author": "Marvin Zhang",
+  "license": "MIT",
+  "repository": {
+    "type": "git",
+    "url": "https://github.com/codervisor/leanspec.git"
+  },
+  "homepage": "https://lean-spec.dev",
+  "bugs": {
+    "url": "https://github.com/codervisor/leanspec/issues"
+  },
+  "files": [
+    "bin/",
+    "binaries/",
+    "templates/",
+    "README.md",
+    "LICENSE",
+    "CHANGELOG.md"
+  ],
+  "engines": {
+    "node": ">=20"
+  },
+  "optionalDependencies": {
+    "@leanspec/cli-darwin-x64": "0.3.0",
+    "@leanspec/cli-darwin-arm64": "0.3.0",
+    "@leanspec/cli-linux-x64": "0.3.0",
+    "@leanspec/cli-windows-x64": "0.3.0"
+  }
+}

package/templates/detailed/AGENTS-minimal.md

@@ -0,0 +1,9 @@
+# {project_name}
+
+## Project-Specific Rules
+
+Add your project-specific conventions here. For example:
+- Code style preferences
+- Naming conventions  
+- Team workflows
+- Custom tooling

package/templates/detailed/AGENTS.md

@@ -0,0 +1,114 @@
+# AI Agent Instructions
+
+## Project: {project_name}
+
+## 🚨 CRITICAL: Before ANY Task
+
+**STOP and check these first:**
+
+1. **Discover context** → Use `board` tool to see project state
+2. **Search for related work** → Use `search` tool before creating new specs
+3. **Never create files manually** → Always use `create` tool for new specs
+
+> **Why?** Skipping discovery creates duplicate work. Manual file creation breaks LeanSpec tooling.
+
+## 🔧 Managing Specs
+
+### MCP Tools (Preferred) with CLI Fallback
+
+| Action | MCP Tool | CLI Fallback |
+|--------|----------|--------------|
+| Project status | `board` | `leanspec board` |
+| List specs | `list` | `leanspec list` |
+| Search specs | `search` | `leanspec search "query"` |
+| View spec | `view` | `leanspec view <spec>` |
+| Create spec | `create` | `leanspec create <name>` |
+| Update spec | `update` | `leanspec update <spec> --status <status>` |
+| Link specs | `link` | `leanspec link <spec> --depends-on <other>` |
+| Unlink specs | `unlink` | `leanspec unlink <spec> --depends-on <other>` |
+| Dependencies | `deps` | `leanspec deps <spec>` |
+| Token count | `tokens` | `leanspec tokens <spec>` |
+| Validate specs | `validate` | `leanspec validate` |
+
+## ⚠️ Core Rules
+
+| Rule | Details |
+|------|---------|
+| **NEVER edit frontmatter manually** | Use `update`, `link`, `unlink` for: `status`, `priority`, `tags`, `assignee`, `transitions`, timestamps, `depends_on` |
+| **ALWAYS link spec references** | Content mentions another spec → `leanspec link <spec> --depends-on <other>` |
+| **Track status transitions** | `planned` → `in-progress` (before coding) → `complete` (after done) |
+| **Keep specs current** | Document progress, decisions, and learnings as work happens. Obsolete specs mislead both humans and AI |
+| **No nested code blocks** | Use indentation instead |
+
+### 🚫 Common Mistakes
+
+| ❌ Don't | ✅ Do Instead |
+|----------|---------------|
+| Create spec files manually | Use `create` tool |
+| Skip discovery | Run `board` and `search` first |
+| Leave status as "planned" | Update to `in-progress` before coding |
+| Edit frontmatter manually | Use `update` tool |
+| Complete spec without documentation | Document progress, prompts, learnings first |
+
+## 📋 SDD Workflow
+
+```
+BEFORE: board → search → check existing specs
+DURING: update status to in-progress → code → document decisions → link dependencies
+AFTER:  document completion → update status to complete
+```
+
+**Status tracks implementation, NOT spec writing.**
+
+## Spec Dependencies
+
+Use `depends_on` to express blocking relationships between specs:
+- **`depends_on`** = True blocker, work order matters, directional (A depends on B)
+
+Link dependencies when one spec builds on another:
+```bash
+leanspec link <spec> --depends-on <other-spec>
+```
+
+## When to Use Specs
+
+| ✅ Write spec | ❌ Skip spec |
+|---------------|--------------|
+| Multi-part features | Bug fixes |
+| Breaking changes | Trivial changes |
+| Design decisions | Self-explanatory refactors |
+
+## Token Thresholds
+
+| Tokens | Status |
+|--------|--------|
+| <2,000 | ✅ Optimal |
+| 2,000-3,500 | ✅ Good |
+| 3,500-5,000 | ⚠️ Consider splitting |
+| >5,000 | 🔴 Must split |
+
+## Quality Validation
+
+Before completing work, validate spec quality:
+```bash
+leanspec validate              # Check structure and quality
+leanspec validate --check-deps # Verify dependency alignment
+```
+
+Validation checks:
+- Missing required sections
+- Excessive length (>400 lines)
+- Content/frontmatter dependency misalignment
+- Invalid frontmatter fields
+
+## First Principles (Priority Order)
+
+1. **Context Economy** - <2,000 tokens optimal, >3,500 needs splitting
+2. **Signal-to-Noise** - Every word must inform a decision
+3. **Intent Over Implementation** - Capture why, let how emerge
+4. **Bridge the Gap** - Both human and AI must understand
+5. **Progressive Disclosure** - Add complexity only when pain is felt
+
+---
+
+**Remember:** LeanSpec tracks what you're building. Keep specs in sync with your work!

package/templates/detailed/README.md

@@ -0,0 +1,28 @@
+# Detailed Template
+
+For complex specs that benefit from structured sub-specs. Demonstrates how to manage token limits.
+
+## What's Included
+
+- **AGENTS.md** - Same AI agent instructions as standard template
+- **Sub-spec structure** - README.md + DESIGN.md + PLAN.md + TEST.md
+- Demonstrates splitting specs to stay under token limits
+- Example of real-world sub-spec organization
+
+## When to Use
+
+- Complex features with lots of detail
+- Specs approaching 3,500+ tokens
+- Need clear separation of concerns (design, plan, test)
+- Large teams with multiple reviewers
+
+## Philosophy
+
+Keep it lean, but organized. Use sub-specs to manage complexity without overwhelming context. Each file stays focused and under token limits.
+
+## Next Steps
+
+You're ready to go! Ask your AI to create a spec for your next feature.
+
+When a spec grows large, consider splitting sections into sub-spec files.
+

package/templates/detailed/config.json

@@ -0,0 +1,20 @@
+{
+  "name": "Enterprise",
+  "description": "Governance-ready with approvals, compliance, and security",
+  "config": {
+    "template": "enterprise",
+    "specsDir": "specs",
+    "structure": {
+      "pattern": "flat",
+      "prefix": "",
+      "dateFormat": "YYYYMMDD",
+      "sequenceDigits": 3,
+      "defaultFile": "README.md"
+    },
+    "features": {
+      "aiAgents": true,
+      "compliance": true,
+      "approvals": true
+    }
+  }
+}

package/templates/detailed/files/DESIGN.md

@@ -0,0 +1,43 @@
+# Design: {name}
+
+> Part of [{name}](README.md)
+
+## Architecture
+
+<!-- High-level system design, components, interactions -->
+
+## Technical Approach
+
+<!-- Specific technologies, patterns, frameworks -->
+
+## Design Decisions
+
+<!-- Key decisions and rationale -->
+
+### Decision 1
+
+**Context**: <!-- What problem does this solve? -->
+
+**Decision**: <!-- What did we choose? -->
+
+**Rationale**: <!-- Why this approach? -->
+
+**Trade-offs**: <!-- What are we giving up? -->
+
+## Dependencies
+
+<!-- What does this depend on? What depends on this? -->
+
+### System Dependencies
+- 
+
+### Team Dependencies
+- 
+
+## Security & Compliance
+
+<!-- Security implications, compliance requirements -->
+
+- [ ] Handles sensitive data (PII, credentials, etc.)
+- [ ] Security review completed
+- [ ] Compliance requirements addressed

package/templates/detailed/files/PLAN.md

@@ -0,0 +1,59 @@
+# Plan: {name}
+
+> Part of [{name}](README.md)
+
+## Implementation Phases
+
+### Phase 1: [Name]
+
+**Goal**: <!-- What does this phase achieve? -->
+
+**Tasks**:
+- [ ] Task 1
+- [ ] Task 2
+- [ ] Task 3
+
+**Dependencies**: <!-- What must be done before this? -->
+
+**Success criteria**: <!-- How do we know this is done? -->
+
+### Phase 2: [Name]
+
+**Goal**: <!-- What does this phase achieve? -->
+
+**Tasks**:
+- [ ] Task 1
+- [ ] Task 2
+- [ ] Task 3
+
+**Dependencies**: <!-- What must be done before this? -->
+
+**Success criteria**: <!-- How do we know this is done? -->
+
+## Rollout Strategy
+
+<!-- How will this be deployed to production? -->
+
+**Staging**:
+- 
+
+**Production**:
+- 
+
+**Monitoring**:
+- 
+
+**Rollback plan**:
+- 
+
+## Timeline
+
+| Phase | Duration | Dependencies |
+|-------|----------|--------------|
+|       |          |              |
+
+## Risks
+
+| Risk | Impact | Mitigation |
+|------|--------|------------|
+|      |        |            |

package/templates/detailed/files/README.md

@@ -0,0 +1,30 @@
+---
+status: planned
+created: '{date}'
+tags: []
+priority: medium
+---
+
+# {name}
+
+> **Status**: {status} · **Priority**: {priority} · **Created**: {date}
+
+## Overview
+
+<!-- What are we solving? Why now? Expected impact? -->
+
+## Sub-Specs
+
+For detailed information, see:
+
+- **[DESIGN.md](DESIGN.md)** - Technical architecture and design decisions
+- **[PLAN.md](PLAN.md)** - Implementation plan and phases
+- **[TEST.md](TEST.md)** - Testing strategy and verification
+
+## Quick Summary
+
+<!-- Brief summary of the spec (2-3 paragraphs max) -->
+
+## Notes
+
+<!-- Key decisions, constraints, open questions -->

package/templates/detailed/files/TEST.md

@@ -0,0 +1,71 @@
+# Test: {name}
+
+> Part of [{name}](README.md)
+
+## Testing Strategy
+
+<!-- Overall approach to verifying this works -->
+
+## Unit Tests
+
+<!-- Component-level testing -->
+
+**Scope**:
+- 
+
+**Key test cases**:
+- [ ] Test case 1
+- [ ] Test case 2
+- [ ] Test case 3
+
+## Integration Tests
+
+<!-- System interaction testing -->
+
+**Scope**:
+- 
+
+**Key test cases**:
+- [ ] Test case 1
+- [ ] Test case 2
+- [ ] Test case 3
+
+## Performance Tests
+
+<!-- Load, stress, and performance testing -->
+
+**Requirements**:
+- 
+
+**Test scenarios**:
+- [ ] Scenario 1
+- [ ] Scenario 2
+
+## Security Tests
+
+<!-- Security validation -->
+
+**Security checks**:
+- [ ] Authentication/authorization
+- [ ] Input validation
+- [ ] Data encryption
+- [ ] Audit logging
+
+## Acceptance Criteria
+
+<!-- What must be true for this to be considered complete? -->
+
+- [ ] Criterion 1
+- [ ] Criterion 2
+- [ ] Criterion 3
+
+## Test Data
+
+<!-- What test data is needed? -->
+
+## Manual Testing
+
+<!-- What requires human verification? -->
+
+- [ ] Manual test 1
+- [ ] Manual test 2