@simpleapps-com/augur-skills 2026.3.23 → 2026.3.25

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@simpleapps-com/augur-skills",
-  "version": "2026.03.23",
+  "version": "2026.03.25",
   "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/deployment/SKILL.md

@@ -40,15 +40,21 @@ Not all projects need all three. Client sites may only have Submit and Deploy. P
 1. Read `wiki/Deployment.md`
 2. Find the section matching the requested action (Submit, Deploy, or Publish)
 3. If the page or section is missing, **refuse to operate** — tell the user to run `/curate-wiki` to generate it
-4. Execute the steps in that section, respecting git-safety at every git write operation
+4. Execute the steps in that section
+
+## Command approval model
+
+The user invoking a command IS the approval to execute all its steps, including git writes. Do not stop to ask for confirmation mid-execution.
+
+- `/submit` — execute all steps (commit, push, PR). Report at the end.
+- `/deploy` — execute all steps. Report at the end.
+- `/publish` — **EXCEPTION**: must complete the verification gate below and get secondary confirmation BEFORE executing any publish steps. This is the only command that pauses for approval.
 
 ## Guard Rails
 
 - **If `wiki/Deployment.md` does not exist, STOP IMMEDIATELY.** Do not guess, do not improvise, do not infer steps from the codebase. Tell the user to run `/curate-wiki` to generate it. Then do nothing else.
 - **If the relevant section (Submit, Deploy, or Publish) is missing from the page, STOP IMMEDIATELY.** Same rule — do not guess the steps.
 - MUST NOT guess deployment steps — only execute what the wiki defines
-- MUST load git-safety — every git write operation requires user approval
-- `/publish` MUST complete the verification gate before executing (see below)
 
 ## Publish Verification Gate
 

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.