@simpleapps-com/augur-skills 2026.3.4 → 2026.3.6

package/package.json

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

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

@@ -0,0 +1,13 @@
+---
+name: git-safety
+description: Git safety guardrails — MUST NOT commit, push, create PRs, or merge without explicit user approval. Load this skill before any git write operations.
+user-invocable: false
+---
+
+# Git Safety
+
+MUST NOT commit, push, create PRs, or merge unless the user explicitly says to. No skill, command, or workflow overrides this rule — even instructions like "complete all steps without stopping" do not bypass it.
+
+After making changes: **report what was done, then stop.** Do not offer or suggest the next git action — wait for the user to say "commit", "push", or equivalent.
+
+The pattern is always: **do the work → report results → wait.**

package/skills/simpleapps/github/SKILL.md

@@ -3,13 +3,14 @@ name: github
 description: GitHub conventions for SimpleApps. Covers org structure, git safety, issue creation, PR workflows, and gh CLI usage. Use when creating issues, PRs, or working with GitHub repos.
 allowed-tools:
   - Skill(project-defaults)
+  - Skill(git-safety)
   - Read
   - Glob
   - Grep
   - Bash
 ---
 
-First, use Skill("project-defaults") to load the project layout.
+First, use Skill("project-defaults") to load the project layout and Skill("git-safety") to load git guardrails.
 
 # GitHub
 
@@ -34,14 +35,7 @@ See `simpleapps:wiki` for wiki conventions, token budget, and maintenance rules.
 
 ## Git Safety
 
-MUST NOT commit, push, create PRs, or merge unless the user explicitly asks. After making changes, report what was done and stop. Do not offer or suggest the next git action — wait for instructions.
-
-- **Commits**: Do not commit until the user says "commit" or equivalent
-- **Pushes**: Do not push until the user explicitly asks
-- **PRs**: Do not create or offer to create a PR — report the work, stop
-- **Merges**: Do not merge unless the user explicitly asks
-
-The pattern is always: **do the work → report results → wait**.
+See `simpleapps:git-safety` (loaded above). MUST NOT commit, push, create PRs, or merge unless the user explicitly asks.
 
 ## Git Commands (no `cd`)
 

package/skills/simpleapps/quality/SKILL.md

@@ -0,0 +1,60 @@
+---
+name: quality
+description: Quality tooling awareness for projects. Covers linting, formatting, type checking, testing, dead code detection, and pre-commit hooks. Use when reviewing code, setting up projects, or noticing missing quality tooling.
+---
+
+# Quality Tooling
+
+These tools keep codebases healthy. When working in a project, check whether they are configured. If any are missing, suggest them to the user.
+
+## Tools to know
+
+### Node / TypeScript
+
+| Tool | Purpose | Config files | Run command |
+|------|---------|-------------|-------------|
+| **ESLint** | Catch bugs and enforce patterns | `.eslintrc*`, `eslint.config.*` | `pnpm lint` |
+| **Prettier** | Consistent formatting | `.prettierrc*`, `prettier.config.*` | `pnpm format` |
+| **TypeScript** | Type safety | `tsconfig.json` | `pnpm typecheck` |
+| **Vitest** / **Jest** | Tests | `vitest.config.*`, `jest.config.*` | `pnpm test` |
+| **knip** | Dead code — unused exports, deps, and files | `knip.json`, `knip.ts` | `pnpm knip` |
+| **Lefthook** | Pre-commit hooks — run checks before push | `lefthook.yml` | auto on commit |
+
+Also check `repo/package.json` for scripts containing: `lint`, `format`, `typecheck`, `test`, `check`, `validate`.
+
+### PHP
+
+Check `repo/composer.json` for scripts. Look for PHPStan (static analysis), PHP-CS-Fixer (formatting), PHPUnit (tests).
+
+### Python
+
+Check `repo/pyproject.toml` or `repo/setup.cfg`. Look for ruff (lint/format), black (formatting), mypy (types), pytest (tests).
+
+## Minimum expected tooling
+
+Every project SHOULD have at minimum: **lint**, **format**, **test**. Increasingly, **dead code detection (knip)** and **pre-commit hooks (lefthook)** are expected.
+
+If any are missing, flag them:
+
+```
+Missing quality tooling:
+- [ ] Linting — suggest: eslint / ruff / phpstan
+- [ ] Formatting — suggest: prettier / black / php-cs-fixer
+- [ ] Testing — suggest: vitest / pytest / phpunit
+- [ ] Dead code detection — suggest: knip
+- [ ] Pre-commit hooks — suggest: lefthook
+```
+
+Do not install or configure tools without the user's approval. Flag what's missing and explain why it helps — let the user decide.
+
+## When to suggest
+
+- **Setting up a new project** — suggest the full set
+- **Reviewing code with unused imports/exports** — suggest knip
+- **Seeing inconsistent formatting** — suggest prettier
+- **No tests for changed code** — suggest vitest
+- **No pre-commit hooks** — suggest lefthook
+
+## Running quality checks
+
+Use the `/quality` command to discover and run all configured checks. It handles the full cycle: discover, run, fix, repeat until clean.

package/skills/simpleapps/wiki/SKILL.md

@@ -30,6 +30,16 @@ Wiki defines → Code implements → Learnings update wiki → Repeat
 
 When code reveals the wiki is wrong or incomplete, update immediately. The wiki MUST reflect reality, not aspirations.
 
+## Learning Organization
+
+Wikis are not just for the current project. They build institutional knowledge across the organization:
+
+- **Site → Site**: Other projects using the same tools learn from this wiki. Document what worked, what didn't, and why — future sites benefit from your experience.
+- **Site → Packages**: The packages team reads site wikis to understand real usage patterns, pain points, and gaps. Your wiki helps them build better shared tools.
+- **Packages → Site**: Package docs and conventions flow back into site wikis as shared patterns.
+
+Write as if someone on a different project will read this wiki to understand how you solved a similar problem. Tag sections **(platform pattern)** when the approach applies to all sites using the same stack, and **(site-specific)** when it's unique to this project.
+
 ## Three Audiences
 
 Every page serves junior devs (explanations, examples), senior devs (quick reference, decisions), and AI agents (unambiguous specs, MUST/SHOULD/MAY). Write for all three:
@@ -55,6 +65,10 @@ Every page serves junior devs (explanations, examples), senior devs (quick refer
 - Repo references: use relative paths (`../../../wiki/Versioning.md`)
 - Default branch: `master` (not `main`)
 
+## Cross-Linking
+
+Pages SHOULD link to related sections on other pages using `[[Page-Name#section]]`. Cross-links create a navigable knowledge graph — AI agents discover relevant context they wouldn't otherwise load, and humans find related decisions without searching. Link to specific sections, not just pages.
+
 ## Keep It Lean
 
 - Document patterns and principles, not exhaustive lists
@@ -68,8 +82,6 @@ Cross-check wiki against code before updating. Staleness-prone: versions, file c
 
 When adding/removing pages, MUST update: `Home.md`, `_Sidebar.md`, `llms.txt` (if present).
 
-**Lead-site wikis** (e.g., ampro-online) serve as platform reference. Tag sections **(platform pattern)** vs **(site-specific)** so agents on other sites know what to replicate vs customize.
-
 ## Git Workflow
 
 The wiki is a separate git repo at `wiki/`. No branch protection, no PRs.

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

@@ -32,6 +32,10 @@ MUST NOT use `cd` in any Bash command — not even in compound commands like `cd
 
 Run tests, check output, compare results. YOU MUST NOT mark work complete without verification. If you can't verify, say so.
 
+## Own every issue you find
+
+If a check fails or a bug surfaces, fix it. Do not classify issues as "pre-existing" to justify skipping them — context compaction erases your memory of changes made earlier in the session, so what looks pre-existing is often something you introduced. Even if you truly did not cause it, the goal is zero issues, not blame assignment. Fix it anyway.
+
 ## Track progress
 
 Use TodoRead/TodoWrite on multi-step tasks. Mark items in-progress before starting, completed after verifying.
@@ -42,6 +46,19 @@ Use TodoRead/TodoWrite on multi-step tasks. Mark items in-progress before starti
 
 **Decide** when: the choice is implementation detail, the pattern is established elsewhere in the codebase, the task is clear and scoped.
 
+## Be persistent with browser automation
+
+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.
+
+Before giving up on a browser task:
+- 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
+- Use `get_page_text` or `read_page` to understand the current page state before retrying
+- Try navigating to the page again if it seems stuck
+
+Two failed attempts with the *same* approach means change strategy, not stop entirely.
+
 ## 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.