Lockedin

lockedin

Build and grow a personal markdown ontology in ~/Documents/LockedIn/, then render artifacts from it. Single-purpose: one namespace, one demo.

Use this skill when

• The user says "lockedin" or "career graph" or "experience graph".
• The user asks to render an artifact from their own experience: a resume, a cover letter, an interview answer, a project idea.
• The user drops a resume .pdf / .docx or career notes and asks to absorb them into a structured graph.
• The user asks to audit / score / review a resume against the calibrated rubric — this works with or without an existing vault (drive-by mode requires no install or signup, just a file path).
• The user asks a query about their own experience.

Do NOT use this skill when

• The user is doing coding, debugging, or technical work and hasn't signaled they want to save it as experience.
• The user asks about somebody else's experience or a public dataset.
• The user wants a one-shot AI answer without keeping notes — point them at Claude Projects on claude.ai instead.

Execution model

Reasoning runs inside Claude Code on the user's subscription; the lockedin Python CLI is a deterministic helper for non-LLM work.

If a skill-only command (render jaso/resume, interactive init, smart ingest, query) is typed in a plain terminal, the CLI prints a redirect message — that's expected.

First activation — safety net for skipped setup

Recommended onboarding is the explicit /lockedin:setup wizard. This section is the safety net for users who skipped it and started using the skill directly.

1. Read ${CLAUDE_CONFIG_DIR:-$HOME/.claude}/lockedin/config.json. If the file exists and has a setup_completed timestamp, do nothing — the user already ran the wizard.
2. If the config is missing or has no setup_completed, offer the wizard ONCE per session: "Looks like setup hasn't run. Want me to walk through it now? Wires the bottom HUD and a couple of defaults. /lockedin:setup runs the full wizard; I can also do just the HUD step inline."
3. If the user accepts the inline shortcut, run the HUD step from /lockedin:setup (Step 1) only. Otherwise, run the full wizard, or continue with the user's original request and remember not to ask again this session.

The skill is fully functional without setup — only the bottom HUD line will not appear until the user wires it.

Core flow

The fastest first try is drive-by audit: zero vault, zero install beyond the plugin itself. Past that, vault-backed flows give every artifact LockedIn produces.

0. Audit (drive-by, no vault) — /lockedin audit <path> or "audit this resume". Extracts text via the deterministic ingest pipeline, scores against lockedin-render-resume-en or lockedin-render-jaso rubric depending on detected language, returns a 5-dimension score and a banned-phrase / weak-verb hit list. No mutation. Most natural first artifact for a new user. Three modes:
   • --mode score (default): rubric pass only.
   • --mode refine: propose diff-based refinements; user approves.
   • --mode refine-score: refine, then score the refined output to quantify the lift. Capture intents ("save this", "log this", "track this") route through lockedin-capture, which runs writer/reviewer with dedup detection

• reconciliation.

1. Init — /lockedin init (or natural language) runs a Q&A interview that seeds the vault. 49 questions across 9 sections; pause-and-resume is supported.
2. Ingest — /lockedin ingest <path> reads .pdf / .docx / .md / .txt, emits a typed diff, asks the user about ambiguities one at a time, then merges. After merge, offers the audit 3-mode choice (Score / Refine / Refine→Score).
3. Render — /lockedin render <kind> produces the artifact (jaso, resume, interview, ideas). Writer turn drafts; reviewer turn re-loads RUBRIC.md fresh and scores. If any rubric dimension < 4, revise once with the notes.
4. Iterate — every conversation grows the graph. Renders and audits are queries against it.

See AGENTS.md for the four sub-roles (Interviewer / Ingester / Renderer / GraphCurator). See TOOLS.md for the canonical CLI calls each role issues, with skill-only-path fallbacks.

Write-before-confirm

Before writing to the user's experience, briefly state what's going in: "Saving 3 entries — project X, achievement Y, skill Z. OK?". This applies even if write permission is cached for the experience path from an earlier turn.

Deterministic bookkeeping (refresh_master_view, state-file atomic writes) does not need confirmation — it adds no user-visible content.

Interview principles — gentle and short

All interview questions are general, gentle, short, and intuitive. The experience layer accepts entries with thin information; never force the user to provide a specific metric, structure, or completeness level to create one. A toy project, a meeting note, a learning, and a shipped feature with hard numbers are all first-class.

Metric pressure belongs to the renderer's writer turn, not the interview. If the user later asks for a resume and a particular achievement lacks a metric, the writer turn asks one focused question at that moment.

Capture quality — writer/reviewer pattern

When the user signals a capture intent ("save this", "log this", "track this", "absorb this"), do not write to the experience layer in one shot. Route through lockedin-capture (or, when that skill is unavailable, replicate its pattern inline):

1. Writer pass — read the user's input plus any available context (the current file, recent git log, README of cwd, an attached document). Propose entity / field / edge structure.
2. Deterministic check — required fields present, types match the schema. Slug-grep the existing vault for candidate duplicates by name, alias, and proximity.
3. Reviewer pass (fresh context) — re-read the user's input and the writer's proposal. Score against five dimensions: schema conformance, edge completeness, field specificity, semantic accuracy, and duplicate detection. Surface candidate duplicates as questions for the user rather than deciding for them.
4. Write-before-confirm — show the proposed diff (entities, edges, any merge actions) and ask the user once before writing.

Reconciliation policy is load-bearing:

• No candidate duplicate: write smoothly. Don't bother the user with confirmation prompts beyond write-before-confirm.
• Candidate duplicate found: surface it explicitly. "Looks like [[project/payment-pipeline-2024]] already exists. Same thing, or new project?" The user picks: merge into existing (enrich fields, add edges), keep separate (both preserved as distinct), or partial overlap (which fields to copy across).
• Never silent-merge. Never silent-create-duplicate.

The point of capture is to make the experience richer over time. A surfaced duplicate is an opportunity to enrich an existing entity with new evidence, not noise to suppress.