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

feat: use AskUserQuestion for dirty working tree check

Browse Source 
Replace hard exit 1 with interactive AskUserQuestion prompt offering
commit/stash/abort options when /qa or /design-review detects a dirty
working tree.
This commit is contained in:
Garry Tan
2026-03-18 22:13:47 -07:00
parent 2a206920ed
commit 78c52878be
4 changed files with 62 additions and 24 deletions
Download Patch File Download Diff File Expand all files Collapse all files
design-review/SKILL.md
+15 -6
View File
@@ -179,15 +179,24 @@ You are a senior product designer AND a frontend engineer. Review live sites wit
Look for `DESIGN.md`, `design-system.md`, or similar in the repo root. If found, read it — all design decisions must be calibrated against it. Deviations from the project's stated design system are higher severity. If not found, use universal design principles and offer to create one from the inferred system.
**Require clean working tree before starting:**
**Check for clean working tree:**
```bash
if [ -n "$(git status --porcelain)" ]; then
echo "ERROR: Working tree is dirty. Commit or stash changes before running /design-review."
exit 1
fi
git status --porcelain
```
If the output is non-empty (working tree is dirty), **STOP** and use AskUserQuestion:
"Your working tree has uncommitted changes. /design-review needs a clean tree so each design fix gets its own atomic commit."
- A) Commit my changes — commit all current changes with a descriptive message, then start design review
- B) Stash my changes — stash, run design review, pop the stash after
- C) Abort — I'll clean up manually
RECOMMENDATION: Choose A because uncommitted work should be preserved as a commit before design review adds its own fix commits.
After the user chooses, execute their choice (commit or stash), then continue with setup.
**Find the browse binary:**
## SETUP (run this check BEFORE any browse command)
@@ -877,7 +886,7 @@ If the repo has a `TODOS.md`:
## Additional Rules (design-review specific)
11. **Clean working tree required.** Refuse to start if `git status --porcelain` is non-empty.
11. **Clean working tree required.** If dirty, use AskUserQuestion to offer commit/stash/abort before proceeding.
12. **One commit per fix.** Never bundle multiple design fixes into one commit.
13. **Only modify tests when generating regression tests in Phase 8e.5.** Never modify CI configuration. Never modify existing tests — only create new test files.
14. **Revert on regression.** If a fix makes things worse, `git revert HEAD` immediately.
design-review/SKILL.md.tmpl
+15 -6
View File
@@ -45,15 +45,24 @@ You are a senior product designer AND a frontend engineer. Review live sites wit
Look for `DESIGN.md`, `design-system.md`, or similar in the repo root. If found, read it — all design decisions must be calibrated against it. Deviations from the project's stated design system are higher severity. If not found, use universal design principles and offer to create one from the inferred system.
**Require clean working tree before starting:**
**Check for clean working tree:**
```bash
if [ -n "$(git status --porcelain)" ]; then
echo "ERROR: Working tree is dirty. Commit or stash changes before running /design-review."
exit 1
fi
git status --porcelain
```
If the output is non-empty (working tree is dirty), **STOP** and use AskUserQuestion:
"Your working tree has uncommitted changes. /design-review needs a clean tree so each design fix gets its own atomic commit."
- A) Commit my changes — commit all current changes with a descriptive message, then start design review
- B) Stash my changes — stash, run design review, pop the stash after
- C) Abort — I'll clean up manually
RECOMMENDATION: Choose A because uncommitted work should be preserved as a commit before design review adds its own fix commits.
After the user chooses, execute their choice (commit or stash), then continue with setup.
**Find the browse binary:**
{{BROWSE_SETUP}}
@@ -245,7 +254,7 @@ If the repo has a `TODOS.md`:
## Additional Rules (design-review specific)
11. **Clean working tree required.** Refuse to start if `git status --porcelain` is non-empty.
11. **Clean working tree required.** If dirty, use AskUserQuestion to offer commit/stash/abort before proceeding.
12. **One commit per fix.** Never bundle multiple design fixes into one commit.
13. **Only modify tests when generating regression tests in Phase 8e.5.** Never modify CI configuration. Never modify existing tests — only create new test files.
14. **Revert on regression.** If a fix makes things worse, `git revert HEAD` immediately.
qa/SKILL.md
+16 -6
View File
@@ -200,14 +200,24 @@ You are a QA engineer AND a bug-fix engineer. Test web applications like a real
**If no URL is given and you're on a feature branch:** Automatically enter **diff-aware mode** (see Modes below). This is the most common case — the user just shipped code on a branch and wants to verify it works.
**Require clean working tree before starting:**
**Check for clean working tree:**
```bash
if [ -n "$(git status --porcelain)" ]; then
echo "ERROR: Working tree is dirty. Commit or stash changes before running /qa."
exit 1
fi
git status --porcelain
```
If the output is non-empty (working tree is dirty), **STOP** and use AskUserQuestion:
"Your working tree has uncommitted changes. /qa needs a clean tree so each bug fix gets its own atomic commit."
- A) Commit my changes — commit all current changes with a descriptive message, then start QA
- B) Stash my changes — stash, run QA, pop the stash after
- C) Abort — I'll clean up manually
RECOMMENDATION: Choose A because uncommitted work should be preserved as a commit before QA adds its own fix commits.
After the user chooses, execute their choice (commit or stash), then continue with setup.
**Find the browse binary:**
## SETUP (run this check BEFORE any browse command)
@@ -892,7 +902,7 @@ If the repo has a `TODOS.md`:
## Additional Rules (qa-specific)
11. **Clean working tree required.** Refuse to start if `git status --porcelain` is non-empty.
11. **Clean working tree required.** If dirty, use AskUserQuestion to offer commit/stash/abort before proceeding.
12. **One commit per fix.** Never bundle multiple fixes into one commit.
13. **Only modify tests when generating regression tests in Phase 8e.5.** Never modify CI configuration. Never modify existing tests — only create new test files.
14. **Revert on regression.** If a fix makes things worse, `git revert HEAD` immediately.
qa/SKILL.md.tmpl
+16 -6
View File
@@ -49,14 +49,24 @@ You are a QA engineer AND a bug-fix engineer. Test web applications like a real
**If no URL is given and you're on a feature branch:** Automatically enter **diff-aware mode** (see Modes below). This is the most common case — the user just shipped code on a branch and wants to verify it works.
**Require clean working tree before starting:**
**Check for clean working tree:**
```bash
if [ -n "$(git status --porcelain)" ]; then
echo "ERROR: Working tree is dirty. Commit or stash changes before running /qa."
exit 1
fi
git status --porcelain
```
If the output is non-empty (working tree is dirty), **STOP** and use AskUserQuestion:
"Your working tree has uncommitted changes. /qa needs a clean tree so each bug fix gets its own atomic commit."
- A) Commit my changes — commit all current changes with a descriptive message, then start QA
- B) Stash my changes — stash, run QA, pop the stash after
- C) Abort — I'll clean up manually
RECOMMENDATION: Choose A because uncommitted work should be preserved as a commit before QA adds its own fix commits.
After the user chooses, execute their choice (commit or stash), then continue with setup.
**Find the browse binary:**
{{BROWSE_SETUP}}
@@ -300,7 +310,7 @@ If the repo has a `TODOS.md`:
## Additional Rules (qa-specific)
11. **Clean working tree required.** Refuse to start if `git status --porcelain` is non-empty.
11. **Clean working tree required.** If dirty, use AskUserQuestion to offer commit/stash/abort before proceeding.
12. **One commit per fix.** Never bundle multiple fixes into one commit.
13. **Only modify tests when generating regression tests in Phase 8e.5.** Never modify CI configuration. Never modify existing tests — only create new test files.
14. **Revert on regression.** If a fix makes things worse, `git revert HEAD` immediately.