fft-dashboard-ops
- Repo stars 3
- Author updated Live
- Author repo FFT_nano
- Domain
- Engineering
- Compatible agents
-
- Claude Code
- Cursor
- Cline
- Codex
- Windsurf
- Gemini CLI
- +20
- Trust score
- 88 / 100 · community maintained
- Author / version / license
- @0-CYBERDYNE-SYSTEMS-0 · no license declared
- Token usage
- Lean
- Setup complexity
- Guided setup
- External API key
- Not required
- Operating systems
- Unspecified (assume cross-platform)
- Runtime requirements
- No special requirements
- Permissions
-
- Read-only
- Write / modify
- Shell exec
- Network behavior
- Local-only
- Install commands
- 26 variants
Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.
Heads up: 未限定 allowed-tools，默认拥有全部工具权限。
---
name: fft-dashboard-ops
description: Build and apply Home Assistant Lovelace dashboards from templates using a staged workflow with s…
category: engineering
runtime: no special runtime
---
# fft-dashboard-ops output preview
## PART A: Task fit
- Use case: Build and apply Home Assistant Lovelace dashboards from templates using a staged workflow with screenshot verification and context-reactive themes. Use when creating or revising Home Assistant Lovelace dashboards. runs entirely locally. Works with Claude Code, Cursor, Cline and 23 more..
- Inputs: target material, constraints, expected output, and acceptance criteria.
- Evidence boundary: follow “When to use this skill / When not to use this skill / Guardrails” and do not present inference as author intent.
## PART B: Execution result
- **01** The card summarizes the use case; runtime output centers on “Build and apply Home Assistant Lovelace dashboards from templates using a staged workflow with screenshot verification and context-reactive themes. Use when creating or revising Home Assistant Lovelace dashboards. runs entirely locally. Works with Claude Code, Cursor, Cline and 23 more.”.
- **02** When the source has headings, the agent prioritizes “When to use this skill / When not to use this skill / Guardrails” so the result follows the author’s structure.
- **03** Typical output includes task judgment, concrete steps, required commands or file edits, validation, and follow-up options.
- **04** Risk context follows the fingerprint: read files, write/modify files, run shell commands; mostly runs locally; usually needs no extra API key.
## Running Rules
- read files, write/modify files, run shell commands; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding scope.
- Return the result, validation criteria, and next iteration options. Choose the trigger
The source mentions slash commands such as `/workspace`; use them first when your agent supports command triggers.
Provide inputs and boundaries
Name target files or source material, expected output, forbidden changes, and whether network or shell access is allowed. Permission fingerprint: read files, write/modify files, run shell commands.
Validate with a small run
Start with a small task and check whether the result follows “When to use this skill / When not to use this skill / Guardrails”. Inspect diffs, logs, previews, or tests before expanding scope.
Review before delivery
Confirm the final output includes a concrete result, evidence, and next action. If it stays generic, tighten inputs, boundaries, and acceptance criteria.
---
name: fft-dashboard-ops
description: Build and apply Home Assistant Lovelace dashboards from templates using a staged workflow with s…
category: engineering
source: 0-CYBERDYNE-SYSTEMS-0/FFT_nano
---
# fft-dashboard-ops
## When to use
- Build and apply Home Assistant Lovelace dashboards from templates using a staged workflow with screenshot verification…
- Use it when the task has clear inputs, repeatable steps, and validation criteria.
## What to provide
- Target material, scope, expected result, and forbidden changes.
- Whether network, commands, file writes, or external services are allowed.
## Execution rules
- Organize steps around “When to use this skill / When not to use this skill / Guardrails” and keep inference separate from source facts.
- read files, write/modify files, run shell commands; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding the task.
## Output requirements
- Return the deliverable, key evidence, validation method, and next action.
- Mark missing information as unknown; do not invent commands, platforms, or dependencies. Evidence boundary and execution chain
The author source anchors workflow facts; repository files anchor sources and commands; Fluxly only adds fit, limitations, and quality judgment.
skill "fft-dashboard-ops" {
input -> user goal + target files + boundaries + acceptance criteria
context -> When to use this skill / When not to use this skill / Guardrails
rules -> SKILL.md triggers / order / output contract
runtime -> no special runtime | read files, write/modify files, run shell commands | mostly runs locally
guardrails -> usually needs no extra API key + small-sample validation + diff/log review
output -> copyable result + checklist + next iteration
}FFT Dashboard Ops
Use this skill for generating, staging, applying, and validating farm dashboards.
When to use this skill
- Use when creating or revising Home Assistant Lovelace dashboards.
- Use when applying dashboard changes through staged files and screenshot checks.
- Use when adapting dashboard layout to live farm-state context.
When not to use this skill
- Do not use for direct live YAML edits in Home Assistant config.
- Do not use for non-dashboard automation or device control requests.
- Do not use outside main/admin chat for dashboard apply operations.
- Do not use for runtime multi-card canvas composition; hand off to
fft-canvas-dynamic-ops.
Guardrails
- Never run destructive git commands unless explicitly requested.
- Preserve unrelated worktree changes.
- Dashboard apply operations are main/admin chat only.
- Always use the staging file flow; never modify live YAML directly.
Template Sources
- View/card/theme templates:
/workspace/dashboard-templates/ - Writable dashboard config mount:
/workspace/dashboard/
Use templates as a baseline, then adapt entity references using live discovery from /workspace/farm-state/devices.json.
Lovelace Structure Rules
- Top-level structure should include
titleandviews. - Each view should define
title, optionalpath, andcards. - Use supported custom cards when available:
custom:mushroom-*custom:apexcharts-card
- Prefer robust layouts (
grid,vertical-stack,horizontal-stack) with clear labels.
Workflow
- Read
/workspace/farm-state/current.jsonand/workspace/farm-state/calendar.jsonfor context. - Draft dashboard YAML to
/workspace/dashboard/ui-lovelace-staging.yaml. - Use
ha_dashboard_validatebefore apply. - Request apply via
ha_apply_dashboardwithstagingFileset to the staging path. - Request screenshot via
ha_capture_screenshotfor the relevant view. - Verify screenshot and iterate until readable and operational.
Skill Routing
- If the user asks for runtime canvas cards, card-level canvas edits, or spec-driven layout updates, use
fft-canvas-dynamic-ops. - If the user asks for full view composition, theme/view structure changes, or staged apply lifecycle management, stay in
fft-dashboard-ops.
Context-Reactive Theming
Use current.json.context.suggestedTheme to choose theme variants (for example: dawn, midday, dusk, night, storm, frost, harvest).
- High alert level: emphasize warnings/errors and simplify visual noise.
- Normal operations: prioritize trend visibility and quick actions.
- Calendar-heavy periods: feature timeline/task cards in primary views.
Safety Expectations
- Never bypass staging-to-live apply flow.
- Never execute shell-level infrastructure changes from dashboard tasks.
- Keep entity IDs explicit and avoid wildcard assumptions.
Decide Fit First
Design Intent
How To Use It
Boundaries And Review