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.
- package/dist/cli/detect.test.d.ts +2 -0
- package/dist/cli/detect.test.d.ts.map +1 -0
- package/dist/cli/detect.test.js +255 -0
- package/dist/cli/detect.test.js.map +1 -0
- package/dist/cli/run/executor.test.d.ts +2 -0
- package/dist/cli/run/executor.test.d.ts.map +1 -0
- package/dist/cli/run/executor.test.js +297 -0
- package/dist/cli/run/executor.test.js.map +1 -0
- package/dist/cli/run/schema.js +1 -1
- package/dist/cli/run/schema.js.map +1 -1
- package/dist/cli/run/schema.test.d.ts +2 -0
- package/dist/cli/run/schema.test.d.ts.map +1 -0
- package/dist/cli/run/schema.test.js +294 -0
- package/dist/cli/run/schema.test.js.map +1 -0
- package/package.json +1 -1
- package/src/cli/detect.test.ts +337 -0
- package/src/cli/run/executor.test.ts +338 -0
- package/src/cli/run/schema.test.ts +343 -0
- package/src/cli/run/schema.ts +1 -1
- package/src/dashboard/node_modules/.vite/deps/_metadata.json +6 -6
- package/src/orchestrator/agents/session-guard.agent.md +113 -0
- package/src/orchestrator/agents/team-lead.agent.md +172 -569
- package/src/orchestrator/skills/agent-hooks/SKILL.md +14 -13
- package/src/orchestrator/skills/decomposition/SKILL.md +122 -0
- package/src/orchestrator/skills/deployment-infrastructure/SKILL.md +143 -2
- package/src/orchestrator/skills/documentation-standards/SKILL.md +125 -12
- package/src/orchestrator/skills/frontend-design/SKILL.md +152 -1
- package/src/orchestrator/skills/nextjs-patterns/SKILL.md +147 -24
- package/src/orchestrator/skills/orchestration-protocols/SKILL.md +116 -0
- 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. **
|
|
62
|
-
|
|
63
|
-
|
|
64
|
-
|
|
65
|
-
|
|
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. **
|
|
119
|
-
|
|
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 (
|
|
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
|
-
-
|
|
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.
|
|
43
|
-
3.
|
|
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
|
|
64
|
-
- Link to related files
|
|
65
|
-
-
|
|
66
|
-
-
|
|
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`
|