bad-agent-kit 0.0.0-stage → 0.1.0
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/GLOSSARY.md +11 -0
- package/LICENSE +21 -0
- package/README.md +230 -2
- package/docs/design-evidence.md +35 -0
- package/docs/playbooks/diagnosis.md +14 -0
- package/docs/playbooks/feature-work.md +23 -0
- package/docs/playbooks/go-work.md +28 -0
- package/docs/playbooks/research-docs.md +10 -0
- package/package.json +34 -4
- package/skills/bak/SKILL.md +108 -0
- package/skills/bak/agents/openai.yaml +4 -0
- package/skills/bak/references/documentation-routing.md +42 -0
- package/skills/bak/references/github-publishing.md +34 -0
- package/skills/bak/references/routing-matrix.md +117 -0
- package/skills/go-plan/SKILL.md +42 -0
- package/skills/go-plan/agents/openai.yaml +5 -0
- package/skills/go-plan/references/go-frontier-questions.md +70 -0
- package/skills/go-review/SKILL.md +28 -0
- package/skills/go-review/agents/openai.yaml +5 -0
- package/skills/go-review/references/lenses/perf.md +13 -0
- package/skills/go-review/references/lenses/race.md +17 -0
- package/skills/go-review/references/lenses/security.md +12 -0
- package/skills/go-review/references/lenses/solid.md +20 -0
- package/skills/go-tdd/SKILL.md +39 -0
- package/skills/go-tdd/agents/openai.yaml +5 -0
- package/skills/go-tdd/assets/.golangci.yml +39 -0
- package/skills/go-tdd/references/GO_RULES.md +44 -0
- package/skills/go-tdd/references/toolchain-setup.md +29 -0
package/GLOSSARY.md
ADDED
|
@@ -0,0 +1,11 @@
|
|
|
1
|
+
# BAK Glossary
|
|
2
|
+
|
|
3
|
+
- **BAK** — Batman Agents Kit. The serious public brand: router + marketplace + orchestrator.
|
|
4
|
+
- **bad-agent-kit** — the persona. The joke IS the rule: don't ship the bad agent kit.
|
|
5
|
+
- **bak** — the router skill itself (`skills/bak/SKILL.md`). Formerly `chief`.
|
|
6
|
+
- **Catalog of record** — the single source of truth for what's listed; README table today, `catalog/catalog.json` + generator past ~40 entries. Never hand-edit both.
|
|
7
|
+
- **Compose, never own** — BAK pins and documents upstream skills; it does not fork or vendor them.
|
|
8
|
+
- **Playbook** — a documented chain of skills for one class of real work (e.g. triage → to-spec → to-tickets → tdd → code-review → handoff).
|
|
9
|
+
- **Routing matrix** — `skills/bak/references/routing-matrix.md`: trigger → smallest complete route.
|
|
10
|
+
- **One channel per agent** — never install the same skill via two channels on one agent (silent hash drift).
|
|
11
|
+
- **Privacy-scrub gate** — CI that fails on `$HOME`-literal leaks and personal-infra inventory before publish.
|
package/LICENSE
ADDED
|
@@ -0,0 +1,21 @@
|
|
|
1
|
+
MIT License
|
|
2
|
+
|
|
3
|
+
Copyright (c) 2026 aniqaqill
|
|
4
|
+
|
|
5
|
+
Permission is hereby granted, free of charge, to any person obtaining a copy
|
|
6
|
+
of this software and associated documentation files (the "Software"), to deal
|
|
7
|
+
in the Software without restriction, including without limitation the rights
|
|
8
|
+
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
|
9
|
+
copies of the Software, and to permit persons to whom the Software is
|
|
10
|
+
furnished to do so, subject to the following conditions:
|
|
11
|
+
|
|
12
|
+
The above copyright notice and this permission notice shall be included in all
|
|
13
|
+
copies or substantial portions of the Software.
|
|
14
|
+
|
|
15
|
+
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
16
|
+
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
17
|
+
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
|
18
|
+
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
19
|
+
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
|
20
|
+
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
|
21
|
+
SOFTWARE.
|
package/README.md
CHANGED
|
@@ -1,3 +1,231 @@
|
|
|
1
|
-
#
|
|
1
|
+
# 🦇 BAK — bad-agent-kit
|
|
2
2
|
|
|
3
|
-
|
|
3
|
+
> **BAK** (Batman Agents Kit) — a curated skills marketplace + workflow
|
|
4
|
+
> orchestrator for coding agents. **Compose, never own.**
|
|
5
|
+
>
|
|
6
|
+
> *bad-agent-kit* is the persona: the punchline encodes the rules — don't ship
|
|
7
|
+
> the bad agent kit. Never mutate on inspect. Never publish without authority.
|
|
8
|
+
> Route every task through the smallest complete set of skills.
|
|
9
|
+
|
|
10
|
+
[](https://www.npmjs.com/package/bad-agent-kit)
|
|
11
|
+
[](https://pi.dev/packages)
|
|
12
|
+
[](https://skills.sh)
|
|
13
|
+
[](https://github.com/aniqaqill/bad-agent-kit/actions)
|
|
14
|
+
[](LICENSE)
|
|
15
|
+
[](CONTRIBUTING.md)
|
|
16
|
+
|
|
17
|
+
<sub>Tags: `golang` · `go` · `skills` · `marketplace` · `agent-skills` · `claude-code` · `codex` · `cursor` · `pi` · `mattpocock` · `pstack-inspired` · `workflow-orchestrator` · `tdd` · `code-review`</sub>
|
|
18
|
+
|
|
19
|
+
## Table of contents
|
|
20
|
+
|
|
21
|
+
- [What is this?](#what-is-this)
|
|
22
|
+
- [Install](#install)
|
|
23
|
+
- [The catalog](#the-catalog)
|
|
24
|
+
- [The BAK workflow](#the-bak-workflow)
|
|
25
|
+
- [Go-first skills](#go-first-skills)
|
|
26
|
+
- [Architecture](#architecture)
|
|
27
|
+
- [Repo layout](#repo-layout)
|
|
28
|
+
- [Contributing](#contributing)
|
|
29
|
+
- [Privacy & security](#privacy--security)
|
|
30
|
+
- [Acknowledgments](#acknowledgments)
|
|
31
|
+
- [License](#license)
|
|
32
|
+
|
|
33
|
+
## What is this?
|
|
34
|
+
|
|
35
|
+
Two things, one repo:
|
|
36
|
+
|
|
37
|
+
1. **Marketplace** — a curated catalog of battle-tested agent skills. The
|
|
38
|
+
catalog below is the catalog of record: every entry pins a source, an
|
|
39
|
+
install command, and its position in the BAK workflow. CI keeps the catalog
|
|
40
|
+
in lockstep with the pinned manifest.
|
|
41
|
+
2. **Orchestrator** — the BAK router skill (`bak`) plus documented playbooks
|
|
42
|
+
encoding how the skills chain together in real work: triage → spec →
|
|
43
|
+
tickets → TDD → review → handoff, and a Go-first lane (plan → tdd →
|
|
44
|
+
review) with sensor gates at every phase exit.
|
|
45
|
+
|
|
46
|
+
BAK never forks upstream. Skills stay owned by their authors; BAK pins them,
|
|
47
|
+
composes them, and documents the chains.
|
|
48
|
+
|
|
49
|
+
## Install
|
|
50
|
+
|
|
51
|
+
```bash
|
|
52
|
+
# pi
|
|
53
|
+
pi install npm:bad-agent-kit
|
|
54
|
+
|
|
55
|
+
# Claude Code / Codex / Cursor via skills.sh
|
|
56
|
+
npx skills@latest add aniqaqill/bad-agent-kit -g --skill bak --agent cursor -y
|
|
57
|
+
npx skills@latest add aniqaqill/bad-agent-kit -g --skill go-plan --agent cursor -y
|
|
58
|
+
npx skills@latest add aniqaqill/bad-agent-kit -g --skill go-tdd --agent cursor -y
|
|
59
|
+
npx skills@latest add aniqaqill/bad-agent-kit -g --skill go-review --agent cursor -y
|
|
60
|
+
```
|
|
61
|
+
|
|
62
|
+
> ⚠️ **Pick ONE channel per agent.** Installing through two channels on the
|
|
63
|
+
> same agent duplicates every skill and drifts hashes silently.
|
|
64
|
+
|
|
65
|
+
Bootstrap the full BAK stack for one agent (router + mattpocock suite +
|
|
66
|
+
discovery + browser):
|
|
67
|
+
|
|
68
|
+
```bash
|
|
69
|
+
bash scripts/bootstrap.sh cursor # cursor | claude | codex
|
|
70
|
+
```
|
|
71
|
+
|
|
72
|
+
## The catalog
|
|
73
|
+
|
|
74
|
+
| Skill | Source | Install | Workflow position |
|
|
75
|
+
|---|---|---|---|
|
|
76
|
+
| `bak` | this repo | `pi install npm:bad-agent-kit` | router — start of every task |
|
|
77
|
+
| `go-plan` | this repo | `pi install npm:bad-agent-kit` | Go plan phase — grill then spec |
|
|
78
|
+
| `go-tdd` | this repo | `pi install npm:bad-agent-kit` | Go implement — sensor gates + e2e tests |
|
|
79
|
+
| `go-review` | this repo | `pi install npm:bad-agent-kit` | Go review — standards + spec lenses |
|
|
80
|
+
| `chief` (legacy) | this repo | — | superseded by `bak`; kept for backlink resolution |
|
|
81
|
+
| `find-skills` | [vercel-labs/skills](https://github.com/vercel-labs/skills) | `npx skills@latest add vercel-labs/skills -g --skill find-skills --agent cursor -y` | discover new capabilities |
|
|
82
|
+
| `tdd` | [mattpocock/skills](https://github.com/mattpocock/skills) | `npx skills@latest add mattpocock/skills -g --skill tdd --agent cursor -y` | build/test-first |
|
|
83
|
+
| `triage` | [mattpocock/skills](https://github.com/mattpocock/skills) | `npx skills@latest add mattpocock/skills -g --skill triage --agent cursor -y` | issue intake |
|
|
84
|
+
| `to-spec` | [mattpocock/skills](https://github.com/mattpocock/skills) | `npx skills@latest add mattpocock/skills -g --skill to-spec --agent cursor -y` | synthesize plan |
|
|
85
|
+
| `to-tickets` | [mattpocock/skills](https://github.com/mattpocock/skills) | `npx skills@latest add mattpocock/skills -g --skill to-tickets --agent cursor -y` | split into tickets |
|
|
86
|
+
| `wayfinder` | [mattpocock/skills](https://github.com/mattpocock/skills) | `npx skills@latest add mattpocock/skills -g --skill wayfinder --agent cursor -y` | large/uncertain efforts |
|
|
87
|
+
| `request-refactor-plan` | [mattpocock/skills](https://github.com/mattpocock/skills) | `npx skills@latest add mattpocock/skills -g --skill request-refactor-plan --agent cursor -y` | planned refactors |
|
|
88
|
+
| `code-review` | [mattpocock/skills](https://github.com/mattpocock/skills) | `npx skills@latest add mattpocock/skills -g --skill code-review --agent cursor -y` | review before merge |
|
|
89
|
+
| `setup-matt-pocock-skills` | [mattpocock/skills](https://github.com/mattpocock/skills) | `npx skills@latest add mattpocock/skills -g --skill setup-matt-pocock-skills --agent cursor -y` | tracker setup |
|
|
90
|
+
| `grilling` | [mattpocock/skills](https://github.com/mattpocock/skills) | `npx skills@latest add mattpocock/skills -g --skill grilling --agent cursor -y` | stress-test ideas |
|
|
91
|
+
| `handoff` | [mattpocock/skills](https://github.com/mattpocock/skills) | `npx skills@latest add mattpocock/skills -g --skill handoff --agent cursor -y` | hand over work |
|
|
92
|
+
| `research` | [mattpocock/skills](https://github.com/mattpocock/skills) | `npx skills@latest add mattpocock/skills -g --skill research --agent cursor -y` | primary-source research |
|
|
93
|
+
| `codebase-design` | [mattpocock/skills](https://github.com/mattpocock/skills) | `npx skills@latest add mattpocock/skills -g --skill codebase-design --agent cursor -y` | deep-module design |
|
|
94
|
+
| `diagnosing-bugs` | [mattpocock/skills](https://github.com/mattpocock/skills) | `npx skills@latest add mattpocock/skills -g --skill diagnosing-bugs --agent cursor -y` | diagnosis loop |
|
|
95
|
+
| `domain-modeling` | [mattpocock/skills](https://github.com/mattpocock/skills) | `npx skills@latest add mattpocock/skills -g --skill domain-modeling --agent cursor -y` | GLOSSARY/ADRs |
|
|
96
|
+
| `improve-codebase-architecture` | [mattpocock/skills](https://github.com/mattpocock/skills) | `npx skills@latest add mattpocock/skills -g --skill improve-codebase-architecture --agent cursor -y` | architecture passes |
|
|
97
|
+
| `migrate-to-shoehorn` | [mattpocock/skills](https://github.com/mattpocock/skills) | `npx skills@latest add mattpocock/skills -g --skill migrate-to-shoehorn --agent cursor -y` | test type safety |
|
|
98
|
+
| `prototype` | [mattpocock/skills](https://github.com/mattpocock/skills) | `npx skills@latest add mattpocock/skills -g --skill prototype --agent cursor -y` | throwaway design probes |
|
|
99
|
+
| `resolving-merge-conflicts` | [mattpocock/skills](https://github.com/mattpocock/skills) | `npx skills@latest add mattpocock/skills -g --skill resolving-merge-conflicts --agent cursor -y` | merge/rebase conflicts |
|
|
100
|
+
| `scaffold-exercises` | [mattpocock/skills](https://github.com/mattpocock/skills) | `npx skills@latest add mattpocock/skills -g --skill scaffold-exercises --agent cursor -y` | course scaffolding |
|
|
101
|
+
| `grill-with-docs` | [mattpocock/skills](https://github.com/mattpocock/skills) | `npx skills@latest add mattpocock/skills -g --skill grill-with-docs --agent cursor -y` | grill with docs |
|
|
102
|
+
| `implement` | [mattpocock/skills](https://github.com/mattpocock/skills) | `npx skills@latest add mattpocock/skills -g --skill implement --agent cursor -y` | direct implementation |
|
|
103
|
+
| `grill-me` | [mattpocock/skills](https://github.com/mattpocock/skills) | `npx skills@latest add mattpocock/skills -g --skill grill-me --agent cursor -y` | get grilled |
|
|
104
|
+
| `qa` | [mattpocock/skills](https://github.com/mattpocock/skills) | `npx skills@latest add mattpocock/skills -g --skill qa --agent cursor -y` | issue filing |
|
|
105
|
+
| `teach` | [mattpocock/skills](https://github.com/mattpocock/skills) | `npx skills@latest add mattpocock/skills -g --skill teach --agent cursor -y` | teach a topic |
|
|
106
|
+
| `chrome-devtools` | [chromedevtools/chrome-devtools-mcp](https://github.com/ChromeDevTools/chrome-devtools-mcp) | `npx skills@latest add chromedevtools/chrome-devtools-mcp -g --agent cursor -y` | browser automation |
|
|
107
|
+
|
|
108
|
+
Full pinned manifest: [`manifest/upstream-sources.txt`](manifest/upstream-sources.txt).
|
|
109
|
+
Playbooks: [`docs/playbooks/`](docs/playbooks/).
|
|
110
|
+
|
|
111
|
+
## The BAK workflow
|
|
112
|
+
|
|
113
|
+
```mermaid
|
|
114
|
+
flowchart LR
|
|
115
|
+
T[triage] --> S[to-spec] --> K[to-tickets] --> D[tdd] --> R[code-review] --> H[handoff]
|
|
116
|
+
W[wayfinder] -.->|large/uncertain| S
|
|
117
|
+
P[request-refactor-plan] -.->|refactor| K
|
|
118
|
+
bak([bak router]) -. routes .-> T
|
|
119
|
+
bak -. routes .-> D
|
|
120
|
+
bak -. routes .-> W
|
|
121
|
+
subgraph GO[Go lane]
|
|
122
|
+
GP[go-plan] --> GT[go-tdd] --> GR[go-review]
|
|
123
|
+
end
|
|
124
|
+
bak -. "go.mod / race|goroutine|channel|mutex" .-> GP
|
|
125
|
+
```
|
|
126
|
+
|
|
127
|
+
## Go-first skills
|
|
128
|
+
|
|
129
|
+
Go work gets first-principles treatment: mattpocock's conversation-first
|
|
130
|
+
phases + pstack's evidence discipline + Go's real sensors.
|
|
131
|
+
|
|
132
|
+
- **`go-plan`** — grills the design with the Go frontier taxonomy (goroutine
|
|
133
|
+
ownership, channel-vs-mutex, leak prevention, error strategy, test seams)
|
|
134
|
+
and synthesizes the spec. Human gate ON for concurrency decisions.
|
|
135
|
+
- **`go-tdd`** — implements test-first at pre-agreed seams. Fail-fast sensor
|
|
136
|
+
chain at every phase exit: `gofmt -l` → `go vet` → `golangci-lint` →
|
|
137
|
+
`govulncheck` → `go test -race` + `goleak`. Mandatory end-to-end
|
|
138
|
+
expected-outcome tests.
|
|
139
|
+
- **`go-review`** — two-axis review with lenses: perf (goperf.dev, hot paths
|
|
140
|
+
only), race (mandatory findings class), security (go.dev best practices),
|
|
141
|
+
SOLID (Cheney's five words).
|
|
142
|
+
|
|
143
|
+
All rules live in one canonical contract —
|
|
144
|
+
[`skills/go-tdd/references/GO_RULES.md`](skills/go-tdd/references/GO_RULES.md):
|
|
145
|
+
24 sensor-tagged rules in HARD/REVIEW/EVIDENCE tiers. A finding survives only
|
|
146
|
+
when a run proves it.
|
|
147
|
+
|
|
148
|
+
```mermaid
|
|
149
|
+
flowchart LR
|
|
150
|
+
GP[go-plan] -->|grilling -> to-spec| P["every shared datum named + owned"]
|
|
151
|
+
P --> G1["gate: go list / go build / go vet"]
|
|
152
|
+
G1 --> GT[go-tdd]
|
|
153
|
+
GT -->|tdd at pre-agreed seams| I[code + tests]
|
|
154
|
+
I --> G2["gate: gofmt -> vet -> golangci-lint -> govulncheck -> -race + goleak"]
|
|
155
|
+
G2 --> GR[go-review]
|
|
156
|
+
GR -->|two-axis + lenses| M[merge]
|
|
157
|
+
```
|
|
158
|
+
|
|
159
|
+
## Architecture
|
|
160
|
+
|
|
161
|
+
```mermaid
|
|
162
|
+
flowchart TD
|
|
163
|
+
subgraph UP["Upstream — source of truth"]
|
|
164
|
+
MP["mattpocock/skills 36+"]
|
|
165
|
+
VL["vercel-labs/skills"]
|
|
166
|
+
CD["chrome-devtools-mcp"]
|
|
167
|
+
end
|
|
168
|
+
subgraph REPO["bad-agent-kit — compose, never own"]
|
|
169
|
+
BAK["bak router<br/>(thin, routes only)"]
|
|
170
|
+
GO["go-plan / go-tdd / go-review<br/>(Go-first lane)"]
|
|
171
|
+
CAT["catalog table<br/>lockstep with manifest"]
|
|
172
|
+
PB["playbooks"]
|
|
173
|
+
MANIFEST["manifest/upstream-sources.txt<br/>pinned, never vendored"]
|
|
174
|
+
end
|
|
175
|
+
UP -->|pinned manifest| MANIFEST
|
|
176
|
+
MANIFEST --> CAT
|
|
177
|
+
BAK -->|routes into| UP
|
|
178
|
+
BAK --> GO
|
|
179
|
+
GO -->|reads| RULES["GO_RULES.md"]
|
|
180
|
+
CAT --> PB
|
|
181
|
+
subgraph CH["Distribution"]
|
|
182
|
+
NPM["npm → pi.dev gallery"]
|
|
183
|
+
NPX["npx skills add"]
|
|
184
|
+
CC["claude/codex plugin marketplace"]
|
|
185
|
+
end
|
|
186
|
+
REPO --> NPM
|
|
187
|
+
REPO --> NPX
|
|
188
|
+
REPO --> CC
|
|
189
|
+
```
|
|
190
|
+
|
|
191
|
+
## Repo layout
|
|
192
|
+
|
|
193
|
+
```text
|
|
194
|
+
skills/ BAK-owned skills (bak, go-plan, go-tdd, go-review)
|
|
195
|
+
manifest/ pinned upstream sources — never vendored
|
|
196
|
+
docs/playbooks/ how the skills chain in real work
|
|
197
|
+
docs/design-evidence.md decision provenance ($HOME-scrubbed)
|
|
198
|
+
scripts/ bootstrap.sh / update.sh / scrub.sh / validate-catalog.js
|
|
199
|
+
.github/ CI: privacy-scrub gate + catalog lockstep + link check
|
|
200
|
+
```
|
|
201
|
+
|
|
202
|
+
## Contributing
|
|
203
|
+
|
|
204
|
+
Catalog edits follow the lockstep rule (manifest ↔ README, CI-enforced).
|
|
205
|
+
See [CONTRIBUTING.md](CONTRIBUTING.md).
|
|
206
|
+
|
|
207
|
+
## Privacy & security
|
|
208
|
+
|
|
209
|
+
A CI privacy-scrub gate fails the build on personal literals (home paths,
|
|
210
|
+
vault names, private endpoints). This repo ships only the portable core;
|
|
211
|
+
personal overlays stay local. See
|
|
212
|
+
[docs/design-evidence.md](docs/design-evidence.md).
|
|
213
|
+
|
|
214
|
+
## Acknowledgments
|
|
215
|
+
|
|
216
|
+
- [Matt Pocock's skills](https://github.com/mattpocock/skills) — the workflow
|
|
217
|
+
stack BAK composes
|
|
218
|
+
- [cursor/plugins — pstack](https://github.com/cursor/plugins/tree/main/pstack) —
|
|
219
|
+
the evidence discipline ("a finding survives only when a run proves it")
|
|
220
|
+
- [vercel-labs/skills](https://github.com/vercel-labs/skills) — find-skills
|
|
221
|
+
- [ChromeDevTools/chrome-devtools-mcp](https://github.com/ChromeDevTools/chrome-devtools-mcp) —
|
|
222
|
+
browser automation
|
|
223
|
+
- [Effective Go](https://go.dev/doc/effective_go),
|
|
224
|
+
[Cheney's SOLID-Go](https://dave.cheney.net/2016/08/20/solid-go-design),
|
|
225
|
+
[goperf.dev](https://goperf.dev/), and
|
|
226
|
+
[go.dev security best practices](https://go.dev/doc/security/best-practices) —
|
|
227
|
+
the Go rulebook behind the go-* skills
|
|
228
|
+
|
|
229
|
+
## License
|
|
230
|
+
|
|
231
|
+
MIT — skills listed here remain property of their respective authors.
|
|
@@ -0,0 +1,35 @@
|
|
|
1
|
+
# Design Evidence — BAK (bad-agent-kit)
|
|
2
|
+
|
|
3
|
+
Provenance for the decisions in this repo. Portable and `$HOME`-scrubbed;
|
|
4
|
+
personal overlays stay local.
|
|
5
|
+
|
|
6
|
+
## Why BAK exists
|
|
7
|
+
|
|
8
|
+
The original `chief` router skill lived only on one machine. It routed every
|
|
9
|
+
workspace task through the smallest complete set of installed skills. It
|
|
10
|
+
worked — but it was unmanaged (absent from `.skill-lock.json`), its reference
|
|
11
|
+
snapshot files rotted silently, and nothing was shareable.
|
|
12
|
+
|
|
13
|
+
BAK is the same router, split in two:
|
|
14
|
+
- **Portable core** (this repo): the `bak` skill, routing matrix, shared
|
|
15
|
+
contracts (documentation routing, GitHub publishing), and playbooks.
|
|
16
|
+
- **Personal overlay** (local only): workspace paths, hook scripts, vault
|
|
17
|
+
locations, and the capability inventory.
|
|
18
|
+
|
|
19
|
+
## Decisions
|
|
20
|
+
|
|
21
|
+
1. **Compose, never own.** Upstream skills (mattpocock, vercel-labs,
|
|
22
|
+
chrome-devtools) are pinned, never vendored. BAK owns only the router and
|
|
23
|
+
the playbooks.
|
|
24
|
+
2. **Two-level brand.** BAK = serious kit; bad-agent-kit = persona whose
|
|
25
|
+
punchline encodes the rules ("never mutate on inspect, never publish
|
|
26
|
+
without authority").
|
|
27
|
+
3. **Catalog of record.** README table until ~40 entries; then
|
|
28
|
+
`catalog/catalog.json` + generator. CI enforces lockstep with the manifest
|
|
29
|
+
so the catalog can't drift.
|
|
30
|
+
4. **Privacy-scrub gate.** CI fails on personal literals — an enforced rule,
|
|
31
|
+
not a manual risk.
|
|
32
|
+
5. **One channel per agent.** Two install channels on one agent duplicates
|
|
33
|
+
skills and drifts hashes silently.
|
|
34
|
+
6. **Deferred product tax.** changesets/CHANGELOG/release CI wait until a
|
|
35
|
+
second human installs the kit.
|
|
@@ -0,0 +1,14 @@
|
|
|
1
|
+
# Playbook: diagnosis
|
|
2
|
+
|
|
3
|
+
For "diagnose this" / "it's broken" / "it's slow":
|
|
4
|
+
|
|
5
|
+
1. **diagnosing-bugs** — the diagnosis loop: reproduce, bisect, root-cause,
|
|
6
|
+
smallest fix.
|
|
7
|
+
2. **grilling** (or `grill-with-docs`) — stress-test the proposed fix against
|
|
8
|
+
the docs before implementing.
|
|
9
|
+
3. **prototype** — when the fix's shape is uncertain, throwaway prototype to
|
|
10
|
+
answer the design question.
|
|
11
|
+
4. **code-review** — after the fix, review standards + spec axes.
|
|
12
|
+
|
|
13
|
+
Sensors: the failing sensor gets re-run after every fix; flaky/always-green
|
|
14
|
+
sensors are weak evidence.
|
|
@@ -0,0 +1,23 @@
|
|
|
1
|
+
# Playbook: feature work (the BAK default chain)
|
|
2
|
+
|
|
3
|
+
The chain used for real feature work. Each step is an installed skill; `bak`
|
|
4
|
+
routes into the right entry point.
|
|
5
|
+
|
|
6
|
+
```mermaid
|
|
7
|
+
flowchart LR
|
|
8
|
+
A[triage] --> B[to-spec] --> C[to-tickets] --> D[tdd] --> E[code-review] --> F[handoff]
|
|
9
|
+
G[wayfinder] -. large or uncertain .-> B
|
|
10
|
+
H[request-refactor-plan] -. refactor .-> C
|
|
11
|
+
```
|
|
12
|
+
|
|
13
|
+
1. **triage** — intake the issue/request; confirm labels, tracker state, and
|
|
14
|
+
confirmation steps before any Matt Pocock workflow.
|
|
15
|
+
2. **to-spec** — synthesize the plan; produce the spec document.
|
|
16
|
+
3. **to-tickets** — split the spec into executable tracer-bullet tickets.
|
|
17
|
+
4. **tdd** — implement each ticket test-first (red → green → refactor).
|
|
18
|
+
5. **code-review** — review the branch along standards + spec axes.
|
|
19
|
+
6. **handoff** — close the loop: summary, remaining risks, learning captured.
|
|
20
|
+
|
|
21
|
+
**Sensors throughout**: prehook.sh before material changes, posthook.sh after,
|
|
22
|
+
prepush.sh only immediately before a user-authorized push. Fast deterministic
|
|
23
|
+
checks first, broader checks proportional to risk.
|
|
@@ -0,0 +1,28 @@
|
|
|
1
|
+
# Playbook: Go work (the go-* chain)
|
|
2
|
+
|
|
3
|
+
Go module work routes through the go-* family; bak stays the orchestrator.
|
|
4
|
+
|
|
5
|
+
```mermaid
|
|
6
|
+
flowchart LR
|
|
7
|
+
GP[go-plan] -->|grilling -> to-spec| P["every shared datum named + owned"]
|
|
8
|
+
P --> G1["gate: go list / go build / go vet"]
|
|
9
|
+
G1 --> GT[go-tdd]
|
|
10
|
+
GT -->|tdd at pre-agreed seams| I[code + tests]
|
|
11
|
+
I --> G2["gate: gofmt -> vet -> golangci-lint -> govulncheck -> -race + goleak"]
|
|
12
|
+
G2 --> GR[go-review]
|
|
13
|
+
GR -->|two-axis + lenses| M[merge]
|
|
14
|
+
```
|
|
15
|
+
|
|
16
|
+
1. **go-plan** — grill with the five frontier questions (ownership,
|
|
17
|
+
channel-vs-mutex, leaks, error strategy, seam); synthesize the spec. Human
|
|
18
|
+
gate ON for concurrency decisions. Exit: plan artifact names every shared
|
|
19
|
+
datum and its owner; pre-flight `go list / go build / go vet`.
|
|
20
|
+
2. **go-tdd** — implement at pre-agreed seams via tdd; fail-fast sensor chain
|
|
21
|
+
at every phase exit; mandatory end-to-end expected-outcome test (real
|
|
22
|
+
binary against the real artifact).
|
|
23
|
+
3. **go-review** — two-axis review with the Go lenses (perf/race/security/
|
|
24
|
+
solid); race findings are a mandatory class gated on `-race`; rules-rot
|
|
25
|
+
upkeep at close.
|
|
26
|
+
|
|
27
|
+
Contract: `skills/go-tdd/references/GO_RULES.md` is shared between go-tdd and
|
|
28
|
+
go-review — never restate rules locally.
|
|
@@ -0,0 +1,10 @@
|
|
|
1
|
+
# Playbook: research & documentation
|
|
2
|
+
|
|
3
|
+
1. **find-docs** — current primary docs for any library/SDK/CLI question;
|
|
4
|
+
never trust training data for API details.
|
|
5
|
+
2. **research** — high-trust primary-source investigation, findings captured
|
|
6
|
+
as a Markdown file in the repo.
|
|
7
|
+
3. **domain-modeling** — record durable terminology (GLOSSARY.md / ADR).
|
|
8
|
+
|
|
9
|
+
Docs routing contract: OpenAI products → official OpenAI route; everything
|
|
10
|
+
else → Context7. See `skills/bak/references/documentation-routing.md`.
|
package/package.json
CHANGED
|
@@ -1,6 +1,36 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "bad-agent-kit",
|
|
3
|
-
"version": "0.
|
|
4
|
-
"
|
|
5
|
-
"
|
|
6
|
-
|
|
3
|
+
"version": "0.1.0",
|
|
4
|
+
"description": "BAK — bad-agent-kit: a curated skills marketplace + workflow orchestrator. The router that keeps you from being one. Compose, never own.",
|
|
5
|
+
"license": "MIT",
|
|
6
|
+
"keywords": [
|
|
7
|
+
"pi-package",
|
|
8
|
+
"pi",
|
|
9
|
+
"agent-skills",
|
|
10
|
+
"skills",
|
|
11
|
+
"claude-code",
|
|
12
|
+
"codex",
|
|
13
|
+
"workflow-orchestrator",
|
|
14
|
+
"mattpocock"
|
|
15
|
+
],
|
|
16
|
+
"scripts": {
|
|
17
|
+
"prepublishOnly": "bash scripts/scrub.sh && node scripts/validate-catalog.js",
|
|
18
|
+
"test": "node scripts/validate-catalog.js"
|
|
19
|
+
},
|
|
20
|
+
"files": [
|
|
21
|
+
"skills",
|
|
22
|
+
"docs",
|
|
23
|
+
"README.md",
|
|
24
|
+
"GLOSSARY.md",
|
|
25
|
+
"LICENSE"
|
|
26
|
+
],
|
|
27
|
+
"pi": {
|
|
28
|
+
"skills": ["./skills/bak", "./skills/go-plan", "./skills/go-tdd", "./skills/go-review"],
|
|
29
|
+
"changelogPath": "CHANGELOG.md"
|
|
30
|
+
},
|
|
31
|
+
"peerDependencies": {
|
|
32
|
+
"@earendil-works/pi-ai": "*",
|
|
33
|
+
"@earendil-works/pi-agent-core": "*",
|
|
34
|
+
"@earendil-works/pi-coding-agent": "*"
|
|
35
|
+
}
|
|
36
|
+
}
|
|
@@ -0,0 +1,108 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: bak
|
|
3
|
+
description: formerly chief — Route and orchestrate every workspace task through the smallest complete set of installed skills, plugins, repository guidance, tools, feedback sensors, and durable learning surfaces. Use at the start of every task under your workspace, when the right workflow is unclear, when work crosses repositories or capabilities, or when deciding whether repeated workspace behavior should become an AGENTS.md rule, skill, hook, MCP app, or plugin.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# BAK — bad-agent-kit
|
|
7
|
+
|
|
8
|
+
Thin workspace router, batman-flavored: preserve the user's real objective,
|
|
9
|
+
select the right capability, coordinate its workflow, verify the result, and
|
|
10
|
+
capture only durable learning. Don't ship the bad agent kit — never mutate on
|
|
11
|
+
inspect, never publish without authority. Do not duplicate the detailed
|
|
12
|
+
instructions owned by routed skills.
|
|
13
|
+
|
|
14
|
+
## Route every task
|
|
15
|
+
|
|
16
|
+
1. Extract the goal, target, constraints, authority, and proof of completion.
|
|
17
|
+
2. Identify the active repository or workspace surface. Read the applicable
|
|
18
|
+
instruction chain and inspect repository state only when relevant.
|
|
19
|
+
3. Read [routing-matrix.md](references/routing-matrix.md). Select the smallest
|
|
20
|
+
complete route; use no specialist skill when ordinary reasoning or a direct
|
|
21
|
+
edit is sufficient.
|
|
22
|
+
4. Treat explicitly named skills as mandatory. Apply system and developer
|
|
23
|
+
trigger rules before this router. Never invent a skill or assume a connector
|
|
24
|
+
is available.
|
|
25
|
+
5. Announce the selected skills and their order when a skill is used. Then
|
|
26
|
+
follow each selected `SKILL.md` faithfully.
|
|
27
|
+
6. Execute within the user's authority. Do not turn a request to inspect,
|
|
28
|
+
explain, review, or diagnose into an unrequested mutation or publication.
|
|
29
|
+
7. Run the feedback loop and verify the actual completion criteria before
|
|
30
|
+
reporting success.
|
|
31
|
+
|
|
32
|
+
Do not invoke `bak` recursively. Do not chain one user-invoked Matt Pocock
|
|
33
|
+
orchestrator into another silently. When such a workflow is the best top-level
|
|
34
|
+
route, select it once and let it call only the model-invoked disciplines it
|
|
35
|
+
permits.
|
|
36
|
+
|
|
37
|
+
## Orient before engineering routes
|
|
38
|
+
|
|
39
|
+
- Find the Git/project root, current branch, dirty state, relevant `AGENTS.md`,
|
|
40
|
+
`CLAUDE.md`, `README.md`, `CONTEXT.md`, ADRs, and commands.
|
|
41
|
+
- Preserve unrelated user changes.
|
|
42
|
+
- Before using tracker-aware Matt Pocock workflows, check for
|
|
43
|
+
`docs/agents/issue-tracker.md`, `domain.md`, and, when `triage` is installed,
|
|
44
|
+
`triage-labels.md`. If missing or inconsistent, route to
|
|
45
|
+
`$setup-matt-pocock-skills` and honor its confirmation steps.
|
|
46
|
+
- Prefer repo-specific terms, commands, and acceptance checks over workspace
|
|
47
|
+
defaults.
|
|
48
|
+
- In a Go module (go.mod present): note the module layout and go directive
|
|
49
|
+
version floor before entering any phase; Go triggers route to the `go-*`
|
|
50
|
+
family (see routing matrix).
|
|
51
|
+
|
|
52
|
+
## Use guides and sensors
|
|
53
|
+
|
|
54
|
+
Before acting, load the cheapest relevant feedforward guides: instructions,
|
|
55
|
+
domain context, ADRs, specifications, examples, and current primary docs.
|
|
56
|
+
|
|
57
|
+
After acting, run feedback sensors from cheapest and most deterministic to more
|
|
58
|
+
expensive and inferential:
|
|
59
|
+
|
|
60
|
+
1. Formatter, linter, type checker, focused tests, static or structural checks.
|
|
61
|
+
2. Broader tests, build, runtime logs, browser or integration checks when the
|
|
62
|
+
blast radius warrants them.
|
|
63
|
+
3. Diff/spec review, security and maintainability review, then human review for
|
|
64
|
+
judgment or irreversible decisions.
|
|
65
|
+
|
|
66
|
+
For material code changes in a child repo under `$HOME/code`, use
|
|
67
|
+
`$HOME/code/.codex/hooks/prehook.sh <repo-root>` as an orientation
|
|
68
|
+
sensor unless the repo provides a more precise equivalent. After the change,
|
|
69
|
+
use `$HOME/code/.codex/hooks/posthook.sh <repo-root>` as a baseline,
|
|
70
|
+
then add the repo-specific checks the task requires. Run
|
|
71
|
+
`prepush.sh <repo-root>` only immediately before a user-authorized push. These
|
|
72
|
+
scripts are sensors, not substitutes for repository instructions or judgment.
|
|
73
|
+
|
|
74
|
+
## Route current documentation
|
|
75
|
+
|
|
76
|
+
For library, framework, SDK, API, CLI, or cloud-service questions, read and
|
|
77
|
+
follow [documentation-routing.md](references/documentation-routing.md).
|
|
78
|
+
|
|
79
|
+
## Route GitHub publication
|
|
80
|
+
|
|
81
|
+
For GitHub authentication, issue/PR publication, sub-issues, or network checks,
|
|
82
|
+
read and follow [github-publishing.md](references/github-publishing.md).
|
|
83
|
+
Drafting is not publication; obtain explicit user authority before publishing,
|
|
84
|
+
pushing, merging, or changing remote state.
|
|
85
|
+
|
|
86
|
+
## Learn without bloating the harness
|
|
87
|
+
|
|
88
|
+
- Capture task facts in the repository that owns them. Use the canonical knowledge vault through
|
|
89
|
+
`$obsidian-vault` for cross-workspace research,
|
|
90
|
+
planning, documentation, learning-loop updates, routing lessons, and plugin
|
|
91
|
+
candidates.
|
|
92
|
+
- Search before creating; update the narrowest existing note; never store
|
|
93
|
+
secrets, credentials, raw private content, or noisy transcripts.
|
|
94
|
+
- Assess the Learn step at the end of every task. Update an existing vault note
|
|
95
|
+
or its learning loop when the result is verified and reusable; do not create
|
|
96
|
+
a note merely to log routine activity.
|
|
97
|
+
- After the same meaningful failure happens twice, record the pattern and
|
|
98
|
+
propose the smallest durable control: deterministic tool or hook first when
|
|
99
|
+
mechanically enforceable; repo doc for repo facts; `AGENTS.md` for durable
|
|
100
|
+
conventions; skill for a reusable workflow; MCP/app for live external data;
|
|
101
|
+
plugin for a stable shareable bundle.
|
|
102
|
+
|
|
103
|
+
## Finish clearly
|
|
104
|
+
|
|
105
|
+
Report the outcome, changed artifacts, checks run, skipped checks, remaining
|
|
106
|
+
risks, and any durable learning captured. A task is complete only when its
|
|
107
|
+
actual acceptance conditions are evidenced; otherwise keep working or state the
|
|
108
|
+
specific blocker.
|
|
@@ -0,0 +1,42 @@
|
|
|
1
|
+
# Current Documentation Routing
|
|
2
|
+
|
|
3
|
+
## OpenAI and Codex
|
|
4
|
+
|
|
5
|
+
Use `$openai-docs` and its official-source route for OpenAI products, APIs,
|
|
6
|
+
models, and Codex behavior. Do not send OpenAI product questions through
|
|
7
|
+
Context7 when the official Codex manual or OpenAI developer documentation owns
|
|
8
|
+
the answer.
|
|
9
|
+
|
|
10
|
+
## Other developer technologies
|
|
11
|
+
|
|
12
|
+
Use `$find-docs`, then use the `ctx7` CLI for every library, framework, SDK,
|
|
13
|
+
API, CLI tool, or cloud-service question, including syntax, configuration,
|
|
14
|
+
migrations, setup, library-specific debugging, and CLI usage.
|
|
15
|
+
|
|
16
|
+
Do not use Context7 for refactoring, scripts written from scratch, business
|
|
17
|
+
logic debugging, code review, or general programming concepts.
|
|
18
|
+
|
|
19
|
+
1. Resolve the official library name:
|
|
20
|
+
|
|
21
|
+
```bash
|
|
22
|
+
npx ctx7@latest library <name> "<full user question>"
|
|
23
|
+
```
|
|
24
|
+
|
|
25
|
+
2. Select the best `/org/project` result by exact name, relevant description,
|
|
26
|
+
snippet count, High/Medium source reputation, and benchmark score. Retry with
|
|
27
|
+
an alternate official name or sharper query only when results are wrong.
|
|
28
|
+
3. Fetch the documentation:
|
|
29
|
+
|
|
30
|
+
```bash
|
|
31
|
+
npx ctx7@latest docs <libraryId> "<full user question>"
|
|
32
|
+
```
|
|
33
|
+
|
|
34
|
+
Use `/org/project/version` for version-specific documentation. Resolve first
|
|
35
|
+
unless the user supplied a valid `/org/project` ID. Run at most three Context7
|
|
36
|
+
commands per question and never include secrets or credentials in queries.
|
|
37
|
+
|
|
38
|
+
Run Context7 outside the default sandbox. If an in-sandbox call reports DNS,
|
|
39
|
+
`ENOTFOUND`, host-resolution, or fetch failures, rerun that specific command
|
|
40
|
+
outside the sandbox. On quota errors, tell the user and suggest
|
|
41
|
+
`npx ctx7@latest login` or `CONTEXT7_API_KEY`; do not silently answer from model
|
|
42
|
+
memory.
|
|
@@ -0,0 +1,34 @@
|
|
|
1
|
+
# GitHub Publishing Contract
|
|
2
|
+
|
|
3
|
+
- Draft locally unless the user explicitly authorizes publishing, pushing,
|
|
4
|
+
merging, creating an issue/PR, commenting, or changing remote state.
|
|
5
|
+
- Use `gh` for GitHub Issues; SSH proves git transport, not GitHub API access.
|
|
6
|
+
- For explicit access, authentication, reachability, permissions, PR, issue, or
|
|
7
|
+
Actions checks, run the relevant `gh` or git network command outside the
|
|
8
|
+
default sandbox. Start with `gh auth status`.
|
|
9
|
+
- If the token is invalid, ask the user to run `gh auth login -h github.com`.
|
|
10
|
+
- If DNS or API access fails despite working local credentials, retry the
|
|
11
|
+
specific command outside the sandbox. If it still fails, report the failure
|
|
12
|
+
and suggest checking VPN/proxy DNS.
|
|
13
|
+
- For pushes, use the existing working remote/auth transport; do not force SSH
|
|
14
|
+
or HTTPS.
|
|
15
|
+
|
|
16
|
+
## Parent and child issues
|
|
17
|
+
|
|
18
|
+
When publishing an epic/PRD with implementation tickets, create real GitHub
|
|
19
|
+
sub-issue relationships rather than relying only on Markdown links:
|
|
20
|
+
|
|
21
|
+
1. Create the parent and child issues with `gh issue create`.
|
|
22
|
+
2. Resolve their node IDs:
|
|
23
|
+
|
|
24
|
+
```bash
|
|
25
|
+
gh api graphql -f owner=OWNER -f name=REPO -F parent=PARENT_NUMBER -F child=CHILD_NUMBER -f query='query($owner:String!, $name:String!, $parent:Int!, $child:Int!) { repository(owner:$owner, name:$name) { parent: issue(number:$parent) { id url } child: issue(number:$child) { id url } } }'
|
|
26
|
+
```
|
|
27
|
+
|
|
28
|
+
3. Attach each child:
|
|
29
|
+
|
|
30
|
+
```bash
|
|
31
|
+
gh api graphql -f parentId=PARENT_NODE_ID -f childId=CHILD_NODE_ID -f query='mutation($parentId:ID!, $childId:ID!) { addSubIssue(input:{issueId:$parentId, subIssueId:$childId}) { issue { id } subIssue { id } } }'
|
|
32
|
+
```
|
|
33
|
+
|
|
34
|
+
Create in dependency order and attach every implementation issue to the parent.
|
|
@@ -0,0 +1,117 @@
|
|
|
1
|
+
# Chief Routing Matrix
|
|
2
|
+
|
|
3
|
+
Use this matrix as a decision aid, not a reason to invoke every matching skill.
|
|
4
|
+
Explicit user skill mentions and current skill trigger rules win. Prefer one
|
|
5
|
+
top-level workflow plus only the supporting disciplines it needs.
|
|
6
|
+
|
|
7
|
+
## Matt Pocock engineering and productivity routes
|
|
8
|
+
|
|
9
|
+
| Intent | Primary route | Supporting route or constraint |
|
|
10
|
+
|---|---|---|
|
|
11
|
+
| Configure a repo for this suite | `$setup-matt-pocock-skills` | Run once per repo; confirm tracker and labels before writing |
|
|
12
|
+
| Ask which Matt workflow fits | `$ask-matt` | Use only when explicitly requested; `chief` otherwise routes directly |
|
|
13
|
+
| Stress-test a code plan while building domain docs | `$grill-with-docs` | May use `$grilling` and `$domain-modeling` |
|
|
14
|
+
| Stress-test a general plan | `$grill-me` or `$grilling` | Interview before implementation |
|
|
15
|
+
| Triage issues or external PRs | `$triage` | Requires configured tracker and label vocabulary |
|
|
16
|
+
| Synthesize an already-discussed spec | `$to-spec` | Do not add a new interview unless required by the skill |
|
|
17
|
+
| Split scope into tracer-bullet tickets | `$to-tickets` | Preserve blocking edges and configured tracker |
|
|
18
|
+
| Implement an accepted spec or tickets | `$implement` | Use `$tdd` at agreed seams and `$code-review` before close |
|
|
19
|
+
| Map a task larger than one session | `$wayfinder` or `$decision-mapping` | Use tracker-backed decision tickets when configured |
|
|
20
|
+
| Prototype a state, logic, or UI question | `$prototype` | Throwaway evidence, not production code |
|
|
21
|
+
| Diagnose broken, failing, flaky, or slow behavior | `$diagnosing-bugs` | Reproduce before fixing; add regression coverage |
|
|
22
|
+
| Build or fix test-first | `$tdd` | Red, green, refactor in vertical slices |
|
|
23
|
+
| Establish terminology or record decisions | `$domain-modeling` | Update `CONTEXT.md` or ADRs only when the repo owns them |
|
|
24
|
+
| Design deep module seams/interfaces | `$codebase-design` | Prefer narrow interfaces with hidden complexity |
|
|
25
|
+
| Scan for architectural deepening opportunities | `$improve-codebase-architecture` | Use for an explicit architecture audit, not routine edits |
|
|
26
|
+
| Review a diff against standards and spec | `$code-review` | Its parallel-agent behavior still requires applicable permission |
|
|
27
|
+
| Run a conversational QA session and file findings | `$qa` | Treat publication as external mutation and require its configured tracker |
|
|
28
|
+
| Plan a safe incremental refactor | `$request-refactor-plan` | Interview, design tiny commits, and publish only with authority |
|
|
29
|
+
| Resolve an active merge or rebase | `$resolving-merge-conflicts` | Resolve by intent and primary history; do not abort silently |
|
|
30
|
+
| Produce continuation context | `$handoff` | Use when the user asks or continuity materially needs it |
|
|
31
|
+
| Teach over multiple sessions | `$teach` | Keep state in the teaching workspace |
|
|
32
|
+
| Write or revise a skill | `$skill-creator` plus `$writing-great-skills` | Validate and forward-test when permitted |
|
|
33
|
+
|
|
34
|
+
## Engineering, documentation, and extension routes
|
|
35
|
+
|
|
36
|
+
| Intent | Route |
|
|
37
|
+
|---|---|
|
|
38
|
+
| Current docs for non-OpenAI developer technology | `$find-docs`, then the Context7 contract in `documentation-routing.md` |
|
|
39
|
+
| OpenAI or Codex behavior/docs | `$openai-docs` |
|
|
40
|
+
| Research from primary sources into Markdown | `$research` |
|
|
41
|
+
| Browser debugging, automation, performance, network inspection | `$chrome-devtools` |
|
|
42
|
+
| UI/product flow critique | `$product-design:index`, which selects `$product-design:audit` or its own subflow |
|
|
43
|
+
| Visual variants or bitmap generation/editing | `$imagegen`; use `$product-design:ideate` for product-design exploration |
|
|
44
|
+
| Implement a screenshot/mockup | `$product-design:image-to-code` |
|
|
45
|
+
| Clone a live frontend URL | `$product-design:url-to-code` |
|
|
46
|
+
| Create/update a reusable skill | `$skill-creator` |
|
|
47
|
+
| Discover/install skills | `$find-skills` or `$skill-installer` |
|
|
48
|
+
| Create/package a stable Codex plugin | `$plugin-creator` |
|
|
49
|
+
| Set up Husky pre-commit checks | `$setup-pre-commit` |
|
|
50
|
+
| Add Claude Code destructive-git hooks | `$git-guardrails-claude-code` |
|
|
51
|
+
| Migrate tests to shoehorn | `$migrate-to-shoehorn` |
|
|
52
|
+
| Scaffold course exercises | `$scaffold-exercises` |
|
|
53
|
+
| Operate or debug Hatchet workflows | `$hatchet-cli` |
|
|
54
|
+
| Create a manual setup wizard | `$wizard` |
|
|
55
|
+
| Explore, shape, or edit prose | `$writing-fragments` -> `$writing-beats` -> `$writing-shape`; `$edit-article` for revision |
|
|
56
|
+
|
|
57
|
+
## Connected-service and plugin routes
|
|
58
|
+
|
|
59
|
+
| Intent | Route |
|
|
60
|
+
|---|---|
|
|
61
|
+
| General GitHub repository, issue, or PR context | `$github:github` |
|
|
62
|
+
| Fix GitHub Actions checks | `$github:gh-fix-ci` |
|
|
63
|
+
| Address PR review comments | `$github:gh-address-comments` |
|
|
64
|
+
| Commit, push, and open a draft PR | `$github:yeet`, only with explicit publication authority |
|
|
65
|
+
| Gmail search, summary, drafting, or triage | `$gmail:gmail` or `$gmail:gmail-inbox-triage` |
|
|
66
|
+
| Calendar scheduling or briefs | The narrowest `$google-calendar:*` skill |
|
|
67
|
+
| Drive, Docs, Sheets, Slides, or Drive comments | The narrowest `$google-drive:*` skill |
|
|
68
|
+
| Notion CLI setup/authentication, general page or data-source CRUD, comments, files, terminal automation, or explicit no-MCP work | `$notion-cli` |
|
|
69
|
+
| Notion capture, research, meeting prep, or spec implementation through the connected Notion app | The narrowest `$notion:*` skill; requires its MCP/app tools |
|
|
70
|
+
| Sales workflow | `$sales:index` first, then its selected focused skill |
|
|
71
|
+
| Obsidian knowledge search or capture | `$obsidian-vault` |
|
|
72
|
+
|
|
73
|
+
### Choose the Notion transport
|
|
74
|
+
|
|
75
|
+
1. Honor an explicitly named skill or transport first. `$notion-cli`, `ntn`,
|
|
76
|
+
terminal, automation, and no-MCP requests route to `$notion-cli`; an explicit
|
|
77
|
+
`$notion:*` request keeps that specialist workflow and its connector.
|
|
78
|
+
2. For an unqualified general read/write task, use `$notion-cli` when its
|
|
79
|
+
advertised skill and authenticated CLI are available. It owns direct page,
|
|
80
|
+
block, property, data-source, comment, and file operations.
|
|
81
|
+
3. Use the narrowest `$notion:*` skill when its semantic workflow—knowledge
|
|
82
|
+
capture, research synthesis, meeting intelligence, or spec-to-implementation—
|
|
83
|
+
materially improves the task and the connected Notion app is available.
|
|
84
|
+
Prove availability from callable Notion tools in the current session or a
|
|
85
|
+
successful tool call; an advertised skill alone is not evidence of a live
|
|
86
|
+
connector.
|
|
87
|
+
4. Do not select both transports for the same operation or silently switch after
|
|
88
|
+
an auth/tool failure. Follow the selected skill's setup flow or ask before
|
|
89
|
+
changing transports; authentication and mutation authority do not transfer.
|
|
90
|
+
5. Account for capability differences: hosted Notion MCP can search connected
|
|
91
|
+
external sources when the workspace plan permits it, while `$notion-cli`
|
|
92
|
+
follows the official CLI and public API surface.
|
|
93
|
+
|
|
94
|
+
## Go routes
|
|
95
|
+
|
|
96
|
+
| Intent | Primary route | Supporting route or constraint |
|
|
97
|
+
|---|---|---|
|
|
98
|
+
| Plan a Go feature or change | `$go-plan` | Grill before implementation; every shared datum named and owned |
|
|
99
|
+
| Implement an accepted Go spec | `$go-tdd` | Use `$go-review` before close; sensor gates at every phase exit |
|
|
100
|
+
| Review Go changes | `$go-review` | Two-axis: standards (GO_RULES.md) and spec |
|
|
101
|
+
|
|
102
|
+
Go triggers (`race`, `goroutine`, `channel`, `mutex`, `deadlock`, `leak`, or a
|
|
103
|
+
`go.mod` in the active repo) route to the `go-*` family; bak remains the sole
|
|
104
|
+
phase orchestrator — the go skills delegate to grilling/to-spec/tdd/code-review,
|
|
105
|
+
they do not replace them.
|
|
106
|
+
|
|
107
|
+
## Fallback rules
|
|
108
|
+
|
|
109
|
+
1. Use an explicitly named skill even if the matrix suggests another route.
|
|
110
|
+
2. Use the advertised skill catalog before scanning disk. Disk discovery may
|
|
111
|
+
find unavailable, disabled, stale, or malformed skills; verify before use.
|
|
112
|
+
3. If two routes overlap, choose the more specific one and use the other only
|
|
113
|
+
for a distinct supporting job.
|
|
114
|
+
4. If no skill materially improves the task, proceed directly with ordinary
|
|
115
|
+
reasoning and the relevant tools.
|
|
116
|
+
5. Do not use a connector unless it is present and authorized in the current
|
|
117
|
+
session. Do not substitute public web search for private connected data.
|
|
@@ -0,0 +1,42 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: go-plan
|
|
3
|
+
description: Plan a Go feature or change. Grill the design with the Go frontier taxonomy (goroutine ownership, channel-vs-mutex, leak prevention, error strategy, test seams) and synthesize an accepted spec. Use when planning Go work under your workspace before any Go implementation, or when Go triggers appear (race, goroutine, channel, mutex, deadlock, leak).
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# go-plan
|
|
7
|
+
|
|
8
|
+
Explicit-only wrapper — the real mechanics live in the skills this delegates to.
|
|
9
|
+
Never re-implement their loops here.
|
|
10
|
+
|
|
11
|
+
## Mechanics
|
|
12
|
+
|
|
13
|
+
1. Call the Skill tool with **grilling** — run its full interview loop, driven
|
|
14
|
+
by the Go frontier taxonomy in
|
|
15
|
+
[go-frontier-questions.md](references/go-frontier-questions.md). Human gate
|
|
16
|
+
is ON for every concurrency-relevant decision (ownership, channel-vs-mutex,
|
|
17
|
+
goroutine lifecycle, error strategy); opt-in elsewhere.
|
|
18
|
+
2. Call the Skill tool with **to-spec** — synthesize the plan with no second
|
|
19
|
+
interview. The spec must name every shared datum and its owner.
|
|
20
|
+
|
|
21
|
+
## Grill rule (from pstack)
|
|
22
|
+
|
|
23
|
+
A finding survives only when a run proves it. Every grill question carries the
|
|
24
|
+
sensor that would prove its answer. "Never hand the human a check you could
|
|
25
|
+
run." Every claim in the plan is labeled measured / inferred / guess.
|
|
26
|
+
|
|
27
|
+
## Exit gate
|
|
28
|
+
|
|
29
|
+
Every goroutine, channel, lock, and shared datum is **named and owned**; the
|
|
30
|
+
plan pre-flights with `go list`, `go build`, `go vet` (zero findings) before
|
|
31
|
+
implementation starts.
|
|
32
|
+
|
|
33
|
+
## Lens → sensor quick map
|
|
34
|
+
|
|
35
|
+
| Concern | Proving sensor |
|
|
36
|
+
|---|---|
|
|
37
|
+
| data races / ownership | `go test -race` (fires only on executed paths) |
|
|
38
|
+
| goroutine leaks | `goleak.VerifyNone`, pprof goroutine profile |
|
|
39
|
+
| sync-primitive copying | `go vet -copylocks` |
|
|
40
|
+
| error handling | `errcheck`, `errorlint`, `wrapcheck` |
|
|
41
|
+
| cancellation | ctx in every blocking `select` |
|
|
42
|
+
| end-to-end outcome | real binary against the real artifact (required) |
|
|
@@ -0,0 +1,70 @@
|
|
|
1
|
+
# Go Frontier Questions
|
|
2
|
+
|
|
3
|
+
Drive the grilling interview with these five. Each carries the research-backed
|
|
4
|
+
recommended answer and the sensor that proves it.
|
|
5
|
+
|
|
6
|
+
## 1. Ownership — which goroutine owns this shared value?
|
|
7
|
+
|
|
8
|
+
**Recommended (Effective Go + Share-by-Communicating codewalk):** transfer of
|
|
9
|
+
ownership via channels. A shared value has exactly one goroutine-owner at any
|
|
10
|
+
moment: "sending a Resource pointer on a channel passes ownership of the
|
|
11
|
+
underlying data from the sender to the receiver." Producer closes its outbound
|
|
12
|
+
channel after the last send; consumers range until close.
|
|
13
|
+
|
|
14
|
+
- After sending a value on a channel, never touch it again.
|
|
15
|
+
- Only the goroutine that owns an outbound channel may close it.
|
|
16
|
+
|
|
17
|
+
**Sensor:** `go test -race` catches unsynchronized send/close; `go vet -copylocks`
|
|
18
|
+
catches mutex copying. Ownership itself is a convention — sensors catch its
|
|
19
|
+
violations.
|
|
20
|
+
|
|
21
|
+
## 2. Channel or mutex — or eliminate the sharing entirely?
|
|
22
|
+
|
|
23
|
+
**Recommended (Go wiki MutexOrChannel + 100 Go Mistakes #57):** parallel
|
|
24
|
+
goroutines mutating shared data → mutex; concurrent goroutines coordinating or
|
|
25
|
+
transferring ownership → channel. First ask: can we eliminate the shared write
|
|
26
|
+
target entirely (pstack: separate-before-serializing-shared-state)? "We need a
|
|
27
|
+
lock" is a smell to justify, not a default answer.
|
|
28
|
+
|
|
29
|
+
- Ownership transfer → channel
|
|
30
|
+
- Caches/guarded state → mutex (non-pointer, non-embedded field)
|
|
31
|
+
- Read-mostly → `sync.RWMutex`
|
|
32
|
+
- Single-word state / copy-on-write → atomic
|
|
33
|
+
- Semaphore / rate limit → buffered channel
|
|
34
|
+
- Buffer capacity 0 or 1, or a documented justification (Uber)
|
|
35
|
+
|
|
36
|
+
**Sensor:** `-race` clean for whatever mode is chosen; `go test -timeout` for
|
|
37
|
+
coordination hangs.
|
|
38
|
+
|
|
39
|
+
## 3. Leak prevention — how does every goroutine exit?
|
|
40
|
+
|
|
41
|
+
**Recommended (go.dev pipelines + context + errgroup):** the caller that starts
|
|
42
|
+
work owns its lifetime: `ctx, cancel := ...; defer cancel()`. Every blocking
|
|
43
|
+
send/receive wrapped in `select { case ch <- v: case <-ctx.Done(): return }`.
|
|
44
|
+
Owner closes channels (`defer close(out)`). Prefer `errgroup.WithContext` over
|
|
45
|
+
raw WaitGroup when errors exist; `wg.Add` before `go`, `defer wg.Done()`.
|
|
46
|
+
Buffer size 1 for "send one result" channels. Any package that starts
|
|
47
|
+
goroutines gets `goleak.VerifyNone` in tests.
|
|
48
|
+
|
|
49
|
+
**Sensor:** `goleak.VerifyNone` / `VerifyTestMain`; pprof goroutine profile in
|
|
50
|
+
production.
|
|
51
|
+
|
|
52
|
+
## 4. Error strategy — sentinel, wrap, or opaque?
|
|
53
|
+
|
|
54
|
+
**Recommended (Cheney SOLID-Go + Go 1.13 blog + Google best-practices):**
|
|
55
|
+
opaque errors preferred; when callers must branch, assert behavior not type
|
|
56
|
+
(`Temporary() bool` probes, `errors.Is` on narrow contracts). `%w` by default
|
|
57
|
+
in-app; `%v` at API/system boundaries to hide third-party internals. Handle
|
|
58
|
+
once — log XOR return, never both. Libraries return and wrap; only the
|
|
59
|
+
top-level handler (main/HTTP) logs or maps to status codes.
|
|
60
|
+
|
|
61
|
+
**Sensor:** `errcheck`, `errorlint`, `wrapcheck`, `staticcheck` ST1005.
|
|
62
|
+
|
|
63
|
+
## 5. Test seam — where do tests live?
|
|
64
|
+
|
|
65
|
+
**Required:** the highest possible package boundary or exported identifier that
|
|
66
|
+
lets an implementer build without asking another question. Fixes the TDD
|
|
67
|
+
vertical slices. **End-to-end expected-outcome tests are mandatory**: the
|
|
68
|
+
expected outcome is an acceptance condition, and acceptance conditions must be
|
|
69
|
+
tested — at least one test runs the real binary against the real artifact, not
|
|
70
|
+
a mocked approximation.
|
|
@@ -0,0 +1,28 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: go-review
|
|
3
|
+
description: Review Go changes on two axes — standards (GO_RULES.md, Effective Go, SOLID-Go, security best practices, goperf lenses) and spec. Use when reviewing Go changes before merge.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# go-review
|
|
7
|
+
|
|
8
|
+
Explicit-only wrapper. Call the Skill tool with **code-review** on its two
|
|
9
|
+
parallel axes; inject the Go specifics below into both review contexts.
|
|
10
|
+
|
|
11
|
+
## Standards axis — Go sources
|
|
12
|
+
|
|
13
|
+
- `../go-tdd/references/GO_RULES.md` — the canonical contract (read it; do not restate it)
|
|
14
|
+
- Effective Go — https://go.dev/doc/effective_go
|
|
15
|
+
- SOLID Go design — https://dave.cheney.net/2016/08/20/solid-go-design
|
|
16
|
+
- Security best practices — https://go.dev/doc/security/best-practices
|
|
17
|
+
- Performance — https://goperf.dev (hot paths only)
|
|
18
|
+
|
|
19
|
+
## Lenses
|
|
20
|
+
|
|
21
|
+
`references/lenses/` — perf, race, security, solid. Race/concurrency findings
|
|
22
|
+
are a mandatory findings class, gated on `go test -race`.
|
|
23
|
+
|
|
24
|
+
## Rules rot
|
|
25
|
+
|
|
26
|
+
At review close: any rule in GO_RULES.md whose sensor never ran in this change
|
|
27
|
+
gets deleted. A rule with no sensor is advice; a rule whose sensor never fires
|
|
28
|
+
is rot.
|
|
@@ -0,0 +1,13 @@
|
|
|
1
|
+
# Perf lens (goperf.dev — hot paths only)
|
|
2
|
+
|
|
3
|
+
Trigger: pprof marks a function hot. Never review perf folklore otherwise.
|
|
4
|
+
|
|
5
|
+
- Escape analysis: `go build -gcflags=-m=2` — allocations must be claimed, not assumed
|
|
6
|
+
- Pooling: `sync.Pool` only for short-lived reusable scratch, verified by escape analysis
|
|
7
|
+
- Prealloc: `make([]T, 0, n)` where size is known; `prealloc`, `fieldalignment`
|
|
8
|
+
- Interface boxing on hot paths — value vs pointer receivers
|
|
9
|
+
- GC pressure: `GOGC` only after `go tool pprof` shows it matters
|
|
10
|
+
- Worker pools: bounded concurrency, `errgroup.SetLimit`
|
|
11
|
+
|
|
12
|
+
Evidence required: `go test -bench -benchmem` + `benchstat` before/after
|
|
13
|
+
(ns/op, B/op, allocs/op). No benchmark → finding is labeled `[unverified]`.
|
|
@@ -0,0 +1,17 @@
|
|
|
1
|
+
# Race / concurrency lens (mandatory findings class)
|
|
2
|
+
|
|
3
|
+
Gate: `go test -race` + `goleak.VerifyNone`. Caveat: -race fires only on
|
|
4
|
+
executed paths, so every concurrent path needs a test that exercises it.
|
|
5
|
+
|
|
6
|
+
Check, in order:
|
|
7
|
+
1. Ownership — which goroutine owns each shared datum; is it named in the spec?
|
|
8
|
+
2. Separate-before-serializing — could the shared write target be eliminated?
|
|
9
|
+
3. Mixed atomic/non-atomic access to one variable (never allowed)
|
|
10
|
+
4. Loop-variable capture in goroutines (vet loopclosure)
|
|
11
|
+
5. WaitGroup misuse: Add before go, Done via defer (vet, staticcheck SA2)
|
|
12
|
+
6. Send-on-closed-channel risk: only the owner closes (race detector)
|
|
13
|
+
7. Goroutine leaks: every `go` has a reachable exit via ctx/done (goleak)
|
|
14
|
+
8. Mutex copying: non-pointer, non-embedded, all access via owning methods
|
|
15
|
+
(vet copylocks)
|
|
16
|
+
9. Channel buffer 0/1 or justified
|
|
17
|
+
10. ctx propagation into every goroutine; `defer cancel()` everywhere
|
|
@@ -0,0 +1,12 @@
|
|
|
1
|
+
# Security lens (go.dev/doc/security/best-practices)
|
|
2
|
+
|
|
3
|
+
Gate: `govulncheck ./...` clean; gosec zero findings.
|
|
4
|
+
|
|
5
|
+
- Tainted input validated at trust boundaries; fuzz tests for every
|
|
6
|
+
parser/decoder of untrusted input (`go test -fuzz`)
|
|
7
|
+
- `crypto/rand` for anything security-relevant; `math/rand` never
|
|
8
|
+
- No secrets in logs, errors, or struct String() methods
|
|
9
|
+
- Deadlines on every network I/O (ctx.WithTimeout); no `noctx` HTTP calls
|
|
10
|
+
- Resource closure: bodyclose, sqlclosecheck
|
|
11
|
+
- Go directive version floor in go.mod (drops unsupported toolchain CVEs)
|
|
12
|
+
- Dependency hygiene: `go list -m -u all` reviewed; minimal transitive surface
|
|
@@ -0,0 +1,20 @@
|
|
|
1
|
+
# SOLID / design lens (dave.cheney.net/2016/08/20/solid-go-design)
|
|
2
|
+
|
|
3
|
+
Name the violation in Cheney's vocabulary — never say "this is bad":
|
|
4
|
+
|
|
5
|
+
- Rigid — change forces cascade edits through unrelated packages
|
|
6
|
+
- Fragile — change breaks distant parts
|
|
7
|
+
- Immobile — can't be reused outside the current context
|
|
8
|
+
- Complex — more cognitive load than the job needs
|
|
9
|
+
- Verbose — more ceremony than information
|
|
10
|
+
|
|
11
|
+
Probes:
|
|
12
|
+
- Model the domain: sealed-interface state machines over scattered booleans
|
|
13
|
+
- One package = one responsibility; no common/utils catch-alls
|
|
14
|
+
- Consumer-defined narrow interfaces; accept interfaces, return structs
|
|
15
|
+
- Deep modules: hide complexity behind a small interface
|
|
16
|
+
- Dependency inversion: concrete wiring pushed up to main/top-level handlers;
|
|
17
|
+
low-level layers return errors, never decide policy
|
|
18
|
+
|
|
19
|
+
Smell proxies (sensors, weak evidence): unused/unparam, gocyclo, funlen,
|
|
20
|
+
revive iface-*, `go list -deps` for the import graph.
|
|
@@ -0,0 +1,39 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: go-tdd
|
|
3
|
+
description: Implement an accepted Go spec test-first. Delegates to tdd at pre-agreed seams with a Go sensor gate at every phase exit, and mandatory end-to-end expected-outcome tests. Use when implementing Go changes after go-plan produced an accepted spec.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# go-tdd
|
|
7
|
+
|
|
8
|
+
Explicit-only wrapper. Call the Skill tool with **tdd** at the pre-agreed seams
|
|
9
|
+
from the spec. Every phase exit is a Go sensor run — "it compiles" is not
|
|
10
|
+
evidence.
|
|
11
|
+
|
|
12
|
+
## The contract
|
|
13
|
+
|
|
14
|
+
All rules come from [GO_RULES.md](references/GO_RULES.md) — the single source
|
|
15
|
+
shared with go-review. Read it before writing code; never restate rules
|
|
16
|
+
locally.
|
|
17
|
+
|
|
18
|
+
## Fail-fast sensor chain (run at every phase exit)
|
|
19
|
+
|
|
20
|
+
1. `gofmt -l .` — zero output
|
|
21
|
+
2. `go vet ./...` — zero findings (copylocks, atomic, loopclosure, lostcancel)
|
|
22
|
+
3. `golangci-lint run` — zero findings (config: assets/.golangci.yml)
|
|
23
|
+
4. `govulncheck ./...` — no known vulnerabilities
|
|
24
|
+
5. `go test -race ./...` — green; `goleak` on any package that starts goroutines
|
|
25
|
+
|
|
26
|
+
A missing binary is not a free pass — install it or use the documented
|
|
27
|
+
degraded-mode fallback in [toolchain-setup.md](references/toolchain-setup.md).
|
|
28
|
+
|
|
29
|
+
## End-to-end outcome tests (required)
|
|
30
|
+
|
|
31
|
+
Beyond unit tests, at least one test exercises the expected end-to-end outcome:
|
|
32
|
+
the real binary against the real artifact where feasible. The expected outcome
|
|
33
|
+
is an acceptance condition, and acceptance conditions must be tested, not
|
|
34
|
+
assumed.
|
|
35
|
+
|
|
36
|
+
## Perf discipline (pstack)
|
|
37
|
+
|
|
38
|
+
Optimize only on a pprof-identified hot path. Every perf change ships
|
|
39
|
+
`benchstat` before/after (ns/op, B/op, allocs/op). No benchmark, no change.
|
|
@@ -0,0 +1,39 @@
|
|
|
1
|
+
version: "2"
|
|
2
|
+
|
|
3
|
+
linters:
|
|
4
|
+
default: none
|
|
5
|
+
enable:
|
|
6
|
+
- errcheck
|
|
7
|
+
- errorlint
|
|
8
|
+
- wrapcheck
|
|
9
|
+
- govet
|
|
10
|
+
- staticcheck
|
|
11
|
+
- unused
|
|
12
|
+
- unparam
|
|
13
|
+
- gosec
|
|
14
|
+
- revive
|
|
15
|
+
- prealloc
|
|
16
|
+
- fieldalignment
|
|
17
|
+
- containedctx
|
|
18
|
+
- bodyclose
|
|
19
|
+
- noctx
|
|
20
|
+
- sqlclosecheck
|
|
21
|
+
- gocyclo
|
|
22
|
+
- funlen
|
|
23
|
+
|
|
24
|
+
settings:
|
|
25
|
+
revive:
|
|
26
|
+
rules:
|
|
27
|
+
- name: exported
|
|
28
|
+
- name: iface
|
|
29
|
+
wrapcheck:
|
|
30
|
+
ignoreSigs:
|
|
31
|
+
- .Errorf(
|
|
32
|
+
gocyclo:
|
|
33
|
+
min-complexity: 15
|
|
34
|
+
|
|
35
|
+
exclusions:
|
|
36
|
+
generated: lax
|
|
37
|
+
paths:
|
|
38
|
+
- third_party$
|
|
39
|
+
- vendor$
|
|
@@ -0,0 +1,44 @@
|
|
|
1
|
+
# GO_RULES.md — the canonical Go contract
|
|
2
|
+
|
|
3
|
+
One line per rule + its `[sensor]`. Tiered: HARD gates block; REVIEW lenses are
|
|
4
|
+
judgment; EVIDENCE gates apply to hot paths only. go-tdd and go-review both read
|
|
5
|
+
this file — never restate rules locally, and delete any rule whose sensor never
|
|
6
|
+
runs (rules rot).
|
|
7
|
+
|
|
8
|
+
## HARD — failing blocks the phase exit
|
|
9
|
+
|
|
10
|
+
1. `gofmt -l` and `goimports -l` print nothing — machine formatting is the standard. `[gofmt -l]`
|
|
11
|
+
2. `go vet ./...` is clean — copylocks, atomic, loopclosure, lostcancel. `[go vet]`
|
|
12
|
+
3. `golangci-lint run` is clean with assets/.golangci.yml. `[golangci-lint]`
|
|
13
|
+
4. `govulncheck ./...` finds no known vulnerabilities. `[govulncheck]`
|
|
14
|
+
5. `go test -race ./...` is green; `goleak.VerifyNone` in every package that starts goroutines. `[go test -race, goleak]`
|
|
15
|
+
6. Every exported declaration has a doc comment beginning with its name. `[revive exported-comments]`
|
|
16
|
+
7. Errors handled: no unchecked returns, no `==`/string matching — `errors.Is`/`errors.As` only. `[errcheck, errorlint]`
|
|
17
|
+
8. `%w` for in-app wrapping, `%v` only at API/system boundaries; error strings lowercase, no trailing punctuation. `[wrapcheck, staticcheck ST1005]`
|
|
18
|
+
9. `context.Context` is the explicit first parameter; never stored in a struct or global; `defer cancel()` for every derived context. `[go vet lostcancel, containedctx]`
|
|
19
|
+
10. Every `go` statement has a reachable exit: blocking ops sit in `select { ... case <-ctx.Done(): return }`. `[goleak, review]`
|
|
20
|
+
11. `wg.Add` before `go`, `defer wg.Done()`; prefer `errgroup.WithContext` when errors exist. `[go vet, go test -race]`
|
|
21
|
+
12. Channel senders close their channel (`defer close(out)`); receivers never close it; buffer capacity 0 or 1 unless justified. `[go test -race, review]`
|
|
22
|
+
13. Mutex as a non-pointer, non-embedded field; all access through the owning struct's methods. `[go vet -copylocks]`
|
|
23
|
+
14. `crypto/rand`, never `math/rand` for anything security-relevant; no secrets in logs/errors; deadlines on every network I/O. `[gosec]`
|
|
24
|
+
15. Fuzz tests exist for every parser/decoder of untrusted input. `[go test -fuzz]`
|
|
25
|
+
16. At least one end-to-end expected-outcome test: the real binary against the real artifact. `[go test ./... e2e]`
|
|
26
|
+
|
|
27
|
+
## REVIEW — judgment lenses, no direct sensor
|
|
28
|
+
|
|
29
|
+
17. SOLID-Go by name: rigidity, fragility, immobility, complexity, verbosity — call them out with the specific violation. `[review]`
|
|
30
|
+
18. Model the domain: sealed-interface state machines over scattered booleans. `[review]`
|
|
31
|
+
19. One package = one responsibility; no `common`/`utils` catch-alls. `[gocyclo, funlen, review]`
|
|
32
|
+
20. Consumer-defined narrow interfaces; accept interfaces, return structs (`Save(io.Writer)`, not `Save(*os.File)`). `[revive iface-*, review]`
|
|
33
|
+
21. Zero value of every exported type usable without initialization. `[review]`
|
|
34
|
+
|
|
35
|
+
## EVIDENCE — hot paths only, triggered by pprof
|
|
36
|
+
|
|
37
|
+
22. Every perf claim ships `benchstat` before/after: ns/op, B/op, allocs/op — never folklore. `[go test -bench -benchmem, benchstat]`
|
|
38
|
+
23. Preallocate when size is known (`make([]T, 0, n)`); order struct fields largest-to-smallest. `[prealloc, fieldalignment]`
|
|
39
|
+
24. `sync.Pool` only for short-lived reusable scratch; verify stack residency with escape analysis before claiming zero-cost. `[go build -gcflags=-m=2]`
|
|
40
|
+
|
|
41
|
+
## Upkeep
|
|
42
|
+
|
|
43
|
+
At review close: delete any rule whose sensor never ran in this change. A rule
|
|
44
|
+
with no sensor is advice; a rule whose sensor never fires is rot.
|
|
@@ -0,0 +1,29 @@
|
|
|
1
|
+
# Toolchain setup & degraded mode
|
|
2
|
+
|
|
3
|
+
## Install the gate binaries once
|
|
4
|
+
|
|
5
|
+
```bash
|
|
6
|
+
go install github.com/golangci/golangci-lint/v2/cmd/golangci-lint@latest
|
|
7
|
+
go install golang.org/x/vuln/cmd/govulncheck@latest
|
|
8
|
+
go install honnef.co/go/tools/cmd/staticcheck@latest
|
|
9
|
+
go install golang.org/x/perf/cmd/benchstat@latest
|
|
10
|
+
go install go.uber.org/goleak/cmd/goleak@latest # or use as a test dependency
|
|
11
|
+
go get go.uber.org/goleak # test dependency form (preferred)
|
|
12
|
+
```
|
|
13
|
+
|
|
14
|
+
Verify: `golangci-lint version`, `govulncheck -version`.
|
|
15
|
+
|
|
16
|
+
## Degraded mode (missing binary)
|
|
17
|
+
|
|
18
|
+
A missing sensor is a degraded phase, not a skipped one:
|
|
19
|
+
|
|
20
|
+
| Missing | Degraded substitute |
|
|
21
|
+
|---|---|
|
|
22
|
+
| govulncheck | `golangci-lint run` (gosec linter) + `go list -m -u all` review |
|
|
23
|
+
| golangci-lint | `go vet ./...` + `staticcheck ./...` |
|
|
24
|
+
| staticcheck | `go vet ./...` (covers copylocks/atomic/loopclosure/lostcancel) |
|
|
25
|
+
| benchstat | manual ns/op comparison — but label the claim `[unverified]` |
|
|
26
|
+
| goleak | `runtime.NumGoroutine()` before/after assertions in the test |
|
|
27
|
+
|
|
28
|
+
Note in the handoff which sensors ran degraded and why; the missing binary
|
|
29
|
+
becomes the first task of the next session.
|