lightspec 0.1.1

package/dist/core/templates/agents-template.js

@@ -0,0 +1,458 @@
+export const agentsTemplate = `# LightSpec Instructions
+
+Instructions for AI coding assistants using LightSpec for spec-driven development.
+
+## TL;DR Quick Checklist
+
+- Search existing work: \`lightspec spec list --long\`, \`lightspec list\` (use \`rg\` only for full-text search)
+- Decide scope: new capability vs modify existing capability
+- Pick a unique \`change-id\`: kebab-case, verb-led (\`add-\`, \`update-\`, \`remove-\`, \`refactor-\`)
+- Scaffold: \`proposal.md\`, \`tasks.md\`, \`design.md\` (only if needed), and delta specs per affected capability
+- Write deltas: use \`## ADDED|MODIFIED|REMOVED|RENAMED Requirements\`; include at least one \`#### Scenario:\` per requirement
+- Validate: \`lightspec validate [change-id] --strict --no-interactive\` and fix issues
+- Request approval: Do not start implementation until proposal is approved
+
+## Three-Stage Workflow
+
+### Stage 1: Creating Changes
+Create proposal when you need to:
+- Add features or functionality
+- Make breaking changes (API, schema)
+- Change architecture or patterns  
+- Optimize performance (changes behavior)
+- Update security patterns
+
+Triggers (examples):
+- "Help me create a change proposal"
+- "Help me plan a change"
+- "Help me create a proposal"
+- "I want to create a spec proposal"
+- "I want to create a spec"
+
+Loose matching guidance:
+- Contains one of: \`proposal\`, \`change\`, \`spec\`
+- With one of: \`create\`, \`plan\`, \`make\`, \`start\`, \`help\`
+
+Skip proposal for:
+- Bug fixes (restore intended behavior)
+- Typos, formatting, comments
+- Dependency updates (non-breaking)
+- Configuration changes
+- Tests for existing behavior
+
+**Workflow**
+1. Review \`lightspec/project.md\`, \`lightspec list\`, and \`lightspec list --specs\` to understand current context.
+2. Choose a unique verb-led \`change-id\` and scaffold \`proposal.md\`, \`tasks.md\`, optional \`design.md\`, and spec deltas under \`lightspec/changes/<id>/\`.
+3. Draft spec deltas using \`## ADDED|MODIFIED|REMOVED Requirements\` with at least one \`#### Scenario:\` per requirement.
+4. Run \`lightspec validate <id> --strict --no-interactive\` and resolve any issues before sharing the proposal.
+
+### Stage 2: Implementing Changes
+Track these steps as TODOs and complete them one by one.
+1. **Read proposal.md** - Understand what's being built
+2. **Read design.md** (if exists) - Review technical decisions
+3. **Read tasks.md** - Get implementation checklist
+4. **Implement tasks sequentially** - Complete in order
+5. **Confirm completion** - Ensure every item in \`tasks.md\` is finished before updating statuses
+6. **Update checklist** - After all work is done, set every task to \`- [x]\` so the list reflects reality
+7. **Approval gate** - Do not start implementation until the proposal is reviewed and approved
+
+### Stage 3: Archiving Changes
+After deployment, create separate PR to:
+- Move \`changes/[name]/\` → \`changes/archive/YYYY-MM-DD-[name]/\`
+- Update \`specs/\` if capabilities changed
+- Use \`lightspec archive <change-id> --skip-specs --yes\` for tooling-only changes (always pass the change ID explicitly)
+- Run \`lightspec validate --strict --no-interactive\` to confirm the archived change passes checks
+
+## Before Any Task
+
+**Context Checklist:**
+- [ ] Read relevant specs in \`specs/[capability]/spec.md\`
+- [ ] Check pending changes in \`changes/\` for conflicts
+- [ ] Read \`lightspec/project.md\` for conventions
+- [ ] Run \`lightspec list\` to see active changes
+- [ ] Run \`lightspec list --specs\` to see existing capabilities
+
+**Before Creating Specs:**
+- Always check if capability already exists
+- Prefer modifying existing specs over creating duplicates
+- Use \`lightspec show [spec]\` to review current state
+- If request is ambiguous, ask 1–2 clarifying questions before scaffolding
+
+### Search Guidance
+- Enumerate specs: \`lightspec spec list --long\` (or \`--json\` for scripts)
+- Enumerate changes: \`lightspec list\` (or \`lightspec change list --json\` - deprecated but available)
+- Show details:
+  - Spec: \`lightspec show <spec-id> --type spec\` (use \`--json\` for filters)
+  - Change: \`lightspec show <change-id> --json --deltas-only\`
+- Full-text search (use ripgrep): \`rg -n "Requirement:|Scenario:" lightspec/specs\`
+
+## Quick Start
+
+### CLI Commands
+
+\`\`\`bash
+# Essential commands
+lightspec list                  # List active changes
+lightspec list --specs          # List specifications
+lightspec show [item]           # Display change or spec
+lightspec validate [item]       # Validate changes or specs
+lightspec archive <change-id> [--yes|-y]   # Archive after deployment (add --yes for non-interactive runs)
+
+# Project management
+lightspec init [path]           # Initialize LightSpec
+lightspec update [path]         # Update instruction files
+
+# Interactive mode
+lightspec show                  # Prompts for selection
+lightspec validate              # Bulk validation mode
+
+# Debugging
+lightspec show [change] --json --deltas-only
+lightspec validate [change] --strict --no-interactive
+\`\`\`
+
+### Command Flags
+
+- \`--json\` - Machine-readable output
+- \`--type change|spec\` - Disambiguate items
+- \`--strict\` - Comprehensive validation
+- \`--no-interactive\` - Disable prompts
+- \`--skip-specs\` - Archive without spec updates
+- \`--yes\`/\`-y\` - Skip confirmation prompts (non-interactive archive)
+
+## Directory Structure
+
+\`\`\`
+lightspec/
+├── project.md              # Project conventions
+├── specs/                  # Current truth - what IS built
+│   └── [capability]/       # Single focused capability
+│       ├── spec.md         # Requirements and scenarios
+│       └── design.md       # Technical patterns
+├── changes/                # Proposals - what SHOULD change
+│   ├── [change-name]/
+│   │   ├── proposal.md     # Why, what, impact
+│   │   ├── tasks.md        # Implementation checklist
+│   │   ├── design.md       # Technical decisions (optional; see criteria)
+│   │   └── specs/          # Delta changes
+│   │       └── [capability]/
+│   │           └── spec.md # ADDED/MODIFIED/REMOVED
+│   └── archive/            # Completed changes
+\`\`\`
+
+## Creating Change Proposals
+
+### Decision Tree
+
+\`\`\`
+New request?
+├─ Bug fix restoring spec behavior? → Fix directly
+├─ Typo/format/comment? → Fix directly  
+├─ New feature/capability? → Create proposal
+├─ Breaking change? → Create proposal
+├─ Architecture change? → Create proposal
+└─ Unclear? → Create proposal (safer)
+\`\`\`
+
+### Proposal Structure
+
+1. **Create directory:** \`changes/[change-id]/\` (kebab-case, verb-led, unique)
+
+2. **Write proposal.md:**
+\`\`\`markdown
+# Change: [Brief description of change]
+
+## Why
+[1-2 sentences on problem/opportunity]
+
+## What Changes
+- [Bullet list of changes]
+- [Mark breaking changes with **BREAKING**]
+
+## Impact
+- Affected specs: [list capabilities]
+- Affected code: [key files/systems]
+\`\`\`
+
+3. **Create spec deltas:** \`specs/[capability]/spec.md\`
+\`\`\`markdown
+## ADDED Requirements
+### Requirement: New Feature
+The system SHALL provide...
+
+#### Scenario: Success case
+- **WHEN** user performs action
+- **THEN** expected result
+
+## MODIFIED Requirements
+### Requirement: Existing Feature
+[Complete modified requirement]
+
+## REMOVED Requirements
+### Requirement: Old Feature
+**Reason**: [Why removing]
+**Migration**: [How to handle]
+\`\`\`
+If multiple capabilities are affected, create multiple delta files under \`changes/[change-id]/specs/<capability>/spec.md\`—one per capability.
+
+4. **Create tasks.md:**
+\`\`\`markdown
+## 1. Implementation
+- [ ] 1.1 Create database schema
+- [ ] 1.2 Implement API endpoint
+- [ ] 1.3 Add frontend component
+- [ ] 1.4 Write tests
+\`\`\`
+
+5. **Create design.md when needed:**
+Create \`design.md\` if any of the following apply; otherwise omit it:
+- Cross-cutting change (multiple services/modules) or a new architectural pattern
+- New external dependency or significant data model changes
+- Security, performance, or migration complexity
+- Ambiguity that benefits from technical decisions before coding
+
+Minimal \`design.md\` skeleton:
+\`\`\`markdown
+## Context
+[Background, constraints, stakeholders]
+
+## Goals / Non-Goals
+- Goals: [...]
+- Non-Goals: [...]
+
+## Decisions
+- Decision: [What and why]
+- Alternatives considered: [Options + rationale]
+
+## Risks / Trade-offs
+- [Risk] → Mitigation
+
+## Migration Plan
+[Steps, rollback]
+
+## Open Questions
+- [...]
+\`\`\`
+
+## Spec File Format
+
+### Critical: Scenario Formatting
+
+**CORRECT** (use #### headers):
+\`\`\`markdown
+#### Scenario: User login success
+- **WHEN** valid credentials provided
+- **THEN** return JWT token
+\`\`\`
+
+**WRONG** (don't use bullets or bold):
+\`\`\`markdown
+- **Scenario: User login**  ❌
+**Scenario**: User login     ❌
+### Scenario: User login      ❌
+\`\`\`
+
+Every requirement MUST have at least one scenario.
+
+### Requirement Wording
+- Use SHALL/MUST for normative requirements (avoid should/may unless intentionally non-normative)
+
+### Delta Operations
+
+- \`## ADDED Requirements\` - New capabilities
+- \`## MODIFIED Requirements\` - Changed behavior
+- \`## REMOVED Requirements\` - Deprecated features
+- \`## RENAMED Requirements\` - Name changes
+
+Headers matched with \`trim(header)\` - whitespace ignored.
+
+#### When to use ADDED vs MODIFIED
+- ADDED: Introduces a new capability or sub-capability that can stand alone as a requirement. Prefer ADDED when the change is orthogonal (e.g., adding "Slash Command Configuration") rather than altering the semantics of an existing requirement.
+- MODIFIED: Changes the behavior, scope, or acceptance criteria of an existing requirement. Always paste the full, updated requirement content (header + all scenarios). The archiver will replace the entire requirement with what you provide here; partial deltas will drop previous details.
+- RENAMED: Use when only the name changes. If you also change behavior, use RENAMED (name) plus MODIFIED (content) referencing the new name.
+
+Common pitfall: Using MODIFIED to add a new concern without including the previous text. This causes loss of detail at archive time. If you aren’t explicitly changing the existing requirement, add a new requirement under ADDED instead.
+
+Authoring a MODIFIED requirement correctly:
+1) Locate the existing requirement in \`lightspec/specs/<capability>/spec.md\`.
+2) Copy the entire requirement block (from \`### Requirement: ...\` through its scenarios).
+3) Paste it under \`## MODIFIED Requirements\` and edit to reflect the new behavior.
+4) Ensure the header text matches exactly (whitespace-insensitive) and keep at least one \`#### Scenario:\`.
+
+Example for RENAMED:
+\`\`\`markdown
+## RENAMED Requirements
+- FROM: \`### Requirement: Login\`
+- TO: \`### Requirement: User Authentication\`
+\`\`\`
+
+## Troubleshooting
+
+### Common Errors
+
+**"Change must have at least one delta"**
+- Check \`changes/[name]/specs/\` exists with .md files
+- Verify files have operation prefixes (## ADDED Requirements)
+
+**"Requirement must have at least one scenario"**
+- Check scenarios use \`#### Scenario:\` format (4 hashtags)
+- Don't use bullet points or bold for scenario headers
+
+**Silent scenario parsing failures**
+- Exact format required: \`#### Scenario: Name\`
+- Debug with: \`lightspec show [change] --json --deltas-only\`
+
+### Validation Tips
+
+\`\`\`bash
+# Always use strict mode for comprehensive checks
+lightspec validate [change] --strict --no-interactive
+
+# Debug delta parsing
+lightspec show [change] --json | jq '.deltas'
+
+# Check specific requirement
+lightspec show [spec] --json -r 1
+\`\`\`
+
+## Happy Path Script
+
+\`\`\`bash
+# 1) Explore current state
+lightspec spec list --long
+lightspec list
+# Optional full-text search:
+# rg -n "Requirement:|Scenario:" lightspec/specs
+# rg -n "^#|Requirement:" lightspec/changes
+
+# 2) Choose change id and scaffold
+CHANGE=add-two-factor-auth
+mkdir -p lightspec/changes/$CHANGE/{specs/auth}
+printf "## Why\\n...\\n\\n## What Changes\\n- ...\\n\\n## Impact\\n- ...\\n" > lightspec/changes/$CHANGE/proposal.md
+printf "## 1. Implementation\\n- [ ] 1.1 ...\\n" > lightspec/changes/$CHANGE/tasks.md
+
+# 3) Add deltas (example)
+cat > lightspec/changes/$CHANGE/specs/auth/spec.md << 'EOF'
+## ADDED Requirements
+### Requirement: Two-Factor Authentication
+Users MUST provide a second factor during login.
+
+#### Scenario: OTP required
+- **WHEN** valid credentials are provided
+- **THEN** an OTP challenge is required
+EOF
+
+# 4) Validate
+lightspec validate $CHANGE --strict --no-interactive
+\`\`\`
+
+## Multi-Capability Example
+
+\`\`\`
+lightspec/changes/add-2fa-notify/
+├── proposal.md
+├── tasks.md
+└── specs/
+    ├── auth/
+    │   └── spec.md   # ADDED: Two-Factor Authentication
+    └── notifications/
+        └── spec.md   # ADDED: OTP email notification
+\`\`\`
+
+auth/spec.md
+\`\`\`markdown
+## ADDED Requirements
+### Requirement: Two-Factor Authentication
+...
+\`\`\`
+
+notifications/spec.md
+\`\`\`markdown
+## ADDED Requirements
+### Requirement: OTP Email Notification
+...
+\`\`\`
+
+## Best Practices
+
+### Simplicity First
+- Default to <100 lines of new code
+- Single-file implementations until proven insufficient
+- Avoid frameworks without clear justification
+- Choose boring, proven patterns
+
+### Complexity Triggers
+Only add complexity with:
+- Performance data showing current solution too slow
+- Concrete scale requirements (>1000 users, >100MB data)
+- Multiple proven use cases requiring abstraction
+
+### Clear References
+- Use \`file.ts:42\` format for code locations
+- Reference specs as \`specs/auth/spec.md\`
+- Link related changes and PRs
+
+### Capability Naming
+- Use verb-noun: \`user-auth\`, \`payment-capture\`
+- Single purpose per capability
+- 10-minute understandability rule
+- Split if description needs "AND"
+
+### Change ID Naming
+- Use kebab-case, short and descriptive: \`add-two-factor-auth\`
+- Prefer verb-led prefixes: \`add-\`, \`update-\`, \`remove-\`, \`refactor-\`
+- Ensure uniqueness; if taken, append \`-2\`, \`-3\`, etc.
+
+## Tool Selection Guide
+
+| Task | Tool | Why |
+|------|------|-----|
+| Find files by pattern | Glob | Fast pattern matching |
+| Search code content | Grep | Optimized regex search |
+| Read specific files | Read | Direct file access |
+| Explore unknown scope | Task | Multi-step investigation |
+
+## Error Recovery
+
+### Change Conflicts
+1. Run \`lightspec list\` to see active changes
+2. Check for overlapping specs
+3. Coordinate with change owners
+4. Consider combining proposals
+
+### Validation Failures
+1. Run with \`--strict\` flag
+2. Check JSON output for details
+3. Verify spec file format
+4. Ensure scenarios properly formatted
+
+### Missing Context
+1. Read project.md first
+2. Check related specs
+3. Review recent archives
+4. Ask for clarification
+
+## Quick Reference
+
+### Stage Indicators
+- \`changes/\` - Proposed, not yet built
+- \`specs/\` - Built and deployed
+- \`archive/\` - Completed changes
+
+### File Purposes
+- \`proposal.md\` - Why and what
+- \`tasks.md\` - Implementation steps
+- \`design.md\` - Technical decisions
+- \`spec.md\` - Requirements and behavior
+
+### CLI Essentials
+\`\`\`bash
+lightspec list              # What's in progress?
+lightspec show [item]       # View details
+lightspec validate --strict --no-interactive  # Is it correct?
+lightspec archive <change-id> [--yes|-y]  # Mark complete (add --yes for automation)
+\`\`\`
+
+Remember: Specs are truth. Changes are proposals. Keep them in sync.
+`;
+//# sourceMappingURL=agents-template.js.map

package/dist/core/templates/claude-template.d.ts

@@ -0,0 +1,2 @@
+export { agentsRootStubTemplate as claudeTemplate } from './agents-root-stub.js';
+//# sourceMappingURL=claude-template.d.ts.map

package/dist/core/templates/claude-template.js

@@ -0,0 +1,2 @@
+export { agentsRootStubTemplate as claudeTemplate } from './agents-root-stub.js';
+//# sourceMappingURL=claude-template.js.map

package/dist/core/templates/cline-template.d.ts

@@ -0,0 +1,2 @@
+export { agentsRootStubTemplate as clineTemplate } from './agents-root-stub.js';
+//# sourceMappingURL=cline-template.d.ts.map

package/dist/core/templates/cline-template.js

@@ -0,0 +1,2 @@
+export { agentsRootStubTemplate as clineTemplate } from './agents-root-stub.js';
+//# sourceMappingURL=cline-template.js.map

package/dist/core/templates/costrict-template.d.ts

@@ -0,0 +1,2 @@
+export { agentsRootStubTemplate as costrictTemplate } from './agents-root-stub.js';
+//# sourceMappingURL=costrict-template.d.ts.map

package/dist/core/templates/costrict-template.js

@@ -0,0 +1,2 @@
+export { agentsRootStubTemplate as costrictTemplate } from './agents-root-stub.js';
+//# sourceMappingURL=costrict-template.js.map

package/dist/core/templates/index.d.ts

@@ -0,0 +1,17 @@
+import { ProjectContext } from './project-template.js';
+import { SlashCommandId } from './slash-command-templates.js';
+export interface Template {
+    path: string;
+    content: string | ((context: ProjectContext) => string);
+}
+export declare class TemplateManager {
+    static getTemplates(context?: ProjectContext): Template[];
+    static getClaudeTemplate(): string;
+    static getClineTemplate(): string;
+    static getCostrictTemplate(): string;
+    static getAgentsStandardTemplate(): string;
+    static getSlashCommandBody(id: SlashCommandId): string;
+}
+export { ProjectContext } from './project-template.js';
+export type { SlashCommandId } from './slash-command-templates.js';
+//# sourceMappingURL=index.d.ts.map

package/dist/core/templates/index.js

@@ -0,0 +1,37 @@
+import { agentsTemplate } from './agents-template.js';
+import { projectTemplate } from './project-template.js';
+import { claudeTemplate } from './claude-template.js';
+import { clineTemplate } from './cline-template.js';
+import { costrictTemplate } from './costrict-template.js';
+import { agentsRootStubTemplate } from './agents-root-stub.js';
+import { getSlashCommandBody } from './slash-command-templates.js';
+export class TemplateManager {
+    static getTemplates(context = {}) {
+        return [
+            {
+                path: 'AGENTS.md',
+                content: agentsTemplate
+            },
+            {
+                path: 'project.md',
+                content: projectTemplate(context)
+            }
+        ];
+    }
+    static getClaudeTemplate() {
+        return claudeTemplate;
+    }
+    static getClineTemplate() {
+        return clineTemplate;
+    }
+    static getCostrictTemplate() {
+        return costrictTemplate;
+    }
+    static getAgentsStandardTemplate() {
+        return agentsRootStubTemplate;
+    }
+    static getSlashCommandBody(id) {
+        return getSlashCommandBody(id);
+    }
+}
+//# sourceMappingURL=index.js.map

package/dist/core/templates/project-template.d.ts

@@ -0,0 +1,8 @@
+export interface ProjectContext {
+    projectName?: string;
+    description?: string;
+    techStack?: string[];
+    conventions?: string;
+}
+export declare const projectTemplate: (context?: ProjectContext) => string;
+//# sourceMappingURL=project-template.d.ts.map

package/dist/core/templates/project-template.js

@@ -0,0 +1,32 @@
+export const projectTemplate = (context = {}) => `# ${context.projectName || 'Project'} Context
+
+## Purpose
+${context.description || '[Describe your project\'s purpose and goals]'}
+
+## Tech Stack
+${context.techStack?.length ? context.techStack.map(tech => `- ${tech}`).join('\n') : '- [List your primary technologies]\n- [e.g., TypeScript, React, Node.js]'}
+
+## Project Conventions
+
+### Code Style
+[Describe your code style preferences, formatting rules, and naming conventions]
+
+### Architecture Patterns
+[Document your architectural decisions and patterns]
+
+### Testing Strategy
+[Explain your testing approach and requirements]
+
+### Git Workflow
+[Describe your branching strategy and commit conventions]
+
+## Domain Context
+[Add domain-specific knowledge that AI assistants need to understand]
+
+## Important Constraints
+[List any technical, business, or regulatory constraints]
+
+## External Dependencies
+[Document key external services, APIs, or systems]
+`;
+//# sourceMappingURL=project-template.js.map

package/dist/core/templates/slash-command-templates.d.ts

@@ -0,0 +1,4 @@
+export type SlashCommandId = 'proposal' | 'apply' | 'archive';
+export declare const slashCommandBodies: Record<SlashCommandId, string>;
+export declare function getSlashCommandBody(id: SlashCommandId): string;
+//# sourceMappingURL=slash-command-templates.d.ts.map

package/dist/core/templates/slash-command-templates.js

@@ -0,0 +1,49 @@
+const baseGuardrails = `**Guardrails**
+- Favor straightforward, minimal implementations first and add complexity only when it is requested or clearly required.
+- Keep changes tightly scoped to the requested outcome.
+- Refer to \`lightspec/AGENTS.md\` (located inside the \`lightspec/\` directory—run \`ls lightspec\` or \`lightspec update\` if you don't see it) if you need additional LightSpec conventions or clarifications.`;
+const proposalGuardrails = `${baseGuardrails}\n- Identify any vague or ambiguous details and ask the necessary follow-up questions before editing files.
+- Do not write any code during the proposal stage. Only create design documents (proposal.md, tasks.md, design.md, and spec deltas). Implementation happens in the apply stage after approval.`;
+const proposalSteps = `**Steps**
+1. Review \`lightspec/project.md\`, run \`lightspec list\` and \`lightspec list --specs\`, and inspect related code or docs (e.g., via \`rg\`/\`ls\`) to ground the proposal in current behaviour; note any gaps that require clarification.
+2. Choose a unique verb-led \`change-id\` and scaffold \`proposal.md\`, \`tasks.md\`, and \`design.md\` (when needed) under \`lightspec/changes/<id>/\`.
+3. Map the change into concrete capabilities or requirements, breaking multi-scope efforts into distinct spec deltas with clear relationships and sequencing.
+4. Capture architectural reasoning in \`design.md\` when the solution spans multiple systems, introduces new patterns, or demands trade-off discussion before committing to specs.
+5. Draft spec deltas in \`changes/<id>/specs/<capability>/spec.md\` (one folder per capability) using \`## ADDED|MODIFIED|REMOVED Requirements\` with at least one \`#### Scenario:\` per requirement and cross-reference related capabilities when relevant.
+6. Draft \`tasks.md\` as an ordered list of small, verifiable work items that deliver user-visible progress, include validation (tests, tooling), and highlight dependencies or parallelizable work.
+7. Validate with \`lightspec validate <id> --strict --no-interactive\` and resolve every issue before sharing the proposal.`;
+const proposalReferences = `**Reference**
+- Use \`lightspec show <id> --json --deltas-only\` or \`lightspec show <spec> --type spec\` to inspect details when validation fails.
+- Search existing requirements with \`rg -n "Requirement:|Scenario:" lightspec/specs\` before writing new ones.
+- Explore the codebase with \`rg <keyword>\`, \`ls\`, or direct file reads so proposals align with current implementation realities.`;
+const applySteps = `**Steps**
+Track these steps as TODOs and complete them one by one.
+1. Read \`changes/<id>/proposal.md\`, \`design.md\` (if present), and \`tasks.md\` to confirm scope and acceptance criteria.
+2. Work through tasks sequentially, keeping edits minimal and focused on the requested change.
+3. Confirm completion before updating statuses—make sure every item in \`tasks.md\` is finished.
+4. Update the checklist after all work is done so each task is marked \`- [x]\` and reflects reality.
+5. Reference \`lightspec list\` or \`lightspec show <item>\` when additional context is required.`;
+const applyReferences = `**Reference**
+- Use \`lightspec show <id> --json --deltas-only\` if you need additional context from the proposal while implementing.`;
+const archiveSteps = `**Steps**
+1. Determine the change ID to archive:
+   - If this prompt already includes a specific change ID (for example inside a \`<ChangeId>\` block populated by slash-command arguments), use that value after trimming whitespace.
+   - If the conversation references a change loosely (for example by title or summary), run \`lightspec list\` to surface likely IDs, share the relevant candidates, and confirm which one the user intends.
+   - Otherwise, review the conversation, run \`lightspec list\`, and ask the user which change to archive; wait for a confirmed change ID before proceeding.
+   - If you still cannot identify a single change ID, stop and tell the user you cannot archive anything yet.
+2. Validate the change ID by running \`lightspec list\` (or \`lightspec show <id>\`) and stop if the change is missing, already archived, or otherwise not ready to archive.
+3. Run \`lightspec archive <id> --yes\` so the CLI moves the change and applies spec updates without prompts (use \`--skip-specs\` only for tooling-only work).
+4. Review the command output to confirm the target specs were updated and the change landed in \`changes/archive/\`.
+5. Validate with \`lightspec validate --strict --no-interactive\` and inspect with \`lightspec show <id>\` if anything looks off.`;
+const archiveReferences = `**Reference**
+- Use \`lightspec list\` to confirm change IDs before archiving.
+- Inspect refreshed specs with \`lightspec list --specs\` and address any validation issues before handing off.`;
+export const slashCommandBodies = {
+    proposal: [proposalGuardrails, proposalSteps, proposalReferences].join('\n\n'),
+    apply: [baseGuardrails, applySteps, applyReferences].join('\n\n'),
+    archive: [baseGuardrails, archiveSteps, archiveReferences].join('\n\n')
+};
+export function getSlashCommandBody(id) {
+    return slashCommandBodies[id];
+}
+//# sourceMappingURL=slash-command-templates.js.map

package/dist/core/update.d.ts

@@ -0,0 +1,4 @@
+export declare class UpdateCommand {
+    execute(projectPath: string): Promise<void>;
+}
+//# sourceMappingURL=update.d.ts.map