@sylphx/flow 3.4.0 → 3.6.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/CHANGELOG.md
CHANGED
|
@@ -1,5 +1,21 @@
|
|
|
1
1
|
# @sylphx/flow
|
|
2
2
|
|
|
3
|
+
## 3.6.0 (2026-01-28)
|
|
4
|
+
|
|
5
|
+
### ✨ Features
|
|
6
|
+
|
|
7
|
+
- add /sweep command for propagating improvements ([ba58697](https://github.com/SylphxAI/flow/commit/ba58697eddabb4b851f7d46bf56cb83930d9a3c5))
|
|
8
|
+
|
|
9
|
+
## 3.5.0 (2026-01-28)
|
|
10
|
+
|
|
11
|
+
### ✨ Features
|
|
12
|
+
|
|
13
|
+
- add /excellence command, rename /review to /challenge ([533c0d0](https://github.com/SylphxAI/flow/commit/533c0d016380d7b37680633d6773792030b07753))
|
|
14
|
+
|
|
15
|
+
### ♻️ Refactoring
|
|
16
|
+
|
|
17
|
+
- rename /review to /challenge ([ec3d9b5](https://github.com/SylphxAI/flow/commit/ec3d9b5510dc76337e64711aea614b00c2ba8de9))
|
|
18
|
+
|
|
3
19
|
## 3.4.0 (2026-01-26)
|
|
4
20
|
|
|
5
21
|
### ✨ Features
|
|
@@ -0,0 +1,101 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: excellence
|
|
3
|
+
description: Is this project truly State of the Art?
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Excellence: Is This State of the Art?
|
|
7
|
+
|
|
8
|
+
You are a world-class expert and harsh critic. Evaluate whether this project is truly excellent — not just functional, not just "good enough", but **state of the art**.
|
|
9
|
+
|
|
10
|
+
## Mindset
|
|
11
|
+
|
|
12
|
+
Don't use checklist thinking. Ask yourself:
|
|
13
|
+
|
|
14
|
+
> "If I showed this project to the top experts in the industry, what would their reaction be?"
|
|
15
|
+
|
|
16
|
+
- Would they be **impressed**?
|
|
17
|
+
- Would they find it **mediocre**?
|
|
18
|
+
- Would they spot **obvious gaps**?
|
|
19
|
+
|
|
20
|
+
Based on this specific project's nature, determine what "excellence" means here.
|
|
21
|
+
|
|
22
|
+
## Evaluation Dimensions
|
|
23
|
+
|
|
24
|
+
### Architecture
|
|
25
|
+
- Is the architecture cutting-edge or outdated?
|
|
26
|
+
- Would system design experts approve?
|
|
27
|
+
- Is it scalable, maintainable, elegant?
|
|
28
|
+
- Are the abstractions right — not too much, not too little?
|
|
29
|
+
|
|
30
|
+
### Code Quality
|
|
31
|
+
- Could this code be used as teaching material?
|
|
32
|
+
- Is it exemplary or just acceptable?
|
|
33
|
+
- Would senior engineers at top companies approve?
|
|
34
|
+
- Is it clean, readable, well-structured?
|
|
35
|
+
|
|
36
|
+
### Business Logic & Design
|
|
37
|
+
- Does the business flow make sense?
|
|
38
|
+
- Are there logical gaps or inconsistencies?
|
|
39
|
+
- Is the product design sound?
|
|
40
|
+
- Would domain experts find issues?
|
|
41
|
+
|
|
42
|
+
### User Experience
|
|
43
|
+
- Is the UX **delightful** or just **functional**?
|
|
44
|
+
- Would users choose this over competitors?
|
|
45
|
+
- Is it intuitive, fast, polished?
|
|
46
|
+
- Are edge cases handled gracefully?
|
|
47
|
+
|
|
48
|
+
### Performance
|
|
49
|
+
- Is it best-in-class or just acceptable?
|
|
50
|
+
- Are there obvious bottlenecks?
|
|
51
|
+
- Would performance engineers approve?
|
|
52
|
+
|
|
53
|
+
### Public-Facing (Docs, README, Marketing)
|
|
54
|
+
- Is the messaging compelling?
|
|
55
|
+
- Would it attract users/contributors?
|
|
56
|
+
- Is documentation clear and complete?
|
|
57
|
+
- Does it convey professionalism and quality?
|
|
58
|
+
|
|
59
|
+
## Process
|
|
60
|
+
|
|
61
|
+
1. **Explore** the project deeply — architecture, code, UI, docs
|
|
62
|
+
2. **Evaluate** each dimension with fresh, critical eyes
|
|
63
|
+
3. **Compare** mentally to best-in-class examples
|
|
64
|
+
4. **Judge** honestly — would you stake your reputation on this?
|
|
65
|
+
5. **Report** findings with specific observations
|
|
66
|
+
|
|
67
|
+
## Output
|
|
68
|
+
|
|
69
|
+
### Overall Verdict
|
|
70
|
+
```
|
|
71
|
+
[ ] World-Class — Experts would be impressed
|
|
72
|
+
[ ] Strong — Good, but room for improvement
|
|
73
|
+
[ ] Acceptable — Works, but not exceptional
|
|
74
|
+
[ ] Needs Work — Obvious gaps exist
|
|
75
|
+
```
|
|
76
|
+
|
|
77
|
+
### Dimension Scores
|
|
78
|
+
| Dimension | Rating | Key Observations |
|
|
79
|
+
|-----------|--------|------------------|
|
|
80
|
+
| Architecture | ⭐⭐⭐⭐⭐ | ... |
|
|
81
|
+
| Code Quality | ⭐⭐⭐⭐☆ | ... |
|
|
82
|
+
| Business Logic | ⭐⭐⭐☆☆ | ... |
|
|
83
|
+
| UX | ⭐⭐⭐⭐☆ | ... |
|
|
84
|
+
| Performance | ⭐⭐⭐⭐⭐ | ... |
|
|
85
|
+
| Public-Facing | ⭐⭐⭐☆☆ | ... |
|
|
86
|
+
|
|
87
|
+
### What's Excellent
|
|
88
|
+
- ...
|
|
89
|
+
|
|
90
|
+
### What's Holding It Back
|
|
91
|
+
- ...
|
|
92
|
+
|
|
93
|
+
### To Reach World-Class
|
|
94
|
+
- ...
|
|
95
|
+
|
|
96
|
+
## Remember
|
|
97
|
+
|
|
98
|
+
- Excellence is contextual — judge based on what this project aims to be
|
|
99
|
+
- Be specific — vague praise or criticism is useless
|
|
100
|
+
- Be honest — if it's mediocre, say so
|
|
101
|
+
- Think holistically — a project with great code but terrible UX is not excellent
|
|
@@ -0,0 +1,116 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: sweep
|
|
3
|
+
description: Find and fix all similar patterns across the project
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Sweep: Propagate Excellence Across the Codebase
|
|
7
|
+
|
|
8
|
+
You just did something — fixed a bug, improved code, optimized something, or established a pattern.
|
|
9
|
+
|
|
10
|
+
Now **sweep** through the entire project and apply the same improvement everywhere it's relevant.
|
|
11
|
+
|
|
12
|
+
## Mindset
|
|
13
|
+
|
|
14
|
+
> "If I fixed this here, where else does the same issue exist?"
|
|
15
|
+
> "If I improved this pattern, where else should it be applied?"
|
|
16
|
+
> "Don't just fix the symptom — eliminate the entire class of problems."
|
|
17
|
+
|
|
18
|
+
**Proactive, not reactive.** One fix should trigger a comprehensive sweep.
|
|
19
|
+
|
|
20
|
+
## Process
|
|
21
|
+
|
|
22
|
+
### 1. Identify What Was Just Done
|
|
23
|
+
- What did you fix, improve, or create?
|
|
24
|
+
- What pattern or principle does it represent?
|
|
25
|
+
- What was wrong with the old approach?
|
|
26
|
+
|
|
27
|
+
### 2. Define the Search Pattern
|
|
28
|
+
- What does "similar" look like?
|
|
29
|
+
- What code patterns indicate the same issue?
|
|
30
|
+
- What files/modules are likely affected?
|
|
31
|
+
|
|
32
|
+
### 3. Sweep the Codebase
|
|
33
|
+
Search systematically:
|
|
34
|
+
```
|
|
35
|
+
- Same file type (*.tsx, *.ts, etc.)
|
|
36
|
+
- Same directory/module
|
|
37
|
+
- Same pattern (hooks, components, utils, etc.)
|
|
38
|
+
- Same anti-pattern being fixed
|
|
39
|
+
```
|
|
40
|
+
|
|
41
|
+
### 4. Apply the Improvement Everywhere
|
|
42
|
+
For each similar case found:
|
|
43
|
+
- Apply the same fix/improvement
|
|
44
|
+
- Ensure consistency with the original
|
|
45
|
+
- Adapt as needed for context
|
|
46
|
+
|
|
47
|
+
### 5. Verify Completeness
|
|
48
|
+
- Did you catch everything?
|
|
49
|
+
- Run one more search to confirm
|
|
50
|
+
- No stragglers left behind
|
|
51
|
+
|
|
52
|
+
## Examples
|
|
53
|
+
|
|
54
|
+
### Bug Fix Sweep
|
|
55
|
+
```
|
|
56
|
+
Fixed: Null check missing in UserProfile
|
|
57
|
+
Sweep: Find all components accessing user data without null checks
|
|
58
|
+
Result: Fixed 12 similar issues across 8 files
|
|
59
|
+
```
|
|
60
|
+
|
|
61
|
+
### Pattern Improvement Sweep
|
|
62
|
+
```
|
|
63
|
+
Improved: Converted callback to async/await in fetchData
|
|
64
|
+
Sweep: Find all callback-style async code
|
|
65
|
+
Result: Modernized 23 functions to async/await
|
|
66
|
+
```
|
|
67
|
+
|
|
68
|
+
### Type Safety Sweep
|
|
69
|
+
```
|
|
70
|
+
Fixed: Added proper TypeScript types to API response
|
|
71
|
+
Sweep: Find all `any` types in API layer
|
|
72
|
+
Result: Added proper types to 15 API functions
|
|
73
|
+
```
|
|
74
|
+
|
|
75
|
+
### Component Pattern Sweep
|
|
76
|
+
```
|
|
77
|
+
Created: Reusable ErrorBoundary with retry
|
|
78
|
+
Sweep: Find all try-catch error handling in components
|
|
79
|
+
Result: Replaced 8 ad-hoc error handlers with ErrorBoundary
|
|
80
|
+
```
|
|
81
|
+
|
|
82
|
+
### Performance Optimization Sweep
|
|
83
|
+
```
|
|
84
|
+
Optimized: Added useMemo to expensive calculation
|
|
85
|
+
Sweep: Find all expensive calculations in render
|
|
86
|
+
Result: Memoized 6 similar calculations
|
|
87
|
+
```
|
|
88
|
+
|
|
89
|
+
## Output
|
|
90
|
+
|
|
91
|
+
### Sweep Summary
|
|
92
|
+
```
|
|
93
|
+
Original Work: [what was done]
|
|
94
|
+
Pattern Identified: [what to look for]
|
|
95
|
+
Files Scanned: [count]
|
|
96
|
+
Similar Cases Found: [count]
|
|
97
|
+
Cases Fixed: [count]
|
|
98
|
+
```
|
|
99
|
+
|
|
100
|
+
### Changes Made
|
|
101
|
+
| File | Change | Status |
|
|
102
|
+
|------|--------|--------|
|
|
103
|
+
| ... | ... | ✅ Fixed |
|
|
104
|
+
|
|
105
|
+
### Verification
|
|
106
|
+
- [ ] All similar patterns addressed
|
|
107
|
+
- [ ] No regressions introduced
|
|
108
|
+
- [ ] Consistency maintained
|
|
109
|
+
|
|
110
|
+
## Remember
|
|
111
|
+
|
|
112
|
+
* **One fix = comprehensive sweep** — never leave similar issues behind
|
|
113
|
+
* **Think in patterns** — what class of problem did you just solve?
|
|
114
|
+
* **Be thorough** — check everywhere, including tests and docs
|
|
115
|
+
* **Maintain consistency** — all similar code should look similar
|
|
116
|
+
* **This is how you reach State of the Art** — excellence everywhere, not just in spots
|
package/package.json
CHANGED