The root
agentkit-seomodule is the entrypoint for the whole bundle. It is a runtime wiki and project self-description that helps an agent understand the system, navigate the knowledge graph, and route a request to the single platform module that fits, instead of loading every skill at once.
1. Overview
AgentKit SEO ships seven installed runtime skills: one orchestration module and six platform modules (agent context optimization, GitHub, LinkedIn, CV/ATS, web portfolio, and X/Twitter). The orchestration module is the one an agent reads first.
It does two jobs:
- Self-description. It explains what AgentKit SEO is, what each module covers, and where the boundaries between modules are, so an agent can answer “which module should I use?” without guessing.
- Routing. It directs a broad request to a single module and the smallest set of references that module needs, rather than pulling the entire library into context.
This keeps each session focused: one module, the references it needs, and the user’s private agent-context-file as the factual base.
2. Use this module when
- A request is broad and the right platform module is not yet obvious.
- An agent needs the project self-description and the knowledge-graph entrypoint before loading a module.
- A task should load one module and its references, not the whole bundle at once.
3. Fast path
- Read the root self-description to understand the system and its module boundaries.
- Identify the single surface the request is really about (a profile, a repository, a CV, a site, a posting strategy, or the context file itself).
- Route to that module and load only the references the current task needs.
- Keep the private agent-context-file as the source of truth the chosen module reads before writing.
Section: routing the request
The orchestration module maps a request to one module. Most requests resolve to a single surface.
| The request is about | Route to |
|---|---|
| Building or maintaining the private career source of truth | agent-context-optimization |
| A GitHub profile or repository | github |
| A LinkedIn profile | |
| A CV or resume for ATS parsing | cv-ats |
| A personal website or portfolio | web-portfolio |
| An X/Twitter profile or posting strategy | x-twitter |
When a request touches more than one surface, the orchestration module still routes to one module at a time. It starts with the context file when the facts are not yet consolidated, then sends each public surface through its own module.
Section: progressive disclosure
The orchestration module exists so an agent does not have to load the whole system to answer a narrow question. A broad question enters at one entrypoint and narrows to a single module and a single constraint.
In practice this means:
- Load one module, then only the references and wiki entries that the current task needs.
- Ask for the smallest missing input set rather than demanding every asset upfront.
- Pull deeper context only when the task actually requires it.
This is token discipline: the agent spends its context budget on the surface being worked on, not on instructions for the other surfaces it is not touching.
Section: knowledge graph
The modules connect as a navigable Markdown knowledge graph with one entrypoint and explicit edges. The root self-description is that entrypoint. From there, each module links to its own references and its own wiki entries (canonical definitions, platform constraints with confidence labels, known failure modes, and audit rules).
The private agent-context-file sits beside the graph: platform modules read it before writing, so every public surface is generated from the same verified facts and stated goals. See the Design page for how the LLM Wiki, evidence labels, and one-source-many-adapters distribution fit together.