@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
|
@@ -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.
|
|
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
|
-
-
|
|
56
|
-
- If
|
|
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
|