City-Lifeline-Cockpit/dynamic-component-service-master/.claude/skills/tvt-dc-service/SKILL.md

---

name: tvt-dc-service

description: Build or modify a dynamic component in this dynamic-component-service repository. Use when working on a single component or component capability here and you need to follow the repo's OpenSpec workflow, tresjs/three implementation style, dcsConfig registration, shader file layout, preview-layer constraints, and validation conventions.

tvtDCService

Overview

Use this skill to add, evolve, or polish a component in this repository without re-discovering the project conventions each time. Keep the work aligned with the repo constitution: component logic lives in src/components, shader sources live in src/shader/<component-name>/, public preview pages stay generic, and component registration happens through src/dcsConfig.ts.

Workflow

1. Build context first

Read these files before making assumptions:

• openspec/config.yaml
• src/dcsConfig.ts
• the target component file if it already exists
• nearby components in src/components/ that use similar tresjs / three patterns

If the request is more than a tiny tweak, use the local OpenSpec skills and workflow instead of jumping straight to code.

2. Keep implementation in the right layer

Default component implementation rules:

• Prefer tresjs / three semantics over DOM or CSS solutions for component visuals
• Put component code in src/components/
• Put shader code in src/shader/<component-name>/
• Split shader code into vertex and fragment files
• Keep src/views/previewEntry.vue and src/views/templateComponet.vue unchanged unless there is a real infrastructure-level reason

Do not add component-specific preview logic into the generic preview views when src/dcsConfig.ts can handle it.

3. Register the component properly

When a component is intended to be previewed and published through this service, sync all three layers:

• component props and defaults in the Vue component
• default values in src/dcsConfig.ts
• config panel schema in src/dcsConfig.ts

If you add a new prop but forget to expose it in dcsConfig.ts, the component is not really integrated into the service.

4. Treat OpenSpec as the change contract

For feature work, use OpenSpec as the source of truth:

• proposal: why this change exists
• design: architectural or implementation choices
• spec: behavior and requirements
• tasks: execution checklist

During implementation:

• read the OpenSpec context files first
• implement task by task
• mark completed tasks in the change's tasks.md
• if implementation teaches a reusable lesson, update the project rules as well as the current change

5. Validate at the right level

Use this validation order:

• build the project with npm run build
• lint the changed files directly when global lint debt is known
• run broader lint if practical
• test dev/serve only when sandbox or environment permits local ports

Be explicit when a failure is caused by repo-wide debt or sandbox limits rather than the current component change.

Checklist

Before calling the task done, confirm all of the following:

• the component works with the repo's tresjs / three style
• shader files are externalized under src/shader/<component-name>/
• src/dcsConfig.ts contains usable defaults and config-panel controls
• generic preview view files were not modified unless truly necessary
• OpenSpec artifacts remain aligned with the final implementation
• validation status is clearly reported

Typical Requests

Requests that should trigger this skill:

• "Help me add a new dynamic component to this repo"
• "Implement a new tresjs component with shader support here"
• "Adjust the default config for an existing component in dynamic-component-service"
• "Use OpenSpec to add a component feature in this repository"