@simpleapps-com/augur-skills 2026.3.18 → 2026.3.19

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@simpleapps-com/augur-skills",
-  "version": "2026.03.18",
+  "version": "2026.03.19",
   "description": "Install curated Claude Code skills",
   "license": "MIT",
   "type": "module",

package/skills/simpleapps/deployment/SKILL.md

@@ -0,0 +1,62 @@
+---
+name: deployment
+description: Project deployment conventions — reads the wiki Deployment page and executes submit, deploy, or publish steps. Refuses to operate without a Deployment page.
+user-invocable: false
+allowed-tools:
+  - Read
+  - Glob
+  - Grep
+  - Bash
+  - Skill(git-safety)
+  - Skill(conventional-commits)
+  - Skill(github)
+---
+
+First, use Skill("git-safety") to load git guardrails.
+
+# Deployment
+
+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.
+
+## Deployment Page Format
+
+Every project wiki SHOULD have a `Deployment.md` page with up to three sections:
+
+```
+## Submit
+How to commit and create a PR for review.
+
+## Deploy
+How to deploy to staging.
+
+## Publish
+How to release to production.
+```
+
+Not all projects need all three. Client sites may only have Submit and Deploy. Package repos may have all three.
+
+## How It Works
+
+1. Read `wiki/Deployment.md`
+2. Find the section matching the requested action (Submit, Deploy, or Publish)
+3. If the page or section is missing, **refuse to operate** — tell the user to run `/curate-wiki` to generate it
+4. Execute the steps in that section, respecting git-safety at every git write operation
+
+## Guard Rails
+
+- MUST NOT guess deployment steps — only execute what the wiki defines
+- MUST NOT operate if the Deployment page is missing or the relevant section is absent
+- MUST load git-safety — every git write operation requires user approval
+- `/publish` MUST complete the verification gate before executing (see below)
+
+## Publish Verification Gate
+
+Before executing any Publish steps, MUST:
+
+1. Show the **current version** and the **proposed new version**
+2. Show **what changes** are included since the last release (`git log` from last tag)
+3. Show **CI/test status** if available (`gh run list` or local test run)
+4. Present a summary: version transition, commit count, test status
+5. Require the user to **explicitly confirm** the specific version going to production
+
+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.

package/skills/simpleapps/wiki/SKILL.md

@@ -124,6 +124,10 @@ The wikis are kept fresh by `/curate-wiki` runs across projects. Searching local
 
 **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.
 
+## Deployment Page
+
+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.
+
 ## Testing Page
 
 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.

package/skills/simpleapps/workflow/SKILL.md

@@ -69,7 +69,7 @@ gh issue create --repo simpleapps-com/<repo> \
 The full workflow from task to delivery, each step feeding the next:
 
 ```
-/triage → /wip → /investigate → /discuss → /implement → /quality → /verify → /curate-wiki
+/triage → /wip → /investigate → /discuss → /implement → /quality → /verify → /submit → /deploy → /publish
 ```
 
 | Phase | Command | What happens |
@@ -81,9 +81,13 @@ The full workflow from task to delivery, each step feeding the next:
 | Build | `/implement` | Execute the plan — code changes only, no commits |
 | Code checks | `/quality` | Lint, typecheck, test, package freshness |
 | Browser checks | `/verify` | Walk through wiki's Testing.md checklist in Chrome |
-| Capture | `/curate-wiki` | Update wiki with session learnings, audit CLAUDE.md/rules |
+| Submit | `/submit` | Commit and create a PR for review |
+| Stage | `/deploy` | Deploy to staging (merge PRs, trigger staging build) |
+| Release | `/publish` | Version bump, tag, release to production (with verification) |
 
-**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.
+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.
+
+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.
 
 Commands like `/research` and `/discuss` can be used at any stage. `/quality`, `/verify`, `/curate-wiki`, and `/wiki-audit` can run independently.