mirror of
https://github.com/mattpocock/skills.git
synced 2026-09-13 02:48:06 +07:00
Compare commits
9
Commits
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
6acc160e4e | ||
|
|
30204e66cb | ||
|
|
113087c684 | ||
|
|
bb8fdc3fd1 | ||
|
|
7bb49795a1 | ||
|
|
c0d69015e0 | ||
|
|
14bfbbd865 | ||
|
|
bda79a3c3c | ||
|
|
efce423018 |
@@ -1,5 +0,0 @@
|
|||||||
---
|
|
||||||
"mattpocock-skills": patch
|
|
||||||
---
|
|
||||||
|
|
||||||
wizard: remove the time estimate. The template drops `TOTAL_MINUTES` and the time-remaining display, `stage` takes a name only, and progress is counted in stages.
|
|
||||||
@@ -1,6 +1,6 @@
|
|||||||
{
|
{
|
||||||
"name": "mattpocock-skills",
|
"name": "mattpocock-skills",
|
||||||
"version": "1.2.2",
|
"version": "1.2.3",
|
||||||
"description": "Matt Pocock's agent skills for real engineering — grilling, spec/ticket flows, TDD, code review, domain modelling and more. Plug-and-play, not vibe coding.",
|
"description": "Matt Pocock's agent skills for real engineering — grilling, spec/ticket flows, TDD, code review, domain modelling and more. Plug-and-play, not vibe coding.",
|
||||||
"author": {
|
"author": {
|
||||||
"name": "Matt Pocock",
|
"name": "Matt Pocock",
|
||||||
|
|||||||
@@ -1,5 +1,19 @@
|
|||||||
# mattpocock-skills
|
# mattpocock-skills
|
||||||
|
|
||||||
|
## 1.2.3
|
||||||
|
|
||||||
|
### Patch Changes
|
||||||
|
|
||||||
|
- [#779](https://github.com/mattpocock/skills/pull/779) [`efce423`](https://github.com/mattpocock/skills/commit/efce423018fc6468a3239621f1c1bcaacc723801) Thanks [@mattpocock](https://github.com/mattpocock)! - Make `diagnosing-bugs` redact secrets.
|
||||||
|
|
||||||
|
- Add a **Redact** section to `SKILL.md`. The skill has the agent show commands, outputs and captured artifacts; the section makes redaction the first move on each — write `<REDACTED>`, build loops against env vars so the credential stays in the environment, and quote only the signal-carrying lines of a captured artifact.
|
||||||
|
- The Phase 1 completion criterion said "paste the invocation and its output". It now says show it redacted, and Phase 1 asks the user for a **redacted** captured artifact.
|
||||||
|
- Note in `scripts/hitl-loop.template.sh` that `capture` prints its value back to the terminal, so it takes observations while signing in stays a `step`.
|
||||||
|
|
||||||
|
- [#781](https://github.com/mattpocock/skills/pull/781) [`14bfbbd`](https://github.com/mattpocock/skills/commit/14bfbbd8654a8d2910299e1a004c19c1979687d8) Thanks [@mattpocock](https://github.com/mattpocock)! - Drop Claude Code's tool and agent-type names from the subagent-dispatch instructions in `code-review`, `codebase-design`, and `improve-codebase-architecture`, so the step is followable on Codex and other harnesses.
|
||||||
|
|
||||||
|
- [#783](https://github.com/mattpocock/skills/pull/783) [`c0fd1e9`](https://github.com/mattpocock/skills/commit/c0fd1e973e040347d424e09934099f1bd6c2dee0) Thanks [@mattpocock](https://github.com/mattpocock)! - wizard: remove the time estimate. The template drops `TOTAL_MINUTES` and the time-remaining display, `stage` takes a name only, and progress is counted in stages.
|
||||||
|
|
||||||
## 1.2.2
|
## 1.2.2
|
||||||
|
|
||||||
### Patch Changes
|
### Patch Changes
|
||||||
|
|||||||
+1
-1
@@ -1,6 +1,6 @@
|
|||||||
{
|
{
|
||||||
"name": "mattpocock-skills",
|
"name": "mattpocock-skills",
|
||||||
"version": "1.2.2",
|
"version": "1.2.3",
|
||||||
"private": true,
|
"private": true,
|
||||||
"description": "Matt Pocock's agent skills for real engineering",
|
"description": "Matt Pocock's agent skills for real engineering",
|
||||||
"repository": {
|
"repository": {
|
||||||
|
|||||||
@@ -57,8 +57,6 @@ Each smell reads *what it is* → *how to fix*; match it against the diff:
|
|||||||
|
|
||||||
### 4. Spawn both sub-agents in parallel
|
### 4. Spawn both sub-agents in parallel
|
||||||
|
|
||||||
Send a single message with two `Agent` tool calls. Use the `general-purpose` subagent for both.
|
|
||||||
|
|
||||||
**Standards sub-agent prompt** — include:
|
**Standards sub-agent prompt** — include:
|
||||||
|
|
||||||
- The full diff command and commit list.
|
- The full diff command and commit list.
|
||||||
|
|||||||
@@ -18,7 +18,7 @@ Show this to the user, then immediately proceed to Step 2. The user reads and th
|
|||||||
|
|
||||||
### 2. Spawn sub-agents
|
### 2. Spawn sub-agents
|
||||||
|
|
||||||
Spawn 3+ sub-agents in parallel using the Agent tool. Each must produce a **radically different** interface for the deepened module.
|
Spawn 3+ sub-agents in parallel. Each must produce a **radically different** interface for the deepened module.
|
||||||
|
|
||||||
Prompt each sub-agent with a separate technical brief (file paths, coupling details, dependency category from [DEEPENING.md](DEEPENING.md), what sits behind the seam). The brief is independent of the user-facing problem-space explanation in Step 1. Give each agent a different design constraint:
|
Prompt each sub-agent with a separate technical brief (file paths, coupling details, dependency category from [DEEPENING.md](DEEPENING.md), what sits behind the seam). The brief is independent of the user-facing problem-space explanation in Step 1. Give each agent a different design constraint:
|
||||||
|
|
||||||
|
|||||||
@@ -9,6 +9,12 @@ A discipline for hard bugs. Skip phases only when explicitly justified.
|
|||||||
|
|
||||||
When exploring the codebase, read `CONTEXT.md` (if it exists) to get a clear mental model of the relevant modules, and check ADRs in the area you're touching.
|
When exploring the codebase, read `CONTEXT.md` (if it exists) to get a clear mental model of the relevant modules, and check ADRs in the area you're touching.
|
||||||
|
|
||||||
|
## Redact
|
||||||
|
|
||||||
|
This skill has you show commands, outputs and captured artifacts. **Redact every secret first** — write `<REDACTED>` in its place. Build loops against env vars, so the credential stays in the environment rather than in what you show. Captured artifacts carry auth headers: quote only the lines that carry the signal.
|
||||||
|
|
||||||
|
If the redacted output is not enough to diagnose the bug, say so and ask the user.
|
||||||
|
|
||||||
## Phase 1 — Build a feedback loop
|
## Phase 1 — Build a feedback loop
|
||||||
|
|
||||||
**This is the skill.** Everything else is mechanical. If you have a **tight** pass/fail signal for the bug — one that goes red on _this_ bug — you will find the cause; bisection, hypothesis-testing, and instrumentation all just consume it. If you don't have one, no amount of staring at code will save you.
|
**This is the skill.** Everything else is mechanical. If you have a **tight** pass/fail signal for the bug — one that goes red on _this_ bug — you will find the cause; bisection, hypothesis-testing, and instrumentation all just consume it. If you don't have one, no amount of staring at code will save you.
|
||||||
@@ -46,11 +52,11 @@ The goal is not a clean repro but a **higher reproduction rate**. Loop the trigg
|
|||||||
|
|
||||||
### When you genuinely cannot build a loop
|
### When you genuinely cannot build a loop
|
||||||
|
|
||||||
Stop and say so explicitly. List what you tried. Ask the user for: (a) access to whatever environment reproduces it, (b) a captured artifact (HAR file, log dump, core dump, screen recording with timestamps), or (c) permission to add temporary production instrumentation. Do **not** proceed to hypothesise without a loop.
|
Stop and say so explicitly. List what you tried. Ask the user for: (a) access to whatever environment reproduces it, (b) a redacted captured artifact (HAR file, log dump, core dump, screen recording with timestamps), or (c) permission to add temporary production instrumentation. Do **not** proceed to hypothesise without a loop.
|
||||||
|
|
||||||
### Completion criterion — a tight loop that goes red
|
### Completion criterion — a tight loop that goes red
|
||||||
|
|
||||||
Phase 1 is done when the loop is **tight** and **red-capable**: you can name **one command** — a script path, a test invocation, a curl — that you have **already run at least once** (paste the invocation and its output), and that is:
|
Phase 1 is done when the loop is **tight** and **red-capable**: you can name **one command** — a script path, a test invocation, a curl — that you have **already run at least once** (show the invocation and its output, redacted), and that is:
|
||||||
|
|
||||||
- [ ] **Red-capable** — it drives the actual bug code path and asserts the **user's exact symptom**, so it can go red on this bug and green once fixed. Not "runs without erroring" — it must be able to _catch this specific bug_.
|
- [ ] **Red-capable** — it drives the actual bug code path and asserts the **user's exact symptom**, so it can go red on this bug and green once fixed. Not "runs without erroring" — it must be able to _catch this specific bug_.
|
||||||
- [ ] **Deterministic** — same verdict every run (flaky bugs: a pinned, high reproduction rate, per above).
|
- [ ] **Deterministic** — same verdict every run (flaky bugs: a pinned, high reproduction rate, per above).
|
||||||
|
|||||||
@@ -11,6 +11,9 @@
|
|||||||
# capture VAR "<question>" → show question, read response into VAR
|
# capture VAR "<question>" → show question, read response into VAR
|
||||||
#
|
#
|
||||||
# At the end, captured values are printed as KEY=VALUE for the agent to parse.
|
# At the end, captured values are printed as KEY=VALUE for the agent to parse.
|
||||||
|
#
|
||||||
|
# `capture` prints its value back to the terminal, where the agent reads it — so
|
||||||
|
# capture observations, and leave signing in to the user as a `step`.
|
||||||
|
|
||||||
set -euo pipefail
|
set -euo pipefail
|
||||||
|
|
||||||
|
|||||||
@@ -24,7 +24,7 @@ This command is _informed_ by the project's domain model and built on a shared d
|
|||||||
|
|
||||||
Read the project's domain glossary (`CONTEXT.md`) and any ADRs in the area you're touching first.
|
Read the project's domain glossary (`CONTEXT.md`) and any ADRs in the area you're touching first.
|
||||||
|
|
||||||
Then use the Agent tool with `subagent_type=Explore` to walk the codebase. Don't follow rigid heuristics — explore organically and note where you experience friction:
|
Then spawn a sub-agent to walk the codebase. Don't follow rigid heuristics — explore organically and note where you experience friction:
|
||||||
|
|
||||||
- Where does understanding one concept require bouncing between many small modules?
|
- Where does understanding one concept require bouncing between many small modules?
|
||||||
- Where are modules **shallow** — interface nearly as complex as the implementation?
|
- Where are modules **shallow** — interface nearly as complex as the implementation?
|
||||||
|
|||||||
Reference in New Issue
Block a user