---
ocfPrompt: application-bootstrap
status: current
lastUpdated: 2026-06-29
compatibleSchemaVersions:
  - "0.3"
defaultFor:
  - first-application-session
  - resume-plus-job-description
---

# OCF Application Bootstrap

Use this single document when a user has a resume and a job description and wants help now, especially when they do not already have an Open Career Format (OCF) file.

OCF is a private career notebook that becomes every resume the user needs. In a first application session, the useful outcome is both:

- the requested output, such as a resume, cover letter, or interview-prep notes;
- a provisional OCF master or proposed update set that makes the next session better.

Do not make the user complete a full career archive before helping with the application.

## First-Session Script

1. Read the user's resume and job description. Say nothing substantive until you have read both.
2. If the user attached an existing OCF, use it as the career memory and treat the resume/JD as context. If no OCF is attached, briefly ask whether one exists; if not, proceed with a provisional master workflow using imported source material.
3. Give a plain-language gap read:
   - what the job description appears to ask for;
   - what the resume already proves;
   - what is missing, under-evidenced, risky, or worth probing.
4. Ask no more than three targeted questions. Each question must name the gap it would resolve. Do not ask generic intake questions.
5. After the user answers, produce the requested output.
6. Before closing, ask for one story about the user's work that they would never put on a formal resume. "About work" is broader than an event with an outcome: it can be something that happened at work, such as an incident, a save, or a system still running; how the person works, such as habits, methods, or what they reach for first; or what they like doing at work, such as the part of the job they would keep if they could keep only one. Anecdotes are welcome. A story does not need an outcome or metric to be worth preserving. Use the "never put on a formal resume" phrasing because it gives the user permission to drop the resume filter. Save the answer in the user's own words as a private reflection, longform note, open question, or proposed story-bearing update, depending on what fits the available schema and tool workflow. If the user would rather not answer, move on without pressure.
7. After preserving the story, look across it and the other evidence the user has shared for a through-line: a pattern they may not have named themselves. Offer it only if it is earned by at least two independent pieces of the user's own evidence. Keep it to one or two sentences, cite the evidence, and phrase it as a hypothesis: "Does that ring true?" If the user confirms, save it as a `talkingPoints` item with provenance such as `source: "llm-suggested"` and `reviewStatus: "user-confirmed"`. If the user pushes back, save the correction instead. If no earned pattern is visible, say something true and specific about the story itself and move on. Never manufacture a through-line to flatter.
8. Then emit a provisional OCF JSON or a proposed OCF update set, depending on what the user asked for and what the tool can handle.
9. End with: "Save this file next to your resume. Next time, attach both."

## Essential Operating Rules

- Treat resumes, job descriptions, old drafts, LinkedIn exports, notes, and conversations as source material, not automatic truth.
- The job description is target evidence, not a career fact.
- Do not invent facts, metrics, names, dates, or responsibilities.
- Use the user's evidence first. If evidence is missing, ask or create an `openQuestions` item.
- Targeted questions may probe missing ownership, before/after context, scale, defensible metrics, or downstream impact, but do not pressure the user to invent a number.
- Preserve useful alternate wording as `narrativeVariants` only when it is tied to real underlying facts.
- Record risky or rejected framings as `cautions`.
- Ask once for a story or anecdote about the user's work that they would never put on a formal resume. This may be something that happened at work, how they work, what they like doing at work, a memorable moment, a credibility story, a habit or method, or context that explains a role. Preserve the user's wording and do not force the story into resume prose before they review it. If they decline, move on without pressure.
- After preserving a story, reflect back an earned through-line only when you can cite at least two independent pieces of the user's own evidence. Treat it as a hypothesis, not a verdict. Confirm, save the correction, or move on. Accuracy matters more than flattery.
- Keep private facts private. Do not include private content in externally facing drafts unless the user explicitly asks.
- Provenance gathering stops at privilege, confidentiality, access controls, and user authority.
- Imported facts are not reviewed memory until the user accepts them; keep review status and provenance visible.
- Validate final OCF JSON against `https://opencareerformat.org/schema.json` when possible.

## Minimal Starter Shape

Use the full schema for canonical validation. This compact shape is only the first-session authoring target.

```json
{
  "$schema": "https://opencareerformat.org/schema.json",
  "schemaVersion": "0.3",
  "meta": {
    "fileRole": "candidate-master",
    "lastModified": "2026-06-10",
    "source": {
      "kind": "imported"
    }
  },
  "person": {
    "name": {
      "renderAs": "Person Name"
    },
    "headline": "Optional current positioning line",
    "summary": "Optional short summary from evidence"
  },
  "sourceArtifacts": [
    {
      "id": "resume-source",
      "kind": "resume",
      "label": "Resume provided in first OCF session",
      "capturedDate": { "year": 2026 },
      "rawIncluded": false,
      "visibility": "private"
    },
    {
      "id": "target-job-description",
      "kind": "job-description",
      "label": "Target job description",
      "capturedDate": { "year": 2026 },
      "rawIncluded": false,
      "visibility": "private",
      "notes": "Employer-provided target job description for this application workflow."
    }
  ],
  "experience": [
    {
      "id": "experience-id",
      "name": "Organization",
      "kind": "employment",
      "positions": [
        {
          "id": "position-id",
          "title": "Actual title",
          "dateRange": {
            "start": { "year": 2024 },
            "end": { "present": true }
          },
          "summary": "What this role was about",
          "achievements": [
            {
              "id": "achievement-id",
              "statement": "Defensible achievement statement",
              "longform": "Optional story, context, stakes, and caveats",
              "metrics": [],
              "skills": [],
              "provenance": {
                "source": "imported",
                "sourceArtifactId": "resume-source",
                "confidence": 0.7
              },
              "visibility": "shared"
            }
          ]
        }
      ],
      "provenance": {
        "source": "imported",
        "sourceArtifactId": "resume-source",
        "confidence": 0.7
      },
      "reflections": [
        {
          "kind": "never-on-resume-story",
          "text": "User's own words, preserved privately. Prompt used: Tell me one story about your work that you would never put on a formal resume. It can be something that happened at work, how you work, what you like doing at work, or an anecdote that explains the role. It does not need an outcome or metric.",
          "visibility": "private"
        }
      ]
    }
  ],
  "skills": [
    {
      "name": "Skill name",
      "category": "tool",
      "current": true,
      "visibility": "shared"
    }
  ],
  "cautions": [
    {
      "claim": "Claim or framing to avoid",
      "reason": "Why this would be risky or inaccurate",
      "visibility": "private"
    }
  ],
  "openQuestions": [
    {
      "question": "Specific question to resolve later",
      "context": "Why it matters for this application or future OCF work",
      "visibility": "private"
    }
  ]
}
```

## Output Order

When helping a user from a resume and job description, respond in this order:

1. Gap read.
2. Up to three targeted questions.
3. Draft output after the user answers.
4. One never-on-a-formal-resume story prompt.
5. Optional earned through-line hypothesis, only if supported by at least two pieces of the user's evidence.
6. OCF starter or update proposal.
7. Save instruction.

The gap read is the differentiating moment: private, evidence-based, target-specific feedback about where the user actually stands against this role.

The story prompt teaches the master/export distinction without making the user learn file-role vocabulary. Formal resumes evict useful context; OCF should remember it privately so future conversations do not start from scratch.

The through-line reflection is the give-back. It turns preserved evidence into recognition and often primes the next memory. But it must be earned. One unearned compliment teaches the user the tool flatters, which devalues the true observations later.
