First: every platform optimises for different things. LinkedIn wants keywords. ATS parsers want specific formatting. GitHub rewards README quality. A portfolio has to be crawlable. Staying consistent across all of them without a system is nearly impossible.
Second: every AI agent session starts from scratch. Paste a context dump, watch it burn half the window fetching your links, get generic output. The agent has no grounded facts about you – so it improvises.
Both problems point to the same fix: one verified source of truth, written once, readable by humans and agents alike.
That's AgentKit SEO [1]. The core concept is an agent-context file – a private Markdown document with your career facts, project metrics, and proof links. You build it once using the context skill. Every other skill (LinkedIn, GitHub, CV/ATS, portfolio, X) reads from it.
It ships as a CLI that installs focused skill files into whichever agent you use:
npx agentkit-seo install --provider codex
# or: claude-code, gemini-cli, opencode, or portable SKILL.md
This is not an auto-apply tool. It's the step before that: create one grounded file, then use it as input for any agent, any platform, any task. No hallucination from context overload. No contradictions between your CV and your LinkedIn.Open source, free, MIT licence. My co-author Elia Innocenti and I built it because it didn't exist.
[1] https://github.com/agentkit-seo/agentkit-seo
renatomignone•29m ago
There is also a VERIFIED FACTS HTML comment in the scope declaration that lists every atomic fact that must never be hallucinated: grades, competition rankings, certification IDs, dates. It is invisible in rendered Markdown but visible to the agent reading raw text. If the fact is not in that comment, the agent is not allowed to state it as certain.
The provider adapter problem was genuinely annoying to solve. Codex, Claude Code, Gemini CLI, and OpenCode each have different conventions for where skills live, how they are activated, and what naming they expect. The install CLI resolves that per-provider rather than shipping four separate packages.
Still early and the spec is not frozen. Feedback on the file structure or the provider support is welcome.