@simpleapps-com/augur-skills 2026.3.17 → 2026.3.19
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
|
@@ -8,24 +8,38 @@ user-invocable: false
|
|
|
8
8
|
|
|
9
9
|
## Why This Matters
|
|
10
10
|
|
|
11
|
-
|
|
11
|
+
A complex command feels efficient — do more in one call. But the more complex the command, the higher the probability it triggers a permission prompt. A permission prompt blocks the agent until the user responds. If the user doesn't see it for an hour, that hour is lost.
|
|
12
12
|
|
|
13
|
-
|
|
13
|
+
**Simple commands are faster than complex ones because they never wait for a human.** Ten simple commands that execute instantly are faster than one complex command that waits an hour for approval. The agent's goal is to complete work — a blocked prompt completes nothing.
|
|
14
14
|
|
|
15
|
-
|
|
15
|
+
The entire plugin system exists to remove the user as the bottleneck. Every permission prompt puts them back in the critical path.
|
|
16
16
|
|
|
17
|
-
|
|
18
|
-
Right: Three separate Bash calls, one per command.
|
|
17
|
+
**Three tiers of execution speed — always use the highest tier available:**
|
|
19
18
|
|
|
20
|
-
|
|
21
|
-
|
|
19
|
+
| Tier | Method | Speed | Example |
|
|
20
|
+
|------|--------|-------|---------|
|
|
21
|
+
| 1 | Dedicated tools (Read, Grep, Glob, Edit) | **WILL** run immediately, zero permission chance | `Grep(pattern: "...", path: "repo")` |
|
|
22
|
+
| 2 | Simple Bash (one command, no operators) | **MAY** run immediately if pre-approved | `pnpm typecheck` |
|
|
23
|
+
| 3 | Complex Bash (operators, plumbing) | **WILL** trigger a permission prompt | `pnpm typecheck 2>&1; echo $?` |
|
|
22
24
|
|
|
23
|
-
|
|
24
|
-
Right: Write the comment to a tmp file, then use two separate calls:
|
|
25
|
-
1. `gh issue comment 367 --repo org/repo --body-file tmp/file.txt`
|
|
26
|
-
2. `gh issue close 367 --repo org/repo`
|
|
25
|
+
Prefer tier 1 over tier 2. Use tier 2 only when no dedicated tool exists. NEVER use tier 3.
|
|
27
26
|
|
|
28
|
-
|
|
27
|
+
## The Bash Tool Is Not a Terminal
|
|
28
|
+
|
|
29
|
+
The Bash tool is a managed environment, not a raw shell. It already captures stdout, stderr, and the exit code automatically. There is NEVER a reason to add shell plumbing — every shell operator triggers a permission prompt that blocks the user for zero benefit.
|
|
30
|
+
|
|
31
|
+
**If the Bash tool already does it, do not do it yourself:**
|
|
32
|
+
|
|
33
|
+
| You want to... | The tool already does it | Do NOT add |
|
|
34
|
+
|----------------|------------------------|------------|
|
|
35
|
+
| Get the exit code | Returned automatically | `; echo $?`, `; echo "Exit code: $?"` |
|
|
36
|
+
| Capture stderr | Captured automatically | `2>&1`, `2>/dev/null` |
|
|
37
|
+
| Limit output | Returned in full | `\| head`, `\| tail`, `\| grep` |
|
|
38
|
+
| Run the next step | Make a separate tool call | `&&`, `;`, `\|\|` |
|
|
39
|
+
| Pass output to another command | Write to a tmp file | `$(...)`, backticks |
|
|
40
|
+
| Run inline code | Use Read/Grep/Edit tools | `node -e`, `python -c` |
|
|
41
|
+
|
|
42
|
+
**One command per Bash call. No operators. No plumbing. If the command has a `;`, `&&`, `|`, `$()`, `2>&1`, or `2>/dev/null` in it — it is wrong.**
|
|
29
43
|
|
|
30
44
|
## Use Dedicated Tools
|
|
31
45
|
|
|
@@ -0,0 +1,62 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: deployment
|
|
3
|
+
description: Project deployment conventions — reads the wiki Deployment page and executes submit, deploy, or publish steps. Refuses to operate without a Deployment page.
|
|
4
|
+
user-invocable: false
|
|
5
|
+
allowed-tools:
|
|
6
|
+
- Read
|
|
7
|
+
- Glob
|
|
8
|
+
- Grep
|
|
9
|
+
- Bash
|
|
10
|
+
- Skill(git-safety)
|
|
11
|
+
- Skill(conventional-commits)
|
|
12
|
+
- Skill(github)
|
|
13
|
+
---
|
|
14
|
+
|
|
15
|
+
First, use Skill("git-safety") to load git guardrails.
|
|
16
|
+
|
|
17
|
+
# Deployment
|
|
18
|
+
|
|
19
|
+
This skill reads the project's `wiki/Deployment.md` and executes the steps defined there. Each project defines its own deployment workflow — this skill is the executor, the wiki is the config.
|
|
20
|
+
|
|
21
|
+
## Deployment Page Format
|
|
22
|
+
|
|
23
|
+
Every project wiki SHOULD have a `Deployment.md` page with up to three sections:
|
|
24
|
+
|
|
25
|
+
```
|
|
26
|
+
## Submit
|
|
27
|
+
How to commit and create a PR for review.
|
|
28
|
+
|
|
29
|
+
## Deploy
|
|
30
|
+
How to deploy to staging.
|
|
31
|
+
|
|
32
|
+
## Publish
|
|
33
|
+
How to release to production.
|
|
34
|
+
```
|
|
35
|
+
|
|
36
|
+
Not all projects need all three. Client sites may only have Submit and Deploy. Package repos may have all three.
|
|
37
|
+
|
|
38
|
+
## How It Works
|
|
39
|
+
|
|
40
|
+
1. Read `wiki/Deployment.md`
|
|
41
|
+
2. Find the section matching the requested action (Submit, Deploy, or Publish)
|
|
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, respecting git-safety at every git write operation
|
|
44
|
+
|
|
45
|
+
## Guard Rails
|
|
46
|
+
|
|
47
|
+
- MUST NOT guess deployment steps — only execute what the wiki defines
|
|
48
|
+
- MUST NOT operate if the Deployment page is missing or the relevant section is absent
|
|
49
|
+
- MUST load git-safety — every git write operation requires user approval
|
|
50
|
+
- `/publish` MUST complete the verification gate before executing (see below)
|
|
51
|
+
|
|
52
|
+
## Publish Verification Gate
|
|
53
|
+
|
|
54
|
+
Before executing any Publish steps, MUST:
|
|
55
|
+
|
|
56
|
+
1. Show the **current version** and the **proposed new version**
|
|
57
|
+
2. Show **what changes** are included since the last release (`git log` from last tag)
|
|
58
|
+
3. Show **CI/test status** if available (`gh run list` or local test run)
|
|
59
|
+
4. Present a summary: version transition, commit count, test status
|
|
60
|
+
5. Require the user to **explicitly confirm** the specific version going to production
|
|
61
|
+
|
|
62
|
+
This is not just git-safety. It is an active verification checklist — the user MUST see exactly what they are releasing and confirm that specific version.
|
|
@@ -124,6 +124,10 @@ The wikis are kept fresh by `/curate-wiki` runs across projects. Searching local
|
|
|
124
124
|
|
|
125
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
126
|
|
|
127
|
+
## Deployment Page
|
|
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.
|
|
130
|
+
|
|
127
131
|
## Testing Page
|
|
128
132
|
|
|
129
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.
|
|
@@ -69,7 +69,7 @@ gh issue create --repo simpleapps-com/<repo> \
|
|
|
69
69
|
The full workflow from task to delivery, each step feeding the next:
|
|
70
70
|
|
|
71
71
|
```
|
|
72
|
-
/triage → /wip → /investigate → /discuss → /implement → /quality → /verify → /
|
|
72
|
+
/triage → /wip → /investigate → /discuss → /implement → /quality → /verify → /submit → /deploy → /publish
|
|
73
73
|
```
|
|
74
74
|
|
|
75
75
|
| Phase | Command | What happens |
|
|
@@ -81,9 +81,13 @@ The full workflow from task to delivery, each step feeding the next:
|
|
|
81
81
|
| Build | `/implement` | Execute the plan — code changes only, no commits |
|
|
82
82
|
| Code checks | `/quality` | Lint, typecheck, test, package freshness |
|
|
83
83
|
| Browser checks | `/verify` | Walk through wiki's Testing.md checklist in Chrome |
|
|
84
|
-
|
|
|
84
|
+
| Submit | `/submit` | Commit and create a PR for review |
|
|
85
|
+
| Stage | `/deploy` | Deploy to staging (merge PRs, trigger staging build) |
|
|
86
|
+
| Release | `/publish` | Version bump, tag, release to production (with verification) |
|
|
85
87
|
|
|
86
|
-
|
|
88
|
+
Not every task uses all steps. Most daily work ends at `/submit`. `/deploy` and `/publish` are used less frequently — `/publish` is intentionally rare and requires explicit verification of the exact version going to production.
|
|
89
|
+
|
|
90
|
+
The three shipping commands (`/submit`, `/deploy`, `/publish`) read project-specific steps from `wiki/Deployment.md`. They refuse to operate if the Deployment page is missing — run `/curate-wiki` to generate it from the codebase.
|
|
87
91
|
|
|
88
92
|
Commands like `/research` and `/discuss` can be used at any stage. `/quality`, `/verify`, `/curate-wiki`, and `/wiki-audit` can run independently.
|
|
89
93
|
|