@blxzer/cursor-trellis 0.3.0 → 0.3.3

package/dist/templates/common/bundled-skills/cstl-meta/references/local-architecture/spec-system.md

@@ -1,13 +1,13 @@
 # Local Spec System
 
-`.trellis/spec/` is the user's project-specific engineering spec library. Trellis is not about making AI memorize conventions; it injects relevant specs or requires the AI to read them at the right time.
+`.cstl/spec/` is the user's project-specific engineering spec library. Trellis is not about making AI memorize conventions; it injects relevant specs or requires the AI to read them at the right time.
 
 ## Directory Model
 
 A common single-repository structure:
 
 ```text
-.trellis/spec/
+.cstl/spec/
 ├── backend/
 │   ├── index.md
 │   └── ...
@@ -22,7 +22,7 @@ A common single-repository structure:
 A common monorepo structure:
 
 ```text
-.trellis/spec/
+.cstl/spec/
 ├── cli/
 │   ├── backend/
 │   │   ├── index.md
@@ -43,7 +43,7 @@ A common monorepo structure:
 
 ## Package Configuration
 
-`.trellis/config.yaml` can declare packages:
+`.cstl/config.yaml` can declare packages:
 
 ```yaml
 packages:
@@ -58,7 +58,7 @@ default_package: cli
 The AI can run:
 
 ```bash
-python3 ./.trellis/scripts/get_context.py --mode packages
+python3 ./.cstl/scripts/get_context.py --mode packages
 ```
 
 This command lists packages and spec layers for the current project. Use this output as the reference when configuring context JSONL.
@@ -68,8 +68,8 @@ This command lists packages and spec layers for the current project. Use this ou
 Before a task enters implementation, planning may write relevant specs into `implement.jsonl` / `check.jsonl` when the task needs spec or research context beyond the task artifacts:
 
 ```jsonl
-{"file": ".trellis/spec/cli/backend/index.md", "reason": "CLI backend conventions"}
-{"file": ".trellis/spec/cli/unit-test/conventions.md", "reason": "Test expectations"}
+{"file": ".cstl/spec/cli/backend/index.md", "reason": "CLI backend conventions"}
+{"file": ".cstl/spec/cli/unit-test/conventions.md", "reason": "Test expectations"}
 ```
 
 Sub-agents or platform preludes read these JSONL files and load the referenced specs. On platforms without sub-agent support, the AI should read the relevant specs directly according to the workflow.
@@ -85,18 +85,18 @@ Specs should contain executable engineering conventions for the project, not gen
 - Cases that require tests.
 - Project-specific pitfalls and how to avoid them.
 
-When the AI learns a new rule during implementation or debugging, it should update `.trellis/spec/` rather than only summarizing it in chat.
+When the AI learns a new rule during implementation or debugging, it should update `.cstl/spec/` rather than only summarizing it in chat.
 
 ## Local Customization Points
 
 | Need | Edit location |
 | --- | --- |
-| Add a new spec layer | `.trellis/spec/<package>/<layer>/index.md` and corresponding guideline files. |
-| Change monorepo spec mapping | `packages` / `default_package` / `spec_scope` in `.trellis/config.yaml`. |
+| Add a new spec layer | `.cstl/spec/<package>/<layer>/index.md` and corresponding guideline files. |
+| Change monorepo spec mapping | `packages` / `default_package` / `spec_scope` in `.cstl/config.yaml`. |
 | Change which specs AI reads before implementation | The task's `implement.jsonl`. |
 | Change which specs AI reads during checking | The task's `check.jsonl`. |
-| Change when specs should be updated | Phase 3.3 in `.trellis/workflow.md` and the `cstl-update-spec` skill. |
+| Change when specs should be updated | Phase 3.3 in `.cstl/workflow.md` and the `cstl-update-spec` skill. |
 
 ## Boundaries
 
-`.trellis/spec/` is the user's project specification, not a permanent copy of Trellis built-in templates. The AI should encourage the user to update it according to the actual project code instead of treating Trellis default templates as immutable documents.
+`.cstl/spec/` is the user's project specification, not a permanent copy of Trellis built-in templates. The AI should encourage the user to update it according to the actual project code instead of treating Trellis default templates as immutable documents.

package/dist/templates/common/bundled-skills/cstl-meta/references/local-architecture/task-system.md

@@ -1,11 +1,11 @@
 # Local Task System
 
-The Trellis task system is stored entirely under `.trellis/tasks/` in the user project. Each task is a directory containing requirements, context, research, state, and relationship information.
+The Trellis task system is stored entirely under `.cstl/tasks/` in the user project. Each task is a directory containing requirements, context, research, state, and relationship information.
 
 ## Task Directory Structure
 
 ```text
-.trellis/tasks/
+.cstl/tasks/
 ├── 04-28-example-task/
 │   ├── task.json
 │   ├── prd.md
@@ -59,14 +59,14 @@ Use child tasks for deliverables that can move through planning, implementation,
 Create new children with:
 
 ```bash
-python3 ./.trellis/scripts/task.py create "<child title>" --slug <child-slug> --parent <parent-dir>
+python3 ./.cstl/scripts/task.py create "<child title>" --slug <child-slug> --parent <parent-dir>
 ```
 
 Link or unlink existing tasks with:
 
 ```bash
-python3 ./.trellis/scripts/task.py add-subtask <parent-dir> <child-dir>
-python3 ./.trellis/scripts/task.py remove-subtask <parent-dir> <child-dir>
+python3 ./.cstl/scripts/task.py add-subtask <parent-dir> <child-dir>
+python3 ./.cstl/scripts/task.py remove-subtask <parent-dir> <child-dir>
 ```
 
 `children` on the parent is a historical list. When a child is archived, Trellis keeps that child name in the parent so progress like `[2/3 done]` remains meaningful after completed children move to `archive/`.
@@ -78,7 +78,7 @@ The AI should not treat phase numbers as task status. Task progress is mainly de
 The user sees a "selected task," and Trellis stores that selection per live session.
 
 ```text
-.trellis/.runtime/sessions/<context-key>.json
+.cstl/.runtime/sessions/<context-key>.json
 ```
 
 `task.py select <task>` writes the task path into the runtime session file for the current session. `task.py selected --source` shows the selected task and where it came from. Different AI windows can point to different tasks without overwriting each other.
@@ -92,8 +92,8 @@ If the platform or shell environment has no stable session identity, `task.py se
 Format:
 
 ```jsonl
-{"file": ".trellis/spec/cli/backend/index.md", "reason": "Backend conventions"}
-{"file": ".trellis/tasks/04-28-example/research/api.md", "reason": "API research"}
+{"file": ".cstl/spec/cli/backend/index.md", "reason": "Backend conventions"}
+{"file": ".cstl/tasks/04-28-example/research/api.md", "reason": "API research"}
 ```
 
 Rules:
@@ -106,16 +106,16 @@ Rules:
 ## Common Commands
 
 ```bash
-python3 ./.trellis/scripts/task.py create "<title>" --slug <slug>
-python3 ./.trellis/scripts/task.py dashboard
-python3 ./.trellis/scripts/task.py select <task>
-python3 ./.trellis/scripts/task.py selected --source
-python3 ./.trellis/scripts/task.py start-execution <task> --check
-python3 ./.trellis/scripts/task.py start-execution <task> --approved
-python3 ./.trellis/scripts/task.py add-context <task> implement <file> <reason>
-python3 ./.trellis/scripts/task.py validate <task>
-python3 ./.trellis/scripts/task.py exit
-python3 ./.trellis/scripts/task.py archive <task>
+python3 ./.cstl/scripts/task.py create "<title>" --slug <slug>
+python3 ./.cstl/scripts/task.py dashboard
+python3 ./.cstl/scripts/task.py select <task>
+python3 ./.cstl/scripts/task.py selected --source
+python3 ./.cstl/scripts/task.py start-execution <task> --check
+python3 ./.cstl/scripts/task.py start-execution <task> --approved
+python3 ./.cstl/scripts/task.py add-context <task> implement <file> <reason>
+python3 ./.cstl/scripts/task.py validate <task>
+python3 ./.cstl/scripts/task.py exit
+python3 ./.cstl/scripts/task.py archive <task>
 ```
 
 When modifying the task system, the AI should prefer script commands to maintain structure. Edit JSON/Markdown directly only when scripts do not cover the need.
@@ -124,10 +124,10 @@ When modifying the task system, the AI should prefer script commands to maintain
 
 | Need | Edit location |
 | --- | --- |
-| Change the default task template | `.trellis/scripts/common/task_store.py` and task creation instructions. |
-| Change status semantics | `.trellis/workflow.md`, workflow-state hook logic, and task usage conventions. |
-| Add task lifecycle actions | `hooks.after_*` in `.trellis/config.yaml`. |
-| Change context rules | Planning artifact guidance in `.trellis/workflow.md` and related platform agent/hook instructions. |
-| Change archive policy | `.trellis/scripts/common/task_store.py` / `task_utils.py`. |
+| Change the default task template | `.cstl/scripts/common/task_store.py` and task creation instructions. |
+| Change status semantics | `.cstl/workflow.md`, workflow-state hook logic, and task usage conventions. |
+| Add task lifecycle actions | `hooks.after_*` in `.cstl/config.yaml`. |
+| Change context rules | Planning artifact guidance in `.cstl/workflow.md` and related platform agent/hook instructions. |
+| Change archive policy | `.cstl/scripts/common/task_store.py` / `task_utils.py`. |
 
 These are local files in the user project. Do not default to editing Trellis CLI source code unless the user wants to contribute upstream.

package/dist/templates/common/bundled-skills/cstl-meta/references/local-architecture/workflow.md

@@ -1,10 +1,10 @@
 # Local Workflow System
 
-`.trellis/workflow.md` is the Trellis workflow source of truth inside the user project. An AI does not need Trellis source code to understand how the current project should move tasks forward; this file is enough.
+`.cstl/workflow.md` is the Trellis workflow source of truth inside the user project. An AI does not need Trellis source code to understand how the current project should move tasks forward; this file is enough.
 
 ## File Responsibilities
 
-`.trellis/workflow.md` has three responsibilities:
+`.cstl/workflow.md` has three responsibilities:
 
 1. **Explain workflow phases**: Plan, Execute, Finish.
 2. **Define skill routing**: which skill or agent the AI should use when the user expresses a certain intent.
@@ -62,7 +62,7 @@ Common changes:
 | Change the wrap-up flow | Update Phase 3 and `finish-work` related descriptions. Note the current split: Phase 3.4 = AI-driven code commits (batched, user-confirmed), Phase 3.5 = `/finish-work` (archive + record session). `/finish-work` refuses to run if the working tree is dirty. |
 | Change platform differences | Update routing descriptions grouped by platform. |
 
-After editing, make the AI reread `.trellis/workflow.md`; do not assume the flow from the old conversation is still valid.
+After editing, make the AI reread `.cstl/workflow.md`; do not assume the flow from the old conversation is still valid.
 
 ## Relationship To Platform Files
 

package/dist/templates/common/bundled-skills/cstl-meta/references/local-architecture/workspace-memory.md

@@ -1,11 +1,11 @@
 # Local Workspace Memory System
 
-`.trellis/workspace/` stores cross-session memory. Its purpose is to let AI and humans understand what happened before across different windows and different days.
+`.cstl/workspace/` stores cross-session memory. Its purpose is to let AI and humans understand what happened before across different windows and different days.
 
 ## Directory Structure
 
 ```text
-.trellis/workspace/
+.cstl/workspace/
 ├── index.md
 └── <developer>/
     ├── index.md
@@ -15,20 +15,20 @@
 
 | File | Purpose |
 | --- | --- |
-| `.trellis/.developer` | Current developer identity. |
-| `.trellis/workspace/index.md` | Global workspace overview. |
-| `.trellis/workspace/<developer>/index.md` | Session index for a developer. |
-| `.trellis/workspace/<developer>/journal-N.md` | Session journal. |
+| `.cstl/.developer` | Current developer identity. |
+| `.cstl/workspace/index.md` | Global workspace overview. |
+| `.cstl/workspace/<developer>/index.md` | Session index for a developer. |
+| `.cstl/workspace/<developer>/journal-N.md` | Session journal. |
 
 ## Developer Identity
 
 Run this the first time:
 
 ```bash
-python3 ./.trellis/scripts/init_developer.py <name>
+python3 ./.cstl/scripts/init_developer.py <name>
 ```
 
-This creates `.trellis/.developer` and the corresponding workspace directory. The AI should not change developer identity casually; if the identity is wrong, first confirm who is using the current project.
+This creates `.cstl/.developer` and the corresponding workspace directory. The AI should not change developer identity casually; if the identity is wrong, first confirm who is using the current project.
 
 ## Journal
 
@@ -37,7 +37,7 @@ This creates `.trellis/.developer` and the corresponding workspace directory. Th
 Common command for recording a session:
 
 ```bash
-python3 ./.trellis/scripts/add_session.py \
+python3 ./.cstl/scripts/add_session.py \
   --title "Session title" \
   --summary "What changed" \
   --commit "abc1234"
@@ -49,9 +49,9 @@ Planning or review work without a commit can also be recorded by using `--no-com
 
 | System | What it stores |
 | --- | --- |
-| `.trellis/tasks/` | Requirements, design, research, and state for a specific task. |
-| `.trellis/workspace/` | Work records across tasks and sessions. |
-| `.trellis/spec/` | Engineering knowledge preserved as long-term conventions. |
+| `.cstl/tasks/` | Requirements, design, research, and state for a specific task. |
+| `.cstl/workspace/` | Work records across tasks and sessions. |
+| `.cstl/spec/` | Engineering knowledge preserved as long-term conventions. |
 
 If information is only useful for the selected task, put it in the task directory.
 If information describes what happened in the current session, put it in the workspace journal.
@@ -61,10 +61,10 @@ If information should be followed every time code is written in the future, put
 
 | Need | Edit location |
 | --- | --- |
-| Change maximum journal lines | `max_journal_lines` in `.trellis/config.yaml`. |
-| Change session auto-commit message | `session_commit_message` in `.trellis/config.yaml`. |
-| Change session content format | `.trellis/scripts/add_session.py`. |
-| Change how workspace is displayed in context | `.trellis/scripts/common/session_context.py`. |
+| Change maximum journal lines | `max_journal_lines` in `.cstl/config.yaml`. |
+| Change session auto-commit message | `session_commit_message` in `.cstl/config.yaml`. |
+| Change session content format | `.cstl/scripts/add_session.py`. |
+| Change how workspace is displayed in context | `.cstl/scripts/common/session_context.py`. |
 
 ## AI Usage Rules
 

package/dist/templates/common/bundled-skills/cstl-meta/references/platform-files/agents.md

@@ -38,7 +38,7 @@ The Cursor hook (`inject-subagent-context.py`, registered in `.cursor/hooks.json
 
 The agent file instructs the agent to read after startup:
 
-- `python3 ./.trellis/scripts/task.py selected --source`
+- `python3 ./.cstl/scripts/task.py selected --source`
 - `implement.jsonl` or `check.jsonl`
 - spec/research files referenced by JSONL
 - selected task `prd.md`
@@ -52,7 +52,7 @@ This mode fits cases where the hook cannot reliably rewrite the sub-agent prompt
 | User need | Edit location |
 | --- | --- |
 | Implement agent must follow extra restrictions | `.cursor/agents/cstl-implement.md`. |
-| Check agent must run project-specific commands | `.cursor/agents/cstl-check.md`, and `.trellis/spec/` if needed. |
+| Check agent must run project-specific commands | `.cursor/agents/cstl-check.md`, and `.cstl/spec/` if needed. |
 | Research agent must output a fixed format | `.cursor/agents/cstl-research.md`. |
 | Agent cannot read task context | Agent prelude in the agent file, or the `inject-subagent-context` hook registration in `.cursor/hooks.json`. |
 | Add a project-specific agent | `.cursor/agents/` + related skill/command entry point that invokes it. |

package/dist/templates/common/bundled-skills/cstl-meta/references/platform-files/hooks-and-settings.md

@@ -7,7 +7,7 @@ Hooks/settings are the entry layer that connects Cursor to Trellis. They decide
 `.cursor/hooks.json` registers:
 
 - session-start hook: injects a Trellis overview when a new session starts or context resets (note the Cursor `additional_context` bug #158452 — see `cursor-context-injection-guide.md.txt`).
-- workflow-state hook: parses `[workflow-state:STATUS]` blocks from `.trellis/workflow.md` and emits the body matching the selected task `status` on each user input. Parser-only; the script does not embed fallback content.
+- workflow-state hook: parses `[workflow-state:STATUS]` blocks from `.cstl/workflow.md` and emits the body matching the selected task `status` on each user input. Parser-only; the script does not embed fallback content.
 - sub-agent context hook: injects task context when implementation/check/research agents start.
 - shell/session bridge: lets shell commands see the same Trellis session identity.
 
@@ -24,7 +24,7 @@ Whether legacy settings/config files exist in a project depends on which histori
 | Script | Purpose |
 | --- | --- |
 | `session-start.py` | Generates session-start context. |
-| `inject-workflow-state.py` | Parses `[workflow-state:STATUS]` blocks in `.trellis/workflow.md` and emits the body matching the selected task status. Falls back to `Refer to workflow.md for current step.` when no matching block exists. |
+| `inject-workflow-state.py` | Parses `[workflow-state:STATUS]` blocks in `.cstl/workflow.md` and emits the body matching the selected task status. Falls back to `Refer to workflow.md for current step.` when no matching block exists. |
 | `inject-subagent-context.py` | Injects PRD, JSONL context, and related spec/research into sub-agents. |
 | `inject-shell-session-context.py` | Lets shell commands inherit Trellis session identity. |
 
@@ -35,7 +35,7 @@ Cursor exposes sessionStart, preToolUse on Task/Subagent, beforeShellExecution,
 | User need | Edit location |
 | --- | --- |
 | AI should see more/less context in a new session | `.cursor/hooks.json` → `session-start` hook (or `.cursor/rules/*.mdc` for content the model must see every turn — see `cursor-context-injection-guide.md.txt`). |
-| Per-turn hint policy should change | `[workflow-state:STATUS]` block in `.trellis/workflow.md`. The hook parses workflow.md verbatim — no script edit required. |
+| Per-turn hint policy should change | `[workflow-state:STATUS]` block in `.cstl/workflow.md`. The hook parses workflow.md verbatim — no script edit required. |
 | Sub-agent cannot read PRD/spec | `inject-subagent-context.py` hook or agent prelude in `.cursor/agents/*.md`. |
 | `task.py selected` in shell has no selected task | `inject-shell-session-context.py` hook or environment-variable configuration. |
 | Disable an automatic injection | The corresponding hook registration in `.cursor/hooks.json`. |
@@ -44,7 +44,7 @@ Cursor exposes sessionStart, preToolUse on Task/Subagent, beforeShellExecution,
 
 1. **Settings wire things up; hooks define behavior**. If only the hook changes, Cursor may never call it. If only settings change, behavior may not change.
 2. **Confirm Cursor event names first**. Cursor's hook event surface has changed between releases; what an older guide calls `UserPromptSubmit` may now be modeled by `beforeSubmitPrompt` instead.
-3. **Hooks read local `.trellis/`, not upstream source**. `.trellis/scripts/` and `.trellis/workflow.md` in the user project are the default targets.
+3. **Hooks read local `.cstl/`, not upstream source**. `.cstl/scripts/` and `.cstl/workflow.md` in the user project are the default targets.
 4. **Errors must be visible**. Hook failures should tell the user what was not injected instead of silently leaving the AI without context.
 
 ## Troubleshooting Path
@@ -53,6 +53,6 @@ If the user says "AI did not read Trellis state":
 
 1. Check whether `.cursor/hooks.json` registers the hook.
 2. Check whether the hook file exists under `.cursor/hooks/`.
-3. Manually run the `.trellis/scripts/get_context.py` or `task.py selected --source` command that the hook depends on.
-4. Check whether selected task state exists in `.trellis/.runtime/sessions/`.
+3. Manually run the `.cstl/scripts/get_context.py` or `task.py selected --source` command that the hook depends on.
+4. Check whether selected task state exists in `.cstl/.runtime/sessions/`.
 5. Check whether the Cursor shell passes session identity.

package/dist/templates/common/bundled-skills/cstl-meta/references/platform-files/overview.md

@@ -1,10 +1,10 @@
 # Platform Files Overview
 
-Trellis connects the same local architecture to **Cursor**. `.trellis/` stores the shared runtime; `.cursor/` stores adapter files that define how Cursor enters Trellis.
+Trellis connects the same local architecture to **Cursor**. `.cstl/` stores the shared runtime; `.cursor/` stores adapter files that define how Cursor enters Trellis.
 
 When a local AI modifies Trellis, it should distinguish two file categories first:
 
-- **Shared files**: `.trellis/workflow.md`, `.trellis/tasks/`, `.trellis/spec/`, `.trellis/scripts/`.
+- **Shared files**: `.cstl/workflow.md`, `.cstl/tasks/`, `.cstl/spec/`, `.cstl/scripts/`.
 - **Platform files**: `.cursor/` (settings, hooks, agents, skills, commands, rules).
 
 Platform files do not store business state. They let Cursor read Trellis state, call Trellis scripts, and load Trellis skills/agents/hooks.
@@ -36,10 +36,10 @@ To change "when the AI knows what," inspect `.cursor/hooks.json` and `.cursor/ru
 
 When the user asks to customize behavior:
 
-1. Read `.trellis/workflow.md` to confirm the shared flow.
+1. Read `.cstl/workflow.md` to confirm the shared flow.
 2. Read `.cursor/hooks.json` to see which hooks are registered.
 3. Read the relevant `.cursor/agents/*.md`, `.cursor/skills/*/SKILL.md`, `.cursor/commands/*.md`, and `.cursor/rules/*.mdc`.
 4. Modify the local file closest to the user's need.
-5. If the change affects the shared flow, synchronize `.trellis/workflow.md` or `.trellis/spec/`.
+5. If the change affects the shared flow, synchronize `.cstl/workflow.md` or `.cstl/spec/`.
 
-Do not modify only platform files and forget the shared workflow. Do not modify only `.trellis/workflow.md` and forget that platform entry points may still contain old descriptions.
+Do not modify only platform files and forget the shared workflow. Do not modify only `.cstl/workflow.md` and forget that platform entry points may still contain old descriptions.

package/dist/templates/common/bundled-skills/cstl-meta/references/platform-files/platform-map.md

@@ -22,9 +22,9 @@ Trellis originally supported multiple AI platforms (Claude Code, Codex, OpenCode
 
 1. User specified a platform other than Cursor: treat as a legacy adapter inspection — preserve existing files but do not extend new behavior there.
 2. User says "all platforms should do this": in Cursor-only world this is equivalent to "modify the Cursor path"; also mirror any dogfooded copy under `.cursor/` in `packages/cli/src/templates/cursor/` if applicable.
-3. User only says "my AI": inspect which directories actually exist in the project; on a fresh `cstl init` only `.cursor/` and `.trellis/` are created.
-4. User wants project rules: prefer `.trellis/spec/` or a project-local skill under `.cursor/skills/`.
-5. User wants Trellis behavior: edit `.trellis/workflow.md` plus `.cursor/hooks.json` / `.cursor/agents/` / `.cursor/skills/` / `.cursor/commands/`.
+3. User only says "my AI": inspect which directories actually exist in the project; on a fresh `cstl init` only `.cursor/` and `.cstl/` are created.
+4. User wants project rules: prefer `.cstl/spec/` or a project-local skill under `.cursor/skills/`.
+5. User wants Trellis behavior: edit `.cstl/workflow.md` plus `.cursor/hooks.json` / `.cursor/agents/` / `.cursor/skills/` / `.cursor/commands/`.
 
 ## When Paths Differ
 

package/dist/templates/common/bundled-skills/cstl-meta/references/platform-files/skills-and-commands.md

@@ -22,7 +22,7 @@ Bundled skills are installed as directories and may include nested `agents/`, `e
 
 `smart-search-cli` is CLI-backed source retrieval. The Trellis package exposes the `smart-search` executable through its runtime wrapper; the skill documents how agents should use that CLI and cite retrieved sources.
 
-`cstl-spec-bootstrap` bootstraps project-specific `.trellis/spec/` guidance from the real repository.
+`cstl-spec-bootstrap` bootstraps project-specific `.cstl/spec/` guidance from the real repository.
 
 `cstl-skill-creator` is the authoring and review guide for Trellis-compatible skills. Use it when creating or improving project-local skills under `.cursor/skills/`, the shared `.agents/skills/` directory (industry skill-sharing, kept but not extended by new Trellis behavior), or upstream bundled skills. Keep `cstl-meta` focused on architecture and routing.
 
@@ -76,11 +76,11 @@ References hold longer explanations so the entry file does not contain everythin
 Commands, prompts, and workflows are usually single files. Their content should include:
 
 - When to use it.
-- Which `.trellis/` files to read.
+- Which `.cstl/` files to read.
 - Which scripts to run.
 - How to report after completion.
 
-They should not store task state; task state belongs in `.trellis/tasks/` and `.trellis/.runtime/`.
+They should not store task state; task state belongs in `.cstl/tasks/` and `.cstl/.runtime/`.
 
 Task selection uses `selected_task`, not legacy current/active task commands. The current command chain is:
 
@@ -106,7 +106,7 @@ Do not reintroduce `task.py start`, `task.py current`, or `task.py finish` into
 
 1. **Keep entry files short; references carry long content**. This matters especially for multi-file skills like `cstl-meta` and `cstl-skill-creator`.
 2. **Make trigger descriptions specific**. A description that is too broad can mis-trigger; one that is too narrow may not trigger.
-3. **Keep behavior descriptions consistent with the shared `.trellis/` runtime**. Format may differ per file type, but semantics should match the shared workflow.
+3. **Keep behavior descriptions consistent with the shared `.cstl/` runtime**. Format may differ per file type, but semantics should match the shared workflow.
 4. **Put project-specific capabilities in local skills**. Do not put team-private flows into public `cstl-meta`.
 
-If the user only wants local AI to know one more project rule, usually create a project-local skill under `.cursor/skills/` or update `.trellis/spec/` instead of changing a Trellis built-in workflow skill.
+If the user only wants local AI to know one more project rule, usually create a project-local skill under `.cursor/skills/` or update `.cstl/spec/` instead of changing a Trellis built-in workflow skill.

package/dist/templates/common/bundled-skills/cstl-skill-creator/SKILL.md

@@ -7,7 +7,7 @@ description: "Create or improve Trellis-compatible agent skills. Use when the us
 
 Create high-quality skills for Trellis-managed projects and Trellis bundled templates.
 
-This skill is the authoring and review guide for skill files. It is not the local Trellis architecture map. Use `cstl-meta` first when the user needs to understand or customize `.trellis/`, hooks, settings, commands, prompts, workflows, agents, or platform directory layout.
+This skill is the authoring and review guide for skill files. It is not the local Trellis architecture map. Use `cstl-meta` first when the user needs to understand or customize `.cstl/`, hooks, settings, commands, prompts, workflows, agents, or platform directory layout.
 
 ## Hard Constraints
 
@@ -39,6 +39,6 @@ This skill is the authoring and review guide for skill files. It is not the loca
 ## When NOT To Use
 
 - Do not use for general Trellis architecture discovery; use `cstl-meta`.
-- Do not use for project coding conventions that belong in `.trellis/spec/`.
+- Do not use for project coding conventions that belong in `.cstl/spec/`.
 - Do not use for one-off commands or prompts unless the user wants a durable auto-triggered capability.
 - Do not use for non-Trellis global skill installation or platform configuration unless the user explicitly asks for that scope.

package/dist/templates/common/bundled-skills/cstl-skill-creator/references/review-checklist.md

@@ -13,7 +13,7 @@ Use this checklist before handing off a new or modified skill.
 
 - [ ] The skill owns one coherent workflow.
 - [ ] `When NOT To Use` or equivalent boundary guidance is present when triggers may overlap.
-- [ ] Project-private rules are in `.trellis/spec/` or a project-local skill, not in a public bundled skill.
+- [ ] Project-private rules are in `.cstl/spec/` or a project-local skill, not in a public bundled skill.
 - [ ] The skill distinguishes local project customization from upstream Trellis source changes.
 
 ## Entry File

package/dist/templates/common/bundled-skills/cstl-spec-bootstrap/SKILL.md

@@ -1,15 +1,15 @@
 ---
 name: cstl-spec-bootstrap
-description: "Bootstrap project-specific Trellis coding specs with a platform-neutral single-agent workflow. Use when creating or refreshing .trellis/spec guidelines, analyzing a codebase with GitNexus, ABCoder, or source inspection, decomposing package/layer spec work, and writing real codebase-backed spec docs without placeholder text."
+description: "Bootstrap project-specific Trellis coding specs with a platform-neutral single-agent workflow. Use when creating or refreshing .cstl/spec guidelines, analyzing a codebase with GitNexus, ABCoder, or source inspection, decomposing package/layer spec work, and writing real codebase-backed spec docs without placeholder text."
 ---
 
 # Trellis Spec Bootstrap
 
-Use this skill to create or refresh `.trellis/spec/` guidelines from the real codebase. One capable agent owns the full loop: analyze the repository, choose the spec boundaries, write the docs, and verify the result. The workflow does not depend on a specific host, CLI, or agent brand.
+Use this skill to create or refresh `.cstl/spec/` guidelines from the real codebase. One capable agent owns the full loop: analyze the repository, choose the spec boundaries, write the docs, and verify the result. The workflow does not depend on a specific host, CLI, or agent brand.
 
 ## Workflow
 
-1. Confirm Trellis is initialized and inspect the current `.trellis/spec/` tree.
+1. Confirm Trellis is initialized and inspect the current `.cstl/spec/` tree.
 2. Analyze the repository architecture with the best available tools: GitNexus, ABCoder, language tooling, and direct source reads.
 3. Decompose the spec work by package and layer only when that reflects the actual codebase.
 4. Fill or reshape the spec files with concrete patterns, file paths, examples, and anti-patterns from the project.
@@ -30,11 +30,11 @@ Use this skill to create or refresh `.trellis/spec/` guidelines from the real co
 - Prefer source-backed rules over generic advice. Every important recommendation should point at a real file or repeated local pattern.
 - Keep execution single-owner by default. Optional helper agents are an implementation detail, not a requirement or user-visible dependency.
 - Do not write platform-specific instructions unless the target project already standardizes on that platform.
-- Do not leave placeholder text, empty headings, or copied boilerplate in `.trellis/spec/`.
+- Do not leave placeholder text, empty headings, or copied boilerplate in `.cstl/spec/`.
 
 ## Done Criteria
 
-- `.trellis/spec/` describes the project as it exists now.
+- `.cstl/spec/` describes the project as it exists now.
 - Each relevant package or layer has practical coding guidance with real examples.
 - Non-applicable template sections are removed.
 - `index.md` files match the final spec file set.

package/dist/templates/common/bundled-skills/cstl-spec-bootstrap/references/repository-analysis.md

@@ -4,7 +4,7 @@ The goal is to discover the project's real architecture before writing rules. Do
 
 ## Analysis Order
 
-1. Read the existing `.trellis/spec/` tree and note which files are templates, outdated, or already project-specific.
+1. Read the existing `.cstl/spec/` tree and note which files are templates, outdated, or already project-specific.
 2. Inspect package manifests, build scripts, workspace config, and top-level documentation to identify packages and runtime layers.
 3. Use GitNexus for execution flows, module clusters, dependency hubs, and impact-sensitive areas.
 4. Use ABCoder or language-native tooling for exact signatures, types, class boundaries, and implementation examples.

package/dist/templates/common/bundled-skills/cstl-spec-bootstrap/references/spec-task-planning.md

@@ -20,7 +20,7 @@ When a Trellis task is useful, write a concise PRD with these sections:
 # Fill <package-or-layer> Trellis Specs
 
 ## Goal
-Write project-specific `.trellis/spec/` guidance for <scope>.
+Write project-specific `.cstl/spec/` guidance for <scope>.
 
 ## Scope
 - Spec directory:
@@ -32,8 +32,8 @@ Write project-specific `.trellis/spec/` guidance for <scope>.
 Summarize the concrete findings from repository analysis.
 
 ## Files To Create Or Update
-- `.trellis/spec/.../index.md`
-- `.trellis/spec/.../<topic>.md`
+- `.cstl/spec/.../index.md`
+- `.cstl/spec/.../<topic>.md`
 
 ## Rules
 - Adapt the spec file set to the real codebase.

package/dist/templates/common/bundled-skills/cstl-spec-bootstrap/references/spec-writing.md

@@ -64,7 +64,7 @@ Avoid passing raw `process.argv` or unvalidated config objects into shared helpe
 Before finishing:
 
 ```bash
-grep -R "To be filled\\|TODO: fill\\|placeholder" .trellis/spec
+grep -R "To be filled\\|TODO: fill\\|placeholder" .cstl/spec
 ```
 
 Also check links, index files, and whether any spec still describes a template rather than this repository.

package/dist/templates/common/commands/continue.md

@@ -7,14 +7,14 @@ Resume work only when this live session already has a `selected_task`. If no tas
 ## Step 1: Load Framework Context
 
 ```bash
-{{PYTHON_CMD}} ./.trellis/scripts/get_context.py
+{{PYTHON_CMD}} ./.cstl/scripts/get_context.py
 ```
 
 Confirms: selected task, Task Dashboard, git state, recent commits.
 
 If the output says `Selected task: none`, do not auto-resume a previous or unique task. Show the dashboard and ask the user to choose one route:
 
-- select a task with `{{PYTHON_CMD}} ./.trellis/scripts/task.py select <task>`
+- select a task with `{{PYTHON_CMD}} ./.cstl/scripts/task.py select <task>`
 - create a task
 - inspect details
 - continue without a task for No Task / Micro-Grill work
@@ -22,7 +22,7 @@ If the output says `Selected task: none`, do not auto-resume a previous or uniqu
 ## Step 2: Load the Phase Index
 
 ```bash
-{{PYTHON_CMD}} ./.trellis/scripts/get_context.py --mode phase
+{{PYTHON_CMD}} ./.cstl/scripts/get_context.py --mode phase
 ```
 
 Shows the Phase Index (Plan / Execute / Finish) with routing + skill mapping.
@@ -40,7 +40,7 @@ When a task is selected, `get_context.py` shows the selected task's `status` fie
 - `status=in_progress` + check passed → **3.1**
 - `status=completed` (rare; usually archived immediately) → archive flow
 
-Phase rules (full detail in `.trellis/workflow.md`):
+Phase rules (full detail in `.cstl/workflow.md`):
 
 1. Run steps **in order** within a phase — `[required]` steps must not be skipped
 2. `[once]` steps are already done if the required output exists. `prd.md` alone can be enough only for lightweight tasks; complex tasks also need `design.md` and `implement.md`.
@@ -51,7 +51,7 @@ Phase rules (full detail in `.trellis/workflow.md`):
 Once you know which step to resume at:
 
 ```bash
-{{PYTHON_CMD}} ./.trellis/scripts/get_context.py --mode phase --step <X.X> --platform {{CLI_FLAG}}
+{{PYTHON_CMD}} ./.cstl/scripts/get_context.py --mode phase --step <X.X> --platform {{CLI_FLAG}}
 ```
 
 Follow the loaded instructions. After each `[required]` step completes, move to the next.
@@ -60,4 +60,4 @@ Follow the loaded instructions. After each `[required]` step completes, move to
 
 ## Reference
 
-Full workflow and detailed phase steps live in `.trellis/workflow.md`. This command is only an entry point — the canonical guidance is there.
+Full workflow and detailed phase steps live in `.cstl/workflow.md`. This command is only an entry point — the canonical guidance is there.

package/dist/templates/common/commands/finish-work.md

@@ -2,7 +2,7 @@
 
 Wrap up the current session: archive the selected task (and any other completed-but-unarchived tasks the user wants to clean up) and record the session journal. Code commits are NOT done here — those happen in workflow Phase 3.4 before you invoke this command.
 
-Before archive, confirm `verify.md` includes Phase 3.3 **Learning decision** (`update-spec` | `no-update` | `unsure`) and gate-compatible evidence per `.trellis/spec/guides/durable-learning-decision-guide.md`. Run `task.py archive <task> --check` when unsure.
+Before archive, confirm `verify.md` includes Phase 3.3 **Learning decision** (`update-spec` | `no-update` | `unsure`) and gate-compatible evidence per `.cstl/spec/guides/durable-learning-decision-guide.md`. Run `task.py archive <task> --check` when unsure.
 
 ## Evidence pack reference (optional — graceful skip)
 
@@ -19,7 +19,7 @@ Pack format: `version`, `source` (`retrieval-pack-orchestrator`), `contextPack.s
 ## Step 1: Survey current state
 
 ```bash
-{{PYTHON_CMD}} ./.trellis/scripts/get_context.py --mode record
+{{PYTHON_CMD}} ./.cstl/scripts/get_context.py --mode record
 ```
 
 This prints:
@@ -38,7 +38,7 @@ Run:
 git status --porcelain
 ```
 
-Filter out paths under `.trellis/workspace/` and `.trellis/tasks/` — those are managed by `add_session.py` and `task.py archive` auto-commits and will appear dirty as part of this skill's own work.
+Filter out paths under `.cstl/workspace/` and `.cstl/tasks/` — those are managed by `add_session.py` and `task.py archive` auto-commits and will appear dirty as part of this skill's own work.
 
 For each remaining dirty path, decide whether it belongs to **the selected task** or to **other parallel work** (e.g., another terminal window editing the same repo). Heuristics:
 
@@ -59,7 +59,7 @@ Then route:
 ## Step 3: Archive task(s)
 
 ```bash
-{{PYTHON_CMD}} ./.trellis/scripts/task.py archive <task-name>
+{{PYTHON_CMD}} ./.cstl/scripts/task.py archive <task-name>
 ```
 
 At minimum: the selected task (if any). Plus any extra tasks the user confirmed in Step 1. Each archive produces a `chore(task): archive ...` commit via the script's auto-commit.
@@ -69,7 +69,7 @@ If there is no selected task and the user did not confirm any cleanup archives,
 ## Step 4: Record session journal
 
 ```bash
-{{PYTHON_CMD}} ./.trellis/scripts/add_session.py \
+{{PYTHON_CMD}} ./.cstl/scripts/add_session.py \
   --title "Session Title" \
   --commit "hash1,hash2" \
   --summary "Brief summary"