@simpleapps-com/augur-skills 2026.4.3 → 2026.4.5

package/package.json

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

package/skills/simpleapps/basecamp/SKILL.md

@@ -29,128 +29,7 @@ This opens the browser for OAuth, user clicks "Allow", credentials are saved aut
 
 The `basecamp` MCP server is bundled with this plugin and starts automatically. API reference: https://github.com/basecamp/bcx-api
 
-### Projects
-| Tool | Description |
-|------|-------------|
-| `list_projects` | List projects. status: 'active', 'drafts', or 'archived' |
-| `get_project` | Get project details by project_id |
-| `create_project` | Create a new project (name, description) |
-| `update_project` | Update project name/description |
-| `archive_project` | Archive or unarchive a project (archive=False to reactivate) |
-| `delete_project` | Delete a project permanently |
-
-### People
-| Tool | Description |
-|------|-------------|
-| `list_people` | List all people on the account |
-| `get_person` | Get person details by person_id |
-| `get_me` | Get the authenticated user's profile |
-| `list_person_projects` | List projects accessible to a person |
-| `delete_person` | Remove a person from the account (admin only) |
-
-### Todos
-| Tool | Description |
-|------|-------------|
-| `get_todo` | Get a single todo with comments and attachments (project_id, todo_id) |
-| `list_todos` | List todos in a project. status: 'remaining', 'completed', or 'all' |
-| `list_todos_due_since` | List todos due after a date (YYYY-MM-DD) |
-| `list_my_todos` | List all open todos assigned to the current user (paginated) |
-| `list_assigned_todos` | List open todos assigned to any person_id |
-| `create_todo` | Create a todo in a todo list (project_id, todolist_id, content, assignee_id, due_date) |
-| `update_todo` | Update a todo's content, due date, or assignee |
-| `assign_todo` | Reassign a todo to a different person_id |
-| `close_todo` | Mark a todo as completed/closed |
-| `reopen_todo` | Reopen a completed todo |
-| `delete_todo` | Delete a todo permanently |
-
-### Comments
-| Tool | Description |
-|------|-------------|
-| `create_comment` | Add a comment to a todo (plain text) |
-| `delete_comment` | Delete a comment permanently |
-
-### Todo Lists
-| Tool | Description |
-|------|-------------|
-| `list_todolists` | List active todo lists in a project |
-| `list_all_todolists` | List todo lists across all projects. status: 'active', 'completed', or 'trashed' |
-| `get_todolist` | Get all todos in a specific todo list |
-| `create_todolist` | Create a new todo list (project_id, name, description) |
-| `update_todolist` | Update a todo list's name, description, or position |
-| `delete_todolist` | Delete a todo list permanently |
-
-### Messages
-| Tool | Description |
-|------|-------------|
-| `list_messages` | List messages/discussions in a project (via topics) |
-| `get_message` | Get a message with comments and attachments |
-| `create_message` | Create a new discussion (project_id, subject, content) |
-| `update_message` | Update a message's subject/content |
-| `delete_message` | Delete a message permanently |
-
-Note: Messages may not be available on all Basecamp plans.
-
-### Documents
-| Tool | Description |
-|------|-------------|
-| `list_documents` | List documents. project_id=0 for all projects |
-| `get_document` | Get a single document (e.g., site-info) |
-| `create_document` | Create a new document (title, content) |
-| `update_document` | Update a document's title/content |
-| `delete_document` | Delete a document permanently |
-
-### Calendar Events
-| Tool | Description |
-|------|-------------|
-| `list_calendars` | List all calendars |
-| `list_calendar_events` | List events. Filter by project_id, start_date, end_date, past |
-| `get_calendar_event` | Get a specific calendar event |
-| `create_calendar_event` | Create an event (summary, starts_at, description, all_day, ends_at, remind_at) |
-| `update_calendar_event` | Update an event's fields |
-| `delete_calendar_event` | Delete a calendar event |
-
-### Topics
-| Tool | Description |
-|------|-------------|
-| `list_topics` | List topics. project_id=0 for all. archived=True for archived |
-| `archive_topic` | Archive a topic |
-| `activate_topic` | Reactivate an archived topic |
-
-### Attachments & Uploads
-| Tool | Description |
-|------|-------------|
-| `list_attachments` | List attachments. project_id=0 for all (paginated) |
-| `get_attachment` | Get attachment metadata and download URL (project_id, attachment_id) |
-| `download_attachment` | Download attachment to local file (project_id, attachment_id) |
-| `get_upload` | Get an upload with comments |
-| `create_upload` | Upload a local file to a project's Files section |
-| `delete_upload` | Delete an upload (move to trash) |
-
-### Activity
-| Tool | Description |
-|------|-------------|
-| `list_events` | Activity log since a datetime. Filter by project_id or person_id |
-
-### Access Management
-| Tool | Description |
-|------|-------------|
-| `list_accesses` | List people with access to a project |
-| `grant_access` | Grant team access (comma-separated ids and/or email_addresses) |
-| `grant_client_access` | Grant client-level access (comma-separated ids and/or email_addresses) |
-| `revoke_access` | Revoke a person's project access |
-
-### Stars
-| Tool | Description |
-|------|-------------|
-| `list_stars` | List starred/favorite projects |
-| `star_project` | Star (bookmark) a project |
-| `unstar_project` | Remove star from a project |
-
-### Forwards
-| Tool | Description |
-|------|-------------|
-| `list_forwards` | List email forwards. project_id=0 for all |
-| `get_forward` | Get a specific email forward with comments |
+All tools are available as `mcp__plugin_simpleapps_basecamp__*`. The tool names and parameters are self-documenting via the MCP schema — do not hardcode tool signatures. Key tool groups: projects, people, todos, comments, todo lists, messages, documents, calendar events, topics, attachments/uploads, activity, access management, stars, forwards.
 
 **Note**: The BCX API does not have a search endpoint. To find content, use `list_topics(project_id)` to browse, or `list_messages(project_id)` for messages. For cross-project browsing, use `list_topics()` (no project_id) to get recent topics across all projects.
 

package/skills/simpleapps/fyxer/SKILL.md

@@ -1,215 +1,28 @@
 ---
 name: fyxer
 description: Fyxer AI meeting recording integration. Covers extraction, local caching, posting to Basecamp, and Fyxer Index management. Use when processing Fyxer recordings or meeting transcripts.
-allowed-tools:
-  - Read
-  - Write
-  - Glob
-  - Bash
-  - mcp__plugin_simpleapps_basecamp__*
-  - mcp__claude-in-chrome__*
 ---
 
 # Fyxer
 
-Fyxer AI records and summarizes meetings. This skill covers extracting data from Fyxer, posting to Basecamp, and managing the Fyxer Index.
+Fyxer AI records and summarizes meetings. Use the `/fyxer` command to process recordings end-to-end.
 
-## Fyxer URLs
+## Key Conventions
 
-Recording page: `https://app.fyxer.com/call-recordings/<meeting-uuid>:<calendar-event-id>`
+- **Recording URL**: `https://app.fyxer.com/call-recordings/<meeting-uuid>:<calendar-event-id>`
+- **Cache location**: `~/.simpleapps/fyxer/<meeting-uuid>/` — contains `summary.txt`, `transcript.txt`, `message.txt`
+- **Use only the meeting UUID** (before the colon) for cache folders, duplicate checks, and frontmatter
+- **Fyxer Index**: a `Fyxer Index` document in each Basecamp project for duplicate detection. One line per posted meeting, newest first: `<meeting-uuid> | <date> | <message-id> | <subject>`
+- **Post format**: plain text with YAML frontmatter (meeting, date, time, participants, topics, fyxer-id) followed by the full transcript
+- **Subject format**: `Fyxer: YYYY-MM-DD`
 
-The URL path after `/call-recordings/` contains two parts separated by a colon:
-- **Meeting UUID** (before colon): `52f0cf2b-fdb8-4e95-8b01-2afb6d367c69`
-- **Calendar event ID** (after colon): `2fg5k3v3hffl91dnuqauc15suk_20260119T190000Z`
-
-Use only the **meeting UUID** for cache folders, duplicate checks, and frontmatter.
-
-Each recording has two tabs:
-- **Summary** — AI-generated summary with section headings, participants, action items. Has "Copy summary" and "Download PDF" buttons.
-- **Transcript** — Speaker-attributed, timestamped full transcript. Has "Copy transcript" and "Download transcript" buttons.
-
-## Local Cache
-
-All extracted data is cached at `~/.simpleapps/fyxer/<meeting-uuid>/`:
-
-```
-summary.txt     - raw Fyxer summary (from Summary tab)
-transcript.txt  - raw Fyxer transcript (from Transcript tab)
-message.txt     - assembled output (generated by posting process)
-```
-
-Cache is populated via Chrome extraction (see below) and reused across processes.
-
-## Chrome Extraction
-
-Only needed when local cache files are missing.
-
-### Extract transcript
-
-Click the **Transcript** tab. Extraction methods (in order of preference):
-
-1. **"Download transcript" button** (BEST) — Downloads a `.txt` file to `~/Downloads/`. Complete content, no truncation. Copy to cache dir, then delete the download.
-2. **"Copy transcript" button** + `pbpaste` — Copies to system clipboard. Write to disk: `pbpaste > transcript.txt`. Reliable but requires clipboard access.
-3. **`get_page_text`** — UNRELIABLE. Only captures visible/partial content. Missed most of a 30-minute transcript in testing. DO NOT USE for transcripts.
-
-Save to `~/.simpleapps/fyxer/<meeting-uuid>/transcript.txt`.
-
-### Extract summary
-
-The Summary tab is the default view. Extraction methods (in order of preference):
-
-1. **"Copy summary" button** + `pbpaste` (BEST) — Copies markdown to clipboard. Write to disk: `pbpaste > summary.txt`. Summaries are short (~1,700 chars) so this works well.
-2. **`get_page_text`** — Works for short summaries but mixes in page chrome. Not recommended.
-
-Save to `~/.simpleapps/fyxer/<meeting-uuid>/summary.txt`.
-
-### Extract participants
-
-Click the **participant count dropdown** (e.g. "3 participants") in the page header to reveal attendee names and emails. Take a screenshot to read them.
-
-### Clipboard verification
-
-To verify clipboard content is complete before writing to disk:
-
-```javascript
-(async () => {
-  const text = await navigator.clipboard.readText();
-  window.__temp = text;
-  return JSON.stringify({
-    length: text.length,
-    first50: text.substring(0, 50),
-    last100: text.substring(text.length - 100)
-  });
-})()
-```
-
-Then write and verify: `pbpaste > target.txt && wc -c target.txt`
-
-**Note**: Do NOT try to read full clipboard content via JS — Chrome MCP truncates JS output at ~1,000 characters. Always use `pbpaste` to write to disk.
-
-### Download cleanup
-
-MUST clean up `~/Downloads/` after copying downloaded files to the cache directory. Fyxer names downloads like `transcript-SA_USCCO.txt`. Repeated downloads append `(1)`, `(2)`, etc.
-
-## Posting to Basecamp
-
-Post Fyxer meeting recordings as searchable Discussions in Basecamp projects.
-
-**Inputs**: Fyxer recording URL + Basecamp project ID.
-
-### 1. Check for duplicate
-
-Extract the meeting UUID from the Fyxer URL. Find the **Fyxer Index** document in the project: `list_documents(project_id)` → scan for title `Fyxer Index`. If found, `get_document(project_id, document_id)` and search content for the meeting UUID. If found, the meeting has already been posted — inform the user and stop.
-
-If no Fyxer Index document exists, there are no tracked meetings. Proceed with posting.
-
-### 2. Check local cache
-
-If `~/.simpleapps/fyxer/<meeting-uuid>/summary.txt` and `transcript.txt` both exist, skip to step 3. Otherwise, follow the Chrome extraction steps above.
-
-### 3. Build message.txt
-
-Parse `summary.txt` for frontmatter fields, extract participants, and combine with the full transcript:
-
-```
----
-meeting: SA/ClientName
-date: YYYY-MM-DD
-time: HH:MM-HH:MM
-participants: Person A, Person B, Person C
-topics: Topic One, Topic Two, Topic Three
-fyxer-id: <meeting-uuid>
----
-
-[contents of transcript.txt]
-```
-
-| Field | Source |
-|-------|--------|
-| meeting | Meeting title from the page header |
-| date | Recording date |
-| time | Recording time range |
-| participants | Participant dropdown (click to reveal names) |
-| topics | Section headings from the Summary |
-| fyxer-id | Meeting UUID from the URL (before the colon) |
-
-Save as `~/.simpleapps/fyxer/<meeting-uuid>/message.txt`.
-
-### 4. Post to Basecamp
-
-Use `create_message(project_id, subject, content)`:
-
-- **Subject**: `Fyxer: YYYY-MM-DD`
-- **Content**: contents of `message.txt`
-
-Capture the **message_id** from the response.
-
-### 5. Update Fyxer Index
-
-After a successful post, update the Fyxer Index document:
-
-1. If no Fyxer Index document exists, create one: `create_document(project_id, "Fyxer Index", "")`
-2. Read current content: `get_document(project_id, document_id)`
-3. Prepend a new line (newest first): `<meeting-uuid> | <date> | <message-id> | <subject>`
-4. Update: `update_document(project_id, document_id, title="Fyxer Index", content=updated_content)`
-
-If the index update fails after a successful post, warn the user. The message is posted but the index is stale. Run reconciliation later.
-
-### Format rules
-
-- **Plain text only** — Basecamp prefers plain text over HTML
-- **YAML frontmatter** — machine-parseable so other Claude Code instances can search and parse meeting context
-- **Transcript only in body** — summary and action items belong on relevant Basecamp todos, not in this message
-- **Consistent title** — `Fyxer: YYYY-MM-DD` keeps messages uniform and sortable
-
-## Fyxer Index
-
-Each Basecamp project that receives Fyxer meeting transcripts MUST have a **Fyxer Index** document for duplicate detection and meeting history.
-
-### Index format
-
-- **Title**: `Fyxer Index`
-- **Location**: Documents section of each Basecamp project
-- **Content**: One line per posted meeting, newest first
-
-```
-<meeting-uuid> | <date> | <message-id> | <subject>
-```
-
-Example:
+## Dependencies
 
-```
-52f0cf2b-fdb8-4e95-8b01-2afb6d367c69 | 2026-01-19 | 514789012 | Fyxer: 2026-01-19
-a1b2c3d4-e5f6-7890-abcd-ef1234567890 | 2026-02-10 | 514801234 | Fyxer: 2026-02-10
-```
+- `simpleapps:basecamp` skill — MCP tools for posting and index management
+- Chrome browser automation — for extraction when cache is empty
 
-### Finding posted transcripts
+## Finding Posted Transcripts
 
-- Check the index: `list_documents(project_id)` → find `Fyxer Index` → `get_document`
+- Check the index: `list_documents(project_id)` then find `Fyxer Index` then `get_document`
 - View a specific transcript: `get_message(project_id, message_id)` using the message_id from the index
 - Browse all messages: `list_messages(project_id)` — Fyxer posts use the title format `Fyxer: YYYY-MM-DD`
-
-### Reconciliation — missing entries
-
-The index MAY fall out of sync. To reconcile:
-
-1. `list_messages(project_id)` → filter for `Fyxer:` titles
-2. For each, `get_message` and extract `fyxer-id` from YAML frontmatter
-3. Compare against the index — add any missing entries
-4. Update the index document
-
-Run reconciliation when the index is first created in a project with existing Fyxer messages, or when the user suspects the index is incomplete.
-
-### Reconciliation — orphaned entries
-
-If an index entry references a deleted message:
-
-1. `get_message(project_id, message_id)` → if 404, remove entry from index
-2. Update the index document
-
-Only run orphan cleanup when explicitly requested by the user.
-
-## Dependencies
-
-- `simpleapps:basecamp` skill — MCP tools for posting and index management
-- Chrome browser automation (for extraction when cache is empty)

package/skills/simpleapps/quality/SKILL.md

@@ -55,23 +55,9 @@ Do not install or configure tools without the user's approval. Flag what's missi
 - **No tests for changed code** — suggest vitest
 - **No pre-commit hooks** — suggest lefthook
 
-## Own every issue
+## Fix everything, hide nothing
 
-Fix every issue the checks find, regardless of which file it is in or who introduced it. There is no such thing as a "pre-existing issue" — context compaction erases your memory of earlier changes, so what looks pre-existing may be something you introduced. Even if you truly did not cause it, the goal is zero issues, not blame assignment. Fix it anyway.
-
-## Resolve, never hide
-
-When a check fails, the solution is ALWAYS to fix the underlying code. NEVER:
-
-- Disable or weaken a lint rule (`eslint-disable`, rule removal, config changes)
-- Skip or delete a failing test (`.skip`, `.only`, deleting the test)
-- Silence type errors (`@ts-ignore`, `@ts-expect-error`, `type: any`)
-- Suppress warnings, lower coverage thresholds, or modify quality configs
-- Add `--no-verify`, `--force`, or flags that bypass checks
-
-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.
-
-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.
+See work-habits: "Leave it better than you found it" and "Resolve, never hide." Both apply fully to quality checks. Fix every issue regardless of who introduced it. NEVER suppress checks — fix the code.
 
 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.
 
@@ -81,12 +67,6 @@ In pnpm workspace projects, the root `pnpm-lock.yaml` and site-level lockfiles M
 
 After ANY `pnpm install`, `pnpm update`, or `pnpm add` in a workspace, run `pnpm install` at the repo root to regenerate the root lockfile. Commit both lockfiles together. If you forget, the next deploy will fail.
 
-## Browser Error Overlays
-
-When debugging in the browser (Chrome automation), Next.js and other frameworks show a **red error overlay** at the bottom of the page when there are runtime errors. This overlay contains the actual error message, stack trace, and usually the exact file and line number causing the problem.
-
-MUST click on the error overlay and read the full error before attempting any fix. 95% of the time the answer is right there. Do not ignore it, do not guess at the problem, do not look elsewhere first — read the error overlay. If using Chrome automation tools, click the overlay element to expand it and read the details.
-
 ## Running quality checks
 
 Use the `/quality` command to discover and run all configured checks. It handles the full cycle: discover, run, fix, repeat until clean.

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

@@ -46,9 +46,23 @@ Code that compiles is not code that works. After making changes, verify they act
 
 YOU MUST NOT mark work complete without verification. Suggesting `/submit` or `/quality` before verifying the code works is backwards — broken code that passes lint is still broken code. Verify first, then let the user decide next steps.
 
-## Own every issue you find
+## Leave it better than you found it
 
-If a check fails or a bug surfaces, fix it. Do not classify issues as "pre-existing" to justify skipping them — context compaction erases your memory of changes made earlier in the session, so what looks pre-existing is often something you introduced. Even if you truly did not cause it, the goal is zero issues, not blame assignment. Fix it anyway.
+Every agent interaction should leave the codebase in a better state. If you encounter a broken test, a console error, an error overlay, a lint warning, or any other issue while working — fix it. This applies whether or not you caused it and whether or not it is related to your current task.
+
+Do not classify issues as "pre-existing" to justify skipping them — context compaction erases your memory of changes made earlier in the session, so what looks pre-existing is often something you introduced. Even if you truly did not cause it, the goal is zero issues, not blame assignment. Fix it anyway. Do not argue with the user about whether an issue is yours to fix. It is.
+
+## Resolve, never hide
+
+When a check fails, the solution is ALWAYS to fix the underlying code. NEVER:
+
+- Disable or weaken a lint rule (`eslint-disable`, rule removal, config changes)
+- Skip or delete a failing test (`.skip`, `.only`, deleting the test)
+- Silence type errors (`@ts-ignore`, `@ts-expect-error`, `type: any`)
+- Suppress warnings, lower coverage thresholds, or modify quality configs
+- Add `--no-verify`, `--force`, or flags that bypass checks
+
+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.
 
 ## Track progress
 

package/skills/simpleapps/writing-style/SKILL.md

@@ -68,10 +68,11 @@ Applies to JSON arrays, markdown bullet lists, table rows, and any unordered col
 
 ## Code Style
 
-Use descriptive variable and function names. Abbreviations save keystrokes but cost readability — the human reviewing your output MUST be able to understand the code without deciphering names.
+Use descriptive variable and function names. Abbreviations save keystrokes but cost readability — the human reviewing your output MUST be able to understand the code without deciphering names. Short names also collide with terminology in the surrounding conversation and confuse the reader (e.g. using `p` as a path variable while the discussion is about a payment path — the reader will read `p` as "payment", not "path").
 
-- MUST use full words: `$groupQuantity` not `$gq`, `cartItem` not `ci`
-- Loop counters (`i`, `j`, `k`) and well-known abbreviations (`id`, `url`, `db`) are fine
+- MUST use full words: `$groupQuantity` not `$gq`, `cartItem` not `ci`, `filePath` not `p`, `response` not `r`
+- MUST NOT use single-letter variable names except loop counters (`i`, `j`, `k`)
+- Well-known abbreviations (`id`, `url`, `db`) are fine
 - Function names SHOULD describe what they do: `calculateShippingCost` not `calcShip`
 
 ## Claude Code Keywords