@simpleapps-com/augur-skills 2026.3.16 → 2026.3.17
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
|
@@ -105,6 +105,31 @@ All projects follow the same directory layout (see `simpleapps:project-defaults`
|
|
|
105
105
|
|
|
106
106
|
MUST NOT use `find`, `grep`, `cat`, `ls`, or any shell command to explore other projects. The paths are known — use the dedicated tools directly.
|
|
107
107
|
|
|
108
|
+
### Search all wikis
|
|
109
|
+
|
|
110
|
+
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:
|
|
111
|
+
|
|
112
|
+
1. Read `~/.simpleapps/settings.json` to get `projectRoot`
|
|
113
|
+
2. Pull the latest for all wikis before searching:
|
|
114
|
+
- `git -C {projectRoot}/clients/*/wiki pull` (one call per wiki, not a glob)
|
|
115
|
+
- `git -C {projectRoot}/simpleapps/*/wiki pull`
|
|
116
|
+
3. Search across all wikis with Grep:
|
|
117
|
+
- `Grep(pattern: "...", path: "{projectRoot}/clients", glob: "*/wiki/*.md")`
|
|
118
|
+
- `Grep(pattern: "...", path: "{projectRoot}/simpleapps", glob: "*/wiki/*.md")`
|
|
119
|
+
4. Read the matching pages to get the full context
|
|
120
|
+
|
|
121
|
+
Use Glob to discover which projects have wikis: `Glob(pattern: "{projectRoot}/clients/*/wiki")` and `Glob(pattern: "{projectRoot}/simpleapps/*/wiki")`.
|
|
122
|
+
|
|
123
|
+
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.
|
|
124
|
+
|
|
125
|
+
**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.
|
|
126
|
+
|
|
127
|
+
## Testing Page
|
|
128
|
+
|
|
129
|
+
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.
|
|
130
|
+
|
|
131
|
+
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").
|
|
132
|
+
|
|
108
133
|
## Keep It Lean
|
|
109
134
|
|
|
110
135
|
- Document patterns and principles, not exhaustive lists
|
|
@@ -64,6 +64,29 @@ gh issue create --repo simpleapps-com/<repo> \
|
|
|
64
64
|
- Include the Basecamp todo URL in the GitHub issue body (under a `## Basecamp` heading)
|
|
65
65
|
- After creating the issue, provide the GitHub issue URL to the user so they can add it to the Basecamp todo comments
|
|
66
66
|
|
|
67
|
+
## Development Lifecycle
|
|
68
|
+
|
|
69
|
+
The full workflow from task to delivery, each step feeding the next:
|
|
70
|
+
|
|
71
|
+
```
|
|
72
|
+
/triage → /wip → /investigate → /discuss → /implement → /quality → /verify → /curate-wiki
|
|
73
|
+
```
|
|
74
|
+
|
|
75
|
+
| Phase | Command | What happens |
|
|
76
|
+
|-------|---------|-------------|
|
|
77
|
+
| Pick work | `/triage` | See open PRs and unlinked issues |
|
|
78
|
+
| Scaffold | `/wip` | Create a WIP file from Basecamp or GitHub issue |
|
|
79
|
+
| Research | `/investigate` | Explore codebase, update WIP with findings |
|
|
80
|
+
| Align | `/discuss` | Conversational alignment before acting |
|
|
81
|
+
| Build | `/implement` | Execute the plan — code changes only, no commits |
|
|
82
|
+
| Code checks | `/quality` | Lint, typecheck, test, package freshness |
|
|
83
|
+
| Browser checks | `/verify` | Walk through wiki's Testing.md checklist in Chrome |
|
|
84
|
+
| Capture | `/curate-wiki` | Update wiki with session learnings, audit CLAUDE.md/rules |
|
|
85
|
+
|
|
86
|
+
**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.
|
|
87
|
+
|
|
88
|
+
Commands like `/research` and `/discuss` can be used at any stage. `/quality`, `/verify`, `/curate-wiki`, and `/wiki-audit` can run independently.
|
|
89
|
+
|
|
67
90
|
## References
|
|
68
91
|
|
|
69
92
|
- See `simpleapps:basecamp` skill for MCP tools, Chrome fallback, and Basecamp navigation
|