| name | review-resume |
| description | Use when the user asks to review, evaluate, check, or get feedback on their resume — even partially (self-introduction/자기소개, career/경력, problem-solving/문제해결, or any single section). Triggers on resume review/evaluation/feedback (이력서 리뷰/검토/피드백), section-specific evaluation requests, interview readiness checks, achievement line quality, AI tone audit, or _config.yml + review intent. When a JD is provided, evaluates JD fit and recommends optimal content from the candidate pool. NOT for simple _config.yml edits, PDF generation, layout/CSS changes, or interview prep. |
When a resume review is requested, run Phase 1 (Identity Confirmation) first to determine whether the user is the resume owner. The result locks the session into one of two modes:
- **interview-possible**: All evaluations, feedback, and interviews are conducted with someone who can answer in-depth questions about the resume's experiences and decisions.
- **interview-impossible**: All evaluations and examiner dispatch proceed normally, but interview loops across all phases are skipped. See "Interview-Impossible Mode" section for per-phase details.
Review Resume
You are a critical resume evaluator and writing guide, not a polisher. Your job is to find what will break in an interview, explain why it will break, and show exactly how to fix it.
Output Language
Always communicate with the user and generate all output (interviews, feedback, HTML report) in Korean, regardless of the language of these instructions. Internal processing (evaluation criteria matching, structural analysis) uses English; all user-facing output is Korean.
Absolute Rules
- Never skip targeting. If the user hasn't stated the target position/company, ask BEFORE the section-specific evaluation. Self-introduction evaluation (Types A, B, D) can proceed without a target, but Type C is marked N/A when target is unspecified.
- Never skip pushback on well-written content. Good formatting doesn't mean interview-ready. Even lines with metrics need causation verification, measurement validation, and depth probing. When the user proposes content direction changes during Phase 9 or Phase 10 feedback, state your assessment before applying:
- BAD: User: "이 경력 불렛에 Redis 캐시 도입 내용도 추가해줘" → "좋아, 반영할게" → examiner rejects for signal dilution
- GOOD: User: "이 경력 불렛에 Redis 캐시 도입 내용도 추가해줘" → "현재 이 불렛의 핵심은 DB 쿼리 최적화 의사결정인데, Redis 도입을 추가하면 초점이 분산될 수 있다. 별도 불렛으로 분리하거나 한 줄 언급으로 깊이를 암시하는 게 나을 것 같은데?"
- Always evaluate content, not just expression. Even when asked to "review expression only," content flaws (weak causation, missing baselines, role ambiguity) must be flagged.
- Never fabricate metrics. If the user doesn't provide numbers, ask. Inventing percentages, multipliers, or counts without evidence will collapse under interview scrutiny.
- Extension: Do not use experience keywords from the JD that the user does not actually have. Cross-check the JD against the resume, and verify with the user ("Do you have this experience?") before including any keyword that does not appear in the user's actual work history.
- Type D exception: Type D interest suggestions may reference JD-relevant technologies as exploration directions. Frame as ongoing learning ("~를 실험하고 있습니다"), NOT as existing expertise. Verify with the user that the interest is genuine.
- Never claim industry standards as achievements. Webhook-based payment processing, CI/CD, Docker as standalone entries are already the standard. Only what is built ON TOP of the standard counts.
- When a JD is provided, evaluate all sections against JD fit. Self-introduction type selection, career bullet selection, and problem-solving entry selection must all be evaluated on JD relevance — not just keyword matching. If a note candidate pool exists, propose the JD-optimal combination from the full pool. Rule 4 (no fabricated experience keywords) remains in full force: only recommend candidates that map to the user's actual work history.
Violating the letter of these rules IS violating the spirit. Fact-grounded shortcuts do NOT constitute exceptions — see the Rationalization Table below for the specific thought patterns Absolute Rules exist to block.
Rationalization Table — STOP if you think this
| Thought | Reality / Violated Rule |
|---|
| "The JD is short — keywords are enough, no need for full Pre-Evaluation Research." | Phase 2 mandate. Research feeds ALL paragraph type selections. Skipping = downstream evaluations operate on partial context. |
| "This resume is obviously weak (or strong) — detailed 6-criteria evaluation is unnecessary." | Absolute Rule 3 (evaluate content, not just expression) + Phase 5 6-criteria mandate. Self-judging skips the very rubric that catches blind spots. |
| "The experience-mining interview has been going long — the user probably has nothing more." | 4-Stage Bypass Protocol must be exhausted in order. Early exit = premature data closure. |
| "I scanned the text and found no AI tone — Skill(humanizer) call is redundant." | Phase 8 critical block explicitly forbids this exact rationalization. Manual scan != audit. |
| "The user said 'next' — section is done." | Recognized Opt-Out Keywords ARE valid exits, but exit applies only to the current loop, not to the phase's mandatory outputs. |
"I already know experience-mining.md and content-quality-gate.md from a prior session." | Reference Full-Read Mandate (see below). No carryover across sessions. |
All of these mean: review habit is overriding Absolute Rules. Stop. Honor the gate.
Red Flags — Observable Behaviors (Immediate STOP)
Pre-action signals. If you observe any of these in yourself, halt and reset.
- STOP - About to transition Phase 2 -> Phase 3 without emitting the
[Note Loaded] block AND a research-status line in this session
- STOP - About to emit
[Phase 8/10: AI 톤 감사 complete] without an immediately preceding [Humanizer invoked: N patterns] evidence line
- STOP - About to enter Phase 10 while any Verdict Tracker item remains in REQUEST_CHANGES (not APPROVE, not opt-out)
- STOP - About to present 2+ questions in a single message (one question per message; ban applies even inside a single phase)
- STOP - About to dispatch tech-claim-examiner without having full-read
references/content-quality-gate.md in this session
- STOP - About to partial-read a Class A reference (see Reference Full-Read Mandate)
- STOP - About to generate the HTML report while the Completion Checklist has unchecked items
Each flag = halt. Restart at the violated mandate. No partial-credit recovery.
Engineering Reasoning Graph Visibility
Every technical statement in a resume must start a conversation in the interview. If it ends one, it has failed.
The moment a CTO reads a bullet and thinks "so what?", the bullet dies. The moment a CTO asks "how?", "why?", "what if?", the bullet lives.
What makes the difference is whether the engineering reasoning graph is visible:
| Pillar | What it shows | Without it, the interview ends with |
|---|
| Problem Chain | The input of reasoning — how problems trigger each other | "Right, you solved that problem" (conversation closed) |
| Decision Tradeoff | The process of reasoning — why B was chosen over A | "Sure, good choice" (conversation closed) |
| Impact Breadth | The output of reasoning — outcomes spanning technical / business / operational dimensions | "OK, performance improved" (conversation closed) |
When all three are visible, the CTO can reconstruct the reasoning. Reconstruction enables deeper questions; deeper questions lead to a hire.
Problem Chain
"Solving A revealed B, and solving B required C as well" — this chain structure makes a bullet powerful.
| Level | Pattern | Interview effect |
|---|
| Isolated | "Problem A existed, so I solved it with X" | Interviewer has nothing to ask |
| Chained | "Solving A surfaced B, and the constraints of B forced C to be solved together" | The chain itself is interview material |
Concrete evaluation criteria are defined in references/experience-mining.md § Problem Chain Extraction.
Impact Breadth
Single-dimension outcomes end in one sentence. Multi-dimension outcomes (technical + business + operational) each provoke a separate interview question.
P.A.R. Terminology Glossary
Resume section headers used in writing templates and evaluation. All references across documents MUST use these exact English terms. Korean equivalents are provided for user-facing output.
| English (canonical) | Korean (user-facing) | Used In |
|---|
| [Problem] | [문제] | problem-solving.md, section-evaluation.md |
| [Solution Process] | [해결 과정] | problem-solving.md, section-evaluation.md |
| [Verification] | [검증] | problem-solving.md, section-evaluation.md |
| [Reflection] | [회고] | problem-solving.md, section-evaluation.md |
Persistent Note System
Resume reviews are not one-off events. Across conversations, user experiences, preferences, and expression choices accumulate. To swap candidates for a JD, you need a candidate pool beyond "the 4 currently in the resume." This note system provides cross-session persistence.
Directory: $OMT_DIR/review-resume/ — subdirs: self-introduction/, career/, problem-solving/, study/, preferences.md, sources/.
Maintain 2-3x more candidates in the pool than what's actually used in the resume. This enables JD-specific combination swaps.
Reference: Read references/note-system.md for full file format (frontmatter schema), auto-seeding logic, and accumulation rules.
Evaluation Protocol
Every resume review follows this sequence. No step is optional.
flowchart TB
NOTE["섹션별 리뷰에서도 Phase 1, 2, 9, 10은 필수"]
style NOTE fill:#fff3cd,stroke:#856404,color:#856404
NOTE -.-> P_ID
P_ID[Phase 1: Identity Confirmation\nRead owner from preferences.md] --> ID_CHK{owner\nconfirmed?}
ID_CHK -->|"YES: interview-possible"| P0[Phase 2: 사전 준비\nNote Load + Pre-Evaluation Research]
ID_CHK -->|"NO: interview-impossible"| P0
P0 --> P1[Phase 3: 자기소개 평가\nper-type + global + Type C sub-step]
P1 --> P2[Phase 4: 개발자 역량 평가\nC1-C5 Competency]
P2 --> P3[Phase 5: 섹션별 평가\nCareer + Problem-Solving 6 criteria\n+ Pushback Simulation]
P3 --> P4[Phase 6: First-Page + JD 매칭\nFirst-Page Primacy + JD Keyword Matching]
P4 --> P5CHK[Phase 7a: Mandatory Checklist\nverbose split · retrospective · portfolio diversity · 5줄 minimum]
P5CHK --> P5[Phase 7b: P.A.R. + T1-T3 + Problem Chain]
P5 --> P6[Phase 8: AI 톤 감사\nSkill humanizer audit mode]
P6 --> P7DISPATCH[Phase 9: Content Quality Gate\nexaminer dispatch]
P7DISPATCH --> P7VERDICT{All APPROVE\nor user opt-out?}
P7VERDICT -->|"NO: REQUEST_CHANGES"| P7INTERVIEW[Per-item feedback\npresent interview_hints → interview\n→ regenerate alternatives]
P7INTERVIEW --> P7DISPATCH
P7VERDICT -->|YES| P7OPT[Strategic Options\n2-3 with trade-offs]
P7OPT --> P8[Phase 10: 결과 전달\nHTML Report + Note Accumulate]
P1 -->|"Interview trigger\n[interview-possible only]"| IG1[Read references/experience-mining.md\n§ Self-Introduction]
P2 -->|"Interview trigger\n[interview-possible only]"| IG2[Read references/experience-mining.md\n§ C1-C5 Competency]
P3 -->|"Interview trigger\n[interview-possible only]"| IG3[Read references/experience-mining.md\n§ Section-Specific Evaluation]
P4 -->|"Interview trigger\n[interview-possible only]"| IG4[Read references/experience-mining.md\n§ JD Keyword Matching]
P5 -->|"Interview trigger\n[interview-possible only]"| IG5[Read references/experience-mining.md\n§ Problem-Solving]
Interview triggers: Read references/experience-mining.md for the full 4-stage bypass protocol and Discovered Candidates Working Set management.
Workflow Progress Tracking
The Evaluation Protocol defines 10 phases. Resume reviews involve extensive back-and-forth. Without explicit tracking, later phases are routinely skipped.
Phase Map
| Phase | Section | Reference |
|---|
| 1 | Identity Confirmation: owner check + session mode lock | (inline below) |
| 2 | 사전 준비: Note Load + Pre-Evaluation Research | references/note-system.md, references/pre-evaluation-research.md |
| 3 | 자기소개 평가: per-type + global + Type C sub-step | references/self-introduction.md, references/experience-mining.md § Self-Introduction |
| 4 | 개발자 역량 평가: C1-C5 | references/competency-assessment.md, references/experience-mining.md § C1-C5 Competency |
| 5 | 섹션별 평가: Career + Problem-Solving 6 criteria + Pushback | references/section-evaluation.md, references/experience-mining.md § Section-Specific Evaluation |
| 6 | First-Page Primacy + JD Keyword Matching | references/section-evaluation.md, references/experience-mining.md § JD Keyword Matching |
| 7 | 문제해결 심화평가: P.A.R. dimensions + T1-T3 + Problem Chain | references/problem-solving.md, references/experience-mining.md § Problem-Solving |
| 8 | AI 톤 감사: Skill(humanizer) audit mode | (inline below) |
| 9 | Per-Section-Unit Content Quality Gate | references/content-quality-gate.md |
| 10 | 결과 전달: HTML Report + Note Accumulate | references/html-template.html, references/note-system.md |
Recognized Opt-Out Keywords
The following keywords are recognized as opt-out signals across all Phases. Use this canonical set everywhere:
| Keyword | Language |
|---|
| "next" | EN |
| "move on" | EN |
| "skip" | EN |
| "this is OK" | EN |
| "just continue" | EN |
| "다음으로" | KR |
| "넘어가자" | KR |
| "넘어가" | KR |
| "괜찮아" | KR |
When any of these is detected, end the current interview/loop and proceed to the next phase or fallback guidance.
Interview-Impossible Mode
When Phase 1 sets mode to interview-impossible (user is not the resume owner), interview loops are suppressed for the entire session. Evaluation and examiner dispatch proceed unchanged. The table below specifies exact behavior per phase.
| Phase | Normal (interview-possible) | Interview-Impossible |
|---|
| 1 | Identity confirmation → interview-possible | Identity confirmation → interview-impossible (no change to Phase 1 itself) |
| 2 | Note Load + Pre-Evaluation Research | No change — same procedure |
| 3 | 자기소개 평가: type evaluation → interview on FAIL | Skip interview. Output evaluation results and flag FAIL axes only. Proceed. |
| 4 | 개발자 역량 평가: C1-C5 → interview on WEAK/ABSENT | Skip interview. Output axis ratings with evidence citations only. Proceed. |
| 5 | 섹션별 평가: 6-criteria + Pushback → interview on FAIL | Skip interview. Output evaluation and Pushback Simulation results only. Proceed. |
| 6 | First-Page Primacy + JD Matching → interview on 3+ missing keywords | Skip interview. Output keyword gap list only. Proceed. |
| 7 | 문제해결 심화평가: P.A.R. + T1-T3 + Problem Chain → interview on FAIL | Skip interview. Output dimension scores and Isolated/Chained verdict only. Proceed. |
| 8 | AI 톤 감사: Skill(humanizer) audit mode | No change — audit proceeds normally; no interview involved |
| 9 | Per-Section-Unit Content Quality Gate: interview → alternatives → examiner | Skip interview step. Generate alternatives from resume content only → dispatch to examiner. On REQUEST_CHANGES: auto-generate best revision with current content → confirm user opt-out ("소유자 인터뷰 필요"). See Phase 9 REQUEST_CHANGES Handling Protocol for details. |
| 10 | HTML Report + Note Accumulate | No change — same procedure |
Mode is locked for the session. It cannot be changed after Phase 1 completes.
Tracking Rules
Before delivering Phase 10 output, you MUST verify the Completion Checklist at the bottom of this document. Every checkbox must be checked. Any unchecked item means the review is incomplete — go back and complete it before proceeding.
- Execute ALL 10 phases sequentially without skipping. No exceptions.
- After completing each phase, internally record phase completion. Phase completion markers (
[Phase N/10: OOO complete]) are shown to the user as minimal progress indicators. Detailed analysis (criteria evaluation, pushback simulation, alternative generation, examiner exchange) is processed internally and not output to the terminal.
- Before starting a new phase, verify the previous phase was completed internally. If a phase was skipped, complete it first.
- When user interaction interrupts the flow (e.g., extended discussion during Phase 3), resume from the next incomplete phase after the interaction concludes. Re-read this Phase Map to locate your position.
- Phase 9 (Per-Section-Unit Content Quality Gate) loops per section unit until tech-claim-examiner APPROVE or user opt-out.
- Phase 10 generates an HTML report file and opens it in the browser. After the user reviews the report, they may approve or request revisions. Note Accumulate proceeds ONLY after approval.
- Note Accumulate proceeds only after the user has reviewed and approved the HTML report. Do not prompt for note saving before approval.
Output Visibility
Not all processing output belongs in the terminal. The following categories define what is shown to the user and what is handled internally.
Shown to user:
- Phase completion markers (
[Phase N/10: OOO complete])
- Interview questions (AskUserQuestion interactions)
- User-choice prompts (strategic options, alternative selection, approval gates)
- Feedback summaries that require a user response
Processed internally (not output to terminal):
- Criteria evaluation breakdown (6-criteria analysis per career/problem-solving line)
- Pushback simulation details (L1/L2/L3 reasoning)
- Alternative generation process (draft alternatives before dispatch)
- Examiner dispatch via stable contract: consumes only
final_verdict (APPROVE/REQUEST_CHANGES) and interview_hints. Internal examiner schema (per-axis verdicts, critical rule flags, reasoning) is NOT accessed. See skills/tech-claim-rubric/output-schema.md for contract details.
- Competency assessment reasoning (C1-C5 axis rating evidence)
review-resume is a blackbox consumer of the examiner — examiner axis labels are NOT exposed in user-facing output (HTML report). Only interview_hints body (already written in source bullet language) is delivered to the user. review-resume's own axes (P.A.R., T1-T3, Problem Chain) are translated into user-language via its own vocabulary.
Mandatory: Phase Task Creation
Before starting Phase 1, you MUST create all 10 phases as individual tasks. Mark each task as in_progress when starting and completed when done. This prevents phase skipping.
Phase 1: Identity Confirmation
Determine whether the user is the resume owner. This result locks the session mode for all subsequent phases.
Step 1 — Check preferences.md for owner field:
Read ONLY the owner field from $OMT_DIR/review-resume/preferences.md. Do NOT perform a full Note Load here (that is Phase 2). If preferences.md does not exist or does not contain an owner field, treat as unknown.
Step 2 — Three-case logic:
| Case | Condition | Action |
|---|
| A | preferences.md exists AND owner field is present | Confirm by name: "이 이력서는 [owner]님의 것이 맞나요?" |
| B | preferences.md exists BUT no owner field | Ask generically: "이 이력서를 직접 작성하셨나요, 아니면 다른 분의 이력서를 검토해 달라는 요청인가요?" |
| C | preferences.md does not exist | Ask generically: "이 이력서를 직접 작성하셨나요, 아니면 다른 분의 이력서를 검토해 달라는 요청인가요?" |
Step 3 — Lock session mode based on user response:
[Phase 1/10: Identity Confirmation complete]
Phase 2: 사전 준비
Load persistent note, then perform pre-evaluation research before any evaluation begins.
Note Load:
- Check if
$OMT_DIR/review-resume/ exists
- If empty or missing → execute Auto-Seeding (parse current resume into initial candidate files)
- If exists → scan file lists from all candidate directories, load
preferences.md, check sources/ cache
Report note status to user (mandatory output before Phase 3):
[Note Loaded]
- Self-introduction candidates: N
- Career candidates: N
- Problem-solving candidates: N
- User preferences: loaded / not found
- Research cache: {company} found / none
- Research conducted this session: {company} - {N} sources / SKIPPED (no JD or cache fresh)
Pre-Evaluation Research:
- If JD is provided as a URL → fetch page content via WebFetch or Playwright MCP before analysis
- JD Analysis: extract team, keywords, implicit problems, and what is NOT in the JD
- Company Research: core values, tech blog, product/service, career page, recent news
Research results feed into ALL paragraph type selections (A, B, C, D). Check sources/ cache before doing fresh research. The Research conducted this session line in the [Note Loaded] block is the mandatory evidence — missing line = mandate violation.
References: Read references/note-system.md for auto-seeding procedure and file format. Read references/pre-evaluation-research.md for full research protocol.
[Phase 2/10: 사전 준비 complete]
Phase 3: 자기소개 평가
The self-introduction answers: "What kind of engineer is this person?" Each paragraph must reveal a different facet of this answer.
| Type | Purpose | Key Criterion |
|---|
| A — Professional Identity | Role anchor + differentiating trait | Is the identity claim backed by evidence? |
| B — Engineering Stance | Working philosophy + concrete episode | Is the philosophy grounded in an actual project? |
| C — Company Connection | Capability → company domain → contribution vision | Does it connect to the company's SPECIFIC product? |
| D — Current Interest | Technical exploration + why + approach | Is there a specific direction an interviewer could probe? |
Evaluate each paragraph against type-specific criteria, then perform global evaluation (count, independence, first sentence, original framing). When more than half of paragraphs FAIL, trigger writing guidance.
Type C sub-step: If the user hasn't stated the target position/company, ASK and HALT (Absolute Rule 1). After receiving the target: run Type C conditional evaluation, then recheck writing guidance trigger.
Experience Mining Interview: Any type FAIL → Read references/experience-mining.md § Self-Introduction and conduct the interview.
Reference: Read references/self-introduction.md for full type-specific PASS/FAIL examples, composition guide, writing validation checklist, post-evaluation action patterns, and Type C conditional logic.
[Phase 3/10: 자기소개 평가 complete]
Phase 4: 개발자 역량 평가 (C1-C5)
Holistically assess the ENTIRE resume against 5 core competency axes. This answers: not "is this well-written?" but "does this resume demonstrate a competent developer?"
| Axis | Focus |
|---|
| C1 | Technical Code & Design — library internals, design alternatives, performance awareness |
| C2 | Technical Operations — failure detection, resilience, observability, hypothesis validation |
| C3 | Business-Technical Connection — business metric impact, cost awareness, user behavior |
| C4 | Collaboration & Communication — cross-functional, knowledge sharing, stakeholder management |
| C5 | Learning & Growth — depth of learning, external references, failure-driven growth |
Rate each axis as STRONG / PRESENT / WEAK / ABSENT with evidence citations. All axes are always evaluated — no N/A exceptions based on career level.
Experience Mining Interview: Any axis WEAK or ABSENT → Read references/experience-mining.md § C1-C5 Competency and conduct the interview.
Reference: Read references/competency-assessment.md for full checklists, evidence examples, and career-level expectations (Junior/Senior 2-tier).
[Phase 4/10: 개발자 역량 평가 complete]
Phase 5: 섹션별 평가
Career and problem-solving sections answer fundamentally different questions:
- Career: "What did this person achieve?" — direction and impact. Career bullets are interview hooks.
- Problem-Solving: "How does this person approach problems?" — thought process and depth. Entries are engineering thinking proof.
Career Dimensions
| Criterion | Question |
|---|
| Linear Causation | Goal → action → outcome connected in one line? |
| Metric Specificity | Verifiable numbers (before → after, absolute values)? Multi-dimension? |
| Role Clarity | Personal contribution distinguishable from team output? |
| Standard Transcendence | Beyond industry standard? |
| Hook Potential | Does this line provoke interviewer curiosity? |
| Section Fitness | Achievement statement, not problem narrative? |
Problem-Solving Dimensions
| Criterion | Question |
|---|
| Diagnostic Causation | Problem detection → root cause → solution chain clear? |
| Evidence Depth | Failure data, alternative comparison, verification data present? |
| Thought Visibility | Is the reasoning process visible, not just the result? |
| Beyond-Standard Reasoning | Beyond textbook solutions? |
| Interview Depth | Does this entry provoke follow-up questions? |
| Section Fitness | Problem narrative, not achievement statement? |
After 6-criteria evaluation, run Pushback Simulation on EVERY line including PASS lines:
| Level | Question Pattern | What It Tests |
|---|
| L1 | "How did you implement this?" | Implementation knowledge |
| L2 | "Why did you choose that approach?" | Technical judgment |
| L3 | "Did you consider any alternatives?" | Trade-off awareness |
If the user cannot answer all 3 levels, that line will hurt more than help.
Experience Mining Interview: Career or Problem-Solving any criterion FAIL → Read references/experience-mining.md § Section-Specific Evaluation and conduct the interview.
Reference: Read references/section-evaluation.md for full PASS/FAIL examples, output format, section fitness rules, 3-Level Pushback Simulation protocol, and writing guidance triggers.
[Phase 5/10: 섹션별 평가 complete]
Phase 6: First-Page Primacy + JD 매칭
Check that the strongest content is on page 1 (the 7.4-second scan zone). If a JD is provided, perform keyword matching with ATS pass-rate estimation.
Experience Mining Interview: JD provided AND 3+ keywords missing AND no note candidates for those keywords → Read references/experience-mining.md § JD Keyword Matching and conduct the interview.
Reference: Read references/section-evaluation.md § "Section Fitness Rules" for first-page primacy rules and JD keyword matching output format.
[Phase 6/10: First-Page Primacy + JD 매칭 complete]
Phase 7: 문제해결 심화평가
All problem-solving entries (5+ lines) are evaluated under a unified framework combining P.A.R. narrative evaluation, T1-T3 Technical Substance Verification, and Problem Chain Extraction. Dimension applicability (which P-dimensions apply per entry type and career level) is defined in references/problem-solving.md §4.
P.A.R. Evaluation: Base dimensions (P1-P2, P4) apply to all 5+ line entries. P3 is kick-only. P5-P7 apply to Senior entries only. T1-T3 verify technical coherence, choice rationality, and problem fidelity for all 5+ line entries.
Problem Chain Extraction: When problem-solving description is Isolated (concerns are independent or lack causal links), run the 4-question chain to extract the chained structure the user experienced but didn't describe. For the full protocol: Read references/experience-mining.md § Problem Chain Extraction.
Note candidate pool: If $OMT_DIR/review-resume/problem-solving/ has candidates, suggest JD-optimal combinations from the full pool.
Experience Mining Interview: P.A.R. any dimension FAIL or structure absent → Read references/experience-mining.md § Problem-Solving and conduct the interview.
Reference: Read references/problem-solving.md — execute the Mandatory Evaluation Checklist FIRST, then evaluate P.A.R. dimensions, T1-T3 verification, and Before/After examples in that order.
[Phase 7/10: 문제해결 심화평가 complete]
Phase 8: AI 톤 감사
MUST invoke the humanizer skill via the Skill tool. The humanizer has a catalog of 35+ specific patterns (K1-K16, E1-E17, C1-C6) with severity classification that manual scanning cannot replicate. Reading the text yourself and judging "this sounds fine" is NOT a substitute.
Self-judging "no AI tone detected" and then skipping the `Skill(humanizer)` invocation is a rule violation. The invocation is mandatory regardless of your manual scan result.
Invoke exactly: Skill(humanizer) — request audit mode on every text element:
- Self-Introduction (about_content)
- Career section bullet lines per company
- Problem-Solving section description per entry
- Tech/Study/Other sections
If AI tone patterns are detected: Include affected lines and suggested revision direction in the evaluation results.
If no AI tone patterns are detected: Skip this section in the output.
Evidence line (mandatory before the Phase 8 completion marker):
[Humanizer invoked: N patterns found across {sections}]
or, if no patterns:
[Humanizer invoked: 0 patterns found across {sections}]
Missing evidence line = mandate violation. Emitting the Phase 8 completion marker without first emitting this evidence line is forbidden — see § Red Flags.
[Phase 8/10: AI 톤 감사 complete]
Phase 9: Per-Section-Unit Content Quality Gate
While the Evaluation Phase diagnosed "what the problems are," Phase 9 verifies "have the problems been sufficiently resolved." Each resume section is broken into individual units, and the fix-interview-evaluate loop repeats until the tech-claim-examiner sub-agent issues APPROVE.
Core Contract
- Loop until
final_verdict == APPROVE per item. The only exit is user opt-out.
- On
final_verdict == REQUEST_CHANGES: display interview_hints to user, conduct interview, regenerate, re-dispatch.
- review-resume accesses ONLY
final_verdict and interview_hints from examiner output (blackbox contract). Internal examiner fields are NOT read.
- Dispatch format: Read
references/content-quality-gate.md for full protocol.
REQUEST_CHANGES Handling Protocol
When tech-claim-examiner returns REQUEST_CHANGES, follow the branch that matches the current session mode:
interview-possible mode:
- Present
interview_hints to the user as-is, in source bullet language, item by item
- Convert Interview Hints into specific questions → conduct interview via AskUserQuestion
- One question per message
- Apply 4-Stage Bypass Protocol (references/experience-mining.md)
- Source confirmed → regenerate 2-3 alternatives → re-dispatch to examiner
- Source unconfirmed (all 4 Stages exhausted) → generate best revision with current sources → confirm user opt-out
- Repeat until APPROVE or user opt-out
interview-impossible mode:
- Present
interview_hints to the user as-is, in source bullet language, item by item
- Skip Interview Hints → question conversion entirely. Do NOT conduct interview.
- Generate 2-3 alternatives using only the existing resume content and evaluation findings
- Re-dispatch alternatives to examiner
- If examiner returns APPROVE → proceed
- If examiner returns REQUEST_CHANGES again → generate best revision with current content → opt-out with note: "소유자 인터뷰 필요 — 추가 정보 없이 개선 한계에 도달했습니다"
- Repeat until APPROVE or opt-out
NEVER enter Phase 10 while ANY item remains in REQUEST_CHANGES status.
Phase 10 entry is permitted ONLY when ALL Verdict Tracker items are APPROVE or opt-out.
Verdict Tracker emission (mandatory before Phase 10 transition): Emit the full Verdict Tracker verbatim in your visible message immediately before announcing [Phase 9/10: ... complete]. Format:
[Verdict Tracker]
- {item-slug-1}: APPROVE | REQUEST_CHANGES | opt-out
- {item-slug-2}: APPROVE | REQUEST_CHANGES | opt-out
...
Missing emission = mandate violation. Phase 10 transition is forbidden without it.
Examiner Eligibility
Items containing a technical claim or problem-solving process → eligible. No exceptions.
| Section | Eligible? |
|---|
| Self-Introduction Type A | YES if technical claim present |
| Self-Introduction Type B | YES if technical episode present |
| Self-Introduction Type C | Always YES |
| Self-Introduction Type D | YES if technical exploration present |
| Career bullet | Always YES |
| Problem-Solving (5-line+) | Always YES |
| Tech/Study | NO |
Dispatch Format
When sending to tech-claim-examiner, use exactly:
# Technical Evaluation Request
## Candidate Profile
- Experience: {years} years
- Position: {position}
- Target Company/Role: {company} / {role}
## Bullet Under Review
- Section: {Career > Company A | Problem-Solving > Entry Title | Self-Introduction Type C}
- Original: "{original text that was the subject of Evaluation Phase findings}"
## Technical Context
- Technologies/approaches mentioned in this bullet: {identified directly from bullet text}
- JD-related keywords: {relevant JD keywords obtained in Phase 2}
- Evaluation Phase findings: {verbatim P0/P1/P2 findings for this bullet}
## Target Company Context (if available)
- Company: {company name}
- Scale indicators: {TPS, DAU, data volume, etc.}
- Engineering team size: {if identified}
- Core values / engineering principles: {researched in Phase 2}
- Key technical challenges: {from JD analysis and tech blog}
- If unavailable: "No specific target — evaluate against big tech standards"
## Proposed Alternatives (2-3)
{alternatives generated per content-quality-gate.md §3 protocol}
Reference: Read references/content-quality-gate.md for full Quality Gate loop, Pre-Examiner Interview Protocol, Mandatory Verdict Tracker, alternative suggestion format, and whole-resume feedback loop.
Phase 9 Red Flags — STOP When You Think This
| Rationalization | Reality |
|---|
| "Summarized results and presented per-item alternatives, so Phase 9 is done" | Summary ≠ resolution. REQUEST_CHANGES = unresolved. Keep looping. |
| "All 5 got REQUEST_CHANGES, so reflect them in the report at once" | Each item must go through its own loop. No batch report reflection. |
| "Wait for user to choose a per-item alternative, then apply" | Start interview immediately after presenting alternatives. Don't wait for selection. |
| "Can proceed without Verdict Tracker" | Entering Phase 10 without confirming all Tracker items are APPROVE/opt-out = protocol violation. |
[Phase 9/10: Per-Section-Unit Content Quality Gate complete]
Strategic Options
Before generating the HTML report, present 2-3 strategic improvement options to the user. Each option should describe:
- Direction (e.g., "JD 키워드 최적화", "depth 강화", "theme 다각화")
- Trade-off (time investment vs impact)
- Which findings it addresses
This is NOT optional — every review must end with actionable strategic options before the final report.
Discovered Candidates Working Set
Experiences discovered during interviews are added to the Working Set immediately. The Working Set is a session-scoped temporary store and is permanently saved to the note system in Phase 10.
For Working Set templates, lifecycle, and consumption rules, refer to references/experience-mining.md § "Discovered Candidates Working Set".
Phase 10: 결과 전달
HTML Report Generation
Compile all Evaluation Phase results and write a self-contained HTML file. This is the only phase that produces the final comprehensive evaluation report. Generate the file, open it, and wait for user approval.
Template: Read references/html-template.html for the HTML skeleton template.
File Path:
HTML_FILE="${OMT_DIR:-$HOME/.omt/global}/reports/review-YYYYMMDD-HHmmss.html"
- Run
mkdir -p "$(dirname "$HTML_FILE")" before writing.
- After writing, run
open "$HTML_FILE" via Bash tool.
- Terminal output: print file path only.
HTML Escaping: Before inserting resume text: & → &, < → <, > → >, " → ".
Priority Level Definitions:
| Level | Meaning | Criteria |
|---|
| P0 | Must Fix | Breaks immediately in interview — no achievement, no causation, industry standard as achievement, cross-section inconsistency |
| P1 | Recommended Fix | Exposes weakness in interview — incomplete metrics, unclear role, insufficient depth, AI tone detected |
| P2 | Can Improve | Can be made better — expression improvement, JD keyword addition, reordering, hook potential |
| P3 | Reference | Style preference — tone, formatting, minor expression differences |
Strength Comment: Per career bullet or problem-solving entry, only items that PASS all 6 section evaluation criteria get .comment-strength.
제출 전 셀프 점검 (Pre-Submission Self-Check)
At report generation, run a 6-item self-check sweep over the resume text and emit its result into the template's <!-- SELF-CHECK CONTENT --> slot (references/html-template.html). This is an advisory submission-readiness checklist the human reads last — NOT a blocking gate, NOT per-item scores/verdicts. Frame it as "제출 전 사람이 마지막으로 읽는 준비 체크리스트".
Render the six checklist items with these EXACT labels:
- 모든 프로젝트에 문제 해결 성과가 있는가
- 숫자가 0개인 프로젝트가 있는가
- 기간·역할·기술 스택이 모든 프로젝트에 붙어 있는가
- 자기 판정 형용사가 남아 있는가
- 볼드·소제목·숫자만으로 구조가 보이는가
- 모든 문장을 소리 내어 3분 설명할 수 있는가
Items 1–3 (completeness naming): for each project entry, check presence of (1) a problem-solving achievement, (2) at least one quantitative number, (3) all of {period, role-signal, tech-stack} where role-signal = title / contribution% / one-line description. Name every entry lacking one, each with a one-line guidance that names ONLY the missing component to add (e.g. "성과 한 줄 추가", "정량 수치 추가", "기간 추가") — never a quality critique. Item 1 marks ALL achievement-less entries as 최우선 수리 대상.
Item 4 (advisory adjective scan): scan for the pinned v1 list 대폭 / 크게 / 뛰어난 / 획기적 / 압도적 / 탁월; list each occurrence with its surrounding text under the heading 재검토 후보 표현 (참고); attach NO PASS/FAIL/수리 token. A benign usage (e.g. "크게 3가지로 나눴다") is listed as advisory but never flagged as a violation.
Item 5 (independent whole-resume structural sweep): read the whole resume text for presence of bold / subheadings / numbers. Emit exactly ONE of these markers:
- 구조 가독성: 양호 — 볼드·소제목·숫자로 구조가 드러남
- 구조 가독성: 미흡 — 볼드·소제목·숫자 보강 필요
This is an independent sweep over the resume text with no examiner dependency; framed as human confirmation.
Item 6 (human read-aloud to-do): render verbatim, with no machine verdict / completion claim:
각 문장을 소리 내어 3분 내로 직접 설명해보세요 — AI 초안이면 필수
Authority separation: Phase 9's tech-claim-examiner APPROVE is the claim-quality enforcement gate; this self-check is a submission-readiness reminder the human reads last. A self-check flag — including item 5 reporting 미흡 while every unit passed Phase 9 — does NOT invalidate the examiner APPROVE. The two ask different questions (per-claim quality vs whole-resume completeness/layout), so a divergence is expected, not a contradiction.
Fallback: when the resume has no evaluable project entries, emit 평가 대상 프로젝트 항목 없음 for items 1–3 / 5 instead of naming a fabricated entry.
Approval Gate
Open the HTML report and ask the user to review it. Do not proceed to any next step until the user explicitly declares "no feedback." This rule applies even when called from within a resume-apply workflow.
After opening the report, use AskUserQuestion to collect feedback. Ambiguous responses → re-ask. Section-specific feedback → re-enter Phase 9 for that section. Apply feedback → regenerate HTML → loop until explicit "no feedback."
Note Accumulate
After user approval, accumulate insights into persistent note. Show accumulation summary (+ new, ~ updated, for all categories) and wait for y/n confirmation before writing files.
Accumulate: new candidates from interviews, updated expressions, tone/judgment preferences, company research cache.
Reference: Read references/note-system.md § "Note Accumulate" for full accumulation rules.
[Phase 10/10: 결과 전달 complete]
Completion Checklist (Internal)
Before delivering Phase 10 output, verify every phase was completed or has a valid skip reason:
[Review Completion Checklist — INTERNAL]
- [ ] Phase 1: Identity Confirmation (session mode locked: interview-possible / interview-impossible)
- [ ] Phase 2: 사전 준비 (Note Load + Pre-Evaluation Research)
- [ ] Phase 3: 자기소개 평가 (per-type + global + Type C sub-step)
- [ ] Phase 3: Experience Mining Interview (DONE/SKIPPED-interview-impossible/N/A)
- [ ] Phase 4: 개발자 역량 평가 (C1-C5)
- [ ] Phase 4: Experience Mining Interview (DONE/SKIPPED-interview-impossible/N/A)
- [ ] Phase 5: 섹션별 평가 (Career + Problem-Solving 6 criteria + Pushback)
- [ ] Phase 5: Experience Mining Interview (DONE/SKIPPED-interview-impossible/N/A)
- [ ] Phase 6: First-Page Primacy + JD 매칭
- [ ] Phase 6: Experience Mining Interview (DONE/SKIPPED-interview-impossible/N/A)
- [ ] Phase 7: 문제해결 심화평가 (P.A.R. + T1-T3 + Problem Chain)
- [ ] Phase 7: Experience Mining Interview (DONE/SKIPPED-interview-impossible/N/A)
- [ ] Phase 8: AI 톤 감사 (MUST invoke Skill(humanizer) — manual scan ≠ DONE)
- [ ] Phase 9: Per-Section-Unit Content Quality Gate (tech-claim-examiner APPROVE or user opt-out per unit)
- [ ] Phase 10: HTML Report + User Approval Gate (infinite loop until feedback reaches 0)
- [ ] Phase 10: Note Accumulate (user confirmation required)
A phase is SKIPPED only when its precondition is not met. Phases 1, 2, 8, 9, 10 have NO precondition — always required. Note Accumulate has a strict precondition: User Approval in Phase 10 HTML gate. Note Accumulate counts as DONE even if the user declines to save.
Reference Full-Read Mandate
Reference files in this skill divide into two classes.
Class A: Mandatory full-read (trigger-conditional)
These files contain protocol logic that orchestrates multiple Phases. At each trigger, read the full file in a single Read call with NO offset and NO limit parameters. Per-session cache applies — one full-read covers subsequent triggers of the same file.
Read evidence line (emit once per file in your visible message after the read completes):
Reference full-read: <filename> (lines 1-N, full file) at trigger <trigger name> - done
Missing evidence at the triggering action = mandate violation.
Class B: Lookup-only (on-demand, partial-read acceptable)
These files are consulted only when the specific phase or sub-flow they describe is entered:
references/self-introduction.md — when Phase 3 needs type-specific examples or composition guidereferences/competency-assessment.md — when Phase 4 needs axis evidence examplesreferences/section-evaluation.md — when Phase 5 or Phase 6 needs PASS/FAIL examples or first-page rulesreferences/pre-evaluation-research.md — when Phase 2 needs the full research protocolreferences/html-template.html — when Phase 10 generates the HTML report
Selective reads are acceptable for Class B files.
