Protocols work by giving the AI explicit behavioral constraints before it starts working. A protocol is not a suggestion — it is a contract loaded into the AI context that governs operating mode, gating behavior, output structure, and stop conditions for the entire session. The key is sequence: the protocol comes first, before any files, before any task description, before any execution. Once it is in context, the AI’s behavior is bound by it for the duration of the session.Documentation Index
Fetch the complete documentation index at: https://mintlify.com/xxyoudeadpunkxx/ai-protocol-kit/llms.txt
Use this file to discover all available pages before exploring further.
Four Steps
Pick by failure mode, not by protocol name
Do not start by browsing protocol names. Start by identifying the failure mode you want to prevent in this session. Is the task still fuzzy and likely to collapse too fast? Is the AI about to write something without a real brief? Are you inspecting a bug where evidence and inference must stay separate? Is this a GitHub publication workflow?Once you know the failure, find the protocol that addresses it. The Protocol Map organizes all 17 protocols by lane and failure mode — use it as your selection tool.
Paste or upload the protocol into the AI context before execution
Open the protocol file and paste its full contents — or upload it directly — into the AI session before you describe the task or provide any material. Do not summarize the protocol. Do not paraphrase it. The AI needs the complete contract, not a description of it.The protocol sets the AI’s operating mode. Everything that follows is governed by it.
Provide the target material
After the protocol is in context, provide the material the AI will work on. The type of material depends on the task — see the section below for examples by category. Be explicit about what the material is: a rough idea, a repo snapshot, a bug report, a set of constraints. The protocol will determine how the AI processes it.
Let the protocol control the workflow
Once the protocol and target material are both in context, let the protocol drive. It will ask the questions it needs to ask, enforce gates before proceeding, surface assumptions instead of hiding them, manage review loops if the protocol calls for them, and apply the stop condition when something is missing or unresolved.Do not prompt the AI to skip gates, rush to output, or bypass review steps. If a protocol is asking questions, those questions are gates — they exist because the protocol has identified that proceeding without an answer would produce a worse result.
The “Do Not Stack” Rule
Stacking protocols is not the default. The kit is designed around using the smallest set that fits the task. Stack only when one protocol controls the session and another controls the artifact or publication target — and those two concerns are genuinely distinct. For example, running a GitHub repository publication workflow may legitimately require a session-governance protocol alongside a README authoring protocol, because one governs how the AI operates and the other governs what the AI produces. When in doubt, use one protocol and expand scope only if a second failure mode appears that the first protocol cannot address.What Counts as Target Material
The target material is whatever the AI will work on inside the protocol. Different protocols expect different types of material. Files — Source code, configuration files, markdown documents, or any artifact the AI should read, inspect, or modify. Used in agentic sessions, review protocols, and GitHub workflows. Repo snapshot — A directory listing, file tree, or representative subset of a repository. Used when the AI needs to understand repository structure without full file access. Relevant for publication preparation and README framing. Page — An existing HTML page, documentation page, or web surface the AI should audit, restructure, or prepare for publication. Used in page publication and discovery protocols. README — The current README file from a repository. Used as primary input for README framing, authoring, and publication protocols. Bug report — A description of observed behavior, error output, reproduction steps, or field observations. Used with Field Findings & Bugs Protocol to structure findings without collapsing evidence and inference. Rough idea — An early-stage description of what you want to build, write, or solve — before it is ready for execution. Used with Idea Shaping and Pre-Task Expansion protocols to surface constraints and shape the structure before any drafting begins. Constraints — Explicit limits, requirements, non-negotiables, or system parameters that must govern the output. Used across multiple protocols to close gates before execution.Picking a Protocol by Failure Mode
If you are not sure which protocol to use, match your situation to one of these failure modes:My idea is fuzzy and not ready for execution
My idea is fuzzy and not ready for execution
Use Idea Shaping Protocol v1. This protocol operates in two explicit modes — shaping first, drafting only after explicit approval. It prevents the AI from collapsing a rough idea into a confident answer before the real constraints and structure are visible. Load it before you describe the idea.
The task is about to collapse too fast into the obvious answer
The task is about to collapse too fast into the obvious answer
Use Pre-Task Expansion Protocol v1. This protocol stops the AI from rushing to the first plausible answer by forcing it to expose alternative readings, tensions, and the surrounding shape of the problem before any output is produced.
I need a brief before building, writing, or implementing
I need a brief before building, writing, or implementing
Use HTML Page & Tool Briefing Protocol v2 for static pages, web surfaces, or local tools. Use Output for Real Readers Protocol v2 for guides, README text, emails, forms, instructions, or any reader-facing material. Both protocols close the brief — reader, purpose, tone, constraints, language — before drafting begins.
I am inspecting a bug, reviewing findings, or preserving field observations
I am inspecting a bug, reviewing findings, or preserving field observations
Use Field Findings & Bugs Protocol v2. This protocol keeps evidence, inference, uncertainty, and relations in separate, named categories. It prevents the common failure where a confident-sounding summary buries the distinction between what was observed and what was inferred.
I am working on GitHub — repo, README, Pages, badges, or publication
I am working on GitHub — repo, README, Pages, badges, or publication
Match the specific surface to the right protocol. For full repository preparation, use GitHub Repository Publication Preparation Protocol v2. For README work, use GitHub README Framing and Authoring Protocol v2. For GitHub Pages, use GitHub Pages Discovery Set Protocol v1. For badges, counters, and analytics decisions, use GitHub Badge, Telemetry & Counter Protocol v1.2.3. See the Protocol Map for the complete GitHub lane.
I need AI to operate across files, tools, and multiple passes
I need AI to operate across files, tools, and multiple passes
Use GPT Agentic Posture Contract for sessions where the AI needs to work like Codex: tool-aware, grounded in real files and artifacts, ledger-based, and verification-oriented rather than operating as a chat assistant. Use Triad AI Orchestration Protocol v3 when the session requires explicit executor/reviewer separation — one AI near the real target, one AI reviewing snapshots and proposing fixes, with the human as the only bridge between them.