@mindfoldhq/trellis 0.4.0 → 0.5.0-beta.1

package/dist/templates/gemini/commands/trellis/start.toml

@@ -1,354 +0,0 @@
-description = "Initialize your AI development session and begin working on tasks"
-
-prompt = """
-# Start Session
-
-Initialize your AI development session and begin working on tasks.
-
----
-
-## Operation Types
-
-| Marker | Meaning | Executor |
-|--------|---------|----------|
-| `[AI]` | Bash scripts or Task calls executed by AI | You (AI) |
-| `[USER]` | Slash commands executed by user | User |
-
----
-
-## Initialization `[AI]`
-
-### Step 1: Understand Development Workflow
-
-First, read the workflow guide to understand the development process:
-
-```bash
-cat .trellis/workflow.md
-```
-
-**Follow the instructions in workflow.md** - it contains:
-- Core principles (Read Before Write, Follow Standards, etc.)
-- File system structure
-- Development process
-- Best practices
-
-### Step 2: Get Current Context
-
-```bash
-python3 ./.trellis/scripts/get_context.py
-```
-
-This shows: developer identity, git status, current task (if any), active tasks.
-
-### Step 3: Read Guidelines Index
-
-```bash
-python3 ./.trellis/scripts/get_context.py --mode packages
-```
-
-This shows available packages and their spec layers. Read the relevant spec indexes:
-
-```bash
-cat .trellis/spec/<package>/<layer>/index.md   # Package-specific guidelines
-cat .trellis/spec/guides/index.md              # Thinking guides (always read)
-```
-
-> **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?"
-
----
-
-## Task Classification
-
-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 | 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 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.
-
----
-
-## Question / Trivial Fix
-
-For questions or trivial fixes, work directly:
-
-1. Answer question or make the fix
-2. If code was changed, remind user to run `/trellis:finish-work`
-
----
-
-## 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?**
-- Research Agent analyzes what specs are needed
-- Specs are configured in jsonl files
-- Implement Agent receives specs via Hook injection
-- Check Agent verifies against specs
-- Result: Code that follows project conventions automatically
-
-### Overview: Two Entry Points
-
-```
-From Brainstorm (Complex Task):
-  PRD confirmed -> Research -> Configure Context -> Activate -> Implement -> Check -> Complete
-
-From Simple Task:
-  Confirm -> Create Task -> Write PRD -> Research -> Configure Context -> Activate -> Implement -> Check -> Complete
-```
-
-**Key principle: Research happens AFTER requirements are clear (PRD exists).**
-
----
-
-### Phase 1: Establish Requirements
-
-#### Path A: From Brainstorm (skip to Phase 2)
-
-PRD and task directory already exist from brainstorm. Skip directly to Phase 2.
-
-#### Path B: From Simple Task
-
-**Step 1: Confirm Understanding** `[AI]`
-
-Quick confirm:
-- What is the goal?
-- What type of development? (frontend / backend / fullstack)
-- Any specific requirements or constraints?
-
-**Step 2: Create Task Directory** `[AI]`
-
-```bash
-TASK_DIR=$(python3 ./.trellis/scripts/task.py create "<title>" --slug <name>)
-```
-
-**Step 3: Write PRD** `[AI]`
-
-Create `prd.md` in the task directory with:
-
-```markdown
-# <Task Title>
-
-## Goal
-<What we're trying to achieve>
-
-## Requirements
-- <Requirement 1>
-- <Requirement 2>
-
-## Acceptance Criteria
-- [ ] <Criterion 1>
-- [ ] <Criterion 2>
-
-## Technical Notes
-<Any technical decisions or constraints>
-```
-
----
-
-### Phase 2: Prepare for Implementation (shared)
-
-> Both paths converge here. PRD and task directory must exist before proceeding.
-
-**Step 4: Code-Spec Depth Check** `[AI]`
-
-If the task touches infra or cross-layer contracts, do not start implementation until code-spec depth is defined.
-
-Trigger this requirement when the change includes any of:
-- New or changed command/API signatures
-- Database schema or migration changes
-- Infra integrations (storage, queue, cache, secrets, env contracts)
-- Cross-layer payload transformations
-
-Must-have before proceeding:
-- [ ] Target spec files to update are identified
-- [ ] Concrete contract is defined (signature, fields, env keys)
-- [ ] Validation and error matrix is defined
-- [ ] At least one Good/Base/Bad case is defined
-
-**Step 5: Research the Codebase** `[AI]`
-
-Based on the confirmed PRD, run a focused research pass and produce:
-
-1. Relevant spec files in `.trellis/spec/`
-2. Existing code patterns to follow (2-3 examples)
-3. Files that will likely need modification
-
-Use this output format:
-
-```markdown
-## Relevant Specs
-- <path>: <why it's relevant>
-
-## Code Patterns Found
-- <pattern>: <example file path>
-
-## Files to Modify
-- <path>: <what change>
-```
-
-**Step 6: Configure Context** `[AI]`
-
-Initialize default context:
-
-```bash
-python3 ./.trellis/scripts/task.py init-context "$TASK_DIR" <type>
-# type: backend | frontend | fullstack
-```
-
-Add specs found in your research pass:
-
-```bash
-# For each relevant spec and code pattern:
-python3 ./.trellis/scripts/task.py add-context "$TASK_DIR" implement "<path>" "<reason>"
-python3 ./.trellis/scripts/task.py add-context "$TASK_DIR" check "<path>" "<reason>"
-```
-
-**Step 7: Activate Task** `[AI]`
-
-```bash
-python3 ./.trellis/scripts/task.py start "$TASK_DIR"
-```
-
-This sets `.current-task` so hooks can inject context.
-
----
-
-### Phase 3: Execute (shared)
-
-**Step 8: Implement** `[AI]`
-
-Implement the task described in `prd.md`.
-
-- Follow all specs injected into implement context
-- Keep changes scoped to requirements
-- Run lint and typecheck before finishing
-
-**Step 9: Check Quality** `[AI]`
-
-Run a quality pass against check context:
-
-- Review all code changes against the specs
-- Fix issues directly
-- Ensure lint and typecheck pass
-
-**Step 10: Complete** `[AI]`
-
-1. Verify lint and typecheck pass
-2. Report what was implemented
-3. Remind user to:
-   - Test the changes
-   - Commit when ready
-   - Run `/trellis:record-session` to record this session
-
----
-
-## Continuing Existing Task
-
-If `get_context.py` shows a current task:
-
-1. Read the task's `prd.md` to understand the goal
-2. Check `task.json` for current status and phase
-3. Ask user: "Continue working on <task-name>?"
-
-If yes, resume from the appropriate step (usually Step 7 or 8).
-
----
-
-## Commands Reference
-
-### User Commands `[USER]`
-
-| Command | When to Use |
-|---------|-------------|
-| `/trellis:start` | Begin a session (this command) |
-| `/trellis:finish-work` | Before committing changes |
-| `/trellis:record-session` | After completing a task |
-
-### AI Scripts `[AI]`
-
-| Script | Purpose |
-|--------|---------|
-| `python3 ./.trellis/scripts/get_context.py` | Get session context |
-| `python3 ./.trellis/scripts/task.py create` | Create task directory |
-| `python3 ./.trellis/scripts/task.py init-context` | Initialize jsonl files |
-| `python3 ./.trellis/scripts/task.py add-context` | Add spec to jsonl |
-| `python3 ./.trellis/scripts/task.py start` | Set current task |
-| `python3 ./.trellis/scripts/task.py finish` | Clear current task |
-| `python3 ./.trellis/scripts/task.py archive` | Archive completed task |
-
----
-
-## Key Principle
-
-> **Specs are injected, not remembered.**
->
-> The Task Workflow ensures agents receive relevant specs automatically.
-> This is more reliable than hoping the AI "remembers" conventions.
-"""

package/dist/templates/gemini/commands/trellis/update-spec.toml

@@ -1,132 +0,0 @@
-description = "Capture knowledge into spec documents after learning something valuable"
-
-prompt = """
-# Update Spec - Capture Knowledge into Specifications
-
-When you learn something valuable (from debugging, implementing, or discussion), use this command to update the relevant spec documents.
-
-**Timing**: After completing a task, fixing a bug, or discovering a new pattern
-
----
-
-## When to Update Specs
-
-| Trigger | Example | Target Spec |
-|---------|---------|-------------|
-| **Implemented a feature** | Added template download with giget | Relevant `backend/` or `frontend/` file |
-| **Made a design decision** | Used type field + mapping table for extensibility | Relevant spec + "Design Decisions" section |
-| **Fixed a bug** | Found a subtle issue with error handling | `backend/error-handling.md` |
-| **Discovered a pattern** | Found a better way to structure code | Relevant `backend/` or `frontend/` file |
-| **Hit a gotcha** | Learned that X must be done before Y | Relevant spec + "Common Mistakes" section |
-| **Established a convention** | Team agreed on naming pattern | `quality-guidelines.md` |
-| **New thinking trigger** | "Don't forget to check X before doing Y" | `guides/*.md` (as a checklist item, not detailed rules) |
-
----
-
-## Spec Structure Overview
-
-```
-.trellis/spec/
-+-- backend/           # Backend coding standards
-|   +-- index.md       # Overview and links
-|   +-- *.md           # Topic-specific guidelines
-+-- frontend/          # Frontend coding standards
-|   +-- index.md       # Overview and links
-|   +-- *.md           # Topic-specific guidelines
-+-- guides/            # Thinking checklists (NOT coding specs!)
-    +-- index.md       # Guide index
-    +-- *.md           # Topic-specific guides
-```
-
-### CRITICAL: Spec vs Guide - Know the Difference
-
-| Type | Location | Purpose | Content Style |
-|------|----------|---------|---------------|
-| **Spec** | `backend/*.md`, `frontend/*.md` | Tell AI "how to write code" | Detailed rules, code examples, forbidden patterns |
-| **Guide** | `guides/*.md` | Help AI "what to think about" | Checklists, questions, pointers to specs |
-
-**Decision Rule**: Ask yourself:
-
-- "This is **how to write** the code" -> Put in `backend/` or `frontend/`
-- "This is **what to consider** before writing" -> Put in `guides/`
-
----
-
-## Update Process
-
-### Step 1: Identify What You Learned
-
-Answer these questions:
-
-1. **What did you learn?** (Be specific)
-2. **Why is it important?** (What problem does it prevent?)
-3. **Where does it belong?** (Which spec file?)
-
-### Step 2: Classify the Update Type
-
-| Type | Description | Action |
-|------|-------------|--------|
-| **Design Decision** | Why we chose approach X over Y | Add to "Design Decisions" section |
-| **Project Convention** | How we do X in this project | Add to relevant section with examples |
-| **New Pattern** | A reusable approach discovered | Add to "Patterns" section |
-| **Forbidden Pattern** | Something that causes problems | Add to "Anti-patterns" or "Don't" section |
-| **Common Mistake** | Easy-to-make error | Add to "Common Mistakes" section |
-| **Convention** | Agreed-upon standard | Add to relevant section |
-| **Gotcha** | Non-obvious behavior | Add warning callout |
-
-### Step 3: Read the Target Spec
-
-Before editing, read the current spec to:
-- Understand existing structure
-- Avoid duplicating content
-- Find the right section for your update
-
-```bash
-cat .trellis/spec/<category>/<file>.md
-```
-
-### Step 4: Make the Update
-
-Follow these principles:
-
-1. **Be Specific**: Include concrete examples, not just abstract rules
-2. **Explain Why**: State the problem this prevents
-3. **Show Code**: Add code snippets for patterns
-4. **Keep it Short**: One concept per section
-
-### Step 5: Update the Index (if needed)
-
-If you added a new section or the spec status changed, update the category's `index.md`.
-
----
-
-## Quality Checklist
-
-Before finishing your spec update:
-
-- [ ] Is the content specific and actionable?
-- [ ] Did you include a code example?
-- [ ] Did you explain WHY, not just WHAT?
-- [ ] Is it in the right spec file?
-- [ ] Does it duplicate existing content?
-- [ ] Would a new team member understand it?
-
----
-
-## Relationship to Other Commands
-
-- `/trellis:break-loop` - Analyzes bugs deeply, often reveals spec updates needed
-- `/trellis:update-spec` - Actually makes the updates (this command)
-- `/trellis:finish-work` - Reminds you to check if specs need updates
-
----
-
-## Core Philosophy
-
-> **Specs are living documents. Every debugging session, every "aha moment" is an opportunity to make the spec better.**
-
-The goal is **institutional memory**:
-- What one person learns, everyone benefits from
-- What AI learns in one session, persists to future sessions
-- Mistakes become documented guardrails
-"""

package/dist/templates/iflow/agents/debug.md

@@ -1,106 +0,0 @@
----
-name: debug
-description: |
-  Issue fixing expert. Understands issues, fixes against specs, and verifies fixes. Precise fixes only.
-tools: Read, Write, Edit, Bash, Glob, Grep, mcp__exa__web_search_exa, mcp__exa__get_code_context_exa
-color: red
----
-# Debug Agent
-
-You are the Debug Agent in the Trellis workflow.
-
-## Context
-
-Before debugging, read:
-- `.trellis/spec/` - Development guidelines
-- Error messages or issue descriptions provided
-
-## Core Responsibilities
-
-1. **Understand issues** - Analyze error messages or reported issues
-2. **Fix against specs** - Fix issues following dev specs
-3. **Verify fixes** - Run typecheck to ensure no new issues
-4. **Report results** - Report fix status
-
----
-
-## Workflow
-
-### Step 1: Understand Issues
-
-Parse the issue, categorize by priority:
-
-- `[P1]` - Must fix (blocking)
-- `[P2]` - Should fix (important)
-- `[P3]` - Optional fix (nice to have)
-
-### Step 2: Research if Needed
-
-If you need additional info:
-
-```bash
-# Check knowledge base
-ls .trellis/big-question/
-```
-
-### Step 3: Fix One by One
-
-For each issue:
-
-1. Locate the exact position
-2. Fix following specs
-3. Run typecheck to verify
-
-### Step 4: Verify
-
-Run project's lint and typecheck commands to verify fixes.
-
-If fix introduces new issues:
-
-1. Revert the fix
-2. Use a more complete solution
-3. Re-verify
-
----
-
-## Report Format
-
-```markdown
-## Fix Report
-
-### Issues Fixed
-
-1. `[P1]` `<file>:<line>` - <what was fixed>
-2. `[P2]` `<file>:<line>` - <what was fixed>
-
-### Issues Not Fixed
-
-- `<file>:<line>` - <reason why not fixed>
-
-### Verification
-
-- TypeCheck: Pass
-- Lint: Pass
-
-### Summary
-
-Fixed X/Y issues. Z issues require discussion.
-```
-
----
-
-## Guidelines
-
-### DO
-
-- Precise fixes for reported issues
-- Follow specs
-- Verify each fix
-
-### DON'T
-
-- Don't refactor surrounding code
-- Don't add new features
-- Don't modify unrelated files
-- Don't use non-null assertion (`x!` operator)
-- Don't execute git commit