Update My Resume

Common Contract (Load First)

When this skill is activated, first load skill-common and apply the shared conventions it defines: canonical section order, frontmatter rules, anti-pattern guidance, and the Review In Mind loop in review-in-mind. This skill adds only domain-specific rules below.

Who

Developers or learners who just solved a non-trivial problem or completed a meaningful task and want to capture the demonstrated competency as a verifiable, well-structured resume entry in both English and Chinese.

What

Analyze the current conversation to extract a resume-worthy accomplishment, then write and append a structured entry to both the English and Chinese sections of the user's .resume file. Each entry follows the three-part narrative:

1. WHAT problem was met
2. HOW the user approached it step by step
3. WHAT was gained and evidence that it is useful and repeatable

When

• The user says "update my resume", "add this to my resume", "capture my growth", or "what did I learn today".
• A conversation solved a non-trivial problem that required reasoning, debugging, architecture decisions, or learning a new tool.
• The conversation produced a working, verified solution that could be repeated.
• Do not use this for trivial lookups, one-liner fixes, or routine tasks that any junior developer would handle without thought.
• Do not fabricate accomplishments. Only write what the conversation actually shows.

Where

• Source material: the current conversation and any code, commands, logs, or artifacts it produced.
• Resume file (English): .resume in the project root, or $HOME/.resume if no project-level file exists. Look for an [EN] or [English] section header.
• Resume file (Chinese): the same file, under a [ZH] or [中文] section header. If the file has no ZH section yet, create one at the end.
• If neither location exists, create $HOME/.resume with the minimal structure shown in the Resources section.

Why

• Solving hard problems is valuable, but the value disappears if it is never recorded.
• A resume entry written immediately after the fact is more accurate and more specific than one written from memory weeks later.
• Structured entries (problem → approach → verified outcome) are more convincing to reviewers than vague bullet points.
• Maintaining both EN and ZH versions keeps the record accessible for opportunities in any language context.
• The repeatable-and-useful test forces honest reflection: if the skill cannot be applied again, it may not belong on a resume yet.

Inputs

• The full current conversation (required).
• Code, commands, logs, config snippets, or test results produced during the conversation (optional but strengthens the entry).
• Explicit user feedback on what they consider the most important takeaway (optional).
• Target resume file path override from the user (optional; defaults to project .resume then $HOME/.resume).

Output (Logical Evidence)

• A structured resume entry appended to the English section of the .resume file.
• The same entry, translated and culturally adapted, appended to the Chinese section of the .resume file.
• A brief summary shown to the user: what was appended, where, and why it qualifies.
• A recommendation to skip the update when the conversation does not meet the bar, with a clear reason.

Optimization Readiness

• Failure Signals: The conversation is inflated into a resume entry, the verified outcome is weak or missing, the narrative drops one of the three required parts, or the entry is not clearly repeatable.
• Evidence To Collect: Conversation logs, verification results, drafted resume entries, validator failures (missing fields, out-of-order fields, invalid dates, EN/ZH date imbalance), and examples showing which outcome was strong enough to be reusable.
• Safe Mutation Boundaries: Refine evaluation questions, narrative framing, and bilingual formatting without changing the core problem→approach→outcome structure.
• Acceptance Criteria: Accept revisions only if the entry is grounded in the conversation, includes verification evidence, mirrors the same facts in English and Chinese, and scripts/validate_resume_entry.py exits 0 on the written file.
• Rejected Revision Handling: Record inflated accomplishments, unsupported outcomes, and weak repeatability claims so they are not reused.
• Transfer Check: Verify the workflow still works for debugging sessions, architecture decisions, and other non-trivial solved problems.
• Stop Rule: If the conversation does not clearly meet the bar for a resume entry, stop and skip the update.

Constraints (Logical Boundaries)

• Only record what the conversation actually demonstrates. Do not inflate scope.
• Each entry must include all three parts: the problem, the step-by-step approach, and the verified outcome.
• Keep each entry concise — aim for 3–6 lines per part, enough to be credible but not a narrative essay.
• The Chinese entry is a translation and cultural adaptation, not a separate story. Keep the facts identical.
• Do not overwrite existing resume entries. Always append.
• If the resume file does not exist, create it with the minimal skeleton first, then append.
• Do not share or transmit the resume file contents to any external service.

One More Thing

If anything is unclear, missing, or conflicting — especially which problem to highlight, what the actual verified outcome was, or where the resume file lives — stop and ask the user before writing anything.

How (Structural Workflow)

Phase 1: Locate the Resume File

1. Check for .resume in the current project root.
2. If not found, check $HOME/.resume.
3. If neither exists, ask the user whether to create $HOME/.resume with the minimal skeleton (see Resources).
4. Note the file path and remember it for Phases 4 and 5.

Phase 2: Assess Whether the Conversation Qualifies

1. Review the conversation for evidence of a non-trivial problem that was actually solved.
2. Ask:
   • Was there a clear problem or goal that required more than a one-step answer?
   • Did the solution require reasoning, iteration, or domain knowledge?
   • Is there evidence that the outcome works (test passing, output verified, build succeeding)?
   • Could a similar approach be applied to a future problem?

3. If the answer to any of these is "no" or "unclear", say so and stop:

   "This conversation doesn't clearly meet the bar for a resume entry because [reason]. Consider running this skill again after you have a verified, repeatable outcome."

Phase 3: Extract the Three-Part Narrative

Build the narrative from the conversation:

Part 1 — The Problem (WHAT)

• State the problem or goal concisely. Include the domain, the specific challenge, and why it was non-trivial.
• Example: "Diagnosed a race condition in a Go service where concurrent map writes caused intermittent panics under load."

Part 2 — The Approach (HOW)

• Describe the step-by-step reasoning and actions taken. Include tools, commands, and pivots.
• Keep it ordered: what was tried first, what failed, what worked, and why.
• Example: "Added -race flag to reproduce the panic reproducibly → identified the shared map with go tool pprof → replaced with sync.Map → re-ran load test to confirm zero panics."

Part 3 — The Outcome (WHAT I GOT)

• State what was gained: the fix, the skill, the understanding.
• Include verification evidence: test results, metrics, code diff, or peer review.
• State why it is repeatable: the same pattern applies to [similar future scenario].
• Example: "Eliminated all race-condition panics under 10× normal load. Pattern is reusable for any shared-state concurrent Go service."

Phase 4: Write the English Entry

Format the entry as follows and append it to the English section of the resume file:

--- [YYYY-MM-DD] ---
Problem:  <one-sentence problem statement>
Approach: <ordered steps, separated by " → ">
Outcome:  <result + verification evidence>
Reuse:    <why this skill applies to future situations>

Phase 5: Write the Chinese Entry

Translate and culturally adapt the English entry. Append it to the Chinese ([ZH] / [中文]) section:

--- [YYYY-MM-DD] ---
问题：  <一句话描述问题>
过程：  <有序步骤，用" → "分隔>
收获：  <结果 + 验证证据>
复用性：<为何此技能可应用于未来类似场景>

Keep the facts identical to the English entry. Adapt phrasing to feel natural in Chinese rather than literally translated.

Phase 6: Verify and Report

1. Run the deterministic validator from the repository root:

   python3 update-my-resume/scripts/validate_resume_entry.py --resume <path-to-.resume> --date YYYY-MM-DD

   Do not report success until it exits 0. If it reports FAIL lines, fix the entry and re-run.

2. Read back the appended entries to the user.
3. Confirm the file path where they were written.
4. Ask: "Does this accurately capture what you accomplished? Would you like to adjust any part before we finish?"
5. Apply any requested adjustments, then re-run the validator.

Resources

• Minimal .resume skeleton to create if no file exists:

[EN]
# My Resume

## Experience & Growth Log


[ZH]
# 我的简历

## 成长与经历记录

• Validator script: scripts/validate_resume_entry.py — deterministic checks for section presence and order, entry date validity, field completeness and canonical order, and EN/ZH date pairing. Run it in Phase 6 and in Validation below.
• Related skills:
  • save-as-skill — if the conversation also produced a reusable workflow worth preserving as a skill
  • improve-existing-skill — if an earlier resume entry needs correction after new evidence

Review In Mind (ReviewInMindGenie)

Execute the common review loop in review-in-mind before delivering.

Review lens for this skill:

• Does the entry follow WHAT/HOW/WHAT-was-gained with concrete evidence?
• Is the accomplishment attributable to the user and free of exaggeration?
• Are the English and Chinese sections consistent and formatted per the resume file?
• Does scripts/validate_resume_entry.py exit 0 on the written file?

Validation

1. From the repository root, run:

   python3 update-my-resume/scripts/validate_resume_entry.py --resume <path-to-.resume> --date YYYY-MM-DD

2. The command exits 0 only when all of the following hold:
   • The [EN]/[English] and [ZH]/[中文] sections both exist, in that order.
   • Every entry uses a valid --- [YYYY-MM-DD] --- marker.
   • Every EN entry contains non-empty Problem → Approach → Outcome → Reuse fields in that order.
   • Every ZH entry contains non-empty 问题 → 过程 → 收获 → 复用性 fields in that order.
   • An entry with the given date exists in both sections.
3. Review any WARNING lines (numeric or date-set differences between EN and ZH) and resolve genuine translation drift before delivering.
4. Confirm no existing entries were modified or removed — the validator checks the new entry's structure, not file history, so verify this by reading the file back.
5. Verify the conversation actually supports the claims in the entry — no inflation.