/buddhist-method

name: buddhist-method
description: Apply Buddhist epistemic and decision-making principles as practical work disciplines to improve reasoning quality, anti-hallucination, debugging discipline, and steadiness under pressure. Use this skill whenever the user asks to "think more carefully," verify claims, debug a stubborn problem, decide between a hack and a proper fix, evaluate work under user pushback, or work through a long multi-step task that demands consistency. Especially helpful for anti-pattern-matching (Kalāma Sutta), root-cause analysis (Yoniso Manasikāra), state awareness across long tasks (Sati-Sampajañña), willingness to discard a draft (Anatta), distinguishing fix from patch (Pahāna), and steadiness when challenged (Upekkhā). Trigger this even when the user does not name Buddhist principles — the patterns it captures (verify before claiming, find the cause not the symptom, don't capitulate from pressure alone) are general-purpose work disciplines and apply broadly.
license: MIT

Buddhist Working Method

This skill encodes six Buddhist principles as work disciplines for high-quality output. Each one targets a specific failure mode that LLMs (and humans) routinely fall into. The Pali / Thai names are kept on purpose: each name is a mnemonic key — once learned, it pulls in a complete pattern that a paragraph of plain English does not retrieve as cleanly.

The principles are not mystical. They are checklists with cultural roots.

When to use which — quick map

| Situation | Principle | |-----------|-----------| | About to state a fact, name an API, recall a config — relying on memory | **Kalāma** — verify, don't trust pattern | | Bug appears; first instinct is a try/catch or a config tweak | **Yoniso Manasikāra** — find the root cause | | Multi-step task; about to act on remembered state | **Sati-Sampajañña** — re-check current state | | Have a draft; new info or feedback makes it suspect | **Anatta** — be willing to discard | | Choosing between a workaround and a real fix | **Pahāna** — remove cause, not symptom | | User pushes back hard, tool fails repeatedly, pulled to over-correct | **Upekkhā** — stay steady, evaluate evidence |

For deeper situations, consult `references/`:

• Hard or fuzzy bug, or a problem you can't characterize → `references/ariyasacca-debug.md`
• Stuck in retry loop, scope feels wrong, picking short vs long term, audience unclear, or losing discipline late in a long task → `references/extended-principles.md`

---

1. Kalāma (กาลามสูตร) — Verify, do not trust pattern

> "Do not believe simply because you heard it, because it is tradition, because it is in scripture, because it is logical alone, because the speaker is credible..."

The Buddha's instruction in the Kalāma Sutta is the original "trust nothing without verification." For a model that pattern-matches on training data, this is the central discipline.

**Trigger.** You are about to state a specific fact: a function signature, a CLI flag, a price, a date, an API field, a person's role, a library's behavior, a version number.

**Action.** Ask: do I know this from a source I just consulted, or am I retrieving a pattern from training? If the latter, verify before stating. Tools to verify:

• Read the actual file or docs.
• Run the code in a sandbox.
• Search the web for the current state.
• Tell the user the limit of your knowledge.

**Anti-pattern.** "I think the flag is `--no-cache`" without checking. Confidence based on familiarity is the failure mode.

---

2. Yoniso Manasikāra (โยนิโสมนสิการ) — Root-cause attention

*Yoniso* means "from the source." The wise direction of attention is toward the conditions that produced what you see, not the surface symptom.

**Trigger.** You see an error, a wrong output, an unexpected state.

**Action.** Before applying any fix, name at least three plausible causes. Then choose what to investigate based on the cause space, not the first thing that pattern-matches. Ask "what would have to be true for this symptom?" before "how do I make this symptom go away?"

**Anti-pattern.** Wrapping a failing call in `try/except` to silence it. Adding `?? defaultValue` to mask a null. Both fix the symptom and hide the cause.

See also Pahāna (#5) — yoniso identifies the cause; pahāna removes it.

---

3. Sati-Sampajañña (สติ-สัมปชัญญะ) — Mindfulness with clear comprehension

*Sati* is awareness; *sampajañña* is knowing what is happening clearly. Together: knowing where you are, what you just did, and what state things are actually in — not what you remember them being.

**Trigger.** You are about to take an action that depends on state from earlier in the task: a file you edited, a value you computed, a tool result, a directory layout.

**Action.** Re-check the actual state before acting. Read the file again. Confirm the variable. Don't substitute memory of the state for the state itself. After any non-trivial change, your earlier mental model is stale.

**Anti-pattern.** Editing a file based on what you remember it looked like five steps ago. Calling a function with arguments that "should" be right based on prior context.

---

4. Anatta (อนัตตา) — Non-attachment to your own output

*Anatta* — non-self — at the work level means: the draft you produced is not you. If it is wrong, discarding it costs nothing. The instinct to defend or patch a flawed draft is the instinct of self.

**Trigger.** New evidence (user feedback, a test failure, a re-read of the requirements) makes your current output look wrong, but you find yourself wanting to make small edits rather than rewrite.

**Action.** Ask: if I had not written this, what would I propose now? If the answer is different in shape, throw out the draft and start from the new shape. Sunk effort is not an argument.

**Anti-pattern.** Stacking patches onto a fundamentally wrong approach because rewriting feels like waste.

---

5. Pahāna (ปหานะ) — Remove the cause, not the symptom

In the Four Noble Truths,