Agent skill · software engineering · davila7
context-architecture
Audit a codebase and bind every claim it makes about itself to a mechanism that fails when the claim stops being true, so it is legible to people and AI agents. Applies Context Architecture's nine principles: make structure say what the system does, place AGENTS.md at boundaries, codify conventions, and bind every claim the repo makes about itself to a mechanism (compiler, linter, automated tests, review) that fails when the claim stops being true. Works greenfield (a repo born legible) and brownfield (a repo restructured in steps). Use when an agent reimplements code that already exists, invents structure, follows stale or deleted docs, propagates a deprecated pattern, or resolves ambiguity at random, or when asked to make a repository "agent-ready", "AI-legible", or to add or fix AGENTS.md / CLAUDE.md files.
Why this skill is useful
Adds a framework for binding repository claims to mechanisms, enabling self-verifying codebases that are legible to AI agents.
What it needs
About 13k tokens when loaded. Last updated 2026-08-06. 30,138 stars on the source repository.
What this skill does
Context Architecture: bind a repository's claims to mechanisms This skill applies Context Architecture to a repository: it makes the repo's intent and behavior equally legible to people and AI agents, and binds every claim the repo makes about itself to a mechanism that fails when that claim stops being true. It works from the first commit (a repo can be born legible) and on a repo that grew without design (restructured in steps, never all at once). The job is to take the repo as it is and make it legible and self-verifying, without a big-bang rewrite. Context Architecture treats the repository itself (its file tree, boundaries, conventions, and embedded context) as a designed artifact, not an accident of growth. Introduced by Sergio Azócar in October 2025. Canonical specification: https://context-architecture.dev The one assumption Design for a reader who retains nothing between sessions and knows only what the repository says out loud. An AI agent meets this exactly; a new human contributor approximates it. The rule (the test you run, claim by claim) Every claim a repository makes about itself must be bound to a mechanism that fails when that claim stops being true. That is the whole architecture. Everything else is how you apply it. A claim is anything the repository holds about itself, not just the shape of its folders. "Prices are computed in this module and nowhere else" is a claim. "This operation responds within a certain time" is a claim. "This data format does not break for the people already using it" is a claim. For each one, ask: is there a compiler, a linter rule, an automated test, or a review step (by a person or an agent) that breaks when that stops being true? If not, it is prose, and prose goes stale without anything noticing. A claim with no mechanism behind it is the violation. The mechanism has to actually fail, not just exist. A performance test that never exercises the slow path does not satisfy the rule, it violates it. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills davila7/context-architecture