@simpleapps-com/augur-skills 2026.3.26 → 2026.3.28

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@simpleapps-com/augur-skills",
-  "version": "2026.03.26",
+  "version": "2026.03.28",
   "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/project-defaults/SKILL.md

@@ -51,11 +51,13 @@ The parent `{project}/` is NOT a git repo — it keeps code and wiki side-by-sid
 | Repo `.claude/rules/` | `repo/` | Minimal summaries referencing wiki |
 | Repo `.claude/CLAUDE.md` | `repo/` | Quick reference + wiki links |
 | Active task context | `wip/` | `{issue-number}-{short-desc}.md` files |
-| Temporary files | `tmp/` | Throwaway files, scratch space, build artifacts |
+| Temporary files | `tmp/` | Scratch space — commit msgs, PR bodies, intermediate output. Full access. |
 | SimpleApps config | `.simpleapps/` | Settings, site profile, credentials (see below) |
 
 **WIP**: Research, plans, decisions, test results. MUST NOT contain secrets, final docs, or code.
 
+**tmp/**: Fully available for scratch work — commit messages, PR bodies, issue comments, intermediate output, and any throwaway files. Read, write, and delete freely without asking. Create the folder if missing. Clean up files after use.
+
 ## Plugin Rules
 
 The plugin ships rule templates in `plugins/simpleapps/rules/` that MUST exist in every project's `repo/.claude/rules/`. Rules are always loaded into context — they enforce baseline guardrails (like git safety) without depending on a skill being invoked. The `/project-init` command copies missing rules from the plugin into the project.

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

@@ -21,6 +21,10 @@ Reserve Bash for commands that have no dedicated tool equivalent.
 
 MUST NOT use `cd` in any Bash command — not even in compound commands like `cd /path && git log`. Use `git -C repo` for git, and path arguments for everything else. The `cd` deny rule does not suppress Claude Code's built-in security prompt for compound cd+git commands, so any `cd` usage will interrupt the user.
 
+## Check site.json first
+
+Before asking the user for credentials, tokens, siteId, domain, or any site-specific configuration, read `.simpleapps/site.json`. It is the single source of truth for site-level data — credentials, auth tokens, defaults, and identifiers. If what you need is not there, ask the user to add it to `site.json` rather than providing it in chat (chat data is ephemeral; `site.json` persists across sessions).
+
 ## Read the error first
 
 When debugging in the browser, MUST check for error overlays (red error pill/badge at the bottom of the page) before guessing at the problem. Click it, read the full error, stack trace, and source location. The answer is almost always right there.
@@ -58,7 +62,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 +74,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.