FAQ

Do I need to know Boyd’s theory?

No. The agent loads the full doctrine on every reasoning step — that’s its job, not yours. You describe your situation in plain language; it brings the OODA discipline, the Schwerpunkt thinking, and the mismatch tracking. You’ll absorb the concepts by using it, because the artifacts explain themselves as they go. If you get curious about the underlying theory, the concepts page is the short version and doctrine/boyd-doctrine.md is the full one.

What counts as a “system”?

Any situation where you have stakes, an opposing force shapes your outcomes, and you’ll keep making decisions as new information arrives. A company in a competitive market is the obvious case — but a job search, a contract negotiation, a fundraise, an open-source project, or a campaign all qualify. The repo ships three worked examples across that range; see examples/.

My problem doesn’t have an “adversary.” Does it?

It probably does — it just isn’t a person. The adversary doesn’t need intent; it needs consistent behaviors you can orient against. A useful test: what force, if you ignored it, would most reliably consume your resources or foreclose your options? That can be a competitor, a counterparty, a market dynamic, a hiring process, inertia, a deadline. The job-search example models a pure process adversary — its Red orientation tracks incentives and predictable behaviors instead of beliefs, and it works.

What if I face several adversaries at once?

Each system models one primary adversary (a deliberate MVP constraint — it keeps the Red orientation honest). Pick the force that most shapes your outcomes; list the secondary forces in rules.md, where they still inform every cycle. The exemplar does exactly this: LexFlow is the adversary, while market inertia and a larger incumbent are named as secondary forces. If two adversaries genuinely dominate two different contests, run two systems.

How often do I run it?

Three speeds. /boyd-observe whenever something happens — it’s cheap, append-only, and takes a minute. /boyd-cycle when you want re-orientation and fresh strategy: typically weekly to monthly, or whenever observations pile up or a mismatch opens. /boyd-outcome once you’ve acted and reality has answered. If you’re ever unsure, /boyd-status tells you which one the system needs next.

How is this different from just asking Claude for strategy advice?

A chat answer is generated from a blank orientation every time, and nothing holds it accountable later. Here, the structure is the product: state that persists and compounds across sessions, your side and the adversary’s modeled by separate subagents that cannot write to each other’s files, beliefs stored as falsifiable models with confidence levels, a forced Destruction & Creation pass on at least one model per cycle, and a critic that stress-tests every proposal before you see it. The worked cycle page shows what that buys you.

Where does my data live? This is sensitive material.

In plain local files under systems/<name>/ in your working directory — YAML, Markdown, JSONL. No database, no external integrations, nothing scraped, nothing sent anywhere beyond the normal Claude Code conversation itself. Your strategy state is yours to read, diff, and version-control.

Does it take actions on my behalf?

No. It proposes a next action with rationale, branches, and sequels — and stops. You decide, you act, and you report back what happened with /boyd-outcome. The seam between proposal and execution is a design feature.

Plugin or clone — which should I pick?

Plugin if you want the /boyd-* commands available in every project. Clone if you want to read or modify how the agent reasons — the doctrine, the skill prompts, the subagent boundaries. Same skills, same doctrine, both ways.