Design Engineering

Orchestrate iterative design and frontend engineering work through research, planning, sub-agent execution, and validation loops. Use when a visual/UI task r...

Security Scan

The skill's requirements and instructions are coherent with its stated purpose (local, iterative frontend design orchestration), but a few instruction snippets (Playwright URL placeholder and an eval-based JS syntax check) deserve careful operational controls before you run it autonomously.

Purpose & Capability

Name and description align with the provided instructions and reference documents: orchestration of design/frontend work, sub-agent dispatch, validation checklists and rendering guidance. No unrelated credentials, binaries, or install steps are requested.

Instruction Scope

Overall the SKILL.md stays on-scope (work limited to project root, sub-agents confined to project). However, two practical inconsistencies/things to watch: (1) validation snippets use a Playwright page.goto("URL") placeholder while the top-level 'Scope & Safety' asserts Playwright will only target localhost — the snippet itself does not enforce localhost and could be pointed at arbitrary URLs if misused; (2) the JS syntax check uses node -e with new Function(require('fs').readFileSync(...)), which intentionally reads and evaluates file text to catch syntax errors — this is coherent for validation but is effectively an eval-like operation and should be constrained to trusted project files. These are operational risks rather than clear contradictions.

Install Mechanism

Instruction-only skill with no install spec and no code files executed during install. Lowest-risk installation footprint.

Credentials

The skill declares no environment variables, credentials, or config paths. The requested operations are filesystem and local-dev-focused, consistent with the stated purpose.

Persistence & Privilege

always is false, agent invocation is allowed (platform default). The skill does not request permanent presence or system-wide changes and does not instruct modifying other skills' configs.

Assessment

This skill appears to do what it says: orchestrate iterative frontend design work locally. Before installing/allowing autonomous runs, consider these points: (1) enforce the project-root boundary — ensure any sub-agent/file paths are constrained so they cannot read outside the intended directory; (2) when the skill uses Playwright, ensure callers bind the URL to localhost/dev servers only (do not allow arbitrary external URLs); (3) the JS syntax check uses an eval-style pattern (new Function(readFileSync(...))) — only run that against trusted project files; (4) because the skill spawns sub-agents and runs build/test commands, run an initial review of the sub-agent task descriptions and any code changes they propose before applying them automatically. If you plan to let the agent run autonomously, restrict its network permissions and filesystem scope (or require human approval for risky steps) to reduce potential misuse.

Orchestrate design-heavy frontend work that requires iteration, technical decisions, and validation. This skill is about the process — how to research, plan, build, validate, and refine — not the aesthetics (use frontend-design for that).

When to Use

• Visual work that will take multiple iterations to get right
• Choosing between technical approaches (Canvas vs SVG vs CSS, etc.)
• Coordinating sub-agents on parallel design/engineering tasks
• Refining an implementation based on user feedback
• Any frontend work where "build it and ship" isn't enough

Scope & Safety

• All file operations stay within the user's project directory — no absolute paths outside the project root
• Sub-agents operate within the project scope defined by the orchestrator and must not access files outside it
• Sub-agent outputs (file writes, research findings) are confined to the project working directory
• No credentials or external services are required
• Playwright (when used for screenshots) connects only to localhost dev servers — never to external URLs
• No data is exfiltrated or transmitted to external endpoints; all work is local

The Iteration Loop

Every design-engineering task follows this cycle:

Research → Plan → Approve → Execute → Validate → Feedback → Refine

1. Research Phase

Before touching code, understand the problem space. Spawn 2-3 research sub-agents in parallel with different lenses:

• Inspiration/reference — find examples of what we're trying to achieve
• Technical approaches — what tools/techniques solve this class of problem
• Constraints — performance, browser support, accessibility, progressive enhancement

Research agents should write findings to files within the project's working directory so context is preserved across iterations.

2. Plan Phase

Synthesize research into a concrete plan. Present to user for approval before executing. The plan should include:

• Architecture decision with rationale (not just "use X" but "use X because Y fails at Z")
• Layer/component breakdown
• What gets removed, what gets added, what stays
• Pre-mortem: "what would cause this to fail?"
• Estimated sub-agent tasks
• Horizon estimate: Count estimated steps across all sub-agents. If > 40 steps total, decompose into sub-phases of ≤ 20 steps. If 20–40 steps, insert a midpoint quality checkpoint (screenshot + integration check before proceeding). Under 20 steps, execute directly. This prevents quality collapse on complex design tasks.

3. Execute Phase

Dispatch sub-agents with focused, context-minimal tasks. Key rules in references/subagent-patterns.md.

4. Validate Phase

After sub-agents complete, the orchestrator MUST validate. Build check is necessary but not sufficient. Check integration points — see references/validation-checklist.md.

5. Feedback → Refine

Ship to user for review. Expect 2-5 iterations on visual work. Each iteration:

1. Screenshot the live result (use Playwright if available)
2. Identify specific issues from feedback
3. Make targeted fixes (don't rebuild from scratch each time)
4. Validate and redeploy

Technical Decision Framework

When choosing between rendering approaches, read references/rendering-decisions.md. Quick heuristic:

Need	Use
Static decorative pattern	CSS background-image with SVG data URI
<100 authored animated elements	Inline SVG + CSS animations
Procedural generation, >100 elements, full-page coverage	Canvas 2D
3D, heavy particle systems, post-processing	Three.js/WebGL (last resort — heavy)

Progressive Enhancement Stack

Every visual enhancement must degrade gracefully:

1. CSS baseline (always works, no JS)
2. JS-enhanced layer fades in on top
3. prefers-reduced-motion → skip animations entirely
4. Low-end device detection → reduce complexity
5. Light/dark theme awareness

Glass-Panel Pattern

For content floating over animated backgrounds:

.card {
  background: color-mix(in srgb, var(--bg-card) 50-60%, transparent);
  backdrop-filter: blur(8-12px);
  -webkit-backdrop-filter: blur(8-12px);
}

Lets animation show through while keeping text readable. Adjust blur and opacity based on background intensity.

References

• references/subagent-patterns.md — How to dispatch and validate sub-agent work
• references/validation-checklist.md — Post-execution checks that catch integration bugs
• references/rendering-decisions.md — Canvas vs SVG vs CSS decision guide with production lessons