@simpleapps-com/augur-skills 2026.3.24 → 2026.3.26

package/package.json

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

package/skills/simpleapps/augur-packages/SKILL.md

@@ -9,6 +9,12 @@ allowed-tools:
 
 # Augur Packages
 
+## Custom code is a liability. Shared code is an asset.
+
+Every line of custom site code carries maintenance cost — it must be understood, tested, and updated by whoever touches it next. Shared packages are the opposite: maintained once, benefiting every site. When you write custom code that a package already handles, you are adding a liability. When you adopt a package export, you are removing one.
+
+This means: always prefer package solutions over custom code. When no package solution exists but the code would benefit other sites, suggest it as a package addition. The goal is to shrink the liability (custom code) and grow the asset (shared packages) over time.
+
 Shared npm packages for Next.js ecommerce sites and React Native apps. Published to npm under `@simpleapps-com`. Source: `simpleapps-com/augur-packages`.
 
 Before writing custom code, check whether a package export already solves the problem.

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

@@ -146,7 +146,9 @@ Every project SHOULD configure `.claude/settings.local.json` with these deny rul
       "Bash(which:*)",
       "Bash(basename:*)",
       "Bash(dirname:*)",
-      "Bash(pwd:*)"
+      "Bash(pwd:*)",
+      "Bash(lsof:*)",
+      "mcp__plugin_simpleapps_augur-api__*"
     ],
     "deny": [
       "Bash(cd:*)",

package/skills/simpleapps/quality/SKILL.md

@@ -55,6 +55,10 @@ 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
+
+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.
+
 ## Resolve, never hide
 
 When a check fails, the solution is ALWAYS to fix the underlying code. NEVER:

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

@@ -44,6 +44,10 @@ If a check fails or a bug surfaces, fix it. Do not classify issues as "pre-exist
 
 Use TodoRead/TodoWrite on multi-step tasks. Mark items in-progress before starting, completed after verifying.
 
+## 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.
+
 ## Know when to stop and ask
 
 **Ask** when: requirements are ambiguous, multiple valid approaches exist, an action is destructive or irreversible, you've failed the same approach twice.
@@ -66,3 +70,9 @@ Two failed attempts with the *same* approach means change strategy, not stop ent
 ## 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.
+
+## Improve the system, not just the output
+
+Removing daily work is more important than doing daily work. While completing a task, notice friction: unnecessary manual steps, repeated patterns that could be shared, error-prone processes that could be automated, custom code that duplicates a package export. When you spot these, flag them — suggest a package addition, a script, a skill improvement, or a workflow change. The value of eliminating a step that runs every day far exceeds the value of completing it one more time.
+
+This is not scope creep on the code. "Do exactly what was asked" still applies to the task. But improving the system the task runs in — making skills clearer, workflows smoother, shared code more complete — is always in scope. File an issue, update a skill, or mention it in your report.

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) |