Reconstructed Claude Code prompts: what agentic-ai-prompt-research documents
Research into how agentic AI coding assistants work. Reconstructed prompt patterns, agent coordination, and security classification
At a glance
- What is it?
- Leonxlnx/agentic-ai-prompt-research is a reading project, not a code project: thirty markdown files describing how an agentic coding assistant might assemble its system prompt, coordinate sub-agents and classify tool calls for auto-approval. The README is explicit that every file is a reconstruction from observed behaviour, which sets the terms for how you use it.
- Who is it for?
- Read this repository if you are designing an agentic coding assistant and want a vocabulary for the parts: prompt assembly, sub-agent coordination, auto-approval classification, memory precedence. Do not treat any file as a specification, since the README says plainly that these are reconstructions from observed behaviour and that the real implementation may differ significantly.
- Can I use it commercially?
- Not without permission. GitHub finds no licence file in the repository, and without a licence all rights are reserved by default: you may read the code but not reuse it. Check the README, or ask the authors, before using it.
- Is it still maintained?
- Yes. The repository last received commits 170 days ago.
- What is it written in?
- GitHub does not report a main language for this repository.
Answers come from the project's GitHub data, last synced on September 14, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
Reconstruction, not disclosure
The repository states its own status in two sections that sit next to each other. What This Project Is describes an educational deep dive into design patterns behind agentic coding assistants. What This Project Is Not says, in capitals on the word not, that this is not a leak, dump or direct copy of any proprietary system, and that the prompts are best reconstructions based on observable behaviour representing one interpretation of how these systems likely work.
The method is named too: behavioural observation, output analysis, community discussions and publicly shared information. That combination matters when you weigh a claim in these files. Behavioural observation can show you that an assistant asks before running a shell command; it cannot show you the classifier that produced the question. The files here are hypotheses written in the shape of prompts.
The stated audience is AI engineers, researchers and builders who want to learn from the patterns and apply them to their own projects.
How the system prompt is assembled
The central architectural claim is that the prompt is built by a pipeline of modular builders rather than held as one string. The README draws it as two halves split by a cache boundary.
The cacheable prefix holds what stays stable across sessions: identity and safety instructions, permission and hook configuration, code style and error handling rules, tool preferences and usage patterns, and tone, style and output rules. Putting stable text first is what makes prefix caching pay off, since the same bytes are sent on every turn.
Past the cache boundary, the dynamic suffix carries what changes per session: available agents and skills, memory file contents, environment context covering OS, directory and git state, language and output preferences, active MCP server instructions, and context window management directives. The ordering is the point. Anything that varies has to sit after everything that does not.
The auto-approval classifier
Auto-approval is where the security thinking lives, and the README describes three stages. First a base classifier with predefined rules for safe and unsafe operations. Second, user-configurable overrides that can extend or restrict those defaults. Third, a fast first pass with extended reasoning as a fallback for ambiguous cases.
That shape is worth copying on its own merits, and it is also the pattern most likely to be wrong in detail. A three-stage design is what you would infer from watching an assistant approve some commands instantly and hesitate on others, but the thresholds and the rule set are not observable from outside. Two of the documented files cover this ground: prompts/11_permission_explainer.md for risk assessment before approval, and prompts/12_yolo_auto_mode_classifier.md for the multi-stage classifier itself.
Memory loading order
The second structural claim is a memory hierarchy, drawn as a loading order where the earliest entry has the lowest priority. Enterprise or managed configuration comes first, then user global preferences, then project-level instructions that are shared, then the project rules directory, then local overrides that are private and not committed.
Two mechanisms sit on top of that order. Transitive file inclusion means one memory file can pull in another, and conditional injection via path-based filtering means a rule applies only to files matching a path. Together they explain why an assistant can appear to know a convention it was never told in the current session.
The related prompts are prompts/16_memory_selection.md, on choosing which memory files enter context for a query, prompts/24_memory_instruction.md, on hierarchical loading and override semantics, and prompts/27_remember_skill.md, on organising and promoting memories.
The thirty documented patterns
The files are numbered 01 through 30 and grouped by role. Core identity holds 01 main system prompt, 02 simple mode, 03 default agent prompt and 04 cyber risk instruction. Orchestration holds 05 coordinator system prompt and 06 teammate prompt addendum. Specialized agents covers 07 verification agent, 08 explore agent, 09 agent creation architect and 10 status line setup agent. Security and permissions holds 11 and 12. Tool descriptions is 13.
The remaining groups are larger. Utility patterns include 14 tool use summary, 15 session search, 16 memory selection, 17 auto mode critique, 20 session title, 29 agent summary and 30 prompt suggestion. Context window management is 21 compact service and 22 away summary. Dynamic behaviors covers 18 proactive mode, 23 chrome browser automation and 24 memory instruction. Skill patterns covers 19 simplify skill, 25 skillify, 26 stuck skill, 27 remember skill and 28 update config skill.
The numbering is not sequential inside a group, which suggests files were added as they were identified. The verification agent at 07 is described as an adversarial testing agent that validates implementations, and the explore agent at 08 as read-only codebase exploration with no-modify constraints.
Reading the repository
There is nothing to install. The file listing is README.md and the prompts/ directory, and GitHub reports no language for the repository. Getting a copy and opening a file is the whole workflow:
git clone https://github.com/Leonxlnx/agentic-ai-prompt-research.gitFrom there, prompts/01_main_system_prompt.md is where the assembly claim is worked out in detail, and prompts/12_yolo_auto_mode_classifier.md is the one to read if auto-approval is what you came for. The README's Architectural Observations section summarises the three big ideas, prompt assembly, security classification and memory hierarchy, so read that before opening individual files.
Where the reconstructions can mislead
The failure mode is treating a reconstruction as a specification. If you build a permission system that copies the three-stage classifier described here, you have built something that behaves the way one observer guessed Claude Code behaves, and nothing in this repository can tell you how far off it is.
There is also no executable artifact to check any of it against. No tests, no scripts, no sample transcripts, and no recorded outputs from which a reader could judge whether a given prompt reproduces the observed behaviour. Every claim rests on the author's reading of behaviour and community discussion.
Two practical notes sit on top. The repository has no licence file and GitHub reports no licence, so the terms for reusing this text are unstated. And the last push was on 2026-03-31, so anything describing a product that ships continuously is describing it as of that date.
Source instead of reconstruction
If you want the implementation layer rather than a guessed-at description, the leaked source mirror at codeaashu/claude-code is the direct alternative. It publishes the actual src/ directory of the Claude Code CLI with an MCP server for searching it, so claims can be checked against code instead of inference. The trade is sharp: that repository carries a NOASSERTION licence on someone else's source and is a snapshot dated 2026-03-31, so it is better for answering narrow structural questions than for anything you intend to ship.
Between the two, this repository is the better starting point and the worse final authority. Its categories give you a map of what to look for; the source, where you can get it, tells you whether the map is right.
Editorial conclusion
Read this repository if you are designing an agentic coding assistant and want a vocabulary for the parts: prompt assembly, sub-agent coordination, auto-approval classification, memory precedence. Do not treat any file as a specification, since the README says plainly that these are reconstructions from observed behaviour and that the real implementation may differ significantly. Verify the parts you plan to copy against source you can read, and check the licence before reusing the text.
Frequently asked questions
Are these the real Claude Code prompts?
No. The README says the files are reconstructed approximations based on behavioural observation, output analysis, community discussions and publicly shared information, and that the actual implementation may differ significantly.
Does agentic-ai-prompt-research contain runnable code?
No. The file listing is README.md plus the prompts directory, and GitHub reports no language for the repository, so it is documentation meant to be read.
What does the auto mode classifier do?
The README describes three stages: a base classifier with predefined rules for safe and unsafe operations, user-configurable overrides that extend or restrict the defaults, and a fast first pass that falls back to extended reasoning for ambiguous cases.
How does the repository say memory is loaded?
It describes a hierarchy where the earliest entry has the lowest priority: enterprise or managed configuration, user global preferences, project-level instructions, the project rules directory, then local overrides that are private and not committed.
Community notes