lean-spec 0.2.5-dev.20251124070920 → 0.2.5-dev.20251125010225

package/templates/enterprise/spec-template.md

@@ -1,80 +0,0 @@
----
-status: planned
-created: '{date}'
-tags: []
-priority: medium
-assignee: 
-reviewer: 
-related: []
-issue: 
-epic: 
----
-
-# {name}
-
-> **Status**: {status} · **Priority**: {priority} · **Created**: {date}  
-> **Assignee**: {assignee} · **Reviewer**: {reviewer}
-
-## Overview
-
-<!-- What business problem? Why now? Expected impact? -->
-
-## Research
-
-<!-- Background investigation, alternatives evaluated, key findings -->
-
-## Design
-
-<!-- Architecture, system interactions, data flows -->
-
-### Dependencies
-
-- **Teams**: <!-- Which teams need to coordinate? -->
-- **Systems**: <!-- External systems affected -->
-- **Data**: <!-- Databases, APIs, shared resources -->
-
-### Security & Compliance
-
-- [ ] Handles sensitive data (PII, credentials, etc.)
-- [ ] Security implications reviewed
-- [ ] Compliance requirements identified
-
-## Plan
-
-<!-- Break into phases if needed -->
-
-<!-- 💡 TIP: If your plan has >6 phases or this spec approaches 
-     400 lines, consider using sub-spec files:
-     - IMPLEMENTATION.md for detailed implementation
-     - See spec 012-sub-spec-files for guidance on splitting -->
-
-- [ ] Task 1 - @owner
-- [ ] Task 2 - @owner
-- [ ] Task 3 - @owner
-
-## Test
-
-<!-- How to verify correctness and safety -->
-
-- [ ] Unit/integration tests
-- [ ] Load/performance testing
-- [ ] Security testing
-- [ ] Rollback plan
-
-## Risks
-
-| Risk | Impact | Mitigation |
-|------|--------|------------|
-|      |        |            |
-
-## Rollout
-
-<!-- Deployment strategy for production systems -->
-
-- Staging validation: 
-- Production approach: 
-- Monitoring: 
-
-## Notes
-
-<!-- Key decisions, constraints, unresolved questions -->

package/templates/minimal/README.md

@@ -1,18 +0,0 @@
-# Minimal Template
-
-Bare essentials. Just the spec folder structure, nothing else.
-
-## What's Included
-
-- Spec folder structure (`specs/YYYYMMDD/NNN-name/`)
-- That's it
-
-## When to Use
-
-- You want maximum flexibility
-- Adding LeanSpec to existing project with established practices
-- Don't need AI agent instructions
-
-## Next Steps
-
-Create your first spec: `lean-spec create my-feature`

package/templates/minimal/agents-config.json

@@ -1,13 +0,0 @@
-{
-  "description": "Lightweight spec methodology for AI-powered development.",
-  "coreRules": ["core-rules-base-additions.md", "core-rules-shared.md"],
-  "whenToUse": "when-to-use-minimal.md",
-  "whenToUseEarly": true,
-  "discoveryCommands": ["discovery-commands-shared.md", "discovery-commands-minimal-additions.md"],
-  "essentialCommands": ["essential-commands-shared.md", "essential-commands-minimal-additions.md"],
-  "frontmatter": "frontmatter-minimal.md",
-  "workflow": ["workflow-standard.md", "status-update-triggers.md"],
-  "qualityStandards": ["quality-standards-minimal-additions.md", "quality-standards-shared.md"],
-  "closingNote": "**Remember**: LeanSpec is a mindset. Adapt these guidelines to what actually helps.",
-  "additionalSections": []
-}

package/templates/minimal/config.json

@@ -1,15 +0,0 @@
-{
-  "name": "Minimal",
-  "description": "Just the essentials - folder structure only",
-  "config": {
-    "template": "minimal",
-    "specsDir": "specs",
-    "structure": {
-      "pattern": "flat",
-      "prefix": "",
-      "dateFormat": "YYYYMMDD",
-      "sequenceDigits": 3,
-      "defaultFile": "README.md"
-    }
-  }
-}

package/templates/minimal/files/AGENTS.md

@@ -1,118 +0,0 @@
-# AI Agent Instructions
-
-## Project: {project_name}
-
-Lightweight spec methodology for AI-powered development.
-
-## Core Rules
-
-1. **Read README.md first** - Understand project context
-2. **Check specs/** - Review existing specs before starting
-3. **Follow LeanSpec principles** - Clarity over documentation
-4. **Keep it minimal** - If it doesn't add clarity, cut it
-5. **Never use nested code blocks** - Markdown doesn't support code blocks within code blocks. Use indentation or describe the structure instead
-
-## When to Use Specs
-
-- Features that affect multiple parts of the system
-- Breaking changes or significant refactors
-- Design decisions that need thinking through
-- Complex features that benefit from upfront planning
-
-Skip specs for:
-- Bug fixes
-- Trivial changes
-- Self-explanatory refactors
-
-## Discovery Commands
-
-Before starting work, understand project context:
-
-- `lean-spec stats` - See work distribution
-- `lean-spec board` - View specs by status
-- `lean-spec search "<query>"` - Find relevant work
-- `lean-spec list` - List all specs
-
-These help you understand what exists and what's in progress.
-
-
-## Essential Commands
-
-**Discovery:**
-- `lean-spec list` - See all specs
-- `lean-spec search "<query>"` - Find relevant specs
-
-**Viewing specs:**
-- `lean-spec view <spec>` - View a spec (formatted)
-- `lean-spec open <spec>` - Open spec in editor
-
-**Working with specs:**
-- `lean-spec create <name>` - Create a new spec
-- `lean-spec update <spec> --status <status>` - Update spec status
-
-**When in doubt:** Run `lean-spec --help` to see all available commands.
-
-
-## Spec Frontmatter
-
-When creating or updating specs, add YAML frontmatter at the top:
-
-```yaml
----
-status: draft|planned|in-progress|complete|blocked|cancelled
-created: YYYY-MM-DD
----
-```
-
-**Keep it simple:**
-- Just `status` and `created` fields
-- Other fields are optional - only add if helpful
-- Update `status` as work progresses
-
-**Update status with:**
-```bash
-lean-spec update <spec> --status in-progress
-```
-
-## Workflow
-
-1. **Check existing work** - Run `lean-spec board` or `lean-spec search`
-2. **Create or update spec** - Add frontmatter with `status` and `created` (status: `planned`)
-3. **Start implementation** - Mark `in-progress` BEFORE implementing what the spec describes
-4. **Implement changes** - Keep spec in sync as you learn
-5. **Complete implementation** - Mark `complete` AFTER implementing what the spec describes
-6. **Document** - Report progress and document changes into the spec
-
-**Remember**: Status tracks implementation work, not spec document creation. Creating a spec = planning (stays `planned` until implementation starts).
-
-**Note on Archiving**: Archive specs when they're no longer actively referenced (weeks/months after completion), not immediately. Use `lean-spec archive <spec>` to move old specs to `archived/` directory.
-**CRITICAL - What "Work" Means:**
-- ❌ **NOT**: Creating/writing the spec document itself
-- ✅ **YES**: Implementing what the spec describes (code, docs, features, etc.)
-- **Example**: Creating a spec for "API redesign" ≠ work complete
-  - Work = Actually redesigning the API as described in the spec
-  - Status `planned` until someone starts the redesign
-  - Status `in-progress` while redesigning
-  - Status `complete` after redesign is done
-
-**Status Update Triggers:**
-- ✅ **Before starting implementation** → `lean-spec update <spec> --status in-progress`
-- ✅ **After completing implementation** → `lean-spec update <spec> --status complete`
-- ✅ **If blocked or paused** → Update status and document why in spec
-- ❌ **NEVER mark spec complete just because you finished writing it**
-
-## Quality Standards
-
-- Tests cover critical paths
-- No unnecessary complexity
-- Documentation where needed (not everywhere)
-- Code is clear and maintainable
-- Specs stay in sync with implementation
-- **Status tracking is mandatory:**
-  - Mark spec as `in-progress` BEFORE starting work
-  - Mark spec as `complete` IMMEDIATELY after finishing
-  - Never leave specs with stale status
-
----
-
-**Remember**: LeanSpec is a mindset. Adapt these guidelines to what actually helps.

package/templates/minimal/spec-template.md

@@ -1,25 +0,0 @@
----
-status: planned
-created: '{date}'
----
-
-# {name}
-
-> **Status**: {status} · **Created**: {date}
-
-## Goal
-
-<!-- What problem does this solve? Why now? -->
-
-## Key Points
-
-- 
-- 
-
-## Non-Goals
-
-- 
-
-## Notes
-
-<!-- Decisions, constraints, open questions -->

package/templates/standard/agents-config.json

@@ -1,13 +0,0 @@
-{
-  "description": "Lightweight spec methodology for AI-powered development.",
-  "coreRules": ["core-rules-base-additions.md", "core-rules-shared.md"],
-  "whenToUse": "when-to-use-standard.md",
-  "whenToUseEarly": true,
-  "discoveryCommands": ["discovery-commands-shared.md", "discovery-commands-standard-additions.md"],
-  "essentialCommands": ["essential-commands-shared.md", "essential-commands-standard-additions.md"],
-  "frontmatter": "frontmatter-standard.md",
-  "workflow": ["workflow-standard-detailed.md", "status-update-triggers.md"],
-  "qualityStandards": ["quality-standards-minimal-additions.md", "quality-standards-shared.md"],
-  "closingNote": "**Remember**: LeanSpec is a mindset. Adapt these guidelines to what actually helps.",
-  "additionalSections": []
-}

package/templates/standard/files/AGENTS.md

@@ -1,144 +0,0 @@
-# AI Agent Instructions
-
-## Project: {project_name}
-
-Lightweight spec methodology for AI-powered development.
-
-## Core Rules
-
-1. **Read README.md first** - Understand project context
-2. **Check specs/** - Review existing specs before starting
-3. **Follow LeanSpec principles** - Clarity over documentation
-4. **Keep it minimal** - If it doesn't add clarity, cut it
-5. **Never use nested code blocks** - Markdown doesn't support code blocks within code blocks. Use indentation or describe the structure instead
-
-## When to Use Specs
-
-- Features that affect multiple parts of the system
-- Breaking changes or significant refactors
-- Design decisions that need team alignment
-- Complex features that benefit from upfront thinking
-
-Skip specs for:
-- Bug fixes
-- Trivial changes
-- Self-explanatory refactors
-
-## Discovery Commands
-
-Before starting work, understand project context:
-
-- `lean-spec stats` - See work distribution
-- `lean-spec board` - View specs by status
-- `lean-spec search "<query>"` - Find relevant work
-- `lean-spec list` - List all specs
-
-These help you understand what exists and what's in progress.
-**Additional commands:**
-- `lean-spec list --tag=<tag>` - Find specs by tag (e.g., `--tag=api`)
-- `lean-spec deps <spec>` - Check dependencies before starting work
-
-## Essential Commands
-
-**Discovery:**
-- `lean-spec list` - See all specs
-- `lean-spec search "<query>"` - Find relevant specs
-
-**Viewing specs:**
-- `lean-spec view <spec>` - View a spec (formatted)
-- `lean-spec open <spec>` - Open spec in editor
-
-**Working with specs:**
-- `lean-spec create <name>` - Create a new spec
-- `lean-spec update <spec> --status <status>` - Update spec status
-
-**When in doubt:** Run `lean-spec --help` to see all available commands.
-**Viewing specs (additional):**
-- `lean-spec view <spec> --raw` - Get raw markdown
-- `lean-spec files <spec>` - List all files in a spec
-
-**Project Overview:**
-- `lean-spec board` - Kanban view with project health summary
-- `lean-spec stats` - Quick project metrics
-
-**Working with specs (additional):**
-- `lean-spec update <spec> --priority <priority>` - Update spec priority
-- `lean-spec update <spec> --tags <tag1,tag2>` - Update spec tags
-- `lean-spec deps <spec>` - Show dependencies and relationships
-
-**Token Management:**
-- `lean-spec tokens <spec>` - Count tokens in a spec
-- `lean-spec tokens` - Show token counts for all specs
-
-**When in doubt (extended):** Run `lean-spec <command> --help` to discover available commands.
-
-## Spec Frontmatter
-
-When creating or updating specs, include YAML frontmatter at the top:
-
-```yaml
----
-status: draft|planned|in-progress|complete|blocked|cancelled
-created: YYYY-MM-DD
-tags: [tag1, tag2]  # helps with discovery
-priority: low|medium|high  # helps with planning
-assignee: username  # for team coordination
----
-```
-
-**Core fields:**
-- `status` and `created` are required
-- `tags` help with discovery and organization
-- `priority` helps teams plan work
-- `assignee` shows who's working on what
-
-**Update status with:**
-```bash
-lean-spec update <spec> --status in-progress --assignee yourname
-# or edit frontmatter directly
-```
-
-## Workflow
-
-1. **Discover context** - Run `lean-spec stats` or `lean-spec board` to see current state
-2. **Search existing specs** - Use `lean-spec search` or `lean-spec list` to find relevant work
-3. **Check dependencies** - Run `lean-spec deps <spec>` if working on existing spec
-4. **Create or update spec** - Add frontmatter with required fields (status: `planned`)
-5. **Start implementation** - Mark `in-progress` BEFORE implementing what the spec describes
-6. **Implement changes** - Keep spec in sync as you learn
-7. **Complete implementation** - Mark `complete` AFTER implementing what the spec describes
-8. **Document** - Report progress and document changes into the spec
-
-**Remember**: Status tracks implementation work, not spec document creation. Creating a spec = planning (stays `planned` until implementation starts).
-
-**Note on Archiving**: Archive specs when they're no longer actively referenced (weeks/months after completion), not immediately. Use `lean-spec archive <spec>` to move old specs to `archived/` directory.
-**CRITICAL - What "Work" Means:**
-- ❌ **NOT**: Creating/writing the spec document itself
-- ✅ **YES**: Implementing what the spec describes (code, docs, features, etc.)
-- **Example**: Creating a spec for "API redesign" ≠ work complete
-  - Work = Actually redesigning the API as described in the spec
-  - Status `planned` until someone starts the redesign
-  - Status `in-progress` while redesigning
-  - Status `complete` after redesign is done
-
-**Status Update Triggers:**
-- ✅ **Before starting implementation** → `lean-spec update <spec> --status in-progress`
-- ✅ **After completing implementation** → `lean-spec update <spec> --status complete`
-- ✅ **If blocked or paused** → Update status and document why in spec
-- ❌ **NEVER mark spec complete just because you finished writing it**
-
-## Quality Standards
-
-- Tests cover critical paths
-- No unnecessary complexity
-- Documentation where needed (not everywhere)
-- Code is clear and maintainable
-- Specs stay in sync with implementation
-- **Status tracking is mandatory:**
-  - Mark spec as `in-progress` BEFORE starting work
-  - Mark spec as `complete` IMMEDIATELY after finishing
-  - Never leave specs with stale status
-
----
-
-**Remember**: LeanSpec is a mindset. Adapt these guidelines to what actually helps.