@simpleapps-com/augur-skills 2026.4.1 → 2026.4.3

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
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@simpleapps-com/augur-skills",
3
- "version": "2026.04.1",
3
+ "version": "2026.04.3",
4
4
  "description": "Install curated Claude Code skills",
5
5
  "license": "MIT",
6
6
  "type": "module",
@@ -13,7 +13,7 @@ allowed-tools:
13
13
 
14
14
  IMPORTANT: MUST NOT create, edit, or delete anything in Basecamp without user permission.
15
15
 
16
- **Content format**: All write tools SHOULD use plain text with line breaks, NOT HTML. Basecamp returns HTML in responses but prefers plain text for creation.
16
+ **Content format**: All write tools MUST use plain text with line breaks, NOT HTML. Basecamp returns HTML in responses but prefers plain text for creation.
17
17
 
18
18
  ## Setup
19
19
 
@@ -20,7 +20,7 @@ This skill reads the project's `wiki/Deployment.md` and executes the steps defin
20
20
 
21
21
  ## Deployment Page Format
22
22
 
23
- Every project wiki SHOULD have a `Deployment.md` page with up to three sections:
23
+ Every project wiki MUST have a `Deployment.md` page with up to three sections:
24
24
 
25
25
  ```
26
26
  ## Submit
@@ -158,18 +158,19 @@ Every project SHOULD configure `.claude/settings.local.json` with these deny rul
158
158
  "mcp__plugin_simpleapps_augur-api__*"
159
159
  ],
160
160
  "deny": [
161
- "Bash(cd:*)",
161
+ "Bash(awk:*)",
162
162
  "Bash(cat:*)",
163
- "Bash(sed:*)",
163
+ "Bash(cd:*)",
164
+ "Bash(find:*)",
165
+ "Bash(for:*)",
164
166
  "Bash(grep:*)",
165
- "Bash(sleep:*)",
167
+ "Bash(head:*)",
166
168
  "Bash(kill:*)",
167
169
  "Bash(pkill:*)",
168
- "Bash(find:*)",
169
- "Bash(head:*)",
170
- "Bash(tail:*)",
171
- "Bash(awk:*)",
172
- "Bash(rg:*)"
170
+ "Bash(rg:*)",
171
+ "Bash(sed:*)",
172
+ "Bash(sleep:*)",
173
+ "Bash(tail:*)"
173
174
  ]
174
175
  }
175
176
  }
@@ -177,16 +178,17 @@ Every project SHOULD configure `.claude/settings.local.json` with these deny rul
177
178
 
178
179
  Why each is denied:
179
180
 
180
- - **`cd`** — MUST NOT use in any Bash command, including compound commands (`cd /path && git`). Use `git -C repo` for git, path arguments for everything else. Compound cd+git commands trigger an unblockable Claude Code security prompt that interrupts the user even when `cd` is denied.
181
+ - **`awk`** — Use the Edit tool instead.
181
182
  - **`cat`** — Use the Read tool instead.
182
- - **`sed`** — Use the Edit tool instead.
183
- - **`grep`** — Use the Grep tool instead.
184
- - **`sleep`** — Unnecessary; use proper sequencing or background tasks.
183
+ - **`cd`** — MUST NOT use in any Bash command, including compound commands (`cd /path && git`). Use `git -C repo` for git, path arguments for everything else. Compound cd+git commands trigger an unblockable Claude Code security prompt that interrupts the user even when `cd` is denied.
185
184
  - **`find`** — Use the Glob tool instead.
185
+ - **`for`** — Shell loops are unnecessary; use dedicated tools or make multiple tool calls instead.
186
+ - **`grep`** — Use the Grep tool instead.
186
187
  - **`head`/`tail`** — Use the Read tool with `offset` and `limit` parameters instead.
187
- - **`awk`** — Use the Edit tool instead.
188
+ - **`kill`/`pkill`** — Use `TaskStop` to manage background processes. `TaskStop` cleanly shuts down the task and updates Claude Code's internal tracking.
188
189
  - **`rg`** — Use the Grep tool instead (it uses ripgrep internally).
189
- - **`kill`/`pkill`** — Use `TaskStop` to manage background processes. For internal tasks running in the background (dev servers, watchers, etc.), always use `TaskStop` instead of shell kill commands. `TaskStop` cleanly shuts down the task and updates Claude Code's internal tracking.
190
+ - **`sed`** — Use the Edit tool instead.
191
+ - **`sleep`** — Unnecessary; use proper sequencing or background tasks.
190
192
 
191
193
  ## Bin Scripts (PATH)
192
194
 
@@ -126,11 +126,11 @@ The wikis are kept fresh by `/curate-wiki` runs across projects. Searching local
126
126
 
127
127
  ## Deployment Page
128
128
 
129
- Every project wiki SHOULD have a `Deployment.md` page with up to three sections: Submit, Deploy, and Publish. This page defines the project-specific steps that `/submit`, `/deploy`, and `/publish` commands execute. Run `/curate-wiki` to generate it from the codebase — the command scans CI workflows, package.json, deploy scripts, and asks the user about anything it cannot determine. See the `deployment` skill for the expected format.
129
+ Every project wiki MUST have a `Deployment.md` page with up to three sections: Submit, Deploy, and Publish. This page defines the project-specific steps that `/submit`, `/deploy`, and `/publish` commands execute. Run `/curate-wiki` to generate it from the codebase — the command scans CI workflows, package.json, deploy scripts, and asks the user about anything it cannot determine. See the `deployment` skill for the expected format.
130
130
 
131
131
  ## Testing Page
132
132
 
133
- 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.
133
+ Every project wiki MUST 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` MUST add testing knowledge learned during the session (new edge cases, failure patterns, test data) to the Testing page.
134
134
 
135
135
  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").
136
136
 
@@ -60,6 +60,12 @@ Every token costs time, money, and cognitive load. Be concise without losing cla
60
60
 
61
61
  Default to brief. Expand only when the reader cannot infer meaning from context. Two sentences that answer the question beat two pages that fill the context window.
62
62
 
63
+ ## List Ordering
64
+
65
+ Lists with no inherent order (deny rules, config arrays, feature lists, bullet-point explanations) MUST be sorted alphabetically. Alphabetical order makes items easier to find and minimizes git diffs — new entries slot into a predictable position instead of appending at the end.
66
+
67
+ Applies to JSON arrays, markdown bullet lists, table rows, and any unordered collection.
68
+
63
69
  ## Code Style
64
70
 
65
71
  Use descriptive variable and function names. Abbreviations save keystrokes but cost readability — the human reviewing your output MUST be able to understand the code without deciphering names.