fe-kit-cli 0.0.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/README.md +89 -0
- package/dist/cli.mjs +1738 -0
- package/dist/cli.mjs.map +1 -0
- package/dist/rules/common/typescript.mdc +21 -0
- package/dist/rules/react/component-conventions.mdc +24 -0
- package/dist/rules/react/hooks.mdc +20 -0
- package/dist/rules/react/react-router.mdc +18 -0
- package/dist/rules/react/state-management.mdc +21 -0
- package/dist/rules/vue/component-conventions.mdc +23 -0
- package/dist/rules/vue/composition-api.mdc +24 -0
- package/dist/rules/vue/state-management.mdc +16 -0
- package/dist/rules/vue/vue-router.mdc +18 -0
- package/dist/skills/app-ui-design/SKILL.md +62 -0
- package/dist/skills/app-ui-design/references/rules.md +127 -0
- package/dist/skills/e2e-testing/SKILL.md +327 -0
- package/dist/skills/eval-harness/SKILL.md +271 -0
- package/dist/skills/frontend-design/SKILL.md +43 -0
- package/dist/skills/frontend-patterns/SKILL.md +643 -0
- package/dist/skills/security-review/SKILL.md +496 -0
- package/dist/skills/tailwindcss-advanced-layouts/SKILL.md +595 -0
- package/dist/skills/tdd-workflow/SKILL.md +464 -0
- package/dist/skills/verification-loop/SKILL.md +127 -0
- package/dist/skills/wechat-ui-design/SKILL.md +64 -0
- package/dist/skills/wechat-ui-design/references/rules.md +121 -0
- package/dist/templates/react-rspack-ts/index.html +11 -0
- package/dist/templates/react-rspack-ts/package.json +20 -0
- package/dist/templates/react-rspack-ts/rspack.config.ts +23 -0
- package/dist/templates/react-rspack-ts/src/App.tsx +7 -0
- package/dist/templates/react-rspack-ts/src/main.tsx +9 -0
- package/dist/templates/react-rspack-ts/tsconfig.json +17 -0
- package/dist/templates/react-vite-ts/index.html +12 -0
- package/dist/templates/react-vite-ts/package.json +22 -0
- package/dist/templates/react-vite-ts/src/App.tsx +7 -0
- package/dist/templates/react-vite-ts/src/main.tsx +9 -0
- package/dist/templates/react-vite-ts/tsconfig.json +19 -0
- package/dist/templates/react-vite-ts/vite.config.ts +9 -0
- package/dist/templates/react-webpack-ts/index.html +11 -0
- package/dist/templates/react-webpack-ts/package.json +25 -0
- package/dist/templates/react-webpack-ts/src/App.tsx +7 -0
- package/dist/templates/react-webpack-ts/src/main.tsx +9 -0
- package/dist/templates/react-webpack-ts/tsconfig.json +17 -0
- package/dist/templates/react-webpack-ts/webpack.config.ts +29 -0
- package/dist/templates/vue-rspack-ts/index.html +11 -0
- package/dist/templates/vue-rspack-ts/package.json +18 -0
- package/dist/templates/vue-rspack-ts/rspack.config.ts +16 -0
- package/dist/templates/vue-rspack-ts/src/App.vue +7 -0
- package/dist/templates/vue-rspack-ts/src/main.ts +4 -0
- package/dist/templates/vue-rspack-ts/tsconfig.json +17 -0
- package/dist/templates/vue-vite-ts/index.html +12 -0
- package/dist/templates/vue-vite-ts/package.json +19 -0
- package/dist/templates/vue-vite-ts/src/App.vue +7 -0
- package/dist/templates/vue-vite-ts/src/main.ts +4 -0
- package/dist/templates/vue-vite-ts/tsconfig.json +19 -0
- package/dist/templates/vue-vite-ts/vite.config.ts +9 -0
- package/dist/templates/vue-webpack-ts/index.html +11 -0
- package/dist/templates/vue-webpack-ts/package.json +24 -0
- package/dist/templates/vue-webpack-ts/src/App.vue +7 -0
- package/dist/templates/vue-webpack-ts/src/main.ts +4 -0
- package/dist/templates/vue-webpack-ts/tsconfig.json +17 -0
- package/dist/templates/vue-webpack-ts/webpack.config.ts +32 -0
- package/package.json +63 -0
|
@@ -0,0 +1,271 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: eval-harness
|
|
3
|
+
description: Formal evaluation framework for Claude Code sessions implementing eval-driven development (EDD) principles
|
|
4
|
+
origin: ECC
|
|
5
|
+
tools: Read, Write, Edit, Bash, Grep, Glob
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
# Eval Harness Skill
|
|
9
|
+
|
|
10
|
+
A formal evaluation framework for Claude Code sessions, implementing eval-driven development (EDD) principles.
|
|
11
|
+
|
|
12
|
+
## When to Activate
|
|
13
|
+
|
|
14
|
+
- Setting up eval-driven development (EDD) for AI-assisted workflows
|
|
15
|
+
- Defining pass/fail criteria for Claude Code task completion
|
|
16
|
+
- Measuring agent reliability with pass@k metrics
|
|
17
|
+
- Creating regression test suites for prompt or agent changes
|
|
18
|
+
- Benchmarking agent performance across model versions
|
|
19
|
+
|
|
20
|
+
## Philosophy
|
|
21
|
+
|
|
22
|
+
Eval-Driven Development treats evals as the "unit tests of AI development":
|
|
23
|
+
- Define expected behavior BEFORE implementation
|
|
24
|
+
- Run evals continuously during development
|
|
25
|
+
- Track regressions with each change
|
|
26
|
+
- Use pass@k metrics for reliability measurement
|
|
27
|
+
|
|
28
|
+
## Eval Types
|
|
29
|
+
|
|
30
|
+
### Capability Evals
|
|
31
|
+
Test if Claude can do something it couldn't before:
|
|
32
|
+
```markdown
|
|
33
|
+
[CAPABILITY EVAL: feature-name]
|
|
34
|
+
Task: Description of what Claude should accomplish
|
|
35
|
+
Success Criteria:
|
|
36
|
+
- [ ] Criterion 1
|
|
37
|
+
- [ ] Criterion 2
|
|
38
|
+
- [ ] Criterion 3
|
|
39
|
+
Expected Output: Description of expected result
|
|
40
|
+
```
|
|
41
|
+
|
|
42
|
+
### Regression Evals
|
|
43
|
+
Ensure changes don't break existing functionality:
|
|
44
|
+
```markdown
|
|
45
|
+
[REGRESSION EVAL: feature-name]
|
|
46
|
+
Baseline: SHA or checkpoint name
|
|
47
|
+
Tests:
|
|
48
|
+
- existing-test-1: PASS/FAIL
|
|
49
|
+
- existing-test-2: PASS/FAIL
|
|
50
|
+
- existing-test-3: PASS/FAIL
|
|
51
|
+
Result: X/Y passed (previously Y/Y)
|
|
52
|
+
```
|
|
53
|
+
|
|
54
|
+
## Grader Types
|
|
55
|
+
|
|
56
|
+
### 1. Code-Based Grader
|
|
57
|
+
Deterministic checks using code:
|
|
58
|
+
```bash
|
|
59
|
+
# Check if file contains expected pattern
|
|
60
|
+
grep -q "export function handleAuth" src/auth.ts && echo "PASS" || echo "FAIL"
|
|
61
|
+
|
|
62
|
+
# Check if tests pass
|
|
63
|
+
npm test -- --testPathPattern="auth" && echo "PASS" || echo "FAIL"
|
|
64
|
+
|
|
65
|
+
# Check if build succeeds
|
|
66
|
+
npm run build && echo "PASS" || echo "FAIL"
|
|
67
|
+
```
|
|
68
|
+
|
|
69
|
+
### 2. Model-Based Grader
|
|
70
|
+
Use Claude to evaluate open-ended outputs:
|
|
71
|
+
```markdown
|
|
72
|
+
[MODEL GRADER PROMPT]
|
|
73
|
+
Evaluate the following code change:
|
|
74
|
+
1. Does it solve the stated problem?
|
|
75
|
+
2. Is it well-structured?
|
|
76
|
+
3. Are edge cases handled?
|
|
77
|
+
4. Is error handling appropriate?
|
|
78
|
+
|
|
79
|
+
Score: 1-5 (1=poor, 5=excellent)
|
|
80
|
+
Reasoning: [explanation]
|
|
81
|
+
```
|
|
82
|
+
|
|
83
|
+
### 3. Human Grader
|
|
84
|
+
Flag for manual review:
|
|
85
|
+
```markdown
|
|
86
|
+
[HUMAN REVIEW REQUIRED]
|
|
87
|
+
Change: Description of what changed
|
|
88
|
+
Reason: Why human review is needed
|
|
89
|
+
Risk Level: LOW/MEDIUM/HIGH
|
|
90
|
+
```
|
|
91
|
+
|
|
92
|
+
## Metrics
|
|
93
|
+
|
|
94
|
+
### pass@k
|
|
95
|
+
"At least one success in k attempts"
|
|
96
|
+
- pass@1: First attempt success rate
|
|
97
|
+
- pass@3: Success within 3 attempts
|
|
98
|
+
- Typical target: pass@3 > 90%
|
|
99
|
+
|
|
100
|
+
### pass^k
|
|
101
|
+
"All k trials succeed"
|
|
102
|
+
- Higher bar for reliability
|
|
103
|
+
- pass^3: 3 consecutive successes
|
|
104
|
+
- Use for critical paths
|
|
105
|
+
|
|
106
|
+
## Eval Workflow
|
|
107
|
+
|
|
108
|
+
### 1. Define (Before Coding)
|
|
109
|
+
```markdown
|
|
110
|
+
## EVAL DEFINITION: feature-xyz
|
|
111
|
+
|
|
112
|
+
### Capability Evals
|
|
113
|
+
1. Can create new user account
|
|
114
|
+
2. Can validate email format
|
|
115
|
+
3. Can hash password securely
|
|
116
|
+
|
|
117
|
+
### Regression Evals
|
|
118
|
+
1. Existing login still works
|
|
119
|
+
2. Session management unchanged
|
|
120
|
+
3. Logout flow intact
|
|
121
|
+
|
|
122
|
+
### Success Metrics
|
|
123
|
+
- pass@3 > 90% for capability evals
|
|
124
|
+
- pass^3 = 100% for regression evals
|
|
125
|
+
```
|
|
126
|
+
|
|
127
|
+
### 2. Implement
|
|
128
|
+
Write code to pass the defined evals.
|
|
129
|
+
|
|
130
|
+
### 3. Evaluate
|
|
131
|
+
```bash
|
|
132
|
+
# Run capability evals
|
|
133
|
+
[Run each capability eval, record PASS/FAIL]
|
|
134
|
+
|
|
135
|
+
# Run regression evals
|
|
136
|
+
npm test -- --testPathPattern="existing"
|
|
137
|
+
|
|
138
|
+
# Generate report
|
|
139
|
+
```
|
|
140
|
+
|
|
141
|
+
### 4. Report
|
|
142
|
+
```markdown
|
|
143
|
+
EVAL REPORT: feature-xyz
|
|
144
|
+
========================
|
|
145
|
+
|
|
146
|
+
Capability Evals:
|
|
147
|
+
create-user: PASS (pass@1)
|
|
148
|
+
validate-email: PASS (pass@2)
|
|
149
|
+
hash-password: PASS (pass@1)
|
|
150
|
+
Overall: 3/3 passed
|
|
151
|
+
|
|
152
|
+
Regression Evals:
|
|
153
|
+
login-flow: PASS
|
|
154
|
+
session-mgmt: PASS
|
|
155
|
+
logout-flow: PASS
|
|
156
|
+
Overall: 3/3 passed
|
|
157
|
+
|
|
158
|
+
Metrics:
|
|
159
|
+
pass@1: 67% (2/3)
|
|
160
|
+
pass@3: 100% (3/3)
|
|
161
|
+
|
|
162
|
+
Status: READY FOR REVIEW
|
|
163
|
+
```
|
|
164
|
+
|
|
165
|
+
## Integration Patterns
|
|
166
|
+
|
|
167
|
+
### Pre-Implementation
|
|
168
|
+
```
|
|
169
|
+
/eval define feature-name
|
|
170
|
+
```
|
|
171
|
+
Creates eval definition file at `.claude/evals/feature-name.md`
|
|
172
|
+
|
|
173
|
+
### During Implementation
|
|
174
|
+
```
|
|
175
|
+
/eval check feature-name
|
|
176
|
+
```
|
|
177
|
+
Runs current evals and reports status
|
|
178
|
+
|
|
179
|
+
### Post-Implementation
|
|
180
|
+
```
|
|
181
|
+
/eval report feature-name
|
|
182
|
+
```
|
|
183
|
+
Generates full eval report
|
|
184
|
+
|
|
185
|
+
## Eval Storage
|
|
186
|
+
|
|
187
|
+
Store evals in project:
|
|
188
|
+
```
|
|
189
|
+
.claude/
|
|
190
|
+
evals/
|
|
191
|
+
feature-xyz.md # Eval definition
|
|
192
|
+
feature-xyz.log # Eval run history
|
|
193
|
+
baseline.json # Regression baselines
|
|
194
|
+
```
|
|
195
|
+
|
|
196
|
+
## Best Practices
|
|
197
|
+
|
|
198
|
+
1. **Define evals BEFORE coding** - Forces clear thinking about success criteria
|
|
199
|
+
2. **Run evals frequently** - Catch regressions early
|
|
200
|
+
3. **Track pass@k over time** - Monitor reliability trends
|
|
201
|
+
4. **Use code graders when possible** - Deterministic > probabilistic
|
|
202
|
+
5. **Human review for security** - Never fully automate security checks
|
|
203
|
+
6. **Keep evals fast** - Slow evals don't get run
|
|
204
|
+
7. **Version evals with code** - Evals are first-class artifacts
|
|
205
|
+
|
|
206
|
+
## Example: Adding Authentication
|
|
207
|
+
|
|
208
|
+
```markdown
|
|
209
|
+
## EVAL: add-authentication
|
|
210
|
+
|
|
211
|
+
### Phase 1: Define (10 min)
|
|
212
|
+
Capability Evals:
|
|
213
|
+
- [ ] User can register with email/password
|
|
214
|
+
- [ ] User can login with valid credentials
|
|
215
|
+
- [ ] Invalid credentials rejected with proper error
|
|
216
|
+
- [ ] Sessions persist across page reloads
|
|
217
|
+
- [ ] Logout clears session
|
|
218
|
+
|
|
219
|
+
Regression Evals:
|
|
220
|
+
- [ ] Public routes still accessible
|
|
221
|
+
- [ ] API responses unchanged
|
|
222
|
+
- [ ] Database schema compatible
|
|
223
|
+
|
|
224
|
+
### Phase 2: Implement (varies)
|
|
225
|
+
[Write code]
|
|
226
|
+
|
|
227
|
+
### Phase 3: Evaluate
|
|
228
|
+
Run: /eval check add-authentication
|
|
229
|
+
|
|
230
|
+
### Phase 4: Report
|
|
231
|
+
EVAL REPORT: add-authentication
|
|
232
|
+
==============================
|
|
233
|
+
Capability: 5/5 passed (pass@3: 100%)
|
|
234
|
+
Regression: 3/3 passed (pass^3: 100%)
|
|
235
|
+
Status: SHIP IT
|
|
236
|
+
```
|
|
237
|
+
|
|
238
|
+
## Product Evals (v1.8)
|
|
239
|
+
|
|
240
|
+
Use product evals when behavior quality cannot be captured by unit tests alone.
|
|
241
|
+
|
|
242
|
+
### Grader Types
|
|
243
|
+
|
|
244
|
+
1. Code grader (deterministic assertions)
|
|
245
|
+
2. Rule grader (regex/schema constraints)
|
|
246
|
+
3. Model grader (LLM-as-judge rubric)
|
|
247
|
+
4. Human grader (manual adjudication for ambiguous outputs)
|
|
248
|
+
|
|
249
|
+
### pass@k Guidance
|
|
250
|
+
|
|
251
|
+
- `pass@1`: direct reliability
|
|
252
|
+
- `pass@3`: practical reliability under controlled retries
|
|
253
|
+
- `pass^3`: stability test (all 3 runs must pass)
|
|
254
|
+
|
|
255
|
+
Recommended thresholds:
|
|
256
|
+
- Capability evals: pass@3 >= 0.90
|
|
257
|
+
- Regression evals: pass^3 = 1.00 for release-critical paths
|
|
258
|
+
|
|
259
|
+
### Eval Anti-Patterns
|
|
260
|
+
|
|
261
|
+
- Overfitting prompts to known eval examples
|
|
262
|
+
- Measuring only happy-path outputs
|
|
263
|
+
- Ignoring cost and latency drift while chasing pass rates
|
|
264
|
+
- Allowing flaky graders in release gates
|
|
265
|
+
|
|
266
|
+
### Minimal Eval Artifact Layout
|
|
267
|
+
|
|
268
|
+
- `.claude/evals/<feature>.md` definition
|
|
269
|
+
- `.claude/evals/<feature>.log` run history
|
|
270
|
+
- `docs/releases/<version>/eval-summary.md` release snapshot
|
|
271
|
+
|
|
@@ -0,0 +1,43 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: frontend-design
|
|
3
|
+
description: Create distinctive, production-grade frontend interfaces with high design quality. Use this skill when the user asks to build web components, pages, artifacts, posters, or applications (examples include websites, landing pages, dashboards, React components, HTML/CSS layouts, or when styling/beautifying any web UI). Generates creative, polished code and UI design that avoids generic AI aesthetics.
|
|
4
|
+
license: Complete terms in LICENSE.txt
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
This skill guides creation of distinctive, production-grade frontend interfaces that avoid generic "AI slop" aesthetics. Implement real working code with exceptional attention to aesthetic details and creative choices.
|
|
8
|
+
|
|
9
|
+
The user provides frontend requirements: a component, page, application, or interface to build. They may include context about the purpose, audience, or technical constraints.
|
|
10
|
+
|
|
11
|
+
## Design Thinking
|
|
12
|
+
|
|
13
|
+
Before coding, understand the context and commit to a BOLD aesthetic direction:
|
|
14
|
+
- **Purpose**: What problem does this interface solve? Who uses it?
|
|
15
|
+
- **Tone**: Pick an extreme: brutally minimal, maximalist chaos, retro-futuristic, organic/natural, luxury/refined, playful/toy-like, editorial/magazine, brutalist/raw, art deco/geometric, soft/pastel, industrial/utilitarian, etc. There are so many flavors to choose from. Use these for inspiration but design one that is true to the aesthetic direction.
|
|
16
|
+
- **Constraints**: Technical requirements (framework, performance, accessibility).
|
|
17
|
+
- **Differentiation**: What makes this UNFORGETTABLE? What's the one thing someone will remember?
|
|
18
|
+
|
|
19
|
+
**CRITICAL**: Choose a clear conceptual direction and execute it with precision. Bold maximalism and refined minimalism both work - the key is intentionality, not intensity.
|
|
20
|
+
|
|
21
|
+
Then implement working code (HTML/CSS/JS, React, Vue, etc.) that is:
|
|
22
|
+
- Production-grade and functional
|
|
23
|
+
- Visually striking and memorable
|
|
24
|
+
- Cohesive with a clear aesthetic point-of-view
|
|
25
|
+
- Meticulously refined in every detail
|
|
26
|
+
|
|
27
|
+
## Frontend Aesthetics Guidelines
|
|
28
|
+
|
|
29
|
+
Focus on:
|
|
30
|
+
- **Typography**: Choose fonts that are beautiful, unique, and interesting. Avoid generic fonts like Arial and Inter; opt instead for distinctive choices that elevate the frontend's aesthetics; unexpected, characterful font choices. Pair a distinctive display font with a refined body font.
|
|
31
|
+
- **Color & Theme**: Commit to a cohesive aesthetic. Use CSS variables for consistency. Dominant colors with sharp accents outperform timid, evenly-distributed palettes.
|
|
32
|
+
- **Motion**: Use animations for effects and micro-interactions. Prioritize CSS-only solutions for HTML. Use Motion library for React when available. Focus on high-impact moments: one well-orchestrated page load with staggered reveals (animation-delay) creates more delight than scattered micro-interactions. Use scroll-triggering and hover states that surprise.
|
|
33
|
+
- **Spatial Composition**: Unexpected layouts. Asymmetry. Overlap. Diagonal flow. Grid-breaking elements. Generous negative space OR controlled density.
|
|
34
|
+
- **Backgrounds & Visual Details**: Create atmosphere and depth rather than defaulting to solid colors. Add contextual effects and textures that match the overall aesthetic. Apply creative forms like gradient meshes, noise textures, geometric patterns, layered transparencies, dramatic shadows, decorative borders, custom cursors, and grain overlays.
|
|
35
|
+
|
|
36
|
+
NEVER use generic AI-generated aesthetics like overused font families (Inter, Roboto, Arial, system fonts), cliched color schemes (particularly purple gradients on white backgrounds), predictable layouts and component patterns, and cookie-cutter design that lacks context-specific character.
|
|
37
|
+
|
|
38
|
+
Interpret creatively and make unexpected choices that feel genuinely designed for the context. No design should be the same. Vary between light and dark themes, different fonts, different aesthetics. NEVER converge on common choices (Space Grotesk, for example) across generations.
|
|
39
|
+
|
|
40
|
+
**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.
|
|
41
|
+
|
|
42
|
+
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.
|
|
43
|
+
|