Imported from anurieli/resume-kit (skills/career-target/SKILL.md). Install upstream with npx skills add anurieli/resume-kit --skill career-target. Copyright stays with the author.

career-target

The coaching half of resume-kit. resume-build answers "what document do I send". This answers the questions that come first: is this role worth the application, what is the honest angle on this person for this job, what is genuinely missing, and what would close it.

A person can run this and stop. Deciding not to apply, with a clear reason and a list of what to do about it, is a legitimate output.

This skill runs stage 03_target and the positioning half of 04_deliverable in the resume-kit ICM workspace. The stage contracts at <data_dir>/03_target/CONTEXT.md and <data_dir>/04_deliverable/CONTEXT.md say the same thing in short form, so the user can also drop a posting into 03_target/ and ask an agent to continue without naming this skill. Keep the two in sync: if you change a rule here, change it in the contract too. resume-build shares stage 03_target and reads the same posting.md and brief.md, so when both run for one job they use one slug and one brief.

Before starting

Read ~/.config/resume-kit/config.yaml for data_dir. If it is missing, tell the user to run resume-kit-init first and stop.

Read <data_dir>/02_career-db/career.yaml in full, plus <data_dir>/_config/career-schema-full.md (repo copy: ../../schema/career-schema.md, in the resume-kit repo) for the evidence_type rules that govern what you may state as fact. Read any reflections under <data_dir>/02_career-db/self/reflections/ that belong to experiences relevant to this posting. The reflections are where the honest angle usually comes from, since they hold the parts of a job that never made it onto a resume.

If career.yaml has no experiences:, tell the user to run career-ingest first and stop.

Life-update check (runs first, every time)

Before anything else, read <data_dir>/02_career-db/self/life-log.md and look at the date on the top entry.

• Under 2 months old: say nothing, carry on.

• 2 months old or more, or the log is empty: ask, before doing the work you were called for:

  What are you up to right now, or what have you been up to?

  Take the answer as it comes. Write it to life-log.md as a new dated entry at the top, in their words. Then file what it contains: concrete events as self-reported material in career.yaml, opinions about themselves as self-assessment, anything worth a longer telling as a file in 02_career-db/self/reflections/. If it opens up more than one question, say so and suggest career-enrich rather than turning this into a full interview.

One question. Then get on with the task.

Workflow

1. Capture the posting (stage 03_target). Accept pasted text, a URL (fetch it), or a file path. Build the slug <company>-<role>, lowercase and hyphenated, and use that same slug through stage 04.

   • Write the posting verbatim to <data_dir>/03_target/output/<slug>/posting.md. Do not summarize at this step. Postings get taken down within weeks and the raw text is the record, both for this session and for the pattern detection in step 5.
   • If a fetched page came back partial or paywalled, say so and ask the user to paste the text rather than working from a fragment.

2. Research the company, in a subagent. As soon as the posting is captured, dispatch a separate agent to research the company and write <data_dir>/03_target/output/<slug>/company.md. Do it in a subagent because it is a wide, link-following job whose intermediate reading has no business in this context: what comes back is the file.

   Brief the subagent to answer these, and nothing else:

   • What the company actually does, in one paragraph, in plain terms. What they sell, to whom, and how they make money.
   • Stage and size: funding, headcount, ownership, public or private, how old.
   • Stated values and vision, quoted from their own material, with the page each quote came from. Their careers page, about page, engineering blog, founder letters, and the posting itself.
   • How they talk. Three to five short verbatim phrases that show their register. This is what makes a cover letter sound like it was written for them rather than at them.
   • What is going on right now. Recent launches, funding, layoffs, pivots, regulatory news, anything in the last twelve months that a candidate would be expected to know about.
   • What this role exists to do, read against the company's situation rather than the posting's wording. A hire made after a funding round is a different job than the same title backfilled after attrition.
   • Open questions for the human, which is the most useful section. Things the research cannot settle that the person can: whether they know anybody there, whether the company's stated way of working matches how they want to work, whether a named value is one they can speak to honestly.

   Three rules the subagent must follow:

   • Every claim carries a source URL and the date it was read. Mark each one stated (the company's own words), reported (a third party), or inferred (your reading, from named evidence). An unsourced claim does not go in the file. This mirrors the evidence_type discipline on the career side, and for the same reason: the person will repeat these things out loud in a room.
   • Research the company, not the people. Public company material, product, press, and engineering writing. Do not compile profiles of employees, hiring managers, or interviewers, and do not go looking through anyone's personal accounts.
   • Say what could not be found. A short "not established" list at the end beats a confident file with quiet holes in it.

   If the company cannot be identified from the posting, say so and skip this step rather than researching the wrong company.

3. Write the brief to <data_dir>/03_target/output/<slug>/brief.md: target title, company, emphasized skills and technologies, key responsibilities, seniority signals (years asked for, scope of ownership, who the role reports to, whether it names leading or mentoring). Stick to the posting's own claims. Do not infer what the company "really wants", and do not import outside knowledge of the company here: that belongs in company.md, sourced. The two files stay separate so a reader can always tell what the posting said from what the internet said. Note which requirements the posting repeats or lists first, since repetition is the clearest signal a posting gives about what it actually screens for. If brief.md already exists for this slug from a resume-build run, update it rather than replacing it, and keep the same structure.

4. Check the record is strong enough to position from. Before writing anything in stage 04, judge whether career.yaml can support real advice for this posting. It cannot when the relevant experiences carry no metrics and no context, when self_assessment is empty, or when the only material is achievement bullets lifted from an old resume. If that is the case, say so plainly, name what is missing, and recommend running career-enrich on the specific roles that matter for this posting before continuing. Offer to write the brief and stop there. Do not produce a thin positioning document and hope it reads as insight. A confident analysis of an empty record is worse than no analysis, because the person will act on it.

5. Detect cross-application patterns. Read every past brief at <data_dir>/03_target/output/*/brief.md, excluding this one.

   • With three or more past targets, look for requirements that appear across multiple briefs and are absent from career.yaml. When one recurs, name it as a pattern with the count and the target names, for example "four of your last five targets named Kubernetes; that is not a one-off gap for this job, it is the ceiling on the roles you are drawn to." Also surface the inverse when it is true: a strength the person keeps having that these postings keep asking for, which is worth leading with every time.
   • With fewer than three past targets, say the sample is too small to call a pattern and move on. Do not manufacture a trend from two postings, and do not present a single repeat as a pattern.
   • Only count a requirement as a gap here if career.yaml genuinely does not cover it. Check tags, achievements, and reflections before concluding something is missing.

6. Write positioning to <data_dir>/04_deliverable/output/<YYYY-MM-DD>-<slug>/positioning.md, with these five sections in this order. Read company.md before you start: it changes the angle, the environment read, and sometimes the recommendation. A company that just raised and is building a new team wants a different story than one consolidating after layoffs, and the posting will not tell you which one you are looking at.

   1. How you read for this role. The honest angle. What story does this record tell a screener looking at it through this posting? Lead with the strongest genuine asset for this specific job, which is often not the most prominent line on the resume. A backend engineer applying to a platform team may have the migration nobody wanted to own as their real asset, not the title. Say what a screener will notice first, and say whether that is the thing you want them to notice.
   2. Strongest evidence. The three to five specific achievements to lead with, each with the reason it lands for this posting. Cite them as they exist in career.yaml, with their real evidence type. A documented metric can be stated as fact. A self-reported account is experience, not a verified number, and should be described that way so the person knows what they can put in writing and what they can only say in conversation.
   3. Gaps. What the posting asks for that the record does not have. State each one plainly and do not rank a real gap below a soft one to make the list feel better. Distinguish a hard gap (named as a requirement, repeated, tied to the core of the role) from a soft one (listed under nice-to-have, or adjacent to something the person has). Never suggest wording that implies experience the record does not support, and never tell someone a gap will not be noticed.
   4. Tips to close the gaps. Concrete, specific, and sized to the gap. Each one names an actual action with a realistic time cost and, where possible, a linkable artifact at the end of it. The right altitude: "the posting names OpenTelemetry twice and you have observability work but nothing citable; one merged PR to an OTel instrumentation library is a weekend and gives you a link." For a research-oriented role it might be reading two named papers and writing a public response, or reproducing a specific result. For a management role it might be a written artifact about a team decision already made. Say which tips are worth doing before this application and which are longer plays for the pattern in step 5. Never write generic advice like "learn Kubernetes" or "build your network"; if you cannot name the specific thing to do, say the gap cannot be closed quickly and treat it as an input to the recommendation.
   5. Should you apply? A real answer, not a hedge. Yes, yes with conditions, or probably not. When it is probably not, say what would change it and roughly how long that takes. When it is yes, say what the application has to do well to survive a screen. Weigh the pattern from step 5 here: a gap that has blocked four applications is a different decision than one that turned up today.

7. Use self_assessment to shape, never to assert. What the person says they are good at should influence which achievements you lead with, how you describe the fit, and which environments you flag as a mismatch. It never appears in the document as a claim about them. Write "your record shows you keep ending up owning the thing nobody else will", grounded in logged experiences, not "you are excellent at ownership" because they said so. self_assessment.working_on and prefers are inputs to the gap list and the recommendation: a role that is a skill fit and an environment mismatch should say that out loud.

8. Report to the user in a few lines: the angle, the top one or two gaps, any cross-target pattern, the recommendation, and the paths to company.md, brief.md, and positioning.md. Then say whether the next step is resume-build, career-enrich, or nothing.

9. Ask the open questions from company.md. They are the reason the research is worth doing. The file can establish what a company says it values; only the person can say whether they believe it, whether they have a story that speaks to it, or whether the way this company works is a way they want to work. Ask them, batched, at the end. File the answers the way any other material gets filed: concrete events as self-reported in career.yaml, opinions about themselves as self-assessment, anything longer as a reflection. A company fact they confirm or contradict goes back into company.md, marked as theirs.

Don't

• Don't soften a gap, bury it under strengths, or imply it can be worded around. The value of this document is that it tells the person what a screener will see.
• Don't suggest phrasing that stretches a self-reported account into a documented result, and don't recommend claiming exposure to something the record does not contain.
• Don't print a self-assessment as a verified fact, in the positioning document or in your summary.
• Don't invent a pattern from fewer than three past targets, and don't inflate a single recurrence into a trend. Say the sample is small.
• Don't give tips that could have been written without reading the posting. "Get certified", "practice system design", "improve your resume" are not tips, they are filler.
• Don't recommend applying to everything. A recommendation that is always yes carries no information, and the person will stop reading it.
• Don't summarize the posting in posting.md. That file is the verbatim record; analysis belongs in brief.md and positioning.md.
• Don't put a company claim in any document without a source and a date. A candidate repeating an unsourced fact about a company in an interview is the same failure as an inflated bullet, and it lands in the same room.
• Don't research people. The company, its product, its press, and its own writing. Not employees, not the hiring manager, not whoever is running the interview loop.
• Don't let the research flatter the application. If what comes back makes the role look like a worse fit, that belongs in the recommendation. Research that only ever strengthens the case is not research.
• Don't build a resume here. If the person wants the document, hand off to resume-build, which reads the same slug and brief.