@simpleapps-com/augur-skills 2026.4.17 → 2026.4.18

package/package.json

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

package/skills/simpleapps/context-efficiency/SKILL.md

@@ -25,7 +25,7 @@ Always-loaded content (CLAUDE.md, rules without `paths`) is paid on every prompt
 - **Skill descriptions**: 2% of context window for all skills combined (16K char fallback). Override with `SLASH_COMMAND_TOOL_CHAR_BUDGET`.
 - **SKILL.md**: under 500 lines. Move detail to supporting files.
 - **Auto memory**: first 200 lines of MEMORY.md loaded. Topic files on demand.
-- **Overhead**: a meaningful share of the context window is consumed by system prompt, tool definitions, and autocompact buffer before you type anything. The exact percentage depends on which MCP servers and tools are loaded. Run `/context` to see the current breakdown.
+- **Overhead**: a meaningful share of the context window is consumed by system prompt, tool definitions, and autocompact buffer before you type anything. The exact percentage depends on which MCP servers and tools are loaded. Run `/context-audit` to see the current breakdown.
 
 ## Evergreen Content
 
@@ -68,7 +68,7 @@ The cheapest pointer with the biggest payoff is a **wiki link in CLAUDE.md**. A
 
 ## Checking Your Budget
 
-Run `/context` to see current token usage by category. Watch for:
+Run `/context-audit` to see current token usage by category. Watch for:
 - Skills being excluded (descriptions exceeded 2% budget)
 - CLAUDE.md consuming more than ~5% of context
 - Many MCP servers inflating tool definitions

package/skills/simpleapps/wip/SKILL.md

@@ -109,12 +109,20 @@ Not every WIP has an issue. Investigation notes, spike results, meeting takeaway
 
 They follow the same retention rule once `status` is terminal. `/process-wips` leaves them alone while `status` is `open` or `in-progress`.
 
+## Attachments
+
+When a WIP is scaffolded from a Basecamp todo, message, or upload, every attachment on the source item AND on every comment MUST be downloaded via `download_attachment` and summarized inline in the WIP's Attachments section. Images are read multimodally with the `Read` tool and described — UI state, error text, highlighted regions, before/after framing. PDFs, spreadsheets, and docs are read and their key facts captured. The bar is that a future agent reading only the WIP has enough context to act without re-downloading.
+
+MUST NOT list attachments by filename alone. MUST NOT skip an attachment because it "looks unimportant" — the user posted it for a reason. If a download fails, note the failure with the attachment ID so the user can intervene; do not silently drop it.
+
+The same rule applies on `/wip` updates: new attachments added to the source since last fetch get downloaded and summarized, not just appended as filenames.
+
 ## What NOT to put in a WIP
 
 - Secrets, tokens, credentials
 - Final user-facing documentation (that's the wiki)
 - Production code (that's the repo)
-- Large binary attachments (link to them instead)
+- The raw binary contents of attachments (the file lives under `~/.simpleapps/downloads/`; the WIP holds the summary and the local path)
 
 ## Related
 

package/skills/simpleapps/work-habits/SKILL.md

@@ -104,7 +104,7 @@ These actions hide problems; they do not fix them. If a rule or test seems wrong
 
 ## Branch hygiene before starting work
 
-Branch management is the agent's job, not the user's. The lifecycle commands `/wip`, `/investigate`, and `/implement` MUST verify branch state before starting, but the agent SHOULD handle the safe transitions itself rather than blocking the user with "go run `git switch` first."
+Branch management is the agent's job, not the user's. **Encourage** clean main; do **not** force it. Nudge the user when the branch state is unexpected, do the safe transition autonomously, and keep moving. The point of this rule is to reduce friction, not to add a gate.
 
 When invoked for issue `#N`:
 
@@ -115,10 +115,10 @@ When invoked for issue `#N`:
 |-----|-----|--------|
 | Contains `N` | any | Proceed — continuing in-flight work for this issue |
 | `main` / `master` | clean | For `/wip` and `/investigate` (read/scaffold only): proceed on `main`. For `/implement` (code changes): create the branch yourself with `git -C repo switch -c <type>/<N>-<slug>`, then proceed. Derive `<type>` from the issue title prefix (`feat:`, `fix:`, `chore:`, `docs:`). Derive `<slug>` from the issue title (lowercase-hyphenated, ≤40 chars). |
-| `main` / `master` | dirty | HARD STOP — uncommitted changes need to land somewhere first. Report exactly which files are modified. Let the user decide (commit on a branch, discard, stash). MUST NOT touch their changes. |
-| Belongs to a different issue (`feat/M-…`, `M ≠ N`) | any | HARD STOP — tell the user to `/submit` the in-flight work first, then re-run. MUST NOT switch branches with uncommitted work present. |
+| Different issue branch (`feat/M-…`, `M ≠ N`) | clean | Nudge in your reply: "you're on `<branch>` for issue M; switching to main first." For `/wip`/`/investigate`: switch to main and proceed. For `/implement`: switch to main, create the new branch yourself, proceed. The user's work is already committed on `M`'s branch; they can return to it later. |
+| any | dirty | **Pause and ask once.** Uncommitted work could be mixed or lost by proceeding. Surface the modified files, propose one path (commit on a branch, stash, discard), and let the user choose. Proceed on their answer — do not refuse further engagement. MUST NOT touch their changes without instruction. |
 
-The HARD STOPs only fire when the user's working state would be lost or mixed by proceeding. Clean main + known issue is not a stop condition — `/implement` creates the branch itself; `/wip` and `/investigate` proceed in place because they don't write code.
+The only pause condition is a dirty tree, because proceeding could destroy work the agent didn't make. Clean main + known issue is not a stop condition; neither is being on someone else's clean feature branch — the agent switches and proceeds.
 
 Branching mistakes compound silently and the cost of recovery scales with how many commands later they are caught — but the answer is the agent doing the safe transition autonomously, not screaming the sky is falling at the user every time the workflow requires a routine `git switch`.