@simpleapps-com/augur-skills 2026.3.16 → 2026.3.18

package/package.json

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

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

@@ -8,24 +8,38 @@ user-invocable: false
 
 ## Why This Matters
 
-Every permission prompt makes the user the bottleneck. If the user doesn't see the prompt for an hour, that hour is lost — the agent is blocked, the task stalls, and the system designed for autonomous work stops working. The entire plugin system exists to remove the user as the bottleneck. A permission prompt works directly against that goal. Use dedicated tools and simple commands to avoid ever triggering one.
+A complex command feels efficient — do more in one call. But the more complex the command, the higher the probability it triggers a permission prompt. A permission prompt blocks the agent until the user responds. If the user doesn't see it for an hour, that hour is lost.
 
-## One Command Per Call
+**Simple commands are faster than complex ones because they never wait for a human.** Ten simple commands that execute instantly are faster than one complex command that waits an hour for approval. The agent's goal is to complete work — a blocked prompt completes nothing.
 
-MUST run each Bash command as a separate, simple call. MUST NOT chain commands with `&&`, `||`, pipes, or sub-shells. Complex commands trigger permission prompts and break automation.
+The entire plugin system exists to remove the user as the bottleneck. Every permission prompt puts them back in the critical path.
 
-Wrong: `git -C repo status && pnpm typecheck && pnpm test`
-Right: Three separate Bash calls, one per command.
+**Three tiers of execution speed — always use the highest tier available:**
 
-Wrong: `pnpm --filter <site> run typecheck 2>&1; echo "EXIT: $?"`
-Right: `pnpm --filter <site> run typecheck` — the Bash tool already captures stderr and exit codes. Never add `2>&1`, `; echo $?`, or other shell plumbing — it triggers permission prompts for no benefit.
+| Tier | Method | Speed | Example |
+|------|--------|-------|---------|
+| 1 | Dedicated tools (Read, Grep, Glob, Edit) | **WILL** run immediately, zero permission chance | `Grep(pattern: "...", path: "repo")` |
+| 2 | Simple Bash (one command, no operators) | **MAY** run immediately if pre-approved | `pnpm typecheck` |
+| 3 | Complex Bash (operators, plumbing) | **WILL** trigger a permission prompt | `pnpm typecheck 2>&1; echo $?` |
 
-Wrong: `gh issue close 367 --repo org/repo --comment "$(< tmp/file.txt)" 2>&1`
-Right: Write the comment to a tmp file, then use two separate calls:
-1. `gh issue comment 367 --repo org/repo --body-file tmp/file.txt`
-2. `gh issue close 367 --repo org/repo`
+Prefer tier 1 over tier 2. Use tier 2 only when no dedicated tool exists. NEVER use tier 3.
 
-MUST NOT use `$()` command substitution in Bash commands — it triggers a permission prompt every time. Write content to a tmp file first, then pass it with a `-F`, `--body-file`, or similar flag.
+## The Bash Tool Is Not a Terminal
+
+The Bash tool is a managed environment, not a raw shell. It already captures stdout, stderr, and the exit code automatically. There is NEVER a reason to add shell plumbing — every shell operator triggers a permission prompt that blocks the user for zero benefit.
+
+**If the Bash tool already does it, do not do it yourself:**
+
+| You want to... | The tool already does it | Do NOT add |
+|----------------|------------------------|------------|
+| Get the exit code | Returned automatically | `; echo $?`, `; echo "Exit code: $?"` |
+| Capture stderr | Captured automatically | `2>&1`, `2>/dev/null` |
+| Limit output | Returned in full | `\| head`, `\| tail`, `\| grep` |
+| Run the next step | Make a separate tool call | `&&`, `;`, `\|\|` |
+| Pass output to another command | Write to a tmp file | `$(...)`, backticks |
+| Run inline code | Use Read/Grep/Edit tools | `node -e`, `python -c` |
+
+**One command per Bash call. No operators. No plumbing. If the command has a `;`, `&&`, `|`, `$()`, `2>&1`, or `2>/dev/null` in it — it is wrong.**
 
 ## Use Dedicated Tools
 

package/skills/simpleapps/wiki/SKILL.md

@@ -105,6 +105,31 @@ All projects follow the same directory layout (see `simpleapps:project-defaults`
 
 MUST NOT use `find`, `grep`, `cat`, `ls`, or any shell command to explore other projects. The paths are known — use the dedicated tools directly.
 
+### Search all wikis
+
+Every wiki on the machine is a local knowledge base. When looking for how something was solved, search across ALL wikis — not just the current project:
+
+1. Read `~/.simpleapps/settings.json` to get `projectRoot`
+2. Pull the latest for all wikis before searching:
+   - `git -C {projectRoot}/clients/*/wiki pull` (one call per wiki, not a glob)
+   - `git -C {projectRoot}/simpleapps/*/wiki pull`
+3. Search across all wikis with Grep:
+   - `Grep(pattern: "...", path: "{projectRoot}/clients", glob: "*/wiki/*.md")`
+   - `Grep(pattern: "...", path: "{projectRoot}/simpleapps", glob: "*/wiki/*.md")`
+4. Read the matching pages to get the full context
+
+Use Glob to discover which projects have wikis: `Glob(pattern: "{projectRoot}/clients/*/wiki")` and `Glob(pattern: "{projectRoot}/simpleapps/*/wiki")`.
+
+The wikis are kept fresh by `/curate-wiki` runs across projects. Searching locally is instant and requires no internet access — the knowledge is already on the machine.
+
+**What to search for:** testing patterns and checklists, architecture decisions, coding conventions, deployment procedures, and how specific features were implemented. Other sites have already solved many of the same problems — search before building from scratch.
+
+## 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.
+
+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").
+
 ## Keep It Lean
 
 - Document patterns and principles, not exhaustive lists

package/skills/simpleapps/workflow/SKILL.md

@@ -64,6 +64,29 @@ gh issue create --repo simpleapps-com/<repo> \
 - Include the Basecamp todo URL in the GitHub issue body (under a `## Basecamp` heading)
 - After creating the issue, provide the GitHub issue URL to the user so they can add it to the Basecamp todo comments
 
+## Development Lifecycle
+
+The full workflow from task to delivery, each step feeding the next:
+
+```
+/triage → /wip → /investigate → /discuss → /implement → /quality → /verify → /curate-wiki
+```
+
+| Phase | Command | What happens |
+|-------|---------|-------------|
+| Pick work | `/triage` | See open PRs and unlinked issues |
+| Scaffold | `/wip` | Create a WIP file from Basecamp or GitHub issue |
+| Research | `/investigate` | Explore codebase, update WIP with findings |
+| Align | `/discuss` | Conversational alignment before acting |
+| Build | `/implement` | Execute the plan — code changes only, no commits |
+| Code checks | `/quality` | Lint, typecheck, test, package freshness |
+| Browser checks | `/verify` | Walk through wiki's Testing.md checklist in Chrome |
+| Capture | `/curate-wiki` | Update wiki with session learnings, audit CLAUDE.md/rules |
+
+**Key principle:** each session generates knowledge. `/curate-wiki` captures it — including new testing patterns, edge cases, and failure modes discovered during `/implement` and `/verify`. This grows the wiki's Testing.md page over time, making future `/verify` runs more thorough. This is the learning organization in action.
+
+Commands like `/research` and `/discuss` can be used at any stage. `/quality`, `/verify`, `/curate-wiki`, and `/wiki-audit` can run independently.
+
 ## References
 
 - See `simpleapps:basecamp` skill for MCP tools, Chrome fallback, and Basecamp navigation