@simpleapps-com/augur-skills 2026.3.22 → 2026.3.24
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
|
@@ -40,15 +40,21 @@ Not all projects need all three. Client sites may only have Submit and Deploy. P
|
|
|
40
40
|
1. Read `wiki/Deployment.md`
|
|
41
41
|
2. Find the section matching the requested action (Submit, Deploy, or Publish)
|
|
42
42
|
3. If the page or section is missing, **refuse to operate** — tell the user to run `/curate-wiki` to generate it
|
|
43
|
-
4. Execute the steps in that section
|
|
43
|
+
4. Execute the steps in that section
|
|
44
|
+
|
|
45
|
+
## Command approval model
|
|
46
|
+
|
|
47
|
+
The user invoking a command IS the approval to execute all its steps, including git writes. Do not stop to ask for confirmation mid-execution.
|
|
48
|
+
|
|
49
|
+
- `/submit` — execute all steps (commit, push, PR). Report at the end.
|
|
50
|
+
- `/deploy` — execute all steps. Report at the end.
|
|
51
|
+
- `/publish` — **EXCEPTION**: must complete the verification gate below and get secondary confirmation BEFORE executing any publish steps. This is the only command that pauses for approval.
|
|
44
52
|
|
|
45
53
|
## Guard Rails
|
|
46
54
|
|
|
47
55
|
- **If `wiki/Deployment.md` does not exist, STOP IMMEDIATELY.** Do not guess, do not improvise, do not infer steps from the codebase. Tell the user to run `/curate-wiki` to generate it. Then do nothing else.
|
|
48
56
|
- **If the relevant section (Submit, Deploy, or Publish) is missing from the page, STOP IMMEDIATELY.** Same rule — do not guess the steps.
|
|
49
57
|
- MUST NOT guess deployment steps — only execute what the wiki defines
|
|
50
|
-
- MUST load git-safety — every git write operation requires user approval
|
|
51
|
-
- `/publish` MUST complete the verification gate before executing (see below)
|
|
52
58
|
|
|
53
59
|
## Publish Verification Gate
|
|
54
60
|
|
|
@@ -57,9 +57,19 @@ Do not install or configure tools without the user's approval. Flag what's missi
|
|
|
57
57
|
|
|
58
58
|
## Resolve, never hide
|
|
59
59
|
|
|
60
|
-
When a check fails,
|
|
60
|
+
When a check fails, the solution is ALWAYS to fix the underlying code. NEVER:
|
|
61
61
|
|
|
62
|
-
|
|
62
|
+
- Disable or weaken a lint rule (`eslint-disable`, rule removal, config changes)
|
|
63
|
+
- Skip or delete a failing test (`.skip`, `.only`, deleting the test)
|
|
64
|
+
- Silence type errors (`@ts-ignore`, `@ts-expect-error`, `type: any`)
|
|
65
|
+
- Suppress warnings, lower coverage thresholds, or modify quality configs
|
|
66
|
+
- Add `--no-verify`, `--force`, or flags that bypass checks
|
|
67
|
+
|
|
68
|
+
These actions hide problems — they do not fix them. A suppressed error is worse than a visible one because it will be forgotten and compound.
|
|
69
|
+
|
|
70
|
+
If a rule or test seems wrong, investigate why it exists before concluding it should change. Rules exist for reasons. If after investigation it genuinely does not apply, explain the reasoning to the user and let them decide — do not unilaterally disable it.
|
|
71
|
+
|
|
72
|
+
When reviewing code, scan for existing suppressions (`eslint-disable`, `@ts-ignore`, `.skip`, `noqa`, `phpcs:ignore`, etc.) and flag every instance to the user. These are hidden technical debt.
|
|
63
73
|
|
|
64
74
|
## Browser Error Overlays
|
|
65
75
|
|