docs: drop the formulaic "load-bearing constraint:" label
The repeated "The load-bearing constraint:" opener on every page read as an agent tell. Strip the label across all skill pages and let the constraint stand as a plain declarative sentence; update the writing-docs template so it isn't regenerated. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
parent
995fceec7a
commit
ade35dc0d8
21 changed files with 24 additions and 24 deletions
|
|
@ -14,7 +14,7 @@ npx skills update grill-me
|
|||
|
||||
`grill-me` runs a relentless interview about a plan or design, walking every branch of the decision tree until you and the agent reach a **shared understanding**.
|
||||
|
||||
The load-bearing constraint: it asks **one question at a time** and waits. It never dumps a batch of questions at you — that is bewildering — and where a question can be answered by reading the codebase, it goes and reads rather than asking. Each question comes with the agent's own recommended answer, so you are reacting to a proposal, not staring at a blank prompt.
|
||||
It asks **one question at a time** and waits. It never dumps a batch of questions at you — that is bewildering — and where a question can be answered by reading the codebase, it goes and reads rather than asking. Each question comes with the agent's own recommended answer, so you are reacting to a proposal, not staring at a blank prompt.
|
||||
|
||||
## When to reach for it
|
||||
|
||||
|
|
@ -24,7 +24,7 @@ Reach for it before you build, when a plan feels roughly right but you can sense
|
|||
|
||||
## The design tree
|
||||
|
||||
The session walks the plan as a tree of decisions, resolving dependencies between them one by one — a parent decision settled before the choices that hang off it. The point is not to reach agreement quickly; it is to make every implicit call explicit, so nothing load-bearing is left assumed. You come out the other side with a plan whose branches have all been visited.
|
||||
The session walks the plan as a tree of decisions, resolving dependencies between them one by one — a parent decision settled before the choices that hang off it. The point is not to reach agreement quickly; it is to make every implicit call explicit, so nothing important is left silently assumed. You come out the other side with a plan whose branches have all been visited.
|
||||
|
||||
`grill-me` is **stateless**: it writes nothing and leaves no workspace behind. It runs anywhere, and the only artifact is the sharpened understanding in the conversation itself. That is the deliberate contrast with [grill-with-docs](https://aihero.dev/skills-grill-with-docs), which captures the same interview as durable ADRs and a glossary.
|
||||
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ npx skills update handoff
|
|||
|
||||
`handoff` compacts the current conversation into a **handoff document** — a single write-up a fresh agent can read to pick up the work where you left off.
|
||||
|
||||
The load-bearing constraint: it does **not** re-state what already lives elsewhere. Anything captured in a PRD, plan, ADR, issue, commit, or diff is referenced by path or URL, never copied. The document carries only the live thread — what you were doing, why, and what's next — and it's saved to your OS's temporary directory, not into the workspace, so it never becomes another artifact to maintain.
|
||||
It does **not** re-state what already lives elsewhere. Anything captured in a PRD, plan, ADR, issue, commit, or diff is referenced by path or URL, never copied. The document carries only the live thread — what you were doing, why, and what's next — and it's saved to your OS's temporary directory, not into the workspace, so it never becomes another artifact to maintain.
|
||||
|
||||
## When to reach for it
|
||||
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ npx skills update teach
|
|||
|
||||
`teach` turns the current directory into a standing teaching workspace and teaches you one topic across many sessions — devising short, beautiful, interactive lessons tied to *why* you want to learn.
|
||||
|
||||
The load-bearing constraint: it does **not** teach from the model's own memory. Parametric knowledge is treated as untrusted; before it can teach, it gathers high-trust resources and grounds every claim in a citation. And it is stateful — the workspace remembers what you've learned, so each session picks up where the last left off rather than starting from scratch.
|
||||
It does **not** teach from the model's own memory. Parametric knowledge is treated as untrusted; before it can teach, it gathers high-trust resources and grounds every claim in a citation. And it is stateful — the workspace remembers what you've learned, so each session picks up where the last left off rather than starting from scratch.
|
||||
|
||||
## When to reach for it
|
||||
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ npx skills update writing-great-skills
|
|||
|
||||
`writing-great-skills` is the reference you write and edit skills against — the shared vocabulary and principles that make a skill predictable.
|
||||
|
||||
The load-bearing constraint: a skill's job is to wrangle determinism out of a stochastic system, so the goal is not the same *output* every run but the same *process*. **Predictability** is the root virtue, and every design choice is judged against it — not against how clever, complete, or exhaustive the skill reads.
|
||||
A skill's job is to wrangle determinism out of a stochastic system, so the goal is not the same *output* every run but the same *process*. **Predictability** is the root virtue, and every design choice is judged against it — not against how clever, complete, or exhaustive the skill reads.
|
||||
|
||||
## When to reach for it
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue