chore: update .gitignore and improve coding standards documentation
- Added .cursor/sessions/* to .gitignore to prevent session files from being tracked. - Enhanced coding standards in SKILL.md by adding semicolons to TypeScript examples for consistency. - Improved formatting in continuous learning, detail layout, and other SKILL.md files for better readability. These changes aim to streamline development processes and maintain code quality across the project.
This commit is contained in:
shancheas
@@ -19,18 +19,21 @@ You are a senior software architect specializing in scalable, maintainable syste
|
||||
## Architecture Review Process
|
||||
|
||||
### 1. Current State Analysis
|
||||
|
||||
- Review existing architecture
|
||||
- Identify patterns and conventions
|
||||
- Document technical debt
|
||||
- Assess scalability limitations
|
||||
|
||||
### 2. Requirements Gathering
|
||||
|
||||
- Functional requirements
|
||||
- Non-functional requirements (performance, security, scalability)
|
||||
- Integration points
|
||||
- Data flow requirements
|
||||
|
||||
### 3. Design Proposal
|
||||
|
||||
- High-level architecture diagram
|
||||
- Component responsibilities
|
||||
- Data models
|
||||
@@ -38,7 +41,9 @@ You are a senior software architect specializing in scalable, maintainable syste
|
||||
- Integration patterns
|
||||
|
||||
### 4. Trade-Off Analysis
|
||||
|
||||
For each design decision, document:
|
||||
|
||||
- **Pros**: Benefits and advantages
|
||||
- **Cons**: Drawbacks and limitations
|
||||
- **Alternatives**: Other options considered
|
||||
@@ -47,12 +52,14 @@ For each design decision, document:
|
||||
## Architectural Principles
|
||||
|
||||
### 1. Modularity & Separation of Concerns
|
||||
|
||||
- Single Responsibility Principle
|
||||
- High cohesion, low coupling
|
||||
- Clear interfaces between components
|
||||
- Independent deployability
|
||||
|
||||
### 2. Scalability
|
||||
|
||||
- Horizontal scaling capability
|
||||
- Stateless design where possible
|
||||
- Efficient database queries
|
||||
@@ -60,6 +67,7 @@ For each design decision, document:
|
||||
- Load balancing considerations
|
||||
|
||||
### 3. Maintainability
|
||||
|
||||
- Clear code organization
|
||||
- Consistent patterns
|
||||
- Comprehensive documentation
|
||||
@@ -67,6 +75,7 @@ For each design decision, document:
|
||||
- Simple to understand
|
||||
|
||||
### 4. Security
|
||||
|
||||
- Defense in depth
|
||||
- Principle of least privilege
|
||||
- Input validation at boundaries
|
||||
@@ -74,6 +83,7 @@ For each design decision, document:
|
||||
- Audit trail
|
||||
|
||||
### 5. Performance
|
||||
|
||||
- Efficient algorithms
|
||||
- Minimal network requests
|
||||
- Optimized database queries
|
||||
@@ -83,6 +93,7 @@ For each design decision, document:
|
||||
## Common Patterns
|
||||
|
||||
### Frontend Patterns
|
||||
|
||||
- **Component Composition**: Build complex UI from simple components
|
||||
- **Container/Presenter**: Separate data logic from presentation
|
||||
- **Custom Hooks**: Reusable stateful logic
|
||||
@@ -90,6 +101,7 @@ For each design decision, document:
|
||||
- **Code Splitting**: Lazy load routes and heavy components
|
||||
|
||||
### Backend Patterns
|
||||
|
||||
- **Repository Pattern**: Abstract data access
|
||||
- **Service Layer**: Business logic separation
|
||||
- **Middleware Pattern**: Request/response processing
|
||||
@@ -97,6 +109,7 @@ For each design decision, document:
|
||||
- **CQRS**: Separate read and write operations
|
||||
|
||||
### Data Patterns
|
||||
|
||||
- **Normalized Database**: Reduce redundancy
|
||||
- **Denormalized for Read Performance**: Optimize queries
|
||||
- **Event Sourcing**: Audit trail and replayability
|
||||
@@ -111,25 +124,31 @@ For significant architectural decisions, create ADRs:
|
||||
# ADR-001: Feature modules live in apps/web, shared UI in packages/ui
|
||||
|
||||
## Context
|
||||
|
||||
Need a default place for product screens vs reusable components.
|
||||
|
||||
## Decision
|
||||
|
||||
Product modules under `apps/web/src/apps/main/modules/` (copy `example/full-page`). Shared primitives in `packages/ui`. Cross-module app code in `src/core/`.
|
||||
|
||||
## Consequences
|
||||
|
||||
### Positive
|
||||
|
||||
- Clear promotion path: module → core → package
|
||||
- Showcase and docs stay free of product logic
|
||||
|
||||
### Negative
|
||||
|
||||
- Easy to over-share too early (YAGNI)
|
||||
|
||||
### Alternatives Considered
|
||||
|
||||
- All UI in apps/web (duplicates landing/showcase)
|
||||
- All features in packages/ui (mixes product with design system)
|
||||
|
||||
## Status
|
||||
|
||||
Accepted
|
||||
```
|
||||
|
||||
@@ -138,18 +157,21 @@ Accepted
|
||||
When designing a new system or feature:
|
||||
|
||||
### Functional Requirements
|
||||
|
||||
- [ ] User stories documented
|
||||
- [ ] API contracts defined
|
||||
- [ ] Data models specified
|
||||
- [ ] UI/UX flows mapped
|
||||
|
||||
### Non-Functional Requirements
|
||||
|
||||
- [ ] Performance targets defined (latency, throughput)
|
||||
- [ ] Scalability requirements specified
|
||||
- [ ] Security requirements identified
|
||||
- [ ] Availability targets set (uptime %)
|
||||
|
||||
### Technical Design
|
||||
|
||||
- [ ] Architecture diagram created
|
||||
- [ ] Component responsibilities defined
|
||||
- [ ] Data flow documented
|
||||
@@ -158,6 +180,7 @@ When designing a new system or feature:
|
||||
- [ ] Testing strategy planned
|
||||
|
||||
### Operations
|
||||
|
||||
- [ ] Deployment strategy defined
|
||||
- [ ] Monitoring and alerting planned
|
||||
- [ ] Backup and recovery strategy
|
||||
@@ -166,6 +189,7 @@ When designing a new system or feature:
|
||||
## Red Flags
|
||||
|
||||
Watch for these architectural anti-patterns:
|
||||
|
||||
- **Big Ball of Mud**: No clear structure
|
||||
- **Golden Hammer**: Using same solution for everything
|
||||
- **Premature Optimization**: Optimizing too early
|
||||
|
||||
@@ -8,11 +8,13 @@ model: opus
|
||||
You are a senior code reviewer ensuring high standards of code quality and security.
|
||||
|
||||
When invoked:
|
||||
|
||||
1. Run git diff to see recent changes
|
||||
2. Focus on modified files
|
||||
3. Begin review immediately
|
||||
|
||||
Review checklist:
|
||||
|
||||
- Code is simple and readable
|
||||
- Functions and variables are well-named
|
||||
- No duplicated code
|
||||
@@ -25,6 +27,7 @@ Review checklist:
|
||||
- Licenses of integrated libraries checked
|
||||
|
||||
Provide feedback organized by priority:
|
||||
|
||||
- Critical issues (must fix)
|
||||
- Warnings (should fix)
|
||||
- Suggestions (consider improving)
|
||||
@@ -74,6 +77,7 @@ Include specific examples of how to fix issues.
|
||||
## Review Output Format
|
||||
|
||||
For each issue:
|
||||
|
||||
```
|
||||
[CRITICAL] Hardcoded API key
|
||||
File: src/core/lib/api-client.ts:42
|
||||
|
||||
@@ -42,14 +42,14 @@ Canonical sample: `apps/web/src/apps/main/modules/example/full-page/`. Copy that
|
||||
### Package component tests (Testing Library)
|
||||
|
||||
```tsx
|
||||
import { render, screen } from '@testing-library/react'
|
||||
import userEvent from '@testing-library/user-event'
|
||||
import { FieldTextInput } from '@repo/ui/form'
|
||||
import { render, screen } from '@testing-library/react';
|
||||
import userEvent from '@testing-library/user-event';
|
||||
import { FieldTextInput } from '@repo/ui/form';
|
||||
|
||||
it('renders the field label', () => {
|
||||
render(<FieldTextInput name="code" label="Code" />)
|
||||
expect(screen.getByLabelText('Code')).toBeInTheDocument()
|
||||
})
|
||||
render(<FieldTextInput name="code" label="Code" />);
|
||||
expect(screen.getByLabelText('Code')).toBeInTheDocument();
|
||||
});
|
||||
```
|
||||
|
||||
### Mock remote data services (not a database)
|
||||
@@ -63,7 +63,7 @@ vi.mock('../../domain/factories', () => ({
|
||||
update: vi.fn(),
|
||||
delete: vi.fn(),
|
||||
},
|
||||
}))
|
||||
}));
|
||||
```
|
||||
|
||||
## Browser verification (`apps/web`)
|
||||
@@ -92,9 +92,11 @@ Do not add Playwright unless the user explicitly asks.
|
||||
**Command:** pnpm test
|
||||
|
||||
## Summary
|
||||
|
||||
- Total / passed / failed
|
||||
|
||||
## Failed
|
||||
|
||||
- File — assertion
|
||||
- Recommended fix
|
||||
```
|
||||
|
||||
@@ -18,19 +18,23 @@ You are an expert planning specialist focused on creating comprehensive, actiona
|
||||
## Planning Process
|
||||
|
||||
### 1. Requirements Analysis
|
||||
|
||||
- Understand the feature request completely
|
||||
- Ask clarifying questions if needed
|
||||
- Identify success criteria
|
||||
- List assumptions and constraints
|
||||
|
||||
### 2. Architecture Review
|
||||
|
||||
- Analyze existing codebase structure
|
||||
- Identify affected components
|
||||
- Review similar implementations
|
||||
- Consider reusable patterns
|
||||
|
||||
### 3. Step Breakdown
|
||||
|
||||
Create detailed steps with:
|
||||
|
||||
- Clear, specific actions
|
||||
- File paths and locations
|
||||
- Dependencies between steps
|
||||
@@ -38,6 +42,7 @@ Create detailed steps with:
|
||||
- Potential risks
|
||||
|
||||
### 4. Implementation Order
|
||||
|
||||
- Prioritize by dependencies
|
||||
- Group related changes
|
||||
- Minimize context switching
|
||||
@@ -49,20 +54,25 @@ Create detailed steps with:
|
||||
# Implementation Plan: [Feature Name]
|
||||
|
||||
## Overview
|
||||
|
||||
[2-3 sentence summary]
|
||||
|
||||
## Requirements
|
||||
|
||||
- [Requirement 1]
|
||||
- [Requirement 2]
|
||||
|
||||
## Architecture Changes
|
||||
|
||||
- [Change 1: file path and description]
|
||||
- [Change 2: file path and description]
|
||||
|
||||
## Implementation Steps
|
||||
|
||||
### Phase 1: [Phase Name]
|
||||
|
||||
1. **[Step Name]** (File: path/to/file.ts)
|
||||
|
||||
- Action: Specific action to take
|
||||
- Why: Reason for this step
|
||||
- Dependencies: None / Requires step X
|
||||
@@ -72,18 +82,22 @@ Create detailed steps with:
|
||||
...
|
||||
|
||||
### Phase 2: [Phase Name]
|
||||
|
||||
...
|
||||
|
||||
## Testing Strategy
|
||||
|
||||
- Unit tests: [files to test]
|
||||
- Integration tests: [flows to test]
|
||||
- E2E tests: [user journeys to test]
|
||||
|
||||
## Risks & Mitigations
|
||||
|
||||
- **Risk**: [Description]
|
||||
- Mitigation: [How to address]
|
||||
|
||||
## Success Criteria
|
||||
|
||||
- [ ] Criterion 1
|
||||
- [ ] Criterion 2
|
||||
```
|
||||
|
||||
@@ -20,12 +20,14 @@ You are an expert refactoring specialist focused on code cleanup and consolidati
|
||||
## Tools at Your Disposal
|
||||
|
||||
### Detection Tools
|
||||
|
||||
- **knip** - Find unused files, exports, dependencies, types
|
||||
- **depcheck** - Identify unused npm dependencies
|
||||
- **ts-prune** - Find unused TypeScript exports
|
||||
- **eslint** - Check for unused disable-directives and variables
|
||||
|
||||
### Analysis Commands
|
||||
|
||||
```bash
|
||||
# Run knip for unused exports/files/dependencies
|
||||
npx knip
|
||||
@@ -43,6 +45,7 @@ npx eslint . --report-unused-disable-directives
|
||||
## Refactoring Workflow
|
||||
|
||||
### 1. Analysis Phase
|
||||
|
||||
```
|
||||
a) Run detection tools in parallel
|
||||
b) Collect all findings
|
||||
@@ -53,6 +56,7 @@ c) Categorize by risk level:
|
||||
```
|
||||
|
||||
### 2. Risk Assessment
|
||||
|
||||
```
|
||||
For each item to remove:
|
||||
- Check if it's imported anywhere (grep search)
|
||||
@@ -63,6 +67,7 @@ For each item to remove:
|
||||
```
|
||||
|
||||
### 3. Safe Removal Process
|
||||
|
||||
```
|
||||
a) Start with SAFE items only
|
||||
b) Remove one category at a time:
|
||||
@@ -75,6 +80,7 @@ d) Create git commit for each batch
|
||||
```
|
||||
|
||||
### 4. Duplicate Consolidation
|
||||
|
||||
```
|
||||
a) Find duplicate components/utilities
|
||||
b) Choose the best implementation:
|
||||
@@ -96,28 +102,34 @@ Create/update `docs/DELETION_LOG.md` with this structure:
|
||||
## [YYYY-MM-DD] Refactor Session
|
||||
|
||||
### Unused Dependencies Removed
|
||||
|
||||
- package-name@version - Last used: never, Size: XX KB
|
||||
- another-package@version - Replaced by: better-package
|
||||
|
||||
### Unused Files Deleted
|
||||
|
||||
- src/old-component.tsx - Replaced by: src/new-component.tsx
|
||||
- lib/deprecated-util.ts - Functionality moved to: lib/utils.ts
|
||||
|
||||
### Duplicate Code Consolidated
|
||||
|
||||
- src/components/Button1.tsx + Button2.tsx → Button.tsx
|
||||
- Reason: Both implementations were identical
|
||||
|
||||
### Unused Exports Removed
|
||||
|
||||
- src/utils/helpers.ts - Functions: foo(), bar()
|
||||
- Reason: No references found in codebase
|
||||
|
||||
### Impact
|
||||
|
||||
- Files deleted: 15
|
||||
- Dependencies removed: 5
|
||||
- Lines of code removed: 2,300
|
||||
- Bundle size reduction: ~45 KB
|
||||
|
||||
### Testing
|
||||
|
||||
- All unit tests passing: ✓
|
||||
- All integration tests passing: ✓
|
||||
- Manual testing completed: ✓
|
||||
@@ -126,6 +138,7 @@ Create/update `docs/DELETION_LOG.md` with this structure:
|
||||
## Safety Checklist
|
||||
|
||||
Before removing ANYTHING:
|
||||
|
||||
- [ ] Run detection tools
|
||||
- [ ] Grep for all references
|
||||
- [ ] Check dynamic imports
|
||||
@@ -136,6 +149,7 @@ Before removing ANYTHING:
|
||||
- [ ] Document in DELETION_LOG.md
|
||||
|
||||
After each removal:
|
||||
|
||||
- [ ] Build succeeds
|
||||
- [ ] Tests pass
|
||||
- [ ] No console errors
|
||||
@@ -145,20 +159,22 @@ After each removal:
|
||||
## Common Patterns to Remove
|
||||
|
||||
### 1. Unused Imports
|
||||
|
||||
```typescript
|
||||
// ❌ Remove unused imports
|
||||
import { useState, useEffect, useMemo } from 'react' // Only useState used
|
||||
import { useState, useEffect, useMemo } from 'react'; // Only useState used
|
||||
|
||||
// ✅ Keep only what's used
|
||||
import { useState } from 'react'
|
||||
import { useState } from 'react';
|
||||
```
|
||||
|
||||
### 2. Dead Code Branches
|
||||
|
||||
```typescript
|
||||
// ❌ Remove unreachable code
|
||||
if (false) {
|
||||
// This never executes
|
||||
doSomething()
|
||||
doSomething();
|
||||
}
|
||||
|
||||
// ❌ Remove unused functions
|
||||
@@ -168,6 +184,7 @@ export function unusedHelper() {
|
||||
```
|
||||
|
||||
### 3. Duplicate Components
|
||||
|
||||
```typescript
|
||||
// ❌ Multiple similar components
|
||||
components/Button.tsx
|
||||
@@ -179,12 +196,13 @@ components/Button.tsx (with variant prop)
|
||||
```
|
||||
|
||||
### 4. Unused Dependencies
|
||||
|
||||
```json
|
||||
// ❌ Package installed but not imported
|
||||
{
|
||||
"dependencies": {
|
||||
"lodash": "^4.17.21", // Not used anywhere
|
||||
"moment": "^2.29.4" // Replaced by date-fns
|
||||
"lodash": "^4.17.21", // Not used anywhere
|
||||
"moment": "^2.29.4" // Replaced by date-fns
|
||||
}
|
||||
}
|
||||
```
|
||||
@@ -192,6 +210,7 @@ components/Button.tsx (with variant prop)
|
||||
## Example Project-Specific Rules
|
||||
|
||||
**CRITICAL - NEVER REMOVE:**
|
||||
|
||||
- `apiClient` / `createHttpClient` wiring
|
||||
- `terminateAuthSession` / auth interceptors
|
||||
- `EnterpriseModuleProvider` and FULL_PAGE page providers
|
||||
@@ -199,6 +218,7 @@ components/Button.tsx (with variant prop)
|
||||
- Electron preload / IPC bridge
|
||||
|
||||
**SAFE TO REMOVE:**
|
||||
|
||||
- Old unused components in components/ folder
|
||||
- Deprecated utility functions
|
||||
- Test files for deleted features
|
||||
@@ -206,6 +226,7 @@ components/Button.tsx (with variant prop)
|
||||
- Unused TypeScript types/interfaces
|
||||
|
||||
**ALWAYS VERIFY:**
|
||||
|
||||
- Auth login + `terminateAuthSession`
|
||||
- `example/full-page` still routes and loads
|
||||
- `@repo/ui` exports used by web/showcase
|
||||
@@ -219,26 +240,31 @@ When opening PR with deletions:
|
||||
## Refactor: Code Cleanup
|
||||
|
||||
### Summary
|
||||
|
||||
Dead code cleanup removing unused exports, dependencies, and duplicates.
|
||||
|
||||
### Changes
|
||||
|
||||
- Removed X unused files
|
||||
- Removed Y unused dependencies
|
||||
- Consolidated Z duplicate components
|
||||
- See docs/DELETION_LOG.md for details
|
||||
|
||||
### Testing
|
||||
|
||||
- [x] Build passes
|
||||
- [x] All tests pass
|
||||
- [x] Manual testing completed
|
||||
- [x] No console errors
|
||||
|
||||
### Impact
|
||||
|
||||
- Bundle size: -XX KB
|
||||
- Lines of code: -XXXX
|
||||
- Dependencies: -X packages
|
||||
|
||||
### Risk Level
|
||||
|
||||
🟢 LOW - Only removed verifiably unused code
|
||||
|
||||
See DELETION_LOG.md for complete details.
|
||||
@@ -249,6 +275,7 @@ See DELETION_LOG.md for complete details.
|
||||
If something breaks after removal:
|
||||
|
||||
1. **Immediate rollback:**
|
||||
|
||||
```bash
|
||||
git revert HEAD
|
||||
pnpm install
|
||||
@@ -257,11 +284,13 @@ If something breaks after removal:
|
||||
```
|
||||
|
||||
2. **Investigate:**
|
||||
|
||||
- What failed?
|
||||
- Was it a dynamic import?
|
||||
- Was it used in a way detection tools missed?
|
||||
|
||||
3. **Fix forward:**
|
||||
|
||||
- Mark item as "DO NOT REMOVE" in notes
|
||||
- Document why detection tools missed it
|
||||
- Add explicit type annotations if needed
|
||||
@@ -293,6 +322,7 @@ If something breaks after removal:
|
||||
## Success Metrics
|
||||
|
||||
After cleanup session:
|
||||
|
||||
- ✅ All tests passing
|
||||
- ✅ Build succeeds
|
||||
- ✅ No console errors
|
||||
|
||||
@@ -65,7 +65,10 @@ If CRITICAL: stop, fix, rotate any leaked secret, scan for the same pattern.
|
||||
|
||||
```markdown
|
||||
# Security Review
|
||||
|
||||
**Status:** CLEAR / ISSUES FOUND
|
||||
|
||||
## Critical / High / Medium
|
||||
|
||||
- File:line — issue — fix
|
||||
```
|
||||
|
||||
+10
-10
@@ -19,18 +19,18 @@ You are a Test-Driven Development (TDD) specialist. This repo uses **Vitest** (a
|
||||
### Step 1: Write the test first (RED)
|
||||
|
||||
```typescript
|
||||
import { describe, it, expect } from 'vitest'
|
||||
import { createFullPageSchema } from './full-page.validator'
|
||||
import { describe, it, expect } from 'vitest';
|
||||
import { createFullPageSchema } from './full-page.validator';
|
||||
|
||||
describe('createFullPageSchema', () => {
|
||||
const t = (key: string) => key
|
||||
const t = (key: string) => key;
|
||||
|
||||
it('rejects an empty code', () => {
|
||||
const schema = createFullPageSchema(t)
|
||||
const result = schema.safeParse({ code: '', name: 'Widget' })
|
||||
expect(result.success).toBe(false)
|
||||
})
|
||||
})
|
||||
const schema = createFullPageSchema(t);
|
||||
const result = schema.safeParse({ code: '', name: 'Widget' });
|
||||
expect(result.success).toBe(false);
|
||||
});
|
||||
});
|
||||
```
|
||||
|
||||
### Step 2: Run it (must FAIL)
|
||||
@@ -47,7 +47,7 @@ export const createFullPageSchema = (t: (key: string) => string) =>
|
||||
z.object({
|
||||
code: compose(z.string(), required(t('common:fields.code'))),
|
||||
name: compose(z.string(), required(t('common:fields.name')), rangeLength(3, 50, t('common:fields.name'))),
|
||||
})
|
||||
});
|
||||
```
|
||||
|
||||
### Step 4: Run until green, then refactor. Coverage via `pnpm test` / `pnpm check:all`.
|
||||
@@ -65,7 +65,7 @@ Mock `@repo/core-api` and `apiClient` — not a database.
|
||||
```ts
|
||||
vi.mock('@repo/core-api/http-client', () => ({
|
||||
createHttpClient: () => ({ get: vi.fn(), post: vi.fn(), put: vi.fn(), delete: vi.fn() }),
|
||||
}))
|
||||
}));
|
||||
```
|
||||
|
||||
## Edge cases you MUST test
|
||||
|
||||
@@ -5,16 +5,19 @@ Incrementally fix TypeScript and build errors:
|
||||
1. Run `pnpm typecheck` or `pnpm build` (this repo uses pnpm + Turbo + Vite)
|
||||
|
||||
2. Parse error output:
|
||||
|
||||
- Group by file
|
||||
- Sort by severity
|
||||
|
||||
3. For each error:
|
||||
|
||||
- Show 5 lines of context
|
||||
- Explain the issue
|
||||
- Apply a minimal fix
|
||||
- Re-run the failing command
|
||||
|
||||
4. Stop if:
|
||||
|
||||
- The fix introduces new errors
|
||||
- The same error persists after 3 attempts
|
||||
- The user asks to pause
|
||||
|
||||
@@ -26,12 +26,14 @@ When verifying against a checkpoint:
|
||||
|
||||
1. Read checkpoint from log
|
||||
2. Compare current state to checkpoint:
|
||||
|
||||
- Files added since checkpoint
|
||||
- Files modified since checkpoint
|
||||
- Test pass rate now vs then
|
||||
- Coverage now vs then
|
||||
|
||||
3. Report:
|
||||
|
||||
```
|
||||
CHECKPOINT COMPARISON: $NAME
|
||||
============================
|
||||
@@ -44,6 +46,7 @@ Build: [PASS/FAIL]
|
||||
## List Checkpoints
|
||||
|
||||
Show all checkpoints with:
|
||||
|
||||
- Name
|
||||
- Timestamp
|
||||
- Git SHA
|
||||
@@ -68,6 +71,7 @@ Typical checkpoint flow:
|
||||
## Arguments
|
||||
|
||||
$ARGUMENTS:
|
||||
|
||||
- `create <name>` - Create named checkpoint
|
||||
- `verify <name>` - Verify against named checkpoint
|
||||
- `list` - Show all checkpoints
|
||||
|
||||
@@ -7,14 +7,16 @@ Comprehensive security and quality review of uncommitted changes:
|
||||
2. For each changed file, check for:
|
||||
|
||||
**Security Issues (CRITICAL):**
|
||||
|
||||
- Hardcoded credentials, API keys, tokens
|
||||
- SQL injection vulnerabilities
|
||||
- XSS vulnerabilities
|
||||
- XSS vulnerabilities
|
||||
- Missing input validation
|
||||
- Insecure dependencies
|
||||
- Path traversal risks
|
||||
|
||||
**Code Quality (HIGH):**
|
||||
|
||||
- Functions > 50 lines
|
||||
- Files > 800 lines
|
||||
- Nesting depth > 4 levels
|
||||
@@ -24,12 +26,14 @@ Comprehensive security and quality review of uncommitted changes:
|
||||
- Missing JSDoc for public APIs
|
||||
|
||||
**Best Practices (MEDIUM):**
|
||||
|
||||
- Mutation patterns (use immutable instead)
|
||||
- Emoji usage in code/comments
|
||||
- Missing tests for new code
|
||||
- Accessibility issues (a11y)
|
||||
|
||||
3. Generate report with:
|
||||
|
||||
- Severity: CRITICAL, HIGH, MEDIUM, LOW
|
||||
- File location and line numbers
|
||||
- Issue description
|
||||
|
||||
@@ -16,17 +16,21 @@ Create a new eval definition:
|
||||
|
||||
```markdown
|
||||
## EVAL: feature-name
|
||||
|
||||
Created: $(date)
|
||||
|
||||
### Capability Evals
|
||||
|
||||
- [ ] [Description of capability 1]
|
||||
- [ ] [Description of capability 2]
|
||||
|
||||
### Regression Evals
|
||||
|
||||
- [ ] [Existing behavior 1 still works]
|
||||
- [ ] [Existing behavior 2 still works]
|
||||
|
||||
### Success Criteria
|
||||
|
||||
- pass@3 > 90% for capability evals
|
||||
- pass^3 = 100% for regression evals
|
||||
```
|
||||
@@ -113,6 +117,7 @@ feature-export [0/4 passing] NOT STARTED
|
||||
## Arguments
|
||||
|
||||
$ARGUMENTS:
|
||||
|
||||
- `define <name>` - Create new eval definition
|
||||
- `check <name>` - Run and check evals
|
||||
- `report <name>` - Generate full report
|
||||
|
||||
@@ -11,17 +11,20 @@ Run `/learn` at any point during a session when you've solved a non-trivial prob
|
||||
Look for:
|
||||
|
||||
1. **Error Resolution Patterns**
|
||||
|
||||
- What error occurred?
|
||||
- What was the root cause?
|
||||
- What fixed it?
|
||||
- Is this reusable for similar errors?
|
||||
|
||||
2. **Debugging Techniques**
|
||||
|
||||
- Non-obvious debugging steps
|
||||
- Tool combinations that worked
|
||||
- Diagnostic patterns
|
||||
|
||||
3. **Workarounds**
|
||||
|
||||
- Library quirks
|
||||
- API limitations
|
||||
- Version-specific fixes
|
||||
@@ -42,15 +45,19 @@ Create a skill file at `.agents/skills/learned/[pattern-name].md`:
|
||||
**Context:** [Brief description of when this applies]
|
||||
|
||||
## Problem
|
||||
|
||||
[What problem this solves - be specific]
|
||||
|
||||
## Solution
|
||||
|
||||
[The pattern/technique/workaround]
|
||||
|
||||
## Example
|
||||
|
||||
[Code example if applicable]
|
||||
|
||||
## When to Use
|
||||
|
||||
[Trigger conditions - what should activate this skill]
|
||||
```
|
||||
|
||||
|
||||
@@ -9,25 +9,33 @@ Sequential agent workflow for complex tasks.
|
||||
## Workflow Types
|
||||
|
||||
### feature
|
||||
|
||||
Full feature implementation workflow:
|
||||
|
||||
```
|
||||
planner -> tdd-guide -> code-reviewer -> security-reviewer
|
||||
```
|
||||
|
||||
### bugfix
|
||||
|
||||
Bug investigation and fix workflow:
|
||||
|
||||
```
|
||||
explorer -> tdd-guide -> code-reviewer
|
||||
```
|
||||
|
||||
### refactor
|
||||
|
||||
Safe refactoring workflow:
|
||||
|
||||
```
|
||||
architect -> code-reviewer -> tdd-guide
|
||||
```
|
||||
|
||||
### security
|
||||
|
||||
Security-focused review:
|
||||
|
||||
```
|
||||
security-reviewer -> code-reviewer -> architect
|
||||
```
|
||||
@@ -49,18 +57,23 @@ Between agents, create handoff document:
|
||||
## HANDOFF: [previous-agent] -> [next-agent]
|
||||
|
||||
### Context
|
||||
|
||||
[Summary of what was done]
|
||||
|
||||
### Findings
|
||||
|
||||
[Key discoveries or decisions]
|
||||
|
||||
### Files Modified
|
||||
|
||||
[List of files touched]
|
||||
|
||||
### Open Questions
|
||||
|
||||
[Unresolved items for next agent]
|
||||
|
||||
### Recommendations
|
||||
|
||||
[Suggested next steps]
|
||||
```
|
||||
|
||||
@@ -73,18 +86,21 @@ Between agents, create handoff document:
|
||||
Executes:
|
||||
|
||||
1. **Planner Agent**
|
||||
|
||||
- Analyzes requirements
|
||||
- Creates implementation plan
|
||||
- Identifies dependencies
|
||||
- Output: `HANDOFF: planner -> tdd-guide`
|
||||
|
||||
2. **TDD Guide Agent**
|
||||
|
||||
- Reads planner handoff
|
||||
- Writes tests first
|
||||
- Implements to pass tests
|
||||
- Output: `HANDOFF: tdd-guide -> code-reviewer`
|
||||
|
||||
3. **Code Reviewer Agent**
|
||||
|
||||
- Reviews implementation
|
||||
- Checks for issues
|
||||
- Suggests improvements
|
||||
@@ -139,18 +155,22 @@ For independent checks, run agents in parallel:
|
||||
|
||||
```markdown
|
||||
### Parallel Phase
|
||||
|
||||
Run simultaneously:
|
||||
|
||||
- code-reviewer (quality)
|
||||
- security-reviewer (security)
|
||||
- architect (design)
|
||||
|
||||
### Merge Results
|
||||
|
||||
Combine outputs into single report
|
||||
```
|
||||
|
||||
## Arguments
|
||||
|
||||
$ARGUMENTS:
|
||||
|
||||
- `feature <description>` - Full feature workflow
|
||||
- `bugfix <description>` - Bug fix workflow
|
||||
- `refactor <description>` - Refactoring workflow
|
||||
|
||||
@@ -16,6 +16,7 @@ This command invokes the **planner** agent to create a comprehensive implementat
|
||||
## When to Use
|
||||
|
||||
Use `/plan` when:
|
||||
|
||||
- Starting a new feature
|
||||
- Making significant architectural changes
|
||||
- Working on complex refactoring
|
||||
@@ -82,6 +83,7 @@ Agent (planner):
|
||||
**CRITICAL**: The planner agent will **NOT** write any code until you explicitly confirm the plan with "yes" or "proceed" or similar affirmative response.
|
||||
|
||||
If you want changes, respond with:
|
||||
|
||||
- "modify: [your changes]"
|
||||
- "different approach: [alternative]"
|
||||
- "skip phase 2 and do phase 3 first"
|
||||
@@ -89,6 +91,7 @@ If you want changes, respond with:
|
||||
## Integration with Other Commands
|
||||
|
||||
After planning:
|
||||
|
||||
- Use `/tdd` to implement with test-driven development
|
||||
- Use `/build-and-fix` if build errors occur
|
||||
- Use `/code-review` to review completed implementation
|
||||
|
||||
@@ -3,6 +3,7 @@
|
||||
Safely identify and remove dead code with test verification:
|
||||
|
||||
1. Run dead code analysis tools:
|
||||
|
||||
- knip: Find unused exports and files
|
||||
- depcheck: Find unused dependencies
|
||||
- ts-prune: Find unused TypeScript exports
|
||||
@@ -10,6 +11,7 @@ Safely identify and remove dead code with test verification:
|
||||
2. Generate comprehensive report in .reports/dead-code-analysis.md
|
||||
|
||||
3. Categorize findings by severity:
|
||||
|
||||
- SAFE: Test files, unused utilities
|
||||
- CAUTION: API routes, components
|
||||
- DANGER: Config files, main entry points
|
||||
@@ -17,6 +19,7 @@ Safely identify and remove dead code with test verification:
|
||||
4. Propose safe deletions only
|
||||
|
||||
5. Before each deletion:
|
||||
|
||||
- Run full test suite
|
||||
- Verify tests pass
|
||||
- Apply change
|
||||
|
||||
@@ -37,6 +37,7 @@ When determining which package manager to use, the following order is checked:
|
||||
## Configuration Files
|
||||
|
||||
### Global Configuration
|
||||
|
||||
```json
|
||||
// ~/.cursor/package-manager.json
|
||||
{
|
||||
@@ -45,6 +46,7 @@ When determining which package manager to use, the following order is checked:
|
||||
```
|
||||
|
||||
### Project Configuration
|
||||
|
||||
```json
|
||||
// .cursor/package-manager.json
|
||||
{
|
||||
@@ -53,6 +55,7 @@ When determining which package manager to use, the following order is checked:
|
||||
```
|
||||
|
||||
### package.json
|
||||
|
||||
```json
|
||||
{
|
||||
"packageManager": "pnpm@8.6.0"
|
||||
|
||||
@@ -34,12 +34,12 @@ User: /tdd Add validation for the full-page name field
|
||||
|
||||
```typescript
|
||||
// full-page.validator.test.ts
|
||||
import { createFullPageSchema } from './full-page.validator'
|
||||
import { createFullPageSchema } from './full-page.validator';
|
||||
|
||||
it('rejects an empty name', () => {
|
||||
const schema = createFullPageSchema((k) => k)
|
||||
expect(schema.safeParse({ code: 'ABC', name: '' }).success).toBe(false)
|
||||
})
|
||||
const schema = createFullPageSchema((k) => k);
|
||||
expect(schema.safeParse({ code: 'ABC', name: '' }).success).toBe(false);
|
||||
});
|
||||
```
|
||||
|
||||
```bash
|
||||
|
||||
@@ -7,6 +7,7 @@ Analyze Vitest coverage and add missing tests:
|
||||
2. Identify files below 80%
|
||||
|
||||
3. For each under-covered file:
|
||||
|
||||
- Unit tests for validators, transformers, utils, stores
|
||||
- Testing Library tests for `@repo/ui` components
|
||||
- Journey tests for critical `apps/web` flows (mock data services)
|
||||
@@ -16,6 +17,7 @@ Analyze Vitest coverage and add missing tests:
|
||||
5. Show before/after coverage
|
||||
|
||||
Focus on:
|
||||
|
||||
- Happy path
|
||||
- Error handling
|
||||
- Edge cases (null, undefined, empty)
|
||||
|
||||
@@ -3,12 +3,15 @@
|
||||
Sync docs with this frontend monorepo. Source of truth: `package.json`, `apps/web/.env.example`, and `apps/docs-dev` (VitePress).
|
||||
|
||||
1. Read root `package.json` scripts
|
||||
|
||||
- Table of `pnpm dev:web`, `pnpm dev:showcase`, `pnpm dev:docs-dev`, `pnpm typecheck:web`, `pnpm test`, `pnpm check:all`
|
||||
|
||||
2. Read `apps/web/.env.example`
|
||||
|
||||
- Document each `VITE_*` var (they are public to the client)
|
||||
|
||||
3. Update `apps/docs-dev` (VitePress) and the root README
|
||||
|
||||
- Where to work (`apps/web` vs `showcase`)
|
||||
- Module layout (`example/full-page`)
|
||||
- Preferred `@repo/*` imports
|
||||
|
||||
@@ -7,23 +7,28 @@ Run comprehensive verification on current codebase state.
|
||||
Execute verification in this exact order:
|
||||
|
||||
1. **Build Check**
|
||||
|
||||
- Run the build command for this project
|
||||
- If it fails, report errors and STOP
|
||||
|
||||
2. **Type Check**
|
||||
|
||||
- Run TypeScript/type checker
|
||||
- Report all errors with file:line
|
||||
|
||||
3. **Lint Check**
|
||||
|
||||
- Run linter
|
||||
- Report warnings and errors
|
||||
|
||||
4. **Test Suite**
|
||||
|
||||
- Run all tests
|
||||
- Report pass/fail count
|
||||
- Report coverage percentage
|
||||
|
||||
5. **Console.log Audit**
|
||||
|
||||
- Search for console.log in source files
|
||||
- Report locations
|
||||
|
||||
@@ -53,6 +58,7 @@ If any critical issues, list them with fix suggestions.
|
||||
## Arguments
|
||||
|
||||
$ARGUMENTS can be:
|
||||
|
||||
- `quick` - Only build + types
|
||||
- `full` - All checks (default)
|
||||
- `pre-commit` - Checks relevant for commits
|
||||
|
||||
@@ -4,17 +4,20 @@ Mode: Active development
|
||||
Focus: Implementation, coding, building features
|
||||
|
||||
## Behavior
|
||||
|
||||
- Write code first, explain after
|
||||
- Prefer working solutions over perfect solutions
|
||||
- Run tests after changes
|
||||
- Keep commits atomic
|
||||
|
||||
## Priorities
|
||||
|
||||
1. Get it working
|
||||
2. Get it right
|
||||
3. Get it clean
|
||||
|
||||
## Tools to favor
|
||||
|
||||
- Edit, Write for code changes
|
||||
- Bash for running tests/builds
|
||||
- Grep, Glob for finding code
|
||||
|
||||
@@ -4,12 +4,14 @@ Mode: Exploration, investigation, learning
|
||||
Focus: Understanding before acting
|
||||
|
||||
## Behavior
|
||||
|
||||
- Read widely before concluding
|
||||
- Ask clarifying questions
|
||||
- Document findings as you go
|
||||
- Don't write code until understanding is clear
|
||||
|
||||
## Research Process
|
||||
|
||||
1. Understand the question
|
||||
2. Explore relevant code/docs
|
||||
3. Form hypothesis
|
||||
@@ -17,10 +19,12 @@ Focus: Understanding before acting
|
||||
5. Summarize findings
|
||||
|
||||
## Tools to favor
|
||||
|
||||
- Read for understanding code
|
||||
- Grep, Glob for finding patterns
|
||||
- WebSearch, WebFetch for external docs
|
||||
- Task with Explore agent for codebase questions
|
||||
|
||||
## Output
|
||||
|
||||
Findings first, recommendations second
|
||||
|
||||
@@ -4,12 +4,14 @@ Mode: PR review, code analysis
|
||||
Focus: Quality, security, maintainability
|
||||
|
||||
## Behavior
|
||||
|
||||
- Read thoroughly before commenting
|
||||
- Prioritize issues by severity (critical > high > medium > low)
|
||||
- Suggest fixes, don't just point out problems
|
||||
- Check for security vulnerabilities
|
||||
|
||||
## Review Checklist
|
||||
|
||||
- [ ] Logic errors
|
||||
- [ ] Edge cases
|
||||
- [ ] Error handling
|
||||
@@ -19,4 +21,5 @@ Focus: Quality, security, maintainability
|
||||
- [ ] Test coverage
|
||||
|
||||
## Output Format
|
||||
|
||||
Group findings by file, severity first
|
||||
|
||||
Reference in New Issue
Block a user