@vpxa/aikit 0.1.4 → 0.1.6
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/package.json +1 -1
- package/packages/cli/dist/aikit-init.js +1 -1
- package/packages/cli/dist/commands/init/constants.d.ts +1 -1
- package/packages/cli/dist/commands/init/constants.js +1 -1
- package/packages/cli/dist/commands/init/user.js +1 -1
- package/packages/core/dist/index.d.ts +2 -2
- package/packages/core/dist/index.js +1 -1
- package/packages/core/dist/types.d.ts +12 -2
- package/packages/core/dist/types.js +1 -1
- package/packages/indexer/dist/incremental-indexer.d.ts +16 -0
- package/packages/indexer/dist/incremental-indexer.js +1 -1
- package/packages/indexer/dist/index.d.ts +2 -1
- package/packages/indexer/dist/index.js +1 -1
- package/packages/indexer/dist/smart-index-scheduler.d.ts +36 -0
- package/packages/indexer/dist/smart-index-scheduler.js +1 -0
- package/packages/server/dist/config.d.ts +3 -1
- package/packages/server/dist/config.js +1 -1
- package/packages/server/dist/index.js +1 -1
- package/packages/server/dist/server.d.ts +6 -2
- package/packages/server/dist/server.js +2 -2
- package/packages/server/dist/tools/context.tools.d.ts +1 -1
- package/packages/server/dist/tools/context.tools.js +2 -2
- package/packages/server/dist/tools/graph.tool.js +7 -2
- package/packages/store/dist/graph-store.interface.d.ts +42 -1
- package/packages/store/dist/index.d.ts +2 -2
- package/packages/store/dist/sqlite-graph-store.d.ts +10 -1
- package/packages/store/dist/sqlite-graph-store.js +49 -17
- package/packages/tools/dist/graph-query.d.ts +14 -2
- package/packages/tools/dist/graph-query.js +1 -1
- package/packages/tools/dist/trace.d.ts +16 -2
- package/packages/tools/dist/trace.js +2 -2
- package/scaffold/definitions/bodies.mjs +24 -0
- package/scaffold/definitions/prompts.mjs +22 -3
- package/scaffold/definitions/protocols.mjs +22 -0
- package/scaffold/general/agents/Architect-Reviewer-Alpha.agent.md +6 -0
- package/scaffold/general/agents/Architect-Reviewer-Beta.agent.md +6 -0
- package/scaffold/general/agents/Code-Reviewer-Alpha.agent.md +6 -0
- package/scaffold/general/agents/Code-Reviewer-Beta.agent.md +6 -0
- package/scaffold/general/agents/Debugger.agent.md +6 -0
- package/scaffold/general/agents/Documenter.agent.md +6 -0
- package/scaffold/general/agents/Explorer.agent.md +6 -0
- package/scaffold/general/agents/Frontend.agent.md +6 -0
- package/scaffold/general/agents/Implementer.agent.md +6 -0
- package/scaffold/general/agents/Orchestrator.agent.md +69 -0
- package/scaffold/general/agents/Planner.agent.md +18 -0
- package/scaffold/general/agents/Refactor.agent.md +6 -0
- package/scaffold/general/agents/Researcher-Alpha.agent.md +6 -0
- package/scaffold/general/agents/Researcher-Beta.agent.md +6 -0
- package/scaffold/general/agents/Researcher-Delta.agent.md +6 -0
- package/scaffold/general/agents/Researcher-Gamma.agent.md +6 -0
- package/scaffold/general/agents/Security.agent.md +6 -0
- package/scaffold/general/agents/_shared/code-agent-base.md +22 -0
- package/scaffold/general/prompts/ask.prompt.md +1 -1
- package/scaffold/general/prompts/debug.prompt.md +1 -0
- package/scaffold/general/prompts/implement.prompt.md +1 -0
- package/scaffold/general/prompts/plan.prompt.md +1 -1
- package/scaffold/general/prompts/review.prompt.md +1 -1
- package/scaffold/general/skills/frontend-design/SKILL.md +225 -0
- package/scaffold/general/skills/react/SKILL.md +297 -0
- package/scaffold/general/skills/typescript/SKILL.md +393 -0
|
@@ -128,6 +128,18 @@ Batch 2 (after batch 1):
|
|
|
128
128
|
- Charts, tables, dependency graphs → always `present`
|
|
129
129
|
- Short confirmations and questions → normal chat
|
|
130
130
|
|
|
131
|
+
## Subagent Output Relay
|
|
132
|
+
|
|
133
|
+
When subagents complete, their visual outputs (from `present`) are NOT visible to the user.
|
|
134
|
+
**You MUST relay key findings:**
|
|
135
|
+
|
|
136
|
+
1. After every subagent completes, extract key data from the returned text
|
|
137
|
+
2. If the subagent mentions charts, tables, or visual data → re-present using `present({ format: "html" })`
|
|
138
|
+
3. If the subagent returns structured findings → summarize and present to user
|
|
139
|
+
4. **Never assume the user saw subagent output** — always relay or re-present
|
|
140
|
+
|
|
141
|
+
**Rule: Every subagent batch completion MUST be followed by a user-visible summary or presentation.**
|
|
142
|
+
|
|
131
143
|
## Critical Rules
|
|
132
144
|
|
|
133
145
|
1. 🚫 **ZERO implementation** — never `editFiles`/`createFile` on source code. Always delegate.
|
|
@@ -139,6 +151,33 @@ Batch 2 (after batch 1):
|
|
|
139
151
|
7. **Never proceed without user approval** at 🛑 stops
|
|
140
152
|
8. **Max 2 retries** then escalate to user
|
|
141
153
|
|
|
154
|
+
## Delegation Enforcement
|
|
155
|
+
|
|
156
|
+
**You are a conductor, not a performer.** Before every action, run this self-check:
|
|
157
|
+
|
|
158
|
+
> Am I about to write, edit, or create source code myself? → **STOP. Delegate instead.**
|
|
159
|
+
|
|
160
|
+
### Forbidden Tools (Orchestrator must NEVER use these on source code)
|
|
161
|
+
- `replace_string_in_file` / `editFiles`
|
|
162
|
+
- `create_file` / `createFile`
|
|
163
|
+
- `multi_replace_string_in_file`
|
|
164
|
+
- `run_in_terminal` for code generation (sed, echo >>, etc.)
|
|
165
|
+
|
|
166
|
+
### Allowed Tools (Orchestrator uses these directly)
|
|
167
|
+
- `search`, `compact`, `digest`, `file_summary`, `scope_map`, `symbol`, `trace`
|
|
168
|
+
- `present`, `remember`, `stash`, `checkpoint`, `restore`
|
|
169
|
+
- `check`, `test_run`, `blast_radius`, `reindex`, `produce_knowledge`
|
|
170
|
+
- `forge_classify`, `forge_ground`, `evidence_map`
|
|
171
|
+
- `runSubagent` — your PRIMARY tool for getting work done
|
|
172
|
+
- `read_file` — ONLY to gather context for subagent prompts
|
|
173
|
+
|
|
174
|
+
### Pre-Action Gate
|
|
175
|
+
Before every tool call, verify:
|
|
176
|
+
1. Is this a **read/analysis** tool? → ✅ Proceed
|
|
177
|
+
2. Is this a **presentation/memory** tool? → ✅ Proceed
|
|
178
|
+
3. Is this a **file modification** tool? → 🚫 Delegate to subagent
|
|
179
|
+
4. Is this a **terminal command** that changes files? → 🚫 Delegate to subagent
|
|
180
|
+
|
|
142
181
|
## Skills (load on demand)
|
|
143
182
|
|
|
144
183
|
| Skill | When to load |
|
|
@@ -147,3 +186,33 @@ Batch 2 (after batch 1):
|
|
|
147
186
|
| `brainstorming` | Before creative/design work (Phase 0) |
|
|
148
187
|
| `session-handoff` | Context filling up, session ending, or major milestone |
|
|
149
188
|
| `lesson-learned` | After completing work — extract engineering principles |
|
|
189
|
+
|
|
190
|
+
## Flow-Aware Routing
|
|
191
|
+
|
|
192
|
+
At session start, check for an active flow:
|
|
193
|
+
1. Call `flow_status` to check if a flow is active
|
|
194
|
+
2. If active and status is 'active':
|
|
195
|
+
- Note the current step name and skill path
|
|
196
|
+
- Load the current step's skill file
|
|
197
|
+
- Follow its instructions for this step
|
|
198
|
+
- When step is complete, call `flow_step({ action: 'next' })`
|
|
199
|
+
3. If no active flow:
|
|
200
|
+
- Check `flow_list` for available flows
|
|
201
|
+
- Suggest starting a flow based on the task type
|
|
202
|
+
- Use `flow_start({ flow: '<name>' })` to begin
|
|
203
|
+
|
|
204
|
+
### Flow MCP Tools
|
|
205
|
+
| Tool | Purpose |
|
|
206
|
+
|------|---------|
|
|
207
|
+
| `flow_list` | List installed flows and active flow |
|
|
208
|
+
| `flow_info` | Get detailed flow info including steps |
|
|
209
|
+
| `flow_start` | Start a named flow |
|
|
210
|
+
| `flow_step` | Advance: next, skip, or redo current step |
|
|
211
|
+
| `flow_status` | Check current execution state |
|
|
212
|
+
| `flow_reset` | Clear flow state to start over |
|
|
213
|
+
|
|
214
|
+
## Flows
|
|
215
|
+
|
|
216
|
+
This project uses aikit's pluggable flow system. Check flow status with the `flow_status` MCP tool.
|
|
217
|
+
If a flow is active, follow the current step's skill instructions. Advance with `flow_step({ action: 'next' })`.
|
|
218
|
+
Use `flow_list` to see available flows and `flow_start` to begin one.
|
|
@@ -38,6 +38,18 @@ You are the **Planner**, autonomous planner that researches codebases and writes
|
|
|
38
38
|
5. **Dependency Graph** — For each phase, list dependencies. Group into parallel batches
|
|
39
39
|
6. **Present** — Show plan with open questions, complexity estimate, parallel batch layout
|
|
40
40
|
|
|
41
|
+
## Subagent Output Relay
|
|
42
|
+
|
|
43
|
+
When subagents complete, their visual outputs (from `present`) are NOT visible to the user.
|
|
44
|
+
**You MUST relay key findings:**
|
|
45
|
+
|
|
46
|
+
1. After every subagent completes, extract key data from the returned text
|
|
47
|
+
2. If the subagent mentions charts, tables, or visual data → re-present using `present({ format: "html" })`
|
|
48
|
+
3. If the subagent returns structured findings → summarize and present to user
|
|
49
|
+
4. **Never assume the user saw subagent output** — always relay or re-present
|
|
50
|
+
|
|
51
|
+
**Rule: Every subagent batch completion MUST be followed by a user-visible summary or presentation.**
|
|
52
|
+
|
|
41
53
|
## Output Format
|
|
42
54
|
|
|
43
55
|
```markdown
|
|
@@ -77,3 +89,9 @@ You are the **Planner**, autonomous planner that researches codebases and writes
|
|
|
77
89
|
| `c4-architecture` | When the plan involves architectural changes — generate C4 diagrams |
|
|
78
90
|
| `adr-skill` | When the plan involves non-trivial technical decisions — create executable ADRs |
|
|
79
91
|
| `session-handoff` | When context window is filling up, planning session ending, or major milestone completed |
|
|
92
|
+
|
|
93
|
+
## Flows
|
|
94
|
+
|
|
95
|
+
This project uses aikit's pluggable flow system. Check flow status with the `flow_status` MCP tool.
|
|
96
|
+
If a flow is active, follow the current step's skill instructions. Advance with `flow_step({ action: 'next' })`.
|
|
97
|
+
Use `flow_list` to see available flows and `flow_start` to begin one.
|
|
@@ -34,3 +34,9 @@ You are the **Refactor**, code refactoring specialist that improves structure, r
|
|
|
34
34
|
| Skill | When to load |
|
|
35
35
|
|-------|--------------|
|
|
36
36
|
| `lesson-learned` | After completing a refactor — extract principles from the before/after diff |
|
|
37
|
+
|
|
38
|
+
## Flows
|
|
39
|
+
|
|
40
|
+
This project uses aikit's pluggable flow system. Check flow status with the `flow_status` MCP tool.
|
|
41
|
+
If a flow is active, follow the current step's skill instructions. Advance with `flow_step({ action: 'next' })`.
|
|
42
|
+
Use `flow_list` to see available flows and `flow_start` to begin one.
|
|
@@ -18,3 +18,9 @@ You are **Researcher-Alpha**, the primary deep research agent. During multi-mode
|
|
|
18
18
|
| `lesson-learned` | When analyzing past changes to extract engineering principles |
|
|
19
19
|
| `c4-architecture` | When researching system architecture — produce C4 diagrams |
|
|
20
20
|
| `adr-skill` | When the research involves a technical decision — draft an ADR |
|
|
21
|
+
|
|
22
|
+
## Flows
|
|
23
|
+
|
|
24
|
+
This project uses aikit's pluggable flow system. Check flow status with the `flow_status` MCP tool.
|
|
25
|
+
If a flow is active, follow the current step's skill instructions. Advance with `flow_step({ action: 'next' })`.
|
|
26
|
+
Use `flow_list` to see available flows and `flow_start` to begin one.
|
|
@@ -18,3 +18,9 @@ You are **Researcher-Beta**, a variant of the Researcher agent. You exist to pro
|
|
|
18
18
|
| `lesson-learned` | When analyzing past changes to extract engineering principles |
|
|
19
19
|
| `c4-architecture` | When researching system architecture — produce C4 diagrams |
|
|
20
20
|
| `adr-skill` | When the research involves a technical decision — draft an ADR |
|
|
21
|
+
|
|
22
|
+
## Flows
|
|
23
|
+
|
|
24
|
+
This project uses aikit's pluggable flow system. Check flow status with the `flow_status` MCP tool.
|
|
25
|
+
If a flow is active, follow the current step's skill instructions. Advance with `flow_step({ action: 'next' })`.
|
|
26
|
+
Use `flow_list` to see available flows and `flow_start` to begin one.
|
|
@@ -18,3 +18,9 @@ You are **Researcher-Delta**, a variant of the Researcher agent. You exist to pr
|
|
|
18
18
|
| `lesson-learned` | When analyzing past changes to extract engineering principles |
|
|
19
19
|
| `c4-architecture` | When researching system architecture — produce C4 diagrams |
|
|
20
20
|
| `adr-skill` | When the research involves a technical decision — draft an ADR |
|
|
21
|
+
|
|
22
|
+
## Flows
|
|
23
|
+
|
|
24
|
+
This project uses aikit's pluggable flow system. Check flow status with the `flow_status` MCP tool.
|
|
25
|
+
If a flow is active, follow the current step's skill instructions. Advance with `flow_step({ action: 'next' })`.
|
|
26
|
+
Use `flow_list` to see available flows and `flow_start` to begin one.
|
|
@@ -18,3 +18,9 @@ You are **Researcher-Gamma**, a variant of the Researcher agent. You exist to pr
|
|
|
18
18
|
| `lesson-learned` | When analyzing past changes to extract engineering principles |
|
|
19
19
|
| `c4-architecture` | When researching system architecture — produce C4 diagrams |
|
|
20
20
|
| `adr-skill` | When the research involves a technical decision — draft an ADR |
|
|
21
|
+
|
|
22
|
+
## Flows
|
|
23
|
+
|
|
24
|
+
This project uses aikit's pluggable flow system. Check flow status with the `flow_status` MCP tool.
|
|
25
|
+
If a flow is active, follow the current step's skill instructions. Advance with `flow_step({ action: 'next' })`.
|
|
26
|
+
Use `flow_list` to see available flows and `flow_start` to begin one.
|
|
@@ -53,3 +53,9 @@ You are the **Security**, security specialist that analyzes code for vulnerabili
|
|
|
53
53
|
### Findings
|
|
54
54
|
1. **[SEVERITY]** Title — Description, file:line, remediation
|
|
55
55
|
```
|
|
56
|
+
|
|
57
|
+
## Flows
|
|
58
|
+
|
|
59
|
+
This project uses aikit's pluggable flow system. Check flow status with the `flow_status` MCP tool.
|
|
60
|
+
If a flow is active, follow the current step's skill instructions. Advance with `flow_step({ action: 'next' })`.
|
|
61
|
+
Use `flow_list` to see available flows and `flow_start` to begin one.
|
|
@@ -3,6 +3,25 @@
|
|
|
3
3
|
> This file contains shared protocols for all code-modifying agents (Implementer, Frontend, Refactor, Debugger). Each agent's definition file contains only its unique identity, constraints, and workflow. **Do not duplicate this content in agent files.**
|
|
4
4
|
|
|
5
5
|
|
|
6
|
+
## AI Kit MCP Tool Naming Convention
|
|
7
|
+
|
|
8
|
+
All tool references in these instructions use **short names** (e.g. `status`, `compact`, `search`).
|
|
9
|
+
At runtime, these are MCP tools exposed by the AI Kit server. Depending on your IDE/client, the actual tool name will be prefixed:
|
|
10
|
+
|
|
11
|
+
| Client | Tool naming pattern | Example |
|
|
12
|
+
|--------|-------------------|---------|
|
|
13
|
+
| VS Code Copilot | `mcp_<serverName>_<tool>` | `mcp_aikit_status` |
|
|
14
|
+
| Claude Code | `mcp__<serverName>__<tool>` | `mcp__aikit__status` |
|
|
15
|
+
| Other MCP clients | `<serverName>_<tool>` or bare `<tool>` | `aikit_status` or `status` |
|
|
16
|
+
|
|
17
|
+
The server name is typically `aikit` or `kb` — check your MCP configuration.
|
|
18
|
+
|
|
19
|
+
**When these instructions say** `status({})` **→ call the MCP tool whose name ends with** `_status` **and pass** `{}` **as arguments.**
|
|
20
|
+
|
|
21
|
+
If tools are deferred/lazy-loaded, load them first (e.g. in VS Code Copilot: `tool_search_tool_regex({ pattern: "aikit" })`).
|
|
22
|
+
|
|
23
|
+
---
|
|
24
|
+
|
|
6
25
|
## Invocation Mode Detection
|
|
7
26
|
|
|
8
27
|
You may be invoked in two modes:
|
|
@@ -10,6 +29,9 @@ You may be invoked in two modes:
|
|
|
10
29
|
2. **Sub-agent** (via Orchestrator) — you may have limited MCP tool access.
|
|
11
30
|
The Orchestrator provides context under "## Prior AI Kit Context" in your prompt.
|
|
12
31
|
If present, skip AI Kit Recall and use the provided context instead.
|
|
32
|
+
**Visual Output:** When running as a sub-agent, do NOT use the `present` tool (output won't reach the user).
|
|
33
|
+
Instead, include structured data (tables, findings, metrics) as formatted text in your final response.
|
|
34
|
+
The Orchestrator will re-present relevant content to the user.
|
|
13
35
|
|
|
14
36
|
**Detection:** If your prompt contains "## Prior AI Kit Context", you are in sub-agent mode.
|
|
15
37
|
|
|
@@ -0,0 +1,225 @@
|
|
|
1
|
+
# Frontend Design
|
|
2
|
+
|
|
3
|
+
> Comprehensive frontend design system — visual design thinking, typography, color, layout, motion, accessibility, performance, and anti-pattern detection. Synthesized from Anthropic's frontend-design skill, Vercel Web Interface Guidelines, and Impeccable design patterns.
|
|
4
|
+
|
|
5
|
+
## When to Use
|
|
6
|
+
|
|
7
|
+
**MANDATORY** for the Frontend agent on every task. Also use when:
|
|
8
|
+
- Building any UI component, page, or layout
|
|
9
|
+
- Styling, theming, or visual design work
|
|
10
|
+
- Reviewing UI for quality, accessibility, or design consistency
|
|
11
|
+
- User says "make it look good", "design", "UI", "styling", "responsive", "dark mode", "animation"
|
|
12
|
+
|
|
13
|
+
## Context Gathering Protocol
|
|
14
|
+
|
|
15
|
+
Before any design work, gather answers to these questions (infer from codebase if user doesn't specify):
|
|
16
|
+
|
|
17
|
+
1. **Design System** — Does one exist? Tokens, variables, component library?
|
|
18
|
+
2. **Brand Guidelines** — Colors, fonts, logo usage, tone?
|
|
19
|
+
3. **Accessibility Requirements** — WCAG level (AA default), assistive tech?
|
|
20
|
+
4. **Responsive Breakpoints** — Mobile-first? Specific breakpoints?
|
|
21
|
+
5. **Motion Preferences** — Animation budget, reduced-motion support?
|
|
22
|
+
6. **Content Model** — CMS, static, dynamic, i18n?
|
|
23
|
+
7. **Dark Mode** — Required? System preference detection?
|
|
24
|
+
8. **Target Platforms** — Desktop, mobile web, tablet, native?
|
|
25
|
+
|
|
26
|
+
## Design Thinking Process
|
|
27
|
+
|
|
28
|
+
Follow this cycle: **Understand → Explore → Evaluate → Refine**
|
|
29
|
+
|
|
30
|
+
1. **Understand** — What is the user trying to accomplish? What are the constraints?
|
|
31
|
+
2. **Explore** — Generate at minimum 2-3 distinct design directions. Name each direction. Describe the aesthetic and rationale.
|
|
32
|
+
3. **Evaluate** — Compare against requirements, accessibility, performance, and the AI Slop Test.
|
|
33
|
+
4. **Refine** — Iterate on the chosen direction. Polish details.
|
|
34
|
+
|
|
35
|
+
## Typography
|
|
36
|
+
|
|
37
|
+
### Hierarchy
|
|
38
|
+
- Use a **clear scale**: display → h1 → h2 → h3 → body → caption → overline
|
|
39
|
+
- Maximum **3 font sizes** per viewport visible at once
|
|
40
|
+
- Use `font-weight` to create hierarchy within same size
|
|
41
|
+
- Line height: 1.5 for body text, 1.2-1.3 for headings
|
|
42
|
+
- **Fluid typography**: use `clamp()` for responsive sizing — e.g., `clamp(1rem, 2.5vw, 1.5rem)`
|
|
43
|
+
|
|
44
|
+
### Rules
|
|
45
|
+
- Never use more than 2 typeface families
|
|
46
|
+
- Ensure minimum **16px** body text on mobile
|
|
47
|
+
- Use `rem` for font sizes, `em` for component-relative spacing
|
|
48
|
+
- Monospace only for code: use a dedicated code font family
|
|
49
|
+
- Set `max-width: 65ch` on text blocks for readability
|
|
50
|
+
- Use `text-wrap: balance` on headings, `text-wrap: pretty` on body
|
|
51
|
+
- Provide room for **text expansion** (50%+) for i18n
|
|
52
|
+
|
|
53
|
+
## Color
|
|
54
|
+
|
|
55
|
+
### 60-30-10 Rule
|
|
56
|
+
- **60%** — Background/surface (neutral)
|
|
57
|
+
- **30%** — Secondary/container (brand subtle)
|
|
58
|
+
- **10%** — Accent/CTA (brand strong)
|
|
59
|
+
|
|
60
|
+
### Systematic Color
|
|
61
|
+
- Define colors as design tokens with semantic names: `--color-surface`, `--color-text-primary`, `--color-accent`
|
|
62
|
+
- Every color needs **4.5:1 contrast ratio** minimum (WCAG AA) for text
|
|
63
|
+
- Non-text elements need **3:1** minimum
|
|
64
|
+
- Never rely on color alone to convey information — pair with icons, text, or patterns
|
|
65
|
+
- Test with color blindness simulators
|
|
66
|
+
|
|
67
|
+
### Dark Mode
|
|
68
|
+
- Detect system preference with `prefers-color-scheme`
|
|
69
|
+
- Don't just invert — re-design surfaces: dark surfaces get lighter elevation, reduce saturation
|
|
70
|
+
- Smooth transition between modes (CSS transitions on `background-color`, `color`)
|
|
71
|
+
- Diagrams/images: consider `filter: invert(1)` or provide alternate assets
|
|
72
|
+
- Store user preference and sync with system default
|
|
73
|
+
|
|
74
|
+
## Layout & Spacing
|
|
75
|
+
|
|
76
|
+
### Grid System
|
|
77
|
+
- Use an **8px base grid** — all spacing is a multiple of 8 (4px for tight spaces)
|
|
78
|
+
- CSS Grid for 2D layouts, Flexbox for 1D alignment
|
|
79
|
+
- Consistent spacing tokens: `--space-xs: 4px`, `--space-sm: 8px`, `--space-md: 16px`, `--space-lg: 24px`, `--space-xl: 32px`, `--space-2xl: 48px`, `--space-3xl: 64px`
|
|
80
|
+
|
|
81
|
+
### Responsive Design
|
|
82
|
+
- **Mobile-first**: design for 320px, scale up
|
|
83
|
+
- Breakpoints: only add when the layout breaks, not at device widths
|
|
84
|
+
- Use `container queries` for component-level responsiveness
|
|
85
|
+
- Fluid layouts with `minmax()`, `auto-fill`, `auto-fit`
|
|
86
|
+
- Every interactive target: minimum **44×44px** touch area (WCAG 2.5.5)
|
|
87
|
+
|
|
88
|
+
### Rules
|
|
89
|
+
- Use consistent gutters — don't mix random padding values
|
|
90
|
+
- Stacking: define a z-index scale (e.g., base: 0, dropdown: 100, modal: 200, toast: 300)
|
|
91
|
+
- Avoid magic numbers — extract to named tokens
|
|
92
|
+
|
|
93
|
+
## Motion & Animation
|
|
94
|
+
|
|
95
|
+
### Principles
|
|
96
|
+
- **Purpose before polish** — every animation must serve a purpose: orientation, feedback, continuity, or delight
|
|
97
|
+
- **Spring physics** over linear easing — use `cubic-bezier(0.175, 0.885, 0.32, 1.275)` or spring-based libraries
|
|
98
|
+
- Duration budget: micro-interactions **100-200ms**, transitions **200-400ms**, page transitions **300-500ms**
|
|
99
|
+
- Never exceed **500ms** unless it's a storytelling/onboarding animation
|
|
100
|
+
|
|
101
|
+
### Performance
|
|
102
|
+
- Animate only `transform` and `opacity` — these run on the compositor thread
|
|
103
|
+
- Never animate `width`, `height`, `top`, `left`, `margin`, `padding` (trigger layout)
|
|
104
|
+
- Use `will-change` sparingly and only before the animation starts
|
|
105
|
+
- `requestAnimationFrame` for JS animations
|
|
106
|
+
|
|
107
|
+
### Accessibility
|
|
108
|
+
- **Always respect `prefers-reduced-motion`**: reduce or remove animations when set
|
|
109
|
+
- Layout animations: use `layout` prop (Framer Motion) or FLIP technique
|
|
110
|
+
- Skeleton screens during loading — never an empty blank page
|
|
111
|
+
- Skeleton loading → content: smooth fade transition, not a hard swap
|
|
112
|
+
|
|
113
|
+
### Patterns
|
|
114
|
+
- Enter/exit transitions with stagger for lists
|
|
115
|
+
- Shared element transitions between route changes
|
|
116
|
+
- Micro-interactions on hover/focus: subtle scale, bg-color shift, shadow change
|
|
117
|
+
- Pull-to-refresh, swipe gestures (mobile) with physics-based feel
|
|
118
|
+
|
|
119
|
+
## Accessibility (WCAG AA Mandatory)
|
|
120
|
+
|
|
121
|
+
### Structure
|
|
122
|
+
- Use **semantic HTML**: `header`, `nav`, `main`, `section`, `article`, `aside`, `footer`
|
|
123
|
+
- Every `<img>` has a meaningful `alt` (or `alt=""` for decorative)
|
|
124
|
+
- Every form field has a visible `<label>` (not just placeholder)
|
|
125
|
+
- Headings form a logical hierarchy (`h1` → `h2` → `h3`, no skipping)
|
|
126
|
+
|
|
127
|
+
### Keyboard Navigation
|
|
128
|
+
- All interactive elements reachable via **Tab** key
|
|
129
|
+
- Logical tab order (follows visual reading order)
|
|
130
|
+
- Focus indicators: visible, high-contrast, never `outline: none` without replacement
|
|
131
|
+
- Escape to close modals/dropdowns, Enter/Space to activate
|
|
132
|
+
- Skip-to-content link for screen readers
|
|
133
|
+
|
|
134
|
+
### Screen Readers
|
|
135
|
+
- ARIA labels on icons-only buttons: `aria-label="Close"`
|
|
136
|
+
- Live regions for dynamic content: `aria-live="polite"` for updates, `"assertive"` for errors
|
|
137
|
+
- Landmark roles if semantic HTML is insufficient
|
|
138
|
+
- Don't use ARIA when a native HTML element works (`<button>` not `<div role="button">`)
|
|
139
|
+
|
|
140
|
+
### Testing
|
|
141
|
+
- Tab through entire flow without mouse
|
|
142
|
+
- Test with screen reader (NVDA, VoiceOver)
|
|
143
|
+
- Run Lighthouse accessibility audit
|
|
144
|
+
- Test at 200% zoom — nothing should break or overflow
|
|
145
|
+
|
|
146
|
+
## Forms
|
|
147
|
+
|
|
148
|
+
- **Instant inline validation** — validate on blur, not on every keystroke
|
|
149
|
+
- Show error messages below the field, not in an alert
|
|
150
|
+
- Preserve user input on error — never clear a form on submit failure
|
|
151
|
+
- **Auto-save** drafts for long forms (debounced)
|
|
152
|
+
- Use `inputmode` for mobile: `numeric`, `email`, `tel`, `url`
|
|
153
|
+
- Multi-step forms: show progress indicator and allow back-navigation
|
|
154
|
+
- File uploads: drag-and-drop zone, progress indicator, file type restrictions, preview
|
|
155
|
+
- **Optimistic UI**: show success immediately, revert on error
|
|
156
|
+
|
|
157
|
+
## Navigation & State
|
|
158
|
+
|
|
159
|
+
- URL should always reflect application state (`/settings/profile` not `/settings#profile`)
|
|
160
|
+
- Support deep linking — any URL should be shareable and land on the right view
|
|
161
|
+
- Breadcrumbs for hierarchical navigation (3+ levels deep)
|
|
162
|
+
- Keyboard shortcuts for power users (document them)
|
|
163
|
+
- Browser back/forward must work correctly — don't break history
|
|
164
|
+
|
|
165
|
+
## Performance
|
|
166
|
+
|
|
167
|
+
- **Virtual scroll** for lists > 100 items — don't render 10,000 DOM nodes
|
|
168
|
+
- **Lazy load** images: use `loading="lazy"`, provide dimensions to prevent layout shift
|
|
169
|
+
- **Prefetch** next-likely routes on hover/viewport intersection
|
|
170
|
+
- **Code split** by route — each page only loads its own JavaScript
|
|
171
|
+
- **Edge rendering** — render at the CDN edge when possible (SSR, RSC)
|
|
172
|
+
- Optimize images: use `<picture>` with WebP/AVIF + fallback
|
|
173
|
+
- Font loading: `font-display: swap`, preload critical fonts
|
|
174
|
+
- Target LCP < 2.5s, INP < 200ms, CLS < 0.1
|
|
175
|
+
|
|
176
|
+
## Error Handling
|
|
177
|
+
|
|
178
|
+
- **Graceful degradation** — partial failures shouldn't crash the entire page
|
|
179
|
+
- Show retry buttons on transient errors
|
|
180
|
+
- Offline indicator when network is lost
|
|
181
|
+
- Clear error messages: what happened, what the user can do about it
|
|
182
|
+
- Error boundaries in React: catch rendering errors, show fallback UI
|
|
183
|
+
- Never show raw error messages, stack traces, or error codes to users
|
|
184
|
+
|
|
185
|
+
## SSR & Hydration
|
|
186
|
+
|
|
187
|
+
- Prevent hydration mismatches: no `Date.now()`, `Math.random()`, `window` in server render
|
|
188
|
+
- Use streaming SSR for faster TTFB
|
|
189
|
+
- Optimistic mutations: update UI before server confirms
|
|
190
|
+
- Handle loading states with Suspense boundaries
|
|
191
|
+
|
|
192
|
+
## Internationalization (i18n)
|
|
193
|
+
|
|
194
|
+
- **RTL support**: use logical properties (`margin-inline-start` not `margin-left`)
|
|
195
|
+
- Format dates/numbers/currencies locale-aware — never hardcode formats
|
|
196
|
+
- Text expansion room: German/French can be 50%+ longer than English
|
|
197
|
+
- Unicode support: test with CJK, Arabic, emoji
|
|
198
|
+
- Externalize all user-visible strings
|
|
199
|
+
|
|
200
|
+
## AI Slop Test — MANDATORY CHECK
|
|
201
|
+
|
|
202
|
+
Before shipping ANY design, verify it does NOT have these AI-generated tells:
|
|
203
|
+
|
|
204
|
+
| AI Slop Pattern | What to check |
|
|
205
|
+
|-----------------|---------------|
|
|
206
|
+
| Centered hero + gradient blob | Does it look like every AI demo landing page? ADD ASYMMETRY |
|
|
207
|
+
| Lowercase geometric sans headings | Add personality: case choices, weight variation, size contrast |
|
|
208
|
+
| Purple-to-blue gradient | If using gradients, use brand-specific or creative color stops |
|
|
209
|
+
| Uniform card grid with icon + heading + text | Vary card sizes, add imagery, break the grid |
|
|
210
|
+
| Stock illustration style | Use real photos, custom illustrations, or no imagery |
|
|
211
|
+
| "Modern SaaS template" look | Add something unexpected: editorial layout, bold typography, color blocking |
|
|
212
|
+
| Generic placeholder copy | Real content or clearly marked FPO (For Placement Only) |
|
|
213
|
+
| Identical padding everywhere | Vary rhythm — tight grouping inside sections, generous between |
|
|
214
|
+
| No texture or depth | Add subtle noise, shadows, borders, layering |
|
|
215
|
+
| Perfectly symmetrical everything | Break symmetry deliberately — offset grids, varied alignments |
|
|
216
|
+
|
|
217
|
+
If 3+ items match → **STOP and redesign**. The goal is distinctive, not generic.
|
|
218
|
+
|
|
219
|
+
## Implementation Principles
|
|
220
|
+
|
|
221
|
+
1. **Design tokens before code** — define variables/tokens first, then use them everywhere
|
|
222
|
+
2. **Component boundaries** — each component owns its internal layout, parent owns its placement
|
|
223
|
+
3. **Progressive enhancement** — works without JS, enhanced with JS
|
|
224
|
+
4. **Content-first** — design with real content, not lorem ipsum
|
|
225
|
+
5. **Test in context** — view components inside the actual page, not just in isolation
|