Agent Skill is already one of the most widely accepted practices in AI Agent engineering: encapsulating repeatable tasks into capability packages that are discoverable, callable, and injectable into context.
This is certainly valuable. Diagnosing bugs can be a skill. Reviewing code can be a skill. Generating slides can be a skill. Converting files can be a skill. Skills let an Agent enter a proven way of working faster, and they allow teams to distill experience into reusable work specifications.
But as the saying goes: “If all you have is a hammer, everything looks like a nail.” The same is true for skills: as soon as people find a useful practice, their first instinct is often “wrap it into a reusable skill.”
Attractor Guided Engineering (AGE) points out that if every AI engineering practice is turned into a skill, we lose sight of the most critical question in AI-dominated software engineering: how does the system remain controlled and convergent under continuous perturbation?
Skills solve the problem of capability invocation. AGE solves the problem of how domain structure is preserved during the long-term evolution of a repository, and how trajectory drift is suppressed.
This also explains why AGE cannot be demoted to a skill: making skills the primary vehicle for AGE practices would collapse repository-level convergence mechanisms into one-shot invocation capabilities, defeating the purpose of AGE.
1. The Essence of a Skill is a Semantic-Level Hash Map
When many people think of skills, they first see the file form: SKILL.md, description, trigger words, supporting files, scripts, templates.
But these are just the shell. Where a skill really works is that the Agent runtime organizes them into a semantic-level lookup table:
task intent -> matched skill -> procedure bundle
In other words, the Agent does not gain capability simply because a file is named SKILL.md; it gains capability because the current task intent can be matched in the skill description space to a loadable work specification.
The hash here is not a string hash. The key is not a fixed string but a combination of task intent, contextual clues, trigger words, and descriptions; the value is not a single file but a collection of instructions, scripts, templates, and examples that can be injected into the context.
This structure is ideally suited to answering one question:
I need to do this kind of task — which set of practices should I load?
Therefore, skills are very suitable for encapsulating local capabilities: diagnosing bugs, reviewing diffs, calling tools, generating reports, executing checklists. Their organizing axis is invocation intent, mapping “what to do” to “which capability package to load.”
2. The Information Format Is Not the Key
Since the real mechanism of a skill is semantic matching, we must not fetishize the file format of a skill.
For an intelligent agent, the format in which information is written is not essential. AI can read Markdown, and it can also read XML and other formats. Database models, API models, and the like can be fully expressed in DSLs (domain-specific languages).
AGENTS.md and docs/index.md can perfectly serve as information routers and can even do better: through file links, we can provide hierarchical routing by domain structure. The AI can first read a compact entry point and then, as the task requires, progressively open more specific owner docs, model files, tests, and source code.
Therefore, the question is not “has this piece of knowledge been written as a skill?”
The question is: after the information changes form, does the original structure still exist?
A key capability of intelligence is the ability to freely transform information across forms. If the structure remains, knowledge written as Markdown, XML, tests, DSL/schema, or source code anchors can all be used by the AI. If the structure is lost, wrapping it in the most exquisite skill only makes the fragments—after the structure is lost—easier to invoke.
3. Why Dynamical Systems Care About Preserving Structure
Dynamical systems in mathematics and physics provide a useful intuition: the variables describing a system can change, but the key structures governing the system’s evolution must not be casually discarded.
Imagine a pendulum clock. You can describe it with angle and angular velocity, or with position and velocity, or with energy and phase. The form of expression can change, but the key structure of the pendulum cannot be lost: how position and velocity are coupled, how energy changes, how damping dissipates energy, where external forces enter.
If an algorithm only pursues “the next position looks roughly right” without preserving these structures, it might make only small errors at each step, yet over the long term it makes the pendulum swing higher and higher for no reason, or stop suddenly. The local output looks similar, but the long-term system is no longer the original system.
Consider an electrical circuit. You can describe it with node voltages, or with branch currents, or treat the energy stored in capacitors and inductors as state variables. The variable form can change, but some structures must not be lost: charge conservation, the coupling relationships between voltage and current, energy storage and dissipation in components, where the external power source injects energy.
If an algorithm only pursues voltage values at a few sampling points that look close, without preserving these structures, the long-term simulation may spontaneously generate energy, or turn a system that should dissipate into one that oscillates endlessly. The local curve resembles the truth, but the physical meaning of the system is already wrong.
This is what it means to preserve structure:
The form of expression can change, but key constraints, coupling relationships, and conservation/dissipation structures must not be lost.
A controlled system converges over the long term not because each step seems reasonable, but because these structures are preserved through repeated transformations and perturbations.
4. The State Space Is Not the Source Code Space
If we observe software engineering through the lens of dynamical systems, a repository is no longer a static folder but a system that is repeatedly perturbed. Every requirements clarification, plan generation, code modification, test addition, review, and log update pushes the repository to a new state.
Traditional software engineering rests on an implicit assumption: the human brain can serve as the long-term implicit integrator of system truth. Source code, requirements, architectural trade-offs, historical bugs, and unwritten context can ultimately be fully understood by a few core engineers who decide the direction of evolution.
After deep participation of AI, this underlying assumption is shaken. AI can generate at high frequency, modify at large amplitude, and spread across modules, while each session lacks a sustained sense of direction. The expansive force that AI introduces into the state space far exceeds the information processing capacity of a few humans. At this point, unless we forcibly slow AI down to a rhythm that humans can continuously integrate, the source of truth in the system's evolution can no longer be the memory inside someone's head. What the next session can re-read is not the complete intent in the author’s mind, but the code, diffs, logs, tests, docs, models, and audit evidence in the repository.
The history of
nop-chaos-fluxhas already recorded this kind of drift multiple times. Workstream 8 ofdocs/plans/436-deep-audit-2026-05-24-full-remediation-plan.mdfixed an active-doc drift: the documentation describedcomponent:open/close/toggle,component:refresh, the old package split, old source anchors, and an outdated component inventory as current facts, while the live repo was no longer like that.docs/logs/2026/05-26.mdrecorded a proof drift: the E2E tests still asserted that the spreadsheet's30row headers were mounted simultaneously, while the live spreadsheet shell had already been virtualized, so the correct proof could only assert that visible row headers were mounted. Code, documentation, and tests might each be locally reasonable, but the owner/proof/precedence relationships among them had already drifted.
Thus, the basic premise of AGE is:
Repository = Source of Truth
Chat = Transient work surface
Under this premise, the core question is not:
Did the Agent invoke the right skill this time?
but:
After many Agent perturbations, does the repository still converge in a controlled manner along the domain structure?
The basic picture of AGE is:
State space -> Attractor -> Trajectory -> Control
The state space here is not the “source code state space.” Source code answers what the current implementation is, but it cannot alone answer where the system should converge, why a certain design is valid, which behavior has been proven, why a certain deviation was accepted, and from where the AI should recover context next time.
AGE is concerned with the state of the entire repository engineering reality: source code, tests, owner docs, requirements, plans, logs, bug notes, schemas, XML models, database models, XDSL, AGENTS.md, docs/index.md, CI configuration, and audit evidence together constitute a state.
These are not several separable materials, but the distribution of the same set of semantic commitments across different carriers. Code has authority over implementation facts; owner docs have authority over convergence direction; tests have authority over proven behavior; logs/bug notes have authority over the evolution trajectory; plans/audits have authority over whether the current cycle of changes is closed. What AGE must maintain is the relationships among these authorities, not the sanctification of any single file format.
A Skill occupies a different position. AGE organizes the repository itself; skills are external capabilities or control inputs that act upon the repository.
External capabilities can change the system, but they cannot replace the internal structure of the system. A bug-diagnosis skill can be used in many repositories, many domains, many bug types. Its organizing logic is general task capability, not the topology of domain concepts inside a specific repository.
What truly needs to be preserved inside the repository are the relationships among source code, documentation, tests, models, plans, logs, and audit evidence — relationships such as owner, proof, precedence, and freshness. Skills can help modify these things, but they cannot replace the relationships themselves.
At this point, we realize that the skill’s semantic hash is insufficient to solve the problem. What a skill stores is:
task intent -> capability package
What AGE needs to preserve is:
domain concept -> semantic commitment -> implementation location -> proof evidence -> audit/memory -> subsequent obligations
These two structures are not the same. A skill can tell an Agent how to review, but it cannot automatically know which owner doc holds the current semantic fact. A skill can tell an Agent how to write tests, but it cannot automatically know which domain commitment this test protects. A skill can tell an Agent how to update documentation, but it cannot automatically determine whether a piece of information should go into an owner doc, a bug note, a log, a lesson, a reference, or a skill.
These judgments are not invocation capabilities; they are the semantic authority structure of the repository.
5. Why age-skill Is a Wrong Abstraction
Turning AGE into an age-skill is superficially tempting: take AGE’s rules, procedures, checklists, and document templates and write them into a callable capability package. When the Agent needs AGE, it loads this skill.
But this places AGE at exactly the wrong level. A skill is a capability package that is matched and loaded after a task occurs; AGE should be the repository structure that already exists before the task begins. It determines how the task is understood, where information is read from, whose voice prevails in a conflict, and how closure is proved after completion.
AGE cannot wait to appear only after a certain skill is selected. It should already be embodied in:
- The operational boundary of
AGENTS.md - The routing structure of
docs/index.md - The fact ownership of owner docs
- The conflict rules of source-of-truth precedence
- The obligation declarations of plans
- The proof relations of tests
- The closure gates of audits
- The trajectory memory of logs, bug notes, and lessons
- The action constraints of freshness/autonomy
If these relationships exist only inside an age-skill, they are not repository structure but merely the content of a procedure bundle. Whenever the Agent does not match this skill, or the skill conflicts with the live repo, AGE becomes ineffective.
Making age-skill an always-on or global skill does not solve this problem either. At best, it can prescribe “read these owner docs first, check precedence this way, do a closure audit like that.” But the real owner, proof, precedence, and freshness relationships must still exist among the repository’s files, tests, logs, plans, and audit evidence.
So the problem is not whether age-skill is loaded every time; the problem is that a skill is still a capability package imposed on the repository from the outside. AGE must become the underlying topology of the repository itself. As long as owner, proof, precedence, and freshness are not internalized as repository state, AGE is demoted to an external operating method rather than an intrinsic convergence structure.
6. The Missing Concepts That AGE Supplies
Under the image of controlled convergence and structure preservation, what AGE supplies is not a new checklist, but a set of first-class system concepts that skill-ification practices lack.
1. Attractor
To what structure should the system return in the long run? This cannot be decided by any single skill. It needs to be carried by owner docs, architectural baselines, domain design, and source-of-truth precedence. Without an attractor, a skill can only tell the Agent how to do things; it cannot tell the repository where it should converge.
2. Trajectory
Completing a single task does not mean the system direction is correct. Logs, bug notes, lessons, plans, and audit records record how the repository arrived at its current state step by step. Without trajectory memory, the AI starts anew from a local cross-section each time, making it hard to judge whether the system is converging or drifting.
3. Semantic Authority
When a skill, plan, code, test, and documentation disagree, whose voice prevails? AGE requires owner, routing, and precedence, rather than letting the currently invoked skill adjudicate on the fly. Semantic authority is not part of the execution steps; it is the internal order of the repository’s state space.
4. Proof Relation
It is not enough for tests to “have coverage.” Tests must declare which semantic commitment they protect. Audit is not a checklist, either, but an examination of whether commitments have disappeared, weakened, or migrated to non-authoritative carriers. Proof relation makes verification not just about passing commands, but about returning to domain commitments.
5. Freshness / Autonomy
Documentation is not eternally trustworthy just because it was written. Whether a document is fresh affects whether the AI can act on it, how far it can go autonomously, and when it must stop and ask a human. Freshness/autonomy turns “can we trust this, can we do this automatically” into a visible state of the repository, rather than an ad-hoc judgment inside a single session.
6. Structure-Preserving Document Routing
AGENTS.md can provide the AI with a compact operational entry point, and docs/index.md can provide complete routing. The purpose of both is not to cram all knowledge into a single file, but to let the AI progressively open the right information according to the task’s needs. Information disclosure can be layered, but the domain structure must not be fragmented.
These concepts together form the semantic authority topology of AGE.
7. AGE Can Use Skills, But Cannot Become a Skill
AGE is not opposed to skills. Skills are excellent execution scaffolds.
But within AGE, skills can only be method nodes; they cannot be the source of truth, nor can they be AGE itself.
The correct order is:
First, find the route via AGENTS.md / docs/index.md
Then, read the domain or architectural owner doc
Then, read the active requirement / plan / audit evidence
Finally, select the appropriate skill as the execution method
Not:
First, select a skill, then let the skill decide fact ownership
For example, a bug diagnosis skill can tell the Agent how to reproduce and locate a problem. But which domain concept the root cause belongs to, which owner doc needs updating, which test proves the fix, and which category of regression the bug note will constrain in the future — all of these must be decided by returning to the semantic topology of AGE.
A good skill accelerates execution. Bad skill-ification replaces domain structure with execution methods.
8. Judgment Criteria
To judge whether a set of AI engineering practices is over-skill-ified, ask:
- Does it organize knowledge primarily by operational verbs, or by domain concepts and architectural ownership?
- Are its links mainly execution resource references, or owner / invariant / proof / precedence / freshness relationships?
- After information is transformed between skills, plans, code, tests, docs, and logs, can the domain structure still be recovered?
- If all skills are deleted, does the repository still know what is correct, who owns it, and how to prove it?
If the answers are negative, skills have already taken on attractor responsibilities they should not bear.
The ultimate distinction can be compressed into a single sentence:
Skill packages capabilities by invocation.
AGE preserves domain structure across transformations.
Skills make the Agent better at doing things. AGE ensures that after the Agent does things repeatedly, the repository still converges in a controlled manner along the domain structure.