@simpleapps-com/augur-skills 2026.3.25 → 2026.3.27

package/package.json

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

package/skills/simpleapps/bash-simplicity/SKILL.md

@@ -60,6 +60,18 @@ These commands are **denied** in project settings and will always be rejected
 
 MUST NOT use `node -e` or `python -c` to run inline scripts — these trigger permission prompts. If you need to read a file, use the Read tool. If you need to process data, do it in your response, not in a shell script.
 
+## Background Tasks
+
+When you start a background task with `run_in_background`, you receive a task ID. That ID is how you manage the task later:
+
+- **Stop it**: use `TaskStop` with the task ID
+- **Check output**: use `TaskGet` or `Read` on the output file
+- **List running tasks**: use `TaskList`
+
+MUST NOT use `kill` or `pkill` to stop background tasks — these are denied and will fail. Use `TaskStop` instead — it cleanly shuts down the process and updates internal tracking.
+
+If a process was started **outside your session** (by the user in a terminal), you cannot stop it with `TaskStop`. Ask the user to restart or stop it themselves.
+
 ## Cross-Project Searching
 
 When looking at another project's code, use dedicated tools with the project path — MUST NOT use shell commands:

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

@@ -33,6 +33,8 @@ Each approval covers ONE specific operation. Examples:
 - The user runs `/submit` → you may execute the Submit steps (commit + push or PR). You may NOT also tag or publish.
 - The user runs `/publish` → you may execute the Publish steps (bump, commit, tag, push). This does NOT carry forward to future commits.
 
+Approval for one repo does NOT extend to another. Approval to commit/push the wiki does NOT grant approval to commit/push the main repo, and vice versa. Each repo requires its own explicit approval.
+
 Previous approvals do NOT grant future permissions. If the user approved a commit earlier in the session, that does not mean you can commit again later without asking.
 
 ### When /submit follows earlier work

package/skills/simpleapps/quality/SKILL.md

@@ -55,9 +55,11 @@ 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
 
-## Every failure is your problem
+## Own your scope
 
-There is no such thing as a "pre-existing issue." If a check fails, fix it immediately. Do not skip it, do not classify it as "not from our changes", do not continue to the next check hoping someone else will fix it later. Context compaction erases your memory of earlier changes — what looks pre-existing may be something you introduced. Even if you truly did not cause it, fix it anyway. The goal is zero issues.
+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.
 
 ## Resolve, never hide
 

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

@@ -58,7 +58,10 @@ MUST NOT ask "want me to commit?", "should I submit?", or any variation after co
 
 When using Chrome tools, do not give up after the first failure. Pages are dynamic — elements may not be visible yet, selectors may need adjusting, or the page may need time to load.
 
+Accessibility features make sites machine-readable — the same semantic HTML, ARIA labels, landmark roles, and alt text that help screen reader users also help you navigate pages during Chrome automation. When looking for elements, prefer ARIA roles and labels over brittle CSS selectors. When reviewing or writing frontend code, strong accessibility is not just a user concern — it directly improves your ability to automate and verify the site, and search engines benefit from the same semantic signals.
+
 Before giving up on a browser task:
+- Look for ARIA labels, roles, and semantic elements first — they are the most reliable selectors
 - Try a different selector or approach (text search, CSS selector, coordinates)
 - Scroll to reveal elements that may be off-screen
 - Wait for the page to finish loading, then retry
@@ -67,6 +70,12 @@ Before giving up on a browser task:
 
 Two failed attempts with the *same* approach means change strategy, not stop entirely.
 
+## Good enough is done
+
+Working code that meets the requirements is good enough — ship it. Do not chase diminishing returns by over-polishing, refactoring working code, or improving what already works. The cost of continued refinement exceeds its value. Stop when the task is done, not when you run out of improvements to make.
+
+The distinction: polishing task-specific code is local optimization — it makes one site marginally better but does not move the system forward. Extracting custom code into shared packages removes a system constraint — every site that would have reimplemented the same thing benefits. Local optimization is waste. Removing system constraints compounds. Flag extraction opportunities per "Improve the system" below, but do not polish the task code itself.
+
 ## Recover from mistakes
 
 Wrong approach? Stop, revert, try differently. Do not keep layering fixes on a broken foundation. Two failed attempts at the same approach = change strategy.

package/skills/simpleapps/workflow/SKILL.md

@@ -69,7 +69,7 @@ gh issue create --repo simpleapps-com/<repo> \
 The full workflow from task to delivery, each step feeding the next:
 
 ```
-/triage → /wip → /investigate → /discuss → /implement → /quality → /verify → /submit → /deploy → /publish
+/triage → /wip → /investigate → /discuss → /implement → /quality → /sanity-check → /verify → /submit → /deploy → /publish
 ```
 
 | Phase | Command | What happens |
@@ -80,6 +80,7 @@ The full workflow from task to delivery, each step feeding the next:
 | Align | `/discuss` | Conversational alignment before acting |
 | Build | `/implement` | Execute the plan — code changes only, no commits |
 | Code checks | `/quality` | Lint, typecheck, test, package freshness |
+| Solution audit | `/sanity-check` | Did we solve the right problem without commission/omission errors? |
 | Browser checks | `/verify` | Walk through wiki's Testing.md checklist in Chrome |
 | Submit | `/submit` | Commit and create a PR for review |
 | Stage | `/deploy` | Deploy to staging (merge PRs, trigger staging build) |