claude-orchestration 1.0.0 → 1.0.2
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 +5 -1
- package/bin/cli.js +18 -13
- package/package.json +1 -1
- package/templates/claude/orchestration.md +40 -1
- package/templates/claude/workflows/react/bugfix.md +20 -22
- package/templates/claude/workflows/react/docs.md +26 -170
- package/templates/claude/workflows/react/feature.md +36 -77
- package/templates/claude/workflows/react/performance.md +59 -0
- package/templates/claude/workflows/react/pr.md +11 -9
- package/templates/claude/workflows/react/refactor.md +19 -28
- package/templates/claude/workflows/react/review.md +54 -0
package/README.md
CHANGED
|
@@ -18,6 +18,8 @@ This will create a `.claude/` directory with workflow templates:
|
|
|
18
18
|
feature.md
|
|
19
19
|
bugfix.md
|
|
20
20
|
refactor.md
|
|
21
|
+
performance.md
|
|
22
|
+
review.md
|
|
21
23
|
pr.md
|
|
22
24
|
docs.md
|
|
23
25
|
```
|
|
@@ -34,7 +36,9 @@ This will create a `.claude/` directory with workflow templates:
|
|
|
34
36
|
| `feature.md` | Building new functionality |
|
|
35
37
|
| `bugfix.md` | Diagnosing and fixing bugs |
|
|
36
38
|
| `refactor.md` | Improving code without behavior changes |
|
|
37
|
-
| `
|
|
39
|
+
| `performance.md` | Profiling and optimizing performance |
|
|
40
|
+
| `review.md` | Reviewing code for merge |
|
|
41
|
+
| `pr.md` | Generating PR title and description |
|
|
38
42
|
| `docs.md` | Writing documentation |
|
|
39
43
|
|
|
40
44
|
The tool auto-detects React projects and routes to React-specific workflows with React 18 best practices.
|
package/bin/cli.js
CHANGED
|
@@ -37,7 +37,6 @@ if (process.argv.includes("--version") || process.argv.includes("-v")) {
|
|
|
37
37
|
|
|
38
38
|
const SOURCE_DIR = path.join(__dirname, "..", "templates", "claude");
|
|
39
39
|
const DEST_NAME = ".claude";
|
|
40
|
-
const CLAUDE_MD = "CLAUDE.md";
|
|
41
40
|
|
|
42
41
|
const ORCHESTRATION_INSTRUCTION = `
|
|
43
42
|
|
|
@@ -46,28 +45,34 @@ const ORCHESTRATION_INSTRUCTION = `
|
|
|
46
45
|
For complex tasks, refer to .claude/orchestration.md for available workflows.
|
|
47
46
|
`;
|
|
48
47
|
|
|
49
|
-
async function
|
|
50
|
-
|
|
51
|
-
|
|
52
|
-
|
|
53
|
-
|
|
54
|
-
return false;
|
|
55
|
-
}
|
|
48
|
+
async function findClaudeMdFiles(projectDir) {
|
|
49
|
+
const entries = await fs.readdir(projectDir, { withFileTypes: true });
|
|
50
|
+
return entries
|
|
51
|
+
.filter((entry) => entry.isFile() && entry.name.toLowerCase() === "claude.md")
|
|
52
|
+
.map((entry) => entry.name);
|
|
56
53
|
}
|
|
57
54
|
|
|
58
55
|
async function updateClaudeMd(projectDir) {
|
|
59
|
-
const
|
|
56
|
+
const claudeMdFiles = await findClaudeMdFiles(projectDir);
|
|
57
|
+
|
|
58
|
+
if (claudeMdFiles.length === 0) {
|
|
59
|
+
const newFilePath = path.join(projectDir, "CLAUDE.md");
|
|
60
|
+
await fs.writeFile(newFilePath, `# CLAUDE.md${ORCHESTRATION_INSTRUCTION}`);
|
|
61
|
+
console.log(" Created: CLAUDE.md");
|
|
62
|
+
return;
|
|
63
|
+
}
|
|
60
64
|
|
|
61
|
-
|
|
65
|
+
for (const fileName of claudeMdFiles) {
|
|
66
|
+
const claudeMdPath = path.join(projectDir, fileName);
|
|
62
67
|
const content = await fs.readFile(claudeMdPath, "utf-8");
|
|
63
68
|
|
|
64
69
|
if (content.includes(".claude/orchestration.md")) {
|
|
65
|
-
console.log(` Skipped: ${
|
|
66
|
-
|
|
70
|
+
console.log(` Skipped: ${fileName} already references orchestration.md`);
|
|
71
|
+
continue;
|
|
67
72
|
}
|
|
68
73
|
|
|
69
74
|
await fs.appendFile(claudeMdPath, ORCHESTRATION_INSTRUCTION);
|
|
70
|
-
console.log(` Updated: ${
|
|
75
|
+
console.log(` Updated: ${fileName}`);
|
|
71
76
|
}
|
|
72
77
|
}
|
|
73
78
|
|
package/package.json
CHANGED
|
@@ -21,7 +21,9 @@ If React indicators are present → use `workflows/react/` directory
|
|
|
21
21
|
| `feature.md` | Building new functionality |
|
|
22
22
|
| `bugfix.md` | Diagnosing and fixing bugs |
|
|
23
23
|
| `refactor.md` | Improving code without behavior changes |
|
|
24
|
-
| `
|
|
24
|
+
| `performance.md` | Profiling and optimizing performance |
|
|
25
|
+
| `review.md` | Reviewing code for merge |
|
|
26
|
+
| `pr.md` | Generating PR title and description |
|
|
25
27
|
| `docs.md` | Writing or updating documentation |
|
|
26
28
|
|
|
27
29
|
**Workflow Path:**
|
|
@@ -34,3 +36,40 @@ If React indicators are present → use `workflows/react/` directory
|
|
|
34
36
|
- Skip workflows for trivial tasks (typos, simple renames, one-line fixes)
|
|
35
37
|
- Workflows are process guidance, not rigid scripts
|
|
36
38
|
- Read the workflow file before starting, adapt steps as needed
|
|
39
|
+
|
|
40
|
+
---
|
|
41
|
+
|
|
42
|
+
## React Architecture Rules
|
|
43
|
+
|
|
44
|
+
All React workflows MUST follow these rules. Violations block merge.
|
|
45
|
+
|
|
46
|
+
### Structure
|
|
47
|
+
- **Feature-based**: Organize by feature, not by type
|
|
48
|
+
- **No barrels**: NEVER use `index.ts` to re-export from a folder
|
|
49
|
+
- **Entry naming**: Main file MUST match folder name (`Button/Button.tsx`, not `Button/index.tsx`)
|
|
50
|
+
- **Colocation**: Keep related files together (component, hooks, types, tests, styles)
|
|
51
|
+
|
|
52
|
+
### File Structure
|
|
53
|
+
```
|
|
54
|
+
features/
|
|
55
|
+
auth/
|
|
56
|
+
auth.tsx # Entry point (matches folder name)
|
|
57
|
+
auth.hooks.ts # Feature-specific hooks
|
|
58
|
+
auth.types.ts # Feature-specific types
|
|
59
|
+
auth.test.tsx # Feature tests
|
|
60
|
+
components/
|
|
61
|
+
LoginForm/
|
|
62
|
+
LoginForm.tsx # Component entry (matches folder name)
|
|
63
|
+
LoginForm.test.tsx
|
|
64
|
+
```
|
|
65
|
+
|
|
66
|
+
### Import Convention
|
|
67
|
+
```tsx
|
|
68
|
+
// CORRECT: Direct imports
|
|
69
|
+
import { LoginForm } from '@/features/auth/components/LoginForm/LoginForm'
|
|
70
|
+
import { useAuth } from '@/features/auth/auth.hooks'
|
|
71
|
+
|
|
72
|
+
// WRONG: Barrel imports - NEVER do this
|
|
73
|
+
import { LoginForm } from '@/features/auth/components'
|
|
74
|
+
import { useAuth } from '@/features/auth'
|
|
75
|
+
```
|
|
@@ -1,38 +1,35 @@
|
|
|
1
1
|
# React Bugfix Workflow
|
|
2
2
|
|
|
3
|
-
|
|
3
|
+
> Architecture rules: See orchestration.md. Violations block merge.
|
|
4
4
|
|
|
5
|
-
|
|
6
|
-
- **No barrel exports**: Never use `index.ts` to re-export
|
|
7
|
-
- **Entry point naming**: File must match folder name (`Button/Button.tsx`)
|
|
5
|
+
## Before Coding
|
|
8
6
|
|
|
9
|
-
|
|
10
|
-
|
|
11
|
-
-
|
|
12
|
-
-
|
|
13
|
-
- [ ] Is this related to React 18 concurrent features?
|
|
7
|
+
MUST answer:
|
|
8
|
+
- Can I reproduce the bug?
|
|
9
|
+
- What is expected vs actual behavior?
|
|
10
|
+
- Is this related to React 18 concurrent features?
|
|
14
11
|
|
|
15
12
|
## Process
|
|
16
13
|
|
|
17
14
|
### 1. Reproduce and Isolate
|
|
18
15
|
- Confirm the bug exists
|
|
19
|
-
- Check if it only occurs in Strict Mode
|
|
20
|
-
- Find
|
|
16
|
+
- Check if it only occurs in Strict Mode
|
|
17
|
+
- Find minimal reproduction case
|
|
21
18
|
|
|
22
|
-
### 2. Locate
|
|
19
|
+
### 2. Locate Root Cause
|
|
23
20
|
|
|
24
21
|
**Common React 18 issues:**
|
|
25
|
-
- Effects
|
|
26
|
-
- Effects
|
|
22
|
+
- Effects missing cleanup functions
|
|
23
|
+
- Effects with stale closures
|
|
27
24
|
- Race conditions from concurrent rendering
|
|
28
25
|
- Automatic batching behavior changes
|
|
29
26
|
|
|
30
27
|
### 3. Fix
|
|
31
28
|
|
|
32
|
-
|
|
29
|
+
MUST keep changes within affected feature folder.
|
|
33
30
|
|
|
34
31
|
```tsx
|
|
35
|
-
//
|
|
32
|
+
// Example: Add cleanup for effects
|
|
36
33
|
useEffect(() => {
|
|
37
34
|
const controller = new AbortController()
|
|
38
35
|
fetchData(controller.signal)
|
|
@@ -41,12 +38,13 @@ useEffect(() => {
|
|
|
41
38
|
```
|
|
42
39
|
|
|
43
40
|
### 4. Verify
|
|
44
|
-
- Confirm
|
|
41
|
+
- Confirm bug is fixed
|
|
45
42
|
- Test with Strict Mode enabled
|
|
46
|
-
- Add
|
|
43
|
+
- Add test that would have caught this bug
|
|
47
44
|
|
|
48
|
-
##
|
|
45
|
+
## Constraints
|
|
49
46
|
|
|
50
|
-
- A bugfix is
|
|
51
|
-
- The best fix is
|
|
52
|
-
-
|
|
47
|
+
- A bugfix is NOT an opportunity to refactor
|
|
48
|
+
- The best fix is the smallest fix
|
|
49
|
+
- NEVER introduce barrel exports
|
|
50
|
+
- Note other issues separately—don't fix them here
|
|
@@ -1,203 +1,59 @@
|
|
|
1
1
|
# React Documentation Workflow
|
|
2
2
|
|
|
3
|
-
|
|
3
|
+
> Document architecture correctly. See orchestration.md for patterns.
|
|
4
4
|
|
|
5
|
-
|
|
6
|
-
- **Feature architecture**: Organize by feature, not by type
|
|
7
|
-
- **No barrel exports**: Never use `index.ts` to re-export from a folder
|
|
8
|
-
- **Entry point naming**: Main file must match folder name (`Button/Button.tsx`, not `Button/index.tsx`)
|
|
9
|
-
- **Colocation**: Keep related files together (component, hooks, types, tests, styles)
|
|
5
|
+
## Before Writing
|
|
10
6
|
|
|
11
|
-
|
|
12
|
-
|
|
13
|
-
-
|
|
14
|
-
-
|
|
15
|
-
- [ ] What existing docs need to stay in sync?
|
|
16
|
-
- [ ] Does this document React 18 patterns correctly?
|
|
7
|
+
MUST answer:
|
|
8
|
+
- Who is the audience?
|
|
9
|
+
- What should they be able to do after reading?
|
|
10
|
+
- What existing docs need to stay in sync?
|
|
17
11
|
|
|
18
12
|
## Process
|
|
19
13
|
|
|
20
14
|
### 1. Understand the Subject
|
|
21
|
-
- Read the code
|
|
15
|
+
- Read the code being documented
|
|
22
16
|
- Try it yourself if possible
|
|
23
|
-
-
|
|
24
|
-
- Identify any non-obvious behavior or gotchas
|
|
17
|
+
- Identify non-obvious behavior or gotchas
|
|
25
18
|
|
|
26
19
|
### 2. Check Existing Docs
|
|
27
20
|
- Find related documentation
|
|
28
21
|
- Identify what's missing or outdated
|
|
29
22
|
- Note the existing style and format
|
|
30
|
-
- Check for outdated React patterns (class components, lifecycle methods)
|
|
31
23
|
|
|
32
24
|
### 3. Write
|
|
33
25
|
|
|
34
|
-
|
|
35
|
-
```markdown
|
|
36
|
-
## File Structure
|
|
37
|
-
|
|
38
|
-
features/
|
|
39
|
-
auth/
|
|
40
|
-
auth.tsx # Main entry point
|
|
41
|
-
auth.hooks.ts # useAuth, useSession
|
|
42
|
-
auth.types.ts # AuthState, User
|
|
43
|
-
components/
|
|
44
|
-
LoginForm/
|
|
45
|
-
LoginForm.tsx # Login form component
|
|
46
|
-
```
|
|
47
|
-
|
|
48
|
-
**Document import conventions:**
|
|
49
|
-
```markdown
|
|
50
|
-
## Importing
|
|
51
|
-
|
|
52
|
-
Always use direct imports:
|
|
53
|
-
|
|
54
|
-
// Correct
|
|
55
|
-
import { LoginForm } from '@/features/auth/components/LoginForm/LoginForm'
|
|
56
|
-
import { useAuth } from '@/features/auth/auth.hooks'
|
|
57
|
-
|
|
58
|
-
// Incorrect - never use barrel imports
|
|
59
|
-
import { LoginForm } from '@/features/auth/components'
|
|
60
|
-
```
|
|
26
|
+
Adapt this template as needed:
|
|
61
27
|
|
|
62
|
-
**Document React 18 patterns:**
|
|
63
28
|
```markdown
|
|
64
|
-
|
|
29
|
+
# {Name}
|
|
65
30
|
|
|
66
|
-
|
|
67
|
-
For non-urgent state updates, use useTransition:
|
|
68
|
-
|
|
69
|
-
const [isPending, startTransition] = useTransition()
|
|
70
|
-
|
|
71
|
-
startTransition(() => {
|
|
72
|
-
setFilteredResults(results)
|
|
73
|
-
})
|
|
74
|
-
|
|
75
|
-
### Suspense for Loading States
|
|
76
|
-
Wrap async components with Suspense:
|
|
77
|
-
|
|
78
|
-
<Suspense fallback={<Skeleton />}>
|
|
79
|
-
<AsyncComponent />
|
|
80
|
-
</Suspense>
|
|
81
|
-
```
|
|
82
|
-
|
|
83
|
-
### 4. Validate
|
|
84
|
-
- Code examples actually work
|
|
85
|
-
- Import paths follow the direct import convention
|
|
86
|
-
- Examples use React 18 patterns (not deprecated ones)
|
|
87
|
-
- Links are valid
|
|
88
|
-
- Instructions produce expected results
|
|
89
|
-
- No references to removed features or old patterns
|
|
90
|
-
|
|
91
|
-
### 5. Review
|
|
92
|
-
- Read it from a newcomer's perspective
|
|
93
|
-
- Check for outdated React terminology
|
|
94
|
-
- Ensure logical flow
|
|
95
|
-
- Verify architecture rules are explained clearly
|
|
96
|
-
|
|
97
|
-
## Documentation Templates
|
|
98
|
-
|
|
99
|
-
### Component Documentation
|
|
100
|
-
```markdown
|
|
101
|
-
# ComponentName
|
|
102
|
-
|
|
103
|
-
Brief description of what the component does.
|
|
31
|
+
Brief description.
|
|
104
32
|
|
|
105
33
|
## Location
|
|
106
|
-
|
|
107
|
-
`features/{feature}/components/ComponentName/ComponentName.tsx`
|
|
34
|
+
`features/{feature}/components/{Name}/{Name}.tsx`
|
|
108
35
|
|
|
109
36
|
## Import
|
|
110
|
-
|
|
111
|
-
import { ComponentName } from '@/features/{feature}/components/ComponentName/ComponentName'
|
|
112
|
-
|
|
113
|
-
## Props
|
|
114
|
-
|
|
115
|
-
| Prop | Type | Required | Description |
|
|
116
|
-
|------|------|----------|-------------|
|
|
117
|
-
| ... | ... | ... | ... |
|
|
37
|
+
import { Name } from '@/features/{feature}/components/{Name}/{Name}'
|
|
118
38
|
|
|
119
39
|
## Usage
|
|
40
|
+
<Name prop="value" />
|
|
120
41
|
|
|
121
|
-
|
|
42
|
+
## Props/Parameters (if applicable)
|
|
43
|
+
| Name | Type | Required | Description |
|
|
44
|
+
|------|------|----------|-------------|
|
|
122
45
|
|
|
123
46
|
## Related
|
|
124
|
-
|
|
125
|
-
- [RelatedComponent](./RelatedComponent.md)
|
|
126
|
-
- [useRelatedHook](../hooks.md#userelatedhook)
|
|
47
|
+
- Links to related components/hooks
|
|
127
48
|
```
|
|
128
49
|
|
|
129
|
-
###
|
|
130
|
-
|
|
131
|
-
|
|
132
|
-
|
|
133
|
-
Brief description of what the hook does.
|
|
134
|
-
|
|
135
|
-
## Location
|
|
136
|
-
|
|
137
|
-
`features/{feature}/{feature}.hooks.ts`
|
|
138
|
-
|
|
139
|
-
## Import
|
|
140
|
-
|
|
141
|
-
import { useHookName } from '@/features/{feature}/{feature}.hooks'
|
|
142
|
-
|
|
143
|
-
## Parameters
|
|
144
|
-
|
|
145
|
-
| Parameter | Type | Required | Description |
|
|
146
|
-
|-----------|------|----------|-------------|
|
|
147
|
-
|
|
148
|
-
## Returns
|
|
149
|
-
|
|
150
|
-
| Property | Type | Description |
|
|
151
|
-
|----------|------|-------------|
|
|
152
|
-
|
|
153
|
-
## Usage
|
|
154
|
-
|
|
155
|
-
const { data, isLoading } = useHookName(param)
|
|
156
|
-
|
|
157
|
-
## React 18 Notes
|
|
158
|
-
|
|
159
|
-
Any specific React 18 considerations (Suspense, transitions, etc.)
|
|
160
|
-
```
|
|
161
|
-
|
|
162
|
-
### Feature Documentation
|
|
163
|
-
```markdown
|
|
164
|
-
# Feature Name
|
|
165
|
-
|
|
166
|
-
## Overview
|
|
167
|
-
|
|
168
|
-
What this feature does and why it exists.
|
|
169
|
-
|
|
170
|
-
## Architecture
|
|
171
|
-
|
|
172
|
-
features/
|
|
173
|
-
{feature}/
|
|
174
|
-
{feature}.tsx # Entry point
|
|
175
|
-
{feature}.hooks.ts # Hooks
|
|
176
|
-
{feature}.types.ts # Types
|
|
177
|
-
components/ # Feature components
|
|
178
|
-
|
|
179
|
-
## Key Components
|
|
180
|
-
|
|
181
|
-
- **ComponentA**: Description
|
|
182
|
-
- **ComponentB**: Description
|
|
183
|
-
|
|
184
|
-
## Hooks
|
|
185
|
-
|
|
186
|
-
- **useHookA**: Description
|
|
187
|
-
- **useHookB**: Description
|
|
188
|
-
|
|
189
|
-
## Usage
|
|
190
|
-
|
|
191
|
-
How to use this feature in the application.
|
|
192
|
-
```
|
|
50
|
+
### 4. Validate
|
|
51
|
+
- Code examples actually work
|
|
52
|
+
- Import paths are direct (not barrel)
|
|
53
|
+
- Links are valid
|
|
193
54
|
|
|
194
|
-
##
|
|
55
|
+
## Constraints
|
|
195
56
|
|
|
196
|
-
-
|
|
197
|
-
-
|
|
198
|
-
-
|
|
199
|
-
- Update related docs to stay consistent
|
|
200
|
-
- Remove documentation for removed features
|
|
201
|
-
- Match the tone and style of existing project docs
|
|
202
|
-
- Ensure all code examples use React 18 patterns
|
|
203
|
-
- Document any migration notes from older patterns
|
|
57
|
+
- MUST explain why, not just what
|
|
58
|
+
- MUST show direct import paths in examples
|
|
59
|
+
- MUST update related docs to stay consistent
|
|
@@ -1,99 +1,58 @@
|
|
|
1
1
|
# React Feature Workflow
|
|
2
2
|
|
|
3
|
-
|
|
3
|
+
> Architecture rules: See orchestration.md. Violations block merge.
|
|
4
4
|
|
|
5
|
-
|
|
6
|
-
- **Feature architecture**: Organize by feature, not by type
|
|
7
|
-
- **No barrel exports**: Never use `index.ts` to re-export from a folder
|
|
8
|
-
- **Entry point naming**: Main file must match folder name (`Button/Button.tsx`, not `Button/index.tsx`)
|
|
9
|
-
- **Colocation**: Keep related files together (component, hooks, types, tests, styles)
|
|
5
|
+
## Before Coding
|
|
10
6
|
|
|
11
|
-
|
|
12
|
-
|
|
13
|
-
|
|
14
|
-
|
|
15
|
-
|
|
16
|
-
auth.hooks.ts # Feature-specific hooks
|
|
17
|
-
auth.types.ts # Feature-specific types
|
|
18
|
-
auth.test.tsx # Feature tests
|
|
19
|
-
components/
|
|
20
|
-
LoginForm/
|
|
21
|
-
LoginForm.tsx # Component entry (matches folder name)
|
|
22
|
-
LoginForm.test.tsx
|
|
23
|
-
```
|
|
24
|
-
|
|
25
|
-
### Import Rules
|
|
26
|
-
```tsx
|
|
27
|
-
// CORRECT: Direct imports
|
|
28
|
-
import { LoginForm } from '@/features/auth/components/LoginForm/LoginForm'
|
|
29
|
-
import { useAuth } from '@/features/auth/auth.hooks'
|
|
30
|
-
|
|
31
|
-
// WRONG: Barrel imports
|
|
32
|
-
import { LoginForm } from '@/features/auth/components'
|
|
33
|
-
import { useAuth } from '@/features/auth'
|
|
34
|
-
```
|
|
35
|
-
|
|
36
|
-
## Before Starting
|
|
37
|
-
|
|
38
|
-
- [ ] What problem does this feature solve?
|
|
39
|
-
- [ ] What's the minimal viable version?
|
|
40
|
-
- [ ] Which feature folder does this belong in?
|
|
41
|
-
- [ ] Are there existing patterns in the codebase to follow?
|
|
7
|
+
MUST answer:
|
|
8
|
+
- What problem does this feature solve?
|
|
9
|
+
- What's the minimal viable version?
|
|
10
|
+
- Which feature folder does this belong in?
|
|
11
|
+
- Are there existing patterns to follow?
|
|
42
12
|
|
|
43
13
|
## Process
|
|
44
14
|
|
|
45
|
-
### 1. Understand
|
|
15
|
+
### 1. Understand Context
|
|
46
16
|
- Read related existing code
|
|
47
|
-
- Identify the feature folder
|
|
48
|
-
- Check for similar implementations
|
|
49
|
-
- Review
|
|
17
|
+
- Identify the target feature folder
|
|
18
|
+
- Check for similar implementations
|
|
19
|
+
- Review reusable hooks and utilities
|
|
50
20
|
|
|
51
|
-
### 2. Plan
|
|
52
|
-
- Break
|
|
53
|
-
- Plan
|
|
21
|
+
### 2. Plan Implementation
|
|
22
|
+
- Break into small, testable pieces
|
|
23
|
+
- Plan component hierarchy
|
|
54
24
|
- Identify shared vs feature-specific code
|
|
55
|
-
- Design state
|
|
25
|
+
- Design state approach (local, context, or external)
|
|
56
26
|
|
|
57
|
-
### 3. Implement
|
|
27
|
+
### 3. Implement
|
|
58
28
|
|
|
59
|
-
**
|
|
60
|
-
-
|
|
61
|
-
-
|
|
62
|
-
-
|
|
63
|
-
-
|
|
64
|
-
-
|
|
29
|
+
**Components:**
|
|
30
|
+
- Function components only
|
|
31
|
+
- `useState`/`useReducer` for local state
|
|
32
|
+
- `useTransition` for non-urgent updates
|
|
33
|
+
- `useDeferredValue` for expensive computations
|
|
34
|
+
- `Suspense` for lazy-loaded components
|
|
65
35
|
|
|
66
36
|
**Hooks:**
|
|
67
37
|
- Extract reusable logic into custom hooks
|
|
68
|
-
-
|
|
69
|
-
- Name
|
|
70
|
-
-
|
|
71
|
-
- Place feature hooks in `{feature}.hooks.ts`
|
|
38
|
+
- Components handle rendering; hooks handle logic
|
|
39
|
+
- Name descriptively: `useAuthState`, `useFormValidation`
|
|
40
|
+
- Place in `{feature}.hooks.ts`
|
|
72
41
|
|
|
73
|
-
**State
|
|
42
|
+
**State:**
|
|
74
43
|
- Lift state only as high as necessary
|
|
75
|
-
-
|
|
76
|
-
-
|
|
77
|
-
- Use `useSyncExternalStore` for external state integration
|
|
44
|
+
- Prefer composition over prop drilling
|
|
45
|
+
- `useSyncExternalStore` for external state
|
|
78
46
|
|
|
79
47
|
### 4. Validate
|
|
80
|
-
- Run existing tests
|
|
81
|
-
- Add tests for new components
|
|
48
|
+
- Run existing tests for regressions
|
|
49
|
+
- Add tests for new components/hooks
|
|
82
50
|
- Test loading and error states
|
|
83
|
-
-
|
|
84
|
-
- Ensure types pass with strict mode
|
|
85
|
-
|
|
86
|
-
### 5. Clean Up
|
|
87
|
-
- Remove any debugging code
|
|
88
|
-
- Ensure code follows project conventions
|
|
89
|
-
- Check for unused imports or variables
|
|
90
|
-
- Verify no barrel exports were introduced
|
|
51
|
+
- Remove debugging code and unused imports
|
|
91
52
|
|
|
92
|
-
##
|
|
53
|
+
## Constraints
|
|
93
54
|
|
|
94
|
-
-
|
|
95
|
-
-
|
|
96
|
-
-
|
|
97
|
-
-
|
|
98
|
-
- Don't add features beyond what was requested
|
|
99
|
-
- Use Suspense for code splitting, not just loading states
|
|
55
|
+
- NEVER create `index.ts` or `index.tsx` files
|
|
56
|
+
- MUST import directly from file, not folder
|
|
57
|
+
- MUST match surrounding code style
|
|
58
|
+
- NEVER add features beyond what was requested
|
|
@@ -0,0 +1,59 @@
|
|
|
1
|
+
# React Performance Workflow
|
|
2
|
+
|
|
3
|
+
> Architecture rules: See orchestration.md. Violations block merge.
|
|
4
|
+
|
|
5
|
+
## Before Coding
|
|
6
|
+
|
|
7
|
+
MUST answer:
|
|
8
|
+
- What is the specific performance problem?
|
|
9
|
+
- How will I measure improvement?
|
|
10
|
+
- Is this a real bottleneck or premature optimization?
|
|
11
|
+
|
|
12
|
+
## Process
|
|
13
|
+
|
|
14
|
+
### 1. Measure First
|
|
15
|
+
- Profile with React DevTools Profiler
|
|
16
|
+
- Identify components that re-render unnecessarily
|
|
17
|
+
- Check bundle size with build analyzer
|
|
18
|
+
- Measure actual user-facing metrics (not just hunches)
|
|
19
|
+
|
|
20
|
+
### 2. Identify Root Cause
|
|
21
|
+
|
|
22
|
+
**Common issues:**
|
|
23
|
+
- Components re-rendering when props haven't changed
|
|
24
|
+
- Expensive calculations on every render
|
|
25
|
+
- Large bundle from unused dependencies
|
|
26
|
+
- Missing code splitting on routes
|
|
27
|
+
|
|
28
|
+
### 3. Optimize
|
|
29
|
+
|
|
30
|
+
**Prevent unnecessary re-renders:**
|
|
31
|
+
```tsx
|
|
32
|
+
// Memoize components that receive stable props
|
|
33
|
+
const MemoizedList = memo(List)
|
|
34
|
+
|
|
35
|
+
// Memoize callbacks passed to children
|
|
36
|
+
const handleClick = useCallback(() => {
|
|
37
|
+
doSomething(id)
|
|
38
|
+
}, [id])
|
|
39
|
+
|
|
40
|
+
// Memoize expensive derived values
|
|
41
|
+
const sorted = useMemo(() => sortItems(items), [items])
|
|
42
|
+
```
|
|
43
|
+
|
|
44
|
+
**Reduce bundle size:**
|
|
45
|
+
- Lazy load routes with `React.lazy` + `Suspense`
|
|
46
|
+
- Replace heavy libraries with lighter alternatives
|
|
47
|
+
- Use tree-shakeable imports
|
|
48
|
+
|
|
49
|
+
### 4. Verify
|
|
50
|
+
- Re-profile to confirm improvement
|
|
51
|
+
- Ensure no regressions in functionality
|
|
52
|
+
- Document the optimization and why it helped
|
|
53
|
+
|
|
54
|
+
## Constraints
|
|
55
|
+
|
|
56
|
+
- NEVER optimize without measuring first
|
|
57
|
+
- NEVER add memo/useMemo/useCallback everywhere "just in case"
|
|
58
|
+
- MUST prove the optimization helps with real measurements
|
|
59
|
+
- Keep optimizations minimal and targeted
|
|
@@ -2,21 +2,23 @@
|
|
|
2
2
|
|
|
3
3
|
## Process
|
|
4
4
|
|
|
5
|
-
1.
|
|
6
|
-
2. Analyze
|
|
7
|
-
3.
|
|
5
|
+
1. Read the diff between current branch and main/master
|
|
6
|
+
2. Analyze changes to understand what was done
|
|
7
|
+
3. Output a PR title and description
|
|
8
8
|
|
|
9
9
|
## Output Format
|
|
10
10
|
|
|
11
11
|
```
|
|
12
|
-
PR
|
|
12
|
+
PR Title: <concise title>
|
|
13
13
|
|
|
14
14
|
Description:
|
|
15
|
-
<2-3 sentences
|
|
15
|
+
<2-3 sentences: what changed and why>
|
|
16
16
|
```
|
|
17
17
|
|
|
18
|
-
##
|
|
18
|
+
## Constraints
|
|
19
19
|
|
|
20
|
-
-
|
|
21
|
-
-
|
|
22
|
-
-
|
|
20
|
+
- MUST use imperative mood ("Add feature" not "Added feature")
|
|
21
|
+
- MUST mention breaking changes if any
|
|
22
|
+
- Keep description focused on "what" and "why"
|
|
23
|
+
- NEVER create branches, push, or create PRs remotely
|
|
24
|
+
- ONLY output the title and description for the user to copy
|
|
@@ -1,52 +1,43 @@
|
|
|
1
1
|
# React Refactor Workflow
|
|
2
2
|
|
|
3
|
-
|
|
3
|
+
> Architecture rules: See orchestration.md. Violations block merge.
|
|
4
4
|
|
|
5
|
-
|
|
6
|
-
- **No barrel exports**: Never use `index.ts` to re-export
|
|
7
|
-
- **Entry point naming**: File must match folder name (`Button/Button.tsx`)
|
|
8
|
-
- **Colocation**: Keep related files together
|
|
5
|
+
## Before Coding
|
|
9
6
|
|
|
10
|
-
|
|
11
|
-
|
|
12
|
-
-
|
|
13
|
-
-
|
|
14
|
-
- [ ] How will I verify behavior is unchanged?
|
|
7
|
+
MUST answer:
|
|
8
|
+
- What specific improvement am I making?
|
|
9
|
+
- Is there adequate test coverage?
|
|
10
|
+
- How will I verify behavior is unchanged?
|
|
15
11
|
|
|
16
12
|
## Process
|
|
17
13
|
|
|
18
14
|
### 1. Ensure Safety Net
|
|
19
|
-
- Run tests to confirm they pass
|
|
15
|
+
- Run tests to confirm they pass
|
|
20
16
|
- Add tests if coverage is insufficient
|
|
21
17
|
|
|
22
|
-
### 2. Plan
|
|
18
|
+
### 2. Plan
|
|
23
19
|
- Map all imports and dependencies
|
|
24
|
-
- Identify all callers of
|
|
20
|
+
- Identify all callers of affected code
|
|
25
21
|
- Break into small, safe steps
|
|
26
22
|
|
|
27
23
|
### 3. Execute Incrementally
|
|
28
24
|
|
|
29
|
-
|
|
30
|
-
```tsx
|
|
31
|
-
// Before (barrel)
|
|
32
|
-
import { Button } from '@/components'
|
|
25
|
+
Make one type of change at a time. Examples:
|
|
33
26
|
|
|
34
|
-
|
|
35
|
-
|
|
36
|
-
|
|
27
|
+
- Rename files to match folder names
|
|
28
|
+
- Convert barrel imports to direct imports
|
|
29
|
+
- Extract logic into hooks
|
|
30
|
+
- Split large components
|
|
37
31
|
|
|
38
|
-
|
|
39
|
-
```
|
|
40
|
-
Button/index.tsx → Button/Button.tsx
|
|
41
|
-
```
|
|
32
|
+
Run tests after each step.
|
|
42
33
|
|
|
43
34
|
### 4. Validate
|
|
44
35
|
- All tests pass
|
|
45
36
|
- No `index.ts` or `index.tsx` files remain
|
|
46
37
|
- All entry points match folder names
|
|
47
38
|
|
|
48
|
-
##
|
|
39
|
+
## Constraints
|
|
49
40
|
|
|
50
|
-
- Refactoring changes structure,
|
|
51
|
-
-
|
|
52
|
-
-
|
|
41
|
+
- Refactoring changes structure, NOT behavior
|
|
42
|
+
- NEVER fix bugs during refactor—note them separately
|
|
43
|
+
- MUST keep scope contained: one change type at a time
|
|
@@ -0,0 +1,54 @@
|
|
|
1
|
+
# React Code Review Workflow
|
|
2
|
+
|
|
3
|
+
> Architecture rules: See orchestration.md. Violations block merge.
|
|
4
|
+
|
|
5
|
+
## Before Reviewing
|
|
6
|
+
|
|
7
|
+
MUST answer:
|
|
8
|
+
- What is this change trying to accomplish?
|
|
9
|
+
- What files are modified?
|
|
10
|
+
|
|
11
|
+
## Process
|
|
12
|
+
|
|
13
|
+
### 1. Understand the Change
|
|
14
|
+
- Read the PR description
|
|
15
|
+
- Review the diff to understand scope
|
|
16
|
+
- Check if the approach makes sense for the goal
|
|
17
|
+
|
|
18
|
+
### 2. Check Architecture Compliance
|
|
19
|
+
|
|
20
|
+
- [ ] No `index.ts` or `index.tsx` barrel files
|
|
21
|
+
- [ ] Entry files match folder names (`Button/Button.tsx`)
|
|
22
|
+
- [ ] Direct imports used, not barrel imports
|
|
23
|
+
- [ ] Files colocated properly (component, hooks, types, tests together)
|
|
24
|
+
- [ ] New code placed in correct feature folder
|
|
25
|
+
|
|
26
|
+
### 3. Check React Patterns
|
|
27
|
+
|
|
28
|
+
- [ ] Function components only (no class components)
|
|
29
|
+
- [ ] Hooks follow rules (no conditional hooks, proper dependencies)
|
|
30
|
+
- [ ] Effects have cleanup where needed
|
|
31
|
+
- [ ] No obvious memory leaks (subscriptions, timers)
|
|
32
|
+
- [ ] Loading and error states handled
|
|
33
|
+
|
|
34
|
+
### 4. Check Code Quality
|
|
35
|
+
|
|
36
|
+
- [ ] No debugging code left in (console.log, debugger)
|
|
37
|
+
- [ ] No unused imports or variables
|
|
38
|
+
- [ ] Types are accurate (no `any` without justification)
|
|
39
|
+
- [ ] Tests cover new functionality
|
|
40
|
+
- [ ] No unrelated changes mixed in
|
|
41
|
+
|
|
42
|
+
### 5. Provide Feedback
|
|
43
|
+
|
|
44
|
+
Categorize comments:
|
|
45
|
+
- **Blocking**: Must fix before merge (bugs, architecture violations)
|
|
46
|
+
- **Suggestion**: Improvements to consider
|
|
47
|
+
- **Question**: Clarification needed
|
|
48
|
+
|
|
49
|
+
## Constraints
|
|
50
|
+
|
|
51
|
+
- NEVER approve code with architecture violations
|
|
52
|
+
- NEVER approve code without understanding what it does
|
|
53
|
+
- Keep feedback specific and actionable
|
|
54
|
+
- Suggest fixes, not just problems
|