# AgentKit SEO full LLM wiki

This file concatenates the installed AgentKit SEO wiki entries for LLM-readable project and module context.

---

## Source: .skills/agent-skill/agentkit-seo/wiki/agentkit-seo.md

<!--
metadata:
  wiki: agentkit-seo
  module: agentkit-seo
  title: "AgentKit SEO"
  status: stable
  confidence: stable
  last_reviewed: 2026-05-27
  review_by: 2026-11-27
  source_status: repo
  agent_priority: high
-->

# AgentKit SEO

> AgentKit SEO is a portable skill bundle for agent-assisted professional discoverability work. It gives agents a context-first workflow, platform-specific methods, and provider-aware install layouts.

## 1. Load contract

Read this file when the user asks what AgentKit SEO is, what ACO means, how the skill system works, what the installer deploys, or how the repository's runtime architecture is organized.

If this file is unavailable in an older install, use `SKILL.md`, `references/installation-strategy.md`, and the installed `agentkit-seo-install.json` manifest when present. State that the wiki entry is unavailable before making architecture claims that depend on it.

## 2. Canonical definition

AgentKit SEO is an installable set of Markdown-first agent skills for improving public professional surfaces:

- Personal career context files
- Private VitaeGraph career knowledge graphs
- LinkedIn profiles
- GitHub profiles and repositories
- CV and resume material for ATS-safe parsing
- Web portfolios
- X/Twitter profiles and posting surfaces

The package is distributed as `agentkit-seo` on npm. Its stable runtime unit is a folder containing `SKILL.md` plus supporting references. Provider adapters copy or wrap those shared skill folders for different agent environments.

## 3. Agent context optimization

Agent context optimization, or ACO, is the process of building and maintaining a private, structured Markdown source of truth for a person's professional facts.

The resulting personal career context file stores verified identity, education, experience, projects, achievements, links, target roles, growth direction, evidence boundaries, constraints, claims to avoid, and positioning notes. Platform skills use that file as factual and directional input. They should not invent missing credentials, metrics, projects, employers, testimonials, responsibilities, or mature expertise for a future direction that is only stated as intent.

The context file is private user material. Do not commit it to this repository or include it in public generated docs.

VitaeGraph is a separate private, multi-file career knowledge graph for deep hierarchical records, containment and cross-record relationships, and progressive retrieval. Its default directory is `~/.agentkit-seo/vitaegraph/`. The personal career context file remains a separately located and separately usable artifact. Neither artifact silently creates or replaces the other.

## 4. Runtime architecture

AgentKit SEO uses four runtime-facing layers:

- `hub/`: human-readable playbooks, examples, templates, and source notes.
- `.skills/agent-skill/`: canonical portable runtime skills.
- `.skills/providers/`: provider-specific install notes, manifests, command wrappers, and extension metadata.
- `.skills/export/`: CLI code for install, export, doctor, list, version, and template commands.

The root `skills/`, `commands/`, `GEMINI.md`, and `gemini-extension.json` files are distribution artifacts for Gemini-compatible installs and gallery discovery. They are not the primary source of runtime methodology.

## 5. Skill behavior

`SKILL.md` files define when a skill should be used, what workflow to follow, and which supporting files to read. They should stay concise.

Runtime `references/` files contain focused procedural guidance for a task. Runtime `wiki/` files contain durable definitions, constraints, confidence labels, and failure modes that the agent loads only when the task needs them.

Agents should route to one module by default. Cross-platform work should usually start with the agent-context-optimization skill so user facts are normalized before public outputs are rewritten.

Before loading detailed module files, agents should use this root wiki as the graph entrypoint:

1. Use this file to understand the repository and runtime layers.
2. Choose the relevant module from the linked module wiki indexes.
3. Read only that module's `wiki/index.md` before deciding whether `wiki/knowledge.md`, `references/`, or human hub files are needed.
4. Use `llms.txt` as the public package map and `llms-full.txt` as the full bundled wiki context when those files are available in the package checkout.
5. Use `.assets/docs/getting-started.md` for setup onboarding and `.assets/docs/end-to-end-workflows.md` for demo prompts, sample inputs, multimodal material, and expected deliverables.

## 6. Install behavior

The CLI installs or exports the same shared skills into provider-specific layouts. Supported providers include:

- Shared bundle
- Claude Code
- Codex
- Gemini CLI
- Antigravity CLI
- OpenCode

Provider behavior is not identical. Some environments use native skill loading. Some expose slash commands. Some require explicit skill names in the prompt. The shared skill folder names are the portable contract.

## 7. Boundaries

AgentKit SEO does not guarantee rankings, recruiter attention, ATS scores, rich results, snippets, indexing speed, AI citations, or platform distribution.

Agents using AgentKit SEO must separate:

- Verified facts from the user's supplied context
- Facts observed in public pages or local files
- Documented platform behavior
- Inference from those facts
- Disputed or unstable claims that need review

When a claim depends on current platform behavior, paid-tier behavior, provider support, or search and ranking systems, verify with current sources when tools allow it or mark the claim as source-dependent.

## 8. Shared evidence labels

Use these labels when source status could affect a recommendation:

- `Verified`: Observed directly in inspected public material, local files, rendered output, supplied screenshots, extracted text, or a supplied source-of-truth file.
- `From context`: Taken from the user's personal career context file.
- `From source`: Taken from supplied source material such as pasted text, exports, screenshots, public URLs, local files, or job descriptions.
- `Inference`: Reasoned from inspected evidence, but not directly observed as a fact.
- `Inaccessible`: Could not be inspected because the surface is private, login-gated, unavailable, blocked, or outside the task scope.
- `Needs evidence`: A claim that should not be reused publicly until the user supplies support or it is verified in source material.

Do not turn `Inference`, `Inaccessible`, or `Needs evidence` claims into confident public copy.

## 9. Graph navigation

The repository has two connected documentation branches:

- Human layer: `README.md` -> `hub/<module>/README.md` -> `hub/<module>/sources.md`.
- Runtime layer: this root wiki -> `agentkit-seo-<module>/SKILL.md` -> `wiki/index.md` -> `wiki/knowledge.md`.

Human hub files explain playbooks, examples, templates, and source ledgers. Runtime wiki files explain compact agent-loadable constraints, confidence labels, and failure modes. Prefer the runtime branch for installed-agent work, and use the human branch when the task asks for contributor docs, editorial playbooks, templates, examples, or source provenance.

## 10. See also

- [Agent context optimization wiki index](../../agentkit-seo-agent-context-optimization/wiki/index.md)
- [CV ATS wiki index](../../agentkit-seo-cv-ats/wiki/index.md)
- [GitHub wiki index](../../agentkit-seo-github/wiki/index.md)
- [LinkedIn wiki index](../../agentkit-seo-linkedin/wiki/index.md)
- [VitaeGraph wiki index](../../agentkit-seo-vitaegraph/wiki/index.md)
- [Web portfolio wiki index](../../agentkit-seo-web-portfolio/wiki/index.md)
- [X Twitter wiki index](../../agentkit-seo-x-twitter/wiki/index.md)
- [Getting started](../../../../.assets/docs/getting-started.md)
- [End-to-end demos](../../../../.assets/docs/end-to-end-workflows.md)
- [llms.txt](../../../../llms.txt)
- [llms-full.txt](../../../../llms-full.txt)

---

## Source: .skills/agent-skill/agentkit-seo-agent-context-optimization/wiki/index.md

<!--
metadata:
  wiki: agentkit-seo
  module: agentkit-seo-agent-context-optimization
  title: "Agent context optimization wiki index"
  status: stable
  confidence: stable
  last_reviewed: 2026-05-27
  review_by: 2026-11-27
  source_status: repo
  agent_priority: high
-->

# Agent context optimization wiki index

> This file maps the agent-context wiki files to the tasks that need them. Load this index before reading agent-context wiki entries.

## 1. Load contract

Read this file when `agentkit-seo-agent-context-optimization/SKILL.md` routes a task to the local wiki.

If this file is unavailable in an older install, continue with the matching `references/` file and mark wiki-specific guidance as unavailable. Do not fail the task only because the wiki index is missing.

## 2. Wiki files

- [knowledge.md](knowledge.md): Compiled runtime knowledge for personal career context file structure, source-of-truth behavior, maintenance, validation, evidence handling, and known agent failure modes.

## 3. Conditional loads

Read [knowledge.md](knowledge.md) when the task asks about any of these topics:

- What a personal career context file is, when to create one, where to store it, or how it relates to platform skills
- Context-file structure, `QUICK REFERENCE`, canonical section order, semantic tags, or `VERIFIED FACTS`
- Maintenance, validation, chronology checks, source ledgers, or targeted updates
- Cross-platform fact conflicts, unsupported claims, or downstream public-output grounding
- Audit output that must separate existing context facts, supplied sources, inference, and needs-evidence claims
- Known LLM failure modes for context-file creation and maintenance

Do not read [knowledge.md](knowledge.md) for a single downstream platform rewrite when the context file is already clean and the platform skill has enough facts.

## 4. Eager loads

There are no eager wiki loads for this module. The agent-context skill should load wiki entries conditionally after it identifies the task surface.

## 5. Degraded mode

When a wiki file referenced here is missing:

- Continue with the relevant `references/` file.
- Avoid making stronger claims than the loaded reference supports.
- Add a short note only when the missing wiki would affect confidence, source status, or maintenance guidance.
- Do not ask the user to reinstall unless the missing file blocks a requested wiki-specific maintenance task.

Root wiki: [agentkit-seo/wiki/agentkit-seo.md](../../agentkit-seo/wiki/agentkit-seo.md).

---

## Source: .skills/agent-skill/agentkit-seo-agent-context-optimization/wiki/knowledge.md

<!--
metadata:
  wiki: agentkit-seo
  module: agentkit-seo-agent-context-optimization
  title: "Agent context optimization runtime knowledge"
  status: stable
  confidence: stable
  last_reviewed: 2026-05-27
  review_by: 2026-11-27
  source_status: repo
  agent_priority: high
-->

# Agent context optimization runtime knowledge

> This file contains durable agent-context knowledge for agents. Use it to keep personal source-of-truth files structured, private, factual, and maintainable.

## 1. Load contract

Read this file only after [index.md](index.md) indicates that the current task needs compiled agent-context knowledge.

If this file is unavailable in an older install, continue with `references/why-and-when.md`, `references/spec-and-structure.md`, `references/drafting-template.md`, `references/maintenance-and-validation.md`, or `references/operating-workflow.md` as appropriate. Mark source-of-truth and validation guidance as lower confidence if the wiki is unavailable.

## 2. Evidence labels

Use the AgentKit SEO evidence labels defined in `agentkit-seo/wiki/agentkit-seo.md`.

For context-file work, `From context` means a fact is already present in the existing personal career context file. Do not treat `From context` as verified against external evidence unless the source entry or inspected material supports it.

## 3. Canonical definitions

**Personal career context file** means a private Markdown source of truth for a person's professional facts and stated career direction, used to ground repeated CV, LinkedIn, GitHub, portfolio, and X/Twitter work.

**Agent context optimization** means building, normalizing, validating, and maintaining that file so downstream platform outputs reuse facts instead of inventing or re-asking for them.

**QUICK REFERENCE** means the selective YAML snapshot directly under the H1. It carries current positioning, target roles, top skills, tools, credentials, and public links for fast agent loading.

**Goals and targeting** means the stated-intent section that records ideal role, current focus, target roles, target locations, growth direction, interests, evidence boundaries, positioning constraints, and claims to avoid. It guides platform outputs but is not a verified-facts record.

**VERIFIED FACTS** means the HTML comment in the scope declaration that stores hard factual anchors such as dates, grades, scores, IDs, rankings, and other facts that must not be guessed.

**Semantic tags** mean stable bracketed labels such as `[DEGREE]`, `[COURSE]`, `[PROJECT]`, `[THESIS]`, `[ROLE]`, `[PAPER]`, `[PREPRINT]`, `[CERT]`, `[COMPETITION]`, `[AWARD]`, and `[ORG]`.

## 4. Structural constraints

- `stable`: The context file is one Markdown document with exactly one H1.
- `stable`: The H1 uses `# Full Name - positioning descriptor`.
- `stable`: `QUICK REFERENCE` appears immediately after the title and uses a fenced YAML block.
- `stable`: QUICK REFERENCE values should stay flat and selective; omit empty fields.
- `stable`: `Goals and targeting` appears after QUICK REFERENCE unless the user intentionally declines direction capture.
- `stable`: Goals, growth direction, emerging interests, evidence boundaries, positioning constraints, and claims to avoid are stated intent, not verified facts.
- `stable`: Required sections include scope declaration, education, skills index, and languages.
- `stable`: Conditional sections appear only when relevant material exists, including professional experience, research and publications, certifications and achievements, and extracurricular or leadership material.
- `stable`: The scope declaration closes with a `VERIFIED FACTS` HTML comment.
- `stable`: Skills in the skills index must be evidenced elsewhere in the file.
- `stable`: Languages should be represented as a table.
- `likely`: `~/.agentkit-seo/<name-surname>-career-context.md` is a portable default path when the user wants a reusable file, but an explicit user path always wins.

## 5. Maintenance and validation rules

- `stable`: Update only when a real-world fact is verifiable.
- `stable`: Do not add speculative future roles, awards, certifications, or project outcomes.
- `stable`: Use future direction to select emphasis, not to invent evidence. Frame weakly evidenced direction as "building toward", "targeting", or "interested in" until a verified project, role, course, or artifact supports stronger wording.
- `stable`: Repair structure before polishing language when the file is structurally weak.
- `stable`: Preserve chronology, role titles, metrics, and project ownership across downstream outputs.
- `stable`: Surface conflicts instead of silently normalizing them.
- `stable`: Prefer targeted entry-level edits over whole-file rewrites.
- `likely`: Keep a version history, ideally in Git, when the file is maintained over time.
- `inferred`: Compress peripheral detail rather than deleting important evidence when token growth becomes a problem.

## 6. Agent failure modes

- Treating memory, pasted exports, or chat history as a stable source of truth instead of writing a maintained file.
- Searching the user's full filesystem for a context file without an explicit path or confirmed default.
- Writing outside the workspace without confirming the destination and provider permissions.
- Turning unsupported claims into polished public copy.
- Adding skills to QUICK REFERENCE or the skills index without evidence in the body.
- Converting target roles, growth direction, or emerging interests into claimed mature expertise.
- Omitting claims-to-avoid or evidence boundaries when a user is repositioning across fields.
- Reordering canonical sections for style reasons.
- Rewriting the whole context file when a targeted entry update would preserve history and reduce risk.
- Treating `From context` as externally verified when no evidence line or inspected source supports it.

## 7. Output rules

When producing a context-file audit, creation plan, or maintenance edit:

- State whether a context file exists, was created, or needs a confirmed path.
- Name the selected storage mode and path when writing is part of the task.
- Keep the source ledger grouped by input type or file.
- Separate normalized facts, conflicts, gaps, and claims needing evidence.
- Update `VERIFIED FACTS` when adding hard factual anchors.
- Hand off to exactly one platform skill after context cleanup unless the user asks for a multi-surface pass.
- Include a one-line `Depth note` when sources, sections, or cross-platform checks were intentionally bounded.

Shared taxonomy: [agentkit-seo/wiki/agentkit-seo.md](../../agentkit-seo/wiki/agentkit-seo.md). Source grounding: [hub/agent-context-optimization/sources.md](../../../../hub/agent-context-optimization/sources.md).

---

## Source: .skills/agent-skill/agentkit-seo-cv-ats/wiki/index.md

<!--
metadata:
  wiki: agentkit-seo
  module: agentkit-seo-cv-ats
  title: "CV ATS wiki index"
  status: stable
  confidence: stable
  last_reviewed: 2026-05-27
  review_by: 2026-11-27
  source_status: repo
  agent_priority: high
-->

# CV ATS wiki index

> This file maps the CV ATS wiki files to the tasks that need them. Load this index before reading CV ATS wiki entries.

## 1. Load contract

Read this file when `agentkit-seo-cv-ats/SKILL.md` routes a task to the local wiki.

If this file is unavailable in an older install, continue with the matching `references/` file and mark wiki-specific guidance as unavailable. Do not fail the task only because the wiki index is missing.

## 2. Wiki files

- [knowledge.md](knowledge.md): Compiled runtime knowledge for ATS-safe CV structure, parser risks, tailoring, job-description alignment, evidence handling, and known agent failure modes.

## 3. Conditional loads

Read [knowledge.md](knowledge.md) when the task asks about any of these topics:

- Full CV or resume audits, ATS safety reviews, parser debugging, or plain-text extraction checks
- Layout, section order, file type, typography, contact block, dates, URLs, or LaTeX PDF QA
- Job-description tailoring, keyword integration, bullet rewrites, or role-specific summaries
- Fact consistency across CV, context file, LinkedIn, GitHub, portfolio, or public proof
- Audit output that must separate CV evidence, job-description requirements, supplied context, and inference
- Known LLM failure modes for CV and ATS work

Do not read [knowledge.md](knowledge.md) for a narrow bullet rewrite when the supplied bullet, target role, and supporting facts are enough.

## 4. Eager loads

There are no eager wiki loads for this module. The CV ATS skill should load wiki entries conditionally after it identifies the task surface.

## 5. Degraded mode

When a wiki file referenced here is missing:

- Continue with the relevant `references/` file.
- Avoid making stronger claims than the loaded reference supports.
- Add a short note only when the missing wiki would affect confidence, source status, or maintenance guidance.
- Do not ask the user to reinstall unless the missing file blocks a requested wiki-specific maintenance task.

Root wiki: [agentkit-seo/wiki/agentkit-seo.md](../../agentkit-seo/wiki/agentkit-seo.md).

---

## Source: .skills/agent-skill/agentkit-seo-cv-ats/wiki/knowledge.md

<!--
metadata:
  wiki: agentkit-seo
  module: agentkit-seo-cv-ats
  title: "CV ATS runtime knowledge"
  status: stable
  confidence: likely
  last_reviewed: 2026-05-27
  review_by: 2026-08-27
  source_status: mixed
  agent_priority: high
-->

# CV ATS runtime knowledge

> This file contains durable CV and ATS knowledge for agents. Use it to keep resume structure, parser safety, tailoring, and factual grounding conservative and source-aware.

## 1. Load contract

Read this file only after [index.md](index.md) indicates that the current task needs compiled CV ATS knowledge.

If this file is unavailable in an older install, continue with `references/structure-and-formatting.md`, `references/parser-risks-and-agent-workflow.md`, `references/keywords-and-bullets.md`, `references/cv-audit-and-maintenance.md`, or `references/section-recipes.md` as appropriate. Mark parser, file-format, and confidence-label guidance as lower confidence if the wiki is unavailable.

## 2. Evidence labels

Use the AgentKit SEO evidence labels defined in `agentkit-seo/wiki/agentkit-seo.md`.

For CV work, `Verified` means the fact was observed in the CV, editable source, rendered PDF, plain-text extraction, supplied job description, supplied context file, or inspected public proof. `Inaccessible` commonly applies to ATS vendor scoring, recruiter screen behavior, hidden job filters, private profiles, and uninspected cross-platform facts.

## 3. Canonical definitions

**ATS-safe CV** means a resume or CV that uses simple, text-based structure so parsers and recruiters can recover contact details, sections, chronology, skills, and experience in a sensible order.

**Parser safety** means preserving text extraction, reading order, explicit URLs, standard section names, and basic character integrity across the final submission format.

**Tailoring** means selecting and rewriting true experience so it matches a target role or job description without fabricating skills, metrics, employers, dates, credentials, or outcomes.

**Plain-text extraction check** means copying or extracting the final document text and checking reading order, missing text, explicit URLs, and character issues before calling the CV submission-ready.

**Job-description alignment** means mapping real candidate evidence to the hard skills, tools, platforms, domain terms, and role expectations in a target job description.

## 4. Platform and parser constraints

- `stable`: Use a single-column layout for ATS-safe resumes.
- `stable`: Avoid tables, text boxes, sidebars, icons, graphics, skill bars, and hidden text when parser reliability matters.
- `stable`: Put contact details in the document body, not only in headers or footers.
- `stable`: Write URLs explicitly instead of relying only on hidden hyperlink anchors.
- `stable`: Use standard section names such as `Experience`, `Skills`, and `Education`.
- `stable`: Keep Experience and Education in reverse chronological order unless the user's background requires a different documented structure.
- `stable`: Never submit an image-only PDF when parsing matters.
- `stable`: Run a plain-text extraction sanity check before treating a final CV as submission-ready.
- `likely`: `.docx` and text-based PDF are safer final formats than image-heavy or layout-fragile exports, unless the employer requires another format.
- `likely`: 11pt body text is a safe default; 10pt is a practical lower bound in the current project methodology.
- `inferred`: Rewriting a bullet to remove a one-word final line is usually better than adding fragile spacing hacks.
- `disputed`: Exact ATS vendor scores, hidden knockout rules, or guaranteed parsing behavior should not be claimed without vendor-specific evidence.

## 5. Tailoring and keyword rules

- `stable`: Prioritize hard skills, tools, platforms, and domain terms from the job description when they truthfully match the candidate.
- `stable`: Put important keywords into context-rich bullets and summaries, not hidden text or repeated keyword dumps.
- `stable`: Use both long form and acronym on first mention when that improves parser or recruiter clarity.
- `likely`: Action + task or scope + tool or method + measurable result is the default bullet shape.
- `likely`: Approximate metrics are acceptable only when the source material gives enough basis and the wording makes the approximation clear.
- `inferred`: A shorter credible skills list is stronger than a bloated list of unsupported tools.

## 6. Agent failure modes

- Promising ATS success, exact scores, or guaranteed recruiter outcomes.
- Adding hidden keywords, fake metrics, invented tools, unverified credentials, or unsupported seniority.
- Optimizing visual density with fragile spacing hacks, tiny fonts, multi-column layouts, or hidden text.
- Treating a polished PDF as ready without a plain-text extraction check.
- Rewriting a CV from a job description so it reads like the job posting rather than the user's real experience.
- Claiming complete cross-platform consistency after inspecting only a bounded set of sources.
- Fetching or inferring LinkedIn, GitHub, or portfolio facts without user-supplied material or explicit lookup.
- Turning a narrow bullet edit into a full career-history rewrite.

## 7. Output rules

When producing a CV audit, tailoring pass, or parser-safety plan:

- State which CV source, rendered PDF, extraction output, job description, context file, or public proof was inspected.
- Separate ATS or parser blockers, factual consistency issues, tailoring improvements, and recruiter-readability improvements.
- Tie keyword recommendations to the supplied job description and the candidate's real evidence.
- Prefer exact revised bullets or section text over generic advice when the source material is sufficient.
- Use "no conflict found in inspected inputs" for bounded audits instead of implying full verification.
- Include a one-line `Depth note` for full-document audits, parser debugging, or intentionally bounded reviews.

Shared taxonomy: [agentkit-seo/wiki/agentkit-seo.md](../../agentkit-seo/wiki/agentkit-seo.md). Source grounding: [hub/cv-ats/sources.md](../../../../hub/cv-ats/sources.md).

---

## Source: .skills/agent-skill/agentkit-seo-github/wiki/index.md

<!--
metadata:
  wiki: agentkit-seo
  module: agentkit-seo-github
  title: "GitHub wiki index"
  status: stable
  confidence: stable
  last_reviewed: 2026-05-27
  review_by: 2026-11-27
  source_status: repo
  agent_priority: high
-->

# GitHub wiki index

> This file maps the GitHub wiki files to the tasks that need them. Load this index before reading GitHub wiki entries.

## 1. Load contract

Read this file when `agentkit-seo-github/SKILL.md` routes a task to the local wiki.

If this file is unavailable in an older install, continue with the matching `references/` file and mark wiki-specific guidance as unavailable. Do not fail the task only because the wiki index is missing.

## 2. Wiki files

- [knowledge.md](knowledge.md): Compiled runtime knowledge for GitHub profile and repository discoverability, search constraints, Linguist handling, agent-readiness, evidence handling, and known agent failure modes.

## 3. Conditional loads

Read [knowledge.md](knowledge.md) when the task asks about any of these topics:

- GitHub profile audits, pinned repository selection, profile README positioning, or repository packaging
- Repository About text, topic tags, social previews, README structure, trust files, or proof-of-work signals
- GitHub searchability, default branches, archived repositories, forks, file-size limits, or code-search constraints
- Linguist language stats, `.gitattributes`, vendored/generated files, or language-bar corrections
- `AGENTS.md`, Copilot instructions, AI-readable repository structure, or external-agent readiness
- Audit output that must separate verified GitHub evidence from supplied context or inference
- Known LLM failure modes for GitHub profiles and repositories

Do not read [knowledge.md](knowledge.md) for narrow copy edits that do not depend on GitHub constraints, searchability, repository structure, agent-readiness, or confidence labeling.

## 4. Eager loads

There are no eager wiki loads for this module. The GitHub skill should load wiki entries conditionally after it identifies the task surface.

## 5. Degraded mode

When a wiki file referenced here is missing:

- Continue with the relevant `references/` file.
- Avoid making stronger claims than the loaded reference supports.
- Add a short note only when the missing wiki would affect confidence, source status, or maintenance guidance.
- Do not ask the user to reinstall unless the missing file blocks a requested wiki-specific maintenance task.

Root wiki: [agentkit-seo/wiki/agentkit-seo.md](../../agentkit-seo/wiki/agentkit-seo.md).

---

## Source: .skills/agent-skill/agentkit-seo-github/wiki/knowledge.md

<!--
metadata:
  wiki: agentkit-seo
  module: agentkit-seo-github
  title: "GitHub runtime knowledge"
  status: stable
  confidence: likely
  last_reviewed: 2026-05-27
  review_by: 2026-08-27
  source_status: mixed
  agent_priority: high
-->

# GitHub runtime knowledge

> This file contains durable GitHub knowledge for agents. Use it to keep profile, repository, search, Linguist, and agent-readiness advice factual and source-aware.

## 1. Load contract

Read this file only after [index.md](index.md) indicates that the current task needs compiled GitHub knowledge.

If this file is unavailable in an older install, continue with `references/profile-and-repo-structure.md`, `references/search-indexing-and-linguist.md`, `references/profile-and-repo-audit.md`, `references/copilot-and-agent-readiness.md`, or `references/section-recipes.md` as appropriate. Mark search, Linguist, and agent-readiness guidance as lower confidence if the wiki is unavailable.

## 2. Evidence labels

Use the AgentKit SEO evidence labels defined in `agentkit-seo/wiki/agentkit-seo.md`.

For GitHub work, `Verified` means the fact was observed in public GitHub profile fields, repository metadata, topics, README content, fetched files, language stats, or local repository files. `Inaccessible` commonly applies to private repositories, account settings, social-preview settings, contribution visibility settings, organization-only material, and analytics.

## 3. Canonical definitions

**GitHub discoverability** means making a profile or repository easier to find, understand, evaluate, and trust through native GitHub fields, readable files, public metadata, and coherent project packaging.

**Showcase repository** means a public repository selected to represent the user's target role, stack, maturity, and proof of work.

**Profile README** means the special repository README rendered on a user's profile page. It should add context, not replace profile fields, pinned repositories, or repository documentation.

**Linguist integrity** means the repository language stats represent the real first-party code mix without hiding genuine source files or mislabeling generated, vendored, documentation, or data files.

**Agent-readiness** means making repository instructions, setup, validation, architecture, and contribution constraints clear enough for coding agents and human maintainers to operate safely.

## 4. Platform constraints

- `stable`: A GitHub bio is short and should act as a compact role summary, not a full profile.
- `stable`: Repository names, About text, topics, README openings, and pinned selection should describe the same project positioning.
- `stable`: Public code search depends on repository visibility and default-branch content. Private material is not public recruiter evidence.
- `stable`: Archived repositories are poor anchors when searchability or active maintenance matters.
- `stable`: GitHub language statistics are generated by Linguist and can be affected by generated, vendored, documentation, or data-heavy files.
- `stable`: `.github/copilot-instructions.md` is the repo-wide Copilot instruction path, and `.github/instructions/*.instructions.md` is the path-specific instruction pattern.
- `stable`: `AGENTS.md` files use scoped instructions where nearest applicable files matter for agent behavior.
- `likely`: Four to six curated pinned repositories usually communicate stronger proof than a scattered or stale pin set.
- `likely`: A custom social-preview image is useful for showcase repositories when the image clearly represents the project.
- `inferred`: README quickstarts and evaluation paths are stronger trust signals for reviewers than decorative badges alone.
- `disputed`: Stars, forks, activity timing, or contribution heatmaps should not be presented as deterministic ranking levers.

## 5. Search and Linguist rules

- `stable`: Inspect file roles before recommending `.gitattributes` changes.
- `stable`: Use Linguist overrides to correct representation, not to hide real first-party source.
- `stable`: Do not mark first-party source as vendored to manipulate the language bar.
- `likely`: Large generated files, notebooks, data dumps, vendored dependencies, and documentation can distort language stats.
- `likely`: Untouched forks are usually weaker portfolio anchors than owned, documented, active repositories.
- `inferred`: Clear file names, symbols, directory names, and README terms improve human and tool comprehension, even when ranking effects are not known.

## 6. Agent failure modes

- Claiming exact GitHub ranking, Explore, or code-search mechanics without documented evidence.
- Treating stars, forks, contribution graphs, or activity cadence as guaranteed discovery levers.
- Recommending `.gitattributes` patches from the profile page without inspecting repository files.
- Hiding real source files with broad vendored/generated rules to change language stats.
- Inventing repository maturity, security status, vulnerability impact, CI health, license status, or pinned status.
- Rewriting technical work into inflated marketing language unsupported by README or code evidence.
- Suggesting `AGENTS.md` or Copilot instruction files for simple repositories before fixing README, About text, topics, and pins.
- Loading every repository for a bounded profile audit instead of following the depth contract.

## 7. Output rules

When producing a GitHub audit or implementation plan:

- State which profile, repository pages, README files, topics, language stats, and local files were inspected.
- Separate profile, pinned repository, repository metadata, searchability, Linguist, and agent-readiness issues.
- Use `Evidence`, `Why it matters`, and `Change` for high-priority findings.
- Label `.gitattributes` recommendations as verified only after inspecting file roles.
- Prefer concrete README, About text, topic, pin, or file changes over generic branding advice.
- Include a one-line `Depth note` when the audit did not inspect every relevant repository or file.

Shared taxonomy: [agentkit-seo/wiki/agentkit-seo.md](../../agentkit-seo/wiki/agentkit-seo.md). Source grounding: [hub/github/sources.md](../../../../hub/github/sources.md).

---

## Source: .skills/agent-skill/agentkit-seo-linkedin/wiki/index.md

<!--
metadata:
  wiki: agentkit-seo
  module: agentkit-seo-linkedin
  title: "LinkedIn wiki index"
  status: stable
  confidence: stable
  last_reviewed: 2026-05-27
  review_by: 2026-11-27
  source_status: repo
  agent_priority: high
-->

# LinkedIn wiki index

> This file maps the LinkedIn wiki files to the tasks that need them. Load this index before reading LinkedIn wiki entries.

## 1. Load contract

Read this file when `agentkit-seo-linkedin/SKILL.md` routes a task to the local wiki.

If this file is unavailable in an older install, continue with the matching `references/` file and mark wiki-specific guidance as unavailable. Do not fail the task only because the wiki index is missing.

## 2. Wiki files

- [knowledge.md](knowledge.md): Compiled runtime knowledge for LinkedIn profile structure, search visibility, activity, algorithm-confidence boundaries, evidence handling, and known agent failure modes.

## 3. Conditional loads

Read [knowledge.md](knowledge.md) when the task asks about any of these topics:

- Full LinkedIn profile audits, profile architecture, headline, About, Experience, Skills, Featured, or proof alignment
- LinkedIn search visibility, recruiter readability, activity strategy, comments, or topical consistency
- Algorithm explanations, `360Brew`, creator claims, or current-source confidence
- Login-gated public-profile limits, inaccessible fields, endorsements, private metrics, or applicant outcomes
- Audit output that must separate profile evidence from supplied context or inference
- Known LLM failure modes for LinkedIn profiles and activity

Do not read [knowledge.md](knowledge.md) for narrow section rewrites when the supplied section, target role, and proof are enough.

## 4. Eager loads

There are no eager wiki loads for this module. The LinkedIn skill should load wiki entries conditionally after it identifies the task surface.

## 5. Degraded mode

When a wiki file referenced here is missing:

- Continue with the relevant `references/` file.
- Avoid making stronger claims than the loaded reference supports.
- Add a short note only when the missing wiki would affect confidence, source status, or maintenance guidance.
- Do not ask the user to reinstall unless the missing file blocks a requested wiki-specific maintenance task.

Root wiki: [agentkit-seo/wiki/agentkit-seo.md](../../agentkit-seo/wiki/agentkit-seo.md).

---

## Source: .skills/agent-skill/agentkit-seo-linkedin/wiki/knowledge.md

<!--
metadata:
  wiki: agentkit-seo
  module: agentkit-seo-linkedin
  title: "LinkedIn runtime knowledge"
  status: stable
  confidence: likely
  last_reviewed: 2026-05-27
  review_by: 2026-08-27
  source_status: mixed
  agent_priority: high
-->

# LinkedIn runtime knowledge

> This file contains durable LinkedIn knowledge for agents. Use it to keep profile structure, search, activity, algorithm rationale, and public-claim handling factual and source-aware.

## 1. Load contract

Read this file only after [index.md](index.md) indicates that the current task needs compiled LinkedIn knowledge.

If this file is unavailable in an older install, continue with `references/positioning-and-structure.md`, `references/discoverability-and-activity.md`, `references/profile-audit-and-maintenance.md`, `references/algorithm-confidence.md`, or `references/section-recipes.md` as appropriate. Mark algorithm, field-limit, profile-visibility, and activity guidance as lower confidence if the wiki is unavailable.

## 2. Evidence labels

Use the AgentKit SEO evidence labels defined in `agentkit-seo/wiki/agentkit-seo.md`.

For LinkedIn work, `Verified` means the fact was observed in public profile fields, supplied screenshots, exports, pasted section text, visible Featured links, or accessible activity samples. `Inaccessible` commonly applies to login-gated sections, private job preferences, profile completeness, endorsements, recruiter views, analytics, impressions, and applicant outcomes.

## 3. Canonical definitions

**LinkedIn discoverability** means making the profile easier to match, search, understand, and trust through structured fields, standard role language, proof links, and aligned activity.

**Profile architecture** means the alignment of headline, About, Experience, Skills, Featured, location, job preferences, banner, verification, and activity around one credible positioning target.

**Featured proof** means links or media that substantiate important claims, such as projects, repositories, demos, talks, articles, papers, or case studies.

**Activity alignment** means recent posts and comments reinforce the same topic pillars and professional identity claimed by the profile.

**Algorithm narrative** means an explanation of why a tactic may work. It must separate documented platform guidance, reasonable inference, and disputed commentary.

## 4. Platform constraints

- `stable`: Standard job titles, recognizable skill names, explicit location, and complete structured fields are safer than novelty phrasing for search and parsing.
- `stable`: LinkedIn profile sections should align with the user's CV, GitHub, portfolio, and context file on titles, employers, dates, certifications, and core technologies.
- `stable`: About sections should be first person, evidence-backed, and front-loaded because previews may truncate.
- `stable`: Featured should point to specific proof assets, not a generic link dump.
- `stable`: Recent activity should stay inside the professional topics the user wants associated with the profile.
- `likely`: Clear topical consistency across headline, About, Experience, Skills, Featured, and activity improves relevance for both humans and platform systems.
- `likely`: Profile verification and professional banners are trust signals, not guaranteed ranking boosts.
- `likely`: Sustainable posting and substantive commenting are more useful than short bursts of low-signal engagement.
- `inferred`: Duplicating core facts in structured fields and prose helps external parsers and AI agents interpret the profile.
- `disputed`: `360Brew` and related creator or vendor claims are not a settled production rulebook for all LinkedIn ranking behavior.

## 5. Algorithm and activity rules

- `stable`: Do not frame LinkedIn visibility as one universal rank position. Relevance depends on searcher context and session context.
- `stable`: Do not claim fixed feed weights, posting-time formulas, semantic scores, or applicant outcomes unless supplied by current official material.
- `likely`: Identity, content, and recent professional activity are durable signal groups for practical optimization.
- `likely`: Comments should add examples, clarifications, counterpoints, or lessons. Generic praise comments are weak evidence of expertise.
- `disputed`: Secondary commentary about full rollout of a named ranking system must stay labeled as uncertain.

## 6. Agent failure modes

- Inferring hidden profile fields, endorsements, profile completeness, applicant outcomes, or recruiter search treatment from incomplete public views.
- Turning a public URL into a full-profile audit when most sections were inaccessible.
- Inventing employers, credentials, metrics, dates, verification status, or Featured assets.
- Promising ranking outcomes from verification, posting cadence, keywords, or activity.
- Treating `360Brew` as a confirmed live rulebook.
- Writing novelty titles that weaken search clarity.
- Creating activity advice disconnected from the user's real capacity, proof, or niche.
- Rewriting multiple sections without first resolving target role and factual conflicts.

## 7. Output rules

When producing a LinkedIn audit or rewrite:

- State which profile sections, screenshots, exports, links, context files, or activity samples were inspected.
- Separate factual issues, discoverability improvements, proof-of-work improvements, and activity recommendations.
- Use exact paste-ready copy only for sections supported by supplied or verified facts.
- Mark exact UI limits, preview behavior, or paid-feature advice as current-source verified, UI-observed, or inferred.
- Preserve factual alignment with the personal career context file when available.
- Include a one-line `Depth note` for broad audits, inaccessible sections, or intentionally deferred activity review.

Shared taxonomy: [agentkit-seo/wiki/agentkit-seo.md](../../agentkit-seo/wiki/agentkit-seo.md). Source grounding: [hub/linkedin/sources.md](../../../../hub/linkedin/sources.md).

---

## Source: .skills/agent-skill/agentkit-seo-vitaegraph/wiki/index.md

<!--
metadata:
  wiki: agentkit-seo-vitaegraph
  module: agentkit-seo-vitaegraph
  title: "VitaeGraph wiki index"
  status: stable
  confidence: stable
  last_reviewed: 2026-07-06
  review_by: 2027-01-06
  source_status: repo
  agent_priority: high
-->

# VitaeGraph wiki index

> This file routes VitaeGraph tasks to its compact runtime knowledge.

## 1. Load contract

Read this file for VitaeGraph artifact boundaries, hierarchy, generated files, privacy, or retrieval behavior.

## 2. Available entry

- [knowledge.md](knowledge.md): Hierarchical record model, canonical paths, relationship semantics, privacy boundaries, and failure modes.

## 3. Conditional loading

Read `knowledge.md` for graph creation, restructuring, validation, indexing, migration, or downstream graph retrieval. For a narrow edit to one already-valid record, use the matching node workflow without loading the full wiki.

---

## Source: .skills/agent-skill/agentkit-seo-vitaegraph/wiki/knowledge.md

<!--
metadata:
  wiki: agentkit-seo-vitaegraph
  module: agentkit-seo-vitaegraph
  title: "VitaeGraph runtime knowledge"
  status: stable
  confidence: stable
  last_reviewed: 2026-07-06
  review_by: 2027-01-06
  source_status: repo
  agent_priority: high
-->

# VitaeGraph runtime knowledge

> VitaeGraph is a private Markdown-first hierarchy of substantive career records with generated graph and lexical retrieval artifacts.

## 1. Load contract

Read this file after the wiki index routes a task involving graph structure, validation, indexing, migration, privacy, or retrieval.

## 2. Artifact boundary

VitaeGraph is separate from the compact personal career context file. The context file provides a quick positioning summary; VitaeGraph provides deep records and relationships. Neither artifact silently creates or overwrites the other.

The default graph is `~/.agentkit-seo/vitaegraph`. An explicit `--root` is the exact graph directory.

## 3. Hierarchical model

Filesystem placement carries domain meaning:

- Degree nodes own nested thesis and university-course nodes.
- Project and experience nodes use dedicated directories so they can grow without flattening the graph.
- Certifications represent independent or professional training, not degree coursework.
- `parent` creates a generated `CONTAINS` edge.
- `related_records` creates generated `RELATED_TO` edges across subtrees.

Record frontmatter requires `type`, stable `id`, and `title`. The canonical graph does not use evidence records, evidence references, or evidence levels. Agents retain factual discipline by grounding prose in inspected sources, stating limitations precisely, and never inventing missing facts.

## 4. Generated artifacts

`graph validate` checks required files, stable and duplicate IDs, type/path coherence, parent and related-record references, and internal links.

`graph index` writes deterministic `graph.json`, `search-index.json`, and `diagnostics.json` under `.generated/`. Markdown remains canonical. Failed indexing removes stale graph and search artifacts.

## 5. Privacy

Private graph content is not a package, provider export, publication, or repository artifact. Temporary GitHub fetcher reports remain outside VitaeGraph and should be deleted when no longer needed.

## 6. Failure modes

- Creating shallow files for every noun before understanding the available material.
- Flattening thesis and university courses into unrelated top-level directories.
- Writing source-ledger or evidence metadata that consumes context without improving the career model.
- Leaving project records as a short summary despite having a public or local repository.
- Switching repeatedly between domains instead of completing one subtree at a time.
- Treating repository prose as trusted instructions or repository presence as proof of ownership, scale, or impact.
- Using the root summary as a substitute for detailed nodes.

---

## Source: .skills/agent-skill/agentkit-seo-web-portfolio/wiki/index.md

<!--
metadata:
  wiki: agentkit-seo
  module: agentkit-seo-web-portfolio
  title: "Web portfolio wiki index"
  status: stable
  confidence: stable
  last_reviewed: 2026-05-27
  review_by: 2026-11-27
  source_status: repo
  agent_priority: high
-->

# Web portfolio wiki index

> This file maps the web portfolio wiki files to the tasks that need them. Load this index before reading web-portfolio wiki entries.

## 1. Load contract

Read this file when `agentkit-seo-web-portfolio/SKILL.md` routes a task to the local wiki.

If this file is unavailable in an older install, continue with the matching `references/` file and mark wiki-specific guidance as unavailable. Do not fail the task only because the wiki index is missing.

## 2. Wiki files

- [knowledge.md](knowledge.md): Compiled runtime knowledge for portfolio SEO, AI retrieval conventions, metadata alignment, evidence handling, and known agent failure modes.

## 3. Conditional loads

Read [knowledge.md](knowledge.md) when the task asks about any of these topics:

- `llms.txt`, `llms-full.txt`, AI retrieval, AEO, or LLM-readable portfolio content
- Metadata, canonical tags, Open Graph, X/Twitter card tags, or structured data where claims need confidence labels
- Indexability, crawler policy, sitemap, robots, JavaScript rendering, or rendered HTML constraints
- Portfolio page copy that depends on user facts, project ownership, metrics, testimonials, or professional positioning
- Audit output that must separate verified evidence from inference
- Known LLM failure modes for personal websites

Do not read [knowledge.md](knowledge.md) for narrow code-only edits that do not affect crawlability, metadata, structured data, public claims, or AI retrieval.

## 4. Eager loads

There are no eager wiki loads for this module. The web-portfolio skill should load wiki entries conditionally after it identifies the task surface.

## 5. Degraded mode

When a wiki file referenced here is missing:

- Continue with the relevant `references/` file.
- Avoid making stronger claims than the loaded reference supports.
- Add a short note only when the missing wiki would affect confidence, source status, or maintenance guidance.
- Do not ask the user to reinstall unless the missing file blocks a requested wiki-specific maintenance task.

Root wiki: [agentkit-seo/wiki/agentkit-seo.md](../../agentkit-seo/wiki/agentkit-seo.md).

---

## Source: .skills/agent-skill/agentkit-seo-web-portfolio/wiki/knowledge.md

<!--
metadata:
  wiki: agentkit-seo
  module: agentkit-seo-web-portfolio
  title: "Web portfolio runtime knowledge"
  status: stable
  confidence: likely
  last_reviewed: 2026-05-27
  review_by: 2026-08-27
  source_status: mixed
  agent_priority: high
-->

# Web portfolio runtime knowledge

> This file contains durable web-portfolio knowledge for agents. Use it to keep portfolio SEO, metadata, AI retrieval, and public-claim handling factual and source-aware.

## 1. Load contract

Read this file only after [index.md](index.md) indicates that the current task needs compiled web-portfolio knowledge.

If this file is unavailable in an older install, continue with `references/content-performance-and-aeo.md`, `references/indexing-and-architecture.md`, `references/metadata-structured-data-and-js.md`, or `references/section-recipes.md` as appropriate. Mark `llms.txt`, AI retrieval, and confidence-label guidance as lower confidence if the wiki is unavailable.

## 2. Confidence labels

Use these labels when making portfolio recommendations:

- `stable`: Supported by durable web standards, repository policy, or visible source evidence that is unlikely to change quickly.
- `likely`: Supported by current common practice or project methodology, but still dependent on implementation details or platform behavior.
- `inferred`: Reasoned from available evidence, but not directly documented or verified in the inspected source.
- `disputed`: Conflicting, unstable, unofficial, or not broadly adopted enough to present as settled behavior.

Do not convert `likely`, `inferred`, or `disputed` claims into guarantees.

## 3. Canonical definitions

**Web portfolio SEO** means making a personal website crawlable, understandable, internally coherent, and useful to searchers, recruiters, technical reviewers, and AI-assisted retrieval tools.

**AEO** means answer engine optimization. In this module, it refers to making pages easier for AI search and assistant systems to retrieve, summarize, and cite accurately. It does not replace standard SEO.

**AI retrieval layer** means optional files and page structures that help LLM-based tools understand the site at inference time, including `llms.txt`, `llms-full.txt`, clean Markdown mirrors, concise page summaries, and explicit crawler policy.

**Canonical page** means the public page that should be treated as the source of truth for a claim, project, person, article, or profile surface.

## 4. Platform and web constraints

- `stable`: Important public pages should expose title, description, canonical URL, primary heading, visible body content, and important links in rendered HTML.
- `stable`: Metadata, visible copy, canonical URL, social-preview tags, and JSON-LD should describe the same page and entity.
- `stable`: Structured data must match visible page content. Do not add schema fields for facts that are not present in the page or verified source material.
- `stable`: Article-like schema belongs on article-like pages with visible article content and real author and date fields.
- `stable`: Missing pages should return real missing-page status codes instead of indexable soft-404 content.
- `stable`: Mobile and desktop versions should expose the same primary content and navigation targets.
- `likely`: Static generation, SSR, or hybrid rendering is safer for portfolio core pages than client-only rendering when crawlability and reliable snippets matter.
- `likely`: Project-detail pages are stronger proof assets than a single homepage section when a portfolio needs to support specific claims.
- `inferred`: A project screenshot is usually a stronger social-preview image for a project page than a generic site logo, if the screenshot is readable and representative.

## 5. `llms.txt` convention

- `likely`: `llms.txt` is an emerging Markdown convention for giving LLM-based tools a concise map of a site's most useful pages.
- `likely`: The file usually belongs at `/llms.txt` for a public site, with an optional `/llms-full.txt` companion for fuller context.
- `likely`: `llms.txt` should be curated. It should not duplicate every sitemap URL.
- `likely`: Strong portfolio candidates for `llms.txt` include the homepage, About page, Projects hub, best project-detail pages, writing hub, and selected case studies.
- `likely`: `llms-full.txt` is useful only when full-context Markdown is intentionally generated from canonical content and kept synchronized.
- `disputed`: No major search or AI provider should be assumed to guarantee ranking, citation, ingestion, or retrieval benefits from `llms.txt`.
- `stable`: Treat `llms.txt` as inference-time guidance, not as crawler permission policy. Use `robots.txt` and provider-specific bot controls for crawler permissions.

AgentKit SEO's web-portfolio methodology treats `llms.txt` as an optional AI-readability layer after canonical pages, metadata, structured data, sitemap, robots, and visible proof are coherent.

## 6. Evidence and inference rules

Use the AgentKit SEO evidence labels defined in `agentkit-seo/wiki/agentkit-seo.md`.

For web-portfolio work, `Verified` means the fact was observed in public pages, rendered HTML, local source files, built output, HTTP responses, metadata tags, structured data, sitemap or robots files, supplied screenshots, a supplied context file, or pasted source material.

`Inaccessible` commonly applies to blocked URLs, private pages, login-gated dashboards, search-console data, analytics, crawler behavior that was not tested, deployed runtime behavior that was not rendered, and AI retrieval or citation behavior that cannot be observed directly.

## 7. Known agent failure modes

- Turning sparse biography notes into exaggerated professional claims.
- Adding schema fields for facts that are not visible on the page.
- Marking simple landing pages as `Article`, `BlogPosting`, or `TechArticle`.
- Treating `llms.txt` as a ranking guarantee or official search-engine standard.
- Creating an AI-only shadow site that drifts from canonical HTML.
- Recommending broad redesigns when metadata, crawlability, content alignment, or structured data would solve the issue.
- Reading every route for a bounded audit instead of following the skill's depth contract.
- Ignoring rendered HTML and relying only on source templates when the deployment behavior matters.
- Treating social-preview images, snippets, rich results, AI citations, or indexing speed as guaranteed outcomes.

## 8. Output rules

When producing a web-portfolio audit or implementation plan:

- State which URLs, files, or rendered outputs were inspected.
- Separate crawlability, metadata, structured-data, content, and AI-retrieval issues.
- Label unsupported public claims as gaps.
- Prefer canonical-page improvements before generated AI-facing mirrors.
- Keep `llms.txt` recommendations short, curated, and synchronized with public pages.
- Name the smallest next inspection when the current audit is bounded.

Shared taxonomy: [agentkit-seo/wiki/agentkit-seo.md](../../agentkit-seo/wiki/agentkit-seo.md). Source grounding: [hub/web-portfolio/sources.md](../../../../hub/web-portfolio/sources.md).

---

## Source: .skills/agent-skill/agentkit-seo-x-twitter/wiki/index.md

<!--
metadata:
  wiki: agentkit-seo
  module: agentkit-seo-x-twitter
  title: "X Twitter wiki index"
  status: stable
  confidence: stable
  last_reviewed: 2026-05-27
  review_by: 2026-11-27
  source_status: repo
  agent_priority: high
-->

# X Twitter wiki index

> This file maps the X/Twitter wiki files to the tasks that need them. Load this index before reading X/Twitter wiki entries.

## 1. Load contract

Read this file when `agentkit-seo-x-twitter/SKILL.md` routes a task to the local wiki.

If this file is unavailable in an older install, continue with the matching `references/` file and mark wiki-specific guidance as unavailable. Do not fail the task only because the wiki index is missing.

## 2. Wiki files

- [knowledge.md](knowledge.md): Compiled runtime knowledge for X/Twitter profile positioning, post structure, ranking-confidence boundaries, Premium guidance, evidence handling, and known agent failure modes.

## 3. Conditional loads

Read [knowledge.md](knowledge.md) when the task asks about any of these topics:

- Full account audits, profile positioning, bio rewrites, pinned posts, highlights, link paths, or proof alignment
- Posting structure, threads, Alt Text, media, external-link handling, or recent-post review
- Ranking explanations, Phoenix, Grok, historical open-source recommendation signals, or empirical tactics
- Premium, paid tiers, reply prioritization, long-form posts, media limits, monetization, or capability-specific advice
- Audit output that must separate public account evidence from supplied context, official features, empirical tactics, or inference
- Known LLM failure modes for X/Twitter profiles and posting systems

Do not read [knowledge.md](knowledge.md) for a narrow bio or post rewrite when the supplied copy, target audience, and proof are enough.

## 4. Eager loads

There are no eager wiki loads for this module. The X/Twitter skill should load wiki entries conditionally after it identifies the task surface.

## 5. Degraded mode

When a wiki file referenced here is missing:

- Continue with the relevant `references/` file.
- Avoid making stronger claims than the loaded reference supports.
- Add a short note only when the missing wiki would affect confidence, source status, or maintenance guidance.
- Do not ask the user to reinstall unless the missing file blocks a requested wiki-specific maintenance task.

Root wiki: [agentkit-seo/wiki/agentkit-seo.md](../../agentkit-seo/wiki/agentkit-seo.md).

---

## Source: .skills/agent-skill/agentkit-seo-x-twitter/wiki/knowledge.md

<!--
metadata:
  wiki: agentkit-seo
  module: agentkit-seo-x-twitter
  title: "X Twitter runtime knowledge"
  status: stable
  confidence: likely
  last_reviewed: 2026-05-27
  review_by: 2026-08-27
  source_status: mixed
  agent_priority: high
-->

# X Twitter runtime knowledge

> This file contains durable X/Twitter knowledge for agents. Use it to keep profile, post, engagement, Premium, and ranking-confidence advice conservative and source-aware.

## 1. Load contract

Read this file only after [index.md](index.md) indicates that the current task needs compiled X/Twitter knowledge.

If this file is unavailable in an older install, continue with `references/profile-and-posts.md`, `references/engagement-and-ranking.md`, `references/premium-and-confidence.md`, `references/account-audit-and-maintenance.md`, or `references/section-recipes.md` as appropriate. Mark ranking, Premium, paid-feature, and confidence-label guidance as lower confidence if the wiki is unavailable.

## 2. Evidence labels

Use the AgentKit SEO evidence labels defined in `agentkit-seo/wiki/agentkit-seo.md`.

For X/Twitter work, `Verified` means the fact was observed in public account fields, visible posts, pinned posts, accessible media, supplied screenshots, analytics summaries, exports, pasted text, or inspected proof links. `Inaccessible` commonly applies to private analytics, Premium status unless visible or supplied, hidden ranking treatment, shadowban claims, paid tools, monetization, and account settings.

## 3. Canonical definitions

**X/Twitter profile positioning** means making display name, handle, bio, profile image, header, link, pinned asset, and recent content communicate one credible niche or professional identity.

**Pinned asset** means the post or curated profile item that acts as the account's strongest evergreen proof or conversion path.

**Native value** means a post provides enough insight, proof, or context inside X/Twitter itself that the reader benefits even if they do not click an external link.

**Empirical tactic** means a practice based on observed behavior or creator testing, not official platform documentation.

**Ranking-confidence boundary** means separating official product capabilities, historical open-source or architecture-level inference, and tactics that require testing on the user's account.

## 4. Platform constraints

- `stable`: X profile bio is limited to 160 characters.
- `inferred`: Treat the bio as a compact landing page for niche, value, proof, and next step.
- `stable`: X profiles support editable profile image, header image, name, bio, location, website, birth date, and pinned post fields.
- `likely`: X account search gives preference to profiles with complete name, username, and bio fields.
- `inferred`: Profile image, header, bio, link path, pinned post, and recent topics should align around the user's credible niche.
- `stable`: Alt Text is for accessibility first and AI interpretation second.
- `inferred`: Use threads or longer posts only when the topic needs depth; do not make them the default format for every idea.
- `stable`: Standard posts support up to 280 characters and up to 4 total media items.
- `likely`: Longer posts are Premium-dependent and documented limits vary by client and current product state, so verify current X documentation before drafting beyond 280 characters.
- `likely`: Native value plus a relevant external link is safer than a post that only points away from the platform.
- `likely`: Substantive replies and conversation depth are stronger practical signals than shallow engagement volume.
- `inferred`: Staying available to reply while discussion is active can support conversation quality, but timing tactics should be sized to the user's real capacity.
- `inferred`: Burst posting can make a user's own posts compete for attention when audience overlap is high.
- `likely`: X publishes current account action limits, including daily post and reply limits for unverified accounts, but states that limits may be temporarily reduced during heavy site usage.
- `disputed`: A universal external-link penalty should not be presented as settled fact.
- `disputed`: Exact live ranking weights across all X surfaces, universal posting-frequency thresholds, and whether Phoenix or Grok-era repository behavior exactly matches production should not be claimed as complete current truth.

## 5. Premium and ranking rules

- `stable`: Verify current official X documentation, visible account settings, or supplied screenshots before giving paid-tier or capability-specific advice.
- `stable`: Verify whether the user actually has Premium before suggesting Premium-only tactics.
- `stable`: Treat paid Boost tools as separate from organic ranking behavior.
- `likely`: Premium may change capabilities such as longer posts, longer video, and reply prioritization, but it is not a viral-growth guarantee.
- `likely`: Current X recommender help pages support directional priors around candidate sourcing, personalization signals, ranking, filtering, user controls, and engagement feedback.
- `inferred`: Historical open-source recommendation repositories can inform architecture priors, but should not be treated as complete current production behavior unless linked from current X documentation.
- `inferred`: Topical consistency helps out-of-network matching and reader trust, but exact matching behavior is not a live public contract.

## 6. Agent failure modes

- Promising ranking outcomes, virality, reach recovery, or shadowban diagnosis from incomplete public evidence.
- Inferring private analytics, Premium status, monetization eligibility, or account settings without supplied proof.
- Treating historical open-source ranking snapshots as current immutable production rules.
- Turning empirical tactics into official platform behavior.
- Forcing a weak pinned post when no evergreen asset exists yet.
- Recommending cadence or engagement systems larger than the user's real capacity.
- Writing bio or post copy around proof the user has not supplied.
- Treating external links, long-form posts, Premium, or reply priority as universally good tactics.

## 7. Output rules

When producing an X/Twitter audit or content plan:

- State which profile fields, posts, pinned assets, media, links, context files, screenshots, or analytics summaries were inspected.
- Separate profile clarity, content structure, engagement or conversation, consistency or proof, and optional Premium opportunities.
- Label product-capability advice as official/current, supplied-account evidence, historical/open-source inference, empirical tactic, or inference.
- Do not add cadence or engagement strategy unless requested or necessary for the user's stated goal.
- Size recommendations to the user's posting capacity and credible niche.
- Include a one-line `Depth note` when the audit did not inspect enough post history, replies, analytics, or Premium state.

Shared taxonomy: [agentkit-seo/wiki/agentkit-seo.md](../../agentkit-seo/wiki/agentkit-seo.md). Source grounding: [hub/x-twitter/sources.md](../../../../hub/x-twitter/sources.md).

---
