ai-sprint-kit 1.1.0
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/README.md +299 -0
- package/bin/cli.js +135 -0
- package/lib/installer.js +205 -0
- package/lib/scanner.js +341 -0
- package/package.json +55 -0
- package/templates/.claude/.env.example +13 -0
- package/templates/.claude/agents/debugger.md +667 -0
- package/templates/.claude/agents/devops.md +727 -0
- package/templates/.claude/agents/docs.md +661 -0
- package/templates/.claude/agents/implementer.md +235 -0
- package/templates/.claude/agents/planner.md +243 -0
- package/templates/.claude/agents/researcher.md +448 -0
- package/templates/.claude/agents/reviewer.md +610 -0
- package/templates/.claude/agents/security.md +202 -0
- package/templates/.claude/agents/tester.md +604 -0
- package/templates/.claude/commands/auto.md +85 -0
- package/templates/.claude/commands/code.md +301 -0
- package/templates/.claude/commands/debug.md +449 -0
- package/templates/.claude/commands/deploy.md +475 -0
- package/templates/.claude/commands/docs.md +519 -0
- package/templates/.claude/commands/plan.md +57 -0
- package/templates/.claude/commands/review.md +412 -0
- package/templates/.claude/commands/scan.md +146 -0
- package/templates/.claude/commands/secure.md +88 -0
- package/templates/.claude/commands/test.md +352 -0
- package/templates/.claude/commands/validate.md +238 -0
- package/templates/.claude/settings.json +27 -0
- package/templates/.claude/skills/codebase-context/SKILL.md +68 -0
- package/templates/.claude/skills/codebase-context/references/reading-context.md +68 -0
- package/templates/.claude/skills/codebase-context/references/refresh-triggers.md +82 -0
- package/templates/.claude/skills/implementation/SKILL.md +70 -0
- package/templates/.claude/skills/implementation/references/error-handling.md +106 -0
- package/templates/.claude/skills/implementation/references/security-patterns.md +73 -0
- package/templates/.claude/skills/implementation/references/validation-patterns.md +107 -0
- package/templates/.claude/skills/memory/SKILL.md +67 -0
- package/templates/.claude/skills/memory/references/decisions-format.md +68 -0
- package/templates/.claude/skills/memory/references/learning-format.md +74 -0
- package/templates/.claude/skills/planning/SKILL.md +72 -0
- package/templates/.claude/skills/planning/references/plan-templates.md +81 -0
- package/templates/.claude/skills/planning/references/research-phase.md +62 -0
- package/templates/.claude/skills/planning/references/solution-design.md +66 -0
- package/templates/.claude/skills/quality-assurance/SKILL.md +79 -0
- package/templates/.claude/skills/quality-assurance/references/review-checklist.md +72 -0
- package/templates/.claude/skills/quality-assurance/references/security-checklist.md +70 -0
- package/templates/.claude/skills/quality-assurance/references/testing-strategy.md +85 -0
- package/templates/.claude/statusline.sh +126 -0
- package/templates/.claude/workflows/development-rules.md +97 -0
- package/templates/.claude/workflows/orchestration-protocol.md +194 -0
- package/templates/.mcp.json.example +36 -0
- package/templates/CLAUDE.md +409 -0
- package/templates/README.md +331 -0
- package/templates/ai_context/codebase/.gitkeep +0 -0
- package/templates/ai_context/memory/active.md +15 -0
- package/templates/ai_context/memory/decisions.md +18 -0
- package/templates/ai_context/memory/learning.md +22 -0
- package/templates/ai_context/plans/.gitkeep +0 -0
- package/templates/ai_context/reports/.gitkeep +0 -0
- package/templates/docs/user-guide-th.md +454 -0
- package/templates/docs/user-guide.md +595 -0
|
@@ -0,0 +1,68 @@
|
|
|
1
|
+
# Reading Codebase Context
|
|
2
|
+
|
|
3
|
+
## Recommended Order
|
|
4
|
+
|
|
5
|
+
### 1. structure.md (Quick - <1 min)
|
|
6
|
+
- Understand project layout
|
|
7
|
+
- Identify key directories (src/, lib/, api/)
|
|
8
|
+
- Find configuration files
|
|
9
|
+
- Note test file locations
|
|
10
|
+
|
|
11
|
+
### 2. overview.md (Comprehensive - 5-10 min)
|
|
12
|
+
- Markdown format, human-readable
|
|
13
|
+
- Contains all source code compressed
|
|
14
|
+
- Files sorted by Git change frequency
|
|
15
|
+
- Good for understanding patterns
|
|
16
|
+
|
|
17
|
+
### 3. repomix-output.xml (As needed)
|
|
18
|
+
- XML format optimized for AI parsing
|
|
19
|
+
- Most token-efficient for large queries
|
|
20
|
+
- Use for specific file searches
|
|
21
|
+
- Best for detailed code analysis
|
|
22
|
+
|
|
23
|
+
## Token Efficiency Tips
|
|
24
|
+
|
|
25
|
+
| Need | Do This |
|
|
26
|
+
|------|---------|
|
|
27
|
+
| Quick overview | Read structure.md only |
|
|
28
|
+
| Understand feature | Read overview.md section |
|
|
29
|
+
| Find specific code | Grep in overview.md |
|
|
30
|
+
| Exact line numbers | Read source file directly |
|
|
31
|
+
|
|
32
|
+
## Understanding Compression
|
|
33
|
+
|
|
34
|
+
Repomix uses Tree-sitter AST compression:
|
|
35
|
+
- Removes unnecessary whitespace
|
|
36
|
+
- Uses delimiter `⋮----` between sections
|
|
37
|
+
- Files sorted by Git change frequency (most active first)
|
|
38
|
+
- ~70% token reduction from raw code
|
|
39
|
+
|
|
40
|
+
## When to Read Files Directly
|
|
41
|
+
|
|
42
|
+
Use Read tool instead of context when:
|
|
43
|
+
- Need exact line numbers for editing
|
|
44
|
+
- File was modified after last scan
|
|
45
|
+
- Debugging specific issue
|
|
46
|
+
- File excluded from scan (in .repomixignore)
|
|
47
|
+
|
|
48
|
+
## Example Workflow
|
|
49
|
+
|
|
50
|
+
```
|
|
51
|
+
1. Check structure.md
|
|
52
|
+
→ Identify: src/auth/, src/api/
|
|
53
|
+
|
|
54
|
+
2. Read overview.md section on auth
|
|
55
|
+
→ Understand: JWT strategy, middleware pattern
|
|
56
|
+
|
|
57
|
+
3. Read src/auth/jwt.ts directly
|
|
58
|
+
→ Get: exact code for modification
|
|
59
|
+
```
|
|
60
|
+
|
|
61
|
+
## Integration with Agents
|
|
62
|
+
|
|
63
|
+
| Agent | Context Usage |
|
|
64
|
+
|-------|---------------|
|
|
65
|
+
| Planner | Read structure + overview before designing |
|
|
66
|
+
| Implementer | Check patterns in overview, then read specific files |
|
|
67
|
+
| Reviewer | Reference overview for consistency checks |
|
|
68
|
+
| Tester | Find test patterns from overview |
|
|
@@ -0,0 +1,82 @@
|
|
|
1
|
+
# When to Refresh Codebase Context
|
|
2
|
+
|
|
3
|
+
## Refresh Triggers
|
|
4
|
+
|
|
5
|
+
Run `/scan` command when:
|
|
6
|
+
|
|
7
|
+
### 1. After Major Changes
|
|
8
|
+
- New features added
|
|
9
|
+
- Architecture refactored
|
|
10
|
+
- Multiple files modified
|
|
11
|
+
- New directories created
|
|
12
|
+
|
|
13
|
+
### 2. Stale Context Detected
|
|
14
|
+
- scan-metadata.json > 1 day old
|
|
15
|
+
- New files not in structure.md
|
|
16
|
+
- Code behavior differs from overview.md
|
|
17
|
+
- Team members made changes
|
|
18
|
+
|
|
19
|
+
### 3. Before Major Work
|
|
20
|
+
- Starting new feature implementation
|
|
21
|
+
- Beginning architecture planning
|
|
22
|
+
- Before comprehensive code review
|
|
23
|
+
|
|
24
|
+
## How to Check Freshness
|
|
25
|
+
|
|
26
|
+
```bash
|
|
27
|
+
# Check when last scanned
|
|
28
|
+
cat ai_context/codebase/scan-metadata.json
|
|
29
|
+
|
|
30
|
+
# Look for scanDate field
|
|
31
|
+
# Compare with today's date
|
|
32
|
+
```
|
|
33
|
+
|
|
34
|
+
## What Gets Scanned
|
|
35
|
+
|
|
36
|
+
**Included by default:**
|
|
37
|
+
- Source code directories (src/, lib/, app/, pages/, components/)
|
|
38
|
+
- Configuration files (*.json, *.yaml, *.toml)
|
|
39
|
+
- Test files (unless ignored)
|
|
40
|
+
|
|
41
|
+
**Excluded by default:**
|
|
42
|
+
- node_modules/
|
|
43
|
+
- .git/
|
|
44
|
+
- dist/, build/, .next/
|
|
45
|
+
- .env files (security)
|
|
46
|
+
- Lock files (package-lock.json, yarn.lock)
|
|
47
|
+
- Coverage reports
|
|
48
|
+
|
|
49
|
+
## Custom Ignore
|
|
50
|
+
|
|
51
|
+
Create `.repomixignore` in project root:
|
|
52
|
+
|
|
53
|
+
```
|
|
54
|
+
# Custom ignores
|
|
55
|
+
*.log
|
|
56
|
+
temp/
|
|
57
|
+
*.generated.ts
|
|
58
|
+
large-data/
|
|
59
|
+
```
|
|
60
|
+
|
|
61
|
+
## Refresh Commands
|
|
62
|
+
|
|
63
|
+
```bash
|
|
64
|
+
# Using Claude command
|
|
65
|
+
/scan
|
|
66
|
+
|
|
67
|
+
# Using CLI directly
|
|
68
|
+
ai-sprint scan
|
|
69
|
+
|
|
70
|
+
# Specific directory
|
|
71
|
+
ai-sprint scan --dir /path/to/project
|
|
72
|
+
```
|
|
73
|
+
|
|
74
|
+
## Refresh Frequency Guidelines
|
|
75
|
+
|
|
76
|
+
| Situation | Recommendation |
|
|
77
|
+
|-----------|----------------|
|
|
78
|
+
| Active development | Daily |
|
|
79
|
+
| Stable codebase | Weekly |
|
|
80
|
+
| Before major feature | Always |
|
|
81
|
+
| After team changes | Always |
|
|
82
|
+
| Quick bug fix | Skip if <1 day old |
|
|
@@ -0,0 +1,70 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: implementation
|
|
3
|
+
description: Secure coding standards and patterns. Activate when generating or refactoring code. Enforces security-first approach with proper error handling, input validation, and test coverage requirements.
|
|
4
|
+
license: MIT
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Implementation Standards
|
|
8
|
+
|
|
9
|
+
Production-grade coding patterns with security-first approach.
|
|
10
|
+
|
|
11
|
+
## When to Use
|
|
12
|
+
|
|
13
|
+
- Generating new code
|
|
14
|
+
- Refactoring existing code
|
|
15
|
+
- Fixing bugs
|
|
16
|
+
- Adding features
|
|
17
|
+
|
|
18
|
+
## Core Principles
|
|
19
|
+
|
|
20
|
+
- **Security-First** - Every line considers security
|
|
21
|
+
- **Test-Driven** - Write tests alongside code
|
|
22
|
+
- **Clean Code** - Simple, readable, maintainable
|
|
23
|
+
- **YAGNI/KISS/DRY** - No over-engineering
|
|
24
|
+
|
|
25
|
+
## Before Implementing
|
|
26
|
+
|
|
27
|
+
```
|
|
28
|
+
1. Read ai_context/memory/learning.md (avoid past mistakes)
|
|
29
|
+
2. Read relevant plan in ai_context/plans/
|
|
30
|
+
3. Understand existing patterns in codebase
|
|
31
|
+
4. Check ai_context/codebase/structure.md for project layout
|
|
32
|
+
```
|
|
33
|
+
|
|
34
|
+
## Security Requirements
|
|
35
|
+
|
|
36
|
+
Load: `references/security-patterns.md`
|
|
37
|
+
|
|
38
|
+
## Error Handling
|
|
39
|
+
|
|
40
|
+
Load: `references/error-handling.md`
|
|
41
|
+
|
|
42
|
+
## Validation Patterns
|
|
43
|
+
|
|
44
|
+
Load: `references/validation-patterns.md`
|
|
45
|
+
|
|
46
|
+
## Output Structure
|
|
47
|
+
|
|
48
|
+
```
|
|
49
|
+
ai_context/reports/
|
|
50
|
+
└── YYMMDD-HHMM-implementation-{feature}.md
|
|
51
|
+
```
|
|
52
|
+
|
|
53
|
+
## Quality Gates
|
|
54
|
+
|
|
55
|
+
Before completing:
|
|
56
|
+
- [ ] Tests pass (>80% coverage)
|
|
57
|
+
- [ ] Linting passes
|
|
58
|
+
- [ ] Type checks pass
|
|
59
|
+
- [ ] No security vulnerabilities
|
|
60
|
+
- [ ] No hardcoded secrets
|
|
61
|
+
- [ ] Error handling complete
|
|
62
|
+
- [ ] Input validation on all boundaries
|
|
63
|
+
|
|
64
|
+
## Date Handling
|
|
65
|
+
|
|
66
|
+
Always use bash for timestamps:
|
|
67
|
+
```bash
|
|
68
|
+
date "+%y%m%d-%H%M" # For filenames: 251225-1430
|
|
69
|
+
date "+%Y-%m-%d" # For docs: 2025-12-25
|
|
70
|
+
```
|
|
@@ -0,0 +1,106 @@
|
|
|
1
|
+
# Error Handling
|
|
2
|
+
|
|
3
|
+
## Principles
|
|
4
|
+
|
|
5
|
+
1. **Fail Fast** - Validate early, fail clearly
|
|
6
|
+
2. **Don't Swallow Errors** - Always handle or propagate
|
|
7
|
+
3. **Log Context** - Include relevant debugging info
|
|
8
|
+
4. **User-Friendly** - Generic messages to users, details in logs
|
|
9
|
+
|
|
10
|
+
## Pattern: Specific Error Handling
|
|
11
|
+
|
|
12
|
+
```typescript
|
|
13
|
+
// GOOD - Specific error handling
|
|
14
|
+
try {
|
|
15
|
+
await processPayment(amount);
|
|
16
|
+
} catch (error) {
|
|
17
|
+
if (error instanceof PaymentDeclinedError) {
|
|
18
|
+
return { success: false, reason: 'Payment declined' };
|
|
19
|
+
}
|
|
20
|
+
if (error instanceof NetworkError) {
|
|
21
|
+
logger.error('Payment network error', { error, amount });
|
|
22
|
+
return { success: false, reason: 'Service unavailable' };
|
|
23
|
+
}
|
|
24
|
+
// Unexpected error - log and rethrow
|
|
25
|
+
logger.error('Unexpected payment error', { error, amount });
|
|
26
|
+
throw new InternalError('Payment processing failed');
|
|
27
|
+
}
|
|
28
|
+
|
|
29
|
+
// BAD - Generic handling
|
|
30
|
+
try {
|
|
31
|
+
await processPayment(amount);
|
|
32
|
+
} catch (error) {
|
|
33
|
+
console.log(error); // Exposes internals
|
|
34
|
+
}
|
|
35
|
+
```
|
|
36
|
+
|
|
37
|
+
## Pattern: Error Hierarchy
|
|
38
|
+
|
|
39
|
+
```typescript
|
|
40
|
+
class AppError extends Error {
|
|
41
|
+
constructor(
|
|
42
|
+
message: string,
|
|
43
|
+
public code: string,
|
|
44
|
+
public statusCode: number = 500
|
|
45
|
+
) {
|
|
46
|
+
super(message);
|
|
47
|
+
this.name = this.constructor.name;
|
|
48
|
+
}
|
|
49
|
+
}
|
|
50
|
+
|
|
51
|
+
class ValidationError extends AppError {
|
|
52
|
+
constructor(message: string) {
|
|
53
|
+
super(message, 'VALIDATION_ERROR', 400);
|
|
54
|
+
}
|
|
55
|
+
}
|
|
56
|
+
|
|
57
|
+
class NotFoundError extends AppError {
|
|
58
|
+
constructor(resource: string) {
|
|
59
|
+
super(`${resource} not found`, 'NOT_FOUND', 404);
|
|
60
|
+
}
|
|
61
|
+
}
|
|
62
|
+
|
|
63
|
+
class ForbiddenError extends AppError {
|
|
64
|
+
constructor(message = 'Access denied') {
|
|
65
|
+
super(message, 'FORBIDDEN', 403);
|
|
66
|
+
}
|
|
67
|
+
}
|
|
68
|
+
```
|
|
69
|
+
|
|
70
|
+
## Logging Context
|
|
71
|
+
|
|
72
|
+
```typescript
|
|
73
|
+
// Include useful context
|
|
74
|
+
logger.error('Operation failed', {
|
|
75
|
+
error: error.message,
|
|
76
|
+
stack: error.stack,
|
|
77
|
+
userId: user.id,
|
|
78
|
+
operation: 'createOrder',
|
|
79
|
+
input: { orderId, amount } // Sanitized input
|
|
80
|
+
});
|
|
81
|
+
|
|
82
|
+
// Never log sensitive data
|
|
83
|
+
// BAD: logger.info('Login', { password: pwd });
|
|
84
|
+
// GOOD: logger.info('Login attempt', { email, success: true });
|
|
85
|
+
```
|
|
86
|
+
|
|
87
|
+
## API Error Responses
|
|
88
|
+
|
|
89
|
+
```typescript
|
|
90
|
+
app.use((error, req, res, next) => {
|
|
91
|
+
const statusCode = error.statusCode || 500;
|
|
92
|
+
const message = statusCode === 500
|
|
93
|
+
? 'Internal server error'
|
|
94
|
+
: error.message;
|
|
95
|
+
|
|
96
|
+
res.status(statusCode).json({
|
|
97
|
+
error: {
|
|
98
|
+
code: error.code || 'INTERNAL_ERROR',
|
|
99
|
+
message,
|
|
100
|
+
...(process.env.NODE_ENV === 'development' && {
|
|
101
|
+
stack: error.stack
|
|
102
|
+
})
|
|
103
|
+
}
|
|
104
|
+
});
|
|
105
|
+
});
|
|
106
|
+
```
|
|
@@ -0,0 +1,73 @@
|
|
|
1
|
+
# Security Patterns
|
|
2
|
+
|
|
3
|
+
## Mandatory Checks
|
|
4
|
+
|
|
5
|
+
### No Hardcoded Secrets
|
|
6
|
+
```typescript
|
|
7
|
+
// BAD
|
|
8
|
+
const API_KEY = "sk_live_abc123";
|
|
9
|
+
|
|
10
|
+
// GOOD
|
|
11
|
+
const API_KEY = process.env.API_KEY;
|
|
12
|
+
if (!API_KEY) throw new Error('API_KEY not configured');
|
|
13
|
+
```
|
|
14
|
+
|
|
15
|
+
### Input Validation
|
|
16
|
+
```typescript
|
|
17
|
+
// Validate ALL user inputs
|
|
18
|
+
function createUser(email: string, password: string) {
|
|
19
|
+
if (!isValidEmail(email)) throw new ValidationError('Invalid email');
|
|
20
|
+
if (!isStrongPassword(password)) throw new ValidationError('Weak password');
|
|
21
|
+
}
|
|
22
|
+
```
|
|
23
|
+
|
|
24
|
+
### Parameterized Queries
|
|
25
|
+
```typescript
|
|
26
|
+
// BAD - SQL Injection vulnerable
|
|
27
|
+
const query = `SELECT * FROM users WHERE email = '${email}'`;
|
|
28
|
+
|
|
29
|
+
// GOOD - Parameterized
|
|
30
|
+
const query = `SELECT * FROM users WHERE email = $1`;
|
|
31
|
+
const result = await db.query(query, [email]);
|
|
32
|
+
```
|
|
33
|
+
|
|
34
|
+
### Output Encoding
|
|
35
|
+
```typescript
|
|
36
|
+
// Escape user content before rendering
|
|
37
|
+
const safeHtml = escapeHtml(userInput);
|
|
38
|
+
```
|
|
39
|
+
|
|
40
|
+
## OWASP Top 10 Checklist
|
|
41
|
+
|
|
42
|
+
- [ ] Broken Access Control - Check auth on every endpoint
|
|
43
|
+
- [ ] Cryptographic Failures - Use strong encryption
|
|
44
|
+
- [ ] Injection - Parameterize all queries
|
|
45
|
+
- [ ] Insecure Design - Threat model early
|
|
46
|
+
- [ ] Security Misconfiguration - Secure defaults
|
|
47
|
+
- [ ] Vulnerable Components - Update dependencies
|
|
48
|
+
- [ ] Authentication Failures - Strong auth
|
|
49
|
+
- [ ] Data Integrity Failures - Verify signatures
|
|
50
|
+
- [ ] Logging Failures - Log security events
|
|
51
|
+
- [ ] SSRF - Validate URLs
|
|
52
|
+
|
|
53
|
+
## Authentication Pattern
|
|
54
|
+
|
|
55
|
+
```typescript
|
|
56
|
+
async function protectedRoute(req, res) {
|
|
57
|
+
const user = await verifyToken(req.headers.authorization);
|
|
58
|
+
if (!user) return res.status(401).json({ error: 'Unauthorized' });
|
|
59
|
+
// Continue with request
|
|
60
|
+
}
|
|
61
|
+
```
|
|
62
|
+
|
|
63
|
+
## Authorization Pattern
|
|
64
|
+
|
|
65
|
+
```typescript
|
|
66
|
+
async function deleteResource(userId, resourceId) {
|
|
67
|
+
const resource = await getResource(resourceId);
|
|
68
|
+
if (resource.ownerId !== userId) {
|
|
69
|
+
throw new ForbiddenError('Not authorized');
|
|
70
|
+
}
|
|
71
|
+
await resource.delete();
|
|
72
|
+
}
|
|
73
|
+
```
|
|
@@ -0,0 +1,107 @@
|
|
|
1
|
+
# Validation Patterns
|
|
2
|
+
|
|
3
|
+
## Input Validation Principles
|
|
4
|
+
|
|
5
|
+
1. **Validate at Boundaries** - API endpoints, form handlers
|
|
6
|
+
2. **Fail Fast** - Reject invalid input immediately
|
|
7
|
+
3. **Whitelist** - Allow known-good, reject everything else
|
|
8
|
+
4. **Type Safety** - Use TypeScript/schemas
|
|
9
|
+
|
|
10
|
+
## Pattern: Schema Validation
|
|
11
|
+
|
|
12
|
+
```typescript
|
|
13
|
+
import { z } from 'zod';
|
|
14
|
+
|
|
15
|
+
const createUserSchema = z.object({
|
|
16
|
+
email: z.string().email(),
|
|
17
|
+
password: z.string().min(8).regex(/[A-Z]/).regex(/[0-9]/),
|
|
18
|
+
name: z.string().min(1).max(100),
|
|
19
|
+
});
|
|
20
|
+
|
|
21
|
+
function createUser(input: unknown) {
|
|
22
|
+
const validated = createUserSchema.parse(input);
|
|
23
|
+
return db.users.create(validated);
|
|
24
|
+
}
|
|
25
|
+
```
|
|
26
|
+
|
|
27
|
+
## Pattern: Sanitization
|
|
28
|
+
|
|
29
|
+
```typescript
|
|
30
|
+
import DOMPurify from 'dompurify';
|
|
31
|
+
|
|
32
|
+
function saveComment(content: string) {
|
|
33
|
+
const sanitized = DOMPurify.sanitize(content, {
|
|
34
|
+
ALLOWED_TAGS: ['b', 'i', 'a'],
|
|
35
|
+
ALLOWED_ATTR: ['href']
|
|
36
|
+
});
|
|
37
|
+
return db.comments.create({ content: sanitized });
|
|
38
|
+
}
|
|
39
|
+
```
|
|
40
|
+
|
|
41
|
+
## Pattern: Type Guards
|
|
42
|
+
|
|
43
|
+
```typescript
|
|
44
|
+
function isValidUser(user: unknown): user is User {
|
|
45
|
+
return (
|
|
46
|
+
typeof user === 'object' &&
|
|
47
|
+
user !== null &&
|
|
48
|
+
'id' in user &&
|
|
49
|
+
'email' in user &&
|
|
50
|
+
typeof user.email === 'string'
|
|
51
|
+
);
|
|
52
|
+
}
|
|
53
|
+
|
|
54
|
+
function processUser(user: unknown) {
|
|
55
|
+
if (!isValidUser(user)) {
|
|
56
|
+
throw new ValidationError('Invalid user data');
|
|
57
|
+
}
|
|
58
|
+
// user is now typed as User
|
|
59
|
+
}
|
|
60
|
+
```
|
|
61
|
+
|
|
62
|
+
## Common Validations
|
|
63
|
+
|
|
64
|
+
```typescript
|
|
65
|
+
// Email
|
|
66
|
+
const emailRegex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
|
|
67
|
+
|
|
68
|
+
// URL
|
|
69
|
+
function isValidUrl(url: string): boolean {
|
|
70
|
+
try {
|
|
71
|
+
new URL(url);
|
|
72
|
+
return true;
|
|
73
|
+
} catch {
|
|
74
|
+
return false;
|
|
75
|
+
}
|
|
76
|
+
}
|
|
77
|
+
|
|
78
|
+
// UUID
|
|
79
|
+
const uuidRegex = /^[0-9a-f]{8}-[0-9a-f]{4}-4[0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$/i;
|
|
80
|
+
|
|
81
|
+
// Phone (basic international)
|
|
82
|
+
const phoneRegex = /^\+?[1-9]\d{1,14}$/;
|
|
83
|
+
```
|
|
84
|
+
|
|
85
|
+
## API Validation Middleware
|
|
86
|
+
|
|
87
|
+
```typescript
|
|
88
|
+
function validate(schema: z.ZodSchema) {
|
|
89
|
+
return (req, res, next) => {
|
|
90
|
+
try {
|
|
91
|
+
req.body = schema.parse(req.body);
|
|
92
|
+
next();
|
|
93
|
+
} catch (error) {
|
|
94
|
+
if (error instanceof z.ZodError) {
|
|
95
|
+
return res.status(400).json({
|
|
96
|
+
error: 'Validation failed',
|
|
97
|
+
details: error.errors
|
|
98
|
+
});
|
|
99
|
+
}
|
|
100
|
+
next(error);
|
|
101
|
+
}
|
|
102
|
+
};
|
|
103
|
+
}
|
|
104
|
+
|
|
105
|
+
// Usage
|
|
106
|
+
app.post('/users', validate(createUserSchema), createUserHandler);
|
|
107
|
+
```
|
|
@@ -0,0 +1,67 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: memory
|
|
3
|
+
description: Cross-session learning and decision tracking. Activate when starting tasks (check past lessons) or after completing work (record learnings). Provides formats for learning.md, decisions.md, and active.md in ai_context/memory/.
|
|
4
|
+
license: MIT
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Memory System
|
|
8
|
+
|
|
9
|
+
Persistent learning across sessions via ai_context/memory/ files.
|
|
10
|
+
|
|
11
|
+
## When to Use
|
|
12
|
+
|
|
13
|
+
**Before starting work:**
|
|
14
|
+
- Read `ai_context/memory/learning.md` to avoid past mistakes
|
|
15
|
+
- Check `ai_context/memory/decisions.md` for architectural context
|
|
16
|
+
|
|
17
|
+
**After completing work:**
|
|
18
|
+
- Record new lessons in `learning.md`
|
|
19
|
+
- Document key decisions in `decisions.md`
|
|
20
|
+
- Update `active.md` with session context
|
|
21
|
+
|
|
22
|
+
## Memory Files
|
|
23
|
+
|
|
24
|
+
### learning.md
|
|
25
|
+
Retrospective lessons to avoid repeating mistakes.
|
|
26
|
+
Load: `references/learning-format.md`
|
|
27
|
+
|
|
28
|
+
### decisions.md
|
|
29
|
+
Key architectural and design decisions with rationale.
|
|
30
|
+
Load: `references/decisions-format.md`
|
|
31
|
+
|
|
32
|
+
### active.md
|
|
33
|
+
Current session context (temporary, overwritten each session).
|
|
34
|
+
|
|
35
|
+
Format:
|
|
36
|
+
```markdown
|
|
37
|
+
# Active Session Context
|
|
38
|
+
|
|
39
|
+
## Current Focus
|
|
40
|
+
[What you're working on]
|
|
41
|
+
|
|
42
|
+
## Recent Changes
|
|
43
|
+
[What was just modified]
|
|
44
|
+
|
|
45
|
+
## Blockers
|
|
46
|
+
[Any issues or questions]
|
|
47
|
+
```
|
|
48
|
+
|
|
49
|
+
## Quick Reference
|
|
50
|
+
|
|
51
|
+
**Check before implementing:**
|
|
52
|
+
```bash
|
|
53
|
+
cat ai_context/memory/learning.md
|
|
54
|
+
cat ai_context/memory/decisions.md
|
|
55
|
+
```
|
|
56
|
+
|
|
57
|
+
**Update after completing:**
|
|
58
|
+
1. Append to learning.md if learned something new
|
|
59
|
+
2. Append to decisions.md if made a key architectural choice
|
|
60
|
+
3. Update active.md with current session state
|
|
61
|
+
|
|
62
|
+
## Integration
|
|
63
|
+
|
|
64
|
+
All agents should:
|
|
65
|
+
1. Read memory files at task start
|
|
66
|
+
2. Update memory files after significant work
|
|
67
|
+
3. Reference past decisions when planning new features
|
|
@@ -0,0 +1,68 @@
|
|
|
1
|
+
# Decisions Log Format
|
|
2
|
+
|
|
3
|
+
## Entry Structure
|
|
4
|
+
|
|
5
|
+
```markdown
|
|
6
|
+
## [YYYY-MM-DD] - [Decision Title]
|
|
7
|
+
|
|
8
|
+
**Context**: Why this decision was needed
|
|
9
|
+
**Options Considered**:
|
|
10
|
+
1. Option A - [brief pros/cons]
|
|
11
|
+
2. Option B - [brief pros/cons]
|
|
12
|
+
|
|
13
|
+
**Decision**: What was chosen
|
|
14
|
+
**Rationale**: Why this choice
|
|
15
|
+
**Implications**: What this affects going forward
|
|
16
|
+
```
|
|
17
|
+
|
|
18
|
+
## When to Log Decisions
|
|
19
|
+
|
|
20
|
+
Document choices about:
|
|
21
|
+
- Architecture patterns (monolith vs microservices)
|
|
22
|
+
- Technology stack (framework, database, etc.)
|
|
23
|
+
- API design (REST vs GraphQL)
|
|
24
|
+
- Authentication approach (JWT, sessions, OAuth)
|
|
25
|
+
- Deployment strategy (serverless, containers)
|
|
26
|
+
- Testing strategy (unit vs integration focus)
|
|
27
|
+
- Third-party integrations
|
|
28
|
+
|
|
29
|
+
## Example Entry
|
|
30
|
+
|
|
31
|
+
```markdown
|
|
32
|
+
## 2025-12-24 - Authentication Strategy
|
|
33
|
+
|
|
34
|
+
**Context**: Need user authentication for the application
|
|
35
|
+
|
|
36
|
+
**Options Considered**:
|
|
37
|
+
1. Session-based - Simple, server-side state, harder to scale
|
|
38
|
+
2. JWT - Stateless, scalable, more complex implementation
|
|
39
|
+
3. OAuth only - Delegate to providers, limited control
|
|
40
|
+
|
|
41
|
+
**Decision**: JWT with refresh tokens
|
|
42
|
+
|
|
43
|
+
**Rationale**:
|
|
44
|
+
- Stateless for horizontal scaling
|
|
45
|
+
- Refresh tokens for security
|
|
46
|
+
- Can add OAuth providers later
|
|
47
|
+
|
|
48
|
+
**Implications**:
|
|
49
|
+
- Need secure token storage (httpOnly cookies)
|
|
50
|
+
- Implement refresh token rotation
|
|
51
|
+
- Consider token blacklist for logout
|
|
52
|
+
```
|
|
53
|
+
|
|
54
|
+
## Best Practices
|
|
55
|
+
|
|
56
|
+
- Record decision when made, not later
|
|
57
|
+
- Include "why" not just "what"
|
|
58
|
+
- List options even if choice was obvious
|
|
59
|
+
- Note constraints that influenced the decision
|
|
60
|
+
- Link to related plans if applicable
|
|
61
|
+
- Keep entries self-contained (readable without context)
|
|
62
|
+
|
|
63
|
+
## Reading Decisions
|
|
64
|
+
|
|
65
|
+
Before planning new features:
|
|
66
|
+
1. Check if related decisions exist
|
|
67
|
+
2. Consider if constraints have changed
|
|
68
|
+
3. Reference existing decisions in new plans
|