@blxzer/cursor-trellis 0.2.9 → 0.3.0

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

@@ -1,47 +1,62 @@
----
-name: trellis-micro-grill
-description: "Clarifies small underspecified Trellis requests with one high-value question at a time before direct execution. Use when a request is likely small, missing details would materially change the result, and creating a Trellis task would be premature."
----
-
-# Trellis Micro-Grill
-
-## Goal
-
-Clarify a small request just enough to execute it directly without creating Trellis task artifacts by default.
-
-## Hard Constraints
-
-- Always ask exactly one high-value question at a time.
-- Always inspect local files first when the missing answer is discoverable from the project.
-- Always include a recommended answer when enough evidence exists.
-- Always use Simplified Chinese for user-facing questions.
-- Never create Trellis task artifacts by default.
-- Never keep grilling after the request is clear enough to execute.
-- Never repeat already answered questions after escalation.
-
-## Workflow
-
-1. Confirm internally that the request is small, underspecified, and not already covered by a selected Trellis task.
-2. Inspect relevant local context first if it can answer the missing detail.
-3. Ask one question whose answer would most change the result.
-4. Include a recommended answer with the concrete tradeoff.
-5. After the user answers, summarize the clarified requirement in one or two Chinese sentences.
-6. Execute directly once the requirement is clear enough.
-
-## Escalation
-
-Escalate once when the clarified work no longer fits Micro-Grill:
-
-- Use Lite Task when there is one independently verifiable deliverable that needs persistence, review, or continuation.
-- Use Full Task when one deliverable has broad impact, platform-adapter changes, external research dependency, or durable design risk.
-- Use Parent/Child when there are multiple independently verifiable deliverables, staged execution, parallel execution, or Parent-controlled integration needs.
-
-When escalating, hand the clarified answers into `trellis-brainstorm` and update Trellis artifacts there.
-
-## When NOT to Use
-
-- Do not use for multi-deliverable work.
-- Do not use for cross-platform workflow changes.
-- Do not use for risky refactors, migrations, prompt deployments, or durable architecture decisions.
-- Do not use when the request is already clear enough to execute.
-- Do not use when there is already a selected Trellis task for the work.
+---
+name: cstl-micro-grill
+description: "Clarifies small underspecified Trellis requests with one high-value question at a time before direct execution. Use when a request is likely small, missing details would materially change the result, and creating a Trellis task would be premature."
+---
+
+# Trellis Micro-Grill
+
+## Goal
+
+Clarify a small request just enough to execute it directly without creating Trellis task artifacts by default.
+
+## Hard Constraints
+
+- Always ask exactly one high-value question at a time.
+- Always inspect local files first when the missing answer is discoverable from the project.
+- Always include a recommended answer when enough evidence exists.
+- Always use Simplified Chinese for user-facing questions.
+- Never create Trellis task artifacts by default.
+- Never keep grilling after the request is clear enough to execute.
+- Never repeat already answered questions after escalation.
+
+## Thinking Principles
+
+These two principles shape *which* question is worth asking and *what* to recommend — apply them inside the one-question-per-message contract above.
+
+### First Principles
+
+Pick the question whose answer most changes the result by tracing the request back to its root user value, not to how similar requests are usually handled.
+
+- Separate the **root need** from **inherited shape** ("I want X like Y") — grill the root need first.
+- Prefer the question that, once answered, collapses the most other candidate questions.
+
+### Occam's Razor
+
+Your recommended answer defaults to the **minimal sufficient** option that still satisfies the likely acceptance bar. Complexity must be justified by evidence you can cite, not added speculatively. If two clarifications are equally valid, recommend the simpler one.
+
+## Workflow
+
+1. Confirm internally that the request is small, underspecified, and not already covered by a selected Trellis task.
+2. Inspect relevant local context first if it can answer the missing detail.
+3. Ask one question whose answer would most change the result.
+4. Include a recommended answer with the concrete tradeoff.
+5. After the user answers, summarize the clarified requirement in one or two Chinese sentences.
+6. Execute directly once the requirement is clear enough.
+
+## Escalation
+
+Escalate once when the clarified work no longer fits Micro-Grill:
+
+- Use Lite Task when there is one independently verifiable deliverable that needs persistence, review, or continuation.
+- Use Full Task when one deliverable has broad impact, platform-adapter changes, external research dependency, or durable design risk.
+- Use Parent/Child when there are multiple independently verifiable deliverables, staged execution, parallel execution, or Parent-controlled integration needs.
+
+When escalating, hand the clarified answers into `cstl-brainstorm` and update Trellis artifacts there.
+
+## When NOT to Use
+
+- Do not use for multi-deliverable work.
+- Do not use for cross-platform workflow changes.
+- Do not use for risky refactors, migrations, prompt deployments, or durable architecture decisions.
+- Do not use when the request is already clear enough to execute.
+- Do not use when there is already a selected Trellis task for the work.

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

@@ -1,44 +1,44 @@
----
-name: trellis-skill-creator
-description: "Create or improve Trellis-compatible agent skills. Use when the user asks to author a project-local skill, shared .agents skill, platform-specific skill, or upstream Trellis bundled skill."
----
-
-# Trellis Skill Creator
-
-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 `trellis-meta` first when the user needs to understand or customize `.trellis/`, hooks, settings, commands, prompts, workflows, agents, or platform directory layout.
-
-## Hard Constraints
-
-- Always inspect existing skill directories and platform conventions before creating or changing a skill.
-- Always keep `SKILL.md` short, English-language, and focused on trigger, constraints, workflow, references, and boundaries.
-- Always use lowercase letters, numbers, and hyphens in the frontmatter `name`.
-- Always write a trigger-rich frontmatter `description` that states what the skill does and when it should trigger.
-- Always place safety, sequencing, and reliability rules in a `## Hard Constraints` section before `## Workflow`.
-- Always move long guidance, examples, prompts, and reference material into directly linked files.
-- Always make helper scripts deterministic, runnable from the skill directory, and explicit about inputs and outputs.
-- Never duplicate `trellis-meta` architecture guidance or project-private conventions inside a public Trellis skill.
-- Never edit Cursor's built-in `create-skill`; create or update Trellis-compatible skill files instead.
-
-## Workflow
-
-1. Classify the target skill location and read `references/trellis-skill-locations.md`.
-2. Gather the skill purpose, trigger scenarios, target users, required tools, output shape, and existing local patterns.
-3. Draft or revise `SKILL.md` using `references/authoring-rules.md`.
-4. Add `references/`, `examples/`, `prompts/`, or `scripts/` only when they reduce entry-file size or make execution more deterministic.
-5. Verify the result with `references/review-checklist.md`.
-6. Report changed files, validation performed, and any boundaries or follow-up work.
-
-## References
-
-- `references/trellis-skill-locations.md`: Choose project-local, shared, platform-specific, or upstream bundled skill locations.
-- `references/authoring-rules.md`: Frontmatter, trigger descriptions, hard constraints, progressive disclosure, deterministic scripts, and anti-patterns.
-- `references/review-checklist.md`: Final quality checklist before handing off a skill change.
-
-## When NOT To Use
-
-- Do not use for general Trellis architecture discovery; use `trellis-meta`.
-- Do not use for project coding conventions that belong in `.trellis/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.
+---
+name: cstl-skill-creator
+description: "Create or improve Trellis-compatible agent skills. Use when the user asks to author a project-local skill, shared .agents skill, platform-specific skill, or upstream Trellis bundled skill."
+---
+
+# Trellis Skill Creator
+
+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.
+
+## Hard Constraints
+
+- Always inspect existing skill directories and platform conventions before creating or changing a skill.
+- Always keep `SKILL.md` short, English-language, and focused on trigger, constraints, workflow, references, and boundaries.
+- Always use lowercase letters, numbers, and hyphens in the frontmatter `name`.
+- Always write a trigger-rich frontmatter `description` that states what the skill does and when it should trigger.
+- Always place safety, sequencing, and reliability rules in a `## Hard Constraints` section before `## Workflow`.
+- Always move long guidance, examples, prompts, and reference material into directly linked files.
+- Always make helper scripts deterministic, runnable from the skill directory, and explicit about inputs and outputs.
+- Never duplicate `cstl-meta` architecture guidance or project-private conventions inside a public Trellis skill.
+- Never edit Cursor's built-in `create-skill`; create or update Trellis-compatible skill files instead.
+
+## Workflow
+
+1. Classify the target skill location and read `references/cstl-skill-locations.md`.
+2. Gather the skill purpose, trigger scenarios, target users, required tools, output shape, and existing local patterns.
+3. Draft or revise `SKILL.md` using `references/authoring-rules.md`.
+4. Add `references/`, `examples/`, `prompts/`, or `scripts/` only when they reduce entry-file size or make execution more deterministic.
+5. Verify the result with `references/review-checklist.md`.
+6. Report changed files, validation performed, and any boundaries or follow-up work.
+
+## References
+
+- `references/cstl-skill-locations.md`: Choose project-local, shared, platform-specific, or upstream bundled skill locations.
+- `references/authoring-rules.md`: Frontmatter, trigger descriptions, hard constraints, progressive disclosure, deterministic scripts, and anti-patterns.
+- `references/review-checklist.md`: Final quality checklist before handing off a skill change.
+
+## 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 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/{trellis-skill-creator → cstl-skill-creator}/references/authoring-rules.md

@@ -1,97 +1,97 @@
-# Skill Authoring Rules
-
-Use these rules when creating or reviewing a Trellis-compatible skill.
-
-## Required Shape
-
-Every active skill directory needs a `SKILL.md` with YAML frontmatter:
-
-```markdown
----
-name: skill-name
-description: Specific capability and trigger scenarios.
----
-```
-
-Rules:
-
-- Use lowercase letters, numbers, and hyphens in `name`.
-- Write `description` in third person because platforms inject it into tool or skill discovery prompts.
-- Include both what the skill does and when it should trigger.
-- Keep `SKILL.md` under 500 lines and usually far shorter.
-- Keep `SKILL.md` in English unless the target platform or user explicitly requires another language.
-
-## Description Quality
-
-The description is the trigger surface. It should contain concrete task nouns and user-intent phrases.
-
-Good:
-
-```yaml
-description: "Create or improve Trellis-compatible agent skills. Use when the user asks to author a project-local skill, shared .agents skill, platform-specific skill, or upstream Trellis bundled skill."
-```
-
-Avoid:
-
-```yaml
-description: "Helps with skills."
-```
-
-Checklist:
-
-- Names the capability.
-- Names common trigger situations.
-- Avoids first person.
-- Avoids broad utility wording such as "helper", "tools", or "useful".
-- Does not claim support for platforms or files the skill does not cover.
-
-## Hard Constraints
-
-Put a `## Hard Constraints` section near the top, before `## Workflow`, when the skill has safety, sequencing, scope, or reliability rules.
-
-Write constraints as imperative one-liners:
-
-- Always inspect local files before editing.
-- Never modify global configuration without explicit user approval.
-- Always run the validator before final output.
-
-Do not bury constraints in paragraphs. Do not repeat the same rule in another section; make Hard Constraints the single source of truth.
-
-## Progressive Disclosure
-
-`SKILL.md` should route, not carry every detail.
-
-Good candidates for references:
-
-- Detailed authoring rules.
-- Domain background.
-- Long examples.
-- Output templates.
-- Platform-specific notes.
-- Review checklists.
-
-Keep references one level deep and link them directly from `SKILL.md`. Avoid reference chains where one reference requires reading another reference before it is useful.
-
-## Deterministic Scripts
-
-Add scripts only when they make the skill more reliable than generated ad hoc code.
-
-Script rules:
-
-- Put scripts under the owning skill directory, usually `scripts/`.
-- Expose only parameters the agent must supply.
-- Let the script decide internal paths, timestamps, defaults, and output filenames when possible.
-- Return structured JSON to stdout when the script mutates files or produces machine-readable status.
-- State whether the agent should execute the script or read it as reference.
-- Avoid shell variables or cross-step state that would not survive separate tool calls.
-
-## Common Anti-Patterns
-
-- Vague frontmatter descriptions that can trigger on unrelated work.
-- A single skill that mixes unrelated workflows.
-- `SKILL.md` files that paste long prompts or full scripts instead of linking references.
-- Rules repeated in several sections with slightly different wording.
-- Missing stop conditions for broad search or expensive loops.
-- Commands that rely on shell variables set by a previous tool call.
-- References to files, scripts, or examples that do not exist.
-- Project-private conventions added to public Trellis bundled skills.
+# Skill Authoring Rules
+
+Use these rules when creating or reviewing a Trellis-compatible skill.
+
+## Required Shape
+
+Every active skill directory needs a `SKILL.md` with YAML frontmatter:
+
+```markdown
+---
+name: skill-name
+description: Specific capability and trigger scenarios.
+---
+```
+
+Rules:
+
+- Use lowercase letters, numbers, and hyphens in `name`.
+- Write `description` in third person because platforms inject it into tool or skill discovery prompts.
+- Include both what the skill does and when it should trigger.
+- Keep `SKILL.md` under 500 lines and usually far shorter.
+- Keep `SKILL.md` in English unless the target platform or user explicitly requires another language.
+
+## Description Quality
+
+The description is the trigger surface. It should contain concrete task nouns and user-intent phrases.
+
+Good:
+
+```yaml
+description: "Create or improve Trellis-compatible agent skills. Use when the user asks to author a project-local skill, shared .agents skill, platform-specific skill, or upstream Trellis bundled skill."
+```
+
+Avoid:
+
+```yaml
+description: "Helps with skills."
+```
+
+Checklist:
+
+- Names the capability.
+- Names common trigger situations.
+- Avoids first person.
+- Avoids broad utility wording such as "helper", "tools", or "useful".
+- Does not claim support for platforms or files the skill does not cover.
+
+## Hard Constraints
+
+Put a `## Hard Constraints` section near the top, before `## Workflow`, when the skill has safety, sequencing, scope, or reliability rules.
+
+Write constraints as imperative one-liners:
+
+- Always inspect local files before editing.
+- Never modify global configuration without explicit user approval.
+- Always run the validator before final output.
+
+Do not bury constraints in paragraphs. Do not repeat the same rule in another section; make Hard Constraints the single source of truth.
+
+## Progressive Disclosure
+
+`SKILL.md` should route, not carry every detail.
+
+Good candidates for references:
+
+- Detailed authoring rules.
+- Domain background.
+- Long examples.
+- Output templates.
+- Platform-specific notes.
+- Review checklists.
+
+Keep references one level deep and link them directly from `SKILL.md`. Avoid reference chains where one reference requires reading another reference before it is useful.
+
+## Deterministic Scripts
+
+Add scripts only when they make the skill more reliable than generated ad hoc code.
+
+Script rules:
+
+- Put scripts under the owning skill directory, usually `scripts/`.
+- Expose only parameters the agent must supply.
+- Let the script decide internal paths, timestamps, defaults, and output filenames when possible.
+- Return structured JSON to stdout when the script mutates files or produces machine-readable status.
+- State whether the agent should execute the script or read it as reference.
+- Avoid shell variables or cross-step state that would not survive separate tool calls.
+
+## Common Anti-Patterns
+
+- Vague frontmatter descriptions that can trigger on unrelated work.
+- A single skill that mixes unrelated workflows.
+- `SKILL.md` files that paste long prompts or full scripts instead of linking references.
+- Rules repeated in several sections with slightly different wording.
+- Missing stop conditions for broad search or expensive loops.
+- Commands that rely on shell variables set by a previous tool call.
+- References to files, scripts, or examples that do not exist.
+- Project-private conventions added to public Trellis bundled skills.

package/dist/templates/common/bundled-skills/{trellis-skill-creator/references/trellis-skill-locations.md → cstl-skill-creator/references/cstl-skill-locations.md}

@@ -1,52 +1,52 @@
-# Trellis Skill Locations
-
-Choose the target directory before writing content. Local files are authoritative when they already exist.
-
-## Location Decision Table
-
-| User goal | Default location | Notes |
-| --- | --- | --- |
-| Add a skill for one Trellis project on Cursor | `.cursor/skills/<skill-name>/` | Default target — Trellis is Cursor-only. |
-| Add a skill shared across tools that read the agentskills.io convention | `.agents/skills/<skill-name>/` | Use only when explicitly sharing with a non-Trellis tool that reads the shared agentskills layer. New Trellis behavior stays in `.cursor/skills/`. |
-| Change an existing local Trellis skill | The existing skill directory in the user's project | Preserve local customizations and read the current `SKILL.md` first. |
-| Add a public Trellis bundled skill | `packages/cli/src/templates/common/bundled-skills/<skill-name>/` | Only when working in the Trellis source repository. Update tests that assert bundled skill installation and template tracking. |
-| Add a personal cross-project skill | User's configured global skills directory | Requires explicit user approval because it changes global behavior outside the project. |
-
-## Relationship To `trellis-meta`
-
-Use `trellis-meta` to understand where local Trellis files live and which platform entry point should be changed.
-
-Use `trellis-skill-creator` after the task is clearly about authoring or reviewing the content of a skill:
-
-- frontmatter quality
-- trigger descriptions
-- hard constraints
-- workflow shape
-- references
-- examples
-- deterministic scripts
-- final quality review
-
-Do not copy the full skill-writing guide into `trellis-meta`. `trellis-meta` should route to this skill for detailed authoring guidance.
-
-## Relationship To Cursor `create-skill`
-
-Cursor may provide its own built-in `create-skill` helper. Treat it as a platform-owned helper, not as Trellis source material to edit.
-
-For Trellis work:
-
-- Use `trellis-skill-creator` for Trellis-compatible content and multi-platform boundaries.
-- Keep the skill name `trellis-skill-creator` to avoid colliding with Cursor's built-in skill.
-- If a user explicitly asks for Cursor-only behavior, write to the local `.cursor/skills/` directory and follow the platform's current file format.
-
-## Upstream Bundled Skill Notes
-
-When adding or modifying a bundled skill in the Trellis source repository:
-
-- Do not edit `dist/` directly.
-- Keep the bundled skill public and project-agnostic.
-- Put the skill under `packages/cli/src/templates/common/bundled-skills/`.
-- Include a short `SKILL.md` and lazy-loadable references when the guidance is long.
-- Search for hard-coded bundled skill lists or tests before editing.
-- Update `trellis-meta` only to route users to the new skill where appropriate.
-- Validate template collection, platform installation, and hash tracking with focused tests.
+# Trellis Skill Locations
+
+Choose the target directory before writing content. Local files are authoritative when they already exist.
+
+## Location Decision Table
+
+| User goal | Default location | Notes |
+| --- | --- | --- |
+| Add a skill for one Trellis project on Cursor | `.cursor/skills/<skill-name>/` | Default target — Trellis is Cursor-only. |
+| Add a skill shared across tools that read the agentskills.io convention | `.agents/skills/<skill-name>/` | Use only when explicitly sharing with a non-Trellis tool that reads the shared agentskills layer. New Trellis behavior stays in `.cursor/skills/`. |
+| Change an existing local Trellis skill | The existing skill directory in the user's project | Preserve local customizations and read the current `SKILL.md` first. |
+| Add a public Trellis bundled skill | `packages/cli/src/templates/common/bundled-skills/<skill-name>/` | Only when working in the Trellis source repository. Update tests that assert bundled skill installation and template tracking. |
+| Add a personal cross-project skill | User's configured global skills directory | Requires explicit user approval because it changes global behavior outside the project. |
+
+## Relationship To `cstl-meta`
+
+Use `cstl-meta` to understand where local Trellis files live and which platform entry point should be changed.
+
+Use `cstl-skill-creator` after the task is clearly about authoring or reviewing the content of a skill:
+
+- frontmatter quality
+- trigger descriptions
+- hard constraints
+- workflow shape
+- references
+- examples
+- deterministic scripts
+- final quality review
+
+Do not copy the full skill-writing guide into `cstl-meta`. `cstl-meta` should route to this skill for detailed authoring guidance.
+
+## Relationship To Cursor `create-skill`
+
+Cursor may provide its own built-in `create-skill` helper. Treat it as a platform-owned helper, not as Trellis source material to edit.
+
+For Trellis work:
+
+- Use `cstl-skill-creator` for Trellis-compatible content and multi-platform boundaries.
+- Keep the skill name `cstl-skill-creator` to avoid colliding with Cursor's built-in skill.
+- If a user explicitly asks for Cursor-only behavior, write to the local `.cursor/skills/` directory and follow the platform's current file format.
+
+## Upstream Bundled Skill Notes
+
+When adding or modifying a bundled skill in the Trellis source repository:
+
+- Do not edit `dist/` directly.
+- Keep the bundled skill public and project-agnostic.
+- Put the skill under `packages/cli/src/templates/common/bundled-skills/`.
+- Include a short `SKILL.md` and lazy-loadable references when the guidance is long.
+- Search for hard-coded bundled skill lists or tests before editing.
+- Update `cstl-meta` only to route users to the new skill where appropriate.
+- Validate template collection, platform installation, and hash tracking with focused tests.

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

@@ -1,47 +1,47 @@
-# Skill Review Checklist
-
-Use this checklist before handing off a new or modified skill.
-
-## Frontmatter
-
-- [ ] `name` uses lowercase letters, numbers, and hyphens only.
-- [ ] `description` is third-person and trigger-rich.
-- [ ] `description` includes both what the skill does and when to use it.
-- [ ] The skill name does not collide with a platform built-in helper unless that is intentional.
-
-## Scope And Boundaries
-
-- [ ] 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.
-- [ ] The skill distinguishes local project customization from upstream Trellis source changes.
-
-## Entry File
-
-- [ ] `SKILL.md` is concise and under 500 lines.
-- [ ] `SKILL.md` contains the minimum routing and workflow needed to start.
-- [ ] `## Hard Constraints` appears before `## Workflow` when constraints exist.
-- [ ] Hard constraints are imperative one-liners.
-- [ ] The same rule is not repeated in multiple sections.
-
-## References And Assets
-
-- [ ] Long guidance lives in directly linked reference files.
-- [ ] Every referenced file, script, prompt, or example exists.
-- [ ] Reference paths are relative to the skill directory.
-- [ ] Examples demonstrate a complete workflow boundary, not just a fragment.
-
-## Scripts
-
-- [ ] Scripts are necessary for determinism, not decorative.
-- [ ] Scripts expose only necessary parameters.
-- [ ] Scripts do not rely on shell variables or state from a previous tool call.
-- [ ] Scripts return structured JSON when they mutate files or provide machine-readable status.
-- [ ] Syntax checks were run for modified scripts when applicable.
-
-## Trellis Template Integration
-
-- [ ] Bundled skills live under `packages/cli/src/templates/common/bundled-skills/`.
-- [ ] Tests or structured checks confirm platform skill installation and template hash tracking where relevant.
-- [ ] `trellis-meta` references route to this skill where useful without duplicating full authoring rules.
-- [ ] `dist/` was not edited as source.
+# Skill Review Checklist
+
+Use this checklist before handing off a new or modified skill.
+
+## Frontmatter
+
+- [ ] `name` uses lowercase letters, numbers, and hyphens only.
+- [ ] `description` is third-person and trigger-rich.
+- [ ] `description` includes both what the skill does and when to use it.
+- [ ] The skill name does not collide with a platform built-in helper unless that is intentional.
+
+## Scope And Boundaries
+
+- [ ] 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.
+- [ ] The skill distinguishes local project customization from upstream Trellis source changes.
+
+## Entry File
+
+- [ ] `SKILL.md` is concise and under 500 lines.
+- [ ] `SKILL.md` contains the minimum routing and workflow needed to start.
+- [ ] `## Hard Constraints` appears before `## Workflow` when constraints exist.
+- [ ] Hard constraints are imperative one-liners.
+- [ ] The same rule is not repeated in multiple sections.
+
+## References And Assets
+
+- [ ] Long guidance lives in directly linked reference files.
+- [ ] Every referenced file, script, prompt, or example exists.
+- [ ] Reference paths are relative to the skill directory.
+- [ ] Examples demonstrate a complete workflow boundary, not just a fragment.
+
+## Scripts
+
+- [ ] Scripts are necessary for determinism, not decorative.
+- [ ] Scripts expose only necessary parameters.
+- [ ] Scripts do not rely on shell variables or state from a previous tool call.
+- [ ] Scripts return structured JSON when they mutate files or provide machine-readable status.
+- [ ] Syntax checks were run for modified scripts when applicable.
+
+## Trellis Template Integration
+
+- [ ] Bundled skills live under `packages/cli/src/templates/common/bundled-skills/`.
+- [ ] Tests or structured checks confirm platform skill installation and template hash tracking where relevant.
+- [ ] `cstl-meta` references route to this skill where useful without duplicating full authoring rules.
+- [ ] `dist/` was not edited as source.

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

@@ -1,5 +1,5 @@
 ---
-name: trellis-spec-bootstrap
+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."
 ---