@simpleapps-com/augur-skills 2026.3.29 → 2026.4.1

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@simpleapps-com/augur-skills",
-  "version": "2026.03.29",
+  "version": "2026.04.1",
   "description": "Install curated Claude Code skills",
   "license": "MIT",
   "type": "module",

package/skills/simpleapps/git-safety/SKILL.md

@@ -43,6 +43,12 @@ If you made changes and the user then runs `/submit`, the command starts fresh
 
 Do NOT ask for redundant confirmation inside `/submit` if the user just invoked it. The invocation is the approval. But each discrete git operation within the flow (commit, then push) should still be reported before execution.
 
+## Stash hygiene
+
+MUST NOT leave stashes behind. If you stash changes (e.g., to switch branches), you MUST pop or drop the stash before the operation is complete. Orphaned stashes accumulate silently and confuse future work.
+
+Better yet, avoid stashing entirely. If you need to create a branch from a different base, commit or stage work first, or create the branch before making changes. Stash is a last resort, not a workflow step.
+
 ## The Pattern
 
 **Do the work → report results → wait.**

package/skills/simpleapps/project-defaults/SKILL.md

@@ -137,6 +137,11 @@ Every project SHOULD configure `.claude/settings.local.json` with these deny rul
 
 ```json
 {
+  "env": {
+    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1",
+    "CLAUDE_CODE_DISABLE_FEEDBACK_SURVEY": "1",
+    "CLAUDE_CODE_NO_FLICKER": "1"
+  },
   "permissions": {
     "allow": [
       "Bash(pnpm:*)",

package/skills/simpleapps/quality/SKILL.md

@@ -55,11 +55,9 @@ Do not install or configure tools without the user's approval. Flag what's missi
 - **No tests for changed code** — suggest vitest
 - **No pre-commit hooks** — suggest lefthook
 
-## Own your scope
+## Own every issue
 
-Fix every issue in files you touched during this session. Context compaction erases your memory of earlier changes — what looks pre-existing may be something you introduced. Err on the side of owning it.
-
-For failures in files you did not touch, report them as separate findings rather than fixing them inline. Fixing unrelated code is local optimization that delays shipping the actual task. The goal is zero issues in the work area, not unbounded cleanup of the entire codebase.
+Fix every issue the checks find, regardless of which file it is in or who introduced it. There is no such thing as a "pre-existing issue" — context compaction erases your memory of earlier changes, so what looks pre-existing may be something you introduced. Even if you truly did not cause it, the goal is zero issues, not blame assignment. Fix it anyway.
 
 ## Resolve, never hide
 

package/skills/simpleapps/work-habits/SKILL.md

@@ -38,7 +38,13 @@ When debugging in the browser, MUST check for error overlays (red error pill/bad
 
 ## Verify your own work
 
-Run tests, check output, compare results. YOU MUST NOT mark work complete without verification. If you can't verify, say so.
+Code that compiles is not code that works. After making changes, verify they actually work:
+
+1. Run tests (`pnpm test` or equivalent)
+2. If the project has a Testing page in the wiki, suggest `/verify` to walk through the E2E checklist in the browser
+3. If you changed UI, check it visually — load the page in Chrome and confirm it looks right
+
+YOU MUST NOT mark work complete without verification. Suggesting `/submit` or `/quality` before verifying the code works is backwards — broken code that passes lint is still broken code. Verify first, then let the user decide next steps.
 
 ## Own every issue you find
 
@@ -50,7 +56,9 @@ Use TodoRead/TodoWrite on multi-step tasks. Mark items in-progress before starti
 
 ## Never prompt for git actions
 
-MUST NOT ask "want me to commit?", "should I submit?", or any variation after completing work. The user will say "commit", `/submit`, or equivalent when ready. During multi-step implementation, asking to commit between steps interrupts the flow and adds noise. Report what was done and stop.
+MUST NOT ask "want me to commit?", "should I submit?", "ready for a PR?", "want me to push?", or ANY variation after completing work. Do not hint at it either — "if you're happy with this, you can run /submit" is the same thing with extra words. The user knows their own workflow. They will say "commit", `/submit`, or equivalent when they are ready.
+
+After completing work: report what changed, suggest `/verify` if untested, then stop. That is the entire post-work protocol. No git prompts. No shipping suggestions.
 
 ## Know when to stop and ask