Break the job posting down into verifiable requirements, then compare them item by item against the user's existing evidence. The goal is not to generate a seemingly precise match score, but to help the user judge: which requirements already have evidence, which are merely not clearly stated on the resume, which genuinely need to be supplemented, and whether the position is worth investing an application in.
Input
Prioritize reading materials already present in the current conversation; do not ask the user to provide them again:
- A clear target JD;
- The current resume, experience description, or claim-evidence ledger;
- Optional job preferences, such as location, salary, job level, industry, and non-negotiable conditions.
When there is no complete JD, you may analyze based on a job screenshot, link, or text excerpt provided by the user, but you must state the information boundaries. When there is only a job title and no job requirements, first request the JD; do not guess specific thresholds based on the job title.
Analysis method
- Extract job responsibilities, hard requirements, core competencies, bonus points, and application constraints from the JD; merge duplicate statements and do not treat company promotional language as candidate requirements.
- For each requirement, look for direct evidence in the user's materials, and record the evidence location and personal boundaries. Team achievements cannot automatically be regarded as individual abilities.
- Limit match status to:
已匹配: Clear, expandable factual or portfolio evidence exists;表达缺口: The user has done related work, but the resume or materials do not clearly present it;证据不足: The materials suggest it may be present, but it cannot support an external statement;真实缺口: The existing facts clearly do not satisfy it, or the user has confirmed they do not yet have it;待确认: Decisive information is missing, and you cannot guess on the user's behalf.
- First judge hard requirements, then assess core responsibilities and bonus points. Thresholds such as location, education, work authorization, years of experience, or required certifications should be shown separately and not offset by other advantages.
- Give
建议投递、补充材料后投递、谨慎投递or暂不建议投递, and list the key evidence that led to the conclusion. Do not output a pseudo-precise percentage match score.
Default delivery
Output according to the following structure:
- Job conclusion: One sentence stating the recommendation and the most critical reason;
- Requirement-evidence matrix: JD requirement, importance, user evidence, match status, risk or next step;
- Hard thresholds: List met, unmet, and to-be-confirmed items one by one;
- Priority reinforcement: At most 5 items, distinguishing "adjust wording", "supplement evidence", and "supplement ability";
- Application strategy: Whether to recommend applying, which resume version is suitable to use, and questions that need to be confirmed;
- Follow-up handoff: Generate the corresponding next-step prompt only when the user needs it.
"User evidence" in the matrix must be traceable back to a resume paragraph, project, portfolio, PR, file, or explicit user statement. When no evidence is found, write "not provided"; do not fill it in with common sense.
Routing and handoff
- Need to rewrite resume bullets, summary, or HR opening pitch: hand the
表达缺口in the matrix and confirmed facts to/great-resume； - Need to generate or edit an HTML/PDF resume: hand it to
/make-resume； - Need to predict questions or simulate an interview: hand the high-risk requirements and
证据不足items to/interview； - Have decided to apply and need to fill out a web form: hand the confirmed fields to
/job-apply； - Need to record application status: hand it to
/offer。
Analysis itself does not authorize modifying resume files, filling out applications, sending messages, or submitting applications. When the user only asks "does it match," stop at the application recommendation.
Factual boundaries
- Do not add skills, responsibilities, job levels, projects, or metrics the user has not actually done in order to fit the JD;
- Do not automatically treat adjacent technologies as mastered, for example knowing React does not equal having Vue project experience; transferability may be explained, but the status is still judged based on evidence;
- Do not uniformly interpret "preferred, familiar, understanding" as hard requirements; judge based on the original JD text and responsibility context;
- Do not directly reject a position because a single keyword is missing, nor judge someone as qualified just because keywords overlap;
- When time-sensitive conditions or external job pages are involved, keep the scraping date, and mark them as pending re-confirmation after the page becomes invalid.