opencastle 0.8.2 → 0.9.1

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.
Files changed (30) hide show
  1. package/dist/cli/detect.test.d.ts +2 -0
  2. package/dist/cli/detect.test.d.ts.map +1 -0
  3. package/dist/cli/detect.test.js +255 -0
  4. package/dist/cli/detect.test.js.map +1 -0
  5. package/dist/cli/run/executor.test.d.ts +2 -0
  6. package/dist/cli/run/executor.test.d.ts.map +1 -0
  7. package/dist/cli/run/executor.test.js +297 -0
  8. package/dist/cli/run/executor.test.js.map +1 -0
  9. package/dist/cli/run/schema.js +1 -1
  10. package/dist/cli/run/schema.js.map +1 -1
  11. package/dist/cli/run/schema.test.d.ts +2 -0
  12. package/dist/cli/run/schema.test.d.ts.map +1 -0
  13. package/dist/cli/run/schema.test.js +294 -0
  14. package/dist/cli/run/schema.test.js.map +1 -0
  15. package/package.json +1 -1
  16. package/src/cli/detect.test.ts +337 -0
  17. package/src/cli/run/executor.test.ts +338 -0
  18. package/src/cli/run/schema.test.ts +343 -0
  19. package/src/cli/run/schema.ts +1 -1
  20. package/src/dashboard/node_modules/.vite/deps/_metadata.json +6 -6
  21. package/src/orchestrator/agents/session-guard.agent.md +113 -0
  22. package/src/orchestrator/agents/team-lead.agent.md +172 -569
  23. package/src/orchestrator/skills/agent-hooks/SKILL.md +14 -13
  24. package/src/orchestrator/skills/decomposition/SKILL.md +122 -0
  25. package/src/orchestrator/skills/deployment-infrastructure/SKILL.md +143 -2
  26. package/src/orchestrator/skills/documentation-standards/SKILL.md +125 -12
  27. package/src/orchestrator/skills/frontend-design/SKILL.md +152 -1
  28. package/src/orchestrator/skills/nextjs-patterns/SKILL.md +147 -24
  29. package/src/orchestrator/skills/orchestration-protocols/SKILL.md +116 -0
  30. package/src/orchestrator/skills/seo-patterns/SKILL.md +182 -24
@@ -58,17 +58,11 @@ Load relevant skills before writing code.
58
58
 
59
59
  ### Actions
60
60
 
61
- 1. **Run the Pre-Response Quality Gate**This is the single exit gate. Verify ALL items from the checklist in `general.instructions.md` § Pre-Response Quality Gate:
62
- - [ ] Lessons read at session start
63
- - [ ] Lessons captured for any retries
64
- - [ ] Discovered issues tracked (not ignored)
65
- - [ ] Lint/type/test pass (no new errors)
66
- - [ ] Session logged to `sessions.ndjson` (ALWAYS)
67
- - [ ] Delegations logged (Team Lead only)
68
- - [ ] Reviews/panels/disputes logged (if applicable)
69
- 2. **Save checkpoint** (Team Lead only) — If work is incomplete, write `.github/customizations/SESSION-CHECKPOINT.md` with current state so the next session can resume. Load **session-checkpoints** skill for format.
70
- 3. **Memory merge check** — If `LESSONS-LEARNED.md` has grown significantly (5+ new entries this session), flag for memory merge consideration.
71
- 4. **Clean up** — Remove any temporary files created during the session (e.g., test fixtures, debug outputs).
61
+ 1. **Call Session Guard** (Team Lead only) Delegate to the **Session Guard** agent with a session summary (delegations, retries, discoveries, files changed). Execute any fix commands it returns. This replaces the manual Pre-Response Quality Gate checklist — the guard runs it automatically with a fresh context window.
62
+ 2. **For specialist agents** (not Team Lead) — Run the Pre-Response Quality Gate checklist from `general.instructions.md` manually. Specialist agents don't have access to the Session Guard.
63
+ 3. **Save checkpoint** (Team Lead only) — If work is incomplete, write `.github/customizations/SESSION-CHECKPOINT.md` with current state so the next session can resume. Load **session-checkpoints** skill for format.
64
+ 4. **Memory merge check** If `LESSONS-LEARNED.md` has grown significantly (5+ new entries this session), flag for memory merge consideration.
65
+ 5. **Clean up** Remove any temporary files created during the session (e.g., test fixtures, debug outputs).
72
66
 
73
67
  ### Template for Delegation Prompts
74
68
 
@@ -80,6 +74,8 @@ Load relevant skills before writing code.
80
74
  - Clean up temp files
81
75
  ```
82
76
 
77
+ > **Note for Team Lead:** You do NOT use this template yourself. Instead, call the **Session Guard** agent (step 10 in your role). This template is only for specialist agents you delegate to.
78
+
83
79
  ---
84
80
 
85
81
  ## Hook: on-pre-delegate
@@ -115,8 +111,12 @@ Pre-Delegate:
115
111
 
116
112
  ### Actions
117
113
 
118
- 0. **Fast review (mandatory)** — Run the `fast-review` skill against the agent's output. This is a **non-skippable gate**. See the fast-review skill for the full procedure (single reviewer sub-agent, automatic retry, escalation). Only after the fast review passes do you proceed to the remaining post-delegate actions below.
119
- 1. **Verify output** — Read changed files. Check that changes stay within the agent's file partition.
114
+ 0. **Log the delegation NOW** — Append a record to `.github/customizations/logs/delegations.ndjson` immediately. Do this BEFORE review or verification logging must not depend on review passing.
115
+ ```bash
116
+ echo '{"timestamp":"...","session_id":"<branch>","agent":"...","model":"...","tier":"...","mechanism":"sub-agent","outcome":"...","retries":0,"phase":N,"file_partition":["..."]}' >> .github/customizations/logs/delegations.ndjson
117
+ ```
118
+ 1. **Fast review (mandatory)** — Run the `fast-review` skill against the agent's output. This is a **non-skippable gate**. See the fast-review skill for the full procedure (single reviewer sub-agent, automatic retry, escalation). Only after the fast review passes do you proceed to the remaining post-delegate actions below.
119
+ 2. **Verify output** — Read changed files. Check that changes stay within the agent's file partition.
120
120
  2. **Run verification** — Execute appropriate checks: lint, type-check, tests, or visual inspection.
121
121
  3. **Check acceptance criteria** — Compare output against the tracker issue's acceptance criteria. Each criterion must be independently verified.
122
122
  4. **Discovered issues tracked** — Verify the agent followed the Discovered Issues Policy. If they found issues, check that they're in KNOWN-ISSUES.md or a new tracker ticket.
@@ -127,6 +127,7 @@ Pre-Delegate:
127
127
 
128
128
  ```
129
129
  Post-Delegate:
130
+ ☐ Delegation logged to delegations.ndjson (FIRST — before anything else)
130
131
  ☐ Changed files reviewed
131
132
  ☐ Files within partition
132
133
  ☐ Lint/test/build passes
@@ -0,0 +1,122 @@
1
+ ---
2
+ name: decomposition
3
+ description: "Task decomposition patterns for the Team Lead: dependency resolution, phase assignment, delegation spec templates, prompt quality examples, and orchestration patterns."
4
+ ---
5
+
6
+ # Task Decomposition
7
+
8
+ Detailed decomposition and delegation patterns for the Team Lead. **Load at:** Decompose & Partition phase (Step 2) or when writing delegation prompts (Step 3).
9
+
10
+ ## Dependency Resolution
11
+
12
+ Declare dependencies between subtasks using arrow notation: `TaskB → TaskA` means B depends on A (A must finish first).
13
+
14
+ **Topological sort rules:**
15
+ 1. Tasks with no dependencies go in Phase 1 (can run in parallel)
16
+ 2. Tasks depending only on Phase 1 tasks go in Phase 2
17
+ 3. Continue until all tasks are assigned to phases
18
+ 4. Tasks in the same phase with no mutual dependencies run in parallel
19
+
20
+ **Cycle detection:** If A → B → C → A, break the cycle by: (a) finding a task that can partially complete independently, (b) splitting that task into an independent part and a dependent part.
21
+
22
+ **Visual example:**
23
+
24
+ ```
25
+ Dependency Graph: Execution Plan:
26
+ E → C → A Phase 1: A, B (parallel)
27
+ D → B Phase 2: C, D (parallel, depend on Phase 1)
28
+ F → C, D Phase 3: E, F (parallel, depend on Phase 2)
29
+ ```
30
+
31
+ Always draw the dependency graph before assigning phases. Missed dependencies cause agents to block on missing inputs; redundant sequencing wastes time.
32
+
33
+ ## Delegation Spec Template
34
+
35
+ For complex tasks (score 5+), generate a structured spec rather than a free-form prompt:
36
+
37
+ ```
38
+ ## Delegation Spec: [Task Title]
39
+
40
+ **Tracker Issue:** TAS-XX — [Title]
41
+ **Complexity:** [score]/13 → [tier] tier
42
+ **Agent:** [Agent Name]
43
+
44
+ ### Objective
45
+ What to build/change and why. 1-3 sentences max.
46
+
47
+ ### Context
48
+ - Key files to read first: [list]
49
+ - Related patterns to follow: [file:line references]
50
+ - Relevant lessons: [LES-XXX references from LESSONS-LEARNED.md]
51
+
52
+ ### Constraints
53
+ - File partition: Only modify files under [paths]
54
+ - Do NOT modify: [explicit exclusions]
55
+ - Dependencies: Requires [TAS-XX] to be Done first
56
+
57
+ ### Acceptance Criteria
58
+ - [ ] Criterion 1 (copied from tracker issue)
59
+ - [ ] Criterion 2
60
+ - [ ] Criterion 3
61
+
62
+ ### Expected Output
63
+ Return a structured summary with:
64
+ - Files changed (path + one-line description)
65
+ - Verification results (lint/test/build pass/fail)
66
+ - Acceptance criteria status (each item ✅/❌)
67
+ - Discovered issues (if any)
68
+ - Lessons applied or added
69
+
70
+ **Note:** Follow the Structured Output Contract from the team-lead-reference skill. Include all standard fields plus agent-specific extensions.
71
+
72
+ ### Self-Improvement
73
+ Read `.github/customizations/LESSONS-LEARNED.md` before starting. If you retry any command/tool with a different approach that works, immediately add a lesson to that file.
74
+ ```
75
+
76
+ For simpler tasks (score 1-3), the existing prompt format (objective + files + criteria) is sufficient. Don't over-engineer delegation for trivial work.
77
+
78
+ **For sub-agents** — also specify what information to return in the result message.
79
+
80
+ **For background agents** — include full self-contained context since they cannot ask follow-up questions.
81
+
82
+ ## Prompt Quality Examples
83
+
84
+ **Strong prompt (simple task, score 2):**
85
+ > "**Tracker issue:** TAS-42 — [Auth] Fix token refresh logic
86
+ > Users report 'Invalid token' errors after 30 minutes. JWT tokens are configured with 1-hour expiration in `libs/auth/src/server.ts`. Investigate why tokens expire early and fix the refresh logic. Only modify files under `libs/auth/`. Run the auth library tests to verify."
87
+
88
+ **Strong prompt (complex task, score 8):**
89
+ > Use the Delegation Spec Template above. Fill in all sections for tasks scoring 5+.
90
+
91
+ **Weak prompt:**
92
+ > "Fix the authentication bug."
93
+
94
+ ## Delegation Mechanism Selection
95
+
96
+ ```
97
+ Need result immediately?
98
+ / \
99
+ YES NO
100
+ | |
101
+ Is it a dependency Expected duration
102
+ for the next step? > 5 minutes?
103
+ / \ / \
104
+ YES NO YES NO
105
+ | | | |
106
+ Sub-Agent Sub-Agent Background Sub-Agent
107
+ (inline) (if small enough, Agent (sequential)
108
+ else Background)
109
+ ```
110
+
111
+ ## Mixed Delegation Orchestration
112
+
113
+ Combine sub-agents and background agents for maximum efficiency:
114
+
115
+ ```
116
+ Phase 1 (sub-agent): Research — gather context, identify patterns, map files
117
+ Phase 2 (background): Foundation — DB migration + Component scaffolding (parallel)
118
+ Phase 3 (sub-agent): Integration — wire components to data (needs Phase 2 results)
119
+ Phase 4 (background): Validation — Security audit + Tests + Docs (parallel)
120
+ Phase 5 (sub-agent): QA gate — verify all phases, run builds, self-review
121
+ Phase 6 (sub-agent): Panel review — load panel-majority-vote skill for high-stakes validation
122
+ ```
@@ -19,6 +19,119 @@ All deployment configuration is project-specific. See [deployment-config.md](../
19
19
  - Use short cache durations for frequently changing assets (e.g., favicon: `max-age=86400`)
20
20
  - Load the **security-hardening** skill for full header inventory and CSP configuration
21
21
 
22
+ ## Environment Variable Management
23
+
24
+ ### Layering & Precedence
25
+
26
+ Environment variables follow a layered override model (lowest to highest priority):
27
+
28
+ 1. `.env` — shared defaults, committed to repo (no secrets)
29
+ 2. `.env.local` — developer-specific overrides, git-ignored
30
+ 3. `.env.production` / `.env.preview` — environment-specific values
31
+ 4. Platform-injected variables — set in hosting dashboard, highest priority
32
+
33
+ ### Validation at Startup
34
+
35
+ Validate required variables at application startup. Fail fast with clear messages:
36
+
37
+ ```typescript
38
+ // src/lib/env.ts
39
+ import { z } from 'zod';
40
+
41
+ const envSchema = z.object({
42
+ DATABASE_URL: z.string().url(),
43
+ API_SECRET: z.string().min(32),
44
+ PUBLIC_SITE_URL: z.string().url(),
45
+ CRON_SECRET: z.string().min(16),
46
+ NODE_ENV: z.enum(['development', 'production', 'test']).default('development'),
47
+ });
48
+
49
+ export const env = envSchema.parse(process.env);
50
+ ```
51
+
52
+ ### Naming & .gitignore
53
+
54
+ - `PUBLIC_*` or `NEXT_PUBLIC_*` — safe to expose to the browser
55
+ - `SECRET_*` or `*_SECRET` — server-only, never bundled into client code
56
+ - `CRON_SECRET` — authenticates scheduled job endpoints
57
+ - Use `SCREAMING_SNAKE_CASE` for all variable names
58
+ - Always gitignore `.env.local`, `.env.*.local`, and `.env.production`
59
+
60
+ ## CI/CD Pipeline Patterns
61
+
62
+ ### Branch-Based Deployment
63
+
64
+ ```
65
+ main branch → Production deployment (auto)
66
+ feature/* → Preview deployment (auto)
67
+ fix/* → Preview deployment (auto)
68
+ ```
69
+
70
+ ### Generic Pipeline Stages
71
+
72
+ Every pipeline should include these stages in order:
73
+
74
+ 1. **Install** — restore dependencies from lockfile (`--frozen-lockfile`)
75
+ 2. **Lint** — static analysis and formatting checks
76
+ 3. **Test** — unit and integration tests with coverage
77
+ 4. **Build** — production build (catches type errors and build-time issues)
78
+ 5. **Deploy** — push artifacts to hosting platform
79
+
80
+ ### Cron Job Authentication
81
+
82
+ Protect scheduled endpoints with a shared secret:
83
+
84
+ ```typescript
85
+ // app/api/cron/route.ts
86
+ export async function GET(request: Request) {
87
+ const authHeader = request.headers.get('authorization');
88
+ if (authHeader !== `Bearer ${process.env.CRON_SECRET}`) {
89
+ return new Response('Unauthorized', { status: 401 });
90
+ }
91
+ // ... run scheduled task
92
+ return Response.json({ ok: true });
93
+ }
94
+ ```
95
+
96
+ ## Caching Strategy
97
+
98
+ ### Cache Duration Reference
99
+
100
+ | Asset Type | `Cache-Control` Header | Rationale |
101
+ |---|---|---|
102
+ | Hashed static assets (JS, CSS) | `public, max-age=31536000, immutable` | Content-addressed filenames; safe to cache forever |
103
+ | Images / fonts | `public, max-age=31536000, immutable` | Typically fingerprinted; long-lived |
104
+ | Favicon / manifest | `public, max-age=86400` | Changes rarely but should refresh within a day |
105
+ | HTML pages (SSG) | `public, max-age=0, must-revalidate` | Serve stale while revalidating |
106
+ | API responses | `private, no-cache` | User-specific or frequently changing |
107
+ | Prerendered pages (ISR) | `public, s-maxage=3600, stale-while-revalidate=86400` | CDN caches for 1 hour, serves stale for up to 1 day |
108
+
109
+ Apply cache headers via framework config (e.g., `headers()` in `next.config.js`) or CDN rules. Match each route pattern to the appropriate duration from the table above.
110
+
111
+ ## Security Headers
112
+
113
+ Apply these headers globally via framework config or middleware. See the **security-hardening** skill for full CSP configuration.
114
+
115
+ ```javascript
116
+ // Recommended security headers
117
+ const securityHeaders = [
118
+ { key: 'Strict-Transport-Security', value: 'max-age=63072000; includeSubDomains; preload' },
119
+ { key: 'X-Content-Type-Options', value: 'nosniff' },
120
+ { key: 'X-Frame-Options', value: 'DENY' },
121
+ { key: 'X-XSS-Protection', value: '1; mode=block' },
122
+ { key: 'Referrer-Policy', value: 'strict-origin-when-cross-origin' },
123
+ { key: 'Permissions-Policy', value: 'camera=(), microphone=(), geolocation=()' },
124
+ { key: 'Content-Security-Policy', value: "default-src 'self'; script-src 'self' 'unsafe-inline';" },
125
+ ];
126
+ ```
127
+
128
+ **Key rules:**
129
+
130
+ - HSTS `max-age` must be at least 1 year (31536000 seconds) for preload eligibility
131
+ - `X-Frame-Options: DENY` prevents clickjacking — use `SAMEORIGIN` only if you embed your own pages
132
+ - CSP should be as restrictive as possible; expand only when needed, document each exception
133
+ - Disable unused browser features via `Permissions-Policy`
134
+
22
135
  ## Release Process
23
136
 
24
137
  ### 1. Pre-Release Audit
@@ -31,7 +144,7 @@ All deployment configuration is project-specific. See [deployment-config.md](../
31
144
  - Identify features adjacent to changes and spot-check them
32
145
  - Run full test suites for all affected projects (not just changed files)
33
146
  - Check deployment preview builds for visual regressions
34
- - Verify critical user flows still work (homepage, search, venue detail)
147
+ - Verify critical user flows still work (e.g., primary navigation, form submissions, authenticated pages)
35
148
 
36
149
  ### 3. Changelog & Release Notes
37
150
  - Generate changelog from commit messages and PR titles since last release
@@ -48,4 +161,32 @@ All deployment configuration is project-specific. See [deployment-config.md](../
48
161
  - Confirm deployment succeeded on production
49
162
  - Smoke-test production URLs for critical pages
50
163
  - Monitor error rates and performance metrics post-release
51
- - Document rollback steps if issues arise
164
+ - Have rollback steps documented and ready (see § Rollback Procedures)
165
+
166
+ ## Rollback Procedures
167
+
168
+ **Two rollback strategies** (prefer platform-level when available):
169
+
170
+ 1. **Platform rollback** — promote the last known-good deployment from the hosting dashboard
171
+ 2. **Git revert** — `git revert -m 1 HEAD && git push origin main` (triggers a clean redeploy)
172
+
173
+ ### Rollback Checklist
174
+
175
+ - [ ] Confirm the issue is deployment-related (not a data or third-party issue)
176
+ - [ ] Roll back via platform or git revert — never force-push to `main`
177
+ - [ ] Verify the rollback deployment is healthy (smoke tests)
178
+ - [ ] Notify the team with a summary of what was rolled back and why
179
+ - [ ] Create a post-mortem ticket to investigate root cause
180
+
181
+ ## Anti-Patterns
182
+
183
+ | Anti-Pattern | Why It's Wrong | Correct Approach |
184
+ |---|---|---|
185
+ | Hardcoding secrets in source code | Secrets leak via git history, logs, and client bundles | Use environment variables; validate with Zod at startup |
186
+ | Skipping preview deployments | Bugs reach production without visual review | Deploy every branch to a preview environment |
187
+ | Using `Cache-Control: no-store` everywhere | Destroys performance; every request hits origin | Use appropriate cache durations per asset type (see table above) |
188
+ | Force-pushing to `main` to "fix" a bad deploy | Destroys git history; breaks other developers' branches | Use `git revert` to cleanly undo changes |
189
+ | Disabling security headers "temporarily" | Temporary becomes permanent; opens attack surface | Keep headers strict; expand only with documented exceptions |
190
+ | Running builds without `--frozen-lockfile` | Non-deterministic installs; works locally, fails in CI | Always use `--frozen-lockfile` (or equivalent) in CI |
191
+ | Storing `.env.local` in the repository | Developer secrets and tokens leak to all contributors | Add `.env.local` to `.gitignore`; share via secure vault |
192
+ | No startup validation of env vars | App starts but crashes later with cryptic errors | Validate all required variables at boot (fail fast) |
@@ -38,11 +38,9 @@ Generic documentation templates and writing standards. For project-specific dire
38
38
  ## Roadmap Update Template
39
39
 
40
40
  When a feature is completed:
41
- 1. Change status to `COMPLETE`
42
- 2. Add completion date
43
- 3. List modified files
44
- 4. Update the summary table at the top
45
- 5. Move to completed section if applicable
41
+ 1. Change status to `COMPLETE` and add completion date
42
+ 2. List modified files and update the summary table
43
+ 3. Move to completed section if applicable
46
44
 
47
45
  ## Architecture Decision Record Template
48
46
 
@@ -57,16 +55,107 @@ When a feature is completed:
57
55
  **Alternatives Considered:** [What else was evaluated]
58
56
  ```
59
57
 
58
+ ## README Template
59
+
60
+ Use this structure for library or feature-level READMEs:
61
+
62
+ ```markdown
63
+ # Feature / Library Name
64
+
65
+ One-sentence summary of what this does and why it exists.
66
+
67
+ ## Quick Start
68
+
69
+ Brief usage example or setup steps.
70
+
71
+ ## Architecture
72
+
73
+ High-level overview. Include a Mermaid diagram for non-trivial systems.
74
+
75
+ ## Key Files
76
+
77
+ | File | Purpose |
78
+ |------|---------|
79
+ | `src/handler.ts` | Request handling logic |
80
+ | `src/schema.ts` | Validation schemas |
81
+ ```
82
+
83
+ ## Mermaid Diagram Patterns
84
+
85
+ Keep diagrams focused — one concern per diagram.
86
+ ### Flowchart (decision logic, pipelines)
87
+
88
+ ```mermaid
89
+ flowchart TD
90
+ A[Receive Request] --> B{Authenticated?}
91
+ B -- Yes --> C[Process Request]
92
+ B -- No --> D[Return 401]
93
+ C --> E{Valid Input?}
94
+ E -- Yes --> F[Execute Action]
95
+ E -- No --> G[Return 400]
96
+ ```
97
+
98
+ ### Sequence Diagram (API flows, multi-service interactions)
99
+
100
+ ```mermaid
101
+ sequenceDiagram
102
+ participant Client
103
+ participant API
104
+ participant DB
105
+ Client->>API: POST /resource
106
+ API->>DB: INSERT record
107
+ DB-->>API: OK
108
+ API-->>Client: 201 Created
109
+ ```
110
+
111
+ ### ER Diagram (data models, relationships)
112
+
113
+ ```mermaid
114
+ erDiagram
115
+ USER ||--o{ ORDER : places
116
+ ORDER ||--|{ LINE_ITEM : contains
117
+ USER { string id PK; string email }
118
+ ORDER { string id PK; date created_at }
119
+ ```
120
+
121
+ ### Diagram Guidelines
122
+
123
+ - Add a title comment (`%% Title: ...`) at the top of complex diagrams
124
+ - Use verb labels on relationship arrows
125
+ - Limit nodes to 10–12 per diagram; split larger systems into sub-diagrams
126
+ - Prefer `flowchart TD` (top-down) for pipelines and `flowchart LR` (left-right) for request flows
127
+
128
+ ## Changelog Entry Template
129
+
130
+ Follow Conventional Commits format. Group entries by type under a version heading:
131
+
132
+ ```markdown
133
+ ## [1.2.0] — YYYY-MM-DD
134
+
135
+ ### Added
136
+ - feat: Add retry logic to API client (#123)
137
+
138
+ ### Fixed
139
+ - fix: Resolve race condition in queue processor (#127)
140
+
141
+ ### Changed
142
+ - refactor: Extract validation into shared module (#125)
143
+ ```
144
+
145
+ ### Changelog Rules
146
+
147
+ - One line per change; reference the PR or issue number
148
+ - Use imperative mood: "Add", "Fix", "Remove" — not "Added", "Fixed"
149
+ - Group under `Added`, `Fixed`, `Changed`, `Removed`, `Deprecated`, `Security`
150
+ - Most recent version at the top
151
+
60
152
  ## Writing Guidelines
61
153
 
62
154
  - Write clear, concise prose — avoid jargon unless necessary
63
- - Include diagrams (Mermaid or ASCII) for architecture
64
- - Link to related files and docs using relative paths
65
- - Keep line length under 400 characters; break at 80 for readability
66
- - Use tables for structured data
67
- - Include "Last Updated" dates on all documents
68
- - Archive outdated docs rather than deleting
69
- - Cross-reference between documents when relevant
155
+ - Include Mermaid diagrams for architecture
156
+ - Link to related files using relative paths
157
+ - Use tables for structured data; include "Last Updated" dates on all documents
158
+ - Archive outdated docs rather than deleting; cross-reference between documents
70
159
 
71
160
  ### Formatting Rules
72
161
 
@@ -85,3 +174,27 @@ Include YAML front matter at the beginning of instruction/skill files:
85
174
  - `title` / `name`: The title of the document
86
175
  - `description`: A brief description of the document content
87
176
  - `applyTo`: (for instruction files) Glob pattern for which files the instructions apply to
177
+
178
+ ## Documentation Review Checklist
179
+
180
+ Before merging docs, verify:
181
+
182
+ - [ ] **Accuracy** — all code snippets, file paths, and commands are correct and tested
183
+ - [ ] **Completeness** — no TODO placeholders or empty sections remain
184
+ - [ ] **Links** — all internal and external links resolve (no 404s)
185
+ - [ ] **Front matter** — YAML front matter is present and valid
186
+ - [ ] **Formatting** — consistent heading levels, list style, whitespace, and Mermaid renders
187
+ - [ ] **Cross-references** — related docs link to each other; "Last Updated" is current
188
+
189
+ ## Anti-Patterns
190
+
191
+ | Anti-Pattern | Why It's Bad | Do This Instead |
192
+ |-------------|-------------|-----------------|
193
+ | Wall of text with no headings | Unnavigable; readers skip it | Break into sections with H2/H3 |
194
+ | Duplicating content across files | Copies drift; causes confusion | Link to a single source of truth |
195
+ | Screenshots without alt text | Inaccessible; breaks when UI changes | Use Mermaid diagrams or describe the UI |
196
+ | Documenting implementation details | Becomes stale as code changes | Document intent and contracts |
197
+ | Using absolute file paths | Breaks on other machines | Use relative paths from doc location |
198
+ | Huge monolithic README | Low signal-to-noise | Split into focused docs, link from README |
199
+ | Undated documents | No way to judge currency | Always include "Last Updated" date |
200
+ | Using H1 inside document body | Conflicts with auto-generated title | Start body headings at H2 |
@@ -41,4 +41,155 @@ Interpret creatively and make unexpected choices that feel genuinely designed fo
41
41
 
42
42
  **IMPORTANT**: Match implementation complexity to the aesthetic vision. Maximalist designs need elaborate code with extensive animations and effects. Minimalist or refined designs need restraint, precision, and careful attention to spacing, typography, and subtle details. Elegance comes from executing the vision well.
43
43
 
44
- Remember: Claude is capable of extraordinary creative work. Don't hold back, show what can truly be created when thinking outside the box and committing fully to a distinctive vision.
44
+ Remember: Claude is capable of extraordinary creative work. Don't hold back, show what can truly be created when thinking outside the box and committing fully to a distinctive vision.
45
+
46
+ ## Design System Foundations
47
+
48
+ Every design starts with a token layer. Define CSS custom properties that encode the aesthetic direction — never scatter raw values through stylesheets. A well-structured variable system makes the entire interface feel cohesive even as complexity grows.
49
+
50
+ ```css
51
+ /* --- Palette: warm editorial with a punch of citron --- */
52
+ :root {
53
+ --color-ink: #1a1614;
54
+ --color-paper: #f5f0e8;
55
+ --color-accent: #c8e630; /* citron — the memorable detail */
56
+ --color-muted: #9b9083;
57
+ --color-surface: #eae3d8;
58
+ --color-border: rgba(26, 22, 20, 0.08);
59
+
60
+ /* Typography scale — modular ratio 1.25 (Major Third) */
61
+ --text-sm: clamp(0.875rem, 0.83rem + 0.22vw, 1rem);
62
+ --text-base: clamp(1rem, 0.95rem + 0.25vw, 1.125rem);
63
+ --text-xl: clamp(1.563rem, 1.35rem + 1.06vw, 2rem);
64
+ --text-2xl: clamp(1.953rem, 1.6rem + 1.77vw, 2.75rem);
65
+ --text-hero: clamp(2.441rem, 1.8rem + 3.2vw, 4.5rem);
66
+
67
+ /* Spacing — 4px base, geometric progression */
68
+ --space-2: 0.5rem; --space-4: 1rem;
69
+ --space-6: 1.5rem; --space-8: 2rem;
70
+ --space-16: 4rem; --space-32: 8rem;
71
+
72
+ /* Motion — intentional easing curves, not defaults */
73
+ --ease-out-expo: cubic-bezier(0.16, 1, 0.3, 1);
74
+ --ease-in-out-back: cubic-bezier(0.68, -0.6, 0.32, 1.6);
75
+ --duration-fast: 150ms;
76
+ --duration-normal: 300ms;
77
+ --duration-slow: 600ms;
78
+
79
+ /* Elevation */
80
+ --shadow-md: 0 4px 16px rgba(26, 22, 20, 0.08);
81
+ --shadow-lg: 0 12px 48px rgba(26, 22, 20, 0.12);
82
+ }
83
+ ```
84
+
85
+ **Anti-pattern:** Never scatter raw hex/px values through stylesheets. Every value should trace back to a token. Change the palette once and the entire interface follows.
86
+
87
+ ## Component Patterns
88
+
89
+ ### Distinctive Card
90
+
91
+ A card should never look like a Bootstrap default. Give it tension — an unexpected border treatment, an oversized label, or a hover that reveals hidden depth.
92
+
93
+ ```css
94
+ .card {
95
+ position: relative;
96
+ background: var(--color-paper);
97
+ border: 1px solid var(--color-border);
98
+ border-left: 4px solid var(--color-accent);
99
+ padding: var(--space-8) var(--space-6);
100
+ transition: transform var(--duration-normal) var(--ease-out-expo),
101
+ box-shadow var(--duration-normal) var(--ease-out-expo);
102
+ }
103
+
104
+ .card:hover {
105
+ transform: translateY(-3px);
106
+ box-shadow: var(--shadow-lg);
107
+ }
108
+
109
+ .card__label {
110
+ position: absolute;
111
+ top: calc(-1 * var(--space-3));
112
+ left: var(--space-4);
113
+ background: var(--color-accent);
114
+ color: var(--color-ink);
115
+ font-size: var(--text-xs);
116
+ font-weight: 700;
117
+ letter-spacing: 0.08em;
118
+ text-transform: uppercase;
119
+ padding: var(--space-1) var(--space-3);
120
+ }
121
+ ```
122
+
123
+ ### Hero Section with Staggered Reveal
124
+
125
+ Orchestrate entrance animations with `animation-delay` for a cinematic first impression. One coordinated sequence beats a dozen scattered `fadeIn`s.
126
+
127
+ ```css
128
+ @keyframes rise {
129
+ from { opacity: 0; transform: translateY(24px); }
130
+ to { opacity: 1; transform: translateY(0); }
131
+ }
132
+
133
+ .hero { overflow: hidden; padding: var(--space-32) var(--space-8); }
134
+ .hero__eyebrow { animation: rise var(--duration-slow) var(--ease-out-expo) both; animation-delay: 100ms; }
135
+ .hero__headline { animation: rise var(--duration-slow) var(--ease-out-expo) both; animation-delay: 250ms; }
136
+ .hero__body { animation: rise var(--duration-slow) var(--ease-out-expo) both; animation-delay: 400ms; }
137
+ .hero__cta { animation: rise var(--duration-slow) var(--ease-out-expo) both; animation-delay: 550ms; }
138
+ ```
139
+
140
+ **Anti-pattern:** Don't animate everything. If the nav bounces, the sidebar slides, and the footer pulses — it's visual noise, not design. Motion has a narrative: one orchestrated entrance, then stillness.
141
+
142
+ ## Typography Pairing Examples
143
+
144
+ Never reach for the same font twice. Each project deserves a pairing chosen for its specific character. These are starting points — not a rotation list.
145
+
146
+ | Aesthetic | Display | Body | Mood |
147
+ |-----------|---------|------|------|
148
+ | Editorial luxury | Playfair Display | Source Serif 4 | Authoritative, rich serif contrast |
149
+ | Swiss precision | Darker Grotesque | IBM Plex Sans | Sharp, high-contrast grotesque |
150
+ | Warm humanist | Fraunces | Nunito Sans | Friendly optical sizes, approachable |
151
+ | Brutalist edge | Monument Extended | JetBrains Mono | Wide + monospace = raw technical power |
152
+ | Art nouveau organic | Cormorant Garamond | Lora | Flowing, calligraphic sensibility |
153
+ | Retro-futuristic | Syne | Outfit | Geometric boldness meets clean body |
154
+
155
+ Always include a fallback chain that preserves metrics: `'Fraunces', 'Georgia', serif` not just `'Fraunces', serif`. And never default to the same "safe" choices (Inter, Roboto, system-ui) — if every project looks the same, the typography isn't doing its job.
156
+
157
+ ## Design Quality Checklist
158
+
159
+ Run this checklist before delivering any frontend work. Every item is a gate — if something fails, the design isn't finished.
160
+
161
+ ### Identity & Cohesion
162
+ - [ ] Can you name the aesthetic direction in 2-3 words? (e.g., "warm editorial," "cold brutalist")
163
+ - [ ] Are color, typography, spacing, and motion all telling the same visual story?
164
+ - [ ] Is there at least one memorable detail — something unexpected that delights?
165
+
166
+ ### Typography
167
+ - [ ] Display and body fonts are distinct and intentionally paired
168
+ - [ ] Type scale uses `clamp()` for fluid responsive sizing — no fixed `px` breakpoints
169
+ - [ ] Line heights are tuned: ~1.1–1.2 for headings, ~1.5–1.7 for body
170
+ - [ ] Letter-spacing is adjusted for uppercase text and small sizes
171
+
172
+ ### Color & Contrast
173
+ - [ ] Palette is defined as CSS custom properties — no raw hex in component styles
174
+ - [ ] There is a clear dominant/accent hierarchy — not five competing colors
175
+ - [ ] Text passes WCAG AA contrast minimums (4.5:1 body, 3:1 large text)
176
+ - [ ] Dark/light theme (if applicable) is not just color inversion — both feel intentional
177
+
178
+ ### Layout & Spacing
179
+ - [ ] Spacing flows from a consistent scale — no random `margin: 37px`
180
+ - [ ] At least one layout choice breaks the expected grid — overlap, bleed, asymmetry
181
+ - [ ] Component padding and gaps use spacing tokens, not ad-hoc values
182
+ - [ ] The design holds at mobile, tablet, and desktop without layout collapse
183
+
184
+ ### Motion & Interaction
185
+ - [ ] Page entrance has a coordinated animation sequence (staggered reveals)
186
+ - [ ] Hover/focus states exist for all interactive elements
187
+ - [ ] Animations use custom easing curves — never `linear` or bare `ease`
188
+ - [ ] Motion serves narrative purpose — no decoration-only animation
189
+ - [ ] `prefers-reduced-motion` is respected with a `@media` query fallback
190
+
191
+ ### Production Readiness
192
+ - [ ] No hardcoded widths that break at unexpected viewports
193
+ - [ ] Images and decorative elements have proper `alt` text or `aria-hidden`
194
+ - [ ] Focus indicators are visible and styled to match the aesthetic
195
+ - [ ] Performance: no layout thrashing from scroll-triggered animations without `will-change`