@mindfoldhq/trellis 0.4.0 → 0.5.0-beta.10

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

@@ -1,29 +0,0 @@
-description = "Check if the code you just wrote follows the development guidelines"
-
-prompt = """
-Check if the code you just wrote follows the development guidelines.
-
-Execute these steps:
-
-1. **Identify changed files**:
-   ```bash
-   git diff --name-only HEAD
-   ```
-
-2. **Determine which spec modules apply** based on the changed file paths:
-   ```bash
-   python3 ./.trellis/scripts/get_context.py --mode packages
-   ```
-
-3. **Read the spec index** for each relevant module:
-   ```bash
-   cat .trellis/spec/<package>/<layer>/index.md
-   ```
-   Follow the **"Quality Check"** section in the index.
-
-4. **Read the specific guideline files** referenced in the Quality Check section (e.g., `quality-guidelines.md`, `conventions.md`). The index is NOT the goal -> it points you to the actual guideline files. Read those files and review your code against them.
-
-5. **Run lint and typecheck** for the affected package.
-
-6. **Report any violations** and fix them if found.
-"""

package/dist/templates/gemini/commands/trellis/create-command.toml

@@ -1,119 +0,0 @@
-description = "Create a new slash command in the Gemini CLI commands directory"
-
-prompt = """
-# Create New Slash Command
-
-Create a new slash command in `.gemini/commands/trellis/` directory based on user requirements.
-
-## Usage
-
-```
-/trellis:create-command <command-name> <description>
-```
-
-**Example**:
-```
-/trellis:create-command review-pr Check PR code changes against project guidelines
-```
-
-## Execution Steps
-
-### 1. Parse Input
-
-Extract from user input:
-- **Command name**: Use kebab-case (e.g., `review-pr`)
-- **Description**: What the command should accomplish
-
-### 2. Analyze Requirements
-
-Determine command type based on description:
-- **Initialization**: Read docs, establish context
-- **Pre-development**: Read guidelines, check dependencies
-- **Code check**: Validate code quality and guideline compliance
-- **Recording**: Record progress, questions, structure changes
-- **Generation**: Generate docs, code templates
-
-### 3. Generate Command Content
-
-Based on command type, generate appropriate TOML content:
-
-**Simple command**:
-```toml
-description = "Short description"
-
-prompt = \"\"\"
-Concise instruction describing what to do
-\"\"\"
-```
-
-**Complex command** (with steps):
-```toml
-description = "Short description"
-
-prompt = \"\"\"
-# Command Title
-
-Command description
-
-## Steps
-
-### 1. First Step
-Specific action
-
-### 2. Second Step
-Specific action
-
-## Output Format (if needed)
-
-Template
-\"\"\"
-```
-
-### 4. Create File
-
-Create the TOML file:
-- `.gemini/commands/trellis/<command-name>.toml`
-
-### 5. Confirm Creation
-
-Output result:
-```
-[OK] Created Slash Command: /trellis:<command-name>
-
-File path:
-- .gemini/commands/trellis/<command-name>.toml
-
-Usage:
-/trellis:<command-name>
-
-Description:
-<description>
-```
-
-## Command Content Guidelines
-
-### [OK] Good command content
-
-1. **Clear and concise**: Immediately understandable
-2. **Executable**: AI can follow steps directly
-3. **Well-scoped**: Clear boundaries of what to do and not do
-4. **Has output**: Specifies expected output format (if needed)
-
-### [X] Avoid
-
-1. **Too vague**: e.g., "optimize code"
-2. **Too complex**: Single command should not exceed 100 lines
-3. **Duplicate functionality**: Check if similar command exists first
-
-## Naming Conventions
-
-| Command Type | Prefix | Example |
-|--------------|--------|---------|
-| Session Start | `start` | `start` |
-| Pre-development | `before-` | `before-dev` |
-| Check | `check-` | `check` |
-| Record | `record-` | `record-session` |
-| Generate | `generate-` | `generate-api-doc` |
-| Update | `update-` | `update-changelog` |
-| Other | Verb-first | `review-code`, `sync-data` |
-"""

package/dist/templates/gemini/commands/trellis/finish-work.toml

@@ -1,133 +0,0 @@
-description = "Pre-commit checklist to ensure work completeness before submitting"
-
-prompt = """
-# Finish Work - Pre-Commit Checklist
-
-Before submitting or committing, use this checklist to ensure work completeness.
-
-**Timing**: After code is written and tested, before commit
-
----
-
-## Checklist
-
-### 1. Code Quality
-
-```bash
-# Must pass
-pnpm lint
-pnpm type-check
-pnpm test
-```
-
-- [ ] `pnpm lint` passes with 0 errors?
-- [ ] `pnpm type-check` passes with no type errors?
-- [ ] Tests pass?
-- [ ] No `console.log` statements (use logger)?
-- [ ] No non-null assertions (the `x!` operator)?
-- [ ] No `any` types?
-
-### 2. Documentation Sync
-
-**Structure Docs**:
-- [ ] Does `.trellis/spec/backend/` need updates?
-  - New patterns, new modules, new conventions
-- [ ] Does `.trellis/spec/frontend/` need updates?
-  - New components, new hooks, new patterns
-- [ ] Does `.trellis/spec/guides/` need updates?
-  - New cross-layer flows, lessons from bugs
-
-**Key Question**:
-> "If I fixed a bug or discovered something non-obvious, should I document it so future me (or others) won't hit the same issue?"
-
-If YES -> Update the relevant spec doc.
-
-### 3. API Changes
-
-If you modified API endpoints:
-
-- [ ] Input schema updated?
-- [ ] Output schema updated?
-- [ ] API documentation updated?
-- [ ] Client code updated to match?
-
-### 4. Database Changes
-
-If you modified database schema:
-
-- [ ] Migration file created?
-- [ ] Schema file updated?
-- [ ] Related queries updated?
-- [ ] Seed data updated (if applicable)?
-
-### 5. Cross-Layer Verification
-
-If the change spans multiple layers:
-
-- [ ] Data flows correctly through all layers?
-- [ ] Error handling works at each boundary?
-- [ ] Types are consistent across layers?
-- [ ] Loading states handled?
-
-### 6. Manual Testing
-
-- [ ] Feature works in browser/app?
-- [ ] Edge cases tested?
-- [ ] Error states tested?
-- [ ] Works after page refresh?
-
----
-
-## Quick Check Flow
-
-```bash
-# 1. Code checks
-pnpm lint && pnpm type-check
-
-# 2. View changes
-git status
-git diff --name-only
-
-# 3. Based on changed files, check relevant items above
-```
-
----
-
-## Common Oversights
-
-| Oversight | Consequence | Check |
-|-----------|-------------|-------|
-| Structure docs not updated | Others don't know the change | Check .trellis/spec/ |
-| Migration not created | Schema out of sync | Check db/migrations/ |
-| Types not synced | Runtime errors | Check shared types |
-| Tests not updated | False confidence | Run full test suite |
-| Console.log left in | Noisy production logs | Search for console.log |
-
----
-
-## Relationship to Other Commands
-
-```
-Development Flow:
-  Write code -> Test -> /trellis:finish-work -> git commit -> /trellis:record-session
-                          |                              |
-                   Ensure completeness              Record progress
-
-Debug Flow:
-  Hit bug -> Fix -> /trellis:break-loop -> Knowledge capture
-                       |
-                  Deep analysis
-```
-
-- `/trellis:finish-work` - Check work completeness (this command)
-- `/trellis:record-session` - Record session and commits
-- `/trellis:break-loop` - Deep analysis after debugging
-
----
-
-## Core Principle
-
-> **Delivery includes not just code, but also documentation, verification, and knowledge capture.**
-
-Complete work = Code + Docs + Tests + Verification
-"""

package/dist/templates/gemini/commands/trellis/integrate-skill.toml

@@ -1,104 +0,0 @@
-description = "Adapt and integrate an external skill into project development guidelines"
-
-prompt = """
-# Integrate Skill into Project Guidelines
-
-Adapt and integrate an external skill into your project's development guidelines (not directly into project code).
-
-## Usage
-
-```
-/trellis:integrate-skill <skill-name>
-```
-
-**Examples**:
-```
-/trellis:integrate-skill frontend-design
-/trellis:integrate-skill mcp-builder
-```
-
-## Core Principle
-
-> [!] **Important**: The goal of skill integration is to update **development guidelines**, not to generate project code directly.
->
-> - Guidelines content -> Write to `.trellis/spec/{target}/doc.md`
-> - Code examples -> Place in `.trellis/spec/{target}/examples/skills/<skill-name>/`
-> - Example files -> Use `.template` suffix (e.g., `component.tsx.template`) to avoid IDE errors
->
-> Where `{target}` is `frontend` or `backend`, determined by skill type.
-
-## Execution Steps
-
-### 1. Read Skill Content
-
-Locate and read the skill definition. If the skill doesn't exist, prompt user to check available skills.
-
-### 2. Determine Integration Target
-
-Based on skill type, determine which guidelines to update:
-
-| Skill Category | Integration Target |
-|----------------|-------------------|
-| UI/Frontend (`frontend-design`, `web-artifacts-builder`) | `.trellis/spec/frontend/` |
-| Backend/API (`mcp-builder`) | `.trellis/spec/backend/` |
-| Documentation (`doc-coauthoring`, `docx`, `pdf`) | `.trellis/` or create dedicated guidelines |
-| Testing (`webapp-testing`) | `.trellis/spec/frontend/` (E2E) |
-
-### 3. Analyze Skill Content
-
-Extract from the skill:
-- **Core concepts**: How the skill works and key concepts
-- **Best practices**: Recommended approaches
-- **Code patterns**: Reusable code templates
-- **Caveats**: Common issues and solutions
-
-### 4. Execute Integration
-
-#### 4.1 Update Guidelines Document
-
-Add a new section to the corresponding `doc.md`.
-
-#### 4.2 Create Examples Directory (if code examples exist)
-
-```bash
-# Directory structure ({target} = frontend or backend)
-.trellis/spec/{target}/
-|-- doc.md                      # Add skill-related section
-|-- index.md                    # Update index
-+-- examples/
-    +-- skills/
-        +-- <skill-name>/
-            |-- README.md               # Example documentation
-            |-- example-1.ts.template   # Code example (use .template suffix)
-            +-- example-2.tsx.template
-```
-
-**File naming conventions**:
-- Code files: `<name>.<ext>.template` (e.g., `component.tsx.template`)
-- Config files: `<name>.config.template` (e.g., `tailwind.config.template`)
-- Documentation: `README.md` (normal suffix)
-
-#### 4.3 Update Index File
-
-Add to the Quick Navigation table in `index.md`.
-
-### 5. Generate Integration Report
-
-Report:
-- Skill description and integration target
-- Tech stack compatibility
-- Integration locations (files modified)
-- Dependencies needed (if any)
-- Completed changes checklist
-
----
-
-## Common Skill Integration Reference
-
-| Skill | Integration Target | Examples Directory |
-|-------|-------------------|-------------------|
-| `frontend-design` | `frontend` | `examples/skills/frontend-design/` |
-| `mcp-builder` | `backend` | `examples/skills/mcp-builder/` |
-| `webapp-testing` | `frontend` | `examples/skills/webapp-testing/` |
-| `doc-coauthoring` | `.trellis/` | N/A (documentation workflow only) |
-"""

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

@@ -1,111 +0,0 @@
-description = "Onboard a new team member to the Trellis AI-assisted workflow system"
-
-prompt = """
-You are a senior developer onboarding a new team member to this project's AI-assisted workflow system.
-
-YOUR ROLE: Be a mentor and teacher. Don't just list steps - EXPLAIN the underlying principles, why each command exists, what problem it solves at a fundamental level.
-
-## CRITICAL INSTRUCTION - YOU MUST COMPLETE ALL SECTIONS
-
-This onboarding has THREE equally important parts:
-
-**PART 1: Core Concepts** (Sections: CORE PHILOSOPHY, SYSTEM STRUCTURE, COMMAND DEEP DIVE)
-- Explain WHY this workflow exists
-- Explain WHAT each command does and WHY
-
-**PART 2: Real-World Examples** (Section: REAL-WORLD WORKFLOW EXAMPLES)
-- Walk through ALL 5 examples in detail
-- For EACH step in EACH example, explain:
-  - PRINCIPLE: Why this step exists
-  - WHAT HAPPENS: What the command actually does
-  - IF SKIPPED: What goes wrong without it
-
-**PART 3: Customize Your Development Guidelines** (Section: CUSTOMIZE YOUR DEVELOPMENT GUIDELINES)
-- Check if project guidelines are still empty templates
-- If empty, guide the developer to fill them with project-specific content
-- Explain the customization workflow
-
-DO NOT skip any part. All three parts are essential.
-
-After completing ALL THREE parts, ask the developer about their first task.
-
----
-
-## CORE PHILOSOPHY: Why This Workflow Exists
-
-AI-assisted development has three fundamental challenges:
-
-### Challenge 1: AI Has No Memory
-
-Every AI session starts with a blank slate. The `.trellis/workspace/` system captures what happened in each session. The `/trellis:start` command reads this history at session start, giving AI "artificial memory."
-
-### Challenge 2: AI Has Generic Knowledge, Not Project-Specific Knowledge
-
-The `.trellis/spec/` directory contains project-specific guidelines. The `/before-*-dev` commands inject this specialized knowledge into AI context before coding starts.
-
-### Challenge 3: AI Context Window Is Limited
-
-The `/check-*` commands re-verify code against guidelines AFTER writing, catching drift that occurred during development. The `/trellis:finish-work` command does a final holistic review.
-
----
-
-## SYSTEM STRUCTURE
-
-```
-.trellis/
-|-- .developer              # Your identity (gitignored)
-|-- workflow.md             # Complete workflow documentation
-|-- workspace/              # "AI Memory" - session history
-|-- tasks/                  # Task tracking (unified)
-|-- spec/                   # "AI Training Data" - project knowledge
-|   |-- frontend/           # Frontend conventions
-|   |-- backend/            # Backend conventions
-|   +-- guides/             # Thinking patterns
-+-- scripts/                # Automation tools
-```
-
----
-
-## COMMAND DEEP DIVE
-
-### /trellis:start - Restore AI Memory
-### /trellis:before-dev - Inject Specialized Knowledge
-### /trellis:check - Combat Context Drift
-### /trellis:check-cross-layer - Multi-Dimension Verification
-### /trellis:finish-work - Holistic Pre-Commit Review
-### /trellis:record-session - Persist Memory for Future
-
----
-
-## REAL-WORLD WORKFLOW EXAMPLES
-
-### Example 1: Bug Fix Session
-### Example 2: Planning Session (No Code)
-### Example 3: Code Review Fixes
-### Example 4: Large Refactoring
-### Example 5: Debug Session
-
-Walk through each example explaining every step.
-
----
-
-## KEY RULES TO EMPHASIZE
-
-1. **AI NEVER commits** - Human tests and approves. AI prepares, human validates.
-2. **Guidelines before code** - /before-*-dev commands inject project knowledge.
-3. **Check after code** - /check-* commands catch context drift.
-4. **Record everything** - /trellis:record-session persists memory.
-
----
-
-# PART 3: Customize Your Development Guidelines
-
-Check if `.trellis/spec/` contains empty templates or customized guidelines:
-
-```bash
-grep -l "To be filled by the team" .trellis/spec/backend/*.md 2>/dev/null | wc -l
-grep -l "To be filled by the team" .trellis/spec/frontend/*.md 2>/dev/null | wc -l
-```
-
-If empty templates, guide filling them. If already customized, proceed with first task.
-"""

package/dist/templates/gemini/commands/trellis/record-session.toml

@@ -1,66 +0,0 @@
-description = "Record work progress after human has tested and committed code"
-
-prompt = """
-[!] **Prerequisite**: This command should only be used AFTER the human has tested and committed the code.
-
-**Do NOT run `git commit` directly** — the scripts below handle their own commits for `.trellis/` metadata. You only need to read git history (`git log`, `git status`, `git diff`) and run the Python scripts.
-
----
-
-## Record Work Progress
-
-### Step 1: Get Context & Check Tasks
-
-```bash
-python3 ./.trellis/scripts/get_context.py --mode record
-```
-
-[!] 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>
-```
-
-### Step 2: One-Click Add Session
-
-```bash
-# Method 1: Simple parameters
-python3 ./.trellis/scripts/add_session.py \\
-  --title "Session Title" \\
-  --commit "hash1,hash2" \\
-  --summary "Brief summary of what was done"
-
-# Method 2: Pass detailed content via stdin
-cat << 'EOF' | python3 ./.trellis/scripts/add_session.py --stdin --title "Title" --commit "hash"
-| Feature | Description |
-|---------|-------------|
-| New API | Added user authentication endpoint |
-| Frontend | Updated login form |
-
-**Updated Files**:
-- `packages/api/modules/auth/router.ts`
-- `apps/web/modules/auth/components/login-form.tsx`
-EOF
-```
-
-**Auto-completes**:
-- [OK] Appends session to journal-N.md
-- [OK] Auto-detects line count, creates new file if >2000 lines
-- [OK] Auto-detects Branch context (`--branch` override; otherwise Branch = task.json -> current git branch; missing values are omitted gracefully)
-- [OK] Updates index.md (Total Sessions +1, Last Active, line stats, history)
-- [OK] Auto-commits .trellis/workspace and .trellis/tasks changes
-
----
-
-## Script Command Reference
-
-| Command | Purpose |
-|---------|---------|
-| `python3 ./.trellis/scripts/get_context.py --mode record` | Get context for record-session |
-| `python3 ./.trellis/scripts/add_session.py --title "..." --commit "..."` | **One-click add session (recommended, branch auto-complete)** |
-| `python3 ./.trellis/scripts/task.py archive <name>` | Archive completed task (auto-commits) |
-| `python3 ./.trellis/scripts/task.py list` | List active tasks |
-"""