@simpleapps-com/augur-skills 2026.3.4 → 2026.3.5
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/package.json
CHANGED
|
@@ -0,0 +1,60 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: quality
|
|
3
|
+
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.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Quality Tooling
|
|
7
|
+
|
|
8
|
+
These tools keep codebases healthy. When working in a project, check whether they are configured. If any are missing, suggest them to the user.
|
|
9
|
+
|
|
10
|
+
## Tools to know
|
|
11
|
+
|
|
12
|
+
### Node / TypeScript
|
|
13
|
+
|
|
14
|
+
| Tool | Purpose | Config files | Run command |
|
|
15
|
+
|------|---------|-------------|-------------|
|
|
16
|
+
| **ESLint** | Catch bugs and enforce patterns | `.eslintrc*`, `eslint.config.*` | `pnpm lint` |
|
|
17
|
+
| **Prettier** | Consistent formatting | `.prettierrc*`, `prettier.config.*` | `pnpm format` |
|
|
18
|
+
| **TypeScript** | Type safety | `tsconfig.json` | `pnpm typecheck` |
|
|
19
|
+
| **Vitest** / **Jest** | Tests | `vitest.config.*`, `jest.config.*` | `pnpm test` |
|
|
20
|
+
| **knip** | Dead code — unused exports, deps, and files | `knip.json`, `knip.ts` | `pnpm knip` |
|
|
21
|
+
| **Lefthook** | Pre-commit hooks — run checks before push | `lefthook.yml` | auto on commit |
|
|
22
|
+
|
|
23
|
+
Also check `repo/package.json` for scripts containing: `lint`, `format`, `typecheck`, `test`, `check`, `validate`.
|
|
24
|
+
|
|
25
|
+
### PHP
|
|
26
|
+
|
|
27
|
+
Check `repo/composer.json` for scripts. Look for PHPStan (static analysis), PHP-CS-Fixer (formatting), PHPUnit (tests).
|
|
28
|
+
|
|
29
|
+
### Python
|
|
30
|
+
|
|
31
|
+
Check `repo/pyproject.toml` or `repo/setup.cfg`. Look for ruff (lint/format), black (formatting), mypy (types), pytest (tests).
|
|
32
|
+
|
|
33
|
+
## Minimum expected tooling
|
|
34
|
+
|
|
35
|
+
Every project SHOULD have at minimum: **lint**, **format**, **test**. Increasingly, **dead code detection (knip)** and **pre-commit hooks (lefthook)** are expected.
|
|
36
|
+
|
|
37
|
+
If any are missing, flag them:
|
|
38
|
+
|
|
39
|
+
```
|
|
40
|
+
Missing quality tooling:
|
|
41
|
+
- [ ] Linting — suggest: eslint / ruff / phpstan
|
|
42
|
+
- [ ] Formatting — suggest: prettier / black / php-cs-fixer
|
|
43
|
+
- [ ] Testing — suggest: vitest / pytest / phpunit
|
|
44
|
+
- [ ] Dead code detection — suggest: knip
|
|
45
|
+
- [ ] Pre-commit hooks — suggest: lefthook
|
|
46
|
+
```
|
|
47
|
+
|
|
48
|
+
Do not install or configure tools without the user's approval. Flag what's missing and explain why it helps — let the user decide.
|
|
49
|
+
|
|
50
|
+
## When to suggest
|
|
51
|
+
|
|
52
|
+
- **Setting up a new project** — suggest the full set
|
|
53
|
+
- **Reviewing code with unused imports/exports** — suggest knip
|
|
54
|
+
- **Seeing inconsistent formatting** — suggest prettier
|
|
55
|
+
- **No tests for changed code** — suggest vitest
|
|
56
|
+
- **No pre-commit hooks** — suggest lefthook
|
|
57
|
+
|
|
58
|
+
## Running quality checks
|
|
59
|
+
|
|
60
|
+
Use the `/quality` command to discover and run all configured checks. It handles the full cycle: discover, run, fix, repeat until clean.
|
|
@@ -30,6 +30,16 @@ Wiki defines → Code implements → Learnings update wiki → Repeat
|
|
|
30
30
|
|
|
31
31
|
When code reveals the wiki is wrong or incomplete, update immediately. The wiki MUST reflect reality, not aspirations.
|
|
32
32
|
|
|
33
|
+
## Learning Organization
|
|
34
|
+
|
|
35
|
+
Wikis are not just for the current project. They build institutional knowledge across the organization:
|
|
36
|
+
|
|
37
|
+
- **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.
|
|
38
|
+
- **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.
|
|
39
|
+
- **Packages → Site**: Package docs and conventions flow back into site wikis as shared patterns.
|
|
40
|
+
|
|
41
|
+
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.
|
|
42
|
+
|
|
33
43
|
## Three Audiences
|
|
34
44
|
|
|
35
45
|
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
|
|
|
68
78
|
|
|
69
79
|
When adding/removing pages, MUST update: `Home.md`, `_Sidebar.md`, `llms.txt` (if present).
|
|
70
80
|
|
|
71
|
-
**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.
|
|
72
|
-
|
|
73
81
|
## Git Workflow
|
|
74
82
|
|
|
75
83
|
The wiki is a separate git repo at `wiki/`. No branch protection, no PRs.
|
|
@@ -32,6 +32,10 @@ MUST NOT use `cd` in any Bash command — not even in compound commands like `cd
|
|
|
32
32
|
|
|
33
33
|
Run tests, check output, compare results. YOU MUST NOT mark work complete without verification. If you can't verify, say so.
|
|
34
34
|
|
|
35
|
+
## Own every issue you find
|
|
36
|
+
|
|
37
|
+
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.
|
|
38
|
+
|
|
35
39
|
## Track progress
|
|
36
40
|
|
|
37
41
|
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
|
|
|
42
46
|
|
|
43
47
|
**Decide** when: the choice is implementation detail, the pattern is established elsewhere in the codebase, the task is clear and scoped.
|
|
44
48
|
|
|
49
|
+
## Be persistent with browser automation
|
|
50
|
+
|
|
51
|
+
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.
|
|
52
|
+
|
|
53
|
+
Before giving up on a browser task:
|
|
54
|
+
- Try a different selector or approach (text search, CSS selector, coordinates)
|
|
55
|
+
- Scroll to reveal elements that may be off-screen
|
|
56
|
+
- Wait for the page to finish loading, then retry
|
|
57
|
+
- Use `get_page_text` or `read_page` to understand the current page state before retrying
|
|
58
|
+
- Try navigating to the page again if it seems stuck
|
|
59
|
+
|
|
60
|
+
Two failed attempts with the *same* approach means change strategy, not stop entirely.
|
|
61
|
+
|
|
45
62
|
## Recover from mistakes
|
|
46
63
|
|
|
47
64
|
Wrong approach? Stop, revert, try differently. Do not keep layering fixes on a broken foundation. Two failed attempts at the same approach = change strategy.
|