@mindfoldhq/trellis 0.3.5 → 0.3.7

package/dist/templates/iflow/hooks/session-start.py

@@ -66,6 +66,60 @@ def run_script(script_path: Path) -> str:
         return "No context available"
 
 
+def _get_task_status(trellis_dir: Path) -> str:
+    """Check current task status and return structured status string."""
+    current_task_file = trellis_dir / ".current-task"
+    if not current_task_file.is_file():
+        return "Status: NO ACTIVE TASK\nNext: Describe what you want to work on"
+
+    task_ref = current_task_file.read_text(encoding="utf-8").strip()
+    if not task_ref:
+        return "Status: NO ACTIVE TASK\nNext: Describe what you want to work on"
+
+    # Resolve task directory
+    if Path(task_ref).is_absolute():
+        task_dir = Path(task_ref)
+    elif task_ref.startswith(".trellis/"):
+        task_dir = trellis_dir.parent / task_ref
+    else:
+        task_dir = trellis_dir / "tasks" / task_ref
+    if not task_dir.is_dir():
+        return f"Status: STALE POINTER\nTask: {task_ref}\nNext: Task directory not found. Run: python3 ./.trellis/scripts/task.py finish"
+
+    # Read task.json
+    task_json_path = task_dir / "task.json"
+    task_data = {}
+    if task_json_path.is_file():
+        try:
+            task_data = json.loads(task_json_path.read_text(encoding="utf-8"))
+        except (json.JSONDecodeError, PermissionError):
+            pass
+
+    task_title = task_data.get("title", task_ref)
+    task_status = task_data.get("status", "unknown")
+
+    if task_status == "completed":
+        return f"Status: COMPLETED\nTask: {task_title}\nNext: Archive with `python3 ./.trellis/scripts/task.py archive {task_dir.name}` or start a new task"
+
+    # Check if context is configured (jsonl files exist and non-empty)
+    has_context = False
+    for jsonl_name in ("implement.jsonl", "check.jsonl", "spec.jsonl"):
+        jsonl_path = task_dir / jsonl_name
+        if jsonl_path.is_file() and jsonl_path.stat().st_size > 0:
+            has_context = True
+            break
+
+    has_prd = (task_dir / "prd.md").is_file()
+
+    if not has_prd:
+        return f"Status: NOT READY\nTask: {task_title}\nMissing: prd.md not created\nNext: Write PRD, then research → init-context → start"
+
+    if not has_context:
+        return f"Status: NOT READY\nTask: {task_title}\nMissing: Context not configured (no jsonl files)\nNext: Complete Phase 2 (research → init-context → start) before implementing"
+
+    return f"Status: READY\nTask: {task_title}\nNext: Continue with implement or check"
+
+
 def main():
     if should_skip_injection():
         sys.exit(0)
@@ -95,28 +149,31 @@ Read and follow all instructions below carefully.
     output.write("\n</workflow>\n\n")
 
     output.write("<guidelines>\n")
-
-    output.write("## Frontend\n")
-    frontend_index = read_file(
-        trellis_dir / "spec" / "frontend" / "index.md", "Not configured"
-    )
-    output.write(frontend_index)
-    output.write("\n\n")
-
-    output.write("## Backend\n")
-    backend_index = read_file(
-        trellis_dir / "spec" / "backend" / "index.md", "Not configured"
-    )
-    output.write(backend_index)
-    output.write("\n\n")
-
-    output.write("## Guides\n")
-    guides_index = read_file(
-        trellis_dir / "spec" / "guides" / "index.md", "Not configured"
-    )
-    output.write(guides_index)
-
-    output.write("\n</guidelines>\n\n")
+    output.write("**Note**: The guidelines below are index files — they list available guideline documents and their locations.\n")
+    output.write("During actual development, you MUST read the specific guideline files listed in each index's Pre-Development Checklist.\n\n")
+
+    spec_dir = trellis_dir / "spec"
+    if spec_dir.is_dir():
+        for sub in sorted(spec_dir.iterdir()):
+            if not sub.is_dir() or sub.name.startswith("."):
+                continue
+            index_file = sub / "index.md"
+            if index_file.is_file():
+                output.write(f"## {sub.name}\n")
+                output.write(read_file(index_file))
+                output.write("\n\n")
+            else:
+                # Check for nested package dirs (monorepo: spec/<pkg>/<layer>/index.md)
+                for nested in sorted(sub.iterdir()):
+                    if not nested.is_dir():
+                        continue
+                    nested_index = nested / "index.md"
+                    if nested_index.is_file():
+                        output.write(f"## {sub.name}/{nested.name}\n")
+                        output.write(read_file(nested_index))
+                        output.write("\n\n")
+
+    output.write("</guidelines>\n\n")
 
     output.write("<instructions>\n")
     start_md = read_file(
@@ -125,8 +182,14 @@ Read and follow all instructions below carefully.
     output.write(start_md)
     output.write("\n</instructions>\n\n")
 
+    # R2: Check task status and inject structured tag
+    task_status = _get_task_status(trellis_dir)
+    output.write(f"<task-status>\n{task_status}\n</task-status>\n\n")
+
     output.write("""<ready>
-Context loaded. Wait for user's first message, then follow <instructions> to handle their request.
+Context loaded. Steps 1-3 (workflow, context, guidelines) are already injected above — do NOT re-read them.
+Start from Step 4. Wait for user's first message, then follow <instructions> to handle their request.
+If there is an active task, ask whether to continue it.
 </ready>""")
 
     result = {

package/dist/templates/kilo/workflows/brainstorm.md

@@ -387,6 +387,19 @@ Here's my understanding of the complete requirements:
 Does this look correct? If yes, I'll proceed with implementation.
 ```
 
+### Subtask Decomposition (Complex Tasks)
+
+For complex tasks with multiple independent work items, create subtasks:
+
+```bash
+# Create child tasks
+CHILD1=$(python3 ./.trellis/scripts/task.py create "Child task 1" --slug child1 --parent "$TASK_DIR")
+CHILD2=$(python3 ./.trellis/scripts/task.py create "Child task 2" --slug child2 --parent "$TASK_DIR")
+
+# Or link existing tasks
+python3 ./.trellis/scripts/task.py add-subtask "$TASK_DIR" "$CHILD_DIR"
+```
+
 ---
 
 ## PRD Target Structure (final)

package/dist/templates/kilo/workflows/record-session.md

@@ -12,7 +12,10 @@
 python3 ./.trellis/scripts/get_context.py --mode record
 ```
 
-[!] If MY ACTIVE TASKS shows any completed tasks, archive them FIRST:
+[!] Archive tasks whose work is **actually done** — judge by work status, not the `status` field in task.json:
+- Code committed? → Archive it (don't wait for PR)
+- All acceptance criteria met? → Archive it
+- Don't skip archiving just because `status` still says `planning` or `in_progress`
 
 ```bash
 python3 ./.trellis/scripts/task.py archive <task-name>

package/dist/templates/kilo/workflows/start.md

@@ -45,6 +45,10 @@ cat .trellis/spec/backend/index.md   # Backend guidelines
 cat .trellis/spec/guides/index.md    # Thinking guides
 ```
 
+> **Important**: The index files are navigation — they list the actual guideline files (e.g., `error-handling.md`, `conventions.md`, `mock-strategies.md`).
+> At this step, just read the indexes to understand what's available.
+> When you start actual development, you MUST go back and read the specific guideline files relevant to your task, as listed in the index's Pre-Development Checklist.
+
 ### Step 4: Report and Ask
 
 Report what you learned and ask: "What would you like to work on?"
@@ -58,12 +62,28 @@ When user describes a task, classify it:
 | Type | Criteria | Workflow |
 |------|----------|----------|
 | **Question** | User asks about code, architecture, or how something works | Answer directly |
-| **Trivial Fix** | Typo fix, comment update, single-line change, < 5 minutes | Direct Edit |
-| **Development Task** | Any code change that: modifies logic, adds features, fixes bugs, touches multiple files | **Task Workflow** |
+| **Trivial Fix** | Typo fix, comment update, single-line change | Direct Edit |
+| **Simple Task** | Clear goal, 1-2 files, well-defined scope | Quick confirm → Implement |
+| **Complex Task** | Vague goal, multiple files, architectural decisions | **Brainstorm → Task Workflow** |
+
+### Classification Signals
+
+**Trivial/Simple indicators:**
+- User specifies exact file and change
+- "Fix the typo in X"
+- "Add field Y to component Z"
+- Clear acceptance criteria already stated
+
+**Complex indicators:**
+- "I want to add a feature for..."
+- "Can you help me improve..."
+- Mentions multiple areas or systems
+- No clear implementation path
+- User seems unsure about approach
 
 ### Decision Rule
 
-> **If in doubt, use Task Workflow.**
+> **If in doubt, use Brainstorm + Task Workflow.**
 >
 > Task Workflow ensures specs are injected to agents, resulting in higher quality code.
 > The overhead is minimal, but the benefit is significant.
@@ -79,6 +99,43 @@ For questions or trivial fixes, work directly:
 
 ---
 
+## Simple Task
+
+For simple, well-defined tasks:
+
+1. Quick confirm: "I understand you want to [goal]. Shall I proceed?"
+2. If no, clarify and confirm again
+3. **If yes: execute ALL steps below without stopping. Do NOT ask for additional confirmation between steps.**
+   - Create task directory (Phase 1 Path B, Step 2)
+   - Write PRD (Step 3)
+   - Research codebase (Phase 2, Step 5)
+   - Configure context (Step 6)
+   - Activate task (Step 7)
+   - Implement (Phase 3, Step 8)
+   - Check quality (Step 9)
+   - Complete (Step 10)
+
+---
+
+## Complex Task - Brainstorm First
+
+For complex or vague tasks, **automatically start the brainstorm process** — do NOT skip directly to implementation.
+
+See `/trellis:brainstorm` for the full process. Summary:
+
+1. **Acknowledge and classify** - State your understanding
+2. **Create task directory** - Track evolving requirements in `prd.md`
+3. **Ask questions one at a time** - Update PRD after each answer
+4. **Propose approaches** - For architectural decisions
+5. **Confirm final requirements** - Get explicit approval
+6. **Proceed to Task Workflow** - With clear requirements in PRD
+
+> **Subtask Decomposition**: If brainstorm reveals multiple independent work items,
+> consider creating subtasks using `--parent` flag or `add-subtask` command.
+> See `/trellis:brainstorm` Step 8 for details.
+
+---
+
 ## Task Workflow (Development Tasks)
 
 **Why this workflow?**
@@ -100,6 +157,10 @@ From Simple Task:
 
 **Key principle: Research happens AFTER requirements are clear (PRD exists).**
 
+> **Subtask Decomposition**: For complex tasks with multiple independent work items,
+> consider creating subtasks using `--parent` flag or `add-subtask` command.
+> See `/trellis:brainstorm` Step 8 for details.
+
 ---
 
 ### Phase 1: Establish Requirements

package/dist/templates/kiro/skills/brainstorm/SKILL.md

@@ -392,6 +392,19 @@ Here's my understanding of the complete requirements:
 Does this look correct? If yes, I'll proceed with implementation.
 ```
 
+### Subtask Decomposition (Complex Tasks)
+
+For complex tasks with multiple independent work items, create subtasks:
+
+```bash
+# Create child tasks
+CHILD1=$(python3 ./.trellis/scripts/task.py create "Child task 1" --slug child1 --parent "$TASK_DIR")
+CHILD2=$(python3 ./.trellis/scripts/task.py create "Child task 2" --slug child2 --parent "$TASK_DIR")
+
+# Or link existing tasks
+python3 ./.trellis/scripts/task.py add-subtask "$TASK_DIR" "$CHILD_DIR"
+```
+
 ---
 
 ## PRD Target Structure (final)

package/dist/templates/kiro/skills/record-session/SKILL.md

@@ -17,7 +17,10 @@ description: "Record work progress after human has tested and committed code"
 python3 ./.trellis/scripts/get_context.py --mode record
 ```
 
-[!] If MY ACTIVE TASKS shows any completed tasks, archive them FIRST:
+[!] Archive tasks whose work is **actually done** — judge by work status, not the `status` field in task.json:
+- Code committed? → Archive it (don't wait for PR)
+- All acceptance criteria met? → Archive it
+- Don't skip archiving just because `status` still says `planning` or `in_progress`
 
 ```bash
 python3 ./.trellis/scripts/task.py archive <task-name>

package/dist/templates/kiro/skills/start/SKILL.md

@@ -50,6 +50,10 @@ cat .trellis/spec/backend/index.md   # Backend guidelines
 cat .trellis/spec/guides/index.md    # Thinking guides
 ```
 
+> **Important**: The index files are navigation — they list the actual guideline files (e.g., `error-handling.md`, `conventions.md`, `mock-strategies.md`).
+> At this step, just read the indexes to understand what's available.
+> When you start actual development, you MUST go back and read the specific guideline files relevant to your task, as listed in the index's Pre-Development Checklist.
+
 ### Step 4: Report and Ask
 
 Report what you learned and ask: "What would you like to work on?"
@@ -74,6 +78,10 @@ When user describes a task, classify it:
 > Task Workflow ensures code-specs are injected to the right context, resulting in higher quality code.
 > The overhead is minimal, but the benefit is significant.
 
+> **Subtask Decomposition**: If brainstorm reveals multiple independent work items,
+> consider creating subtasks using `--parent` flag or `add-subtask` command.
+> See the brainstorm skill's Step 8 for details.
+
 ---
 
 ## Question / Trivial Fix
@@ -89,15 +97,23 @@ For questions or trivial fixes, work directly:
 
 For simple, well-defined tasks:
 
-1. Quick confirm: "I understand you want to [goal]. Ready to proceed?"
-2. If yes, proceed to **Task Workflow Phase 1 Path B** (create task, write PRD, then research)
-3. If no, clarify and confirm again
+1. Quick confirm: "I understand you want to [goal]. Shall I proceed?"
+2. If no, clarify and confirm again
+3. **If yes: execute ALL steps below without stopping. Do NOT ask for additional confirmation between steps.**
+   - Create task directory (Phase 1 Path B, Step 2)
+   - Write PRD (Step 3)
+   - Research codebase (Phase 2, Step 5)
+   - Configure context (Step 6)
+   - Activate task (Step 7)
+   - Implement (Phase 3, Step 8)
+   - Check quality (Step 9)
+   - Complete (Step 10)
 
 ---
 
 ## Complex Task - Brainstorm First
 
-For complex or vague tasks, use the brainstorm process to clarify requirements.
+For complex or vague tasks, **automatically start the brainstorm process** — do NOT skip directly to implementation.
 
 See `$brainstorm` for the full process. Summary:
 

package/dist/templates/markdown/spec/backend/directory-structure.md

@@ -0,0 +1,292 @@
+# Directory Structure
+
+> How backend/CLI code is organized in this project.
+
+---
+
+## Overview
+
+This project is a **TypeScript CLI tool** using ES modules. The source code follows a **dogfooding architecture** - Trellis uses its own configuration files (`.cursor/`, `.claude/`, `.trellis/`) as templates for new projects.
+
+---
+
+## Directory Layout
+
+```
+src/
+├── cli/                 # CLI entry point and argument parsing
+│   └── index.ts         # Main CLI entry (Commander.js setup)
+├── commands/            # Command implementations
+│   └── init.ts          # Each command in its own file
+├── configurators/       # Configuration generators
+│   ├── index.ts         # Platform registry (PLATFORM_FUNCTIONS, derived helpers)
+│   ├── shared.ts        # Shared utilities (resolvePlaceholders)
+│   ├── claude.ts        # Claude Code configurator
+│   ├── cursor.ts        # Cursor configurator
+│   ├── iflow.ts         # iFlow CLI configurator
+│   ├── opencode.ts      # OpenCode configurator
+│   └── workflow.ts      # Creates .trellis/ structure
+├── constants/           # Shared constants and paths
+│   └── paths.ts         # Path constants (centralized)
+├── templates/           # Template utilities and generic templates
+│   ├── markdown/        # Generic markdown templates
+│   │   ├── spec/        # Spec templates (*.md.txt)
+│   │   ├── init-agent.md    # Project root file template
+│   │   ├── agents.md        # Project root file template
+│   │   ├── worktree.yaml.txt # Generic worktree config
+│   │   └── index.ts     # Template exports
+│   └── extract.ts       # Template extraction utilities
+├── types/               # TypeScript type definitions
+│   └── ai-tools.ts      # AI tool types and registry
+├── utils/               # Shared utility functions
+│   ├── compare-versions.ts # Semver comparison with prerelease support
+│   ├── file-writer.ts   # File writing with conflict handling
+│   ├── project-detector.ts # Project type detection
+│   ├── template-fetcher.ts # Remote template download from GitHub
+│   └── template-hash.ts # Template hash tracking for update detection
+└── index.ts             # Package entry point (exports public API)
+```
+
+### Dogfooding Directories (Project Root)
+
+These directories are copied to `dist/` during build and used as templates:
+
+```
+.cursor/                 # Cursor configuration (dogfooded)
+├── commands/            # Slash commands for Cursor
+│   ├── start.md
+│   ├── finish-work.md
+│   └── ...
+
+.claude/                 # Claude Code configuration (dogfooded)
+├── commands/            # Slash commands
+├── agents/              # Multi-agent pipeline agents
+├── hooks/               # Context injection hooks
+└── settings.json        # Hook configuration
+
+.trellis/                # Trellis workflow (partially dogfooded)
+├── scripts/             # Python scripts (dogfooded)
+│   ├── common/          # Shared utilities (paths.py, developer.py, etc.)
+│   ├── multi_agent/     # Pipeline scripts (start.py, status.py, etc.)
+│   ├── hooks/           # Lifecycle hook scripts (project-specific, NOT dogfooded)
+│   └── *.py             # Main scripts (task.py, get_context.py, etc.)
+├── workspace/           # Developer progress tracking
+│   └── index.md         # Index template (dogfooded)
+├── spec/                # Project guidelines (NOT dogfooded)
+│   ├── backend/         # Backend development docs
+│   ├── frontend/        # Frontend development docs
+│   └── guides/          # Thinking guides
+├── workflow.md          # Workflow documentation (dogfooded)
+├── worktree.yaml        # Worktree config (Trellis-specific)
+└── .gitignore           # Git ignore rules (dogfooded)
+```
+
+---
+
+## Dogfooding Architecture
+
+### What is Dogfooded
+
+Files that are copied directly from Trellis project to user projects:
+
+| Source | Destination | Description |
+|--------|-------------|-------------|
+| `.cursor/` | `.cursor/` | Entire directory copied |
+| `.claude/` | `.claude/` | Entire directory copied |
+| `.trellis/scripts/` | `.trellis/scripts/` | All scripts copied |
+| `.trellis/workflow.md` | `.trellis/workflow.md` | Direct copy |
+| `.trellis/.gitignore` | `.trellis/.gitignore` | Direct copy |
+| `.trellis/workspace/index.md` | `.trellis/workspace/index.md` | Direct copy |
+
+### What is NOT Dogfooded
+
+Files that use generic templates (in `src/templates/`):
+
+| Template Source | Destination | Reason |
+|----------------|-------------|--------|
+| `src/templates/markdown/spec/**/*.md.txt` | `.trellis/spec/**/*.md` | User fills with project-specific content |
+| `src/templates/markdown/worktree.yaml.txt` | `.trellis/worktree.yaml` | Language-agnostic template |
+| `src/templates/markdown/init-agent.md` | `init-agent.md` | Project root file |
+| `src/templates/markdown/agents.md` | `AGENTS.md` | Project root file |
+
+### Build Process
+
+```bash
+# scripts/copy-templates.js copies dogfooding sources to dist/
+pnpm build
+
+# Result:
+dist/
+├── .cursor/           # From project root .cursor/
+├── .claude/           # From project root .claude/
+├── .trellis/          # From project root .trellis/ (filtered)
+│   ├── scripts/       # All scripts
+│   ├── workspace/
+│   │   └── index.md   # Only index.md, no developer subdirs
+│   ├── workflow.md
+│   ├── worktree.yaml
+│   └── .gitignore
+└── templates/         # From src/templates/ (no .ts files)
+    └── markdown/
+        └── spec/      # Generic templates
+```
+
+---
+
+## Module Organization
+
+### Layer Responsibilities
+
+| Layer | Directory | Responsibility |
+|-------|-----------|----------------|
+| CLI | `cli/` | Parse arguments, display help, call commands |
+| Commands | `commands/` | Implement CLI commands, orchestrate actions |
+| Configurators | `configurators/` | Copy/generate configuration for tools |
+| Templates | `templates/` | Extract template content, provide utilities |
+| Types | `types/` | TypeScript type definitions |
+| Utils | `utils/` | Reusable utility functions |
+| Constants | `constants/` | Shared constants (paths, names) |
+
+### Configurator Pattern
+
+Configurators use `cpSync` for direct directory copy (dogfooding):
+
+```typescript
+// configurators/cursor.ts
+export async function configureCursor(cwd: string): Promise<void> {
+  const sourcePath = getCursorSourcePath(); // dist/.cursor/ or .cursor/
+  const destPath = path.join(cwd, ".cursor");
+  cpSync(sourcePath, destPath, { recursive: true });
+}
+```
+
+### Template Extraction
+
+`extract.ts` provides utilities for reading dogfooded files:
+
+```typescript
+// Get path to .trellis/ (works in dev and production)
+getTrellisSourcePath(): string
+
+// Read file from .trellis/
+readTrellisFile(relativePath: string): string
+
+// Copy directory from .trellis/ with executable scripts
+copyTrellisDir(srcRelativePath: string, destPath: string, options?: { executable?: boolean }): void
+```
+
+---
+
+## Naming Conventions
+
+### Files and Directories
+
+| Convention | Example | Usage |
+|------------|---------|-------|
+| `kebab-case` | `file-writer.ts` | All TypeScript files |
+| `kebab-case` | `multi-agent/` | All directories |
+| `*.ts` | `init.ts` | TypeScript source files |
+| `*.md.txt` | `index.md.txt` | Template files for markdown |
+| `*.yaml.txt` | `worktree.yaml.txt` | Template files for yaml |
+
+### Why `.txt` Extension for Templates
+
+Templates use `.txt` extension to:
+- Prevent IDE markdown preview from rendering templates
+- Make clear these are template sources, not actual docs
+- Avoid confusion with actual markdown files
+
+---
+
+## DO / DON'T
+
+### DO
+
+- Dogfood from project's own config files when possible
+- Use `cpSync` for copying entire directories
+- Keep generic templates in `src/templates/markdown/`
+- Use `.md.txt` or `.yaml.txt` for template files
+- Update dogfooding sources (`.cursor/`, `.claude/`, `.trellis/scripts/`) when making changes
+- Always use `python3` explicitly when documenting script invocation (Windows compatibility)
+
+### DON'T
+
+- Don't hardcode file lists - copy entire directories instead
+- Don't duplicate content between templates and dogfooding sources
+- Don't put project-specific content in generic templates
+- Don't use dogfooding for spec/ (users fill these in)
+
+---
+
+## Design Decisions
+
+### Remote Template Download (giget)
+
+**Context**: Need to download GitHub subdirectories for remote template support.
+
+**Options Considered**:
+1. `degit` / `tiged` - Simple, but no programmatic API
+2. `giget` - TypeScript native, has programmatic API, used by Nuxt/UnJS
+3. Manual GitHub API - Too complex
+
+**Decision**: Use `giget` because:
+- TypeScript native with programmatic API
+- Supports GitHub subdirectory: `gh:user/repo/path/to/subdir`
+- Built-in caching for offline support
+- Actively maintained by UnJS ecosystem
+
+**Example**:
+```typescript
+import { downloadTemplate } from "giget";
+
+await downloadTemplate("gh:mindfold-ai/Trellis/marketplace/specs/electron-fullstack", {
+  dir: destDir,
+  preferOffline: true,
+});
+```
+
+### Directory Conflict Strategy (skip/overwrite/append)
+
+**Context**: When downloading remote templates, target directory may already exist.
+
+**Decision**: Three strategies with `skip` as default:
+- `skip` - Don't download if directory exists (safe default)
+- `overwrite` - Delete existing, download fresh
+- `append` - Only copy files that don't exist (merge)
+
+**Why**: giget doesn't support append natively, so we:
+1. Download to temp directory
+2. Walk and copy missing files only
+3. Clean up temp directory
+
+**Example**:
+```typescript
+// append strategy implementation
+const tempDir = path.join(os.tmpdir(), `trellis-template-${Date.now()}`);
+await downloadTemplate(source, { dir: tempDir });
+await copyMissing(tempDir, destDir);  // Only copy non-existing files
+await fs.promises.rm(tempDir, { recursive: true });
+```
+
+### Extensible Template Type Mapping
+
+**Context**: Currently only `spec` templates, but future needs `skill`, `command`, `full` types.
+
+**Decision**: Use type field + mapping table for extensibility:
+
+```typescript
+const INSTALL_PATHS: Record<string, string> = {
+  spec: ".trellis/spec",
+  skill: ".claude/skills",
+  command: ".claude/commands",
+  full: ".",  // Entire project root
+};
+
+// Usage: auto-detect install path from template type
+const destDir = INSTALL_PATHS[template.type] || INSTALL_PATHS.spec;
+```
+
+**Extensibility**: To add new template type:
+1. Add entry to `INSTALL_PATHS`
+2. Add templates to `index.json` with new type
+3. No code changes needed for download logic