mirror of
https://github.com/garrytan/gstack.git
synced 2026-05-20 19:29:56 +08:00
merge: incorporate origin/main into community-mode branch
Main advanced from 0.12.0.0 to 0.12.5.0 (voice directive, deploy dry-run, smarter browsing, headed mode, full commit coverage, codex hang fixes). Our branch had a stale 0.12.0.0 entry for community mode. Conflicts resolved: - VERSION/package.json: take main's 0.12.5.0 - CHANGELOG: take main's entries; our community-mode entry rewrites at ship - gen-skill-docs.ts: removed duplicate slug functions (main moved to resolvers/utility.ts) - touchfiles.ts: removed duplicate review-plan-completion tier entry - All 21 SKILL.md files: regenerated from templates (never resolve generated files manually) Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
Garry Tan
@@ -65,26 +65,15 @@ You are running the `/ship` workflow. This is a **non-interactive, fully automat
|
||||
|
||||
If the Eng Review is NOT "CLEAR":
|
||||
|
||||
1. **Check for a prior override on this branch:**
|
||||
```bash
|
||||
{{SLUG_EVAL}}
|
||||
grep '"skill":"ship-review-override"' ~/.gstack/projects/$SLUG/$BRANCH-reviews.jsonl 2>/dev/null || echo "NO_OVERRIDE"
|
||||
```
|
||||
If an override exists, display the dashboard and note "Review gate previously accepted — continuing." Do NOT ask again.
|
||||
Print: "No prior eng review found — ship will run its own pre-landing review in Step 3.5."
|
||||
|
||||
2. **If no override exists,** use AskUserQuestion:
|
||||
- Show that Eng Review is missing or has open issues
|
||||
- RECOMMENDATION: Choose C if the change is obviously trivial (< 20 lines, typo fix, config-only); Choose B for larger changes
|
||||
- Options: A) Ship anyway B) Abort — run /review or /plan-eng-review first C) Change is too small to need eng review
|
||||
- If CEO Review is missing, mention as informational ("CEO Review not run — recommended for product changes") but do NOT block
|
||||
- For Design Review: run `source <(~/.claude/skills/gstack/bin/gstack-diff-scope <base> 2>/dev/null)`. If `SCOPE_FRONTEND=true` and no design review (plan-design-review or design-review-lite) exists in the dashboard, mention: "Design Review not run — this PR changes frontend code. The lite design check will run automatically in Step 3.5, but consider running /design-review for a full visual audit post-implementation." Still never block.
|
||||
Check diff size: `git diff <base>...HEAD --stat | tail -1`. If the diff is >200 lines, add: "Note: This is a large diff. Consider running `/plan-eng-review` or `/autoplan` for architecture-level review before shipping."
|
||||
|
||||
3. **If the user chooses A or C,** persist the decision so future `/ship` runs on this branch skip the gate:
|
||||
```bash
|
||||
{{SLUG_EVAL}}
|
||||
echo '{"skill":"ship-review-override","timestamp":"'"$(date -u +%Y-%m-%dT%H:%M:%SZ)"'","decision":"USER_CHOICE"}' >> ~/.gstack/projects/$SLUG/$BRANCH-reviews.jsonl
|
||||
```
|
||||
Substitute USER_CHOICE with "ship_anyway" or "not_relevant".
|
||||
If CEO Review is missing, mention as informational ("CEO Review not run — recommended for product changes") but do NOT block.
|
||||
|
||||
For Design Review: run `source <(~/.claude/skills/gstack/bin/gstack-diff-scope <base> 2>/dev/null)`. If `SCOPE_FRONTEND=true` and no design review (plan-design-review or design-review-lite) exists in the dashboard, mention: "Design Review not run — this PR changes frontend code. The lite design check will run automatically in Step 3.5, but consider running /design-review for a full visual audit post-implementation." Still never block.
|
||||
|
||||
Continue to Step 1.5 — do NOT block or ask. Ship runs its own review in Step 3.5.
|
||||
|
||||
---
|
||||
|
||||
@@ -101,12 +90,13 @@ service with existing deployment — verify that a distribution pipeline exists.
|
||||
2. If new artifact detected, check for a release workflow:
|
||||
```bash
|
||||
ls .github/workflows/ 2>/dev/null | grep -iE 'release|publish|dist'
|
||||
grep -qE 'release|publish|deploy' .gitlab-ci.yml 2>/dev/null && echo "GITLAB_CI_RELEASE"
|
||||
```
|
||||
|
||||
3. **If no release pipeline exists and a new artifact was added:** Use AskUserQuestion:
|
||||
- "This PR adds a new binary/tool but there's no CI/CD pipeline to build and publish it.
|
||||
Users won't be able to download the artifact after merge."
|
||||
- A) Add a release workflow now (GitHub Actions cross-platform build + GitHub Releases)
|
||||
- A) Add a release workflow now (CI/CD release pipeline — GitHub Actions or GitLab CI depending on platform)
|
||||
- B) Defer — add to TODOS.md
|
||||
- C) Not needed — this is internal/web-only, existing deployment covers it
|
||||
|
||||
@@ -275,6 +265,13 @@ Review the diff for structural issues that tests don't catch.
|
||||
|
||||
If no issues found: `Pre-Landing Review: No issues found.`
|
||||
|
||||
9. Persist the review result to the review log:
|
||||
```bash
|
||||
~/.claude/skills/gstack/bin/gstack-review-log '{"skill":"review","timestamp":"TIMESTAMP","status":"STATUS","issues_found":N,"critical":N,"informational":N,"commit":"'"$(git rev-parse --short HEAD)"'","via":"ship"}'
|
||||
```
|
||||
Substitute TIMESTAMP (ISO 8601), STATUS ("clean" if no issues, "issues_found" otherwise),
|
||||
and N values from the summary counts above. The `via:"ship"` distinguishes from standalone `/review` runs.
|
||||
|
||||
Save the review output — it goes into the PR body in Step 8.
|
||||
|
||||
---
|
||||
@@ -343,10 +340,26 @@ For each classified comment:
|
||||
|
||||
1. Read `CHANGELOG.md` header to know the format.
|
||||
|
||||
2. Auto-generate the entry from **ALL commits on the branch** (not just recent ones):
|
||||
- Use `git log <base>..HEAD --oneline` to see every commit being shipped
|
||||
- Use `git diff <base>...HEAD` to see the full diff against the base branch
|
||||
- The CHANGELOG entry must be comprehensive of ALL changes going into the PR
|
||||
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
|
||||
@@ -357,6 +370,11 @@ For each classified comment:
|
||||
- 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.
|
||||
|
||||
---
|
||||
@@ -560,14 +578,20 @@ git push -u origin <branch-name>
|
||||
|
||||
---
|
||||
|
||||
## Step 8: Create PR
|
||||
## Step 8: Create PR/MR
|
||||
|
||||
Create a pull request using `gh`:
|
||||
Create a pull request (GitHub) or merge request (GitLab) using the platform detected in Step 0.
|
||||
|
||||
```bash
|
||||
gh pr create --base <base> --title "<type>: <summary>" --body "$(cat <<'EOF'
|
||||
The PR/MR body should contain these sections:
|
||||
|
||||
```
|
||||
## Summary
|
||||
<bullet points from CHANGELOG>
|
||||
<Summarize ALL changes being shipped. Run `git log <base>..HEAD --oneline` to enumerate
|
||||
every commit. Exclude the VERSION/CHANGELOG metadata commit (that's this PR's bookkeeping,
|
||||
not a substantive change). Group the remaining commits into logical sections (e.g.,
|
||||
"**Performance**", "**Dead Code Removal**", "**Infrastructure**"). Every substantive commit
|
||||
must appear in at least one section. If a commit's work isn't reflected in the summary,
|
||||
you missed it.>
|
||||
|
||||
## Test Coverage
|
||||
<coverage diagram from Step 3.4, or "All new code paths have test coverage.">
|
||||
@@ -621,11 +645,30 @@ Screenshots by [GStack](https://gstack.gg)
|
||||
- [x] All Vitest tests pass (N tests)
|
||||
|
||||
🤖 Generated with [Claude Code](https://claude.com/claude-code)
|
||||
```
|
||||
|
||||
**If GitHub:**
|
||||
|
||||
```bash
|
||||
gh pr create --base <base> --title "<type>: <summary>" --body "$(cat <<'EOF'
|
||||
<PR body from above>
|
||||
EOF
|
||||
)"
|
||||
```
|
||||
|
||||
**Output the PR URL** — then proceed to Step 8.5.
|
||||
**If GitLab:**
|
||||
|
||||
```bash
|
||||
glab mr create -b <base> -t "<type>: <summary>" -d "$(cat <<'EOF'
|
||||
<MR body from above>
|
||||
EOF
|
||||
)"
|
||||
```
|
||||
|
||||
**If neither CLI is available:**
|
||||
Print the branch name, remote URL, and instruct the user to create the PR/MR manually via the web UI. Do not stop — the code is pushed and ready.
|
||||
|
||||
**Output the PR/MR URL** — then proceed to Step 8.5.
|
||||
|
||||
---
|
||||
|
||||
|
||||
Reference in New Issue
Block a user