@simpleapps-com/augur-skills 2026.3.30 → 2026.4.2

package/package.json

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

package/skills/simpleapps/basecamp/SKILL.md

@@ -13,7 +13,7 @@ allowed-tools:
 
 IMPORTANT: MUST NOT create, edit, or delete anything in Basecamp without user permission.
 
-**Content format**: All write tools SHOULD use plain text with line breaks, NOT HTML. Basecamp returns HTML in responses but prefers plain text for creation.
+**Content format**: All write tools MUST use plain text with line breaks, NOT HTML. Basecamp returns HTML in responses but prefers plain text for creation.
 
 ## Setup
 

package/skills/simpleapps/deployment/SKILL.md

@@ -20,7 +20,7 @@ This skill reads the project's `wiki/Deployment.md` and executes the steps defin
 
 ## Deployment Page Format
 
-Every project wiki SHOULD have a `Deployment.md` page with up to three sections:
+Every project wiki MUST have a `Deployment.md` page with up to three sections:
 
 ```
 ## Submit

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

@@ -139,7 +139,8 @@ Every project SHOULD configure `.claude/settings.local.json` with these deny rul
 {
   "env": {
     "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1",
-    "CLAUDE_CODE_DISABLE_FEEDBACK_SURVEY": "1"
+    "CLAUDE_CODE_DISABLE_FEEDBACK_SURVEY": "1",
+    "CLAUDE_CODE_NO_FLICKER": "1"
   },
   "permissions": {
     "allow": [
@@ -157,18 +158,19 @@ Every project SHOULD configure `.claude/settings.local.json` with these deny rul
       "mcp__plugin_simpleapps_augur-api__*"
     ],
     "deny": [
-      "Bash(cd:*)",
+      "Bash(awk:*)",
       "Bash(cat:*)",
-      "Bash(sed:*)",
+      "Bash(cd:*)",
+      "Bash(find:*)",
+      "Bash(for:*)",
       "Bash(grep:*)",
-      "Bash(sleep:*)",
+      "Bash(head:*)",
       "Bash(kill:*)",
       "Bash(pkill:*)",
-      "Bash(find:*)",
-      "Bash(head:*)",
-      "Bash(tail:*)",
-      "Bash(awk:*)",
-      "Bash(rg:*)"
+      "Bash(rg:*)",
+      "Bash(sed:*)",
+      "Bash(sleep:*)",
+      "Bash(tail:*)"
     ]
   }
 }
@@ -176,16 +178,17 @@ Every project SHOULD configure `.claude/settings.local.json` with these deny rul
 
 Why each is denied:
 
-- **`cd`** — MUST NOT use in any Bash command, including compound commands (`cd /path && git`). Use `git -C repo` for git, path arguments for everything else. Compound cd+git commands trigger an unblockable Claude Code security prompt that interrupts the user even when `cd` is denied.
+- **`awk`** — Use the Edit tool instead.
 - **`cat`** — Use the Read tool instead.
-- **`sed`** — Use the Edit tool instead.
-- **`grep`** — Use the Grep tool instead.
-- **`sleep`** — Unnecessary; use proper sequencing or background tasks.
+- **`cd`** — MUST NOT use in any Bash command, including compound commands (`cd /path && git`). Use `git -C repo` for git, path arguments for everything else. Compound cd+git commands trigger an unblockable Claude Code security prompt that interrupts the user even when `cd` is denied.
 - **`find`** — Use the Glob tool instead.
+- **`for`** — Shell loops are unnecessary; use dedicated tools or make multiple tool calls instead.
+- **`grep`** — Use the Grep tool instead.
 - **`head`/`tail`** — Use the Read tool with `offset` and `limit` parameters instead.
-- **`awk`** — Use the Edit tool instead.
+- **`kill`/`pkill`** — Use `TaskStop` to manage background processes. `TaskStop` cleanly shuts down the task and updates Claude Code's internal tracking.
 - **`rg`** — Use the Grep tool instead (it uses ripgrep internally).
-- **`kill`/`pkill`** — Use `TaskStop` to manage background processes. For internal tasks running in the background (dev servers, watchers, etc.), always use `TaskStop` instead of shell kill commands. `TaskStop` cleanly shuts down the task and updates Claude Code's internal tracking.
+- **`sed`** — Use the Edit tool instead.
+- **`sleep`** — Unnecessary; use proper sequencing or background tasks.
 
 ## Bin Scripts (PATH)
 

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/wiki/SKILL.md

@@ -126,11 +126,11 @@ The wikis are kept fresh by `/curate-wiki` runs across projects. Searching local
 
 ## Deployment Page
 
-Every project wiki SHOULD have a `Deployment.md` page with up to three sections: Submit, Deploy, and Publish. This page defines the project-specific steps that `/submit`, `/deploy`, and `/publish` commands execute. Run `/curate-wiki` to generate it from the codebase — the command scans CI workflows, package.json, deploy scripts, and asks the user about anything it cannot determine. See the `deployment` skill for the expected format.
+Every project wiki MUST have a `Deployment.md` page with up to three sections: Submit, Deploy, and Publish. This page defines the project-specific steps that `/submit`, `/deploy`, and `/publish` commands execute. Run `/curate-wiki` to generate it from the codebase — the command scans CI workflows, package.json, deploy scripts, and asks the user about anything it cannot determine. See the `deployment` skill for the expected format.
 
 ## Testing Page
 
-Every project wiki SHOULD have a `Testing.md` page. This is the E2E verification checklist that `/verify` uses to walk through the site in Chrome. The page grows over time — `/curate-wiki` SHOULD add testing knowledge learned during the session (new edge cases, failure patterns, test data) to the Testing page.
+Every project wiki MUST have a `Testing.md` page. This is the E2E verification checklist that `/verify` uses to walk through the site in Chrome. The page grows over time — `/curate-wiki` MUST add testing knowledge learned during the session (new edge cases, failure patterns, test data) to the Testing page.
 
 A good Testing page covers: test tiers (automated vs manual), test data (items, accounts, cards), and an E2E checklist organized by page area (homepage, listing, detail, cart, checkout, etc.). Each checklist item is a concrete, verifiable condition — not vague ("works") but specific ("price shows $9.26").
 

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
 

package/skills/simpleapps/writing-style/SKILL.md

@@ -60,6 +60,12 @@ Every token costs time, money, and cognitive load. Be concise without losing cla
 
 Default to brief. Expand only when the reader cannot infer meaning from context. Two sentences that answer the question beat two pages that fill the context window.
 
+## List Ordering
+
+Lists with no inherent order (deny rules, config arrays, feature lists, bullet-point explanations) MUST be sorted alphabetically. Alphabetical order makes items easier to find and minimizes git diffs — new entries slot into a predictable position instead of appending at the end.
+
+Applies to JSON arrays, markdown bullet lists, table rows, and any unordered collection.
+
 ## Code Style
 
 Use descriptive variable and function names. Abbreviations save keystrokes but cost readability — the human reviewing your output MUST be able to understand the code without deciphering names.