| name | portfolio-company |
| effort | high |
| description | Use when someone wants to know which companies or company types their portfolio would appeal to — without a specific JD in hand. Triggers on: "which companies fit my portfolio", "where should I apply", "어느 회사에 잘 맞아?", "네이버 지원하려는데 어때?", "어디 써볼 만해?", |
| scenarios | ["Which Korean tech companies would my portfolio appeal to?","Is my portfolio a good fit for Naver or Kakao?","Tell me where I should be applying based on my portfolio","어느 회사 유형에 내 포트폴리오가 잘 맞는지 분석해줘","네이버 지원하려는데 내 포트폴리오 핏이 어때?"] |
| compatibility | {"recommended":["think-tool"],"optional":["sequential-thinking"],"remote_mcp_note":"think-tool이 있으면 회사 유형별 핏 점수 판단 품질이 높아집니다. Claude 설정 → MCP Servers에서 remote SSE 엔드포인트를 추가하세요."} |
Standing Mandates
- ALWAYS read company signals (engineering blog, job postings, tech stack) before scoring fit.
- ALWAYS distinguish 'can apply here' from 'strong mutual fit here'.
- NEVER recommend applying to a company based solely on name recognition.
- NEVER score fit without knowing the candidate's non-negotiables (location, domain, stack).
Portfolio × Company Fit Analyzer
When to Use / When Not to Use
Use when:
- Deciding where to apply without a specific JD in hand
- Wanting a fit score across multiple company types at once
- Needing honest feedback on where this portfolio would struggle
Not for:
- You have a specific job posting (use portfolio-jd)
- You want to rewrite portfolio sections (use portfolio-rewrite)
- You want overall feedback on portfolio quality (use portfolio-feedback)
Process
- Characterize the portfolio — what type of engineer does it most clearly represent? what are the strongest and weakest signals?
- Plan analysis across company types — identify which types are relevant; what each actually looks for vs. states
- Score each company type — fit score (X/10) + green flags + red flags + one concrete improvement action
- Name Top 2 fits and worst fits — where this portfolio is most and least competitive
- Produce positioning suggestions — if the target isn't the natural fit, what 2-3 changes would move the needle?
Standalone Inputs
Provide: your portfolio (paste or describe key sections), and optionally any specific company names you're considering.
What Claude Does / What You Do
| Claude | You |
|---|
| Characterizes your portfolio type (platform builder, product engineer, etc.) | Decides which companies to target |
| Scores fit across 5 company types with specific evidence | Validates fit signals with network contacts at target companies |
| Names Top 2 best-fit and worst-fit company types | Makes final application decisions |
| Recommends 2-3 portfolio changes to improve fit for a target type | Does the actual relationship building and applying |
Related Skills
../portfolio-jd/SKILL.md — once you've chosen a target, do JD-specific gap analysis../portfolio-rewrite/SKILL.md — improve weak sections after identifying positioning gaps../portfolio-feedback/SKILL.md — overall assessment before company fit analysis
Stage 1 — Characterize the Portfolio (Think Tool)
Before doing any company analysis, call think to build a clear profile of what this portfolio signals:
- What kind of engineer does this portfolio most clearly represent? (platform builder, product engineer, infrastructure specialist, generalist, etc.)
- What is the strongest signal in the portfolio? (scale experience, ownership, depth, breadth, communication quality?)
- What is the weakest or most ambiguous signal?
- What does this portfolio not say — and would a particular company care?
🧠 Fit note: Record the core portfolio profile here. Everything downstream depends on this read.
Stage 2 — Company Type Framework (Sequential Thinking)
Call sequentialthinking to plan the analysis across company types. Think through:
- Which company categories are relevant for a 5+ year Korean backend engineer?
- What does each type actually look for vs. what they say they look for?
- Which types are this portfolio's natural fit vs. a stretch?
Company Type Profiles
Evaluate fit against the following categories. Adjust which ones are included based on what the user asks — don't force irrelevant categories.
대형 플랫폼 (네이버, 카카오, 라인, 쿠팡 등)
What they actually look for:
- System scale experience (millions of users, high QPS, distributed systems)
- Technical depth and ability to own complex infra decisions
- Evidence of working within large engineering organizations (process, code review culture, RFC/design doc experience)
- Stability and reliability focus
Green flags: specific scale numbers, distributed systems experience, performance optimization with before/after metrics
Red flags: only small-scale projects, startup-style "we did everything" without depth, no system design evidence
성장기 스타트업 (Series B–D, 50–300명)
What they actually look for:
- Ownership and initiative beyond assigned tasks
- Ability to make good-enough decisions fast
- Cross-functional collaboration, not just backend silo
- Evidence of building something from scratch or scaling it meaningfully
Green flags: founding engineer experience, greenfield architecture ownership, business impact language
Red flags: only large-company execution work, no initiative signals, heavy process dependency
핀테크 / 엔터프라이즈 (토스, 카카오뱅크, SI 계열 등)
What they actually look for:
- Reliability, compliance awareness, and risk management mindset
- Long-term system maintainability and documentation discipline
- Incident handling and operational maturity
- Consistent track record over flashy projects
Green flags: SLA/SLO experience, incident runbooks, security awareness, payment/financial system experience
Red flags: hype-driven tech choices without rationale, no mention of operational concerns, short tenure on any project
글로벌 테크 (Google, Meta, Amazon, Databricks 등 한국 오피스 또는 해외 지원)
What they actually look for:
- Algorithmic and systems thinking demonstrable beyond the portfolio
- Clear technical communication (design docs, proposals, cross-team alignment)
- Impact at scope (did work affect many users, many teams, or many systems?)
- Leadership even without title
Green flags: technical writing samples, cross-org impact, mentorship, open source contributions
Red flags: no evidence of technical communication, individual-only work, no demonstration of scope beyond own team
개발 도구 / 플랫폼 / 오픈소스 팀
What they actually look for:
- API and developer experience intuition
- Public technical communication (blog, talks, OSS contributions)
- Abstraction and interface design thinking
- Empathy for other engineers as users
Green flags: OSS contributions, technical blog, API design examples, developer tooling work
Red flags: entirely internal product work, no public technical footprint, no developer-facing work experience
Output Structure
Write in Korean. Use this structure:
[이 포트폴리오의 핵심 신호]
In 3–5 sentences: what kind of engineer does this portfolio most clearly represent? This sets the frame for everything below.
[회사 유형별 핏 분석]
For each relevant company type:
[회사 유형명]
- 핏 점수: X/10
- 이 유형에서 강한 이유: [specific evidence from portfolio]
- 이 유형에서 약한 이유: [specific gap or mismatch]
- 지원 전 보완할 것: [one concrete action]
Insert 🧠 Fit note where the fit score required a non-obvious judgment call.
[가장 잘 맞는 회사 유형 Top 2]
Where this portfolio would be most competitive, and why.
[피해야 할 회사 유형]
Where this portfolio would likely struggle — not because the person is unqualified, but because the portfolio doesn't speak that company's language yet.
[포트폴리오 포지셔닝 제안]
If the candidate is targeting a specific company type that isn't their current best fit, what 2–3 changes to the portfolio would move the needle most?
Rules
- Be honest about poor fits. It's more useful than false encouragement.
- Tie every fit judgment to something specific in the portfolio — not general impressions.
- If the user names a specific company, reason about that company's actual engineering culture, not just their reputation.
- Use
think when a fit score is genuinely unclear — especially when portfolio strengths and company expectations only partially overlap.
