@blxzer/cursor-trellis 0.2.8 → 0.3.0

package/dist/templates/common/bundled-skills/{trellis-meta → cstl-meta}/SKILL.md

@@ -1,75 +1,75 @@
----
-name: trellis-meta
-description: "Understand and customize the local Trellis architecture inside a user project. Use when modifying .trellis plus platform hooks, settings, agents, skills, commands, prompts, or workflows generated by trellis init."
----
-
-# Trellis Meta
-
-This skill is for local Trellis users who have already run `trellis init` in a project. After reading it, an AI should understand the Trellis architecture, operating model, and customization entry points inside that user project, then modify the generated `.trellis/` and platform directory files according to the user's request.
-
-The default operating scope is local files in the user project:
-
-- `.trellis/`: workflow, config, tasks, spec, workspace, scripts, and runtime state.
-- Platform directory: `.cursor/` — skills, agents, hooks, commands, rules.
-- Shared skill layer: `.agents/skills/` (industry skill-sharing path, kept when present but not extended by new Trellis behavior).
-
-Trellis previously supported many AI-platform adapter directories (`.claude/`, `.codex/`, `.opencode/`, `.kiro/`, `.gemini/`, `.qoder/`, `.codebuddy/`, `.github/`, `.factory/`, `.pi/`, `.kilocode/`, `.agent/`, `.windsurf/`). The project has converged on **Cursor-only**. Legacy adapter directories in upgraded projects are preserved by `trellis update` but new Trellis behavior ships to `.cursor/` only.
-
-Do not assume the user has the Trellis source repository. Do not default to modifying the global npm install directory or `node_modules`.
-
-## How To Use
-
-1. Read `references/local-architecture/overview.md` first to establish the local Trellis system model.
-2. If the request involves a specific AI tool, read `references/platform-files/platform-map.md` and the relevant platform file notes.
-3. If the user wants to change behavior, read `references/customize-local/overview.md`, then open the specific customization topic.
-4. Before editing, read the actual files in the user project and treat local content as authoritative.
-
-## References
-
-### Local Architecture
-
-- `references/local-architecture/overview.md`: The three-layer local Trellis architecture and customization principles.
-- `references/local-architecture/generated-files.md`: Files generated by `trellis init` and their customization boundaries.
-- `references/local-architecture/workflow.md`: Phases, routing, and workflow-state blocks in `.trellis/workflow.md`.
-- `references/local-architecture/task-system.md`: Task directories, selected tasks, JSONL context, and task runtime.
-- `references/local-architecture/spec-system.md`: How `.trellis/spec/` is organized and injected.
-- `references/local-architecture/workspace-memory.md`: `.trellis/workspace/`, journals, and cross-session memory.
-- `references/local-architecture/context-injection.md`: Hooks, sub-agent preludes, and context injection paths.
-
-### Platform Files
-
-- `references/platform-files/overview.md`: How shared `.trellis/` files relate to platform directories.
-- `references/platform-files/platform-map.md`: Platform directories and paths for skills, agents, hooks, and extensions.
-- `references/platform-files/hooks-and-settings.md`: How settings/config files, hooks, plugins, and extensions connect to Trellis.
-- `references/platform-files/agents.md`: Local file responsibilities for `trellis-research`, `trellis-implement`, and `trellis-check`.
-- `references/platform-files/skills-and-commands.md`: Differences between skills, commands, prompts, and workflows, plus how to change them.
-
-### Local Customization
-
-- `references/customize-local/overview.md`: Choose the right local customization entry point for the user's request.
-- `references/customize-local/change-workflow.md`: Change phases, routing, next actions, and workflow-state.
-- `references/customize-local/change-task-lifecycle.md`: Change task creation, status, archive behavior, and hooks.
-- `references/customize-local/change-context-loading.md`: Change how tasks, specs, journals, and hook context are loaded.
-- `references/customize-local/change-hooks.md`: Change platform hooks, settings, and shell session bridges.
-- `references/customize-local/change-agents.md`: Change research, implement, and check agent behavior.
-- `references/customize-local/change-skills-or-commands.md`: Add or modify local skills, commands, prompts, and workflows.
-- `references/customize-local/change-spec-structure.md`: Adjust the project spec structure under `.trellis/spec/`.
-- `references/customize-local/add-project-local-conventions.md`: Put team rules into project-local specs or local skills.
-
-## Current Rules
-
-- `.trellis/workflow.md` is the local workflow source of truth.
-- `.trellis/config.yaml` is the project-level Trellis configuration and task hook configuration entry point.
-- `.trellis/spec/` stores the user's project-specific coding conventions and design constraints.
-- `.trellis/tasks/` stores task PRDs, technical notes, research files, and JSONL context.
-- `.trellis/workspace/` stores developer journals and cross-session memory.
-- Platform settings/config files decide which hooks, agents, skills, commands, prompts, and workflows actually run.
-- `.trellis/.template-hashes.json` and `.trellis/.runtime/` are management/runtime state files. Confirm necessity before editing them.
-
-## Do Not
-
-- Do not treat Trellis upstream source code as the default target for local customization.
-- Do not modify the global npm install directory or `node_modules/@blxzer/cursor-trellis` to implement project needs.
-- Do not overwrite user-modified local files with default templates.
-- Do not put team-private project rules into the public `trellis-meta`; put project rules in `.trellis/spec/` or a project-local skill.
-- Do not describe removed historical mechanisms as current Trellis behavior.
+---
+name: cstl-meta
+description: "Understand and customize the local Trellis architecture inside a user project. Use when modifying .trellis plus platform hooks, settings, agents, skills, commands, prompts, or workflows generated by cstl init."
+---
+
+# Trellis Meta
+
+This skill is for local Trellis users who have already run `cstl init` in a project. After reading it, an AI should understand the Trellis architecture, operating model, and customization entry points inside that user project, then modify the generated `.trellis/` and platform directory files according to the user's request.
+
+The default operating scope is local files in the user project:
+
+- `.trellis/`: workflow, config, tasks, spec, workspace, scripts, and runtime state.
+- Platform directory: `.cursor/` — skills, agents, hooks, commands, rules.
+- Shared skill layer: `.agents/skills/` (industry skill-sharing path, kept when present but not extended by new Trellis behavior).
+
+Trellis previously supported many AI-platform adapter directories (`.claude/`, `.codex/`, `.opencode/`, `.kiro/`, `.gemini/`, `.qoder/`, `.codebuddy/`, `.github/`, `.factory/`, `.pi/`, `.kilocode/`, `.agent/`, `.windsurf/`). The project has converged on **Cursor-only**. Legacy adapter directories in upgraded projects are preserved by `cstl update` but new Trellis behavior ships to `.cursor/` only.
+
+Do not assume the user has the Trellis source repository. Do not default to modifying the global npm install directory or `node_modules`.
+
+## How To Use
+
+1. Read `references/local-architecture/overview.md` first to establish the local Trellis system model.
+2. If the request involves a specific AI tool, read `references/platform-files/platform-map.md` and the relevant platform file notes.
+3. If the user wants to change behavior, read `references/customize-local/overview.md`, then open the specific customization topic.
+4. Before editing, read the actual files in the user project and treat local content as authoritative.
+
+## References
+
+### Local Architecture
+
+- `references/local-architecture/overview.md`: The three-layer local Trellis architecture and customization principles.
+- `references/local-architecture/generated-files.md`: Files generated by `cstl init` and their customization boundaries.
+- `references/local-architecture/workflow.md`: Phases, routing, and workflow-state blocks in `.trellis/workflow.md`.
+- `references/local-architecture/task-system.md`: Task directories, selected tasks, JSONL context, and task runtime.
+- `references/local-architecture/spec-system.md`: How `.trellis/spec/` is organized and injected.
+- `references/local-architecture/workspace-memory.md`: `.trellis/workspace/`, journals, and cross-session memory.
+- `references/local-architecture/context-injection.md`: Hooks, sub-agent preludes, and context injection paths.
+
+### Platform Files
+
+- `references/platform-files/overview.md`: How shared `.trellis/` files relate to platform directories.
+- `references/platform-files/platform-map.md`: Platform directories and paths for skills, agents, hooks, and extensions.
+- `references/platform-files/hooks-and-settings.md`: How settings/config files, hooks, plugins, and extensions connect to Trellis.
+- `references/platform-files/agents.md`: Local file responsibilities for `cstl-research`, `cstl-implement`, and `cstl-check`.
+- `references/platform-files/skills-and-commands.md`: Differences between skills, commands, prompts, and workflows, plus how to change them.
+
+### Local Customization
+
+- `references/customize-local/overview.md`: Choose the right local customization entry point for the user's request.
+- `references/customize-local/change-workflow.md`: Change phases, routing, next actions, and workflow-state.
+- `references/customize-local/change-task-lifecycle.md`: Change task creation, status, archive behavior, and hooks.
+- `references/customize-local/change-context-loading.md`: Change how tasks, specs, journals, and hook context are loaded.
+- `references/customize-local/change-hooks.md`: Change platform hooks, settings, and shell session bridges.
+- `references/customize-local/change-agents.md`: Change research, implement, and check agent behavior.
+- `references/customize-local/change-skills-or-commands.md`: Add or modify local skills, commands, prompts, and workflows.
+- `references/customize-local/change-spec-structure.md`: Adjust the project spec structure under `.trellis/spec/`.
+- `references/customize-local/add-project-local-conventions.md`: Put team rules into project-local specs or local skills.
+
+## Current Rules
+
+- `.trellis/workflow.md` is the local workflow source of truth.
+- `.trellis/config.yaml` is the project-level Trellis configuration and task hook configuration entry point.
+- `.trellis/spec/` stores the user's project-specific coding conventions and design constraints.
+- `.trellis/tasks/` stores task PRDs, technical notes, research files, and JSONL context.
+- `.trellis/workspace/` stores developer journals and cross-session memory.
+- Platform settings/config files decide which hooks, agents, skills, commands, prompts, and workflows actually run.
+- `.trellis/.template-hashes.json` and `.trellis/.runtime/` are management/runtime state files. Confirm necessity before editing them.
+
+## Do Not
+
+- Do not treat Trellis upstream source code as the default target for local customization.
+- Do not modify the global npm install directory or `node_modules/@blxzer/cursor-trellis` to implement project needs.
+- Do not overwrite user-modified local files with default templates.
+- Do not put team-private project rules into the public `cstl-meta`; put project rules in `.trellis/spec/` or a project-local skill.
+- Do not describe removed historical mechanisms as current Trellis behavior.

package/dist/templates/common/bundled-skills/{trellis-meta → cstl-meta}/references/customize-local/add-project-local-conventions.md

@@ -1,6 +1,6 @@
 # Add Project-Local Conventions
 
-Often the user does not need to change Trellis mechanics; they need local AI to understand their team's conventions. In that case, prefer `.trellis/spec/` or a project-local skill instead of editing `trellis-meta`.
+Often the user does not need to change Trellis mechanics; they need local AI to understand their team's conventions. In that case, prefer `.trellis/spec/` or a project-local skill instead of editing `cstl-meta`.
 
 ## Where To Put Things
 
@@ -62,22 +62,22 @@ If the content is a coding convention, write it to spec. Examples:
 
 After writing it, update the corresponding `index.md` so AI can find the new rule from the entry point.
 
-## Make The Selected Task Use New Conventions
-
-After writing a spec, add it to the selected task context:
+## Make The Selected Task Use New Conventions
+
+After writing a spec, add it to the selected task context:
 
 ```bash
 python3 ./.trellis/scripts/task.py add-context <task> implement ".trellis/spec/backend/error-handling.md" "Error handling conventions"
 python3 ./.trellis/scripts/task.py add-context <task> check ".trellis/spec/backend/error-handling.md" "Review error handling"
 ```
 
-## Do Not Store Project-Private Rules In `trellis-meta`
+## Do Not Store Project-Private Rules In `cstl-meta`
 
-`trellis-meta` is a public skill for understanding Trellis architecture and local customization entry points. Put project-private content in:
+`cstl-meta` is a public skill for understanding Trellis architecture and local customization entry points. Put project-private content in:
 
 - `.trellis/spec/`
 - a project-local skill
-- the selected task
+- the selected task
 - workspace journal
 
-This prevents future updates to Trellis's built-in `trellis-meta` from overwriting the team's own conventions.
+This prevents future updates to Trellis's built-in `cstl-meta` from overwriting the team's own conventions.

package/dist/templates/common/bundled-skills/{trellis-meta → cstl-meta}/references/customize-local/change-agents.md

@@ -1,6 +1,6 @@
 # Change Local Agents
 
-When the user wants to change `trellis-research`, `trellis-implement`, or `trellis-check` behavior, edit platform agent files in the user project.
+When the user wants to change `cstl-research`, `cstl-implement`, or `cstl-check` behavior, edit platform agent files in the user project.
 
 ## Read These Files First
 
@@ -14,7 +14,7 @@ When the user wants to change `trellis-research`, `trellis-implement`, or `trell
 
 | Platform | Path |
 | --- | --- |
-| Cursor | `.cursor/agents/trellis-*.md` |
+| Cursor | `.cursor/agents/cstl-*.md` |
 
 If a user project still contains legacy platform agent directories (`.claude/agents/`, `.codex/agents/`, etc.), inspect them but route new agent definitions to `.cursor/agents/`.
 
@@ -24,9 +24,9 @@ Use the actual paths in the user project as authoritative.
 
 | Need | Which agent to edit |
 | --- | --- |
-| Research must write files, not only reply in chat | `trellis-research` |
-| Certain local specs must be read before implementation | `trellis-implement` + `implement.jsonl` configuration rules |
-| Specific commands must run during checking | `trellis-check` |
+| Research must write files, not only reply in chat | `cstl-research` |
+| Certain local specs must be read before implementation | `cstl-implement` + `implement.jsonl` configuration rules |
+| Specific commands must run during checking | `cstl-check` |
 | Agent must not modify certain directories | The corresponding agent's write boundary instructions |
 | Agent output format must be fixed | The corresponding agent's final/reporting instructions |
 
@@ -36,7 +36,7 @@ Use the actual paths in the user project as authoritative.
 2. **Do not hard-code project specs into agents**: long-term specs belong in `.trellis/spec/`; agents are responsible for reading them.
 3. **Make read order explicit**: selected task -> PRD -> info -> JSONL -> spec/research.
 4. **Make write boundaries explicit**: which directories may be written and which may not.
-5. **Treat dogfood + published copies consistently**: `.cursor/agents/trellis-*.md` (dogfooded) and `packages/cli/src/templates/cursor/agents/trellis-*.md` (published template) must stay in sync — see `cross-layer-thinking-guide.md.txt` → Cross-Package Template Consistency.
+5. **Treat dogfood + published copies consistently**: `.cursor/agents/cstl-*.md` (dogfooded) and `packages/cli/src/templates/cursor/agents/cstl-*.md` (published template) must stay in sync — see `cross-layer-thinking-guide.md.txt` → Cross-Package Template Consistency.
 
 ## Agent Pull Mode
 

package/dist/templates/common/bundled-skills/{trellis-meta → cstl-meta}/references/customize-local/change-context-loading.md

@@ -1,6 +1,6 @@
 # Change Local Context Loading
 
-Context loading determines when AI reads workflow, task, spec, research, workspace, and git status. Read this page when the user says "AI does not know the selected task," "the agent did not read specs," or "there is too much/too little context."
+Context loading determines when AI reads workflow, task, spec, research, workspace, and git status. Read this page when the user says "AI does not know the selected task," "the agent did not read specs," or "there is too much/too little context."
 
 ## Read These Files First
 
@@ -10,14 +10,14 @@ Context loading determines when AI reads workflow, task, spec, research, workspa
 4. `.trellis/scripts/common/task_context.py`
 5. `.trellis/scripts/common/active_task.py`
 6. Current platform hooks or agent files
-7. The selected task's `implement.jsonl` / `check.jsonl`
+7. The selected task's `implement.jsonl` / `check.jsonl`
 
 ## Context Sources
 
 | Source | Purpose |
 | --- | --- |
 | `.trellis/workflow.md` | Workflow and next-action hints. |
-| `.trellis/tasks/<task>/prd.md` | Selected task requirements. |
+| `.trellis/tasks/<task>/prd.md` | Selected task requirements. |
 | `.trellis/tasks/<task>/design.md` | Complex task technical design. |
 | `.trellis/tasks/<task>/implement.md` | Complex task execution plan. |
 | `.trellis/tasks/<task>/implement.jsonl` | Spec/research to read before implementation. |
@@ -33,7 +33,7 @@ Context loading determines when AI reads workflow, task, spec, research, workspa
 | Inject more/less information in new sessions | `session_context.py` or the platform `session-start` hook. |
 | Change hints on each user input | `[workflow-state:STATUS]` block in `.trellis/workflow.md`. The `inject-workflow-state` hook is parser-only and reads the block verbatim. |
 | Agent did not read specs | Task JSONL, agent prelude, `inject-subagent-context` hook. |
-| Selected task is lost | `active_task.py` and platform session identity propagation. |
+| Selected task is lost | `active_task.py` and platform session identity propagation. |
 | Change JSONL validation rules | `task_context.py`. |
 
 ## JSONL Rules
@@ -61,11 +61,11 @@ Context cannot grow without bound. Prefer injecting indexes and paths so the AI
 First determine which mode the platform uses:
 
 - hook push: edit the `inject-subagent-context` hook.
-- agent pull: edit the read steps in the corresponding `trellis-implement` / `trellis-check` agent file.
+- agent pull: edit the read steps in the corresponding `cstl-implement` / `cstl-check` agent file.
 
 In both modes, make sure the agent ultimately reads:
 
-1. selected task
+1. selected task
 2. the corresponding JSONL
 3. spec/research referenced by the JSONL
 4. `prd.md`
@@ -75,7 +75,7 @@ In both modes, make sure the agent ultimately reads:
 ## Troubleshooting Order
 
 ```bash
-python3 ./.trellis/scripts/task.py selected --source
+python3 ./.trellis/scripts/task.py selected --source
 python3 ./.trellis/scripts/task.py list-context <task>
 python3 ./.trellis/scripts/task.py validate <task>
 python3 ./.trellis/scripts/get_context.py --mode packages

package/dist/templates/common/bundled-skills/{trellis-meta → cstl-meta}/references/customize-local/change-skills-or-commands.md

@@ -30,7 +30,7 @@ A skill is usually:
 
 `SKILL.md` should be short and responsible for triggering/routing. Put long content in `references/` so AI can read it on demand.
 
-For detailed skill authoring and review rules, use `trellis-skill-creator`. This `trellis-meta` page only identifies where local Trellis skill, command, prompt, and workflow changes belong.
+For detailed skill authoring and review rules, use `cstl-skill-creator`. This `cstl-meta` page only identifies where local Trellis skill, command, prompt, and workflow changes belong.
 
 The frontmatter description should specify when to use the skill. Example:
 

package/dist/templates/common/bundled-skills/{trellis-meta → cstl-meta}/references/customize-local/change-spec-structure.md

@@ -7,7 +7,7 @@ When the user wants to change the engineering conventions AI follows, add new sp
 1. `.trellis/config.yaml`
 2. `.trellis/spec/`
 3. `.trellis/workflow.md` planning artifact guidance and Phase 3.3
-4. Selected task `implement.jsonl` / `check.jsonl`
+4. Selected task `implement.jsonl` / `check.jsonl`
 
 ## Common Needs
 
@@ -47,7 +47,7 @@ Monorepo example:
 
 ## Update Context
 
-Adding a spec does not mean every task automatically reads it. The selected task must reference it in JSONL:
+Adding a spec does not mean every task automatically reads it. The selected task must reference it in JSONL:
 
 ```bash
 python3 ./.trellis/scripts/task.py add-context <task> implement ".trellis/spec/webapp/security/index.md" "Security conventions"

package/dist/templates/common/bundled-skills/{trellis-meta → cstl-meta}/references/customize-local/change-task-lifecycle.md

@@ -1,6 +1,6 @@
 # Change Local Task Lifecycle
 
-Task lifecycle includes creation, selection, execution start, context configuration, archive, parent/child tasks, and lifecycle hooks. The default customization targets are `.trellis/tasks/`, `.trellis/config.yaml`, and `.trellis/scripts/`.
+Task lifecycle includes creation, selection, execution start, context configuration, archive, parent/child tasks, and lifecycle hooks. The default customization targets are `.trellis/tasks/`, `.trellis/config.yaml`, and `.trellis/scripts/`.
 
 ## Read These Files First
 
@@ -9,18 +9,18 @@ Task lifecycle includes creation, selection, execution start, context configurat
 3. `.trellis/scripts/task.py`
 4. `.trellis/scripts/common/task_store.py`
 5. `.trellis/scripts/common/task_utils.py`
-6. The selected task's `.trellis/tasks/<task>/task.json`
+6. The selected task's `.trellis/tasks/<task>/task.json`
 
 ## Common Needs And Edit Points
 
 | Need | Edit point |
 | --- | --- |
 | Automatically sync an external system after task creation | `hooks.after_create` in `.trellis/config.yaml`. |
-| Automatically update status after execution start | `hooks.after_start` in `.trellis/config.yaml`. |
-| Clean external resources after archive | `hooks.after_archive` in `.trellis/config.yaml`. |
+| Automatically update status after execution start | `hooks.after_start` in `.trellis/config.yaml`. |
+| Clean external resources after archive | `hooks.after_archive` in `.trellis/config.yaml`. |
 | Change default task fields | `.trellis/scripts/common/task_store.py`. |
 | Change task parsing/search | `.trellis/scripts/common/task_utils.py`. |
-| Change selected task behavior | `.trellis/scripts/common/active_task.py`. |
+| Change selected task behavior | `.trellis/scripts/common/active_task.py`. |
 
 ## lifecycle hooks
 
@@ -32,11 +32,11 @@ hooks:
     - "python3 .trellis/scripts/hooks/my_sync.py create"
   after_start:
     - "python3 .trellis/scripts/hooks/my_sync.py start"
-  after_archive:
-    - "python3 .trellis/scripts/hooks/my_sync.py archive"
-```
-
-Hook commands receive the `TASK_JSON_PATH` environment variable, pointing to the task's `task.json`. Hook failures should usually warn, but not block the main task operation.
+  after_archive:
+    - "python3 .trellis/scripts/hooks/my_sync.py archive"
+```
+
+Hook commands receive the `TASK_JSON_PATH` environment variable, pointing to the task's `task.json`. Hook failures should usually warn, but not block the main task operation.
 
 ## Change Task Fields
 
@@ -53,30 +53,30 @@ Example:
 
 If standard fields really need to change, inspect every local script that reads `task.json`.
 
-## Change Selected Task
-
-Selected task is session-level state stored in `.trellis/.runtime/sessions/`. Do not fall back to a global `.current-task` model. If the user wants to change selected task behavior, edit:
-
-- `.trellis/scripts/common/active_task.py`
-- platform hooks or shell session bridges
-- selected task descriptions in `.trellis/workflow.md`
-
-### `task.py create` Does Not Select
-
-`cmd_create` in `.trellis/scripts/common/task_store.py` writes the task directory and planning artifacts only. The behavior:
-
-- The task's `status=planning` is written.
-- No selected-task pointer is written, even when session identity exists.
-- The user or AI selects the task later with `task.py select <dir>` when they explicitly choose to enter it.
-
-This keeps new sessions and bare task creation at `Selected task: none` until a live-session choice is made.
-
-If you fork `task.py` to add a new creation path (e.g. an external import that bypasses `cmd_create`), audit that it does not auto-select or auto-start the created task. The full status writer table is in `.trellis/spec/cli/backend/workflow-state-contract.md`.
+## Change Selected Task
+
+Selected task is session-level state stored in `.trellis/.runtime/sessions/`. Do not fall back to a global `.current-task` model. If the user wants to change selected task behavior, edit:
+
+- `.trellis/scripts/common/active_task.py`
+- platform hooks or shell session bridges
+- selected task descriptions in `.trellis/workflow.md`
+
+### `task.py create` Does Not Select
+
+`cmd_create` in `.trellis/scripts/common/task_store.py` writes the task directory and planning artifacts only. The behavior:
+
+- The task's `status=planning` is written.
+- No selected-task pointer is written, even when session identity exists.
+- The user or AI selects the task later with `task.py select <dir>` when they explicitly choose to enter it.
+
+This keeps new sessions and bare task creation at `Selected task: none` until a live-session choice is made.
+
+If you fork `task.py` to add a new creation path (e.g. an external import that bypasses `cmd_create`), audit that it does not auto-select or auto-start the created task. The full status writer table is in `.trellis/spec/cli/backend/workflow-state-contract.md`.
 
 ## Modification Steps
 
-1. Confirm the selected task with `python3 ./.trellis/scripts/task.py selected --source`.
-2. Read the selected task's `task.json` and confirm status and fields.
+1. Confirm the selected task with `python3 ./.trellis/scripts/task.py selected --source`.
+2. Read the selected task's `task.json` and confirm status and fields.
 3. For configuration needs, edit `.trellis/config.yaml` first.
 4. For script behavior needs, then edit `.trellis/scripts/`.
 5. If the AI flow changed, synchronize `.trellis/workflow.md`.

package/dist/templates/common/bundled-skills/{trellis-meta → cstl-meta}/references/customize-local/change-workflow.md

@@ -6,7 +6,7 @@ When the user wants to change Trellis phases, next-action hints, whether to crea
 
 1. `.trellis/workflow.md`
 2. Entry files for the current platform, such as skills/commands/prompts/workflows
-3. The selected task's `task.json` and `prd.md`
+3. The selected task's `task.json` and `prd.md`
 
 ## Common Needs And Edit Points
 
@@ -41,24 +41,24 @@ If the formal Phase 1 flow also needs to change, synchronize the Phase 1 section
 
 ## Example: One Platform Does Not Use Sub-Agents
 
-If the user wants only one platform to avoid sub-agents, first confirm whether that platform has a separate group in the workflow. Then change Phase 2 routing for that platform group instead of deleting all `trellis-implement` / `trellis-check` instructions across platforms.
+If the user wants only one platform to avoid sub-agents, first confirm whether that platform has a separate group in the workflow. Then change Phase 2 routing for that platform group instead of deleting all `cstl-implement` / `cstl-check` instructions across platforms.
 
-## `/trellis:continue` Route Table
+## `cstl-continue` Route Table
 
-`/trellis:continue` resumes a task by deciding which phase step to load next. The decision combines `task.json.status` with the presence of artifacts inside the task directory. The mapping is fixed in the command itself; forks that add custom statuses must extend both the workflow.md tag block and this table.
+`cstl-continue` (the continue skill; legacy projects may still invoke it as the `/cstl:continue` slash command) resumes a task by deciding which phase step to load next. The decision combines `task.json.status` with the presence of artifacts inside the task directory. The mapping is fixed in the skill itself; forks that add custom statuses must extend both the workflow.md tag block and this table.
 
 | `status` | Artifact state | Resume at |
 | --- | --- | --- |
-| `planning` | `prd.md` missing | Phase 1.1 (load `trellis-brainstorm`) |
-| `planning` | lightweight task with `prd.md` complete | run `task.py start-execution <task> --check`, ask for explicit execution approval, then run `--approved` |
-| `planning` | complex task missing `design.md` or `implement.md` | complete missing planning artifacts |
-| `planning` | complex task has `prd.md`, `design.md`, and `implement.md` | run `task.py start-execution <task> --check`, ask for explicit execution approval, then run `--approved` |
-| `in_progress` | no implementation in conversation history | Phase 2.1 (`trellis-implement`) |
-| `in_progress` | implementation done, no `trellis-check` run | Phase 2.2 (`trellis-check`) |
+| `planning` | `prd.md` missing | Phase 1.1 (load `cstl-brainstorm`) |
+| `planning` | lightweight task with `prd.md` complete | run `task.py start-execution <task> --check`, ask for explicit execution approval, then run `--approved` |
+| `planning` | complex task missing `design.md` or `implement.md` | complete missing planning artifacts |
+| `planning` | complex task has `prd.md`, `design.md`, and `implement.md` | run `task.py start-execution <task> --check`, ask for explicit execution approval, then run `--approved` |
+| `in_progress` | no implementation in conversation history | Phase 2.1 (`cstl-implement`) |
+| `in_progress` | implementation done, no `cstl-check` run | Phase 2.2 (`cstl-check`) |
 | `in_progress` | check passed | Phase 3.1 (verify quality + spec update) |
-| `completed` | task is still in active tree | Phase 3.5 (run `/trellis:finish-work` to archive) |
+| `completed` | task is still in active tree | Phase 3.5 (run `cstl-finish-work` to archive) |
 
-When you add a custom status (e.g. `in-review`), add a `[workflow-state:in-review]` block in `.trellis/workflow.md` for the per-turn breadcrumb AND extend this route table — usually by editing the `/trellis:continue` command file (`.{platform}/commands/trellis/continue.md` or equivalent) to add a row that decides where to resume from. Without the route entry, `/trellis:continue` will fall through to a default branch and the user will not land on the step you intended.
+When you add a custom status (e.g. `in-review`), add a `[workflow-state:in-review]` block in `.trellis/workflow.md` for the per-turn breadcrumb AND extend this route table — usually by editing the `cstl-continue` skill (`.cursor/skills/cstl-continue/` or the equivalent command file) to add a row that decides where to resume from. Without the route entry, the resume flow will fall through to a default branch and the user will not land on the step you intended.
 
 ## Notes
 

package/dist/templates/common/bundled-skills/{trellis-meta → cstl-meta}/references/customize-local/overview.md

@@ -1,55 +1,55 @@
-# Local Customization Overview
-
-This directory is for local AI working in a user project where Trellis was installed through npm and `trellis init` has already been run. The AI should modify generated `.trellis/` and platform directories inside the project, not Trellis CLI upstream source code.
-
-## First Determine What The User Actually Wants To Change
-
-| User wording | Read first |
-| --- | --- |
-| "Change the Trellis flow / phases / next prompt" | `change-workflow.md` |
-| "Change task creation, status, archive, or hooks" | `change-task-lifecycle.md` |
-| "AI did not read context / change injected content" | `change-context-loading.md` |
-| "A platform hook is not behaving as expected" | `change-hooks.md` |
-| "Change implement/check/research agent behavior" | `change-agents.md` |
-| "Add a skill/command/workflow/prompt" | `change-skills-or-commands.md` |
-| "Adjust the project spec structure" | `change-spec-structure.md` |
-| "Add team conventions and local notes" | `add-project-local-conventions.md` |
-
-## General Operation Order
-
-1. **Confirm platform and directories**: inspect which directories exist; on a fresh `trellis init --cursor` only `.cursor/` and `.trellis/` are created.
-2. **Confirm the selected task**: run `python3 ./.trellis/scripts/task.py selected --source`.
-3. **Read the local source of truth**: prefer `.trellis/workflow.md`, `.trellis/config.yaml`, and relevant platform files.
-4. **Modify narrowly**: edit only files related to the user's request.
-5. **Synchronize semantics**: if a shared flow changes, check whether platform entry points also need changes; if a platform entry changes, check whether `.trellis/workflow.md` still agrees.
-
-## Local File Priority
-
-| Layer | Files |
-| --- | --- |
-| Workflow | `.trellis/workflow.md` |
-| Project configuration | `.trellis/config.yaml` |
-| Task material | `.trellis/tasks/<task>/` |
-| Project specs | `.trellis/spec/` |
-| Runtime scripts | `.trellis/scripts/` |
-| Platform integration | `.cursor/` plus legacy adapter directories preserved by `trellis update` |
-| Shared skill | `.agents/skills/` |
-
-## Things Not To Do By Default
-
-- Do not edit the global npm install directory.
-- Do not edit `node_modules/@blxzer/cursor-trellis`.
-- Do not assume the user has the Trellis GitHub repository.
-- Do not overwrite local files already modified by the user with default templates.
-- Do not put team project rules into public `trellis-meta`; project rules belong in `.trellis/spec/` or a local skill.
-
-## When To Inspect Upstream Source
-
-Switch to an upstream source-code perspective only when the user explicitly expresses one of these goals:
-
-- "I want to open a PR to Trellis"
-- "I want to change npm package publish contents"
-- "I want to fork Trellis"
-- "I want to modify the generation logic for `trellis init/update`"
-
-Otherwise, default to modifying local Trellis files inside the user project.
+# Local Customization Overview
+
+This directory is for local AI working in a user project where Trellis was installed through npm and `cstl init` has already been run. The AI should modify generated `.trellis/` and platform directories inside the project, not Trellis CLI upstream source code.
+
+## First Determine What The User Actually Wants To Change
+
+| User wording | Read first |
+| --- | --- |
+| "Change the Trellis flow / phases / next prompt" | `change-workflow.md` |
+| "Change task creation, status, archive, or hooks" | `change-task-lifecycle.md` |
+| "AI did not read context / change injected content" | `change-context-loading.md` |
+| "A platform hook is not behaving as expected" | `change-hooks.md` |
+| "Change implement/check/research agent behavior" | `change-agents.md` |
+| "Add a skill/command/workflow/prompt" | `change-skills-or-commands.md` |
+| "Adjust the project spec structure" | `change-spec-structure.md` |
+| "Add team conventions and local notes" | `add-project-local-conventions.md` |
+
+## General Operation Order
+
+1. **Confirm platform and directories**: inspect which directories exist; on a fresh `cstl init --cursor` only `.cursor/` and `.trellis/` are created.
+2. **Confirm the selected task**: run `python3 ./.trellis/scripts/task.py selected --source`.
+3. **Read the local source of truth**: prefer `.trellis/workflow.md`, `.trellis/config.yaml`, and relevant platform files.
+4. **Modify narrowly**: edit only files related to the user's request.
+5. **Synchronize semantics**: if a shared flow changes, check whether platform entry points also need changes; if a platform entry changes, check whether `.trellis/workflow.md` still agrees.
+
+## Local File Priority
+
+| Layer | Files |
+| --- | --- |
+| Workflow | `.trellis/workflow.md` |
+| Project configuration | `.trellis/config.yaml` |
+| Task material | `.trellis/tasks/<task>/` |
+| Project specs | `.trellis/spec/` |
+| Runtime scripts | `.trellis/scripts/` |
+| Platform integration | `.cursor/` plus legacy adapter directories preserved by `cstl update` |
+| Shared skill | `.agents/skills/` |
+
+## Things Not To Do By Default
+
+- Do not edit the global npm install directory.
+- Do not edit `node_modules/@blxzer/cursor-trellis`.
+- Do not assume the user has the Trellis GitHub repository.
+- Do not overwrite local files already modified by the user with default templates.
+- Do not put team project rules into public `cstl-meta`; project rules belong in `.trellis/spec/` or a local skill.
+
+## When To Inspect Upstream Source
+
+Switch to an upstream source-code perspective only when the user explicitly expresses one of these goals:
+
+- "I want to open a PR to Trellis"
+- "I want to change npm package publish contents"
+- "I want to fork Trellis"
+- "I want to modify the generation logic for `cstl init/update`"
+
+Otherwise, default to modifying local Trellis files inside the user project.