dynacat-dashboard-implementation

name	dynacat-dashboard-implementation
description	Implement approved Glance or Dynacat dashboard architectures after human approval. Use when the user has approved a planning document and wants code, YAML, Docker Compose, modular includes, API bridge widgets, theme files, validation, local smoke tests, or final optimization review for a Glance or Dynacat dashboard project.

Dynacat Dashboard Implementation

Purpose

Turn an approved planning document into a maintainable Glance or Dynacat dashboard implementation. Do not use this skill before user approval unless the user is only asking for a small, isolated patch to an existing implementation.

Source References

Use official and project references as source-of-truth. In a repo checkout, load the shared references/source-of-truth.md when exact URLs or scope are needed. If this skill was installed standalone with npx skills, use the official Glance, community-widgets, and Dynacat repositories/docs named in the user prompt or AGENTS.md. Prefer documented Glance and Dynacat configuration patterns over invented structures.

Preconditions

Before implementing, confirm:

• the target platform is Glance or Dynacat
• the planning document has been approved
• required secrets are represented by environment variables or secret stores
• existing configs are backed up or preserved when migrating
• acceptance criteria are clear

If approval is missing, stop and route to $dynacat-dashboard-planning.

Implementation Rules

Progress:

• Confirm approval and target platform.
• Preserve or back up existing configs before migration edits.
• Implement the smallest structure that satisfies the approved plan.
• Validate config, Docker, and UI behavior where applicable.
• Fix validation failures and rerun checks.
• Report tested, not tested, and remaining risks.

Build a modular project:

• keep YAML split by pages, widgets, services, themes, and environments where the platform supports it
• avoid monolithic configs unless the selected platform requires one
• use reusable widgets and includes where documented
• use .env.example for required environment variables
• keep real secrets out of generated files
• implement loading, empty, error, timeout, and stale-data states for API-backed widgets
• optimize polling with cache TTLs, retries, and backoff
• support responsive layouts and mobile-friendly density
• support dark and light themes when requested or planned

Gotchas

• Do not hardcode secrets, internal IPs, tokens, or user-specific hostnames unless the user explicitly provides them as intended public config.
• Do not create Dockerfiles for services that are intended to use upstream images directly.
• Do not add observability stacks, auth proxies, or databases that were not approved in the plan.
• For Glance, prefer documented YAML and custom-api widget patterns over generated ad hoc schemas.
• For Dynacat, preserve documented configuration patterns and compatibility boundaries from the source references.

Validation

Run relevant checks before claiming success:

• parse generated YAML
• validate Docker Compose with docker compose config when Docker is available
• run platform-specific config validation when available
• start a local smoke test when feasible
• use browser verification for desktop and mobile layouts when a UI runs locally
• verify missing API/token failure states for custom API widgets
• report what was tested, what was not tested, and residual risks

Final Optimization Review

After implementation, produce a concise final review:

• what changed
• why it matches the approved plan
• validation results
• risks and limitations
• follow-up improvements