CalvinBackup/gstack
1
0
Fork 0
mirror of https://github.com/garrytan/gstack.git synced 2026-08-18 20:17:14 +02:00
Code Issues Packages Projects Releases Wiki Activity

merge: incorporate origin/main into community-mode branch

Browse Source 
Conflicts resolved:
- VERSION: accept main's 0.14.5.0 (higher than our 0.14.0.0)
- package.json: same version resolution
- CHANGELOG.md: drop duplicate 0.14.0.0 entry (already on main),
  keep main's entries for 0.14.1-0.14.5 and 0.13.7-0.13.10
- README.md: merge skill lists — keep main's /design-html + /learn,
  add our /gstack-submit to both install and troubleshooting lists
- docs/skills.md: keep all three entries (/gstack-submit, /autoplan, /learn)

Main brought in 0.14.1-0.14.5: design-to-code (/design-html),
comparison board chooser, sidebar CSS inspector + per-tab agents,
always-on adversarial review + scope drift, review army (7 parallel
specialist reviewers), ship idempotency, skill prefix fix.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
Garry Tan
2026-03-30 21:50:02 -07:00
co-authored by Claude Opus 4.6
parent 3b0102b12d 7ea6ead9fa
commit 93e8258241
128 changed files with 14314 additions and 1393 deletions
Download Patch File Download Diff File Expand all files Collapse all files
ship/SKILL.md.tmpl
+52 -46
View File
@@ -3,8 +3,11 @@ name: ship
preamble-tier: 4
version: 1.0.0
description: |
Ship workflow: detect + merge base branch, run tests, review diff, bump VERSION, update CHANGELOG, commit, push, create PR. Use when asked to "ship", "deploy", "push to main", "create a PR", or "merge and push".
Proactively suggest when the user says code is ready or asks about deploying.
Ship workflow: detect + merge base branch, run tests, review diff, bump VERSION,
update CHANGELOG, commit, push, create PR. Use when asked to "ship", "deploy",
"push to main", "create a PR", "merge and push", or "get it deployed".
Proactively invoke this skill (do NOT push/PR directly) when the user says code
is ready, asks about deploying, wants to push code up, or asks to create a PR. (gstack)
allowed-tools:
- Bash
- Read
@@ -230,6 +233,8 @@ If multiple suites need to run, run them sequentially (each needs a test lane).
{{LEARNINGS_SEARCH}}
{{SCOPE_DRIFT}}
---
## Step 3.5: Pre-Landing Review
@@ -326,13 +331,25 @@ For each classified comment:
## Step 4: Version bump (auto-decide)
**Idempotency check:** Before bumping, compare VERSION against the base branch.
```bash
BASE_VERSION=$(git show origin/<base>:VERSION 2>/dev/null || echo "0.0.0.0")
CURRENT_VERSION=$(cat VERSION 2>/dev/null || echo "0.0.0.0")
echo "BASE: $BASE_VERSION HEAD: $CURRENT_VERSION"
if [ "$CURRENT_VERSION" != "$BASE_VERSION" ]; then echo "ALREADY_BUMPED"; fi
```
If output shows `ALREADY_BUMPED`, VERSION was already bumped on this branch (prior `/ship` run). Skip the rest of Step 4 and use the current VERSION. Otherwise proceed with the bump.
1. Read the current `VERSION` file (4-digit format: `MAJOR.MINOR.PATCH.MICRO`)
2. **Auto-decide the bump level based on the diff:**
- Count lines changed (`git diff origin/<base>...HEAD --stat | tail -1`)
- Check for feature signals: new route/page files (e.g. `app/*/page.tsx`, `pages/*.ts`), new DB migration/schema files, new test files alongside new source files, or branch name starting with `feat/`
- **MICRO** (4th digit): < 50 lines changed, trivial tweaks, typos, config
- **PATCH** (3rd digit): 50+ lines changed, bug fixes, small-medium features
- **MINOR** (2nd digit): **ASK the user** — only for major features or significant architectural changes
- **PATCH** (3rd digit): 50+ lines changed, no feature signals detected
- **MINOR** (2nd digit): **ASK the user** if ANY feature signal is detected, OR 500+ lines changed, OR new modules/packages added
- **MAJOR** (1st digit): **ASK the user** — only for milestones or breaking changes
3. Compute the new version:
@@ -343,46 +360,7 @@ For each classified comment:
---
## Step 5: CHANGELOG (auto-generate)
1. Read `CHANGELOG.md` header to know the format.
2. **First, enumerate every commit on the branch:**
```bash
git log <base>..HEAD --oneline
```
Copy the full list. Count the commits. You will use this as a checklist.
3. **Read the full diff** to understand what each commit actually changed:
```bash
git diff <base>...HEAD
```
4. **Group commits by theme** before writing anything. Common themes:
- New features / capabilities
- Performance improvements
- Bug fixes
- Dead code removal / cleanup
- Infrastructure / tooling / tests
- Refactoring
5. **Write the CHANGELOG entry** covering ALL groups:
- If existing CHANGELOG entries on the branch already cover some commits, replace them with one unified entry for the new version
- Categorize changes into applicable sections:
- `### Added` — new features
- `### Changed` — changes to existing functionality
- `### Fixed` — bug fixes
- `### Removed` — removed features
- Write concise, descriptive bullet points
- Insert after the file header (line 5), dated today
- Format: `## [X.Y.Z.W] - YYYY-MM-DD`
6. **Cross-check:** Compare your CHANGELOG entry against the commit list from step 2.
Every commit must map to at least one bullet point. If any commit is unrepresented,
add it now. If the branch has N commits spanning K themes, the CHANGELOG must
reflect all K themes.
**Do NOT ask the user to describe changes.** Infer from the diff and commit history.
{{CHANGELOG_WORKFLOW}}
---
@@ -577,7 +555,17 @@ If `SCOPE_FRONTEND=false` or browse is not available, skip this step silently.
## Step 7: Push
Push to the remote with upstream tracking:
**Idempotency check:** Check if the branch is already pushed and up to date.
```bash
git fetch origin <branch-name> 2>/dev/null
LOCAL=$(git rev-parse HEAD)
REMOTE=$(git rev-parse origin/<branch-name> 2>/dev/null || echo "none")
echo "LOCAL: $LOCAL REMOTE: $REMOTE"
[ "$LOCAL" = "$REMOTE" ] && echo "ALREADY_PUSHED" || echo "PUSH_NEEDED"
```
If `ALREADY_PUSHED`, skip the push. Otherwise push with upstream tracking:
```bash
git push -u origin <branch-name>
@@ -587,7 +575,21 @@ git push -u origin <branch-name>
## Step 8: Create PR/MR
Create a pull request (GitHub) or merge request (GitLab) using the platform detected in Step 0.
**Idempotency check:** Check if a PR/MR already exists for this branch.
**If GitHub:**
```bash
gh pr view --json url,number,state -q 'if .state == "OPEN" then "PR #\(.number): \(.url)" else "NO_PR" end' 2>/dev/null || echo "NO_PR"
```
**If GitLab:**
```bash
glab mr view -F json 2>/dev/null | jq -r 'if .state == "opened" then "MR_EXISTS" else "NO_MR" end' 2>/dev/null || echo "NO_MR"
```
If an **open** PR/MR already exists: **update** the PR body with the latest test results, coverage, and review findings using `gh pr edit --body "..."` (GitHub) or `glab mr update -d "..."` (GitLab). Print the existing URL and continue to Step 8.5.
If no PR/MR exists: create a pull request (GitHub) or merge request (GitLab) using the platform detected in Step 0.
The PR/MR body should contain these sections:
@@ -619,6 +621,10 @@ you missed it.>
<If no Greptile comments found: "No Greptile comments.">
<If no PR existed during Step 3.75: omit this section entirely>
## Scope Drift
<If scope drift ran: "Scope Check: CLEAN" or list of drift/creep findings>
<If no scope drift: omit this section>
## Plan Completion
<If plan file found: completion checklist summary from Step 3.45>
<If no plan file: "No plan file detected.">