@mindfoldhq/trellis 0.3.10-beta.0 → 0.3.10

package/dist/templates/kilo/workflows/check-frontend.md

@@ -0,0 +1,13 @@
+Check if the code you just wrote follows the frontend development guidelines.
+
+Execute these steps:
+1. Run `git status` to see modified files
+2. Read `.trellis/spec/frontend/index.md` to understand which guidelines apply
+3. Based on what you changed, read the relevant guideline files:
+   - Component changes → `.trellis/spec/frontend/component-guidelines.md`
+   - Hook changes → `.trellis/spec/frontend/hook-guidelines.md`
+   - State changes → `.trellis/spec/frontend/state-management.md`
+   - Type changes → `.trellis/spec/frontend/type-safety.md`
+   - Any changes → `.trellis/spec/frontend/quality-guidelines.md`
+4. Review your code against the guidelines
+5. Report any violations and fix them if found

package/dist/templates/kilo/workflows/create-command.md

@@ -99,8 +99,8 @@ Description:
 | Command Type | Prefix | Example |
 |--------------|--------|---------|
 | Session Start | `start` | `start` |
-| Pre-development | `before-` | `before-dev` |
-| Check | `check-` | `check` |
+| Pre-development | `before-` | `before-frontend-dev` |
+| Check | `check-` | `check-frontend` |
 | Record | `record-` | `record-session` |
 | Generate | `generate-` | `generate-api-doc` |
 | Update | `update-` | `update-changelog` |

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

@@ -126,13 +126,13 @@ AI needs the same onboarding - but compressed into seconds at session start.
 
 ---
 
-### /trellis:before-dev - Inject Specialized Knowledge
+### /trellis:before-frontend-dev and /trellis:before-backend-dev - Inject Specialized Knowledge
 
 **WHY IT EXISTS**:
 AI models have "pre-trained knowledge" - general patterns from millions of codebases. But YOUR project has specific conventions that differ from generic patterns.
 
 **WHAT IT ACTUALLY DOES**:
-1. Discovers spec layers via `get_context.py --mode packages` and reads relevant guidelines
+1. Reads `.trellis/spec/frontend/` or `.trellis/spec/backend/`
 2. Loads project-specific patterns into AI's working context:
    - Component naming conventions
    - State management patterns
@@ -140,12 +140,12 @@ AI models have "pre-trained knowledge" - general patterns from millions of codeb
    - Error handling standards
 
 **WHY THIS MATTERS**:
-- Without before-dev: AI writes generic code that doesn't match project style.
-- With before-dev: AI writes code that looks like the rest of the codebase.
+- Without before-*-dev: AI writes generic code that doesn't match project style.
+- With before-*-dev: AI writes code that looks like the rest of the codebase.
 
 ---
 
-### /trellis:check - Combat Context Drift
+### /trellis:check-frontend and /trellis:check-backend - Combat Context Drift
 
 **WHY IT EXISTS**:
 AI context window has limited capacity. As conversation progresses, guidelines injected at session start become less influential. This causes "context drift."
@@ -211,9 +211,9 @@ All the context AI built during this session will be lost when session ends. The
 
 **[1/8] /trellis:start** - AI needs project context before touching code
 **[2/8] python3 ./.trellis/scripts/task.py create "Fix bug" --slug fix-bug** - Track work for future reference
-**[3/8] /trellis:before-dev** - Inject project-specific development guidelines
+**[3/8] /trellis:before-frontend-dev** - Inject project-specific frontend knowledge
 **[4/8] Investigate and fix the bug** - Actual development work
-**[5/8] /trellis:check** - Re-verify code against guidelines
+**[5/8] /trellis:check-frontend** - Re-verify code against guidelines
 **[6/8] /trellis:finish-work** - Holistic cross-layer review
 **[7/8] Human tests and commits** - Human validates before code enters repo
 **[8/8] /trellis:record-session** - Persist memory for future sessions
@@ -228,9 +228,9 @@ All the context AI built during this session will be lost when session ends. The
 ### Example 3: Code Review Fixes
 
 **[1/6] /trellis:start** - Resume context from previous session
-**[2/6] /trellis:before-dev** - Re-inject guidelines before fixes
+**[2/6] /trellis:before-backend-dev** - Re-inject guidelines before fixes
 **[3/6] Fix each CR issue** - Address feedback with guidelines in context
-**[4/6] /trellis:check** - Verify fixes did not introduce new issues
+**[4/6] /trellis:check-backend** - Verify fixes didn't introduce new issues
 **[5/6] /trellis:finish-work** - Document lessons from CR
 **[6/6] Human commits, then /trellis:record-session** - Preserve CR lessons
 
@@ -238,16 +238,16 @@ All the context AI built during this session will be lost when session ends. The
 
 **[1/5] /trellis:start** - Clear baseline before major changes
 **[2/5] Plan phases** - Break into verifiable chunks
-**[3/5] Execute phase by phase with /trellis:check after each** - Incremental verification
+**[3/5] Execute phase by phase with /check-* after each** - Incremental verification
 **[4/5] /trellis:finish-work** - Check if new patterns should be documented
 **[5/5] Record with multiple commit hashes** - Link all commits to one feature
 
 ### Example 5: Debug Session
 
 **[1/6] /trellis:start** - See if this bug was investigated before
-**[2/6] /trellis:before-dev** - Guidelines might document known gotchas
+**[2/6] /trellis:before-backend-dev** - Guidelines might document known gotchas
 **[3/6] Investigation** - Actual debugging work
-**[4/6] /trellis:check** - Verify debug changes do not break other things
+**[4/6] /trellis:check-backend** - Verify debug changes don't break other things
 **[5/6] /trellis:finish-work** - Debug findings might need documentation
 **[6/6] Human commits, then /trellis:record-session** - Debug knowledge is valuable
 
@@ -256,7 +256,7 @@ All the context AI built during this session will be lost when session ends. The
 ## KEY RULES TO EMPHASIZE
 
 1. **AI NEVER commits** - Human tests and approves. AI prepares, human validates.
-2. **Guidelines before code** - /before-dev command injects project knowledge.
+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.
 

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

@@ -41,7 +41,8 @@ python3 ./.trellis/scripts/get_context.py
 ### Step 3: Read Project Guidelines `[AI]`
 
 ```bash
-python3 ./.trellis/scripts/get_context.py --mode packages  # Discover available spec layers
+cat .trellis/spec/frontend/index.md  # Frontend guidelines index
+cat .trellis/spec/backend/index.md   # Backend guidelines index
 cat .trellis/spec/guides/index.md    # Thinking guides
 ```
 

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

@@ -1,6 +1,6 @@
 [!] **Prerequisite**: This command should only be used AFTER the human has tested and committed the code.
 
-**AI must NOT execute git commit** - only read history (`git log`, `git status`, `git diff`).
+**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.
 
 ---
 
@@ -31,7 +31,7 @@ python3 ./.trellis/scripts/add_session.py \
   --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"
+cat << 'EOF' | python3 ./.trellis/scripts/add_session.py --title "Title" --commit "hash"
 | Feature | Description |
 |---------|-------------|
 | New API | Added user authentication endpoint |

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

@@ -40,14 +40,9 @@ 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)
+cat .trellis/spec/frontend/index.md  # Frontend guidelines
+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`).

package/dist/templates/kiro/skills/before-backend-dev/SKILL.md

@@ -0,0 +1,18 @@
+---
+name: before-backend-dev
+description: "Read the backend development guidelines before starting your development task."
+---
+
+Read the backend development guidelines before starting your development task.
+
+Execute these steps:
+1. Read `.trellis/spec/backend/index.md` to understand available guidelines
+2. Based on your task, read the relevant guideline files:
+   - Database work → `.trellis/spec/backend/database-guidelines.md`
+   - Error handling → `.trellis/spec/backend/error-handling.md`
+   - Logging → `.trellis/spec/backend/logging-guidelines.md`
+   - Type questions → `.trellis/spec/backend/type-safety.md`
+3. Understand the coding standards and patterns you need to follow
+4. Then proceed with your development plan
+
+This step is **mandatory** before writing any backend code.

package/dist/templates/kiro/skills/before-frontend-dev/SKILL.md

@@ -0,0 +1,18 @@
+---
+name: before-frontend-dev
+description: "Read the frontend development guidelines before starting your development task."
+---
+
+Read the frontend development guidelines before starting your development task.
+
+Execute these steps:
+1. Read `.trellis/spec/frontend/index.md` to understand available guidelines
+2. Based on your task, read the relevant guideline files:
+   - Component work → `.trellis/spec/frontend/component-guidelines.md`
+   - Hook work → `.trellis/spec/frontend/hook-guidelines.md`
+   - State management → `.trellis/spec/frontend/state-management.md`
+   - Type questions → `.trellis/spec/frontend/type-safety.md`
+3. Understand the coding standards and patterns you need to follow
+4. Then proceed with your development plan
+
+This step is **mandatory** before writing any frontend code.

package/dist/templates/kiro/skills/check-backend/SKILL.md

@@ -0,0 +1,18 @@
+---
+name: check-backend
+description: "Check if the code you just wrote follows the backend development guidelines."
+---
+
+Check if the code you just wrote follows the backend development guidelines.
+
+Execute these steps:
+1. Run `git status` to see modified files
+2. Read `.trellis/spec/backend/index.md` to understand which guidelines apply
+3. Based on what you changed, read the relevant guideline files:
+   - Database changes → `.trellis/spec/backend/database-guidelines.md`
+   - Error handling → `.trellis/spec/backend/error-handling.md`
+   - Logging changes → `.trellis/spec/backend/logging-guidelines.md`
+   - Type changes → `.trellis/spec/backend/type-safety.md`
+   - Any changes → `.trellis/spec/backend/quality-guidelines.md`
+4. Review your code against the guidelines
+5. Report any violations and fix them if found

package/dist/templates/kiro/skills/check-frontend/SKILL.md

@@ -0,0 +1,18 @@
+---
+name: check-frontend
+description: "Check if the code you just wrote follows the frontend development guidelines."
+---
+
+Check if the code you just wrote follows the frontend development guidelines.
+
+Execute these steps:
+1. Run `git status` to see modified files
+2. Read `.trellis/spec/frontend/index.md` to understand which guidelines apply
+3. Based on what you changed, read the relevant guideline files:
+   - Component changes → `.trellis/spec/frontend/component-guidelines.md`
+   - Hook changes → `.trellis/spec/frontend/hook-guidelines.md`
+   - State changes → `.trellis/spec/frontend/state-management.md`
+   - Type changes → `.trellis/spec/frontend/type-safety.md`
+   - Any changes → `.trellis/spec/frontend/quality-guidelines.md`
+4. Review your code against the guidelines
+5. Report any violations and fix them if found

package/dist/templates/kiro/skills/create-command/SKILL.md

@@ -93,8 +93,8 @@ Description:
 | Skill Type | Prefix | Example |
 |------------|--------|---------|
 | Session Start | `start` | `start` |
-| Pre-development | `before-` | `before-dev` |
-| Check | `check-` | `check` |
+| Pre-development | `before-` | `before-frontend-dev` |
+| Check | `check-` | `check-frontend` |
 | Record | `record-` | `record-session` |
 | Generate | `generate-` | `generate-api-doc` |
 | Update | `update-` | `update-changelog` |

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

@@ -131,13 +131,13 @@ AI needs the same onboarding - but compressed into seconds at session start.
 
 ---
 
-### $before-dev - Inject Specialized Knowledge
+### $before-frontend-dev and $before-backend-dev - Inject Specialized Knowledge
 
 **WHY IT EXISTS**:
 AI models have "pre-trained knowledge" - general patterns from millions of codebases. But YOUR project has specific conventions that differ from generic patterns.
 
 **WHAT IT ACTUALLY DOES**:
-1. Discovers spec layers via `get_context.py --mode packages` and reads relevant guidelines
+1. Reads `.trellis/spec/frontend/` or `.trellis/spec/backend/`
 2. Loads project-specific patterns into AI's working context:
    - Component naming conventions
    - State management patterns
@@ -145,12 +145,12 @@ AI models have "pre-trained knowledge" - general patterns from millions of codeb
    - Error handling standards
 
 **WHY THIS MATTERS**:
-- Without before-dev: AI writes generic code that doesn't match project style.
-- With before-dev: AI writes code that looks like the rest of the codebase.
+- Without before-*-dev: AI writes generic code that doesn't match project style.
+- With before-*-dev: AI writes code that looks like the rest of the codebase.
 
 ---
 
-### $check - Combat Context Drift
+### $check-frontend and $check-backend - Combat Context Drift
 
 **WHY IT EXISTS**:
 AI context window has limited capacity. As conversation progresses, guidelines injected at session start become less influential. This causes "context drift."
@@ -216,9 +216,9 @@ All the context AI built during this session will be lost when session ends. The
 
 **[1/8] $start** - AI needs project context before touching code
 **[2/8] python3 ./.trellis/scripts/task.py create "Fix bug" --slug fix-bug** - Track work for future reference
-**[3/8] $before-dev** - Inject project-specific development guidelines
+**[3/8] $before-frontend-dev** - Inject project-specific frontend knowledge
 **[4/8] Investigate and fix the bug** - Actual development work
-**[5/8] $check** - Re-verify code against guidelines
+**[5/8] $check-frontend** - Re-verify code against guidelines
 **[6/8] $finish-work** - Holistic cross-layer review
 **[7/8] Human tests and commits** - Human validates before code enters repo
 **[8/8] $record-session** - Persist memory for future sessions
@@ -233,9 +233,9 @@ All the context AI built during this session will be lost when session ends. The
 ### Example 3: Code Review Fixes
 
 **[1/6] $start** - Resume context from previous session
-**[2/6] $before-dev** - Re-inject guidelines before fixes
+**[2/6] $before-backend-dev** - Re-inject guidelines before fixes
 **[3/6] Fix each CR issue** - Address feedback with guidelines in context
-**[4/6] $check** - Verify fixes did not introduce new issues
+**[4/6] $check-backend** - Verify fixes didn't introduce new issues
 **[5/6] $finish-work** - Document lessons from CR
 **[6/6] Human commits, then $record-session** - Preserve CR lessons
 
@@ -250,9 +250,9 @@ All the context AI built during this session will be lost when session ends. The
 ### Example 5: Debug Session
 
 **[1/6] $start** - See if this bug was investigated before
-**[2/6] $before-dev** - Guidelines might document known gotchas
+**[2/6] $before-backend-dev** - Guidelines might document known gotchas
 **[3/6] Investigation** - Actual debugging work
-**[4/6] $check** - Verify debug changes do not break other things
+**[4/6] $check-backend** - Verify debug changes don't break other things
 **[5/6] $finish-work** - Debug findings might need documentation
 **[6/6] Human commits, then $record-session** - Debug knowledge is valuable
 

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

@@ -5,7 +5,7 @@ description: "Record work progress after human has tested and committed code"
 
 [!] **Prerequisite**: This skill should only be used AFTER the human has tested and committed the code.
 
-**AI must NOT execute git commit** - only read history (`git log`, `git status`, `git diff`).
+**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.
 
 ---
 
@@ -36,7 +36,7 @@ python3 ./.trellis/scripts/add_session.py \
   --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"
+cat << 'EOF' | python3 ./.trellis/scripts/add_session.py --title "Title" --commit "hash"
 | Feature | Description |
 |---------|-------------|
 | New API | Added user authentication endpoint |

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

@@ -45,14 +45,9 @@ 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)
+cat .trellis/spec/frontend/index.md  # Frontend guidelines
+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`).

package/dist/templates/markdown/spec/backend/script-conventions.md

@@ -502,99 +502,6 @@ parser.add_argument(
 
 ---
 
-## Parsing Structured Command Output
-
-### CRITICAL: Preserve Semantic Whitespace
-
-Many CLI tools encode status information in leading/trailing whitespace characters. **Never blindly `.strip()` before parsing.**
-
-**Example — `git submodule status` output format**:
-
-```
- abc1234 path/to/submodule (v1.0)     ← space prefix = initialized
--def5678 path/to/other (v2.0)         ← minus prefix = not initialized
-+ghi9012 path/to/modified (v3.0)      ← plus prefix = modified (out of sync)
-```
-
-```python
-# BAD — .strip() removes the leading space that means "initialized"
-status_line = status_out.strip()
-prefix = status_line[0]  # Reads commit hash char, not status prefix!
-
-# GOOD — parse the raw line, then strip individual fields
-raw_line = status_out.rstrip("\n")  # Only remove trailing newline
-if not raw_line:
-    continue
-prefix = raw_line[0]               # ' ', '-', or '+'
-rest = raw_line[1:].strip()        # Now safe to strip the rest
-commit_hash = rest.split()[0]
-```
-
-**General rule**: When a command's output uses positional formatting (columns, prefixes, fixed-width fields), parse the structure first, then clean up individual values.
-
-**Other commands with semantic whitespace**:
-- `git status --porcelain` — two-char status prefix (`XY`)
-- `git diff --name-status` — tab-separated with status prefix
-- `docker ps --format` — column-aligned output
-
----
-
-## Monorepo Config API (`common/config.py`)
-
-### Config Functions
-
-| Function | Return | Purpose |
-|----------|--------|---------|
-| `is_monorepo(repo_root)` | `bool` | Whether `packages:` exists in config.yaml |
-| `get_packages(repo_root)` | `dict[str, dict] \| None` | All packages from config.yaml (`{name: {path, type?}}`) |
-| `get_default_package(repo_root)` | `str \| None` | The `default_package` from config.yaml |
-| `get_submodule_packages(repo_root)` | `dict[str, str]` | Packages with `type: submodule` (`{name: path}`) |
-| `get_spec_base(package, repo_root)` | `str` | `"spec"` (single-repo) or `"spec/<package>"` (monorepo) |
-| `validate_package(package, repo_root)` | `bool` | Whether package exists in config (always `True` for single-repo) |
-| `resolve_package(task_pkg, repo_root)` | `str \| None` | Resolve package: task → default → None |
-| `get_spec_scope(repo_root)` | `str \| list \| None` | The `session.spec_scope` config value |
-| `get_hooks(event, repo_root)` | `list[str]` | Hook commands for lifecycle event |
-
-### Config.yaml Schema
-
-```yaml
-# Auto-detected monorepo packages (written by trellis init)
-packages:
-  cli:
-    path: packages/cli
-  docs-site:
-    path: docs-site
-    type: submodule       # optional, marks git submodule
-default_package: cli      # first non-submodule package
-
-# Session behavior
-session:
-  spec_scope: active_task  # or ["cli", "docs-site"] or omit for full scan
-
-# Update behavior
-update:
-  skip:
-    - .claude/commands/trellis/my-custom.md
-
-# Lifecycle hooks
-hooks:
-  after_create:
-    - "python3 .trellis/scripts/hooks/my_hook.py create"
-```
-
-### Worktree Submodule Initialization
-
-When `start.py` creates a worktree for a task, it calls `_init_submodules_for_task()`:
-
-1. Read `packages` from config.yaml via `get_packages()`
-2. Resolve target package from task data or `default_package`
-3. Check if the package is a submodule via `get_submodule_packages()`
-4. Run `git submodule status <path>` in the worktree
-5. Parse the status prefix (see "Parsing Structured Command Output" above)
-6. If uninitialized (`-` prefix): run `git submodule update --init <path>`
-
----
-
 ## Error Handling
 
 ### Exit Codes

package/dist/templates/opencode/agents/dispatch.md

@@ -106,7 +106,8 @@ Hook will auto-inject:
 
 - finish-work.md
 - check-cross-layer.md
-- check.md
+- check-backend.md
+- check-frontend.md
 - All spec files from check.jsonl
 
 ### action: "debug"

package/dist/templates/opencode/agents/implement.md

@@ -65,8 +65,8 @@ Before implementing, read:
 
 Read relevant specs based on task type:
 
-- Spec layers: `.trellis/spec/<package>/<layer>/`
-- Shared guides: `.trellis/spec/guides/`
+- Backend: `.trellis/spec/backend/`
+- Frontend: `.trellis/spec/frontend/`
 - Guides: `.trellis/spec/guides/`
 
 ### 2. Understand Requirements

package/dist/templates/opencode/agents/research.md

@@ -29,7 +29,8 @@ Otherwise, if task-specific research is needed:
    - If `path` is a directory → Read all `.md` files in it
 
 Project spec locations for reference:
-- `.trellis/spec/<package>/<layer>/` - Package-specific standards
+- `.trellis/spec/backend/` - Backend standards
+- `.trellis/spec/frontend/` - Frontend standards
 - `.trellis/spec/guides/` - Thinking guides
 - `.trellis/big-question/` - Known issues and pitfalls
 

package/dist/templates/opencode/commands/trellis/before-backend-dev.md

@@ -0,0 +1,13 @@
+Read the backend development guidelines before starting your development task.
+
+Execute these steps:
+1. Read `.trellis/spec/backend/index.md` to understand available guidelines
+2. Based on your task, read the relevant guideline files:
+   - Database work → `.trellis/spec/backend/database-guidelines.md`
+   - Error handling → `.trellis/spec/backend/error-handling.md`
+   - Logging → `.trellis/spec/backend/logging-guidelines.md`
+   - Type questions → `.trellis/spec/backend/type-safety.md`
+3. Understand the coding standards and patterns you need to follow
+4. Then proceed with your development plan
+
+This step is **mandatory** before writing any backend code.

package/dist/templates/opencode/commands/trellis/before-frontend-dev.md

@@ -0,0 +1,13 @@
+Read the frontend development guidelines before starting your development task.
+
+Execute these steps:
+1. Read `.trellis/spec/frontend/index.md` to understand available guidelines
+2. Based on your task, read the relevant guideline files:
+   - Component work → `.trellis/spec/frontend/component-guidelines.md`
+   - Hook work → `.trellis/spec/frontend/hook-guidelines.md`
+   - State management → `.trellis/spec/frontend/state-management.md`
+   - Type questions → `.trellis/spec/frontend/type-safety.md`
+3. Understand the coding standards and patterns you need to follow
+4. Then proceed with your development plan
+
+This step is **mandatory** before writing any frontend code.

package/dist/templates/opencode/commands/trellis/check-backend.md

@@ -0,0 +1,13 @@
+Check if the code you just wrote follows the backend development guidelines.
+
+Execute these steps:
+1. Run `git status` to see modified files
+2. Read `.trellis/spec/backend/index.md` to understand which guidelines apply
+3. Based on what you changed, read the relevant guideline files:
+   - Database changes → `.trellis/spec/backend/database-guidelines.md`
+   - Error handling → `.trellis/spec/backend/error-handling.md`
+   - Logging changes → `.trellis/spec/backend/logging-guidelines.md`
+   - Type changes → `.trellis/spec/backend/type-safety.md`
+   - Any changes → `.trellis/spec/backend/quality-guidelines.md`
+4. Review your code against the guidelines
+5. Report any violations and fix them if found

package/dist/templates/opencode/commands/trellis/check-frontend.md

@@ -0,0 +1,13 @@
+Check if the code you just wrote follows the frontend development guidelines.
+
+Execute these steps:
+1. Run `git status` to see modified files
+2. Read `.trellis/spec/frontend/index.md` to understand which guidelines apply
+3. Based on what you changed, read the relevant guideline files:
+   - Component changes → `.trellis/spec/frontend/component-guidelines.md`
+   - Hook changes → `.trellis/spec/frontend/hook-guidelines.md`
+   - State changes → `.trellis/spec/frontend/state-management.md`
+   - Type changes → `.trellis/spec/frontend/type-safety.md`
+   - Any changes → `.trellis/spec/frontend/quality-guidelines.md`
+4. Review your code against the guidelines
+5. Report any violations and fix them if found

package/dist/templates/opencode/commands/trellis/create-command.md

@@ -101,8 +101,8 @@ Description:
 | Command Type | Prefix | Example |
 |--------------|--------|---------|
 | Session Start | `start` | `start` |
-| Pre-development | `before-` | `before-dev` |
-| Check | `check-` | `check` |
+| Pre-development | `before-` | `before-frontend-dev` |
+| Check | `check-` | `check-frontend` |
 | Record | `record-` | `record-session` |
 | Generate | `generate-` | `generate-api-doc` |
 | Update | `update-` | `update-changelog` |