The "Autonomous Architect DareDash" Skill

This document describes the purpose, philosophy, and recommended usage of the autonomous-architect-daredash skill, also referred to as AADD.

---

1. What AADD Is

AADD is an adaptation of the original Autonomous Architect skill for projects that must use the DareDash UI library instead of a custom Stylus-driven UI layer.

It keeps the original architectural discipline:

• Nuxt 4
• TypeScript strict
• Pinia
• Pug
• Store-First
• 3-Layer Architecture

But it changes the UI strategy completely:

• pnpm instead of Bun
• DareDash as the official UI system
• DareDash public APIs as the safe integration surface
• Pug + kebab-case as the official component-writing convention for this skill

The UI source of truth for AADD is:

• modules/daredash/docs/LLM.md
• modules/daredash/llms.md

---

2. Core Philosophy

Store-First, Not Component-First

Business logic belongs in stores, not inside visual components.

The architecture remains:

1. API Layer: execution only, no state
2. Store Layer: business logic, state, retries, errors, mutations
3. Component/Page Layer: visual orchestration using DareDash

Components should never become the place where data rules, workflow state, and fetch orchestration accumulate.

DareDash Before Custom CSS

AADD assumes the project should solve UI through DareDash first, in this order:

1. choose the right DareDash component
2. use supported attrs and documented variants
3. adjust tokens or exposed CSS variables
4. only then consider local CSS

Custom CSS is treated as an exception, not the default implementation path.

Self-Annealing

Like the original skill, AADD is expected to improve itself.

If a recurring mistake or ambiguity is discovered, the skill docs and rules should be updated so the same misuse does not happen again.

---

3. What Makes AADD Different from the Original Skill

The original Autonomous Architect assumes:

• Bun
• Stylus
• custom local layout primitives copied into the app
• a CSS/token architecture authored directly inside the project

AADD replaces that with:

• pnpm
• DareDash as a Nuxt module
• DareDash layout primitives such as dd-layout, dd-stack, dd-grid, dd-cluster
• DareDash forms, feedback, and widgets
• DareDash tokens, icons, and prefix conventions

This means AADD is not a generic frontend skill with a UI preference. It is a skill specifically tuned to generate projects that know how to use DareDash correctly.

---

4. Important DareDash Rules

Public Surface Only

Generated app code should rely only on DareDash public APIs:

• auto-registered components
• useToaster
• module options such as tokens, prefix, and debug
• appConfig.daredash.icons

Avoid internal imports such as:

• runtime/components/*
• runtime/shared/utils/*
• #dd/*
• useBaseComponent
• useThemeEditor

Prefix Awareness

The default prefix is dd, but AADD must ask what prefix the project will use.

If the prefix changes:

• component tags must change
• token references must change
• examples must change

This is mandatory because DareDash component names and CSS variables are prefix-dependent.

AADD Writing Convention

Even if some DareDash internal or LLM-facing examples use names like DdButton, AADD uses:

• Pug
• kebab-case tags

Example:

dd-button(primary) Save

Do not mix DdButton and dd-button in the same artifact.

Forms and Feedback

• Use dd-form-* only when the app flow uses vee-validate
• Use primitives such as dd-input and dd-select otherwise
• Use dd-alert for inline feedback
• Use a single global dd-toaster with useToaster for transient notifications

---

5. Recommended Use Cases

✅ Use AADD When

1. The project must use DareDash as the UI foundation.
2. The team wants a strict, reusable, scalable Nuxt architecture.
3. The project has medium or long-term maintenance expectations.
4. You want an AI architect that already understands the distinction between:
   • store logic vs visual orchestration
   • wrapper forms vs primitive inputs
   • inline feedback vs toast feedback
   • DareDash public APIs vs internal implementation details

🚫 Avoid AADD When

1. The project is intentionally UI-agnostic.
2. The team does not want to use DareDash.
3. The goal is a throwaway prototype where architectural rigor is unnecessary.
4. The team wants a CSS-first workflow with free-form component styling instead of a library-first approach.

---

6. Practical Value

AADD works best as an execution-grade architecture guide for AI-assisted project creation.

It helps ensure that generated Nuxt projects:

• keep business logic in the right place
• use SSR and hydration correctly
• use DareDash consistently
• avoid inventing unsupported props and variants
• stay coherent when the DareDash prefix changes
• resist drifting into ad hoc CSS and ad hoc component APIs

In short:

Use AADD when you want the discipline of Autonomous Architect with the real-world UI contract of DareDash.