@yeongjaeyou/claude-code-config 0.7.0 → 0.7.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.
|
@@ -10,10 +10,20 @@ Act as an expert developer who systematically analyzes and resolves GitHub issue
|
|
|
10
10
|
- If milestone exists, run `gh issue list --milestone "<milestone-name>" --json number,title,state` to view related issues and understand overall context
|
|
11
11
|
- Identify requirements precisely
|
|
12
12
|
|
|
13
|
-
2. **
|
|
13
|
+
2. **Verify Plan File Alignment (If Exists)**:
|
|
14
|
+
- Check if issue body or milestone description contains a plan file path
|
|
15
|
+
- Common patterns: `Plan: /path/to/plan.md`, `See: .claude/plans/xxx.md`
|
|
16
|
+
- If plan file exists:
|
|
17
|
+
1. Read the plan file content
|
|
18
|
+
2. Compare plan objectives with issue requirements
|
|
19
|
+
3. Verify scope alignment (plan covers issue, no scope creep)
|
|
20
|
+
4. If misaligned, ask user for clarification before proceeding
|
|
21
|
+
- If no plan file, continue to next step
|
|
22
|
+
|
|
23
|
+
3. **Create Branch**: Create and checkout a new branch named `issue-$ISSUE_NUMBER` from `main` or `master` branch.
|
|
14
24
|
- **Initialize submodules**: When using worktree, run `git submodule update --init --recursive`
|
|
15
25
|
|
|
16
|
-
|
|
26
|
+
4. **Update GitHub Project Status (Optional)**
|
|
17
27
|
- Run `gh project list --owner <owner> --format json` to check for projects
|
|
18
28
|
- If no projects exist, skip silently
|
|
19
29
|
- If projects exist:
|
|
@@ -26,20 +36,21 @@ Act as an expert developer who systematically analyzes and resolves GitHub issue
|
|
|
26
36
|
```
|
|
27
37
|
- Skip if Status field does not exist
|
|
28
38
|
|
|
29
|
-
|
|
39
|
+
5. **Analyze Codebase**: Use sub-agents to analyze the codebase in parallel, identifying relevant files and structure needed to resolve the issue.
|
|
30
40
|
|
|
31
|
-
|
|
41
|
+
6. **Plan Resolution**: Based on analysis results, develop a concrete resolution plan and define work steps.
|
|
32
42
|
|
|
33
|
-
|
|
43
|
+
7. **Resolve Issue**: Spawn sub-agents to modify code and implement features according to the plan.
|
|
34
44
|
- **Execution verification required**: For Python scripts, executables, or any runnable code, always execute to verify correct behavior. Do not rely solely on file existence or previous results.
|
|
35
45
|
|
|
36
|
-
|
|
46
|
+
8. **Write Tests**: Spawn independent sub-agents per file to write unit tests in parallel, achieving at least 80% coverage.
|
|
37
47
|
|
|
38
|
-
|
|
48
|
+
9. **Validate**: Run tests, lint checks, and build verification in parallel using independent sub-agents to validate code quality.
|
|
39
49
|
|
|
40
|
-
|
|
50
|
+
10. **Create PR**: Create a pull request for the resolved issue.
|
|
51
|
+
- **Commit only issue-relevant files**: Never use `git add -A`. Stage only files directly related to the issue.
|
|
41
52
|
|
|
42
|
-
|
|
53
|
+
11. **Update Issue Checkboxes**: Mark completed checkbox items in the issue as done.
|
|
43
54
|
|
|
44
55
|
> See [Work Guidelines](../guidelines/work-guidelines.md)
|
|
45
56
|
|
|
@@ -85,6 +85,27 @@ task-master show $TASK_ID
|
|
|
85
85
|
- [ ] Task status is `pending` or `in-progress`
|
|
86
86
|
- [ ] All dependency tasks are complete (check dependencies via `task-master show`)
|
|
87
87
|
|
|
88
|
+
### 2.5. Verify Plan File Alignment (If Exists)
|
|
89
|
+
|
|
90
|
+
Check if Issue body or Milestone description references a plan file:
|
|
91
|
+
|
|
92
|
+
```bash
|
|
93
|
+
# Extract plan file path from issue body
|
|
94
|
+
gh issue view $ISSUE_NUMBER --json body --jq '.body' | grep -oP '(?:Plan|plan|See|see)[:\s]+[`"]?([^\s`"]+\.md)'
|
|
95
|
+
```
|
|
96
|
+
|
|
97
|
+
**If plan file found:**
|
|
98
|
+
1. Read the plan file and understand the implementation approach
|
|
99
|
+
2. Verify alignment:
|
|
100
|
+
- [ ] Plan objectives match Issue requirements
|
|
101
|
+
- [ ] Plan scope covers all Issue checkboxes
|
|
102
|
+
- [ ] No conflicting approaches between plan and issue
|
|
103
|
+
3. If misaligned:
|
|
104
|
+
- Use AskUserQuestion to clarify which to follow
|
|
105
|
+
- Options: "Follow plan", "Follow issue", "Abort for revision"
|
|
106
|
+
|
|
107
|
+
**If no plan file, continue to Step 3.**
|
|
108
|
+
|
|
88
109
|
### 3. Expand Subtasks (If Needed)
|
|
89
110
|
|
|
90
111
|
```bash
|
|
@@ -61,6 +61,33 @@ Utilize MCP servers whenever possible:
|
|
|
61
61
|
- `mcpdocs` - Documentation fetching
|
|
62
62
|
- `firecrawl` - Web scraping and search
|
|
63
63
|
|
|
64
|
+
### Serena MCP (Symbolic Code Analysis)
|
|
65
|
+
|
|
66
|
+
Serena provides LSP-based semantic code analysis. Use it for precise code navigation and modification.
|
|
67
|
+
|
|
68
|
+
**When to Use:**
|
|
69
|
+
- Understanding codebase structure → `get_symbols_overview`
|
|
70
|
+
- Finding specific symbols → `find_symbol`
|
|
71
|
+
- Tracing references → `find_referencing_symbols`
|
|
72
|
+
- Precise code modifications → `replace_symbol_body`, `insert_after_symbol`
|
|
73
|
+
|
|
74
|
+
**Key Tools:**
|
|
75
|
+
|
|
76
|
+
| Tool | Use Case |
|
|
77
|
+
|------|----------|
|
|
78
|
+
| `get_symbols_overview` | First step: understand file structure |
|
|
79
|
+
| `find_symbol` | Search by name pattern (supports substring matching) |
|
|
80
|
+
| `find_referencing_symbols` | Find all usages of a symbol |
|
|
81
|
+
| `replace_symbol_body` | Replace entire function/class/method |
|
|
82
|
+
| `insert_after_symbol` / `insert_before_symbol` | Add new code at precise locations |
|
|
83
|
+
| `search_for_pattern` | Flexible regex search across codebase |
|
|
84
|
+
|
|
85
|
+
**Best Practices:**
|
|
86
|
+
1. Start with `get_symbols_overview` for new files
|
|
87
|
+
2. Use `find_symbol` with `depth=1` to see class methods before diving deeper
|
|
88
|
+
3. Prefer symbolic editing over file-based editing when modifying functions/classes
|
|
89
|
+
4. Always check `find_referencing_symbols` before renaming/removing symbols
|
|
90
|
+
|
|
64
91
|
### Python Development
|
|
65
92
|
- **Virtual Environment (MANDATORY)**: Always use virtual environment (uv) when running Python
|
|
66
93
|
- **NEVER** use system Python (`python`, `python3`) directly
|