Start with the blockage
You understood a lesson, but cannot recall what to do at work. These tables compress methods already explained on this site. Find the nearest trigger, then follow its lesson link for conditions. Command names alone are not deliverables.
Here's a cheat sheet that will get you 90% of the way there.
— Matt Pocock
The quote illustrates the reference format. This page does not reproduce the author's TSConfig graphic or promise that percentage of learning progress.
Choose a workflow
| Trigger | Available step | Input → output | When to skip |
|---|---|---|---|
| Clear small change | Implement and verify | Settled behaviour → evidence | Skip extra planning |
| Moderate uncertainty | Align and prototype | Vague request → acceptance behaviour | Behaviour already agreed |
| Decisions across sessions | Workflow triage | Dependencies and unknowns → decision map | No cross-session need |
Plan enough to support the next verification. Agreed behaviour can proceed to specs and tickets. A step's presence in the table does not make it compulsory.
Put rules where they work
| Purpose | Location | Full explanation |
|---|---|---|
| Navigation | AGENTS.md | Agent documents |
| Judgement-based standards | CODING_STANDARDS | Standards and checks |
| Mechanical enforcement | lint / hook / CI | Standards and checks |
| Durable reasoning | ADR | Decisions and retrospectives |
| Domain language | GLOSSARY | Agent documents |
One requirement may need two homes: a standard explains the judgement, while a check enforces its mechanically recognisable part. Both should describe the same behaviour so documentation and enforcement agree.
Navigation points a collaborator to information; checks reject mechanically detectable errors. Putting every requirement in a root document cannot make it execute automatically and creates more material to keep current.
Verification and handoff
These fields condense structures from Matt Pocock's skills repository, adapted under MIT. The complete licence follows at the end of this page; see also the copyright page.
| Field | What to retain | Full lesson |
|---|---|---|
| Behaviour evidence | Steps, expected and actual results | Implementation and feedback |
| Failure path | Failure behaviour and recovery | Review and PR |
| Unverified items | Missing evidence and risk | Review and PR |
| Artifact links | Existing locations, avoiding duplication | Context and handoff |
| Next action | Receiving task and verification | Context and handoff |
Source files: skills/, skills/, skills/.
Navigation also adapts skills/; the exercise and review structure adapts skills/.
The PR source credits Dex Horthy / HumanLayer's upstream work. This site takes no content from that upstream file.
An unverified field should identify behaviours not run, missing environment and possible impact. The receiver needs to know which conclusions remain unsupported. Link existing evidence without treating an earlier result as a fresh verification.
TypeScript entry points
| Trigger | First move | Full explanation |
|---|---|---|
| Unknown input | Accept unknown, validate at runtime | TS foundations |
| Type relationships | Connect input and output types | TypeScript foundations |
| Key types | Check whether a key may be a string, number or symbol | Practical type tools |
| Contradictory states | List valid states and transitions | States and boundaries |
Before using the type table, distinguish a static relationship from a runtime fact. Unknown data needs validation; valid keys need type constraints. For states, return to accepted transitions. Identify the gap before choosing its representation.
Exercise and completion
A fresh session claims completion without running anything
- Task: use the tables to select a full lesson and one immediate action.
- Add: identify an unknown that the handoff must disclose.
Suggested approach
Open implementation and feedback, run the target behaviour, and record expected and actual results. Disclose checks not yet run and their risks in the handoff. Naming a command alone is insufficient.
Done means the selection addresses the reported failure and the action produces checkable evidence. Return later with a different scenario to practise choosing, rather than remembering a row's position.
Quick reference
Workflow
Choose enough steps for the uncertainty.
Rules
Give navigation, judgement and enforcement distinct homes.
Delivery
Retain behaviour evidence, unknowns and a next action.
Sources
- Matt's cheat-sheet quote, 2023-09-12
- Each table links to this site's full explanations; MIT source files and upstream credit accompany the adapted fields.
skills MIT notice
The structure adapted here comes from mattpocock/skills, MIT licence, Copyright (c) 2026 Matt Pocock. The complete licence follows, identical to the repository LICENSE.
Full licence: mattpocock/skills
MIT License
Copyright (c) 2026 Matt Pocock
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.
Unofficial, non-commercial study notes. No affiliation with or endorsement by Matt Pocock. Quoted works remain their authors’ copyright; MIT reuse retains its copyright and licence notices.