Governing AI discipline
Basic rules for foreground AI planning, executor AI work, repo inspection, scope control, and human authority.
Doctor Bones / GitHub-native project discipline
A starting discipline for AI-assisted work inside a repository.
Doctor Bones gives a new project an initial governing structure for working with AI: repository-owned guidance, example prompt workflows, workorders, checks, and handoff rules. The GitHub repository remains the source of truth.
What you get at the beginning
Example prompt workflows
Day-in-the-life examples that teach future AI sessions when to read guidance, when to create workorders, and when to stop.
Workorders and checks
A plain contract format for bounded file-changing work, plus checks that help keep repo guidance and examples coherent.
What the repo actually uses
The starting material is ordinary GitHub-native project material. There is no special platform to install before the repo can begin teaching the AI how to work.
Human-facing orientation
The plain starting explanation: what this repo is, how to begin, and where a project-specific copy should put its own memory.
AI operating rules
Standing instructions for AI assistants: inspect repo state, respect the source/project boundary, and choose advice, prompt, edit, or workorder deliberately.
Prompt workflow examples
Concrete day-in-the-life patterns that show how a foreground AI should behave in recurring project situations.
Bounded executor tasks
Workorders describe file-changing work with purpose, scope, constraints, required checks, fallback behavior, and completion notes.
Contract shape
The workorder contract gives future AI sessions a concrete structure to validate against instead of relying on vibes.
Repo checks
Check scripts help catch drift between guidance, examples, schemas, and the discipline the repo claims to teach.
How it starts
You can begin by pointing a foreground AI at the GitHub repository. The AI reads the repo guidance first, then helps decide whether the next move is advice, a prompt, a small doc edit, or a workorder for an executor.
1
Use GitHub as the shared memory
The repository carries the current project instructions. Chat memory is useful, but repo state wins.
2
Ask the foreground AI to read first
The AI should inspect README, AGENTS, examples, and relevant folder guidance before giving architecture advice or suggesting changes.
3
Use workorders for file-changing work
When the task needs an executor, the workorder names the target repo, scope, constraints, checks, fallback behavior, and expected completion note.
Example startup prompt
This is the basic shape. Replace the repository URL with the project repository created from the Doctor Bones template.
You are the foreground AI for <your project repository URL>.
Current repo state beats chat memory. Inspect the current project repository before giving
architecture advice, writing workorders, or suggesting repo changes.
Read README.md, AGENTS.md, examples/README.md, and relevant folder guidance first.
Then identify current state, target, constraints, foreground/executor decision,
and the smallest useful next move.Small prompts can do constrained work
When a repository has enough discipline, a short prompt can carry more meaning than it looks like. The AI is not guessing from a blank page. It can read the repo rules, follow the examples, respect the workorder boundary, and apply referenced architecture lenses such as PFEM and PFCOMM. *This was done vs. complete reference to the repos of PFEM and PFCOMM, not the lite versions of those preloaded in your Doctor Bones.
Make me a WebGL 3D demo of what PFEM and PFCOMM would do in the context of a resilient mesh
of flying things that need to be coordinated with a mission objective.The point is not that the prompt is magic. The point is that the repository narrows the lane before the executor starts making files: evidence stays separate from coordination, authority is explicit, outputs are bounded, and checks or completion notes can be named.
Same architecture, different mission surface
The real PFEM and PFCOMM architectures can also shape a critical-infrastructure alert handling system and a HAM RADIO/RACES field interface for watching the skies. Same generic boundaries; different operator surfaces.
What can Doctor Bones inherent PFEM-lite do as regards coding agents and testing repositories?
PFEM-lite gives a coding agent a first-pass evidence-boundary lens for a repository. It helps the agent ask whether source inputs, normalized records, findings, reports, packages, rollups, tool calls, checks, and completion claims are being kept separate.
Review agent changes
Look for places where generated code collapses evidence, interpretation, action, reports, and proof into one blob.
Test repository boundaries
Ask whether tests, fixtures, schemas, CI workflows, or validation scripts prove the important transitions instead of only checking that files exist.
Keep tool authority honest
Distinguish read-only inspection, draft/propose work, mutation, publish/send actions, and human-approved execution.
This is not a full PFEM audit. It is a useful starter discipline for coding agents: inspect the repo, cite what was read, name the boundary risks, and create a workorder when the fix needs real execution.
What exactly are PFEM-lite and PFCOMM-lite?
PFEM-lite and PFCOMM-lite are small embedded reference snapshots inside Doctor Bones. They give the AI enough vocabulary and boundary discipline to do useful first-pass analysis when the full PFEM or PFCOMM repositories are not being inspected.
PFEM-lite
A lightweight evidence-governance lens: raw evidence, normalized observations, findings, alerts, evidence packages, reports, rollups, provenance, confidence, and proof should not be collapsed.
PFCOMM-lite
A lightweight command-and-coordination lens: command intent, authority context, tasking, assignments, resources, status, receipts, messages, decisions, after-action records, and reports should not be collapsed.
They are not replacements for the real PFEM and PFCOMM architectures. They are the repo-smarts Doctor Bones carries by default so an AI can start in the right lane before you decide whether full architecture inspection is needed.
You still have to think
Doctor Bones is not here to do all your thinking for you or to automate your intelligence. As a software architect, systems architect, or cognitive architect, your job is to understand the day-in-the-life examples and then do your own thing hereafter. Why did we show Polycentric Federated Evidence Mesh and Polycentric Federated Command Mesh doing those things? It is because if you think that way, this may be the right place for you.