@simpleapps-com/augur-skills 2026.3.3 → 2026.3.5

package/package.json

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

package/skills/simpleapps/github/SKILL.md

@@ -100,6 +100,29 @@ gh issue close <number> --repo simpleapps-com/<repo> --comment "message"
 
 Include `Closes #N` in commit body to auto-close issues.
 
+### Commenting on existing issues
+
+Before adding a comment to a closed issue, check its state first with `gh issue view`. If the issue is closed but the problem still exists, reopen it with `gh issue reopen` before commenting — a comment on a closed issue is easily missed.
+
+## Cross-Repo Issues
+
+When a project hits a blocker that depends on another team's repo, create two issues and keep working:
+
+1. **Local issue** (in the site/project repo) — describe the impact and what's blocked
+2. **Upstream issue** (in the dependency repo) — describe the ask, include reproduction steps or specifics
+3. **Cross-link** — reference the other issue using `simpleapps-com/repo#N` syntax in both issue bodies
+4. **Don't block** — continue with other tasks while waiting for the upstream fix
+
+Target repos:
+
+| Dependency | Repo |
+|------------|------|
+| Backend microservices | `simpleapps-com/augur` |
+| Shared frontend packages | `simpleapps-com/augur-packages` |
+| TypeScript API SDK | `simpleapps-com/augur-api` |
+
+Example cross-link in issue body: `Upstream: simpleapps-com/augur#44` or `Local impact: simpleapps-com/spotweldingsupplies#3`
+
 ## Pull Requests
 
 ```bash

package/skills/simpleapps/project-defaults/SKILL.md

@@ -65,6 +65,7 @@ The repo contains `.claude/rules/` and `.claude/commands/` with project-specific
 
 ```bash
 mkdir -p {project}/.claude
+mkdir -p {project}/repo/.claude/rules {project}/repo/.claude/commands
 ln -sf ../repo/.claude/rules {project}/.claude/rules
 ln -sf ../repo/.claude/commands {project}/.claude/commands
 ```
@@ -136,6 +137,7 @@ mkdir {project} && cd {project}
 git clone https://github.com/simpleapps-com/<name>.git repo
 git clone https://github.com/simpleapps-com/<name>.wiki.git wiki
 mkdir -p wip tmp .simpleapps .claude
+mkdir -p repo/.claude/rules repo/.claude/commands
 ln -sf ../repo/.claude/rules .claude/rules
 ln -sf ../repo/.claude/commands .claude/commands
 ```

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:
@@ -68,8 +78,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.