# VitaeContext full LLM wiki This file concatenates the installed VitaeContext wiki entries for LLM-readable project and module context. --- ## Source: skills/vitaecontext/wiki/vitaecontext.md # VitaeContext > VitaeContext is a portable skill bundle for building and reusing private career context. It gives agents a context-first workflow, an optional deeper career knowledge graph, and provider-aware install layouts. ## 1. Load contract Read this file when the user asks what VitaeContext 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 `vitaecontext-install.json` manifest when present. State that the wiki entry is unavailable before making architecture claims that depend on it. ## 2. Canonical definition VitaeContext is an installable set of Markdown-first agent skills for maintaining private career context: - Career Context files - Private VitaeGraph career knowledge graphs The package is distributed as `vitaecontext` 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. Context Builder Context Builder, or ACO, is the process of building and maintaining a private, structured Markdown source of truth for a person's professional facts. The resulting Career Context file stores verified identity, education, experience, projects, achievements, links, target roles, growth direction, evidence boundaries, constraints, claims to avoid, and positioning notes. Downstream skills and tools 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 `~/.vitaecontext/vitaegraph/`. The Career Context file remains a separately located and separately usable artifact. Neither artifact silently creates or replaces the other. ## 4. Runtime architecture VitaeContext uses four core repository layers: - `hub/`: human-readable playbooks, examples, templates, and source notes. - `skills/`: canonical portable standard Agent Skills. - `providers/`: provider-specific install notes, manifests, command wrappers, and extension metadata. - `src/` and `bin/`: CLI and stateless MCP server engine. - `mcp/`: Model Context Protocol documentation, configs, and schema contracts. ## 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 use an explicit existing Career Context file for compact current facts or retrieve the smallest relevant subtree from an explicit existing VitaeGraph. Start with the context-builder skill when facts are scattered, conflicting, or no usable source of truth exists. Do not silently create or convert either private artifact. 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` or local `references/` 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 the repository's maintainer docs only when working from a package checkout or source clone. Installed provider skill folders must remain usable without those files. ## 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 - Cursor - Windsurf - Roo Code - IBM Bob - Grok 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 VitaeContext does not guarantee rankings, recruiter attention, ATS scores, rich results, snippets, indexing speed, AI citations, or platform distribution. Agents using VitaeContext 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 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//README.md` -> `hub//sources.md`. - Runtime layer: this root wiki -> `vitaecontext-/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 - [Context Builder wiki index](../../vitaecontext-build/wiki/index.md) - [VitaeGraph wiki index](../../vitaecontext-vitaegraph/wiki/index.md) - [Getting started](https://github.com/vitaecontext/vitaecontext/blob/main/.assets/docs/getting-started.md) - [End-to-end demos](https://github.com/vitaecontext/vitaecontext/blob/main/.assets/docs/end-to-end-workflows.md) - [llms.txt](https://vitaecontext.github.io/llms.txt) - [llms-full.txt](https://vitaecontext.github.io/llms-full.txt) --- ## Source: skills/vitaecontext-build/wiki/index.md # Context Builder 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 `vitaecontext-build/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 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 Career Context file is, when to create one, where to store it, or how it relates to platform skills - Context-file structure, `QUICK REFERENCE`, personalized narrative hierarchy, semantic tags, or `VERIFIED FACTS` - Personalization interviews, purpose-led entries, claim states, metric selection, or means-versus-objective distinctions - 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: [vitaecontext/wiki/vitaecontext.md](../../vitaecontext/wiki/vitaecontext.md). --- ## Source: skills/vitaecontext-build/wiki/knowledge.md # Context Builder 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 VitaeContext evidence labels defined in `vitaecontext/wiki/vitaecontext.md`. For context-file work, `From context` means a fact is already present in the existing 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 **Career Context file** means a private Markdown source of truth and positioning guide for a person's professional facts, priorities, direction, and claim boundaries, used to ground repeated career work. **Context Builder** 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 interpretive layer that records ideal role, current focus, paths to keep open, defining evidence, target locations, growth direction, interests, evidence boundaries, positioning constraints, supporting means, 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`: Direction, priorities, evidence boundaries, and claims to avoid appear 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 semantic components include a scope declaration, evidence-backed history, and a skills index. - `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`: Body modules after QUICK REFERENCE may be ordered by personal importance. Stable semantic tags provide retrieval without a universal body order. - `stable`: Defining entries should explain purpose and personal ownership. Technologies and metrics support that explanation rather than replace it. - `stable`: Claim states distinguish employment, research, implementation, proposal, exposure, learning, membership, contribution, affiliation, and target expertise when confusion is likely. - `likely`: `~/.vitaecontext/-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. - `stable`: For major creation, restructuring, or repositioning, confirm a positioning synthesis and narrative hierarchy before the full rewrite. - `stable`: Treat a prominent method or domain as a supporting means when the user's actual objective lies elsewhere. - `stable`: Use only decision-relevant metrics, normally one to three per entry, and explain why each retained number matters. - `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. - Preserving a default section order after the user has identified a different hierarchy of importance. - Treating membership as contribution, affiliation as employment, a proposal as implementation, or a target capability as established expertise. - Producing technology and metric inventories that do not explain purpose, ownership, or significance. - 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. - Suggest a platform handoff only when it serves the user's requested next step. - Include a one-line `Depth note` when sources, sections, or cross-platform checks were intentionally bounded. Shared taxonomy: [vitaecontext/wiki/vitaecontext.md](../../vitaecontext/wiki/vitaecontext.md). Source grounding: [repository source inventory](https://github.com/vitaecontext/vitaecontext/blob/main/hub/context-builder/sources.md). --- ## Source: skills/vitaecontext-vitaegraph/wiki/index.md # 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/vitaecontext-vitaegraph/wiki/knowledge.md # 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 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 `~/.vitaecontext/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. `visibility: public` marks a record as eligible for public consideration. It does not authorize publication. Public-output retrieval must also apply graph-level claims to avoid, record limitations, open questions, and the user's requested scope. ## 6. Lifecycle modes - `Create` and `deepen` add supported detail from explicit sources. - `Maintain` corrects facts and relationships without rewriting unrelated domains. - `Validate` and `index` are structural operations; indexing never changes canonical Markdown. - `Retrieve` is read-only and loads the smallest relevant subtree. - `Migrate` previews path, hierarchy, and relationship changes while preserving stable IDs. Deletion, duplicate merges, and many-record migrations require a preview because they can remove private history or break inbound relationships. ## 7. 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.