interview-assessment

Support evidence-based interview assessment for two audiences:

• audience: recruiter: for HR, hiring managers, and interviewers who need candidate evaluation, interview planning, and post-interview recommendations.
• audience: candidate: for candidates who need role-fit self-assessment, interview preparation, resume or portfolio evidence improvement, and post-interview review.

Default to Markdown-first delivery. Use outputMode: json only when the user explicitly needs automation, ATS integration, app ingestion, or structured validation. Use outputMode: both when the user asks for both human-readable reports and a machine-readable evaluationBundle.

Infer defaults when the user does not specify them:

• If the user asks to evaluate a candidate, screen resumes, prepare interviewer questions, or make a hiring recommendation, use audience: recruiter.
• If the user says "I", asks to prepare for an interview, improve resume match, rehearse answers, or review their own interview, use audience: candidate.
• Use outputMode: markdown by default.

Minimum required fields:

• jdText
• resumeText

Optional fields:

• interviewTranscriptText or interview experience notes
• interviewerNotes
• metadata such as candidate name, role, company, round, date, and target language
• audience: recruiter | candidate
• outputMode: markdown | json | both
• outputLanguage or metadata.language, such as zh-CN or en

If jdText or resumeText is missing, do not score or make a conclusion. Return an insufficientEvidence section that asks only for the missing material.

Apply these rules before scoring or writing recommendations:

• Use only evidence from the JD, resume, transcript, interviewer notes, or user-provided context.
• Format every evidence quote as [来源: JD | 简历 | 面试转写 | 面试官笔记] "original quoted text".
• Do not invent qualifications, protected-class signals, interview performance, or hiring conclusions beyond provided evidence.
• Do not score or recommend based on protected attributes or obvious proxies, including age, gender, race, ethnicity, religion, disability, marital status, pregnancy, nationality, or other legally protected categories.
• Do not repeat private contact details, identity document numbers, home addresses, or unrelated personal information in reports.
• Treat salary, overtime, job stability, graduation year, location, and similar sensitive or bias-prone signals cautiously; use them only when directly relevant to JD requirements or user-provided legitimate assessment context.

Infer output language unless the user explicitly sets outputLanguage or metadata.language.

Language priority:

1. Explicit user instruction, outputLanguage, or metadata.language.
2. The language of the user's request.
3. If the request is mixed, use the dominant language of jdText and resumeText.
4. If still unclear, default to zh-CN.

Rules:

• Write all Markdown report content in the inferred output language.
• Localize section headings while preserving the required template structure and meaning.
• Localize filenames to the same output language.
• Preserve candidate names, company names, role names, product names, and quoted evidence in their original language unless translation is necessary for readability.
• If input materials are in one language but the user asks for another language, write analysis in the requested language and keep evidence quotes in the original language with a short translated explanation when helpful.

1. Extract must-have skills, role context, seniority, domain expectations, and success signals from the JD.
2. Map resume evidence to the JD.
3. Score in 0-100:
• workExperience
• professionalCapability
• softSkills
4. Compute weighted score using scoring-rubric.md.
5. For each dimension, include:
• score
• 1-3 sentence rationale
• 1-2 grounded evidence quotes from the JD/resume/interview material using the required evidence quote format
6. Apply audience-specific language:
• Recruiter: output 通过 | 待定 | 拒绝 and explain hiring risk.
• Candidate: output fit level and preparation priority; do not use hiring-decision wording.

1. Identify uncertainty zones and missing evidence.
2. Produce focus areas with high | medium | low priority.
3. Generate targeted questions and answer strategy:
• behavioral questions
• technical/domain questions
• motivation and expectation questions
4. For recruiter output, include target competency and follow-up hints.
5. For candidate output, include answer angle, evidence to prepare, and weak spots to repair.

Run this stage only when interviewTranscriptText, interview notes, or interview experience is provided.

1. Extract objective evidence snippets.
2. Evaluate professional capability, soft qualities, personal style, motivation, and expectation alignment.
3. Output pending concerns and next-step recommendations.
4. Use audience-specific framing:
• Recruiter: final hiring recommendation and process next step.
• Candidate: interview performance review, follow-up strategy, and improvement plan.

Markdown mode is the default. Write Markdown files unless the user asks for chat-only, no files, or equivalent wording. When the user asks for chat-only or no files, return the same report content in chat without writing files.

For audience: recruiter, use recruiter-report-templates.md:

• {候选人姓名}-候选人初评报告.md
• {候选人姓名}-面试准备清单.md
• {候选人姓名}-面试后综合评价报告.md only when Stage 3 is produced

For audience: candidate, use candidate-report-templates.md:

• {候选人姓名}-岗位匹配度自评报告.md
• {候选人姓名}-候选人面试准备清单.md
• {候选人姓名}-面试后复盘与跟进建议.md only when Stage 3 is produced

For English output, use localized filenames:

• Recruiter:
• {candidateName}-candidate-pre-screening-report.md
• {candidateName}-interview-preparation-checklist.md
• {candidateName}-post-interview-evaluation-report.md
• Candidate:
• {candidateName}-role-fit-self-assessment.md
• {candidateName}-candidate-interview-preparation-checklist.md
• {candidateName}-post-interview-review-and-follow-up.md

For other languages, translate the filename suffix naturally and keep the candidate name unchanged.

Default directories:

• Recruiter: {workspaceRoot}/候选人评估报告/
• Candidate: {workspaceRoot}/候选人面试准备/

Candidate name:

• Use metadata.candidateName if present.
• Otherwise infer from the resume header only when explicit.
• If still unknown, use candidateId and ask for the name in follow-up; do not guess.

When the user explicitly requests outputMode: json or outputMode: both, return a complete evaluationBundle using references/evaluationBundle.schema.md as the optional automation contract.

Rules:

• In json mode, do not write Markdown files unless asked.
• In both mode, Markdown and JSON must contain the same scores, conclusions, risks, recommendations, and evidence.
• For audience: recruiter, use recruiterDecision: 通过 | 待定 | 拒绝.
• For audience: candidate, use candidateFitLevel: 高匹配 | 中等匹配 | 需要补强; do not output 通过 | 待定 | 拒绝 as a candidate conclusion.
• JSON is an integration format, not the default HR/candidate deliverable.

• Keep language concise, evidence-based, and suitable for HR or interview panels.
• Use decision vocabulary: 通过 | 待定 | 拒绝.
• State that recruiter-facing reports are decision support for human review, not final hiring decisions.
• Include risks, must-verify items, next-round suggestions, and evidence quotes.
• For high-impact decisions (通过 or 拒绝), include at least 2 grounded evidence quotes.
• Do not invent facts not found in the input or use protected attributes/proxies as scoring evidence.

• Keep language practical, coaching-oriented, and non-deterministic.
• Do not use phrases such as "建议拒绝该候选人" or imply a guaranteed hiring outcome.
• Use fit and preparation vocabulary:
• 匹配度判断
• 优势证据
• 风险短板
• 回答策略
• 简历与作品集补强建议
• 面试后跟进建议
• Scores are preparation references, not predictions of hiring results.

Use only when the user asks for multi-agent or panel-style assessment.

Suggested role split:

• Role A: professional capability
• Role B: soft qualities and communication
• Role C: motivation, culture fit, and risk control

Aggregation:

1. Each role proposes scores, evidence, and concerns.
2. The orchestrator resolves conflicts by evidence quality.
3. Output the same audience-specific Markdown templates.
4. If JSON is requested, include agentVotes and roundtableSummary without removing base fields.

If a requested model is unavailable, use a single available model while preserving the role logic.

Follow docs/responsible-use.md for fairness, evidence grounding, and sensitive decision handling. Never invent qualifications, protected-class signals, interview performance, or hiring conclusions beyond the provided evidence.