Skip to main content

Playbook Method Template

What makes a method repeatable?

A playbook page helps a reader do one repeatable job.

The reusable model is outcome -> inputs -> steps -> checks -> proof. Apply it when the reader needs to produce the same artifact or state without the original author present.

Use this when the page job is playbook.

Frontmatter​

type: playbook
template: playbook-method-template
template_url: /playbook/standards/templates/playbook-method-template
claim_state: REALITY | DREAM | CONSUMED
retrieval_trigger: "When should a future human or agent pull this method?"
loop_phase: action
level: working

Shape​

  1. Open with the problem.
  2. Ask the question the method answers.
  3. Name the decision this method improves.
  4. Name the outcome.
  5. List inputs and preconditions.
  6. Give ordered steps.
  7. Name the output of each step.
  8. Add checks and gates.
  9. Show proof of done.
  10. Close with the falsifier and next question.

Skill Reference Use​

Operational skills may cite a playbook method as source doctrine. Make that safe by naming the proof clearly enough that a skill can turn it into evals, checks, or receipts.

Do not link public pages to private skill paths. Let skills reference the playbook, not the other way around.

Skeleton​

TITLE

Problem: WHAT IS STUCK?

Question: WHAT MUST THIS METHOD ANSWER?

Decision: WHAT CHOICE OR ACTION GETS BETTER?

This method produces OUTCOME.

## Inputs

- Input A
- Input B

## Steps

1. Do the first action.
2. Produce the first output.
3. Check the output.

## Checks

- What must be true before moving on?

## Failure Modes

- What usually breaks?

## Proof Of Done

What evidence shows the method worked?

Changes my mind: What would prove this method is wrong, obsolete, or unsafe?

## Retrieval

When should a future human or agent pull this method?

Version delta: What belief, route, or operating step changed in this update?

## Context

- [Related standard](/playbook/)

## Questions

Next question: What constraint should the next loop inspect?

Checks​

  • The page drives action instead of teaching theory.
  • The first screen names the problem, question, decision, and outcome.
  • Each step has an output.
  • The proof of done is visible.
  • claim_state, retrieval_trigger, Changes my mind, and Next question are visible.
  • Failure modes are specific enough to catch bad execution.
  • A skill author could extract the outcome, proof signal, and failure mode without asking what the method means.

Failure Modes​

  • The page explains why for too long before the first action.
  • Steps are vague and produce no artifact.
  • Checks depend on taste instead of evidence.

Context​

Questions​

What should a new operator produce after following this page?

  • What input starts the method?
  • What artifact or state proves each step worked?
  • Which check stops bad work before it compounds?
  • What would falsify the method?
  • When should an agent retrieve it?