@simpleapps-com/augur-skills 0.0.16 → 0.0.18

package/package.json

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

package/skills/simpleapps/github/SKILL.md

@@ -25,6 +25,7 @@ If `git push` fails with 401/403, run `gh auth setup-git` to fix credentials.
 ## Key Topics
 
 - **Wiki as context** — See `wiki-as-context.md` for why the wiki is the source of truth and how to write for both humans and AI agents.
+- **Wiki maintenance** — See `wiki-maintenance.md` for how to verify, update, and maintain wiki content correctly.
 - **Project structure** — See `project-structure.md` for the `{project}/[repo|wiki]` layout, what goes where, and wiki conventions.
 - **Issues & pull requests** — See `issues-prs.md` for issue templates, PR commands, and cross-linking with Basecamp.
 

package/skills/simpleapps/github/project-structure.md

@@ -6,13 +6,13 @@ Every project MUST use this layout:
 
 ```
 {project}/
-├── repo/        # Main git repo (simpleapps-com/<name>.git)
-├── wiki/        # GitHub wiki repo (simpleapps-com/<name>.wiki.git)
-├── wip/         # Work-in-progress files for active tasks (not in git)
-└── protected/   # Secrets and credentials for dev testing (not in git)
+├── repo/           # Main git repo (simpleapps-com/<name>.git)
+├── wiki/           # GitHub wiki repo (simpleapps-com/<name>.wiki.git)
+├── wip/            # Work-in-progress files for active tasks (not in git)
+└── .simpleapps/    # Project-level secrets and credentials (not in git)
 ```
 
-The parent `{project}/` directory is NOT a git repo — it's a local wrapper that keeps the code repo and wiki side-by-side. The `wip/` and `protected/` directories sit outside both git trees so their contents can never be accidentally committed.
+The parent `{project}/` directory is NOT a git repo — it's a local wrapper that keeps the code repo and wiki side-by-side. The `wip/` and `.simpleapps/` directories sit outside both git trees so their contents can never be accidentally committed.
 
 ## Why This Pattern
 
@@ -41,7 +41,8 @@ If the wiki repo doesn't exist yet, create it by adding any page via the GitHub
 | Repo `.claude/rules/` | `repo/` | Minimal summaries referencing wiki pages |
 | Repo `.claude/CLAUDE.md` | `repo/` | Quick reference + wiki links |
 | Active task context | `wip/` | WIP files for Basecamp todos or GitHub issues |
-| Dev secrets | `protected/` | API keys, tokens, test credentials |
+| Project secrets | `{project}/.simpleapps/` | Site-specific credentials, `{siteId}.json` |
+| Global secrets | `~/.simpleapps/` | Shared credentials across all projects |
 
 Rule of thumb: if a `.md` file isn't built into the end product, it belongs in the wiki. If it contains secrets or ephemeral task state, it belongs outside both git trees.
 
@@ -69,15 +70,18 @@ The `wip/` directory holds work-in-progress files that AI agents create when pic
 
 ### What does NOT belong in WIP
 
-- Secrets, credentials, or tokens (use `protected/`)
+- Secrets, credentials, or tokens (use `.simpleapps/`)
 - Final documentation (use `wiki/`)
 - Code (use `repo/`)
 
-## Protected Directory
+## Credentials (`.simpleapps/`)
 
-The `protected/` directory stores secrets and credentials needed during development and testing. It sits outside all git trees so nothing can be accidentally committed.
+Secrets and credentials live in `.simpleapps/` directories at two levels:
 
-Examples: API keys, OAuth tokens, test credentials, `.env` files for local testing.
+- **`~/.simpleapps/`** (user-level) — shared credentials across all projects (e.g., `augur-api.json`, `basecamp.json`)
+- **`{project}/.simpleapps/`** (project-level) — credentials specific to that project (e.g., `{siteId}.json` with test user creds)
+
+Project-level credentials override user-level ones when both exist. Both directories sit outside git trees so nothing can be accidentally committed.
 
 MUST NOT be committed to any git repository. MUST NOT be copied into `repo/` or `wiki/`.
 

package/skills/simpleapps/github/wiki-as-context.md

@@ -110,24 +110,23 @@ This matters for two reasons:
 - **Devs** jump straight to the answer instead of scrolling through a page
 - **AI agents** use anchor links as an attention signal — a `#section` reference tells the agent exactly which part of a page is relevant to the current task, reducing noise in a 20K token wiki
 
-### The 20K Token Budget
+### Keep It Lean
 
-The entire wiki MUST stay under **20K tokens** (~60KB of markdown). This is a hard constraint, not a guideline.
+Wikis SHOULD be as small as possible while remaining complete. The goal: an AI agent can load the **entire wiki** into context at session start and keep it there throughout.
 
-Why 20K: with a 200K token context window, the full wiki never exceeds 10% of available context. This means an AI agent can load the **entire wiki** into active context at the start of a session and keep it there throughout. No selective loading, no missed context, no stale references — the agent always has the complete picture.
-
-If the wiki approaches the budget:
+Guidelines:
 - Tighten language — cut filler, use tables over prose
 - Merge overlapping pages
-- Move implementation details back to code comments where they belong
+- Document patterns and principles, not exhaustive implementation details (see `wiki-maintenance.md`)
 - Archive obsolete pages (delete, don't hoard)
+- Move implementation specifics back to code comments where they belong
 
-To check the current budget:
+To check wiki size:
 ```bash
 wc -c {project}/wiki/*.md
 ```
 
-Rough conversion: 1 token ≈ 3 bytes of markdown. So 20K tokens ≈ 60KB.
+Rough conversion: 1 token ≈ 3 bytes of markdown.
 
 ### Right-Size Each Page
 

package/skills/simpleapps/github/wiki-maintenance.md

@@ -0,0 +1,71 @@
+# Wiki Maintenance
+
+Guidance for agents editing wiki content. Applies to all `wiki/*.md` files across all projects.
+
+## Verify Before You Write
+
+Cross-check wiki claims against the codebase before updating. Staleness-prone sections:
+
+- Package versions (`package.json` is the source of truth)
+- File counts and file inventories (files get added/deleted)
+- CI/CD workflow status (workflows get added/modified)
+- TODO items and "not yet built" markers (things get done)
+- Export lists and API surfaces (code changes)
+
+**Never echo what the wiki already says.** Read the code, then write the wiki.
+
+## Patterns, Not Details
+
+The wiki documents **conventions and principles**. The code is the source of truth for specifics.
+
+- No hardcoded counts ("22 components", "14 hooks" — these change)
+- No exhaustive lists of every type, hook, component, or export by name
+- No pinned version numbers for peer dependencies
+- Instead: describe the pattern, give 1-2 examples, point to source code for the current list
+
+## Naming Conventions
+
+Follow the project's existing convention:
+
+- **Site wikis**: PascalCase with hyphens (`Getting-Started.md`, `Architecture.md`)
+- **Package wikis**: Prefix-based sections (`guide-*.md` for users, `design-*.md` for contributors)
+
+Check `Home.md` or `_Sidebar.md` to confirm the convention before creating new pages.
+
+## Keep Indexes Current
+
+When adding or removing pages, MUST update:
+
+- `Home.md` / `README.md` (index tables)
+- `_Sidebar.md` (navigation)
+- `llms.txt` (if present)
+
+## Tagging for Lead-Site Wikis
+
+The lead site wiki (e.g., ampro-online) serves as both site documentation and platform reference. Tag sections:
+
+- **(platform pattern)** — guidance all sites SHOULD follow
+- **(site-specific)** — this site's particular values, replace with your own
+
+This tells agents working on other sites what to replicate vs customize.
+
+## Dual-Audience Framing
+
+Lead site wikis serve two audiences:
+
+1. Developers/agents working on **that site**
+2. Developers/agents building or migrating **other sites**
+
+Write for both: document current reality AND provide guidance others can follow.
+
+## Git Workflow
+
+The wiki is a separate git repo at `wiki/`. No branch protection, no PRs, no changesets.
+
+```bash
+git -C wiki add -A
+git -C wiki commit -m "docs: describe the change"
+git -C wiki push
+```
+
+Wiki repos typically use `master` as the default branch.