|
| 1 | +# Skill: Generate Branch Summary |
| 2 | + |
| 3 | +## Purpose |
| 4 | +Generate a concise, structured summary of all changes in the current branch compared to the develop branch. This summary is written to `summary.md` and serves as the single source of truth for understanding what a branch introduces. |
| 5 | + |
| 6 | +## When to Use |
| 7 | +- After completing implementation work on a feature branch |
| 8 | +- Before opening a pull request to develop |
| 9 | +- When updating branch documentation |
| 10 | +- To communicate changes clearly to reviewers |
| 11 | + |
| 12 | +## Process |
| 13 | + |
| 14 | +### 1. Determine Current Branch Context |
| 15 | +```bash |
| 16 | +git rev-parse --abbrev-ref HEAD # Get current branch name |
| 17 | +git log --oneline -5 # Check recent commits |
| 18 | +``` |
| 19 | + |
| 20 | +### 2. Analyze Changes Relative to Develop |
| 21 | +```bash |
| 22 | +git diff --stat develop...HEAD # Summary of changed files |
| 23 | +git log --oneline develop..HEAD # Commits in this branch |
| 24 | +git --no-pager diff develop...HEAD # Full diff (use --no-pager to avoid pager issues) |
| 25 | +``` |
| 26 | + |
| 27 | +### 3. Categorize Changes |
| 28 | +Group modifications by their nature: |
| 29 | +- **New APIs/Features** — new interfaces, classes, methods |
| 30 | +- **Performance Optimizations** — efficiency improvements, early-exit checks, reduced allocations |
| 31 | +- **Bug Fixes** — corrections to existing behavior |
| 32 | +- **Refactoring** — internal improvements without behavior change |
| 33 | +- **Documentation** — javadoc, comments, instruction files, style guides |
| 34 | +- **Version Bumps** — changes to version numbers in build.gradle or other config |
| 35 | + |
| 36 | +### 4. Structure the Summary |
| 37 | +Create a section in `summary.md` with this format: |
| 38 | + |
| 39 | +```markdown |
| 40 | +# Branch: <branch-name> |
| 41 | + |
| 42 | +**Status:** <Ready for review / In progress / Draft> |
| 43 | +**Commits:** <number> (e.g., "1 (abc1234 - 'commit message')" or "3 commits") |
| 44 | +**Version:** <old-version> → <new-version> (if applicable) |
| 45 | + |
| 46 | +## Changes Summary |
| 47 | + |
| 48 | +### <Category 1> (e.g., "New Array API") |
| 49 | +- Description of what was added/changed |
| 50 | +- Key implementation details |
| 51 | +- Important behaviors or constraints |
| 52 | + |
| 53 | +### <Category 2> (e.g., "Collection Optimization Pattern") |
| 54 | +- Explanation of the optimization |
| 55 | +- Which files/classes affected |
| 56 | +- Methods modified (count if many) |
| 57 | + |
| 58 | +### <Category 3> (e.g., "Documentation") |
| 59 | +- What documentation was added |
| 60 | +- Why it matters (e.g., for future contributors) |
| 61 | + |
| 62 | +## Testing & Validation |
| 63 | +- `./gradlew :module-name:build` ✅ |
| 64 | +- `./gradlew clean build` (recommended before merge) |
| 65 | +``` |
| 66 | + |
| 67 | +### 5. Key Guidelines for Content |
| 68 | + |
| 69 | +#### Be Specific |
| 70 | +- ✅ "Added `tryTrimTo(int)` method to safely resize internal storage" |
| 71 | +- ❌ "Added new method" |
| 72 | + |
| 73 | +#### Quantify When Helpful |
| 74 | +- ✅ "Applied isEmpty() checks to 21 methods across 3 dictionary types" |
| 75 | +- ❌ "Applied optimization across dictionaries" |
| 76 | + |
| 77 | +#### Explain Impact |
| 78 | +- ✅ "Avoids unnecessary allocations and iterations when collections are empty" |
| 79 | +- ❌ "Performance improvement" |
| 80 | + |
| 81 | +#### Include Implementation Details |
| 82 | +- ✅ "Returns unchanged if requested size exceeds capacity or is less than current size" |
| 83 | +- ❌ "Has validation logic" |
| 84 | + |
| 85 | +#### Use Clear Formatting |
| 86 | +- Use markdown headers (`#`, `##`, `###`) for hierarchy |
| 87 | +- Use bullet points for lists |
| 88 | +- Use bold (`**`) for emphasis on key terms |
| 89 | +- Use inline code (`` ` ` ``) for class/method names |
| 90 | + |
| 91 | +### 6. Output Location |
| 92 | +Always write to `summary.md` in the repository root, replacing or updating the previous summary section. |
| 93 | + |
| 94 | +### 7. Keep Previous Content |
| 95 | +If `summary.md` already contains unrelated sections (e.g., documentation of other work), preserve them unless explicitly asked to remove them. Only update or replace the branch summary section. |
| 96 | + |
| 97 | +## Example Output |
| 98 | + |
| 99 | +```markdown |
| 100 | +# Branch: update-api-part-2 |
| 101 | + |
| 102 | +**Status:** Ready for review |
| 103 | +**Commits:** 1 (1367d9b - "small improvements") |
| 104 | +**Version:** 10.0.alpha13 → 10.0.alpha14 |
| 105 | + |
| 106 | +## Changes Summary |
| 107 | + |
| 108 | +### 1. New Array API: `tryTrimTo(int)` |
| 109 | +- Added `UnsafeMutableArray.tryTrimTo(int internalStorageSize)` method for safe internal storage resizing |
| 110 | +- Implemented in `AbstractMutableArray` with validation: |
| 111 | + - Returns unchanged if requested size exceeds current capacity |
| 112 | + - Returns unchanged if requested size is less than current element count |
| 113 | + - Performs trimming for valid requests |
| 114 | +- Includes complete javadoc with `@since 10.0.alpha14` tag |
| 115 | + |
| 116 | +### 2. Collection Optimization Pattern |
| 117 | +Applied early-exit `isEmpty()` checks across dictionary implementations: |
| 118 | +- **AbstractHashBasedIntToRefDictionary:** 7 methods optimized |
| 119 | +- **AbstractHashBasedLongToRefDictionary:** 7 methods optimized |
| 120 | +- **AbstractHashBasedRefToRefDictionary:** 7 methods optimized |
| 121 | + |
| 122 | +Optimized methods: `iterator()`, `keys()` (all overloads), `values()` (all overloads) |
| 123 | +**Benefit:** Avoids allocations and iterations when collections are empty |
| 124 | + |
| 125 | +### 3. Documentation |
| 126 | +- Added comprehensive javadoc to `tryTrimTo()` method |
| 127 | +- Updated `.github/copilot-instructions.md` with "Collections optimization pattern" section |
| 128 | + |
| 129 | +## Testing & Validation |
| 130 | +- Module build: `./gradlew :rlib-collections:build` ✅ |
| 131 | +- Full build verification: `./gradlew clean build` (recommended before merge) |
| 132 | +``` |
| 133 | + |
| 134 | +## Common Patterns in RLib |
| 135 | + |
| 136 | +### API Additions |
| 137 | +Always mention: |
| 138 | +- Method signature and purpose |
| 139 | +- Return type and parameter descriptions |
| 140 | +- Javadoc status (whether included, version tag) |
| 141 | +- Key behaviors or constraints |
| 142 | + |
| 143 | +### Optimizations |
| 144 | +Always mention: |
| 145 | +- What was optimized (method names, counts) |
| 146 | +- Why (avoid allocations, reduce iterations, etc.) |
| 147 | +- Affected files/classes |
| 148 | +- Observable impact |
| 149 | + |
| 150 | +### Documentation Changes |
| 151 | +Mention: |
| 152 | +- What was added or updated |
| 153 | +- Why it matters (helps future contributors, clarifies usage, standardizes conventions) |
| 154 | +- Files affected |
| 155 | + |
| 156 | +## Tips |
| 157 | + |
| 158 | +1. **Use `git diff --stat`** to get a quick overview of which files changed and how many lines |
| 159 | +2. **Use `git log develop..HEAD`** to list all commits in the branch for reference |
| 160 | +3. **Extract key insights from the actual diff** — skim the output to understand the nature of changes |
| 161 | +4. **Be concise** — summaries should be readable in 2-3 minutes |
| 162 | +5. **Link to code** — mention file paths and method names so reviewers can navigate easily |
| 163 | +6. **Quantify changes** — "7 methods optimized" is more informative than "several optimizations" |
0 commit comments