| name | resume-forge |
| description | Use when creating, sourcing, or refining resume problem-solving material — building compound scenarios, developing problem definitions, crafting solution strategies, or iterating entries until examiner approval. Triggers on 이력서 재료/소재, 문제 상황 만들기, 시나리오 작성, compound scenario, 이력서 항목 작성 |
Resume Forge
Axis-aware orchestrator boundary: This skill is the axis-aware orchestrator of tech-claim-examiner. It consumes the full examiner schema including INTERNAL fields (verdicts.a1-a5, critical_rule_flags.*, reasoning, evidence_quote) for source-extraction routing and Loop 1/2 gate decisions. The blackbox contract rule that restricts review-resume to PUBLIC fields does not apply here — see skills/tech-claim-rubric/output-schema.md for full contract.
Collaboratively source, refine, and complete resume problem-solving entries with the user. Two feedback loops progressively elevate quality.
Principles
- Delegate scoring: All evaluation goes to
tech-claim-examiner. This skill only checks pass/fail thresholds
- Free-form discussion: Never force structured choices in AskUserQuestion. Use open-ended questions
- Critical partner: Do not blindly accept user input. Challenge, propose alternatives, surface trade-offs. When the user proposes a content direction change, state your assessment before applying it:
- BAD: User: "파티션 설계 내용도 넣자" → "좋아, 반영할게" → structural_verdict FAIL (scanability low: detail spill)
- GOOD: User: "파티션 설계 내용도 넣자" → "structural_verdict 기준상 design rationale 없는 구현 디테일로 읽힐 가능성이 높다 — 넣을까, 한 문장 언급으로 깊이를 암시할까?"
- GOOD (agree): User: "goroutine이 아니라 속성 병렬 처리가 핵심 아니야?" → "맞다, goroutine은 Go 구현체 디테일이고 설계 결정은 속성 병렬 추론이다" → 바로 반영
- Show full text: Always show the complete entry before discussing. Never show fragments
- Guided interview: Ask ONE focused question per turn. With each question, propose 2-3 candidate directions or framings — show the user what strong material looks like and how to frame their experience. Don't just extract raw facts; coach toward a compelling entry
Workflow
digraph resume_forge {
rankdir=TB;
Setup [shape=box, style=filled, fillcolor=lightblue];
Loop1 [shape=box, label="Loop 1: Problem Definition\na2_causal_honesty == PASS", style=filled, fillcolor=lightyellow];
Loop2 [shape=box, label="Loop 2: Entry approved\n(final_verdict APPROVE && 5축 verdict 종합)", style=filled, fillcolor=lightyellow];
Done [shape=box, label="Save + Update State", style=filled, fillcolor=lightgreen];
Setup -> Loop1;
Loop1 -> Loop2 [label="all passed\nor user skip"];
Loop2 -> Done [label="all passed\nor user skip"];
}
Phase 0: Setup
- Load existing state — scan
$OMT_DIR/review-resume/ (drafts/, problem-solving/, forge-references/) and check for prior state in $OMT_DIR/state/resume-forge/. Show the user what already exists. Use existing problem-solving/ entries as dedup and differentiation criteria when proposing new scenarios — never re-propose the same topic; approach similar domains from a different angle
- CRITICAL: Source mining + User interview (ALWAYS, NEVER SKIP) — The user IS a source. Mine from everywhere until good problems emerge:
- Interview the user: Ask about their hardest problems, biggest wins, what kept them up at night. One question per turn — with each question, suggest candidate directions: "이런 포인트가 있으면 차별화될 것 같은데", "이 각도로 풀어내면 강할 것 같아". Dig deep. Follow up. The user's memory is the richest source
- External sources: company Notion (MCP), Jira/Linear, file system docs, Slack threads, past Claude sessions, reference resumes — whatever the user can provide access to
- Iterate: propose candidate problems from what you've gathered, get user feedback, mine more, propose again. This loop continues until enough good problems are found — NOT a one-shot questionnaire
- Save digested analysis to
$OMT_DIR/review-resume/forge-references/. Record filenames in state JSON sources array
- Target count — AskUserQuestion: how many scenarios? (skip if resuming and count already set)
- Create/update session state —
$OMT_DIR/state/resume-forge-{sessionId}.json (see State section)
Phase 1: Loop 1 — Problem Definition
Source mining does NOT stop at Phase 0. If a problem needs more context during Loop 1 or Loop 2, go back to the user, mine more sources, ask deeper questions. Phase 0 is the initial pass — mining continues throughout.
Iterate per scenario:
digraph loop1 {
rankdir=TB;
draft [shape=box, label="Draft problem\n(domain + user input)"];
discuss [shape=box, label="Discuss with user\n(AskUserQuestion)", style=filled, fillcolor=lightyellow];
confirm [shape=box, label="Confirm with user\n(AskUserQuestion:\n이걸로 제출할까?)", style=filled, fillcolor=lightyellow];
exam [shape=box, label="Submit to\ntech-claim-examiner", style=filled, fillcolor=orange];
check [shape=diamond, label="verdicts.a2_causal_honesty\n== PASS?"];
save [shape=box, label="Save to drafts/", style=filled, fillcolor=lightgreen];
feedback [shape=box, label="Show examiner feedback\n+ propose alternatives\n→ re-discuss", style=filled, fillcolor=lightyellow];
draft -> discuss;
discuss -> confirm;
confirm -> exam [label="user: 제출"];
confirm -> discuss [label="user: 아직"];
exam -> check;
check -> save [label="yes"];
check -> feedback [label="no"];
feedback -> discuss;
}
Confirmation Gate — After discussing the problem definition with the user, show the complete draft and ask via AskUserQuestion: "이 문제 정의로 examiner에게 제출할까요?" User responds:
- "제출" / 확인: Proceed to examiner
- "아직": Return to discuss — refine together, then confirm again. This is NOT "다음" (skip). "아직" means "keep improving this scenario"; "다음" means "skip to next scenario"
User says "다음" (next) → skip current scenario, move on. Allowed at any point in both Loop 1 and Loop 2. Skipped scenarios stay in their current location (drafts/ or wherever they are) with state unchanged (pending).
Examiner invocation — tech-claim-examiner subagent_type:
Evaluate the causal honesty of this problem definition.
## Candidate Profile
{user role, experience level, domain}
## Bullet Under Review
{full problem definition + technical challenges}
## Technical Context
{tech stack, system scale, domain background}
Invoke via Agent(subagent_type="tech-claim-examiner", ...). Check verdicts.a2_causal_honesty.verdict in response. PASS = Loop 1 gate cleared.
Phase 2: Loop 2 — Complete Entry
Pick from drafts/ one by one (skip scenarios where loop2.status == "passed"), fill in solution strategy + results.
User says "다음" → skip current scenario (stays in drafts/, state remains pending), move to next.
digraph loop2 {
rankdir=TB;
pick [shape=box, label="Pick a draft"];
interview [shape=box, label="Interview: solution strategy\n(AskUserQuestion)", style=filled, fillcolor=lightyellow];
show [shape=box, label="Show full entry\n(problem+challenge+solution+result)"];
confirm [shape=box, label="Confirm with user\n(AskUserQuestion:\n이 엔트리로 확정할까?)", style=filled, fillcolor=lightyellow];
exam [shape=box, label="Submit to\ntech-claim-examiner\n(full Input Format)", style=filled, fillcolor=orange];
check [shape=diamond, label="Final Verdict\nAPPROVE?"];
save [shape=box, label="Save to\nproblem-solving/", style=filled, fillcolor=lightgreen];
e_fail [shape=box, label="Source extraction:\n{a1/a2/a3/a4} FAIL\nOR structural_verdict+co-failure\n→ interview for depth", style=filled, fillcolor=lightyellow];
r_fail [shape=box, label="Readability-only fix:\nstructural_verdict FAIL alone\n→ propose structure fixes", style=filled, fillcolor=lightyellow];
revise [shape=box, label="Regenerate entry\n+ show to user"];
pick -> interview;
interview -> show;
show -> exam [label="dispatch"];
exam -> check;
check -> confirm [label="APPROVE"];
check -> classify [label="REQUEST_CHANGES"];
confirm -> save [label="user: 확정"];
confirm -> interview [label="user: 아직"];
confirm -> pick [label="user: 다음\n(skip)"];
classify [shape=box, label="Step 1: Classify\n(5축 verdict 패턴)", style=filled, fillcolor=lightyellow];
classify -> r_fail [label="structural_verdict FAIL alone\n(apply immediately)"];
classify -> e_fail [label="{a1/a2/a3/a4} FAIL\nor structural_verdict+co-failure"];
e_fail -> revise;
r_fail -> revise;
revise -> show;
}
Confirmation Gate (post-APPROVE confirm) — After examiner returns final_verdict == APPROVE, ask via AskUserQuestion: "이 엔트리로 확정하시겠습니까?" User responds:
- "확정" / 확인: Save to problem-solving/ and update state
- "아직": Return to interview — dig deeper into solution details, refine the entry, then re-dispatch to examiner. This is NOT "다음" (skip). "아직" means "keep improving this entry"; "다음" means "skip to next scenario"
- "다음": Skip current scenario (stays in drafts/, state remains
pending), move to next
Solution interview protocol:
- One question per turn: Never batch multiple questions. Ask a single focused question, wait for the answer, then follow up
- Suggest directions: With each question, propose 2-3 candidate directions or framings based on what you know. Example: "Saga 패턴으로 명시적으로 구현한 건지, 이벤트 체인 + 수동 보정이었는지가 기술적 깊이를 좌우할 것 같아" — show what strong material looks like
- Real experience validation: if real, dig deep into specifics; if fabricated, validate technical plausibility
- Alternative surfacing: why this approach was chosen and what alternatives were rejected (and why)
- Trade-off extraction: limitations of chosen approach and why they were accepted
Examiner invocation:
Use the rubric's full Input Format. Missing fields cause loose evaluation.
# Technical Evaluation Request
## Candidate Profile
- Experience: {years} years
- Position: {position}
- Target Company/Role: {company} / {role} (if unknown: "No specific target — evaluate against big tech standards")
## Bullet Under Review
- Section: Problem-Solving > {scenario title}
- Original: "{MUST be the full original text from the draft file — never summarize}"
## Technical Context
- Technologies/approaches mentioned in this bullet: {identified directly from bullet text}
- JD-related keywords: {if available from Phase 0 sources, else "N/A"}
- Loop 1 findings: {verdicts.a2_causal_honesty.verdict and any notes from Loop 1}
## Target Company Context
- If known: {company, scale indicators, team size, core values, key challenges}
- If unknown: "No specific target — evaluate against big tech standards"
## Proposed Alternatives (if re-dispatching after feedback)
### Alternative 1: {summary}
{revised text}
### Alternative 2: {summary}
{revised text}
(On first dispatch: "None — initial evaluation of the original entry only.")
MUST send the full original text from the draft file. NEVER summarize, paraphrase, or shorten the entry. Less text → LLM fills gaps with charity → inflated scores. Read the draft file and copy the full content verbatim.
Invoke via Agent(subagent_type="tech-claim-examiner", ...).
Pass criteria — ALL must be met:
final_verdict == APPROVEverdicts.a1_technical_credibility.verdict != FAILverdicts.a2_causal_honesty.verdict != FAILverdicts.a3_outcome_significance.verdict != FAILverdicts.a4_ownership_scope.verdict != FAILcount(P1 across A1-A4) < 3 ← cumulative P1 허용 상한: P1 최대 2개structural_verdict ∈ {PASS, P1}critical_rule_flags.r_phys.triggered == falsecritical_rule_flags.r_cross.triggered == false
(P1 verdicts on any axis do not block APPROVE (subject to the cumulative count(P1) < 3 gate above at L205) but surface in interview_hints. This applies to A1-A4 + structural_verdict uniformly — formerly only A4 emitted P1.)
On APPROVE: Present entry to user via Confirmation Gate (post-APPROVE). On user "확정": Remove from drafts/ → save to problem-solving/. Update state loop2.status to "passed". On user "아직": return to interview for further refinement and re-dispatch.
On REQUEST_CHANGES:
Step 1. Classify Feedback (5축 verdict 패턴)
skills/tech-claim-rubric/output-schema.md §A5 Co-failure Disambiguation Full Routing Matrix를 참조하여 emitted verdicts와 flags 기반으로 routing을 결정한다. 우선순위 순:
- r_phys.triggered == true → Source extraction with impossibility explanation (사용자에게 physically impossible 수치 설명 요청)
- r_cross.triggered == true → Source extraction with contradiction explanation (사용자에게 cross-entry contradiction 설명 요청)
- count(P1 across A1-A4) >= 3 → Source extraction via Step 3 Stages 1-4, starting with the weakest P1 axis (ascending strength order)
- {a1, a2, a3, a4} 중 FAIL 있음 AND structural_verdict ∈ {PASS, P1} → per-axis Stage 1-4 Source extraction (FAIL 축 interview hints 기반 depth 보강)
- {a1, a2, a3, a4} 중 FAIL 있음 AND structural_verdict == FAIL → Stage 5 multi-axis synthesis (co-failure: axis FAIL + structural FAIL 동시 발생)
- structural_verdict == FAIL + {a1, a2, a3, a4} 모두 PASS/P1 + count(P1 across A1-A4) < 3 → Readability-only fix (no interview needed — 재구성·압축만으로 해결)
Readability-only fixes can be applied by rearranging/compressing the same material — apply immediately. Source extraction failures require new depth material — apply the Source Extraction protocol below.
Step 2. Convert Interview Hints → Specific Questions
The examiner provides Interview Hints for each FAIL axis. Do NOT use them verbatim — transform them into questions that include technical context + specific situation + examples:
BAD (abstract):
"Were there any tradeoffs?"
GOOD (specific, with context):
"Redis 도입할 때 cache consistency와 response speed 사이에서 고민한 적 있나요?
예를 들어 cache TTL 기준은 어떻게 정했고, stale data로 문제된 적은?"
Conversion principles:
- Diagnostic context: explain why you are asking this question
- Specific target: target a specific situation/decision/metric, not vague "experience"
- Include examples: help the user recall similar cases
Step 3. Source Extraction (5-Stage)
Progress per axis below PASS (FAIL first, then P1 by ascending strength). One question per turn at each Stage:
| Stage | Trigger | Action |
|---|
| Stage 1 | a1_technical_credibility FAIL or P1 | Named systems / mechanisms 보강: ask specifically about the technical decisions the examiner flagged. If axis-specific questions exhaust without surfacing material → apply Domain-Informed Source Proposal |
| Stage 2 | a2_causal_honesty FAIL or P1 | Causal chain explicit화 + arithmetic 검증: reframe the question from 3 different angles to surface cause-effect logic. If axis-specific questions exhaust without surfacing material → apply Domain-Informed Source Proposal |
| Stage 3 | a3_outcome_significance FAIL or P1 | Tech 또는 business outcome 추가 (vanity metric 회피): ask about adjacent experience or measurable results. If axis-specific questions exhaust without surfacing material → apply Domain-Informed Source Proposal |
| Stage 4 | a4_ownership_scope FAIL or P1 | Verb-scope coherence 보강: probe daily work for hidden ownership evidence, monitoring discoveries, operational context. If axis-specific questions exhaust without surfacing material → apply Domain-Informed Source Proposal |
| Stage 5 | structural_verdict == FAIL + (a1/a2/a3/a4) co-failure | Source extraction 종합 (multi-axis): apply Domain-Informed Source Proposal — AI synthesizes user's domain/stack and proposes scenarios typical for the context |
Source Quality Check:
At each Stage, verify 3 elements whenever the user provides source material:
| Element | Definition | When absent |
|---|
| Fact | What happened | "I have experience" — content unknown → next Stage |
| Context | Why / where / how | Fact alone cannot be shaped into an entry → ask follow-up |
| Verifiability | Metrics, before/after, measurable outcome | Unverifiable → examiner FAIL expected → ask follow-up |
All 3 elements confirmed → reconstruct entry. Any element missing → proceed to next Stage.
Domain-Informed Source Proposal
Applicable at: Stages 1-4 (when axis-specific extraction exhausts without surfacing material) AND Stage 5 (co-failure trigger: structural_verdict == FAIL + at least one of a1/a2/a3/a4 FAIL).
When axis-specific questions fail to surface material, the AI acts as a domain expert and proposes concrete sources:
- Synthesize the user's company scale, domain, tech stack, and the specific FAIL axis
- Propose 2-3 scenarios in the form: "In this context, this problem typically occurs — did you experience something like this?"
- Example: "위탁판매 정산이면 PG 환불 타이밍이랑 정산 주기가 안 맞아서 차액이 생기는 케이스가 많은데, 이런 경험 있나요?"
- Example: "Go로 concurrent processing 하면 goroutine leak이나 channel deadlock이 흔한데, 그런 이슈 겪으셨나요?"
- User confirms → use as new source material → reconstruct entry
- User denies all → build best entry with current sources → final dispatch
Step 4. Reconstruct Entry + Re-dispatch
- Incorporate extracted sources + readability-only fixes into a reconstructed entry
- Cognitive depth check (before final emission): verify that the reconstructed entry surfaces at least one concrete decision point — a rejected alternative, a constraint that forced the approach, or a measurable trade-off. If absent, return to source extraction for the weakest axis below PASS (FAIL first, then P1 by ascending strength) before emitting
- Show full entry to user for visual review (no pre-dispatch confirmation gate — still in REQUEST_CHANGES iteration; post-APPROVE confirm gate applies only after a future APPROVE)
- Re-dispatch to examiner with the revised entry as Proposed Alternative
- Repeat until APPROVE or user opt-out ("다음")
State stays "pending" until APPROVE.
Storage
$OMT_DIR/review-resume/
├── sources/ # review-resume skill: company research, JD analysis (DO NOT USE)
├── forge-references/ # resume-forge: digested work history from Notion, Jira, docs, threads, etc.
│ └── {kebab-case}.md # e.g. mineiss-project-context.md, jira-key-issues.md
├── drafts/ # Loop 1 passed (problem definition only, awaiting Loop 2)
│ └── {kebab-case}.md
├── problem-solving/ # Loop 2 passed (complete entries, note-system compatible)
│ └── {kebab-case}.md
└── ...
Draft file format:
---
tags: [go, kafka, resilience]
---
# Scenario Title
- **sub_title**: ...
- **caption**: Company · YYYY.MM ~ YYYY.MM
- **skills**: ...
**Problem Definition**
...
**Technical Challenges**
...
Complete entry: follows review-resume/references/note-system.md candidate file format (tags frontmatter + body).
Session State
$OMT_DIR/state/resume-forge-{sessionId}.json (session-scoped state file — sessionId from Claude's input.sessionId):
{
"session_id": "abc123-def456",
"created_at": "2026-04-10T12:00:00",
"sources": ["existing-notes", "current-resume"],
"target_count": 9,
"scenarios": [
{
"id": "c1-pipeline-throughput",
"title": "Attribute inference pipeline",
"loop1": { "status": "passed", "verdicts": { "a2_causal_honesty": "PASS" } },
"loop2": { "status": "passed", "final_verdict": "APPROVE" }
},
{
"id": "c2-return-workflow",
"title": "Return workflow automation",
"loop1": { "status": "passed", "verdicts": { "a2_causal_honesty": "PASS" } },
"loop2": { "status": "pending" }
}
]
}
Session Recovery
On new session start:
- List
$OMT_DIR/state/resume-forge-*.json and pick the most recent by created_at field
- Read the state JSON. Skip scenarios where
loop1.status == "passed" (go to Loop 2). Skip scenarios where loop2.status == "passed" (fully complete)
- Scan forge-references/ (if directory exists) —
ls $OMT_DIR/review-resume/forge-references/ → read the first ~10 lines of each file to understand domain/content. Read in full any reference relevant to the current scenario
- If all scenarios have
loop1.status == "passed", skip directly to Phase 2
- Candidate Profile info (user role, experience): ask the user once in Phase 0 setup, or infer from
caption field in drafts
Cleanup
When all scenarios have loop2.status == "passed", delete the state file ($OMT_DIR/state/resume-forge-{sessionId}.json). All data lives in drafts/ and problem-solving/ — the state file is only needed during active forging.
Writing Direction
The examiner's core question: "If I hire this person based on this claim, will they actually deliver?"
Entries that pass share these traits:
- "Why this over alternatives?" — every tech choice has a rejected alternative with a reason
- "What constraints forced this?" — the problem shape dictated the solution, not the other way around
- "What did you give up?" — trade-offs are explicit and accepted with justification
- Cascade discovery — "tried A → discovered constraint → pivoted to B" narrative, not "designed the perfect solution upfront"
- Scale-appropriate — solutions match the actual system scale, not over-engineered for hypothetical load
Entries that fail:
- List technologies without explaining why they were chosen
- Describe the solution without showing the problem's complexity
- Claim results without measurable baselines (before → after)
- Read like architecture decision records instead of problem-solving stories
Anti-Patterns
| Don't | Why |
|---|
| Force structured choices in AskUserQuestion | Users prefer free-form feedback. Closed questions limit discussion |
| Show problem/solution in fragments | Without full context, discussion is inefficient. Always show complete text |
| Blindly accept user opinions | User says "add X" → "좋아 반영할게" → examiner FAIL → wasted cycle. State your assessment first: agree with reasoning, or flag the risk and propose alternatives |
| Judge examiner scoring criteria yourself | Scoring is the examiner's job. This skill only checks pass/fail |
| Request source extraction without identifying which axis failed | A2 FAIL requires causal chain repair; A1 FAIL requires named systems; routing is axis-specific |
| Use technical terms without verification | Outbox, priority queue, etc. — align definitions with user to prevent misunderstanding |
| Batch multiple questions in one turn | Cognitive overload — user answers shallowly or skips hard questions. One focused question + candidate directions per turn |
