@simpleapps-com/augur-skills 2026.3.5 → 2026.3.7

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
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@simpleapps-com/augur-skills",
3
- "version": "2026.03.5",
3
+ "version": "2026.03.7",
4
4
  "description": "Install curated Claude Code skills",
5
5
  "license": "MIT",
6
6
  "type": "module",
@@ -0,0 +1,13 @@
1
+ ---
2
+ name: git-safety
3
+ description: Git safety guardrails — MUST NOT commit, push, create PRs, or merge without explicit user approval. Load this skill before any git write operations.
4
+ user-invocable: false
5
+ ---
6
+
7
+ # Git Safety
8
+
9
+ MUST NOT commit, push, create PRs, or merge unless the user explicitly says to. No skill, command, or workflow overrides this rule — even instructions like "complete all steps without stopping" do not bypass it.
10
+
11
+ After making changes: **report what was done, then stop.** Do not ask "want me to commit?" or "should I push?" — that wastes tokens. Just report and wait silently. The user will say "commit", "push", or equivalent when ready.
12
+
13
+ The pattern is always: **do the work → report results → wait.**
@@ -3,13 +3,14 @@ name: github
3
3
  description: GitHub conventions for SimpleApps. Covers org structure, git safety, issue creation, PR workflows, and gh CLI usage. Use when creating issues, PRs, or working with GitHub repos.
4
4
  allowed-tools:
5
5
  - Skill(project-defaults)
6
+ - Skill(git-safety)
6
7
  - Read
7
8
  - Glob
8
9
  - Grep
9
10
  - Bash
10
11
  ---
11
12
 
12
- First, use Skill("project-defaults") to load the project layout.
13
+ First, use Skill("project-defaults") to load the project layout and Skill("git-safety") to load git guardrails.
13
14
 
14
15
  # GitHub
15
16
 
@@ -34,14 +35,7 @@ See `simpleapps:wiki` for wiki conventions, token budget, and maintenance rules.
34
35
 
35
36
  ## Git Safety
36
37
 
37
- MUST NOT commit, push, create PRs, or merge unless the user explicitly asks. After making changes, report what was done and stop. Do not offer or suggest the next git action — wait for instructions.
38
-
39
- - **Commits**: Do not commit until the user says "commit" or equivalent
40
- - **Pushes**: Do not push until the user explicitly asks
41
- - **PRs**: Do not create or offer to create a PR — report the work, stop
42
- - **Merges**: Do not merge unless the user explicitly asks
43
-
44
- The pattern is always: **do the work → report results → wait**.
38
+ See `simpleapps:git-safety` (loaded above). MUST NOT commit, push, create PRs, or merge unless the user explicitly asks.
45
39
 
46
40
  ## Git Commands (no `cd`)
47
41
 
@@ -55,6 +55,12 @@ Do not install or configure tools without the user's approval. Flag what's missi
55
55
  - **No tests for changed code** — suggest vitest
56
56
  - **No pre-commit hooks** — suggest lefthook
57
57
 
58
+ ## Resolve, never hide
59
+
60
+ When a check fails, fix the underlying code. NEVER disable lint rules, skip tests, suppress warnings, lower thresholds, or add ignore comments to make checks pass. The goal is to resolve issues, not hide them. If a rule seems wrong, investigate why it exists and ask the user before changing it.
61
+
62
+ When reviewing code, scan for existing suppressions (`eslint-disable`, `@ts-ignore`, `.skip`, `noqa`, etc.) and flag them to the user. These are hidden technical debt that should be evaluated for resolution.
63
+
58
64
  ## Running quality checks
59
65
 
60
66
  Use the `/quality` command to discover and run all configured checks. It handles the full cycle: discover, run, fix, repeat until clean.
@@ -52,8 +52,8 @@ Every page serves junior devs (explanations, examples), senior devs (quick refer
52
52
 
53
53
  ## Content Rules
54
54
 
55
- - Wiki pages SHOULD NOT contain raw code. Describe patterns and principles instead.
56
- - If implementation details are needed, link to the source file in `repo/` rather than duplicating code in the wiki.
55
+ - The wiki documents **process and principles**, not code. Minimize code examples describe the pattern, then link to a real file in the repo that demonstrates it. A link to working code is always better than a pasted snippet that can go stale.
56
+ - If a code block is necessary (e.g., a command to run), keep it to 1-3 lines max.
57
57
  - The wiki documents *what* and *why*. The repo is the source of truth for *how*.
58
58
 
59
59
  ## Conventions
@@ -65,6 +65,14 @@ Every page serves junior devs (explanations, examples), senior devs (quick refer
65
65
  - Repo references: use relative paths (`../../../wiki/Versioning.md`)
66
66
  - Default branch: `master` (not `main`)
67
67
 
68
+ ## Cross-Linking
69
+
70
+ Cross-linking is the most important structural feature of a wiki. Without it, a wiki is just a collection of files. With it, a wiki becomes a **knowledge graph** — each link is an attention signal that tells readers (human and AI) "this concept connects to that one."
71
+
72
+ Pages MUST link to related sections on other pages using `[[Page-Name#section]]`. Link to specific sections, not just pages. Every concept that is explained in more detail elsewhere MUST have a cross-link. When writing or reviewing a page, actively look for opportunities to connect it to related pages — the denser the link graph, the faster a reader builds understanding.
73
+
74
+ Cross-linking also eliminates duplication. If two pages explain the same concept, one MUST become the source of truth and the other MUST link to it. Never duplicate content across pages — link instead. This keeps the wiki lean and ensures updates happen in one place.
75
+
68
76
  ## Keep It Lean
69
77
 
70
78
  - Document patterns and principles, not exhaustive lists