@simpleapps-com/augur-skills 2026.4.13 → 2026.4.15
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
|
@@ -60,6 +60,18 @@ These commands are **denied** in project settings and will always be rejected. D
|
|
|
60
60
|
|
|
61
61
|
MUST NOT use `node -e` or `python -c` to run inline scripts. These trigger permission prompts. If you need to read a file, use the Read tool. If you need to process data, do it in your response, not in a shell script.
|
|
62
62
|
|
|
63
|
+
## When a Bash Command Is Denied
|
|
64
|
+
|
|
65
|
+
If a Bash call is denied, do NOT retry the same command and do NOT ask the user to approve it. Before anything else, check for a tool equivalent or shell plumbing that can be decomposed:
|
|
66
|
+
|
|
67
|
+
- `grep`/`rg` → Grep tool (for files on disk); for command output, the Bash tool already returned it — read what you have
|
|
68
|
+
- `find`/`ls` → Glob tool
|
|
69
|
+
- `cat`/`head`/`tail` → Read tool
|
|
70
|
+
- `sed`/`awk` → Edit tool
|
|
71
|
+
- `|`, `2>&1`, `&&`, `;`, `$()` → split into separate calls; the Bash tool already captures stdout, stderr, and exit code
|
|
72
|
+
|
|
73
|
+
Worked example: `pnpm --filter <package> typecheck 2>&1 | grep -c "error TS"` is denied because of the pipe to `grep`. The fix is to run `pnpm --filter <package> typecheck` alone — the Bash tool returns the full output and exit code — then count "error TS" occurrences in the returned output yourself. No grep, no redirection, no retry.
|
|
74
|
+
|
|
63
75
|
## Background Tasks
|
|
64
76
|
|
|
65
77
|
When you start a background task with `run_in_background`, you receive a task ID. That ID is how you manage the task later:
|
|
@@ -94,9 +94,26 @@ When a check fails, the solution is ALWAYS to fix the underlying code. NEVER:
|
|
|
94
94
|
|
|
95
95
|
These actions hide problems; they do not fix them. 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.
|
|
96
96
|
|
|
97
|
-
##
|
|
97
|
+
## Branch hygiene before starting work
|
|
98
98
|
|
|
99
|
-
|
|
99
|
+
The lifecycle commands `/wip`, `/investigate`, and `/implement` MUST verify branch state before doing anything else. This is a HARD STOP, not a warning. A warning the agent emits and then ignores is identical to no check — three concerns end up on one branch and the mess is only discovered at `/submit`.
|
|
100
|
+
|
|
101
|
+
When invoked for issue `#N`:
|
|
102
|
+
|
|
103
|
+
1. Run `git -C repo branch --show-current` → branch `B`
|
|
104
|
+
2. Run `git -C repo status --porcelain` → working tree state `T`
|
|
105
|
+
|
|
106
|
+
Proceed ONLY if one of these holds:
|
|
107
|
+
|
|
108
|
+
- `B` is `main` or `master` AND `T` is clean
|
|
109
|
+
- `B` contains `N` (e.g., `feat/N-...`, `fix/N-…`) — you are continuing in-flight work for the same issue; dirty tree is allowed
|
|
110
|
+
|
|
111
|
+
Otherwise STOP. Report exactly what you saw and the recovery path:
|
|
112
|
+
|
|
113
|
+
- If `B` is for a different issue: tell the user to `/submit` the in-flight work first, then `git -C repo switch main` and re-run the command. Do NOT offer to commit or stash on their behalf.
|
|
114
|
+
- If `B` is `main`/`master` but `T` is dirty: tell the user the uncommitted changes need to land somewhere (their own branch + `/submit`, or explicit discard) before starting new work.
|
|
115
|
+
|
|
116
|
+
Do NOT proceed with a "warning." Do NOT scaffold, investigate, or implement on a stale or wrong branch. Branching mistakes compound silently and the cost of recovery scales with how many commands later they are caught.
|
|
100
117
|
|
|
101
118
|
## Track progress
|
|
102
119
|
|