CalvinBackup/gstack
1
0
Fork 0
mirror of https://github.com/garrytan/gstack.git synced 2026-06-01 15:51:41 +02:00
Code Issues Packages Projects Releases Wiki Activity

Merge branch 'main' into garrytan/team-supabase-store

Browse Source 
Resolved conflicts across 23 files. Key merge decisions:
- Adopted main's TemplateContext type in gen-skill-docs.ts
- Adopted main's new features (trigger phrases, codex integration,
  analytics, proactive config, review chaining)
- Replaced gstack-review-log/gstack-review-read helpers with inline
  approach using $PROJECTS_DIR/$SLUG/reviews/$BRANCH.jsonl paths
- Added "commit":"COMMIT" field to all review log entries (from main)
- Kept our $PROJECTS_DIR/$SLUG path reorganization throughout
- Added Codex E2E test from main + our E2E isolation cleanup

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
Garry Tan
2026-03-19 17:16:08 -07:00
parent fb7fe3d280 bd834aeadb
commit 0ffb4e9ec5
84 changed files with 8122 additions and 1234 deletions
Download Patch File Download Diff File Expand all files Collapse all files
ship/SKILL.md.tmpl
+83 -32
View File
@@ -2,7 +2,8 @@
name: ship
version: 1.0.0
description: |
Ship workflow: detect + merge base branch, run tests, review diff, bump VERSION, update CHANGELOG, commit, push, create PR.
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.
allowed-tools:
- Bash
- Read
@@ -70,7 +71,7 @@ If the Eng Review is NOT "CLEAR":
- 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 /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 `eval $(~/.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.
- 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.
3. **If the user chooses A or C,** persist the decision so future `/ship` runs on this branch skip the gate:
```bash
@@ -402,6 +403,46 @@ For each classified comment:
---
## Step 3.8: Codex second opinion (optional)
Check if the Codex CLI is available:
```bash
which codex 2>/dev/null && echo "CODEX_AVAILABLE" || echo "CODEX_NOT_AVAILABLE"
```
If Codex is available, use AskUserQuestion:
```
Pre-landing review complete. Want an independent Codex (OpenAI) review before shipping?
A) Run Codex code review — independent diff review with pass/fail gate
B) Run Codex adversarial challenge — try to break this code
C) Skip — ship without Codex review
```
If the user chooses A or B:
**For code review (A):** Run `codex review --base <base>` with a 5-minute timeout.
Present the full output verbatim under a `CODEX SAYS:` header. Check for `[P1]` markers
to determine pass/fail gate. Persist the result:
```bash
eval $(~/.claude/skills/gstack/bin/gstack-slug 2>/dev/null)
mkdir -p $PROJECTS_DIR/$SLUG/reviews
echo '{"skill":"codex-review","timestamp":"TIMESTAMP","status":"STATUS","gate":"GATE","commit":"COMMIT"}' >> $PROJECTS_DIR/$SLUG/reviews/$BRANCH.jsonl
```
If GATE is FAIL, use AskUserQuestion: "Codex found critical issues. Ship anyway?"
If the user says no, stop. If yes, continue to Step 4.
**For adversarial (B):** Run codex exec with the adversarial prompt (see /codex skill).
Present findings. This is informational — does not block shipping.
If Codex is not available, skip silently. Continue to Step 4.
---
## Step 4: Version bump (auto-decide)
1. Read the current `VERSION` file (4-digit format: `MAJOR.MINOR.PATCH.MICRO`)
@@ -536,6 +577,28 @@ EOF
---
## Step 6.5: Verification Gate
**IRON LAW: NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE.**
Before pushing, re-verify if code changed during Steps 4-6:
1. **Test verification:** If ANY code changed after Step 3's test run (fixes from review findings, CHANGELOG edits don't count), re-run the test suite. Paste fresh output. Stale output from Step 3 is NOT acceptable.
2. **Build verification:** If the project has a build step, run it. Paste output.
3. **Rationalization prevention:**
- "Should work now" → RUN IT.
- "I'm confident" → Confidence is not evidence.
- "I already tested earlier" → Code changed since then. Test again.
- "It's a trivial change" → Trivial changes break production.
**If tests fail here:** STOP. Do not push. Fix the issue and return to Step 3.
Claiming work is complete without verification is dishonesty, not efficiency.
---
## Step 7: Push
Push to the remote with upstream tracking:
@@ -589,41 +652,28 @@ EOF
)"
```
**Output the PR URL** — this should be the final output the user sees.
**Output the PR URL** — then proceed to Step 8.5.
---
## Step 8.5: Sync to Team (non-fatal)
## Step 8.5: Auto-invoke /document-release
After the PR is created, write a ship log and sync to the team store. This step is entirely silent if sync is not configured.
After the PR is created, automatically sync project documentation. Read the
`document-release/SKILL.md` skill file (adjacent to this skill's directory) and
execute its full workflow:
1. Write ship metadata to a temp file:
```bash
cat > /tmp/gstack-ship-log.json << 'SHIPEOF'
{
"version": "<new version from Step 4>",
"branch": "<current branch>",
"pr_url": "<PR URL from Step 8>",
"review_findings": { "critical": 0, "informational": 0 },
"greptile_stats": { "total": 0, "valid": 0, "fixed": 0, "fp": 0 },
"todos_completed": [],
"test_results": { "pass": true, "test_count": 0 }
}
SHIPEOF
```
Substitute actual values from the preceding steps. Use `0` for Greptile fields if no Greptile comments were found.
1. Read the `/document-release` skill: `cat ${CLAUDE_SKILL_DIR}/../document-release/SKILL.md`
2. Follow its instructions — it reads all .md files in the project, cross-references
the diff, and updates anything that drifted (README, ARCHITECTURE, CONTRIBUTING,
CLAUDE.md, TODOS, etc.)
3. If any docs were updated, commit the changes and push to the same branch:
```bash
git add -A && git commit -m "docs: sync documentation with shipped changes" && git push
```
4. If no docs needed updating, say "Documentation is current — no updates needed."
2. Push (non-fatal):
```bash
~/.claude/skills/gstack/bin/gstack-sync push-ship /tmp/gstack-ship-log.json 2>/dev/null && echo "Synced to team ✓" || true
~/.claude/skills/gstack/bin/gstack-sync push-transcript 2>/dev/null || true
```
3. Leaderboard callout (non-fatal): After sync, show the user their position on the team leaderboard this week:
```bash
~/.claude/skills/gstack/bin/gstack-eval leaderboard 2>/dev/null | head -15 || true
```
If leaderboard data is available, print the table. If sync is not configured or no data exists, silently skip.
This step is automatic. Do not ask the user for confirmation. The goal is zero-friction
doc updates — the user runs `/ship` and documentation stays current without a separate command.
---
@@ -638,5 +688,6 @@ If leaderboard data is available, print the table. If sync is not configured or
- **Split commits for bisectability** — each commit = one logical change.
- **TODOS.md completion detection must be conservative.** Only mark items as completed when the diff clearly shows the work is done.
- **Use Greptile reply templates from greptile-triage.md.** Every reply includes evidence (inline diff, code references, re-rank suggestion). Never post vague replies.
- **Never push without fresh verification evidence.** If code changed after Step 3 tests, re-run before pushing.
- **Step 3.4 generates coverage tests.** They must pass before committing. Never commit failing tests.
- **The goal is: user says `/ship`, next thing they see is the review + PR URL.**
- **The goal is: user says `/ship`, next thing they see is the review + PR URL + auto-synced docs.**