dynacat-dashboard-planning

name	dynacat-dashboard-planning
description	Create complete approval-ready architecture plans for Glance or Dynacat dashboards. Use after discovery, when the user asks for a dashboard architecture, redesign plan, implementation plan, Glance vs Dynacat recommendation, modular folder layout, service integration matrix, Mermaid diagrams, ASCII layout previews, or human-in-the-loop approval document.

Dynacat Dashboard Planning

Purpose

Produce the mandatory planning document before code generation. Act as solution architect, infrastructure consultant, dashboard UX designer, and homelab observability engineer.

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.

Inputs

Use the discovery summary when available. If discovery is missing, perform only the minimum needed discovery before planning, then continue.

Inputs may include:

• current Glance or Dynacat configs
• screenshots
• repository tree
• Docker Compose files
• widget YAMLs
• service inventory
• user goals, constraints, and non-goals

Workflow

Progress:

• Load discovery summary or gather minimum missing discovery.
• Check source references only when schema, widget, or platform behavior matters.
• Draft the planning document with required sections.
• Include diagrams and layout previews.
• Self-check against the approval gate and required sections.
• Stop and ask for approval.

Required Planning Document

Generate a complete Markdown document with these sections:

1. Executive Summary
2. Goals
3. Current Problems, if this is an existing setup
4. Proposed Improvements
5. Platform Recommendation: Glance vs Dynacat analysis
6. Page Hierarchy
7. Widget Hierarchy
8. Service Integration Matrix
9. Folder Structure
10. Docker Architecture
11. Backend API Design
12. Caching Strategy
13. Theme Strategy
14. Performance Considerations
15. Security Considerations
16. Mobile Responsiveness Strategy
17. Future Expansion Plan
18. Acceptance Criteria
19. Migration and Rollback Plan, if this is an existing dashboard
20. Open Questions and Approval Request

Visual Requirements

Include:

• Mermaid service dependency graph
• Mermaid page hierarchy
• Mermaid widget/API communication flow when API-backed widgets exist
• ASCII layout previews
• column layout previews
• widget grouping previews

Architecture Rules

The plan must be modular and support:

• reusable widgets
• optional services
• feature toggles
• environment variables
• .env.example
• secret management
• multi-environment deployment
• dark and light themes
• compact and dense modes
• desktop and mobile layouts
• graceful degradation when services or APIs fail

Gotchas

• Do not produce implementation files during planning, even if the user asks to move quickly.
• Do not invent include syntax or YAML structure; defer exact syntax until verified against source references.
• If requirements fit Glance better, recommend Glance even when the user initially mentioned Dynacat, and vice versa.
• Keep target-state architecture separate from current-state findings for existing dashboards.

Service Integration Matrix

Use this table shape:

Service	Purpose	API	Auth	Widgets	Polling/Cache	Failure State

Approval Gate

Stop after the planning document. Ask the user to approve the architecture before implementation.

Do not generate code, YAML, Docker files, or repository structure until the user explicitly approves the plan.