Repo To Resume Tailor

Repo to Resume Tailor

Overview

Analyze the repository before writing. Extract only verifiable project facts, then rewrite them into concise, resume-appropriate project descriptions. Optimize for credibility, role relevance, and hiring readability instead of broad repository summarization.

Dynamically adjust extraction and writing priorities based on the user's target role direction or specific job description. For AI or Agent or LLM, AI product, backend, frontend, full-stack, data, algorithm, DevOps, security, testing, and related roles, prioritize the most role-relevant implementation evidence and technical proof from the repository. If a concrete job description is provided, treat its frequent responsibilities, technical keywords, and delivery expectations as the highest priority. If the role name is not directly covered, map it to the nearest role category based on the underlying responsibilities. Do not invent technologies, responsibilities, or outcomes that are not supported by repository evidence in order to improve match quality.

Adjust repository analysis and project phrasing dynamically according to the user's target role direction or specific job description. Do not mechanically list every technology in the repository. Instead, prioritize the abilities, modules, and implementation details that are most relevant to the target role. If the user provides a concrete job description, treat its high-frequency responsibilities, keywords, and technical requirements as the highest priority.

Workflow

1. Clarify the input mode. Use one of these two modes:
   • target-role mode: the user gives a role direction such as backend, AI or agent, data, full-stack, platform, or MLOps
   • JD mode: the user pastes a concrete company job description In target-role mode, prioritize the capability mapping for that role. In JD mode, prioritize the keywords, skills, and responsibilities from the job description.
2. Traverse the repository selectively and prioritize high-signal evidence.
3. Ignore low-value noise aggressively.
4. Build an evidence-backed view of project positioning, tech stack, modules, and delivery form.
5. Rank findings by role fit, not by broad coverage.
6. Write with evidence discipline and conservative wording where needed.

Evidence Priority

• Level 1 evidence: README, architecture or design docs, code comments with intent, API definitions, config files, deployment files, schema definitions
• Level 2 evidence: directory structure, module naming, dependency inference, service boundaries implied by code organization
• Level 3 evidence: reasonable inference from surrounding code

If a claim depends mostly on Level 3 evidence, weaken the wording instead of presenting it as a confirmed fact.

Role Mapping

Use the role mapping reference in role_mapping.md when matching repository evidence to role categories.

• When the role is directly covered, prioritize the mapped capability areas and evidence patterns from that reference.
• When the user provides a concrete job description, use the role mapping as a helper but let repeated job-description responsibilities, keywords, and delivery requirements take highest priority.
• When the role is not directly covered, merge it into the nearest category by underlying responsibilities rather than by title wording.
• For AI product roles, prioritize product problem definition, user scenarios, feature structure, capability boundaries, evaluation loops, and landing strategy over raw infrastructure details. Even if the repository uses RAG, prompts, agent workflows, or orchestration frameworks, explain how those capabilities serve product goals and user experience.
• If the repository mainly proves technical implementation but lacks clear product documents, workflow design, evaluation loops, or productized evidence, do not over-package it as an AI product project.
• Never increase match quality by inventing unsupported technologies, responsibilities, or outcomes.