init
This commit is contained in:
redlineo committed
commit
d295c7f139
1527 files changed
+270726
No files matched your search
@@ -0,0 +1,60 @@
|
||||
# Custom Instructions -- career-ops
|
||||
|
||||
<!-- ============================================================
|
||||
THIS FILE IS YOURS. It will NEVER be auto-updated.
|
||||
|
||||
Put your own house rules, custom workflows, and automations
|
||||
here -- anything you want the agent to ALWAYS do (or never do).
|
||||
|
||||
This is for PROCEDURAL rules ("HOW I want things done").
|
||||
For WHO you are (archetypes, narrative, comp, negotiation),
|
||||
use modes/_profile.md instead. Keeping the two separate keeps
|
||||
each one readable.
|
||||
|
||||
The agent reads this file alongside the system instructions;
|
||||
your rules here take precedence over the defaults, as long as
|
||||
they don't break the Data Contract (your files are never
|
||||
touched, and we never auto-submit an application for you).
|
||||
|
||||
Because this is a user-layer file, anything you write here
|
||||
survives `node update-system.mjs`. Put customizations HERE,
|
||||
not in CLAUDE.md / modes/_shared.md / other system files --
|
||||
those get overwritten on update.
|
||||
============================================================ -->
|
||||
|
||||
## House Rules
|
||||
|
||||
<!-- Rules the agent should always follow. Examples:
|
||||
- Always write evaluation summaries in British English.
|
||||
- Never include a photo in my CV (US / ATS-first market).
|
||||
- Cap each batch run at 20 listings unless I say otherwise.
|
||||
- If a report scores below 6, skip the cover letter. -->
|
||||
|
||||
(none yet -- add yours above)
|
||||
|
||||
## Custom Workflows
|
||||
|
||||
<!-- Multi-step routines you run often, given a short name. Examples:
|
||||
- "weekly review": scan my saved portals, evaluate the new roles,
|
||||
then give me a one-paragraph summary of the top 3.
|
||||
- "prep <company>": pull the JD, generate STAR stories from
|
||||
article-digest.md, and draft 5 likely interview questions. -->
|
||||
|
||||
(none yet -- add yours above)
|
||||
|
||||
## Output Preferences
|
||||
|
||||
<!-- How you like results formatted. Examples:
|
||||
- Reports: lead with the score and the one-line verdict.
|
||||
- Show the per-step token breakdown after a batch run.
|
||||
- Save PDFs date-first: YYYY-MM-DD-company.pdf -->
|
||||
|
||||
(none yet -- add yours above)
|
||||
|
||||
## Off-Limits
|
||||
|
||||
<!-- Things the agent must never do for you. Examples:
|
||||
- Never auto-fill or submit an application without showing me first.
|
||||
- Never edit a system file to customize my setup -- put it here. -->
|
||||
|
||||
(none yet -- add yours above)
|
||||
@@ -0,0 +1,60 @@
|
||||
# Custom Instructions -- career-ops
|
||||
|
||||
<!-- ============================================================
|
||||
THIS FILE IS YOURS. It will NEVER be auto-updated.
|
||||
|
||||
Put your own house rules, custom workflows, and automations
|
||||
here -- anything you want the agent to ALWAYS do (or never do).
|
||||
|
||||
This is for PROCEDURAL rules ("HOW I want things done").
|
||||
For WHO you are (archetypes, narrative, comp, negotiation),
|
||||
use modes/_profile.md instead. Keeping the two separate keeps
|
||||
each one readable.
|
||||
|
||||
The agent reads this file alongside the system instructions;
|
||||
your rules here take precedence over the defaults, as long as
|
||||
they don't break the Data Contract (your files are never
|
||||
touched, and we never auto-submit an application for you).
|
||||
|
||||
Because this is a user-layer file, anything you write here
|
||||
survives `node update-system.mjs`. Put customizations HERE,
|
||||
not in CLAUDE.md / modes/_shared.md / other system files --
|
||||
those get overwritten on update.
|
||||
============================================================ -->
|
||||
|
||||
## House Rules
|
||||
|
||||
<!-- Rules the agent should always follow. Examples:
|
||||
- Always write evaluation summaries in British English.
|
||||
- Never include a photo in my CV (US / ATS-first market).
|
||||
- Cap each batch run at 20 listings unless I say otherwise.
|
||||
- If a report scores below 6, skip the cover letter. -->
|
||||
|
||||
(none yet -- add yours above)
|
||||
|
||||
## Custom Workflows
|
||||
|
||||
<!-- Multi-step routines you run often, given a short name. Examples:
|
||||
- "weekly review": scan my saved portals, evaluate the new roles,
|
||||
then give me a one-paragraph summary of the top 3.
|
||||
- "prep <company>": pull the JD, generate STAR stories from
|
||||
article-digest.md, and draft 5 likely interview questions. -->
|
||||
|
||||
(none yet -- add yours above)
|
||||
|
||||
## Output Preferences
|
||||
|
||||
<!-- How you like results formatted. Examples:
|
||||
- Reports: lead with the score and the one-line verdict.
|
||||
- Show the per-step token breakdown after a batch run.
|
||||
- Save PDFs date-first: YYYY-MM-DD-company.pdf -->
|
||||
|
||||
(none yet -- add yours above)
|
||||
|
||||
## Off-Limits
|
||||
|
||||
<!-- Things the agent must never do for you. Examples:
|
||||
- Never auto-fill or submit an application without showing me first.
|
||||
- Never edit a system file to customize my setup -- put it here. -->
|
||||
|
||||
(none yet -- add yours above)
|
||||
@@ -0,0 +1,93 @@
|
||||
# User Profile Context -- career-ops
|
||||
|
||||
<!-- ============================================================
|
||||
THIS FILE IS YOURS. It will NEVER be auto-updated.
|
||||
|
||||
Customize everything here: your archetypes, narrative,
|
||||
proof points, negotiation scripts, location policy.
|
||||
|
||||
The system reads _shared.md (updatable) first, then this
|
||||
file (your overrides). Your customizations always win.
|
||||
============================================================ -->
|
||||
|
||||
## Your Target Roles
|
||||
|
||||
| Archetype | Thematic axes | What they buy |
|
||||
|-----------|---------------|---------------|
|
||||
| **Frontend Developer (Vue.js)** | Vue 3, Composition API, TS, Pinia, component architecture | Someone who ships production Vue with tests and docs |
|
||||
| **Mobile Developer (Flutter)** | Dart, BLoC, clean architecture, cross-platform | Someone who ships and stabilizes a shipping Flutter app |
|
||||
| **Fullstack Developer (Vue + Node.js)** | Vue front + light Node/Express backend | Someone who can bridge frontend and simple backend work |
|
||||
|
||||
## Your Adaptive Framing
|
||||
|
||||
| If the role is... | Emphasize about you... | Proof point sources |
|
||||
|-------------------|------------------------|---------------------|
|
||||
| Frontend (Vue.js) | Vue 3 + Composition API + TS + Pinia production work, RBAC/authorization design, error-preventing UI, unit/e2e test coverage (Vitest, Storybook) | cv.md |
|
||||
| Mobile (Flutter) | "Здесь Аптека" app: new features, refactoring, stability bugfixing, "Избранное" feature with lazy loading | cv.md |
|
||||
| Fullstack (Vue + Node) | Vue frontend + Node/Express/MongoDB exposure (hackathon + TulGU project), WebSocket integration experience | cv.md |
|
||||
|
||||
## Your Exit Narrative
|
||||
|
||||
<!-- Recent-grad narrative, not a career-change story. -->
|
||||
|
||||
Use the candidate's narrative from `config/profile.yml` to frame ALL content:
|
||||
- **In PDF Summaries:** Lead with the Vue 3 + Flutter dual-track production experience, then the info-sec → RBAC angle as the differentiator
|
||||
- **In STAR stories:** Reference proof points from `cv.md` (courier scheduling automation, order management UI, RBAC design, "Избранное" feature)
|
||||
- **In Draft Answers:** Don't frame this as a "career change" — she has no prior unrelated career; frame it as "info-security education gives an unusual edge in authorization/access-control design for a frontend developer"
|
||||
|
||||
## Your Cross-cutting Advantage
|
||||
|
||||
Frame profile as **"Frontend/mobile builder with an information-security lens on access control"** — the RBAC design work at Здравсервис is the standout differentiator versus other frontend candidates at the same level, and should be surfaced whenever a JD mentions permissions, roles, access control, or admin panels.
|
||||
|
||||
Two secondary differentiators, use when relevant:
|
||||
- **De facto product designer in a no-designer team** — self-driven UI redesigns (Favorites button, order info compact layout, app icons for two new internal apps) on top of frontend work. Surface for roles that value design sense or "no dedicated designer" team contexts.
|
||||
- **Backlog/priority advocate** — repeatedly flagged forgotten/lost roadmap priorities, which led leadership to reinstate 6-month/annual goal-setting and got her included in sprint planning with the product owner. Surface for roles that value proactive process ownership, not just execution.
|
||||
|
||||
## Your Portfolio / Demo
|
||||
|
||||
No live public demo, dashboard, or GitHub portfolio yet. Do not fabricate one — omit portfolio/GitHub links from generated content until `config/profile.yml`'s `candidate.github` / `candidate.portfolio_url` are filled in.
|
||||
|
||||
## Your Comp Targets
|
||||
|
||||
**General guidance:**
|
||||
- Target range: 100,000–120,000+ ₽/month net (see `config/profile.yml`)
|
||||
- Use WebSearch for current Russian market data (hh.ru salary stats, Habr Career salary surveys) when benchmarking a specific offer
|
||||
- Frame by role title (Frontend Developer / Vue.js Developer, Middle level), not by raw skill count
|
||||
|
||||
## Your Negotiation Scripts
|
||||
|
||||
**Salary expectations (RU market, informal register is fine):**
|
||||
> "Ориентируюсь на [RANGE из profile.yml] на руки. Открыта к обсуждению структуры (оклад/премии), важен итоговый доход и условия."
|
||||
|
||||
**When offered below target:**
|
||||
> "Смотрю также другие предложения в диапазоне [higher range]. [Company] интересна из-за [reason] — можем обсудить приближение к [target]?"
|
||||
|
||||
**Remote/relocation clarification (important — she does NOT relocate):**
|
||||
> "Готова работать удалённо или гибридно в Туле при дневном графике. Переезд и командировки не рассматриваю."
|
||||
|
||||
## Your Team Vibe / Culture Criteria (secondary signal, not part of the primary score)
|
||||
|
||||
For every evaluation, add a short **"Vibe команды"** comment (at the end of Block A, or Block C when more relevant) assessing qualitative signals from the JD text about team culture:
|
||||
|
||||
- **Живая, активная команда** — упоминания ownership, автономии разработчиков, участия в решениях/RFC/архитектурных обсуждениях, "право голоса"
|
||||
- **Минимум бюрократии** — короткие циклы согласований, плоская иерархия, отсутствие описаний многоступенчатых апрувов
|
||||
- **Менторство и рост** — явные упоминания менторов, code review culture, парного программирования, обучения/сертификаций/конференций, грейдовой сетки роста
|
||||
- **Гибкость** — гибкий график, свобода выбора инструментов/подходов, конкретика по remote-политике (не только слово "удалённо")
|
||||
|
||||
**Правила применения:**
|
||||
- Это качественный комментарий, **не входит в числовую оценку 1-5** — не пересчитывать балл из-за вайба.
|
||||
- Формулировать как инференс из текста JD, а не как факт: "судя по формулировкам JD..." — никогда не утверждать как подтверждённое ("в этой команде точно менторство есть"), если это не прямая цитата из вакансии.
|
||||
- Если сигналов в JD недостаточно — честно писать "недостаточно данных в JD, стоит уточнить на собеседовании", а не выдумывать позитивный вайб.
|
||||
- Не первоочередной критерий: не нужно тратить дополнительный WebSearch на поиск отзывов о культуре компании ради этого пункта — если такие данные уже есть в Блоке D (компенсация/репутация), можно ими дополнить.
|
||||
|
||||
## Your Location Policy
|
||||
|
||||
**In forms:**
|
||||
- Location: Тула, Россия. Remote preferred; hybrid/office in Тула acceptable, day shift only.
|
||||
- **No relocation, no business trips** — state this explicitly whenever a form asks about relocation/travel willingness; never soften this into "flexible."
|
||||
|
||||
**In evaluations (scoring):**
|
||||
- Remote roles: score normally (5.0 if fully remote-friendly)
|
||||
- Hybrid/office roles located in Тула: score normally
|
||||
- Hybrid/office roles requiring relocation outside Тула, or requiring business travel: score **1.0** — this is a hard constraint, not a soft preference
|
||||
- On-site-only roles outside Тула with no remote option: score **1.0**
|
||||
@@ -0,0 +1,102 @@
|
||||
# User Profile Context -- career-ops
|
||||
|
||||
<!-- ============================================================
|
||||
THIS FILE IS YOURS. It will NEVER be auto-updated.
|
||||
|
||||
Customize everything here: your archetypes, narrative,
|
||||
proof points, negotiation scripts, location policy.
|
||||
|
||||
The system reads _shared.md (updatable) first, then this
|
||||
file (your overrides). Your customizations always win.
|
||||
============================================================ -->
|
||||
|
||||
## Your Target Roles
|
||||
|
||||
<!-- Replace these with YOUR target roles. Examples:
|
||||
- Senior Backend Engineer / Staff Platform Engineer
|
||||
- AI Product Manager / Technical PM
|
||||
- Data Engineer / ML Engineer
|
||||
- DevOps / SRE / Platform
|
||||
Whatever you're optimizing for. -->
|
||||
|
||||
| Archetype | Thematic axes | What they buy |
|
||||
|-----------|---------------|---------------|
|
||||
| **AI Platform / LLMOps Engineer** | Evaluation, observability, reliability, pipelines | Someone who puts AI in production with metrics |
|
||||
| **Agentic Workflows / Automation** | HITL, tooling, orchestration, multi-agent | Someone who builds reliable agent systems |
|
||||
| **Technical AI Product Manager** | GenAI/Agents, PRDs, discovery, delivery | Someone who translates business to AI product |
|
||||
| **AI Solutions Architect** | Hyperautomation, enterprise, integrations | Someone who designs end-to-end AI architectures |
|
||||
| **AI Forward Deployed Engineer** | Client-facing, fast delivery, prototyping | Someone who delivers AI solutions to clients fast |
|
||||
| **AI Transformation Lead** | Change management, adoption, org enablement | Someone who leads AI transformation in an org |
|
||||
|
||||
## Your Adaptive Framing
|
||||
|
||||
<!-- Map YOUR projects to each archetype. Example:
|
||||
| Platform / LLMOps | My monitoring dashboard project | article-digest.md |
|
||||
| Agentic | My chatbot with HITL escalation | cv.md section 3 | -->
|
||||
|
||||
| If the role is... | Emphasize about you... | Proof point sources |
|
||||
|-------------------|------------------------|---------------------|
|
||||
| Platform / LLMOps | Production systems builder, observability, evals | article-digest.md + cv.md |
|
||||
| Agentic / Automation | Multi-agent orchestration, HITL, reliability | article-digest.md + cv.md |
|
||||
| Technical AI PM | Product discovery, PRDs, metrics | cv.md + article-digest.md |
|
||||
| Solutions Architect | System design, integrations, enterprise-ready | article-digest.md + cv.md |
|
||||
| Forward Deployed Engineer | Fast delivery, client-facing, prototype to prod | cv.md + article-digest.md |
|
||||
| AI Transformation Lead | Change management, team enablement, adoption | cv.md + article-digest.md |
|
||||
|
||||
## Your Exit Narrative
|
||||
|
||||
<!-- Replace with YOUR story. This frames everything. -->
|
||||
|
||||
Use the candidate's exit story from `config/profile.yml` to frame ALL content:
|
||||
- **In PDF Summaries:** Bridge from past to future
|
||||
- **In STAR stories:** Reference proof points from article-digest.md
|
||||
- **In Draft Answers:** The transition narrative appears in the first response
|
||||
|
||||
## Your Cross-cutting Advantage
|
||||
|
||||
<!-- What's your "signature move"? What do you do that others can't? -->
|
||||
|
||||
Frame profile as **"Technical builder with real-world proof"** that adapts framing to the role.
|
||||
|
||||
## Your Portfolio / Demo
|
||||
|
||||
<!-- If you have a live demo, dashboard, or public project:
|
||||
url: https://yoursite.dev/demo
|
||||
password: demo-2026
|
||||
when_to_share: "LLMOps, AI Platform roles" -->
|
||||
|
||||
If you have a live demo/dashboard (check profile.yml), offer access in applications for relevant roles.
|
||||
|
||||
## Your Comp Targets
|
||||
|
||||
<!-- Research comp ranges for YOUR target roles -->
|
||||
|
||||
**General guidance:**
|
||||
- Use WebSearch for current market data (Glassdoor, Levels.fyi, Blind)
|
||||
- Frame by role title, not by skills
|
||||
- Contractor rates are typically 30-50% higher than employee base
|
||||
|
||||
## Your Negotiation Scripts
|
||||
|
||||
<!-- Adapt to YOUR situation, currency, location -->
|
||||
|
||||
**Salary expectations:**
|
||||
> "Based on market data for this role, I'm targeting [RANGE from profile.yml]. I'm flexible on structure -- what matters is the total package and the opportunity."
|
||||
|
||||
**Geographic discount pushback:**
|
||||
> "The roles I'm competitive for are output-based, not location-based. My track record doesn't change based on postal code."
|
||||
|
||||
**When offered below target:**
|
||||
> "I'm comparing with opportunities in the [higher range]. I'm drawn to [company] because of [reason]. Can we explore [target]?"
|
||||
|
||||
## Your Location Policy
|
||||
|
||||
<!-- Adapt to YOUR situation -->
|
||||
|
||||
**In forms:**
|
||||
- Follow your actual availability from profile.yml
|
||||
- Specify timezone overlap in free-text fields
|
||||
|
||||
**In evaluations (scoring):**
|
||||
- Remote dimension for hybrid outside your country: score **3.0** (not 1.0)
|
||||
- Only score 1.0 if JD says "must be on-site 4-5 days/week, no exceptions"
|
||||
@@ -0,0 +1,272 @@
|
||||
# System Context -- career-ops
|
||||
|
||||
<!-- ============================================================
|
||||
THIS FILE IS AUTO-UPDATABLE. Don't put personal data here.
|
||||
|
||||
Your customizations go in modes/_profile.md (never auto-updated).
|
||||
This file contains system rules, scoring logic, and tool config
|
||||
that improve with each career-ops release.
|
||||
============================================================ -->
|
||||
|
||||
## Sources of Truth (EXCLUSIVE)
|
||||
|
||||
The files below are the **ONLY** sources for user-facing content (CV, cover letters, form answers, recruiter outreach). Auto-memory, parent-directory repos, and cross-session inferences are out of scope. See "Source-of-Truth Boundary" in `AGENTS.md` / `CLAUDE.md` / `CODEX.md` for the full rule.
|
||||
|
||||
| File | Path | When |
|
||||
|------|------|------|
|
||||
| cv.md | `cv.md` (project root) | ALWAYS |
|
||||
| article-digest.md | `article-digest.md` (if exists) | ALWAYS (detailed proof points) |
|
||||
| profile.yml | `config/profile.yml` | ALWAYS (candidate identity and targets) |
|
||||
| _profile.md | `modes/_profile.md` | ALWAYS (user archetypes, narrative, negotiation) |
|
||||
| writing-samples/ | `writing-samples/` | When generating candidate-facing text — check `_profile.md` for cached `## Writing Style` first; only scan files if absent |
|
||||
| voice-dna.md | `voice-dna.md` (project root, if exists) | When generating candidate-facing text. Anti-AI-slop guardrail + voice. See Voice DNA precedence below. |
|
||||
| interview-prep | `interview-prep/story-bank.md`, `interview-prep/{company}-{role}.md` | When generating ATS form answers / interview content — the user's own STAR stories + prep notes (same trust as cv.md). Consumed by `apply`/`match-star` + interview modes |
|
||||
|
||||
**RULE: NEVER hardcode metrics from proof points.** Read them from cv.md + article-digest.md at evaluation time.
|
||||
**RULE: For article/project metrics, article-digest.md takes precedence over cv.md.**
|
||||
**RULE: Read _profile.md AFTER this file. User customizations in _profile.md override defaults here.**
|
||||
**RULE: NEVER claim the user authored a project, repo, library, tool, framework, or open-source artefact unless explicitly attributed to them in cv.md or article-digest.md.** Tool-of-trade conflation (user uses X → user built X) is the most common fabrication pattern and is forbidden.
|
||||
**RULE: Keywords get reformulated, never fabricated.** Reorder, reframe, emphasise — but never invent. If a claim isn't backed by an in-scope file, ask the user. If no answer, omit. Silence on a topic beats manufactured detail.
|
||||
|
||||
---
|
||||
|
||||
## Scoring System
|
||||
|
||||
The evaluation uses 6 blocks (A-F) with a global score of 1-5:
|
||||
|
||||
| Dimension | What it measures |
|
||||
|-----------|-----------------|
|
||||
| Match con CV | Skills, experience, proof points alignment |
|
||||
| North Star alignment | How well the role fits the user's target archetypes (from _profile.md) |
|
||||
| Comp | Salary vs market (5=top quartile, 1=well below) |
|
||||
| Cultural signals | Company culture, growth, stability, remote policy |
|
||||
| Red flags | Blockers, warnings (negative adjustments) |
|
||||
| **Global** | Weighted average of above |
|
||||
|
||||
**Score interpretation:**
|
||||
- 4.5+ → Strong match, recommend applying immediately
|
||||
- 4.0-4.4 → Good match, worth applying
|
||||
- 3.5-3.9 → Decent but not ideal, apply only if specific reason
|
||||
- Below 3.5 → Recommend against applying (see Ethical Use in AGENTS.md)
|
||||
|
||||
## Posting Legitimacy (Block G)
|
||||
|
||||
Block G assesses whether a posting is likely a real, active opening. It does NOT affect the 1-5 global score -- it is a separate qualitative assessment.
|
||||
|
||||
**Three tiers:**
|
||||
- **High Confidence** -- Real, active opening (most signals positive)
|
||||
- **Proceed with Caution** -- Mixed signals, worth noting (some concerns)
|
||||
- **Suspicious** -- Multiple ghost indicators, user should investigate first
|
||||
|
||||
**Key signals (weighted by reliability):**
|
||||
|
||||
| Signal | Source | Reliability | Notes |
|
||||
|--------|--------|-------------|-------|
|
||||
| Posting age | Page snapshot | High | Under 30d=good, 30-60d=mixed, 60d+=concerning (adjusted for role type) |
|
||||
| Apply button active | Page snapshot | High | Direct observable fact |
|
||||
| Tech specificity in JD | JD text | Medium | Generic JDs correlate with ghost postings but also with poor writing |
|
||||
| Requirements realism | JD text | Medium | Contradictions are a strong signal, vagueness is weaker |
|
||||
| Recent layoff news | WebSearch | Medium | Must consider department, timing, and company size |
|
||||
| Reposting pattern | scan-history.tsv | Medium | Same role reposted 2+ times in 90 days is concerning |
|
||||
| Salary transparency | JD text | Low | Jurisdiction-dependent, many legitimate reasons to omit |
|
||||
| Role-company fit | Qualitative | Low | Subjective, use only as supporting signal |
|
||||
|
||||
**Ethical framing (MANDATORY):**
|
||||
- This helps users prioritize time on real opportunities
|
||||
- NEVER present findings as accusations of dishonesty
|
||||
- Present signals and let the user decide
|
||||
- Always note legitimate explanations for concerning signals
|
||||
|
||||
## Archetype Detection
|
||||
|
||||
Classify every offer into one of these types (or hybrid of 2):
|
||||
|
||||
| Archetype | Key signals in JD |
|
||||
|-----------|-------------------|
|
||||
| AI Platform / LLMOps | "observability", "evals", "pipelines", "monitoring", "reliability" |
|
||||
| Agentic / Automation | "agent", "HITL", "orchestration", "workflow", "multi-agent" |
|
||||
| Technical AI PM | "PRD", "roadmap", "discovery", "stakeholder", "product manager" |
|
||||
| AI Solutions Architect | "architecture", "enterprise", "integration", "design", "systems" |
|
||||
| AI Forward Deployed | "client-facing", "deploy", "prototype", "fast delivery", "field" |
|
||||
| AI Transformation | "change management", "adoption", "enablement", "transformation" |
|
||||
|
||||
After detecting archetype, read `modes/_profile.md` for the user's specific framing and proof points for that archetype.
|
||||
|
||||
## Global Rules
|
||||
|
||||
### NEVER
|
||||
|
||||
1. Invent experience or metrics
|
||||
2. Modify cv.md or portfolio files
|
||||
3. Submit applications on behalf of the candidate
|
||||
4. Share phone number in generated messages
|
||||
5. Recommend comp below market rate
|
||||
6. Generate a PDF without reading the JD first
|
||||
7. Use corporate-speak
|
||||
8. Ignore the tracker (every evaluated offer gets registered)
|
||||
9. Spawn nested subagents, or hand company/role/comp research to an open-ended research skill — research is bounded and inline (see Tools → Subagent delegation)
|
||||
|
||||
### ALWAYS
|
||||
|
||||
0. **Cover letter:** If the form allows it, ALWAYS include one. Same visual design as CV. JD quotes mapped to proof points. 1 page max.
|
||||
1. Read cv.md, _profile.md, and article-digest.md (if exists) before evaluating
|
||||
1b. **First evaluation of each session:** Run `node cv-sync-check.mjs`. If warnings, notify user.
|
||||
2. Detect the role archetype and adapt framing per _profile.md
|
||||
3. Cite exact lines from CV when matching
|
||||
4. Use WebSearch for comp and company data
|
||||
5. Register in tracker after evaluating
|
||||
6. Generate content in the language of the JD (EN default)
|
||||
7. Be direct and actionable -- no fluff
|
||||
8. Native tech English for generated text. Short sentences, action verbs, no passive voice.
|
||||
8b. Case study URLs in PDF Professional Summary (recruiter may only read this).
|
||||
9. **Tracker additions as TSV** -- NEVER edit applications.md directly. Write TSV in `batch/tracker-additions/`.
|
||||
10. **Include `**URL:**` in every report header.**
|
||||
|
||||
### Tools
|
||||
|
||||
| Tool | Use |
|
||||
|------|-----|
|
||||
| WebSearch | Comp research, trends, company culture, LinkedIn contacts, fallback for JDs |
|
||||
| WebFetch | Fallback for extracting JDs from static pages |
|
||||
| Playwright | Verify offers (browser_navigate + browser_snapshot). **NEVER 2+ agents with Playwright in parallel.** |
|
||||
| Read | cv.md, _profile.md, article-digest.md, cv-template.html |
|
||||
| Write | Temporary HTML for PDF, applications.md, reports .md |
|
||||
| Edit | Update tracker |
|
||||
| Canva MCP | Optional visual CV generation. Duplicate base design, edit text, export PDF. Requires `cv.canva_resume_design_id` in profile.yml. |
|
||||
| Bash | `node generate-pdf.mjs` |
|
||||
|
||||
### Subagent delegation (cost guardrail)
|
||||
|
||||
A mode may tell you to run work in a background subagent (e.g. `scan`, or parallel `pipeline` URLs) to spare the main agent's context. Any subagent you spawn for career-ops is a **single-pass worker**:
|
||||
|
||||
- It MUST NOT spawn further subagents, and MUST NOT invoke other skills — especially open-ended or recursive research skills (e.g. a `deep-research` skill). Those fan out into nested agents and can burn tens of millions of tokens on one run.
|
||||
- Company, role, and compensation research is ALWAYS done **inline**, with the small explicit set of WebSearch/WebFetch queries the mode names (e.g. `oferta` Blocks C/D) — never delegated to a recursive research harness.
|
||||
- One `/career-ops <JD>` evaluates one role; it must never explode into a self-replicating swarm of agents. If you are about to delegate research or nest agents, stop and do it inline, bounded.
|
||||
|
||||
### Time-to-offer priority
|
||||
- Working demo + metrics > perfection
|
||||
- Apply sooner > learn more
|
||||
- 80/20 approach, timebox everything
|
||||
|
||||
---
|
||||
|
||||
## Voice DNA (writing guardrail)
|
||||
|
||||
If `voice-dna.md` exists in the project root, it is a writing guardrail for generated prose. It is user-layer and optional — never assume it exists, and skip this block silently if it doesn't. It layers **under** the user's personal style: it catches AI-slop and fills gaps, but it always defers to the user's own voice rules in `_profile.md` (see Precedence below).
|
||||
|
||||
**Two-tier scope (this is what keeps CVs accurate):**
|
||||
|
||||
- **Tier 1 — anti-AI-slop guardrail** (voice-dna §3 Banned List, §4 Patterns to Avoid: banned words, dead phrases, no em-dashes, no negative parallelisms, formatting rules). These are HARD RULES. They apply to **all** generated text, including CV bullets and the Professional Summary.
|
||||
- **Tier 2 — conversational voice** (voice-dna §1-2: contractions, And/But sentence openers, hedging like "I think"/"maybe", parenthetical asides, direct "I"/"you"). Apply **only** to conversational candidate-facing prose: cover letters, LinkedIn outreach, follow-up emails. **Do NOT apply Tier 2 to CV/ATS text** (PDF bullets, Professional Summary) — those keep the formal, keyword-dense register in the ATS Rules below.
|
||||
|
||||
**Accuracy always wins over style.** Facts from `cv.md` and `article-digest.md` are never overridden by voice-dna. Never drop, soften, or hedge a real metric to improve rhythm. Never invent detail to sound more human. Voice-dna shapes wording; it never changes content.
|
||||
|
||||
**Precedence with personal style (`_profile.md` always wins):** The user's `## Writing Style` in `_profile.md` is the authority on voice and tone. Where `voice-dna.md` and `_profile.md` conflict, `_profile.md` wins — voice-dna never overrides a rule the user set for themselves. Example: if the user's `_profile.md` style uses em-dashes, keep them, even though voice-dna discourages them. voice-dna's anti-AI-slop rules apply only where `_profile.md` is silent. (`voice-dna.md` is itself a user file, so a user who wants the strict guardrail to win can simply leave that preference out of `_profile.md`.)
|
||||
|
||||
---
|
||||
|
||||
## Writing Style Calibration
|
||||
|
||||
**Check `_profile.md` first.** If a `## Writing Style` section exists there, use it directly — do not re-scan the writing-samples files. Re-scanning is only needed when new samples are added or the user explicitly asks to recalibrate.
|
||||
|
||||
**When to apply:** Before generating any text the user will send or publish — cover letters, LinkedIn outreach, application form answers, follow-up emails, executive summaries, profile blurbs. Does NOT apply to internal evaluation reports (A–F blocks, scores, analysis).
|
||||
|
||||
**If no cached style in `_profile.md`:** Read all files in `writing-samples/`, **skipping any file named `README.md`**. If no user-provided samples are found, skip style calibration and gently note — once, without pressure — that adding a writing sample (e.g. a past cover letter, a LinkedIn About section, any professional writing) would help tailor outputs to their voice. If samples exist, extract the markers below and write the result to `_profile.md` under `## Writing Style` so future sessions skip this step.
|
||||
|
||||
### What to extract
|
||||
|
||||
**Tone & register**
|
||||
- Formal vs. conversational
|
||||
- Confident vs. hedging (watch for qualifiers like "I think", "perhaps", "somewhat")
|
||||
- Warm vs. transactional
|
||||
- Degree of self-promotion — does the user undersell, match, or lead with achievements?
|
||||
|
||||
**Sentence structure**
|
||||
- Average sentence length — short and punchy or long and layered?
|
||||
- Use of fragments for emphasis
|
||||
- Clause nesting and complexity
|
||||
- How sentences open — subject-first, action-first, context-first?
|
||||
|
||||
**Punctuation habits**
|
||||
- Em dashes, en dashes, or parentheses for asides?
|
||||
- Oxford comma or not?
|
||||
- Ellipses — used or avoided?
|
||||
- Exclamation marks — never, sparingly, or freely?
|
||||
- Semicolons vs. full stops to join related ideas
|
||||
|
||||
**Vocabulary**
|
||||
- Technical density — how much jargon per paragraph?
|
||||
- Preferred synonyms (e.g. "built" vs. "developed" vs. "engineered")
|
||||
- Words or phrases the user reaches for repeatedly — keep them
|
||||
- Words that never appear — don't introduce them
|
||||
|
||||
**Paragraph and structure patterns**
|
||||
- Paragraph length — one-liners or developed blocks?
|
||||
- Bullet-heavy or prose-heavy?
|
||||
- How ideas are sequenced — problem → solution, result-first, chronological?
|
||||
- Use of headers within longer pieces
|
||||
|
||||
**Voice signatures**
|
||||
- First-person patterns — "I led", "we built", "our team"?
|
||||
- Active vs. passive ratio
|
||||
- Habitual openers and closers
|
||||
- Rhetorical moves — does the user ask questions, use contrast, tell micro-stories?
|
||||
|
||||
### Rules
|
||||
|
||||
- **Only extract what is demonstrably present.** Do not infer style from a single data point.
|
||||
- **Idiosyncratic choices are intentional.** Unconventional punctuation or phrasing is the user's voice — preserve it, do not correct it.
|
||||
- **If samples conflict**, weight the most recent or most similar-context file.
|
||||
- **If samples are sparse**, apply what can be reliably extracted and fall back to defaults for the rest.
|
||||
- **Style calibration applies to tone and structure only.** Do not import content, claims, or metrics from samples into CVs, reports, or evaluations.
|
||||
- **No verbatim copying or personal identifiers.** Store only abstract style descriptors (tone, structure, vocabulary preferences). Do not quote user sentences verbatim and do not retain personal identifiers (names, emails, phone numbers) from writing samples. "Preserve idiosyncratic choices" applies to stylistic traits only.
|
||||
|
||||
### Persisting the extracted style
|
||||
|
||||
After scanning (excluding any `README.md` files), write to `modes/_profile.md` only if at least one user-provided sample was found: find the existing `## Writing Style` section and replace the entire block up to the next `##` heading (or EOF) with the new content. If no `## Writing Style` section exists, append it. This ensures there is always exactly one canonical section. If no samples were found after filtering, do not write or modify the section.
|
||||
|
||||
```markdown
|
||||
## Writing Style
|
||||
|
||||
_Extracted from writing-samples/ on {date}. Re-run if new samples are added._
|
||||
|
||||
**Tone:** {e.g. conversational, confident, no hedging qualifiers}
|
||||
**Sentence length:** {e.g. short and punchy, avg 12 words}
|
||||
**Openings:** {e.g. action-first, subject-first}
|
||||
**Punctuation:** {e.g. em dashes for asides, Oxford comma, no ellipses}
|
||||
**Vocabulary:** {e.g. prefers "built"/"ran"/"cut" over "developed"/"led"/"reduced"}
|
||||
**Structure:** {e.g. prose-heavy, result-first sequencing}
|
||||
**Voice:** {e.g. "I led", active voice dominant, no rhetorical questions}
|
||||
**Avoid:** {words or patterns absent from samples}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Professional Writing & ATS Compatibility
|
||||
|
||||
These rules apply to ALL generated text that ends up in candidate-facing documents: PDF summaries, bullets, cover letters, form answers, LinkedIn messages. They do NOT apply to internal evaluation reports.
|
||||
|
||||
For recruiter-side risk mapping, six-second clarity, business-value bullets, and ATS reality checks, read `modes/heuristics/recruiter-side.md`.
|
||||
|
||||
### Avoid cliché phrases
|
||||
_If `voice-dna.md` exists, its §3 Banned List is the canonical, fuller version of this list and takes precedence. The list below is the fallback for users without that file._
|
||||
- "passionate about" / "results-oriented" / "proven track record"
|
||||
- "leveraged" (use "used" or name the tool)
|
||||
- "spearheaded" (use "led" or "ran")
|
||||
- "facilitated" (use "ran" or "set up")
|
||||
- "synergies" / "robust" / "seamless" / "cutting-edge" / "innovative"
|
||||
- "in today's fast-paced world"
|
||||
- "demonstrated ability to" / "best practices" (name the practice)
|
||||
|
||||
### Unicode normalization for ATS
|
||||
`generate-pdf.mjs` automatically normalizes em-dashes, smart quotes, and zero-width characters to ASCII equivalents for maximum ATS compatibility. But avoid generating them in the first place.
|
||||
|
||||
### Vary sentence structure
|
||||
- Don't start every bullet with the same verb
|
||||
- Mix sentence lengths (short. Then longer with context. Short again.)
|
||||
- Don't always use "X, Y, and Z" — sometimes two items, sometimes four
|
||||
|
||||
### Prefer specifics over abstractions
|
||||
- "Cut p95 latency from 2.1s to 380ms" beats "improved performance"
|
||||
- "Postgres + pgvector for retrieval over 12k docs" beats "designed scalable RAG architecture"
|
||||
- Name tools, projects, and customers when allowed
|
||||
+107
@@ -0,0 +1,107 @@
|
||||
# Mode: add — Add a project, paper, or role to your CV
|
||||
|
||||
Fetch a finished project / paper / internship from a link (or plain text), turn
|
||||
it into ATS-style CV content **grounded only in what the source actually says**,
|
||||
preview it, and — after you confirm — append it to `cv.md` and (for projects)
|
||||
`article-digest.md`. Deterministic dedup and insertion are handled by
|
||||
`add-entry.mjs`, so re-adding the same thing is a safe no-op.
|
||||
|
||||
> **Non-negotiables (from the project's source-of-truth rules in `_shared.md`):**
|
||||
> - **Confirm before write.** Never touch `cv.md` / `article-digest.md` until the
|
||||
> user approves the preview.
|
||||
> - **Never fabricate.** Every bullet, metric, and date must be backed by the
|
||||
> fetched page or the user's own words. If the source doesn't state it, it does
|
||||
> not go in. Keywords get reformulated, never invented.
|
||||
> - **Zero-key, local.** Use only public, no-auth fetches (GitHub's public API,
|
||||
> WebFetch). No API keys, no third-party services.
|
||||
|
||||
## Input
|
||||
|
||||
`$mode` after `add` is the source. Accept any of:
|
||||
- a **GitHub repo URL** (`github.com/<owner>/<repo>`)
|
||||
- a **paper / publication link** (arXiv, DOI, journal, personal page)
|
||||
- a **project / portfolio page URL**
|
||||
- **plain text** the user pastes describing the work
|
||||
|
||||
If no source was given, ask the user for one.
|
||||
|
||||
## Pipeline
|
||||
|
||||
1. **Load context.** Read `cv.md` (its existing section names and formatting are
|
||||
the template to match) and `article-digest.md` if present.
|
||||
2. **Fetch the source (zero-key):**
|
||||
- **GitHub repo** → the public REST API (`https://api.github.com/repos/<owner>/<repo>`
|
||||
for name/description/topics/language/stars/timestamps) **plus** the README
|
||||
via WebFetch. No token required for public repos.
|
||||
- **Any other link** → WebFetch. Only fall back to Playwright if the page is
|
||||
JS-rendered and WebFetch returns nothing useful.
|
||||
- **Plain text** → use it directly as the source; do not invent beyond it.
|
||||
3. **Extract structured facts** actually present in the source: name, dates /
|
||||
period, tech stack, role, and concrete outcomes/metrics. Leave anything the
|
||||
source doesn't state **blank** — do not guess.
|
||||
4. **Classify the entry type → target CV section** (see table). Placement is
|
||||
inferred, but shown in the preview; only ask the user when it's genuinely
|
||||
ambiguous.
|
||||
5. **Write ATS bullets from the extracted facts** — 2–4 concise, quantified-where-the-
|
||||
source-supports-it bullets, matching the bullet style already used in `cv.md`.
|
||||
For a **project**, also compose an `article-digest.md` block (`## <Name> — <tagline>`
|
||||
with `**Hero metrics:**`, `**Architecture:**`, `**Key decisions:**`,
|
||||
`**Proof points:**`), filling only what the source supports.
|
||||
6. **Preview.** Show, as a diff-style preview: the inferred CV section, the exact
|
||||
markdown to be inserted into `cv.md`, and (for projects) the `article-digest.md`
|
||||
block. Flag anything you could not source.
|
||||
7. **Confirm gate.** Ask the user to approve, edit, or cancel. Do **not** proceed
|
||||
without an explicit yes.
|
||||
8. **Write via the helper.** Build the payload (schema below), write it to
|
||||
`/tmp/add-<slug>.json`, then run:
|
||||
|
||||
```bash
|
||||
node add-entry.mjs /tmp/add-<slug>.json
|
||||
```
|
||||
|
||||
(Add `--dry-run` first if the user wants to see the file-level change without
|
||||
writing.)
|
||||
9. **Report** the helper's JSON result. If a target comes back `duplicate`, tell
|
||||
the user it was already present and nothing was changed.
|
||||
|
||||
## Section inference
|
||||
|
||||
| Source is… | CV section |
|
||||
|------------|------------|
|
||||
| a code project / repo / tool | `Projects` |
|
||||
| a paper / publication / preprint | `Publications` (create if absent) |
|
||||
| an internship / job / role | `Work Experience` |
|
||||
| a talk / course / certification | `Education` (or ask if unclear) |
|
||||
|
||||
`add-entry.mjs` creates the section heading if it doesn't exist yet, so a new
|
||||
`## Publications` is fine.
|
||||
|
||||
## Payload schema (input to `add-entry.mjs`)
|
||||
|
||||
Both keys optional; provide at least one. `articleDigest` is for projects only.
|
||||
|
||||
```json
|
||||
{
|
||||
"cv": {
|
||||
"section": "Projects",
|
||||
"dedupKey": "<short canonical name, e.g. the repo/project name>",
|
||||
"entry": "<exact markdown to insert — a bullet for Projects, or a\n### Org — Location / **Title** / dates / bullets block for Work Experience>"
|
||||
},
|
||||
"articleDigest": {
|
||||
"dedupKey": "<same canonical name>",
|
||||
"entry": "## <Name> — <tagline>\n\n**Hero metrics:** ...\n\n**Architecture:** ...\n\n**Key decisions:**\n- ...\n\n**Proof points:**\n- ..."
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
`dedupKey` is normalized (case- and punctuation-insensitive) to detect an entry
|
||||
that's already there, so the command is idempotent.
|
||||
|
||||
## Rules
|
||||
|
||||
- Match the existing `cv.md` formatting exactly (heading levels, bullet style,
|
||||
date format) — the file is the template.
|
||||
- One entry per run. To add several, run `add` per item.
|
||||
- If the fetch fails or the page has no usable content, say so and stop — never
|
||||
synthesize an entry from nothing.
|
||||
- Personal data (the CV itself) stays local; the fetch only reads public sources.
|
||||
@@ -0,0 +1,50 @@
|
||||
# Mode: agent-inbox — Queue requests for the next session
|
||||
|
||||
A durable bridge between *looking at* the pipeline and *acting on* it. career-ops
|
||||
runs from an AI session, but there's no place to drop a request when you're not
|
||||
in one. The agent inbox is that place: an append-only checklist
|
||||
(`data/agent-inbox.md`) that any tool — this CLI, a dashboard button, a cron job,
|
||||
or you by hand — can append to, and that the agent drains at the start of a
|
||||
session.
|
||||
|
||||
Local-first, human-in-the-loop, zero dependencies: **nothing here auto-submits.**
|
||||
Queued items are *intents* for the agent to action and the user to review.
|
||||
|
||||
## Queue a request
|
||||
|
||||
```bash
|
||||
node agent-inbox.mjs add "evaluate https://acme.com/jobs/42"
|
||||
node agent-inbox.mjs add "draft a follow-up for application #7"
|
||||
node agent-inbox.mjs add "run a scan and triage anything new"
|
||||
```
|
||||
|
||||
## Inspect / resolve
|
||||
|
||||
```bash
|
||||
node agent-inbox.mjs list # pending items
|
||||
node agent-inbox.mjs list --all # include resolved items
|
||||
node agent-inbox.mjs resolve 1 --result "scored 4.3 — report 012"
|
||||
```
|
||||
|
||||
`data/agent-inbox.md` is user-layer (gitignored). Items look like:
|
||||
|
||||
```markdown
|
||||
- [ ] 2026-06-21 09:30 — evaluate https://acme.com/jobs/42
|
||||
- [x] 2026-06-20 18:05 — run a scan → result: 3 new, 1 worth evaluating
|
||||
```
|
||||
|
||||
## Agent protocol (when the user invokes this mode, or at session start)
|
||||
|
||||
1. Read `data/agent-inbox.md`. If it doesn't exist or has no unchecked items,
|
||||
say so and stop.
|
||||
2. Run each **unchecked** item top-to-bottom by routing it to the right mode
|
||||
(a URL → `auto-pipeline`; "follow-up" → `followup`; "scan" → `scan`; etc.).
|
||||
3. After each, mark it `[x]` and append `→ result: <one line>` — either by hand
|
||||
or with `node agent-inbox.mjs resolve <n> --result "..."`.
|
||||
4. Items that need **live user input** (a mock interview, a pasted transcript, a
|
||||
decision, anything that would submit an application) → do **not** run them;
|
||||
ask the user to start them instead. The inbox never bypasses human review.
|
||||
|
||||
This mode pairs naturally with a dashboard: a "queue this" button writes to the
|
||||
same file, so a click while browsing the tracker becomes work the next session
|
||||
picks up.
|
||||
+213
@@ -0,0 +1,213 @@
|
||||
# Mode: apply — Live Application Assistant
|
||||
|
||||
> Apply `voice-dna.md` (if present) to free-text answers and cover-letter fields — full guardrail, conversational voice included (Tier 1 + Tier 2). See `_shared.md` → Voice DNA.
|
||||
|
||||
Interactive mode for when the candidate is filling out an application form in Chrome. It reads what is on the screen, loads the previous context of the job, and generates personalized responses for each form question.
|
||||
|
||||
## Requirements
|
||||
|
||||
- **Best with Playwright in visible mode**: In visible mode, the candidate sees the browser and the agent can interact with the page.
|
||||
- **Without Playwright**: the candidate shares a screenshot or pastes the questions manually.
|
||||
|
||||
## Workflow
|
||||
|
||||
```text
|
||||
1. DETECT → Read active Chrome tab (screenshot/URL/title)
|
||||
2. IDENTIFY → Extract company + role from the page
|
||||
3. SEARCH → Match against existing reports in reports/
|
||||
4. LOAD → Read full report + Section H / Application Answers (if they exist)
|
||||
5. PREFLIGHT → Confirm posting liveness + company/role match before drafting
|
||||
5b. PRE-SCAN → Scan page for knock-out questions (degree, experience, work authorization/visa, sponsorship, salary floors)
|
||||
6. ANALYZE → Identify ALL visible form questions
|
||||
7. GENERATE → For each question, generate a personalized response
|
||||
8. PRESENT → Show formatted responses for copy-paste
|
||||
9. PERSIST → Save the final filled/submitted answers into the report
|
||||
```
|
||||
|
||||
## Step 5 — Preflight gate
|
||||
|
||||
Before generating any application answers, verify that the form still points to the intended active job. This gate runs after the page has been detected, the company/role has been identified, and the matching report has been loaded.
|
||||
|
||||
1. Read the visible URL, page title, company, role, and any closed/expired signals.
|
||||
2. If a URL is available, verify liveness with Playwright:
|
||||
- active posting evidence: title/role + job description or form fields + submit/apply path
|
||||
- closed posting evidence: expired/closed/no longer accepting applications, missing JD with only nav/footer, hard redirect to generic careers/search, or 404/410
|
||||
3. Compare the visible company and role against the matched report.
|
||||
4. If company or title changed materially, stop before drafting and ask:
|
||||
"The form appears to be for [visible company] — [visible role], but the matched report is [report company] — [report role]. Do you want me to re-evaluate, adapt with this mismatch, or stop?"
|
||||
5. If the posting appears closed, refuse to generate final copy unless the candidate explicitly overrides with a known reason.
|
||||
6. If liveness cannot be verified because the candidate only pasted questions or a screenshot, state that limitation and ask the candidate to confirm the company, role, and active posting before drafting.
|
||||
|
||||
Do not continue to Step 6 until this preflight is resolved.
|
||||
|
||||
## Step 5b — Pre-scan for knock-out questions
|
||||
|
||||
Read the entire page/form to scan for knock-out questions BEFORE generating full responses. These are questions designed to automatically disqualify candidates who do not meet critical criteria.
|
||||
|
||||
1. Common knock-out question areas to target:
|
||||
- **Minimum years of experience** (e.g., "Do you have at least 5 years of professional software engineering experience?")
|
||||
- **Degree requirements** (e.g., "Do you have a Bachelor's degree in Computer Science or a related field?")
|
||||
- **Work authorization/Visa sponsorship** (e.g., "Will you now or in the future require visa sponsorship to work in the United States?")
|
||||
- **Salary floors/expectations** (e.g., "What is your target salary / expectation?")
|
||||
2. Check these questions against the candidate's `config/profile.yml` or `cv.md` parameters.
|
||||
3. If a knock-out question is detected where the candidate's profile represents a potential mismatch (e.g., candidate needs sponsorship and the form automatically filters out sponsorship-needy applicants, or candidate's salary expectations mismatch the visible JD/form floors):
|
||||
- Highlight the specific knock-out question to the candidate immediately.
|
||||
- Present a clear warning block:
|
||||
`⚠️ KNOCK-OUT WARNING: The form asks "[question text]". Based on your profile/CV, answering "[profile answer]" may trigger immediate automatic rejection by the ATS. How would you like to answer this, or do you want to skip applying?`
|
||||
- Stop and wait for the candidate's confirmation before drafting any further answers.
|
||||
4. If no knock-out questions are found, or the candidate resolves the warning, proceed to Step 6.
|
||||
|
||||
**Applying to several roles in one sitting?** This preflight verifies the single form in front of you. Before a multi-role session — especially against scanner entries marked `**Verification:** unconfirmed (batch mode)` — run the `pipeline` mode **Liveness sweep** first (`node check-liveness.mjs --file <urls>`). It drops the dead postings from `data/pipeline.md` in one batch so you never open a tab on an expired role.
|
||||
|
||||
## Step 1 — Detect the job
|
||||
|
||||
**With Playwright:** Take a snapshot of the active page. Read title, URL, and visible content.
|
||||
|
||||
**Without Playwright:** Ask the candidate to:
|
||||
- Share a screenshot of the form (Read tool can read images)
|
||||
- Or paste the form questions as text
|
||||
- Or say company + role so we can search for it
|
||||
|
||||
## Step 2 — Identify and search for context
|
||||
|
||||
1. Extract company name and role title from the page
|
||||
2. Search in `reports/` by company name (case-insensitive grep)
|
||||
3. If there is a match → load the full report
|
||||
4. If there is a Section H or `## Application Answers` → load previous answers as a base
|
||||
5. If there is NO match → notify and offer to run a quick auto-pipeline
|
||||
|
||||
## Step 3 — Detect changes in the role
|
||||
|
||||
If the role on screen differs from the one evaluated:
|
||||
- **Notify the candidate**: "The role has changed from [X] to [Y]. Do you want me to re-evaluate or adapt the responses to the new title?"
|
||||
- **If adapt**: Adjust responses to the new role without re-evaluating, only after the candidate explicitly accepts the mismatch
|
||||
- **If re-evaluate**: Execute full A-F evaluation, update report, regenerate Section H
|
||||
- **Update tracker**: Change role title in applications.md if applicable
|
||||
|
||||
## Step 6 — Analyze form questions
|
||||
|
||||
Identify ALL visible questions:
|
||||
- Free text fields (cover letter, why this role, etc.)
|
||||
- Dropdowns (how did you hear, work authorization, etc.)
|
||||
- Yes/No (relocation, visa, etc.)
|
||||
- Salary fields (range, expectation)
|
||||
- Upload fields (resume, cover letter PDF)
|
||||
|
||||
Classify each question:
|
||||
- **Already answered in Section H or `## Application Answers`** → adapt the existing response
|
||||
- **New question** → generate response from the report + cv.md
|
||||
|
||||
For each field, preserve the application form contract:
|
||||
- `field_type`: `text`, `textarea`, `select`, `radio`, `checkbox`, `number`, `file`, or `unknown`
|
||||
- `required`: `yes`, `no`, or `unknown`
|
||||
- `limit`: exact character/word limit if visible; otherwise `unknown`
|
||||
- `options`: visible options for select/radio/checkbox fields
|
||||
- `needs_candidate_confirmation`: `yes` for legal, demographic, work authorization, visa, relocation, salary, disability, veteran, sponsorship, background-check, or self-identification questions unless the answer is explicitly present in `config/profile.yml`
|
||||
|
||||
Never invent answers for legal, demographic, work-authorization, visa/sponsorship, salary, disability, veteran, background-check, relocation, or self-identification fields. If the answer is not present in `config/profile.yml` or visible context, mark it as needing candidate confirmation and provide the safest question to ask the candidate.
|
||||
|
||||
|
||||
## Step 7 — Generate responses
|
||||
|
||||
For each question, generate the response following:
|
||||
|
||||
1. **Report context**: Use proof points from block B, STAR stories from block F
|
||||
2. **Previous Section H / Application Answers**: If a draft or final response exists, use it as a base and refine
|
||||
3. **"I'm choosing you" tone**: Same auto-pipeline framework
|
||||
4. **Specificity**: Reference something specific from the JD visible on screen
|
||||
5. **career-ops proof point**: Include in "Additional info" if there is a field for it
|
||||
6. **Recruiter-side risk map**: Use `modes/heuristics/recruiter-side.md` to identify what doubt the question is trying to resolve (motivation, stack fit, logistics, comp, work-auth, availability, seniority) and answer that doubt directly.
|
||||
7. **Disclosure discipline**: Answer logistics questions truthfully when asked, but do not volunteer sensitive or HR-only details in unrelated motivation/fit answers.
|
||||
|
||||
**Output format:**
|
||||
|
||||
```text
|
||||
## Responses for [Company] — [Role]
|
||||
|
||||
Based on: Report #NNN | Score: X.X/5 | Archetype: [type]
|
||||
|
||||
---
|
||||
|
||||
### 1. [Exact form question]
|
||||
> [Response ready for copy-paste, or "Ask candidate: ..." if the field needs confirmation]
|
||||
|
||||
### 2. [Next question]
|
||||
> [Response]
|
||||
|
||||
...
|
||||
|
||||
---
|
||||
|
||||
Notes:
|
||||
- [Any observations about the role, changes, etc.]
|
||||
- [Personalization suggestions the candidate should review]
|
||||
```
|
||||
|
||||
## Step 8 — Persist application snapshot
|
||||
|
||||
After the final answers are filled into the form or handed to the candidate for copy-paste, update the matched report with an additive `## Application Answers` section. If the candidate later confirms submission, update that same section from `filled` to `submitted`.
|
||||
|
||||
The section must include:
|
||||
- `**Date:** YYYY-MM-DD`
|
||||
- `**State:** filled` or `**State:** submitted`
|
||||
- Free-text answers exactly as submitted
|
||||
- Dropdown/radio/checkbox selections made
|
||||
- Number or short-answer fields such as compensation, availability, start date, and work authorization
|
||||
- Files used, including CV, cover letter, portfolio, or other uploads with version/path when known
|
||||
|
||||
Write the section at the end of the report, or replace only the existing `## Application Answers` section if it already exists. Do not rename, reorder, or edit the existing A-H report blocks or `## Keywords extracted`.
|
||||
|
||||
Use `application-answers.mjs` when possible to format/upsert the section:
|
||||
|
||||
```bash
|
||||
node application-answers.mjs --report reports/NNN-company-role-date.md --input answers.json --state filled
|
||||
```
|
||||
|
||||
## Step 9 — Post-apply (optional)
|
||||
|
||||
If the candidate confirms that they submitted the application:
|
||||
1. Update status in `applications.md` from "Evaluated" to "Applied"
|
||||
2. Seed the follow-up schedule: run `node followup-seed.mjs {num} --json` (where `{num}` is the tracker row number). If the candidate applied on a different day than today, pass `--date YYYY-MM-DD` with the actual submission date. It's idempotent, so re-running is safe.
|
||||
3. Refresh the report's `## Application Answers` section with the final field values and `**State:** submitted`
|
||||
4. Suggest next step: run the `contacto` mode (`/career-ops contacto` where available) for LinkedIn outreach
|
||||
|
||||
## Scroll handling
|
||||
|
||||
If the form has more questions than the visible ones:
|
||||
- Ask the candidate to scroll and share another screenshot
|
||||
- Or paste the remaining questions
|
||||
- Process in iterations until the entire form is covered
|
||||
|
||||
## Known ATS Quirks
|
||||
|
||||
Field-tested across ~12 Playwright-driven applications (Ashby, Greenhouse, Lever, Workable). These quirks silently break an apply run if not accounted for.
|
||||
|
||||
### Ashby — email-based candidate dedup
|
||||
|
||||
- **Symptom:** Submitting a second application at the same company silently fails or merges into the existing candidate record. Ashby deduplicates by email per company.
|
||||
- **Agent:** Before filling the email field, check whether an earlier report for the same company already exists in `reports/`. If it does, warn the candidate and pre-fill a `+tag` alias (e.g., `user+teamname@domain.com`) as the suggested value.
|
||||
- **Candidate:** Confirms or changes the email before the form is submitted.
|
||||
|
||||
### Lever — hCaptcha intercepts checkbox/radio clicks
|
||||
|
||||
- **Symptom:** Programmatic `click()` on checkboxes or radio buttons triggers an hCaptcha challenge mid-form, blocking the rest of the fill.
|
||||
- **Agent:** Fill `<input type="text">`, `<textarea>`, and `<select>` fields only. Skip all checkboxes, radio buttons, and the captcha widget. List the skipped fields with their recommended values so the candidate can tick them.
|
||||
- **Candidate:** Completes the checkboxes, solves the captcha, and clicks Submit.
|
||||
|
||||
### Workable — SPA re-renders break form refs
|
||||
|
||||
- **Symptom:** Workable's SPA re-renders form components between fills, invalidating element references. Sequential `fill()` calls hit stale-element errors.
|
||||
- **Agent:** Copy each answer to the clipboard and present a numbered paste list. If Playwright is active, dispatch `Ctrl+V` per field with a fresh element query before each paste — do not cache refs across fields.
|
||||
- **Candidate:** Pastes remaining answers manually if clipboard dispatch fails, then submits.
|
||||
|
||||
### React-select autocomplete widgets
|
||||
|
||||
- **Symptom:** `react-select` (common in Greenhouse, Ashby, Lever for location/department fields) destroys and recreates its internal DOM on every keystroke. Cached refs go stale instantly.
|
||||
- **Agent:** Type character-by-character with short delays (~100 ms). Re-snapshot after every selection to pick up the new DOM state. Never cache element references across interactions.
|
||||
- **Candidate:** Verifies each selected value is correct before moving on; corrects any mis-selection inline.
|
||||
|
||||
### Huge native `<select>` elements (1 000+ options)
|
||||
|
||||
- **Symptom:** Country, university, or field-of-study dropdowns contain thousands of `<option>` entries. Snapshotting them floods context and stalls the agent.
|
||||
- **Agent:** Use `select_option` directly by value or visible label. Never snapshot the full option list. If the exact label is unknown, ask the candidate for the value instead of dumping options into context.
|
||||
- **Candidate:** Provides the correct label when the agent cannot infer it from `config/profile.yml`.
|
||||
@@ -0,0 +1,110 @@
|
||||
# Career-Ops -- الأنماط واللغة العربية (`modes/ar/`)
|
||||
|
||||
يحتوي هذا المجلد على الترجمة العربية الكاملة للأنماط (modes) الأساسية لنظام career-ops، والمصممة خصيصاً للمرشحين والمطورين في العالم العربي والشرق الأوسط، أو الذين يتقدمون لوظائف تتطلب التواصل باللغة العربية.
|
||||
|
||||
## متى يُستخدم هذا النمط؟
|
||||
|
||||
استخدم `modes/ar/` إذا تحقق شرط واحد على الأقل من الشروط التالية:
|
||||
|
||||
- تتقدم بشكل أساسي إلى **فرص عمل مكتوبة باللغة العربية** (منصات مثل LinkedIn في العالم العربي، وظائف، بيت.كوم، إلخ).
|
||||
- ترغب في أن تكون **سيرتك الذاتية باللغة العربية** أو تريد التنقل بين العربية والإنجليزية حسب لغة الإعلان.
|
||||
- تحتاج إلى صياغة خطابات تغطية (Cover Letters) ورسائل تواصل احترافية **بلغة عربية تقنية طبيعية وسلسة**، بعيدة تماماً عن الترجمة الآلية الركيكة.
|
||||
- تحتاج إلى التعامل مع **الميزات التعاقدية والتنظيمية في قوانين العمل العربية**: مثل مكافأة نهاية الخدمة، التأمينات الاجتماعية، الراتب الإجمالي والصافي، فترة التجربة، مهلة الإخطار، البدلات (السكن، الانتقال، الطعام)، والتأمين الصحي.
|
||||
|
||||
إذا كانت معظم الفرص التي تتقدم إليها باللغة الإنجليزية، فاستمر في استخدام الأنماط القياسية في مجلد `modes/`.
|
||||
|
||||
## كيفية التفعيل؟
|
||||
|
||||
### الخيار 1 -- أثناء الجلسة (مؤقتاً)
|
||||
|
||||
أخبر الوكيل (Claude أو Gemini) في بداية المحادثة:
|
||||
|
||||
> "استخدم الأنماط العربية الموجودة في مجلد `modes/ar/`."
|
||||
|
||||
سيقوم الوكيل بقراءة ملفات هذا المجلد بدلاً من المجلد القياسي `modes/`.
|
||||
|
||||
### الخيار 2 -- بشكل دائم عبر الإعدادات
|
||||
|
||||
أضف السطور التالية إلى ملف الإعدادات `config/profile.yml`:
|
||||
|
||||
```yaml
|
||||
language:
|
||||
primary: ar
|
||||
modes_dir: modes/ar
|
||||
```
|
||||
|
||||
ثم ذكّر الوكيل بذلك في أول محادثة ("انظر في ملف `profile.yml` لقد قمت بتعيين `language.modes_dir`"). سيستخدم النظام الأنماط العربية تلقائياً.
|
||||
|
||||
---
|
||||
|
||||
## الأنماط المترجمة
|
||||
|
||||
تغطي هذه الترجمة الأنماط الأربعة الأكثر أهمية وتأثيراً في عملية البحث:
|
||||
|
||||
| الملف | الأصل المترجم منه | دور الملف |
|
||||
|:---|:---|:---|
|
||||
| `_shared.md` | `modes/_shared.md` (EN) | السياق المشترك، الأنماط الوظيفية (Archetypes)، القواعد العامة، والمصطلحات القانونية العربية |
|
||||
| `fursah.md` | `modes/oferta.md` (ES) | التقييم الشامل والعميق لإعلان الوظيفة (الكتل A-G) |
|
||||
| `takdeem.md` | `modes/apply.md` (EN) | المساعد الفوري لكتابة الردود أثناء تعبئة نماذج طلب التوظيف |
|
||||
| `pipeline.md` | `modes/pipeline.md` (ES) | إدارة روابط الفرص المجمعة ومعالجتها |
|
||||
|
||||
تبقى الملفات الأخرى باللغة الإنجليزية نظراً لاعتمادها بشكل أساسي على الأدوات وسطور الأوامر البرمجية التي يجب أن تظل مستقلة عن اللغة.
|
||||
|
||||
---
|
||||
|
||||
## المصطلحات التقنية والتعريب
|
||||
|
||||
تم الإبقاء على بعض المصطلحات التقنية الشائعة باللغة الإنجليزية عمداً لضمان التوافق مع الأنظمة التقنية وثقافة العمل في الشركات الحديثة:
|
||||
|
||||
- `cv.md` و `pipeline` و `tracker` و `report` و `score` و `archetype` و `proof point`.
|
||||
- أسماء الأدوات البرمجية (`Playwright` و `WebSearch` و `WebFetch` و `Read` و `Write` و `Edit` و `Bash`).
|
||||
- حالات الطلبات في جدول التتبع (`Evaluated` و `Applied` و `Interview` و `Offer` و `Rejected` و `Discarded`).
|
||||
- مسارات الملفات، الأوامر البرمجية، وقطع الشفرة المصدرية.
|
||||
|
||||
تستخدم هذه الأنماط لغة عربية مهنية مرنة: تُكتب النصوص والشروحات بلغة عربية فصحى راقية، مع استخدام المصطلحات التقنية الإنجليزية الشائعة في بيئة العمل التقنية (مثل استخدام Backend و Frontend و RAG و Pipelines كما هي متداولة في أوساط المطورين).
|
||||
|
||||
---
|
||||
|
||||
## دليل المصطلحات المرجعي
|
||||
|
||||
لضمان الاتساق اللغوي عند كتابة أو تعديل الأنماط:
|
||||
|
||||
| المصطلح الإنجليزي | المقابل باللغة العربية (في هذا المشروع) |
|
||||
|:---|:---|
|
||||
| Job posting / vacancy | فرصة عمل / إعلان وظيفة |
|
||||
| Application | طلب توظيف / تقديم |
|
||||
| Cover letter | خطاب تغطية / رسالة تعريفية |
|
||||
| Resume / CV | سيرة ذاتية |
|
||||
| Salary | راتب / أجر |
|
||||
| Compensation | تعويضات / الحزمة المالية |
|
||||
| Skills | مهارات |
|
||||
| Interview | مقابلة شخصية / مقابلة عمل |
|
||||
| Hiring manager | مدير التوظيف |
|
||||
| Recruiter | مسؤول توظيف |
|
||||
| Requirements | متطلبات |
|
||||
| Career history | التاريخ المهني / الخبرات المهنية |
|
||||
| Notice period | فترة الإخطار / مهلة الاستقالة |
|
||||
| Probation period | فترة التجربة / فترة الاختبار |
|
||||
| Annual leave | إجازة سنوية |
|
||||
| Severance pay | مكافأة نهاية الخدمة |
|
||||
| Gross / Net salary | راتب إجمالي / راتب صافي |
|
||||
| Social security | التأمينات الاجتماعية |
|
||||
| Permanent contract | عقد غير محدد المدة / عقد دائم |
|
||||
| Fixed-term contract | عقد محدد المدة |
|
||||
| Remote / Hybrid | عمل عن بعد / عمل هجين |
|
||||
| Meal allowance | بدل طعام |
|
||||
| Health insurance | تأمين صحي |
|
||||
| Transportation allowance| بدل انتقال / مواصلات |
|
||||
| Inflation adjustment | علاوة تضخم / تعديل سنوي |
|
||||
|
||||
---
|
||||
|
||||
## المساهمة والتطوير
|
||||
|
||||
لتعديل أو إضافة تحسينات على الترجمة العربية:
|
||||
|
||||
1. افتح تذكرة (Issue) تشرح فيها اقتراحك وفقاً لملف `CONTRIBUTING.md`.
|
||||
2. التزم بجدول المصطلحات المذكور أعلاه لضمان اتساق الصياغة.
|
||||
3. اكتب بلغة عربية طبيعية وسلسة، وتجنب تماماً الترجمة الحرفية الجافة.
|
||||
4. حافظ على العناصر الهيكلية البرمجية (الكتل A-G، الجداول، أكواد التوثيق، وأوامر الأدوات) كما هي تماماً.
|
||||
5. اختبر الترجمة مع إعلان وظيفة حقيقي مكتوب بالعربية قبل تقديم طلب الدمج (PR).
|
||||
@@ -0,0 +1,184 @@
|
||||
# سياق النظام المشترك -- career-ops
|
||||
|
||||
<!-- ============================================================
|
||||
هذا الملف قابل للتحديث التلقائي. لا تضع بياناتك الشخصية هنا.
|
||||
|
||||
تخصيصاتك الشخصية توضع في ملف modes/_profile.md (الذي لا يتم تحديثه تلقائياً).
|
||||
يحتوي هذا الملف على القواعد المشتركة، منطق التقييم، وتكوينات الأدوات
|
||||
التي يتم تحسينها مع كل إصدار جديد من career-ops.
|
||||
============================================================ -->
|
||||
|
||||
## مصادر الحقيقة (Sources of Truth)
|
||||
|
||||
| الملف | المسار | متى يتم الرجوع إليه |
|
||||
|:---|:---|:---|
|
||||
| cv.md | `cv.md` (جذر المشروع) | دائماً |
|
||||
| article-digest.md | `article-digest.md` (إذا وُجد) | دائماً (نقاط إثبات تفصيلية) |
|
||||
| profile.yml | `config/profile.yml` | دائماً (هوية المتقدم للوظيفة والأهداف) |
|
||||
| _profile.md | `modes/_profile.md` | دائماً (الأنماط الوظيفية المخصصة للمستخدم، السرد، والتفاوض) |
|
||||
| writing-samples/ | `writing-samples/` | عند إنشاء نصوص موجهة للمستخدم — افحص `_profile.md` أولاً بحثاً عن `## Writing Style` المخزن؛ لا تقم بمسح الملفات إلا إذا كان غائباً |
|
||||
|
||||
**قاعدة: لا تقم أبداً بكتابة أرقام ونسب الإنجازات (metrics) بشكل ثابت. اقرأها دائماً من ملف cv.md و article-digest.md وقت التقييم.**
|
||||
**قاعدة: بالنسبة للمشاريع والمقالات، يكون لملف article-digest.md الأولوية على cv.md.**
|
||||
**قاعدة: اقرأ ملف _profile.md بعد قراءة هذا الملف. إعدادات وتخصيصات المستخدم في _profile.md تلغي وتتفوق على الإعدادات الافتراضية هنا.**
|
||||
|
||||
---
|
||||
|
||||
## نظام التقييم (Scoring System)
|
||||
|
||||
يستخدم التقييم 6 كتل أساسية (A-F) مع درجة تقييم إجمالية تتراوح من 1 إلى 5:
|
||||
|
||||
| البعد | ما يقيسه |
|
||||
|:---|:---|
|
||||
| Match con CV (المطابقة مع السيرة الذاتية) | توافق المهارات والخبرات ونقاط الإثبات |
|
||||
| North Star alignment (المحاذاة مع الهدف الأساسي) | مدى ملاءمة الوظيفة للأنماط الوظيفية المستهدفة (من ملف _profile.md) |
|
||||
| Comp (الحزمة المالية والراتب) | الراتب مقارنة بالسوق (5 = الربع الأعلى، 1 = أقل بكثير من متوسط السوق) |
|
||||
| Cultural signals (الإشارات الثقافية) | ثقافة الشركة، نموها، استقرارها، وسياسة العمل عن بعد |
|
||||
| Red flags (الإشارات الحمراء التحذيرية) | العوائق والمحاذير (تؤدي إلى تعديلات سلبية للدرجة) |
|
||||
| **Global (التقييم الإجمالي)** | المتوسط الموزون للأبعاد المذكورة أعلاه |
|
||||
|
||||
**تفسير الدرجات:**
|
||||
- **4.5+** ← توافق ممتاز وقوي جداً، ينصح بالتقديم فوراً.
|
||||
- **4.0 - 4.4** ← توافق جيد جداً، تستحق عناء التقديم.
|
||||
- **3.5 - 3.9** ← توافق مقبول ولكن ليس مثالياً، قدم فقط إذا كان هناك سبب محدد.
|
||||
- **أقل من 3.5** ← ينصح بعدم التقديم (راجع قواعد الاستخدام الأخلاقي في AGENTS.md).
|
||||
|
||||
---
|
||||
|
||||
## مصداقية وجودة الإعلان (Block G — Posting Legitimacy)
|
||||
|
||||
تقوم الكتلة G بتقييم مدى جدية وحيوية الوظيفة المعلن عنها للتأكد من أنها فرصة حقيقية وليست وظيفة وهمية أو منتهية. **هذا التقييم نوعي ومنفصل، ولا يؤثر على التقييم الإجمالي (1-5).**
|
||||
|
||||
**ثلاثة مستويات للمصداقية:**
|
||||
- **High Confidence (ثقة عالية)** -- فرصة عمل حقيقية ونشطة (أغلب الإشارات إيجابية).
|
||||
- **Proceed with Caution (تقدم بحذر)** -- إشارات مختلطة تستدعي الانتباه.
|
||||
- **Suspicious (مشبوهة)** -- مؤشرات متعددة على وظيفة وهمية، يجب على المستخدم التحقق بنفسه أولاً.
|
||||
|
||||
**الإشارات الأساسية (مرتبة حسب الموثوقية):**
|
||||
|
||||
| الإشارة | المصدر | درجة الموثوقية | ملاحظات |
|
||||
|:---|:---|:---|:---|
|
||||
| عمر الإعلان (Posting age) | لقطة الصفحة (snapshot) | عالية | أقل من 30 يوماً = ممتاز، 30-60 يوماً = مختلط، 60+ = مقلق (يعدل حسب نوع الوظيفة) |
|
||||
| زر التقديم نشط | لقطة الصفحة (snapshot) | عالية | واقعة مباشرة قابلة للملاحظة |
|
||||
| التحديد التقني في الوصف | نص الإعلان (JD) | متوسطة | الإعلانات العامة ترتبط بالوظائف الوهمية أو رداءة الصياغة |
|
||||
| واقعية المتطلبات | نص الإعلان (JD) | متوسطة | التعارضات الصارخة إشارة قوية، والعمومية إشارة أضعف |
|
||||
| أخبار تسريح الموظفين مؤخراً | WebSearch | متوسطة | يجب النظر في القسم المعني، التوقيت، وحجم الشركة |
|
||||
| نمط إعادة النشر | scan-history.tsv | متوسطة | تكرار نشر نفس الوظيفة مرتين أو أكثر في 90 يوماً أمر يدعو للقلق |
|
||||
| شفافية الرواتب | نص الإعلان (JD) | منخفضة | تعتمد على الولاية القضائية، هناك أسباب مشروعة كثيرة لعدم الإفصاح |
|
||||
| ملاءمة الوظيفة للشركة | تقييم نوعي | منخفضة | تقييم شخصي ذاتي، يستخدم كإشارة داعمة فقط |
|
||||
|
||||
**الإطار الأخلاقي والإرشادي (إلزامي):**
|
||||
- الهدف هو مساعدة المستخدمين على تنظيم وقتهم للفرص الحقيقية.
|
||||
- لا تقدم النتائج كاتهامات بالخداع أو التضليل للشركات.
|
||||
- اعرض الإشارات ودع المستخدم يقرر بنفسه.
|
||||
- اذكر دائماً التفسيرات المشروعة والممكنة للإشارات المقلقة.
|
||||
|
||||
---
|
||||
|
||||
## تحديد النمط الوظيفي (Archetype Detection)
|
||||
|
||||
قم بتصنيف كل عرض وظيفي إلى أحد الأنماط الستة التالية (أو نمط هجين يجمع بين اثنين منها):
|
||||
|
||||
| النمط الوظيفي (Archetype) | الإشارات المفتاحية في نص الوظيفة (JD) |
|
||||
|:---|:---|
|
||||
| **AI Platform / LLMOps** | "observability", "evals", "pipelines", "monitoring", "reliability", "infrastructure" |
|
||||
| **Agentic / Automation** | "agent", "HITL", "orchestration", "workflow", "multi-agent", "autonomy" |
|
||||
| **Technical AI PM** | "PRD", "roadmap", "discovery", "stakeholder", "product manager", "strategy" |
|
||||
| **AI Solutions Architect** | "architecture", "enterprise", "integration", "design", "systems", "client requirements" |
|
||||
| **AI Forward Deployed** | "client-facing", "deploy", "prototype", "fast delivery", "field", "hands-on" |
|
||||
| **AI Transformation** | "change management", "adoption", "enablement", "transformation", "training", "scaling" |
|
||||
|
||||
بعد تحديد النمط، اقرأ ملف `modes/_profile.md` للحصول على الصياغة المخصصة ونقاط الإثبات الخاصة بالمستخدم لهذا النمط.
|
||||
|
||||
---
|
||||
|
||||
## القواعد العامة (Global Rules)
|
||||
|
||||
### يمنع تماماً (NEVER)
|
||||
|
||||
1. اختراع أو تزييف خبرات أو أرقام إنجازات للمرشح.
|
||||
2. تعديل ملف cv.md أو ملفات معرض الأعمال مباشرة دون توجيه صريح.
|
||||
3. تقديم الطلبات نيابة عن المرشح (النظام لا يضغط على زر الإرسال أبداً).
|
||||
4. مشاركة رقم الهاتف في الرسائل التلقائية المولدة (حافظ على الخصوصية).
|
||||
5. التوصية براتب أو حزمة تعويضات أقل من سعر السوق.
|
||||
6. توليد ملف PDF للسيرة الذاتية دون قراءة متطلبات الوظيفة (JD) أولاً.
|
||||
7. استخدام العبارات والمصطلحات الإنشائية الفارغة (Corporate-speak).
|
||||
8. تجاهل أداة التتبع (سجل كل عرض عمل يتم تقييمه فوراً).
|
||||
|
||||
### يجب دائماً (ALWAYS)
|
||||
|
||||
0. **خطاب التغطية (Cover Letter):** إذا كان نموذج التقديم يسمح به، قم بتوليده دائماً بنفس التصميم البصري للسيرة الذاتية، ومطابقة اقتباسات متطلبات الوظيفة مع نقاط الإثبات الخاصة بالمرشح. صفحة واحدة كحد أقصى.
|
||||
1. قراءة cv.md و _profile.md و article-digest.md (إذا وُجد) قبل البدء بالتقييم.
|
||||
1b. **التقييم الأول في كل جلسة:** قم بتشغيل `node cv-sync-check.mjs`. إذا ظهرت تحذيرات، نبه المستخدم.
|
||||
2. تحديد النمط الوظيفي للدور وتعديل الصياغة وفقاً لملف _profile.md.
|
||||
3. الاستشهاد بالسطور الدقيقة من السيرة الذاتية عند مطابقة المتطلبات.
|
||||
4. استخدام أداة WebSearch للبحث عن معلومات الرواتب وبيانات الشركات المستهدفة.
|
||||
5. تسجيل وتوثيق الوظيفة في جدول التتبع بعد الانتهاء من التقييم.
|
||||
6. توليد السيرة الذاتية والخطابات بنفس لغة إعلان الوظيفة (اللغة الإنجليزية بشكل افتراضي ما لم يُنص على غير ذلك).
|
||||
7. أن تكون صياغتك مباشرة وقابلة للتنفيذ وخالية من الحشو.
|
||||
8. استخدام لغة تقنية مهنية رصينة ومباشرة: جمل قصيرة، أفعال حركية ونشطة.
|
||||
8b. تضمين روابط دراسات الحالة في الملخص المهني للملف (Professional Summary).
|
||||
9. **إضافة التتبع بصيغة TSV** -- لا تقم أبداً بتعديل ملف applications.md مباشرة لإضافة الأسطر الجديدة. اكتب ملف TSV في `batch/tracker-additions/` وسيتولى النص البرمجي دمجها.
|
||||
10. **تضمين السطر `**URL:**` في ترويسة كل تقرير.**
|
||||
|
||||
---
|
||||
|
||||
## الأدوات المستعملة (Tools)
|
||||
|
||||
| الأداة | الغرض من الاستخدام |
|
||||
|:---|:---|
|
||||
| **WebSearch** | أبحاث الرواتب، اتجاهات السوق، ثقافة الشركة، جهات الاتصال في LinkedIn، والبحث البديل عن تفاصيل الوظيفة. |
|
||||
| **WebFetch** | استخراج متطلبات الوظيفة من الصفحات الساكنة كخيار احتياطي. |
|
||||
| **Playwright** | التحقق من نشاط الوظائف وحيويتها (`browser_navigate` + `browser_snapshot`). يمنع تشغيل وكيلين بالتوازي يستخدمان Playwright. |
|
||||
| **Read** | قراءة cv.md، _profile.md، article-digest.md، و cv-template.html. |
|
||||
| **Write** | إنشاء ملفات HTML المؤقتة لتوليد PDF، وتحديث ملف applications.md، وتقارير التقييم بصيغة md. |
|
||||
| **Edit** | إجراء التعديلات اللازمة في ملفات التتبع والتهيئة. |
|
||||
| **Canva MCP** | توليد وتصدير السيرة الذاتية بصرياً من خلال التعديل على تصميم Canva الأساسي وتصديره كـ PDF (اختياري). |
|
||||
| **Bash** | تنفيذ الأوامر البرمجية مثل تشغيل `node generate-pdf.mjs`. |
|
||||
|
||||
---
|
||||
|
||||
## معايرة وتحديد أسلوب الكتابة (Writing Style Calibration)
|
||||
|
||||
**افحص ملف `_profile.md` أولاً.** إذا كان هناك قسم باسم `## Writing Style` متوفراً، فاستخدمه مباشرة ولا تقم بإعادة مسح ملفات عينات الكتابة. إعادة المسح مطلوبة فقط إذا تمت إضافة عينات جديدة أو طلب المستخدم ذلك صراحة.
|
||||
|
||||
**متى يُطبق الأسلوب المعاير:** يُطبق قبل إنشاء أي نص سيقوم المستخدم بإرساله أو نشره — مثل خطابات التغطية، رسائل LinkedIn، إجابات النماذج، رسائل البريد الإلكتروني للمتابعة، والملخص المهني. لا ينطبق على تقارير التقييم الداخلية للوظائف.
|
||||
|
||||
**إذا لم يكن هناك أسلوب مخزن في ملف `_profile.md`:** قم بقراءة كافة الملفات في مجلد `writing-samples/` مع **تخطي أي ملف يحمل الاسم `README.md`**. إذا لم توجد عينات، تجاوز هذه الخطوة واقترح بلطف على المستخدم تزويدك بعينات لاحقاً. إذا وُجدت عينات، قم باستخلاص المؤشرات أدناه واكتب النتيجة في `_profile.md` تحت العنوان `## Writing Style` لتسريع العمل في الجلسات القادمة.
|
||||
|
||||
### المؤشرات المستخلصة:
|
||||
|
||||
- **النبرة والمستوى (Tone & register):** رسمية مقابل ودية، واثقة مقابل متحفظة، دافئة مقابل عملية.
|
||||
- **تركيبة الجمل (Sentence structure):** متوسط طول الجمل، استخدام القطع الإنشائية للتأكيد، وتعقيد الجمل.
|
||||
- **عادات علامات الترقيم (Punctuation):** استخدام الشرطات، الأقواس، علامات التعجب، أو الفواصل.
|
||||
- **المفردات المفضلة (Vocabulary):** الكثافة التقنية، الكلمات المفضلة والمكررة، وتجنب مصطلحات معينة.
|
||||
- **أنماط الفقرات والهيكلية (Paragraph structure):** طول الفقرة، الاعتماد على النقاط مقابل النص النثري المتصل، ترتيب الأفكار.
|
||||
|
||||
---
|
||||
|
||||
## الكتابة المهنية والتوافق مع أنظمة ATS
|
||||
|
||||
تنطبق هذه القواعد على جميع النصوص المولدة التي ستوضع في وثائق المستخدم النهائية (ملفات PDF، الإجابات، الخطابات):
|
||||
|
||||
### تجنب الكليشيهات والعبارات المستهلكة:
|
||||
|
||||
- "passionate about" / "results-oriented" / "proven track record"
|
||||
- "leveraged" (استخدم "used" أو حدد الأداة مباشرة)
|
||||
- "spearheaded" (استخدم "led" أو "ran")
|
||||
- "facilitated" (استخدم "ran" أو "set up")
|
||||
- "synergies" / "robust" / "seamless" / "cutting-edge" / "innovative"
|
||||
- "in today's fast-paced world"
|
||||
|
||||
### توحيد الترميز لـ ATS (Unicode Normalization):
|
||||
|
||||
يتكفل السكريبت `generate-pdf.mjs` تلقائيًا بتحويل الرموز الخاصة والشرطات الطويلة وعلامات الاقتباس الذكية إلى مكافئاتها القياسية لضمان القراءة السليمة من قبل أنظمة الفرز والفلترة، ولكن يفضل تجنب توليدها ابتداءً.
|
||||
|
||||
### تنويع تراكيب الجمل:
|
||||
|
||||
- لا تبدأ كل النقاط بنفس الفعل التقني.
|
||||
- امزج بين الجمل القصيرة والقوية، والجمل المتوسطة التي توفر السياق التقني.
|
||||
|
||||
### تفضيل الأرقام والتفاصيل الدقيقة على التعبيرات العامة:
|
||||
|
||||
- عبارة "صياغة معمارية RAG تعتمد على Postgres + pgvector لاسترجاع البيانات عبر 12 ألف وثيقة" أفضل بكثير من "بناء نظام ذكاء اصطناعي قابل للتوسع".
|
||||
- اذكر أسماء الأدوات والمشاريع والمقاييس بوضوح وأرقام محددة كلما سنحت الفرصة.
|
||||
@@ -0,0 +1,212 @@
|
||||
# النمط: fursah — تقييم شامل وعميق لفرصة العمل (الكتل A-G)
|
||||
|
||||
عندما يقوم المرشح بلصق تفاصيل وظيفة (سواء كانت نصاً أو رابطاً)، قم **دائماً** بتقديم تقييم مفصل يتكون من 7 كتل أساسية (التقييم من A إلى F + مصداقية الإعلان G):
|
||||
|
||||
---
|
||||
|
||||
## الخطوة 0 — تحديد النمط الوظيفي (Archetype Detection)
|
||||
|
||||
قم بتصنيف الوظيفة إلى أحد الأنماط الستة المحددة في ملف `_shared.md`. إذا كانت الوظيفة هجينة، فاذكر النمطين الأقرب إليها. يحدد هذا التصنيف:
|
||||
- نقاط الإثبات التي يجب إعطاؤها الأولوية في الكتلة B.
|
||||
- كيفية إعادة صياغة الملخص المهني في الكتلة E.
|
||||
- قصص المقابلات (STAR) التي يجب تحضيرها في الكتلة F.
|
||||
|
||||
---
|
||||
|
||||
## الكتلة A — ملخص الدور الوظيفي (Role Summary)
|
||||
|
||||
جدول يحتوي على:
|
||||
- النمط الوظيفي المكتشف (Archetype)
|
||||
- المجال التقني (Domain) (مثال: منصات/عملاء/LLMOps/تعلم آلي/مؤسسات)
|
||||
- الدور الأساسي (Function) (بناء/استشارة/إدارة/نشر وتطبيق)
|
||||
- المستوى الوظيفي والأقدمية (Seniority)
|
||||
- طبيعة العمل والعمل عن بعد (Remote) (عن بعد كامل/هجين/من الموقع)
|
||||
- حجم الفريق (إن ذكر في الإعلان)
|
||||
- الملخص المفيد (TL;DR) في جملة واحدة مكثفة ومباشرة.
|
||||
|
||||
---
|
||||
|
||||
## الكتلة B — التوافق مع السيرة الذاتية (Match with CV)
|
||||
|
||||
اقرأ ملف `cv.md` الخاص بالمرشح. أنشئ جدولاً يطابق كل متطلب أساسي في إعلان الوظيفة (JD) مع السطور الدقيقة المطابقة له في السيرة الذاتية.
|
||||
|
||||
**التكييف حسب النمط الوظيفي:**
|
||||
- إذا كانت الوظيفة **FDE** ← ركّز على سرعة التنفيذ والتسليم، والخبرة في التعامل المباشر مع العملاء وصياغة النماذج الأولية.
|
||||
- إذا كانت الوظيفة **SA** ← ركّز على تصميم المعماريات، التكامل والدمج التقني، والحلول الجاهزة للمؤسسات الكبرى.
|
||||
- إذا كانت الوظيفة **PM** ← ركّز على استكشاف وتطوير المنتجات، كتابة وثائق متطلبات المنتجات (PRDs)، ومقاييس الأداء والأعمال.
|
||||
- إذا كانت الوظيفة **LLMOps** ← ركّز على تقييم النماذج (Evals)، المراقبة والملاحظة (observability)، وتدفقات البيانات والعمليات المهيأة للإنتاج.
|
||||
- إذا كانت الوظيفة **Agentic** ← ركّز على أطر عمل الوكلاء المتعددين، موجهات التنسيق والتكامل، التفاعل البشري في الحلقة (HITL)، ومعالجة الأخطاء.
|
||||
- إذا كانت الوظيفة **Transformation** ← ركّز على إدارة التغيير، تسريع تبني الذكاء الاصطناعي، وتدريب وتمكين الفرق والمؤسسات.
|
||||
|
||||
**قسم الفجوات والقصور (Gaps):**
|
||||
ضع استراتيجية واضحة للتعامل مع كل فجوة في المتطلبات. لكل فجوة:
|
||||
1. هل المتطلب يمثل عائقاً حتمياً (Blocker) أم أنه ميزة إضافية مفضلة فقط (Nice-to-have)؟
|
||||
2. هل يملك المرشح خبرة مجاورة أو بديلة يمكن الاستناد إليها؟
|
||||
3. هل يغطي أحد المشاريع في معرض الأعمال هذه الفجوة؟
|
||||
4. خطة عملية محددة للالتفاف حول هذه الفجوة (صياغة مناسبة لرسالة التغطية، بناء مشروع سريع، إلخ).
|
||||
|
||||
---
|
||||
|
||||
## الكتلة C — المستوى الوظيفي والاستراتيجية (Level and Strategy)
|
||||
|
||||
1. **المستوى المطلوب في الإعلان** مقارنة بـ **المستوى الفعلي والطبيعي للمرشح** في هذا النمط.
|
||||
2. **خطة "إبراز الخبرة القيادية دون تزييف"**: عبارات مصاغة بدقة تناسب النمط المكتشف، إنجازات كمية ملموسة للتركيز عليها، وكيفية إبراز الخبرات التأسيسية والريادية كعامل قوة حاسم.
|
||||
3. **خطة "في حال محاولة خفض مستواي الوظيفي (Downlevel)"**: شروط القبول (مثل عدالة التعويض المالي)، طلب مراجعة المستوى بعد 6 أشهر، وتحديد معايير ترقية واضحة وموثقة.
|
||||
|
||||
---
|
||||
|
||||
## الكتلة D — أبحاث الرواتب والطلب (Comp and Demand)
|
||||
|
||||
استخدم أداة WebSearch للبحث عن:
|
||||
- متوسط الرواتب الحالية لهذا الدور (استناداً إلى منصات مثل Glassdoor و Levels.fyi و Blind).
|
||||
- السمعة المالية للشركة المستهدفة في تقديم الحزم المالية والتعويضات.
|
||||
- اتجاه الطلب على هذا الدور في سوق العمل حالياً.
|
||||
|
||||
ضع النتائج في جدول موثق مع ذكر المصادر المستشهد بها بالتفصيل. إذا لم تتوفر بيانات موثوقة، فاذكر ذلك بوضوح ولا تقم باختراع أرقام عشوائية.
|
||||
|
||||
---
|
||||
|
||||
## الكتلة E — خطة التخصيص والملاءمة (Customization Plan)
|
||||
|
||||
أنشئ جدولاً يوضح أهم التغييرات المقترحة لتخصيص السيرة الذاتية وملف LinkedIn:
|
||||
|
||||
| # | القسم المستهدف | الحالة الحالية في CV | التغيير المقترح | السبب والهدف من التغيير |
|
||||
|---|---|---|---|---|
|
||||
| 1 | الملخص المهني | ... | ... | ... |
|
||||
| ... | ... | ... | ... | ... |
|
||||
|
||||
اقترح **أبرز 5 تغييرات** على السيرة الذاتية + **أبرز 5 تغييرات** على ملف LinkedIn لرفع نسبة المطابقة للحد الأقصى.
|
||||
|
||||
---
|
||||
|
||||
## الكتلة F — خطة وتجهيز المقابلات (Interview Plan)
|
||||
|
||||
قم بإعداد **6 إلى 10 قصص مهنية مصاغة بأسلوب STAR+R** ومطابقة لمتطلبات الدور (تتكون من: السياق S، المهمة T، الإجراء A، النتيجة R + **الدروس المستفادة Reflection**):
|
||||
|
||||
| # | المتطلب المستهدف من الـ JD | القصة المقترحة | S | T | A | R | الدروس المستفادة (Reflection) |
|
||||
|---|---|---|---|---|---|---|---|
|
||||
|
||||
يعكس عمود **الدروس المستفادة (Reflection)** مستوى النضج والخبرة القيادية للمرشح (المرشحون المبتدئون يصفون ما حدث فقط، بينما القادة والمحترفون يستخلصون الدروس الاستراتيجية العميقة).
|
||||
|
||||
**بنك القصص (Story Bank):** إذا كان ملف `interview-prep/story-bank.md` متوفراً، فراجع القصص المسجلة فيه أولاً لتجنب التكرار واستخدامها كقاعدة. إذا لم تكن موجودة، أضف هذه القصص الجديدة إليه لتثري البنك تدريجياً.
|
||||
|
||||
**تكييف واختيار القصص وفقاً للنمط:**
|
||||
- **FDE** ← التركيز على سرعة الإنجاز والتعامل الذكي والمباشر مع تحديات العملاء.
|
||||
- **SA** ← التركيز على القرارات الهيكلية الكبرى واختيار البنية التحتية المناسبة والمفاضلات الهندسية.
|
||||
- **PM** ← التركيز على أبحاث المستخدمين، المواءمة بين الأقسام، والمقاييس المالية والتشغيلية للمنتج.
|
||||
- **LLMOps** ← التركيز على استقرار الأنظمة في الإنتاج، تخفيض التكاليف، وإدارة وتوثيق جودة النماذج ومراقبتها.
|
||||
- **Agentic** ← التركيز على معالجة المشاكل المعقدة في التشغيل الذاتي والذكاء غير المتوقع للوكلاء والتنسيق بين الأنظمة.
|
||||
- **Transformation** ← التركيز على تحفيز التبني الجماعي، التعامل مع مقاومة التغيير، وتأهيل وتدريب الكوادر البشرية.
|
||||
|
||||
تضمين الآتي أيضاً:
|
||||
- **مشروع عملي مقترح للعرض (Case Study):** أي من مشاريع المرشح هو الأنسب لعرضه في المقابلة الفنية وكيفية هيكلة العرض.
|
||||
- **الأسئلة المقلقة وكيفية التعامل معها:** الأسئلة التي قد تثير الشكوك (مثل: "لماذا قمت ببيع شركتك السابقة؟"، "هل تملك خبرة سابقة في إدارة أعداد كبيرة من الموظفين؟") وصياغة ردود ذكية ومقنعة لها.
|
||||
|
||||
---
|
||||
|
||||
## الكتلة G — مصداقية وجودة الإعلان (Posting Legitimacy)
|
||||
|
||||
حلل إعلان الوظيفة للكشف عن الإشارات التي توضح ما إذا كان الإعلان يعبر عن فرصة عمل نشطة وحقيقية أم أنه مجرد إعلان وهمي (Ghost Job).
|
||||
|
||||
**الإطار الأخلاقي:** اعرض الملاحظات بموضوعية ومهنية دون اتهام مباشر للشركات. لكل إشارة مقلقة قد تكون هناك أسباب تنظيمية أو إدارية مشروعة تماماً. القرار النهائي يعود دائماً للمرشح.
|
||||
|
||||
### الإشارات الخاضعة للتحليل:
|
||||
|
||||
1. **حيوية وحداثة النشر (Posting Freshness):**
|
||||
- تاريخ النشر الفعلي أو "منذ X يوماً" (مستخرج من لقطة الصفحة عبر Playwright).
|
||||
- حالة زر التقديم (نشط / مغلق / مفقود / يحول لصفحة توظيف عامة).
|
||||
|
||||
2. **جودة وتفصيل الوصف الوظيفي (Description Quality):**
|
||||
- هل يذكر الإعلان تقنيات وأدوات وأطر عمل محددة بدقة؟
|
||||
- هل يشير لحجم الفريق، الهيكلية الإدارية، وسياق العمل؟
|
||||
- هل متطلبات سنوات الخبرة واقعية ومطابقة لحداثة التقنيات المطلوبة؟
|
||||
- هل يحدد الإعلان المهام الأساسية بدقة لأول 6-12 شهراً؟
|
||||
- هل تم الإفصاح عن حزمة الرواتب والتعويضات؟
|
||||
|
||||
3. **حالة التوظيف الفعلية في الشركة (Company Hiring Signals):**
|
||||
- ابحث عبر الإنترنت عن عمليات التسريح الأخيرة للشركة أو تجميد التوظيف.
|
||||
- إذا وُجدت عمليات تسريح: هل مست الأقسام ذات الصلة بهذه الوظيفة مباشرة؟
|
||||
|
||||
4. **تكرار النشر (Reposting Detection):**
|
||||
- افحص ملف `scan-history.tsv` للتأكد مما إذا كانت الشركة قد نشرت نفس الوظيفة مراراً وتكراراً بروابط مختلفة في فترة قصيرة.
|
||||
|
||||
5. **سياق سوق العمل العام الوظيفي (Role Market Context):**
|
||||
- هل هذا الدور وظيفي شائع يُغلق عادة في غضون 4-6 أسابيع؟
|
||||
- هل تعكس الوظيفة أهداف وأعمال الشركة الفعلية بشكل منطقي؟
|
||||
|
||||
### الصياغة النهائية للكتلة G:
|
||||
|
||||
- **التقييم العام (Assessment):** واحد من ثلاثة مستويات:
|
||||
- **High Confidence (ثقة عالية)** -- إشارات متعددة تؤكد جدية الفرصة وحداثتها.
|
||||
- **Proceed with Caution (تقدم بحذر)** -- إشارات مختلطة تستدعي التحقق والملاحظة.
|
||||
- **Suspicious (مشبوهة)** -- مؤشرات واضحة على إعلان غير نشط أو وهمي، يفضل البحث قبل استهلاك الوقت.
|
||||
- **جدول الإشارات المرصودة:** تفصيل كل مؤشر مع وزنه وتأثيره (إيجابي / محايد / مقلق).
|
||||
- **الملاحظات السياقية (Context Notes):** تفسيرات إضافية وتوضيحات هامة قد تبرر الإشارات المقلقة (مثلاً: الوظائف الحكومية أو الأكاديمية تستغرق بطبيعتها أوقاتاً طويلة جداً للنشر والفرز، وهذا أمر طبيعي).
|
||||
|
||||
---
|
||||
|
||||
## خطوات ما بعد التقييم (Post-evaluation)
|
||||
|
||||
**دائماً** وبلا استثناء بعد إعداد الكتل من A إلى G:
|
||||
|
||||
### 1. حفظ التقرير بصيغة Markdown
|
||||
|
||||
احفظ التقييم كاملاً في المسار التالي: `reports/{###}-{company-slug}-{YYYY-MM-DD}.md`.
|
||||
|
||||
- `{###}` = الرقم التسلسلي المكون من 3 خانات (مع تعبئة الأصفار على اليسار، مثلاً `042`).
|
||||
- `{company-slug}` = اسم الشركة مكتوباً بأحرف إنجليزية صغيرة وبدون مسافات (استخدم الشرطات للفصل بين الكلمات).
|
||||
- `{YYYY-MM-DD}` = التاريخ الحالي.
|
||||
|
||||
**هيكل ومحتوى التقرير:**
|
||||
|
||||
```markdown
|
||||
# Evaluation: {Company} — {Role}
|
||||
|
||||
**Date:** {YYYY-MM-DD}
|
||||
**URL:**
|
||||
**Archetype:** {detected}
|
||||
**Score:** {X/5}
|
||||
**Legitimacy:** {High Confidence | Proceed with Caution | Suspicious}
|
||||
**PDF:** {path or pending}
|
||||
|
||||
---
|
||||
|
||||
## A) Role Summary
|
||||
(محتوى الكتلة A كاملاً)
|
||||
|
||||
## B) Match with CV
|
||||
(محتوى الكتلة B كاملاً)
|
||||
|
||||
## C) Level and Strategy
|
||||
(محتوى الكتلة C كاملاً)
|
||||
|
||||
## D) Comp and Demand
|
||||
(محتوى الكتلة D كاملاً)
|
||||
|
||||
## E) Customization Plan
|
||||
(محتوى الكتلة E كاملاً)
|
||||
|
||||
## F) Interview Plan
|
||||
(محتوى الكتلة F كاملاً)
|
||||
|
||||
## G) Posting Legitimacy
|
||||
(محتوى الكتلة G كاملاً)
|
||||
|
||||
## H) Draft Application Answers
|
||||
(يُكتب فقط إذا كان التقييم الإجمالي للمطابقة 4.5 فما فوق — مسودات إجابات جاهزة ومقترحة لنموذج التقديم)
|
||||
|
||||
---
|
||||
|
||||
## Keywords extracted
|
||||
(قائمة تحتوي على 15-20 كلمة مفتاحية مستخرجة من الـ JD ومهمة لتحسين الـ ATS)
|
||||
```
|
||||
|
||||
### 2. التسجيل في نظام التتبع
|
||||
|
||||
**دائماً** سجل هذا الطلب في الجدول الأساسي بملف `data/applications.md` باتباع الصيغة المشتركة المحددة (عبر كتابة الأسطر المؤقتة في ملفات الـ TSV تحت مجلد `batch/tracker-additions/` لتجنب التكرار وتسهيل الدمج السليم).
|
||||
|
||||
**ملاحظة:** بعد إنشاء ملف الإضافة المؤقت، يجب تشغيل الأمر التالي لدمج التعديلات في الجدول الرئيسي:
|
||||
|
||||
```bash
|
||||
node merge-tracker.mjs
|
||||
```
|
||||
@@ -0,0 +1,70 @@
|
||||
# النمط: pipeline — معالجة روابط الوظائف المنتظرة (Second Brain)
|
||||
|
||||
معالجة وفحص روابط الوظائف المخزنة في صندوق الوارد بملف `data/pipeline.md`. يقوم المستخدم بإضافة روابط الفرص التي تسترعي انتباهه في أي وقت، ثم يقوم بتشغيل الأمر `/career-ops pipeline` ليقوم النظام بمعالجتها وتقييمها بالكامل تلقائياً.
|
||||
|
||||
---
|
||||
|
||||
## مسار العمل التنفيذي
|
||||
|
||||
1. **قراءة الملف** `data/pipeline.md` ← البحث عن العناصر المحددة بـ `- [ ]` (غير المكتملة) في قسم "Pending" (الفرص المنتظرة).
|
||||
2. **لكل رابط منتظر في القائمة**:
|
||||
a. حساب الرقم التسلسلي القادم للتقرير `REPORT_NUM` (بقراءة محتويات مجلد `reports/` وأخذ أكبر رقم مضافاً إليه 1).
|
||||
b. **استخراج تفاصيل متطلبات الوظيفة (JD)** باستخدام Playwright (`browser_navigate` + `browser_snapshot`) ← ثم استخدام WebFetch ← كخيار بديل أخير استخدام WebSearch.
|
||||
c. إذا كان الرابط غير قابل للوصول ← قم بتغيير العلامة إلى `- [!]` مع تدوين سبب الخطأ واستمر في معالجة الروابط الأخرى.
|
||||
d. **تنفيذ المسار التلقائي بالكامل**: تشغيل التقييم من A إلى G ← إنشاء ملف تقرير بصيغة md ← توليد ملف PDF للسيرة الذاتية المخصصة (فقط إذا كان التقييم 3.0 فما فوق) ← التوثيق الفوري في جدول التتبع.
|
||||
e. **نقل العنصر من قسم "Pending" إلى قسم "Processed" (المعالجة)** بصيغة: `- [x] #NNN | URL | Company | Role | Score/5 | PDF ✅/❌`.
|
||||
3. **إذا كان هناك 3 روابط أو أكثر منتظرة**: قم بإطلاق وكلاء فرعيين بالتوازي (باستخدام أداة الوكلاء الفرعيين مع خيار التشغيل في الخلفية `run_in_background`) لرفع سرعة المعالجة للحد الأقصى.
|
||||
4. **بعد اكتمال جميع التقييمات**: قم بتشغيل `node merge-tracker.mjs` لدمج جميع إضافات التتبع في ملف `data/applications.md` وتجنب التكرارات.
|
||||
5. **في النهاية**: اعرض جدولاً يلخص الفرص التي تمت معالجتها:
|
||||
|
||||
```text
|
||||
| # | الشركة | الوظيفة | التقييم | السيرة الذاتية PDF | الإجراء المقترح |
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## هيكل وصيغة ملف pipeline.md
|
||||
|
||||
```markdown
|
||||
## Pending
|
||||
- [ ] https://jobs.example.com/posting/123
|
||||
- [ ] https://boards.greenhouse.io/company/jobs/456 | Company Inc | Senior PM
|
||||
- [!] https://private.url/job — Error: login required
|
||||
|
||||
## Processed
|
||||
- [x] #143 | https://jobs.example.com/posting/789 | Acme Corp | AI PM | 4.2/5 | PDF ✅
|
||||
- [x] #144 | https://boards.greenhouse.io/xyz/jobs/012 | BigCo | SA | 2.1/5 | PDF ❌
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## الاستخراج الذكي لمتطلبات الوظيفة (JD) من الرابط
|
||||
|
||||
1. **أداة Playwright (الخيار المفضل):** استخدام أداة التنقل وأخذ لقطة للصفحة (`browser_navigate` + `browser_snapshot`). تعمل بكفاءة عالية مع كافة تطبيقات الصفحة الواحدة (SPAs).
|
||||
2. **أداة WebFetch (الخيار الاحتياطي الأول):** للصفحات الساكنة أو عند عدم توفر Playwright في البيئة المحلية.
|
||||
3. **أداة WebSearch (الخيار الاحتياطي الأخير):** للبحث في المنصات الثانوية التي تقوم بنسخ وفهرسة الإعلان الأصلي للوظيفة.
|
||||
|
||||
**حالات خاصة:**
|
||||
- **LinkedIn:** قد تطلب المنصة تسجيل الدخول لقراءة محتوى الوصف الوظيفي ← في هذه الحالة، ضع العلامة `[!]` واطلب من المستخدم نسخ ولصق نص الإعلان يدوياً في المحادثة.
|
||||
- **ملفات PDF:** إذا كان الرابط يشير مباشرة إلى ملف PDF، فاستخدم أداة قراءة الملفات مباشرة لقراءة محتوياته.
|
||||
- **البادئة `local:`:** لقراءة ملف محلي على الجهاز. مثال: `local:jds/linkedin-pm-ai.md` ← سيقوم النظام بفتح وقراءة الملف المحلي `jds/linkedin-pm-ai.md`.
|
||||
|
||||
---
|
||||
|
||||
## الترقيم التلقائي للتقارير
|
||||
|
||||
1. فحص وسرد كافة الملفات الموجودة في مجلد `reports/`.
|
||||
2. استخراج الرقم التسلسلي من البادئة الخاصة بكل ملف (مثال: الملف `142-company...` يمثل الرقم 142).
|
||||
3. تعيين الرقم الجديد للتقرير القادم = أكبر رقم تم العثور عليه مضافاً إليه 1.
|
||||
|
||||
---
|
||||
|
||||
## التحقق من مزامنة وتناسق البيانات
|
||||
|
||||
قبل البدء في معالجة أي رابط، تحقق دائماً من سلامة ومزامنة مصادر البيانات وسيرتك الذاتية عن طريق تشغيل:
|
||||
|
||||
```bash
|
||||
node cv-sync-check.mjs
|
||||
```
|
||||
|
||||
إذا تم اكتشاف أي عدم تطابق أو مشاكل في المزامنة، فقم بتنبيه وتحذير المستخدم فوراً قبل متابعة العمل.
|
||||
@@ -0,0 +1,115 @@
|
||||
# النمط: takdeem — المساعد التفاعلي الفوري لتقديم طلبات التوظيف
|
||||
|
||||
الوضع التفاعلي المخصص لمساعدة المرشح أثناء قيامه بتعبئة نموذج التقديم الإلكتروني للوظيفة. يقوم هذا الوضع بقراءة ما يظهر على الشاشة، تحميل السياق والتقارير السابقة للوظيفة، وتوليد إجابات مخصصة ودقيقة ومقنعة لكل سؤال في النموذج.
|
||||
|
||||
---
|
||||
|
||||
## المتطلبات الأساسية
|
||||
|
||||
- **يفضل تشغيل Playwright في الوضع المرئي (Visible Mode):** يتيح هذا الوضع للمرشح رؤية المتصفح ويسمح للوكيل الذكي (Claude/Gemini) بالتفاعل وقراءة الصفحة مباشرة.
|
||||
- **بدون استخدام Playwright:** يقوم المرشح بمشاركة لقطة شاشة للنموذج أو نسخ ولصق الأسئلة يدوياً في المحادثة.
|
||||
|
||||
---
|
||||
|
||||
## مسار العمل التفاعلي
|
||||
|
||||
```text
|
||||
1. الكشف (DETECT) ← قراءة التبويب النشط في المتصفح (لقطة الشاشة/الرابط/العنوان)
|
||||
2. التحديد (IDENTIFY)← استخراج اسم الشركة والمسمى الوظيفي من الصفحة
|
||||
3. البحث (SEARCH) ← مطابقة الدور مع التقارير السابقة الموجودة في مجلد reports/
|
||||
4. التحميل (LOAD) ← قراءة التقرير الكامل ومراجعة القسم H (مسودات إجابات التقديم)
|
||||
5. المقارنة (COMPARE)← التحقق من تطابق الوظيفة على الشاشة مع الوظيفة التي تم تقييمها سابقاً
|
||||
6. التحليل (ANALYZE) ← رصد وتحديد جميع الأسئلة المرئية في النموذج
|
||||
7. التوليد (GENERATE)← صياغة إجابة مقنعة ومخصصة لكل سؤال بالاستناد إلى السيرة الذاتية والتقرير
|
||||
8. العرض (PRESENT) ← عرض الردود الجاهزة والمنسقة للمرشح لينسخها ويلصقها مباشرة
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## الخطوة 1 — الكشف عن الوظيفة والنموذج (Detect the job)
|
||||
|
||||
**باستخدام Playwright:** التقط لقطة شاشة للتبويب النشط واقرأ العنوان والرابط والمحتوى المكتوب في الصفحة تلقائياً.
|
||||
|
||||
**بدون استخدام Playwright:** اطلب من المرشح القيام بأحد الخيارات التالية:
|
||||
- مشاركة لقطة شاشة للنموذج (يمكن للوكيل قراءة النصوص من الصور).
|
||||
- أو نسخ ولصق أسئلة النموذج كمتن نصي في المحادثة.
|
||||
- أو ذكر اسم الشركة والوظيفة لنقوم بالبحث عنها في التقارير السابقة.
|
||||
|
||||
---
|
||||
|
||||
## الخطوة 2 — تحديد الفرصة واستحضار السياق (Identify and search)
|
||||
|
||||
1. استخراج اسم الشركة والمسمى الوظيفي بدقة من الصفحة.
|
||||
2. البحث في مجلد `reports/` عن التقارير المرتبطة باسم الشركة (باستخدام بحث grep غير حساس لحالة الأحرف).
|
||||
3. عند العثور على التقرير المطابق ← قم بتحميله بالكامل.
|
||||
4. إذا كان التقرير يحتوي على القسم H — Draft Application Answers (مسودات إجابات التقديم، كما هو محدد في fursah.md) ← قم بتحميل مسودات الإجابات السابقة لاستخدامها كقاعدة صلبة.
|
||||
5. في حال عدم وجود أي تقارير سابقة مطابقة لهذه الشركة ← نبه المرشح واقترح تشغيل تقييم سريع وتلقائي للوظيفة (Auto-Pipeline) أولاً.
|
||||
|
||||
---
|
||||
|
||||
## الخطوة 3 — التحقق من مطابقة متطلبات الوظيفة (Detect changes)
|
||||
|
||||
إذا كانت متطلبات وتفاصيل الوظيفة المعروضة حالياً على الشاشة تختلف عما تم تقييمه وحفظه في التقرير سابقاً:
|
||||
- **نبه المرشح فوراً:** "المسمى الوظيفي أو تفاصيل الفرصة قد تغيرت من [X] إلى [Y]. هل تفضل أن أقوم بإعادة تقييم الدور بالكامل أم أقوم بتكييف الإجابات مع المسمى الجديد مباشرة؟"
|
||||
- **في حال التكييف (Adapt):** عدل الردود لتلائم التسمية والمتطلبات الجديدة دون إعادة كتابة التقرير الشامل.
|
||||
- **في حال إعادة التقييم (Re-evaluate):** أطلق تقييماً شاملاً من A إلى G، قم بتحديث التقرير في المجلد وتوليد مسودات ردود جديدة تماماً.
|
||||
- **تحديث جدول التتبع:** قم بتحديث اسم الوظيفة وحالتها في ملف `applications.md` إذا لزم الأمر.
|
||||
|
||||
---
|
||||
|
||||
## الخطوة 4 — تحليل أسئلة نموذج التقديم (Analyze form questions)
|
||||
|
||||
قم برصد وتصنيف كافة الأسئلة والأسطح المرئية في النموذج الإلكتروني:
|
||||
- الحقول النصية الحرة (خطاب التغطية، لماذا تريد الانضمام إلينا؟، تحدّث عن مشروع مميز، إلخ).
|
||||
- القوائم المنسدلة (كيف سمعت عنا؟، تصريح العمل، إلخ).
|
||||
- الأسئلة الثنائية نعم/لا (الموافقة على الانتقال، رعاية التأشيرة، إلخ).
|
||||
- حقول الراتب والتوقعات المالية (الحد الأدنى، التوقعات المالية الإجمالية).
|
||||
- حقول رفع المستندات (السيرة الذاتية المخصصة، خطاب التغطية بصيغة PDF).
|
||||
|
||||
صنف الأسئلة المطروحة إلى:
|
||||
- **أسئلة مجاب عنها سابقاً في مسودة التقرير** ← قم بتكييف الصياغة السابقة وتحسينها لتناسب حقل النموذج الحالي.
|
||||
- **أسئلة جديدة تماماً** ← قم بتوليد إجابات مهنية مقنعة فوراً بالاستناد إلى التقرير الشامل وملف السيرة الذاتية `cv.md`.
|
||||
|
||||
---
|
||||
|
||||
## الخطوة 5 — توليد وصياغة الإجابات (Generate responses)
|
||||
|
||||
لكل سؤال مرصود في النموذج، صغ الإجابة مع الالتزام بالمعايير التالية:
|
||||
|
||||
1. **الاستناد إلى السياق والتقارير:** استخدم نقاط الإثبات القوية المستخلصة في التقييم (الكتلة B) وقصص المقابلات المسجلة بأسلوب STAR (الكتلة F).
|
||||
2. **استغلال المسودات السابقة:** ابدأ بالمسودات المعدة مسبقاً في القسم H إن وُجدت، وقم بتنقيحها وتلميعها.
|
||||
3. **نبرة مهنية واثقة ومباشرة:** ابتعد عن العبارات الاستهلاكية والجمل الطويلة المفرغة من المعاني المهنية، وركّز على إبراز رغبتك بالانضمام للشركة تحديداً استناداً لمعلومات دقيقة.
|
||||
4. **تضمين تفاصيل محددة من الـ JD:** أشر في إجاباتك إلى متطلبات تقنية أو مهام حقيقية ذُكرت بوضوح في إعلان الوظيفة المعروض على الشاشة.
|
||||
|
||||
**صيغة وهيكل الإجابات المعروضة:**
|
||||
|
||||
```text
|
||||
## إجابات مقترحة لنموذج تقديم: [الشركة] — [الوظيفة]
|
||||
|
||||
مستند إلى: تقرير التقييم #{###} | التقييم الإجمالي: {X.X/5} | النمط الوظيفي: [النمط المكتشف]
|
||||
|
||||
---
|
||||
|
||||
### 1. [السؤال كما هو مكتوب في نموذج التقديم تماماً]
|
||||
> [الإجابة المصاغة والجاهزة للنسخ واللصق المباشر]
|
||||
|
||||
### 2. [السؤال التالي]
|
||||
> [الإجابة المصاغة]
|
||||
|
||||
...
|
||||
|
||||
---
|
||||
|
||||
ملاحظات وتوجيهات للمرشح:
|
||||
- [أي ملاحظات حول التغييرات المرصودة في متطلبات الوظيفة أو شروط التقديم]
|
||||
- [نقاط تذكرك بالأشياء التي يجب عليك التحقق منها أو إضافتها بنفسك قبل الإرسال]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## الخطوة 6 — ما بعد إرسال الطلب (Post-apply)
|
||||
|
||||
عندما يؤكد المرشح قيامه بإرسال طلب التقديم بنجاح:
|
||||
1. قم بتحديث حالة طلب التوظيف في ملف التتبع `applications.md` من "Evaluated" إلى "Applied".
|
||||
2. قم بحفظ الإجابات النهائية المعتمدة والملقاة في القسم H من تقرير الوظيفة للرجوع إليها لاحقاً عند التحضير للمقابلات.
|
||||
3. اقترح على المرشح الخطوة الذكية التالية مباشرة: تشغيل الأمر `/career-ops contacto` لصياغة رسالة احترافية وموجهة للتواصل مع مسؤولي التوظيف في الشركة عبر LinkedIn.
|
||||
@@ -0,0 +1,89 @@
|
||||
# Mode: auto-pipeline — Full Automatic Pipeline
|
||||
|
||||
When the user pastes a JD (text or URL) without an explicit sub-command, execute the ENTIRE pipeline in sequence:
|
||||
|
||||
## Step 0 — Extract JD
|
||||
|
||||
If the input is a **URL** (not pasted JD text), follow this strategy to extract the content:
|
||||
|
||||
**Priority order:**
|
||||
|
||||
1. **Playwright (preferred):** Most job portals (Lever, Ashby, Greenhouse, Workday) are SPAs. Use `browser_navigate` + `browser_snapshot` to render and read the JD.
|
||||
2. **WebFetch (fallback):** For static pages (ZipRecruiter, WeLoveProduct, company career pages).
|
||||
3. **WebSearch (last resort):** Search for the role title + company in secondary portals that index the JD in static HTML.
|
||||
|
||||
**If no method works:** Ask the candidate to paste the JD manually or share a screenshot.
|
||||
|
||||
**If the input is JD text** (not a URL): use directly, without needing to fetch.
|
||||
|
||||
## Step 0.5 — Liveness gate
|
||||
|
||||
Before running any evaluation, confirm the posting is still live. The Step 0 Playwright snapshot already holds the evidence — judge it now, before spending tokens on the A-G evaluation, the report, or a PDF. A 404/expired page silently served as a static fallback ("position filled", empty shell) otherwise scores a full evaluation against phantom content.
|
||||
|
||||
1. From the Step 0 snapshot/fetched content, classify the posting:
|
||||
- **active posting evidence:** title/role + a real job description or an application/apply path
|
||||
- **closed posting evidence:** expired/closed/"no longer accepting applications", missing JD with only nav/footer, hard redirect to a generic careers/search page, or 404/410
|
||||
2. If the posting appears closed or the page is a dead/fallback shell, **stop here**: do not run Step 1–Step 4. Tell the candidate the link is dead, and if the entry came from `data/pipeline.md`, mark it `- [x] ~~Company | Role~~ — oferta nieaktywna`.
|
||||
3. If only JD text was pasted (no URL), there is no link to verify — skip the gate and proceed.
|
||||
|
||||
Do not continue to Step 1 until this gate is resolved.
|
||||
|
||||
## Step 1 — A-G Evaluation
|
||||
|
||||
Execute the same as the `oferta` mode (read `modes/oferta.md` for all A-F blocks + Block G Posting Legitimacy).
|
||||
|
||||
The evaluation inherits `oferta`'s bounded research budget. Company, compensation, and hiring-signal lookup must not invoke `deep-research`, must not spawn subagents, and must stop at the shared query cap instead of escalating into open-ended research.
|
||||
|
||||
## Step 2 — Save Report .md
|
||||
|
||||
Save the full evaluation in `reports/{###}-{company-slug}-{YYYY-MM-DD}.md` (see format in `modes/oferta.md`).
|
||||
Include Block G in the saved report. Add **URL:** {url} and **Legitimacy:** {tier} to the report header.
|
||||
|
||||
## Step 3 — Generate PDF
|
||||
|
||||
Read `config/profile.yml`. Check `cv.output_format`:
|
||||
|
||||
- If `"latex"`, execute the full pipeline from `modes/latex.md`
|
||||
- Otherwise (default), execute the full pipeline from `modes/pdf.md`
|
||||
|
||||
## Step 4 — Draft Application Answers (only if score >= 4.5)
|
||||
|
||||
If the final score is >= 4.5, generate a draft of responses for the application form:
|
||||
|
||||
1. **Extract form questions**: Use Playwright to navigate to the form and take a snapshot. If they cannot be extracted, use the generic questions.
|
||||
2. **Generate responses** following the tone (see below).
|
||||
3. **Save in the report** as section `## H) Draft Application Answers`.
|
||||
|
||||
### Generic questions (use if they cannot be extracted from the form)
|
||||
|
||||
- Why are you interested in this role?
|
||||
- Why do you want to work at [Company]?
|
||||
- Tell us about a relevant project or achievement
|
||||
- What makes you a good fit for this position?
|
||||
- How did you hear about this role?
|
||||
|
||||
### Tone for Form Answers
|
||||
|
||||
**Position: "I'm choosing you."** The candidate has options and is choosing this company for specific reasons.
|
||||
|
||||
**Tone rules:**
|
||||
- **Confident without arrogance**: "I've spent the past year building production AI agent systems — your role is where I want to apply that experience next"
|
||||
- **Selective without arrogance**: "I've been intentional about finding a team where I can contribute meaningfully from day one"
|
||||
- **Specific and concrete**: Always reference something REAL from the JD or the company, and something REAL from the candidate's experience
|
||||
- **Direct, without fluff**: 2-4 sentences per response. No "I'm passionate about..." or "I would love the opportunity to..."
|
||||
- **The hook is the proof, not the statement**: Instead of "I'm great at X", say "I built X that does Y"
|
||||
|
||||
**Framework per question:**
|
||||
- **Why this role?** → "Your [specific thing] maps directly to [specific thing I built]."
|
||||
- **Why this company?** → Mention something specific about the company. "I've been using [product] for [time/purpose]."
|
||||
- **Relevant experience?** → A quantified proof point. "Built [X] that [metric]. Sold the company in 2025."
|
||||
- **Good fit?** → "I sit at the intersection of [A] and [B], which is exactly where this role lives."
|
||||
- **How did you hear?** → Honest: "Found through [portal/scan], evaluated against my criteria, and it scored highest."
|
||||
|
||||
**Language**: Always in the language of the JD (EN default). Apply `/tech-translate`.
|
||||
|
||||
## Step 5 — Update Tracker
|
||||
|
||||
Record it in `data/applications.md` with all columns including Report and PDF as ✅.
|
||||
|
||||
**If any step fails**, continue with the next ones and mark the failed step as pending in the tracker.
|
||||
+143
@@ -0,0 +1,143 @@
|
||||
# Mode: batch — Mass Processing of Jobs
|
||||
|
||||
Two usage modes: **conductor --chrome** (navigates portals in real time) or **standalone** (script for URLs already collected).
|
||||
|
||||
## Architecture
|
||||
|
||||
```text
|
||||
Conductor (headed browser mode)
|
||||
│
|
||||
│ Chrome: navigates portals (logged-in sessions)
|
||||
│ Reads DOM directly — the user sees everything in real time
|
||||
│
|
||||
├─ Job 1: reads JD from DOM + URL
|
||||
│ └─► headless worker → report .md + PDF + tracker-line
|
||||
│
|
||||
├─ Job 2: click next, read JD + URL
|
||||
│ └─► headless worker → report .md + PDF + tracker-line
|
||||
│
|
||||
└─ End: merge tracker-additions → applications.md + summary
|
||||
```
|
||||
|
||||
Each worker is a headless child process with a clean 200K token context. The conductor only orchestrates. See the **Headless / Batch Mode** table in `AGENTS.md` for the correct command per CLI.
|
||||
|
||||
## Files
|
||||
|
||||
```text
|
||||
batch/
|
||||
batch-input.tsv # URLs (from conductor or manual)
|
||||
batch-state.tsv # Progress (auto-generated, gitignored)
|
||||
batch-runner.sh # Standalone orchestrator script
|
||||
batch-prompt.md # Prompt template for workers
|
||||
logs/ # One log per job (gitignored)
|
||||
tracker-additions/ # Tracker lines (gitignored)
|
||||
```
|
||||
|
||||
## Mode A: Conductor --chrome
|
||||
|
||||
1. **Read state**: `batch/batch-state.tsv` → identify what has already been processed
|
||||
2. **Navigate portal**: Chrome → search URL
|
||||
3. **Extract URLs**: Read results DOM → extract URL list → append to `batch-input.tsv`
|
||||
4. **For each pending URL**:
|
||||
a. Chrome: click on the job → read JD text from the DOM
|
||||
b. Save JD to `/tmp/batch-jd-{id}.txt`
|
||||
c. Reserve the next REPORT_NUM atomically: `node reserve-report-num.mjs` (release with `--release {num}` after the worker writes the report; stale sentinels are GC'd automatically)
|
||||
d. Execute via Bash:
|
||||
|
||||
```bash
|
||||
# Use your CLI's headless command (see AGENTS.md — Headless / Batch Mode)
|
||||
<headless-cmd> "Process this job. URL: {url}. JD: /tmp/batch-jd-{id}.txt. Report: {num}. ID: {id}"
|
||||
```
|
||||
|
||||
e. Update `batch-state.tsv` (completed/failed + score + report_num)
|
||||
f. Log to `logs/{report_num}-{id}.log`
|
||||
g. Chrome: go back → next job
|
||||
5. **Pagination**: If no more jobs → click "Next" → repeat
|
||||
6. **End**: Merge `tracker-additions/` → `applications.md` + summary
|
||||
|
||||
### What to watch during a run
|
||||
|
||||
During a conductor run, the operator has two primary live interfaces to monitor:
|
||||
1. **The headed Chrome window:** Watch the browser navigate the portals, login to sessions, and interact with the job description pages in real time.
|
||||
2. **The agent CLI conversation:** Follow the agent's turn-by-turn narration in the shell.
|
||||
|
||||
The individual worker tasks spawn headlessly in the background and write their stdout/stderr logs to `batch/logs/{report_num}-{id}.log`, which can be inspected on demand.
|
||||
|
||||
### Manual multi-agent fan-out
|
||||
|
||||
Orchestrating N parallel evaluators by hand (multiple agent windows / subagents, outside `batch-runner.sh`)? Reserve the whole range FIRST, then hand each worker its own number — never let workers compute `max+1` themselves:
|
||||
|
||||
```bash
|
||||
node reserve-report-num.mjs --count 8
|
||||
# stdout: 042-049 → worker 1 gets 042, worker 2 gets 043, ...
|
||||
```
|
||||
|
||||
Each number is backed by a sentinel file in `reports/`, so concurrent reservations from other windows cannot collide. After all reports are written, release leftovers in one call:
|
||||
|
||||
```bash
|
||||
node reserve-report-num.mjs --release 042-049
|
||||
```
|
||||
|
||||
**Two things to know:**
|
||||
|
||||
- **4-hour protection window.** Sentinels older than 4h are garbage-collected (`verify-pipeline.mjs` triggers this). Reserve the range immediately before spawning workers, not at the start of a long session. Once a worker writes its real report, that slot is permanently safe — only slow or unstarted slots are at risk after 4h.
|
||||
- **Gaps are normal.** If a reservation collides and restarts, skipped numbers (e.g. `006`) are never reused. Report numbers are opaque IDs; a gap is not corruption.
|
||||
|
||||
## Mode B: Standalone script
|
||||
|
||||
```bash
|
||||
batch/batch-runner.sh [OPTIONS]
|
||||
```
|
||||
|
||||
Options:
|
||||
- `--dry-run` — list pending jobs without executing
|
||||
- `--retry-failed` — retry only failed jobs
|
||||
- `--resume-paused` — resume jobs paused after a Claude session/rate limit
|
||||
- `--start-from N` — start from ID N
|
||||
- `--limit N` — max number of jobs to process in this run
|
||||
- `--parallel N` — N workers in parallel
|
||||
- `--max-retries N` — attempts per job (default: 2)
|
||||
- `--rate-limit-sleep N` — seconds to wait before retrying a transient rate-limited worker (default: 300; use 0 to pause the batch immediately)
|
||||
|
||||
## batch-state.tsv Format
|
||||
|
||||
```text
|
||||
id url status started_at completed_at report_num score error retries
|
||||
1 https://... completed 2026-... 2026-... 002 4.2 - 0
|
||||
2 https://... failed 2026-... 2026-... - - Error msg 1
|
||||
3 https://... pending - - - - - 0
|
||||
4 https://... rate_limited 2026-... 2026-... 004 - rate-limit; retrying after 300s 1
|
||||
5 https://... paused_rate_limit 2026-... 2026-... 005 - session limit; paused 1
|
||||
```
|
||||
|
||||
Valid statuses include `pending`, `processing`, `completed`, `failed`, `skipped`, `rate_limited`, and `paused_rate_limit`. `rate_limited` is an intermediate non-completed state emitted while the runner waits before retrying; if the run is interrupted there, a later non-`--retry-failed` run treats it as pending work.
|
||||
|
||||
`paused_rate_limit` means a worker hit a Claude session/usage limit. The runner stops scheduling new offers, preserves the retry count, and resumes only when explicitly called with `--resume-paused`.
|
||||
|
||||
## Resumability
|
||||
|
||||
- If it crashes → re-run → reads `batch-state.tsv` → skip completed jobs
|
||||
- Lock file (`batch-runner.pid`) prevents double execution
|
||||
- Each worker is independent: failure in job #47 does not affect the others
|
||||
|
||||
## Workers (headless mode)
|
||||
|
||||
Each worker receives `batch-prompt.md` as a system prompt. It is self-contained. Use your CLI's headless command — see the **Headless / Batch Mode** table in `AGENTS.md`.
|
||||
|
||||
The worker produces:
|
||||
1. `.md` report in `reports/`
|
||||
2. PDF in `output/`
|
||||
3. Tracker line in `batch/tracker-additions/{id}.tsv`
|
||||
4. Result JSON via stdout
|
||||
|
||||
## Error handling
|
||||
|
||||
| Error | Recovery |
|
||||
|-------|----------|
|
||||
| URL inaccessible | Worker fails → conductor marks `failed`, continues |
|
||||
| JD behind login | Conductor attempts to read DOM. If it fails → `failed` |
|
||||
| Portal changes layout | Conductor reasons about HTML, adapts |
|
||||
| Worker crashes | Conductor marks `failed`, continues. Retry with `--retry-failed` |
|
||||
| Claude session/usage limit | Runner marks the current offer `paused_rate_limit`, stops scheduling new offers, preserves retries. Resume with `--resume-paused` after reset. |
|
||||
| Conductor crashes | Re-run → reads state → skip completed jobs |
|
||||
| PDF fails | .md report is saved. PDF remains pending |
|
||||
@@ -0,0 +1,129 @@
|
||||
# Mode: contacto -- Outreach messages
|
||||
|
||||
> Apply `voice-dna.md` (if present) to every generated message — full guardrail, conversational voice included (Tier 1 + Tier 2). See `_shared.md` → Voice DNA.
|
||||
|
||||
This mode has two variants that share the same persona engine (recruiter → hard
|
||||
requirements; hiring manager → impact/vision):
|
||||
|
||||
- **LinkedIn power move** (default) — find contacts and draft a ≤300-char message
|
||||
tied to a specific application/interview. This is the flow below.
|
||||
- **Greeting** — a single ultra-short first-touch message for platforms with a hard
|
||||
character budget (BOSS Zhipin 打招呼, job-board chat, a cold-email opener). No
|
||||
contact discovery. See **Greeting variant** at the end of this file.
|
||||
|
||||
**Pick the variant:** use **Greeting** when the user says "greeting" / "打招呼" /
|
||||
"cold opener", names a chat-style platform (e.g. BOSS Zhipin), or asks for a very
|
||||
short message; otherwise run the LinkedIn power move below.
|
||||
|
||||
## LinkedIn power move (default)
|
||||
|
||||
1. **Identify targets** via WebSearch:
|
||||
- Hiring manager of the team
|
||||
- Assigned recruiter
|
||||
- 2-3 team peers (people with similar roles)
|
||||
- Interviewer (if the candidate already has a scheduled interview)
|
||||
|
||||
2. **Classify contact type** -- ask the candidate or infer from context:
|
||||
- **Recruiter** -- person whose role is talent acquisition, sourcing, or recruiting
|
||||
- **Hiring Manager** -- the person who leads the hiring team
|
||||
- **Peer** -- someone with a similar role in the team (indirect referral)
|
||||
- **Interviewer** -- someone who will interview the candidate (known date)
|
||||
|
||||
3. **Select primary target**: the person who would benefit most from the candidate being there
|
||||
|
||||
4. **Generate message** with a 3-sentence framework adapted to the contact type:
|
||||
|
||||
### Recruiter
|
||||
- **Sentence 1 (Fit)**: Direct match criteria -- role, relevant experience, availability, or location
|
||||
- **Sentence 2 (Proof)**: Data that answers their screening questions before they ask them (e.g., "5 years building ML pipelines, currently in Berlin, available immediately")
|
||||
- **Sentence 3 (CTA)**: "Happy to share my CV if this aligns with what you're looking for"
|
||||
|
||||
### Hiring Manager
|
||||
- **Sentence 1 (Hook)**: Specific challenge their team is facing (extracted from the JD, company blog, or news)
|
||||
- **Sentence 2 (Proof)**: Candidate's greatest quantifiable achievement showing they have solved similar problems
|
||||
- **Sentence 3 (CTA)**: "Would love to hear how your team is approaching [specific challenge]"
|
||||
|
||||
### Peer (referral)
|
||||
- **Sentence 1 (Interest)**: Genuine reference to their work -- blog post, talk, open-source project, or publication
|
||||
- **Sentence 2 (Connection)**: Something the candidate is doing in the same space (NOT a job pitch)
|
||||
- **Sentence 3 (CTA)**: "I've been working on similar problems at [company], would love to hear your take on [topic]"
|
||||
- **Note**: DO NOT ask for a job. The referral happens naturally if the conversation flows.
|
||||
|
||||
### Interviewer (pre-interview)
|
||||
- **Sentence 1 (Research)**: Reference to something specific from their work or trajectory
|
||||
- **Sentence 2 (Context)**: Light connection to the candidate's experience in that area
|
||||
- **Sentence 3 (CTA)**: "Looking forward to our conversation on [date]"
|
||||
- **Note**: Light tone, not desperate. The goal is to show that you prepared.
|
||||
|
||||
5. **Versions**:
|
||||
- EN (default)
|
||||
- ES (if Spanish company)
|
||||
|
||||
6. **Alternative targets** with justification for why they are good second choices
|
||||
|
||||
**Contact channel preference:** Read `contact_preferences.preferred_channel` from
|
||||
`config/profile.yml`. If it is absent or set to `"either"`, write the CTA
|
||||
sentence exactly as specified above — no change. If it is set to `"email"` or
|
||||
`"phone"`, steer the CTA toward that channel instead of the generic default
|
||||
(e.g. Recruiter's CTA becomes "Happy to share my CV over email if this aligns
|
||||
with what you're looking for" rather than defaulting to a call; Hiring
|
||||
Manager's CTA leans on "happy to continue this over email" instead of
|
||||
proposing a call). Keep the same
|
||||
3-sentence structure and per-persona emphasis -- only the channel named in the
|
||||
CTA changes. If `contact_preferences.note` is set, you may fold its intent into
|
||||
the CTA phrasing (e.g. "screens unknown numbers" → prefer email wording) but do
|
||||
not quote the note verbatim in a public-facing message.
|
||||
|
||||
**Message rules:**
|
||||
- Maximum 300 characters (LinkedIn connection request limit)
|
||||
- NO corporate-speak
|
||||
- NO "I'm passionate about..."
|
||||
- Something that makes them want to respond
|
||||
- NEVER share phone number
|
||||
- The contact type changes the EMPHASIS, not the structure
|
||||
|
||||
---
|
||||
|
||||
## Greeting variant
|
||||
|
||||
A single, punchy first-touch message for platforms where the opener has a hard
|
||||
character budget — BOSS Zhipin's 打招呼, job-board chat boxes, or the first line
|
||||
of a cold email. Reuses the persona engine above; the difference is brevity, and
|
||||
that there is **no contact discovery**.
|
||||
|
||||
1. **Skip target identification.** There is no WebSearch/contact-finding step —
|
||||
the message goes to whoever the platform connects you with (usually the poster
|
||||
or the recruiter). Do not fabricate a named recipient.
|
||||
|
||||
2. **Classify the recipient's persona** from context (default to **Recruiter** if
|
||||
unknown) and set the emphasis exactly as above:
|
||||
- **Recruiter** → hard requirements met (role, years, stack, location, availability)
|
||||
- **Hiring Manager / Founder** → impact and vision (a result that maps to their goal)
|
||||
|
||||
3. **Synthesize the top 3 match points** between the JD and `cv.md` (same JD↔profile
|
||||
fit logic the LinkedIn flow uses). These are the raw material — you will surface
|
||||
only the strongest one or two that fit the budget.
|
||||
|
||||
4. **Compose ONE message within the character budget.**
|
||||
- **Budget:** read `outreach.greeting_max_chars` from `config/profile.yml`.
|
||||
**Default 150** when the key is absent. The message MUST fit — count and trim.
|
||||
- **Lead with a specific value proposition** (the single strongest match point),
|
||||
not an introduction. Punchy sentences, not paragraphs.
|
||||
- **Language:** match the JD / platform language (e.g. Simplified Chinese for
|
||||
BOSS Zhipin). Character count applies to the output language.
|
||||
|
||||
5. **No-fluff policy (hard):** remove filler and replace it with a concrete value
|
||||
prop. Ban phrases like "I'm looking for a job", "I'm passionate about",
|
||||
"I hope to have the opportunity", generic self-description. Every clause must
|
||||
earn its characters.
|
||||
|
||||
6. **Output:** the greeting, its character count vs the budget, and a one-line note
|
||||
of which match point(s) it used. Offer a shorter fallback if it's near the limit.
|
||||
|
||||
**Greeting rules:**
|
||||
- Platform-agnostic — never assume LinkedIn; works for any chat/opener surface.
|
||||
- Within `outreach.greeting_max_chars` (default 150). Never exceed it.
|
||||
- Same non-fabrication rule as the rest of career-ops: reformulate real experience
|
||||
from `cv.md`, never invent a skill, metric, or claim.
|
||||
- NO corporate-speak, NO "I'm passionate about...", NEVER share a phone number.
|
||||
- Persona changes the EMPHASIS, not the structure.
|
||||
+333
@@ -0,0 +1,333 @@
|
||||
# Mode: cover — Cover Letter Generator
|
||||
|
||||
Generates a tailored cover letter for any candidate from a job description.
|
||||
Works in two modes:
|
||||
- **Slug mode:** `/career-ops cover {slug}` — loads the existing evaluation report draft as a starting point
|
||||
- **Paste mode:** `/career-ops cover` or JD pasted directly — starts from scratch
|
||||
|
||||
---
|
||||
|
||||
## Step 0 — JD Gate (mandatory)
|
||||
|
||||
Before doing anything, confirm a job description is present.
|
||||
|
||||
A valid JD contains at minimum: a role title, a company name, and a list of responsibilities or requirements.
|
||||
|
||||
- **No JD present** → Stop. Say: "Please paste the job description — I need it to tailor the letter."
|
||||
- **Slug provided** → Read `reports/` to find the matching report. Extract the `## Cover Letter Draft` section as a starting point. Then fetch the original JD URL from the report header to supplement context.
|
||||
- **JD present** → Proceed to Step 1.
|
||||
|
||||
Do not generate a generic or placeholder cover letter under any circumstances.
|
||||
|
||||
---
|
||||
|
||||
## Step 1 — Load candidate profile
|
||||
|
||||
Read `config/profile.yml` for:
|
||||
- `candidate.name`, `email`, `phone`, `location`, `linkedin`, `github`
|
||||
- `candidate.credentials` (derive from cv.md Education + Certifications if not in profile.yml)
|
||||
- `cover_letter.notice_period_days` (default: omit if key absent)
|
||||
- `cover_letter.primary_domain` (default: infer from cv.md if absent)
|
||||
- `cover_letter.language_learning` (default: empty list if absent)
|
||||
|
||||
Read `cv.md` for:
|
||||
- Professional summary (profile introduction source)
|
||||
- All achievement bullets across all roles (achievement selection pool)
|
||||
|
||||
Read `article-digest.md` if it exists — supplementary proof points and metrics take precedence over cv.md where they overlap.
|
||||
|
||||
Read `modes/_profile.md` if it exists — the candidate's personalization file. It captures their target roles, adaptive framing and archetypes, exit narrative, cross-cutting advantage, proof points, comp targets, negotiation scripts, location policy, and any voice or writing-style rules they have added. Its rules **govern the letter's voice and structure and override the generic defaults in this mode**, so the candidate's personalization is never lost.
|
||||
|
||||
---
|
||||
|
||||
## Step 2 — Parse the JD
|
||||
|
||||
Extract:
|
||||
- **Role title** (exact wording from JD)
|
||||
- **Company name**
|
||||
- **Location / city**
|
||||
- **Top 3-4 required competencies** (from requirements or responsibilities section)
|
||||
- **Mission/vision language** the company uses (opening paragraphs)
|
||||
- **Domain** (e.g. fintech, healthcare, media, logistics) — compare against `cover_letter.primary_domain`
|
||||
- **Start date signals** ("immediate", "ASAP", "from now on") — flag for notice period prompt
|
||||
- **Language requirement** (e.g. "German B2 required") — flag for language gap prompt
|
||||
- **JD tone** (formal / direct / casual) — used in tone prompt default suggestion
|
||||
|
||||
---
|
||||
|
||||
## Step 3 — Company research (baked in, not optional)
|
||||
|
||||
Run three WebSearch queries (substitute the actual current year for {year}):
|
||||
1. `"{company}" product strategy OR roadmap {year}`
|
||||
2. `"{company}" challenges OR problems OR priorities {year}`
|
||||
3. `"{company}" news OR announcement OR funding {year}`
|
||||
|
||||
Synthesize findings into 2-3 sentences: what the company is working on, what challenges they face, what goals they've stated publicly.
|
||||
|
||||
Present to the user:
|
||||
|
||||
```text
|
||||
Here's what I found about {company}:
|
||||
|
||||
{2-3 sentence synthesis}
|
||||
|
||||
Does this match what you know? Correct or add anything before I write the letter.
|
||||
```
|
||||
|
||||
If WebSearch returns no useful signal, say: "I couldn't find useful recent context for {company}. Can you share what you know about their current challenges or goals?"
|
||||
|
||||
Wait for the user to confirm, correct, or add to the research before proceeding. This synthesis feeds directly into the "Problems I will solve" section.
|
||||
|
||||
---
|
||||
|
||||
## Step 4 — Keyword extraction
|
||||
|
||||
Extract the top 8-10 exact phrases the company uses in the JD. Separate into two groups:
|
||||
|
||||
**ATS-critical** — exact terms likely scanned by automated systems:
|
||||
- Role-specific titles, tool names, methodology names
|
||||
|
||||
**Human trust signals** — language that shows you read the actual posting:
|
||||
- Action verbs the company uses ("own", "drive", "define")
|
||||
- Product/domain nouns as the company names them
|
||||
- Outcome language ("business impact", "time to insight")
|
||||
- Team framing ("embedded in", "partner with")
|
||||
|
||||
Present to the user:
|
||||
|
||||
```text
|
||||
Keywords I'll mirror from the JD:
|
||||
|
||||
ATS-critical:
|
||||
• [keyword]
|
||||
• [keyword]
|
||||
|
||||
Language signals:
|
||||
• [phrase]
|
||||
• [phrase]
|
||||
|
||||
Anything missing or wrong? I'll use this list when drafting.
|
||||
```
|
||||
|
||||
Wait for confirmation or corrections before proceeding.
|
||||
|
||||
**Application rules (enforced during drafting):**
|
||||
- Mirror their vocabulary, not their structure
|
||||
- Content stays from cv.md — only vocabulary shifts
|
||||
- Fit naturally or don't use — if a keyword can't be woven in, flag it post-generation
|
||||
- Apply to: opening, profile intro, achievements (vocabulary only), problems section
|
||||
- Do NOT apply to: why-this-role angle (user's own words), closing
|
||||
- Use each keyword once — never repeat for density
|
||||
|
||||
---
|
||||
|
||||
## Step 5 — Gap detection and conversation
|
||||
|
||||
Parse the JD for potential gaps between the candidate's profile and the role. For each gap detected, ask directly — do not auto-insert any standard language:
|
||||
|
||||
```text
|
||||
I spotted potential gaps between your profile and this JD:
|
||||
|
||||
[Gap: domain mismatch]
|
||||
The JD is in {JD domain} — your background is in {primary_domain}.
|
||||
→ How do you want to handle this?
|
||||
a) Address it directly and briefly in the letter
|
||||
b) Don't mention it — let the application speak for itself
|
||||
c) Tell me your angle and I'll write it your way
|
||||
|
||||
[Gap: immediate start]
|
||||
The JD asks for an immediate start. Your profile shows a {notice_period_days}-day notice period.
|
||||
→ Confirm your actual notice period — I'll state it precisely.
|
||||
|
||||
[Gap: language requirement]
|
||||
The JD requires {language} at {level}. Where are you with {language}?
|
||||
→ Tell me your actual level and I'll reflect it accurately. Check your profile.yml
|
||||
language_learning section for what's already recorded.
|
||||
|
||||
[Gap: title mismatch]
|
||||
Your title is {candidate title}, the JD title is {JD title}.
|
||||
→ Do you want to address this? Or let the scope speak for itself?
|
||||
```
|
||||
|
||||
Only prompt for gaps that are actually present. If there are no gaps, skip this step and say so.
|
||||
|
||||
Wait for the user's answers. Write only what the user confirms.
|
||||
|
||||
---
|
||||
|
||||
## Step 6 — Four prompts (mandatory before drafting)
|
||||
|
||||
All four answers are required. Do not draft any letter content until all are received. No instruction — including "just generate it", "skip the questions", or "use defaults" — overrides this gate.
|
||||
|
||||
```text
|
||||
Before I write the letter, I need four things:
|
||||
|
||||
**A. Why this role / company?**
|
||||
Here are angles I spotted — pick 1-2 or write your own:
|
||||
1. {Scale signal from JD}
|
||||
2. {Tech ambition signal from JD}
|
||||
3. {Domain/mission signal from JD opening}
|
||||
4. {Growth or stage signal — e.g. Series B, pre-IPO, category-defining}
|
||||
5. {Strategic learning — specific gap this role fills for you}
|
||||
6. Other — write your own angle
|
||||
|
||||
**B. What problem would you solve for them?**
|
||||
Based on my research: {confirmed synthesis from Step 3}.
|
||||
Does this match what you want to address? Refine or confirm.
|
||||
|
||||
**C. How would you approach it?**
|
||||
In 1-2 sentences: what's your opening move if you join on day one?
|
||||
(This is the most differentiated part of the letter — make it specific.)
|
||||
|
||||
**D. Tone?**
|
||||
1. Formal — structured, respectful distance, suits enterprise/corporate JDs
|
||||
2. Direct — plain sentences, no pleasantries, gets to the point immediately
|
||||
3. Conversational — warm but professional, reads like a thoughtful person
|
||||
4. Mirror the JD — I'll match whatever register the company used
|
||||
```
|
||||
|
||||
Wait for all four answers before proceeding to Step 7.
|
||||
|
||||
---
|
||||
|
||||
## Step 7 — Achievement selection (from cv.md only)
|
||||
|
||||
Select 4-5 achievement bullets from `cv.md` only (`article-digest.md` may be read for context but is not a source of achievement bullets):
|
||||
1. Read all bullet points across all roles in cv.md
|
||||
2. Score each against the JD's top 3-4 required competencies
|
||||
3. Pick the 4-5 highest-scoring, with at least one metric per bullet
|
||||
4. Use the exact wording and metrics from cv.md — never paraphrase or invent
|
||||
5. Apply keyword mirroring from Step 4 to the vocabulary around each bullet (not the metrics)
|
||||
|
||||
Format: `**Bold lead phrase,** one sentence of impact with metric.`
|
||||
|
||||
---
|
||||
|
||||
## Step 8 — Draft the letter in chat (mandatory before PDF)
|
||||
|
||||
Write the full letter as plain text in the chat. Follow this structure:
|
||||
|
||||
```text
|
||||
[Candidate Name]
|
||||
[Location] | [Email] | [Phone if available] | [LinkedIn if available]
|
||||
[Credentials line if available]
|
||||
|
||||
Cover Letter: [Role Title]
|
||||
[Company], [City] [Date]
|
||||
|
||||
────────────────────────────────────────────────
|
||||
|
||||
[Salutation — optional]
|
||||
Address the named hiring manager if known, e.g. "Dear Jane Smith,". Omit if no name.
|
||||
|
||||
[Opening — 2 sentences]
|
||||
Why applying + functional summary. Derived from Angle A. Uses JD mirror vocabulary.
|
||||
|
||||
[Profile introduction — 1 paragraph]
|
||||
Years of experience, current/most recent role, domain. Read from cv.md summary.
|
||||
Tone matches user's choice from Step 6D.
|
||||
|
||||
[Achievements — 4-5 bullets]
|
||||
• **Lead phrase,** impact sentence with metric.
|
||||
• **Lead phrase,** impact sentence with metric.
|
||||
• **Lead phrase,** impact sentence with metric.
|
||||
• **Lead phrase,** impact sentence with metric.
|
||||
|
||||
[Problems I will solve — 2-3 sentences]
|
||||
Derived from: confirmed research (Step 3) + Angle B + Angle C.
|
||||
Specific to this company's actual situation. Not generic.
|
||||
|
||||
[Closing — 1-2 sentences]
|
||||
Availability + any gap acknowledgments the user chose to include (Step 5).
|
||||
|
||||
[Language closing — if applicable]
|
||||
Only if user confirmed inclusion in Step 5. Written in that language. Italic in PDF.
|
||||
```
|
||||
|
||||
End the draft with: "How does this read? Once you approve I'll generate the PDF."
|
||||
|
||||
**Do NOT generate any PDF until the user explicitly approves.** Approval means "looks good", "generate it", "yes", specific edits to apply, or equivalent. A question or silence is not approval.
|
||||
|
||||
---
|
||||
|
||||
## Language rules (enforced in every sentence)
|
||||
|
||||
1. **Active voice only** — never "was delivered", "has been built", "were led"
|
||||
2. **No abbreviations unless JD used them first** — write the full term on first use with abbreviation in brackets. After that, abbreviation is fine.
|
||||
3. **No em dashes** — replace with a comma, full stop, or rewrite the sentence
|
||||
4. **No buzzwords** — hard ban: leverage, synergy, seamless, holistic, robust, cutting-edge, spearheaded, championed, orchestrated, passionate, excited, stakeholder alignment, data-driven (say what the data drove instead), actionable insights, move the needle, north star, unique opportunity, perfect fit, strong track record
|
||||
5. **No filler openers** — never "I am pleased to", "I am writing to express", "I am excited to"
|
||||
6. **Concrete over abstract** — every claim needs a number, system name, or specific outcome. "Improved performance" is banned. "Cut latency from 2s to 380ms" is fine.
|
||||
7. **350-420 words** total body (header + credentials not counted)
|
||||
8. **Bullet format** — `**Bold lead phrase,** impact sentence with metric.` No em dash between lead and sentence.
|
||||
9. **Self-check** — before finalising, re-read each sentence: could it appear in any cover letter for any company? If yes, rewrite it.
|
||||
10. **Tone consistency** — apply the chosen tone (Step 6D) uniformly. Don't shift register mid-letter.
|
||||
|
||||
---
|
||||
|
||||
## Step 9 — Generate PDF
|
||||
|
||||
Only after explicit user approval.
|
||||
|
||||
Assemble the JSON payload:
|
||||
|
||||
```json
|
||||
{
|
||||
"candidate": {
|
||||
"name": "{from profile.yml}",
|
||||
"email": "{from profile.yml}",
|
||||
"phone": "{from profile.yml, omit if empty}",
|
||||
"location": "{from profile.yml}",
|
||||
"linkedin": "{from profile.yml, omit if empty}",
|
||||
"github": "{from profile.yml, omit if empty}",
|
||||
"credentials": ["{degree}", "{MBA}", "{cert}"]
|
||||
},
|
||||
"letter": {
|
||||
"role_title": "{exact from JD}",
|
||||
"company": "{company name}",
|
||||
"city": "{JD city}",
|
||||
"date": "{YYYY-MM-DD}",
|
||||
"greeting": "{optional salutation, e.g. 'Dear Jane Smith,'; omit the key to skip the salutation}",
|
||||
"opening": "{approved opening paragraph}",
|
||||
"profile_intro": "{approved profile intro}",
|
||||
"achievements": [
|
||||
{"lead": "...", "impact": "..."}
|
||||
],
|
||||
"problems_section": "{approved problems paragraph}",
|
||||
"closing": "{approved closing}",
|
||||
"language_closing": "{approved language sentence or null}"
|
||||
},
|
||||
"output_path": "output/{company-slug}-{role-slug}-cover.pdf"
|
||||
}
|
||||
```
|
||||
|
||||
Write payload to `/tmp/cover-payload-{company-slug}.json`.
|
||||
|
||||
Run:
|
||||
```bash
|
||||
node generate-cover-letter.mjs --payload /tmp/cover-payload-{company-slug}.json
|
||||
```
|
||||
|
||||
Report the output path and file size.
|
||||
|
||||
---
|
||||
|
||||
## Step 10 — Post-generation note
|
||||
|
||||
After the PDF is confirmed, add a brief note:
|
||||
|
||||
- Any JD keywords from Step 4 that could not be incorporated naturally (flag for manual review)
|
||||
- Which gap acknowledgments were included and which were omitted, and why
|
||||
- Whether the word count hit the 350-420 target (if short or long, note it)
|
||||
|
||||
---
|
||||
|
||||
## Slug mode specifics
|
||||
|
||||
When invoked as `/career-ops cover {slug}`:
|
||||
|
||||
1. Find the matching report in `reports/` by slug
|
||||
2. Extract the `## Cover Letter Draft` section — use it as a pre-populated starting point for the draft
|
||||
3. Run all steps as normal (research, keywords, prompts, gaps) — the draft is a starting point, not the final output
|
||||
4. When presenting the draft in Step 8, show what was auto-generated and what was changed based on the user's answers
|
||||
5. After PDF generation, update the report's `## Cover Letter Draft` section with a note: `PDF generated: output/{path} on {date}`
|
||||
@@ -0,0 +1,103 @@
|
||||
# career-ops -- Danske modes (`modes/da/`)
|
||||
|
||||
Denne mappe indeholder de danske oversættelser af de vigtigste career-ops-modes for kandidater, der søger på det danske marked.
|
||||
|
||||
## Hvornår skal du bruge disse modes?
|
||||
|
||||
Brug `modes/da/`, hvis mindst én af disse betingelser er opfyldt:
|
||||
|
||||
- Du søger primært **jobopslag på dansk** (Jobindex, The Hub, LinkedIn DK, virksomhedernes karrieresider, Jobnet)
|
||||
- Dit **CV er på dansk**, eller du skifter mellem DA og EN afhængigt af opslaget
|
||||
- Du har brug for svar og ansøgninger på **naturligt tech-dansk**, ikke maskinoversat
|
||||
- Du skal håndtere **danske kontraktspecifikke forhold**: overenskomst, funktionærloven, ferie efter ferieloven, opsigelsesvarsel, prøvetid, pension, feriepenge, A-kasse, fagforening
|
||||
|
||||
Hvis de fleste af dine opslag er på engelsk, så bliv ved standard-modes i `modes/`. De engelske modes fungerer til danske opslag, men de kender ikke det danske markeds særtræk i detaljen.
|
||||
|
||||
## Hvordan aktiverer du dem?
|
||||
|
||||
### Mulighed 1 -- Per session
|
||||
|
||||
Sig til Claude i starten af sessionen:
|
||||
|
||||
> "Brug de danske modes under `modes/da/`."
|
||||
|
||||
Claude vil så læse filerne i denne mappe i stedet for `modes/`.
|
||||
|
||||
### Mulighed 2 -- Permanent
|
||||
|
||||
Tilføj i `config/profile.yml`:
|
||||
|
||||
```yaml
|
||||
language:
|
||||
primary: da
|
||||
modes_dir: modes/da
|
||||
```
|
||||
|
||||
Mind Claude om det i din første session ("Kig i `profile.yml`, jeg har konfigureret `language.modes_dir`"). Claude bruger så automatisk de danske modes.
|
||||
|
||||
## Hvilke modes er oversat?
|
||||
|
||||
Denne første iteration dækker de fire modes med størst effekt:
|
||||
|
||||
| Fil | Oversat fra | Rolle |
|
||||
|-----|-------------|-------|
|
||||
| `_shared.md` | `modes/_shared.md` (EN) | Delt kontekst, arketyper, globale regler, særtræk ved det danske marked |
|
||||
| `oferta.md` | `modes/oferta.md` (ES) | Fuld evaluering af et opslag (Blok A-F) |
|
||||
| `apply.md` | `modes/apply.md` (EN) | Live-assistent til udfyldelse af ansøgningsformularer |
|
||||
| `pipeline.md` | `modes/pipeline.md` (ES) | URL-indbakke / Second Brain til indsamlede opslag |
|
||||
|
||||
De øvrige modes (`scan`, `batch`, `pdf`, `tracker`, `auto-pipeline`, `deep`, `contacto`, `ofertas`, `project`, `training`) forbliver på EN/ES. Deres indhold er primært tooling, stier og kommandoer -- det skal forblive sproguafhængigt.
|
||||
|
||||
## Hvad forbliver på engelsk
|
||||
|
||||
Bevidst ikke oversat, fordi det er standard tech-ordforråd:
|
||||
|
||||
- `cv.md`, `pipeline`, `tracker`, `report`, `score`, `archetype`, `proof point`
|
||||
- Værktøjsnavne (`Playwright`, `WebSearch`, `WebFetch`, `Read`, `Write`, `Edit`, `Bash`)
|
||||
- Statusværdier i trackeren (`Evaluated`, `Applied`, `Interview`, `Offer`, `Rejected`)
|
||||
- Kodeuddrag, stier, kommandoer
|
||||
|
||||
Modes bruger naturligt tech-dansk, sådan som det tales i engineering-teams i København, Aarhus eller Odense: løbende tekst på dansk, tekniske termer på engelsk dér, hvor det er normen. Ingen tvungen oversættelse af "Pipeline" til "Rørledning" eller "Deploy" til "Udrulning".
|
||||
|
||||
## Referenceordliste
|
||||
|
||||
For at holde tonen konsistent, hvis du ændrer eller udvider modes:
|
||||
|
||||
| Engelsk | Dansk (i denne codebase) |
|
||||
|---------|--------------------------|
|
||||
| Job posting | Jobopslag / Stillingsopslag |
|
||||
| Application | Ansøgning |
|
||||
| Cover letter | Ansøgning (motiveret) / Følgebrev |
|
||||
| Resume / CV | CV |
|
||||
| Salary | Løn / Aflønning |
|
||||
| Compensation | Aflønning / Pakke |
|
||||
| Skills | Kompetencer |
|
||||
| Interview | Samtale / Jobsamtale |
|
||||
| Hiring manager | Ansættende leder / Hiring manager |
|
||||
| Recruiter | Rekrutteringskonsulent (eller Recruiter) |
|
||||
| AI | AI (kunstig intelligens) |
|
||||
| Requirements | Krav / Forudsætninger |
|
||||
| Career history | Karriereforløb / Erhvervserfaring |
|
||||
| Notice period | Opsigelsesvarsel |
|
||||
| Probation | Prøvetid |
|
||||
| Vacation | Ferie |
|
||||
| Holiday pay | Feriepenge |
|
||||
| Permanent employment | Fastansættelse (tidsubegrænset) |
|
||||
| Fixed-term contract | Tidsbegrænset ansættelse |
|
||||
| Freelance | Freelance / Selvstændig |
|
||||
| Collective agreement | Overenskomst |
|
||||
| Salaried-employee act | Funktionærloven |
|
||||
| Holiday act | Ferieloven |
|
||||
| Trade union | Fagforening |
|
||||
| Unemployment insurance fund | A-kasse |
|
||||
| Pension | Pension (arbejdsgiverbidrag) |
|
||||
|
||||
## Bidrag
|
||||
|
||||
For at forbedre en oversættelse eller tilføje en mode:
|
||||
|
||||
1. Åbn en Issue med dit forslag (se `CONTRIBUTING.md`)
|
||||
2. Følg ordlisten ovenfor for at holde tonen konsistent
|
||||
3. Oversæt idiomatisk -- ingen ord-for-ord-oversættelse
|
||||
4. Bevar de strukturelle elementer (Blok A-F, tabeller, kodeblokke, værktøjsinstruktioner) uændret
|
||||
5. Test med et rigtigt dansk opslag (Jobindex, The Hub, LinkedIn DK), før du sender din PR
|
||||
@@ -0,0 +1,203 @@
|
||||
# Delt kontekst -- career-ops (Dansk)
|
||||
|
||||
<!-- ============================================================
|
||||
TILPASNING AF DENNE FIL
|
||||
============================================================
|
||||
Denne fil indeholder den delte kontekst for alle career-ops-modes
|
||||
i den danske version. Før du bruger career-ops, SKAL du:
|
||||
1. Udfylde config/profile.yml med dine personlige oplysninger
|
||||
2. Oprette cv.md i projektets rod (CV i Markdown)
|
||||
3. (Valgfrit) Oprette article-digest.md med dine proof points
|
||||
4. Tilpasse de afsnit, der er markeret med [TILPAS] nedenfor
|
||||
============================================================ -->
|
||||
|
||||
## Kilder til sandhed (læs ALTID før hver evaluering)
|
||||
|
||||
| Fil | Sti | Hvornår |
|
||||
|-----|-----|---------|
|
||||
| cv.md | `cv.md` (projektets rod) | ALTID |
|
||||
| article-digest.md | `article-digest.md` (hvis den findes) | ALTID (detaljerede proof points) |
|
||||
| profile.yml | `config/profile.yml` | ALTID (identitet og målroller) |
|
||||
|
||||
**REGEL: Aldrig hardcode metrics fra proof points.** Læs dem fra `cv.md` og `article-digest.md` på evalueringstidspunktet.
|
||||
**REGEL: For metrics om artikler/projekter har `article-digest.md` forrang frem for `cv.md`** (`cv.md` kan indeholde ældre tal).
|
||||
|
||||
---
|
||||
|
||||
## North Star -- Målroller
|
||||
|
||||
Dette skill behandler ALLE målroller med samme omhu. Ingen er primær eller sekundær -- hver enkelt er en succes, hvis aflønning og udviklingsmuligheder er til stede:
|
||||
|
||||
| Arketype | Tematiske akser | Hvad virksomheden køber |
|
||||
|----------|-----------------|-------------------------|
|
||||
| **AI Platform / LLMOps Engineer** | Evaluation, Observability, Pålidelighed, Pipelines | En der sætter AI i produktion med metrics |
|
||||
| **Agentic Workflows / Automation** | HITL, Tooling, Orkestrering, Multi-Agent | En der bygger pålidelige agent-systemer |
|
||||
| **Technical AI Product Manager** | GenAI/Agents, PRDs, Discovery, Delivery | En der oversætter forretning til AI-produkter |
|
||||
| **AI Solutions Architect** | Hyperautomation, Enterprise, Integrationer | En der designer end-to-end AI-arkitekturer |
|
||||
| **AI Forward Deployed Engineer** | Client-facing, Hurtig levering, Prototyping | En der hurtigt udruller AI-løsninger hos kunden |
|
||||
| **AI Transformation Lead** | Forandringsledelse, Adoption, Enablement | En der driver AI-transformation i organisationer |
|
||||
|
||||
<!-- [TILPAS] Tilpas arketyperne ovenfor til dine målroller.
|
||||
Eksempel for backend engineering:
|
||||
- Senior Backend Engineer
|
||||
- Staff Platform Engineer
|
||||
- Engineering Manager
|
||||
osv. -->
|
||||
|
||||
### Adaptiv framing efter arketype
|
||||
|
||||
> **Konkrete metrics: læs dem fra `cv.md` og `article-digest.md` på evalueringstidspunktet. ALDRIG hardcode dem her.**
|
||||
|
||||
| Hvis rollen er... | Fremhæv hos kandidaten... | Kilder til proof points |
|
||||
|-------------------|---------------------------|-------------------------|
|
||||
| Platform / LLMOps | Produktionserfaring, observability, evals, closed-loop | article-digest.md + cv.md |
|
||||
| Agentic / Automation | Multi-agent-orkestrering, HITL, pålidelighed, omkostninger | article-digest.md + cv.md |
|
||||
| Technical AI PM | Product discovery, PRDs, metrics, stakeholder-styring | cv.md + article-digest.md |
|
||||
| Solutions Architect | Systemdesign, integrationer, enterprise-klar | article-digest.md + cv.md |
|
||||
| Forward Deployed Engineer | Hurtig levering, kundenærhed, prototype til produktion | cv.md + article-digest.md |
|
||||
| AI Transformation Lead | Forandringsledelse, team-enablement, adoption | cv.md + article-digest.md |
|
||||
|
||||
<!-- [TILPAS] Knyt dine konkrete projekter/artikler til arketyperne ovenfor -->
|
||||
|
||||
### Overgangsnarrativ (skal bruges i ALLE framings)
|
||||
|
||||
<!-- [TILPAS] Erstat med dit eget narrativ. Eksempler:
|
||||
- "SaaS bygget og solgt efter 5 år. Nu 100% fokus på anvendt AI i enterprise."
|
||||
- "Engineering-lead i en Series-B under 10x vækst. Søger den næste udfordring."
|
||||
- "Skift fra konsulent til produkt. Søger roller med højt ansvar."
|
||||
Læses fra config/profile.yml -> narrative.exit_story -->
|
||||
|
||||
Brug overgangsnarrativet fra `config/profile.yml` til at ramme ALT indhold ind:
|
||||
- **I PDF-summaries:** Byg bro mellem fortid og fremtid -- "Anvender nu de samme [kompetencer] på [opslagets domæne]."
|
||||
- **I STAR-stories:** Referér til proof points fra `article-digest.md`.
|
||||
- **I draft-svar (Blok G):** Overgangsnarrativet hører til i det første svar.
|
||||
- **Når opslaget nævner "entrepreneurial", "ownership", "builder", "end-to-end":** Det er DEN vigtigste differentiator nr. 1. Øg match-vægten.
|
||||
|
||||
### Tværgående fordel
|
||||
|
||||
Ram profilen ind som **"Teknisk builder med dokumenteret praksis"**, og tilpas framingen til rollen:
|
||||
- For PM: "Builder, der reducerer usikkerhed med prototyper og derefter leverer disciplineret i produktion"
|
||||
- For FDE: "Builder, der leverer fra dag 1 med observability og metrics"
|
||||
- For SA: "Builder, der designer end-to-end-systemer med ægte integrationserfaring"
|
||||
- For LLMOps: "Builder, der sætter AI i produktion med closed-loop kvalitetssystemer"
|
||||
|
||||
Positionér "Builder" som et professionelt signal -- ikke som "hobbyist". De ægte proof points gør det troværdigt.
|
||||
|
||||
### Portfolio som proof point (brug ved ansøgninger med høj indsats)
|
||||
|
||||
<!-- [TILPAS] Hvis du har en live demo, et dashboard eller et offentligt projekt, så konfigurér det her.
|
||||
Eksempel:
|
||||
dashboard:
|
||||
url: "https://ditdomæne.dev/demo"
|
||||
password: "demo-2026"
|
||||
when_to_share: "LLMOps, AI Platform, Observability-roller"
|
||||
Læses fra config/profile.yml -> narrative.proof_points og narrative.dashboard -->
|
||||
|
||||
Hvis kandidaten har en live demo / et dashboard (tjek `profile.yml`), så tilbyd adgang i relevante ansøgninger.
|
||||
|
||||
### Lønintelligens (Comp Intelligence)
|
||||
|
||||
<!-- [TILPAS] Undersøg lønintervaller for dine målroller og tilpas værdierne -->
|
||||
|
||||
**Generelle råd:**
|
||||
- WebSearch for aktuelle markedsdata (Glassdoor, Levels.fyi, Jobindex Lønstatistik, IDA Lønstatistik, PROSA)
|
||||
- Ram ind efter jobtitel, ikke efter kompetencer -- titler definerer lønbåndene
|
||||
- Freelance-satser i Danmark ligger typisk 30-50% over den tilsvarende brutto-timeløn i en fastansættelse (sociale bidrag, ferie, sygdom, opsøgende arbejde)
|
||||
- Geo-arbitrage fungerer i remote: lavere leveomkostninger = bedre netto
|
||||
|
||||
### Det danske marked -- Særtræk (VIGTIGT)
|
||||
|
||||
I danske opslag og forhandlinger optræder visse termer, som ikke findes på EN/ES-markederne. De SKAL håndteres korrekt:
|
||||
|
||||
| Term | Betydning | Effekt på evaluering |
|
||||
|------|-----------|----------------------|
|
||||
| **Fastansættelse** (tidsubegrænset) | Svarer til "permanent employment". Standarden i Danmark | Forventet standard. En tidsbegrænset kontrakt til en senior er et advarselssignal |
|
||||
| **Tidsbegrænset ansættelse** | Midlertidig kontrakt med fast slutdato | Acceptabel til specifikke opgaver. Ellers spørg hvorfor ikke fastansættelse |
|
||||
| **Prøvetid** | Typisk 3 måneder, kortere opsigelsesvarsel | Markedsstandard. Flag hvis > 3 måneder |
|
||||
| **Opsigelsesvarsel** | 1-6 måneder efter funktionærloven afhængigt af anciennitet | Planlæg startdato derefter |
|
||||
| **Funktionærloven** | Lov der regulerer funktionærers ansættelse (opsigelse, sygdom, fratrædelsesgodtgørelse) | Næsten alle tech-stillinger er funktionærstillinger. Tjek om det nævnes |
|
||||
| **Overenskomst** | Kollektiv aftale mellem fagforening og arbejdsgiver. Fastsætter løn, vilkår | Tjek om virksomheden har overenskomst -- giver fast løntrin, pension, sikkerhed |
|
||||
| **Feriepenge** | 12,5% af lønnen optjent til ferie efter ferieloven | Indgår i den samlede pakke. Glem ALDRIG i sammenligningen |
|
||||
| **Ferie** | 25 dage (5 uger) efter ferieloven. Mange giver flere | < 25 dage = under lovens minimum. 25 + feriefridage = standard i tech. > 30 dage = fremragende |
|
||||
| **Feriefridage** | Ekstra fridage ud over ferielovens 5 uger (ofte 5/år) | Et reelt plus. Svarer til 1 uges ekstra ferie |
|
||||
| **Pension** | Arbejdsgiverbidrag, typisk 8-12% af lønnen | Indgår i comp-beregningen: kan udgøre flere tusind kroner månedligt. Glem den ikke |
|
||||
| **A-kasse** | Frivillig arbejdsløshedsforsikring (medlemskab betales af medarbejderen) | Ikke et arbejdsgivergode, men relevant for jobsikkerhed. Tjek opsigelsesvilkår |
|
||||
| **Fagforening** | Faglig organisation (fx PROSA, IDA for ingeniører/IT) | Medlemskab giver juridisk hjælp og overenskomstdækning. Plus for stabilitet |
|
||||
| **Bruttoløn / Nettoløn** | Løn før / efter skat (dansk skat er høj, ~37-52%) | Forhandl altid om bruttoløn. Beregn netto til sammenligning af leveomkostninger |
|
||||
| **13. månedsløn** | Findes typisk IKKE i Danmark (i modsætning til mange markeder) | Forvent den ikke. Hvis nævnt, er det et ekstra plus -- inkludér i comp |
|
||||
|
||||
### Forhandlingsscripts
|
||||
|
||||
<!-- [TILPAS] Tilpas til din situation -->
|
||||
|
||||
**Lønforventning (generelt framework):**
|
||||
> "På baggrund af aktuelle markedsdata for denne type stilling sigter jeg efter intervallet [INTERVAL fra profile.yml]. Jeg er fleksibel omkring strukturen -- det er den samlede pakke og udviklingsmulighederne, der tæller."
|
||||
|
||||
**Modsvar på et geografisk fradrag:**
|
||||
> "De roller, jeg er i konkurrence om, er resultatorienterede, ikke lokationsbestemte. Min track record ændrer sig ikke med postnummeret."
|
||||
|
||||
**Hvis tilbuddet ligger under målet:**
|
||||
> "Jeg er i øjeblikket i dialog om pakker i intervallet [højere interval]. [Virksomhed] tiltrækker mig på grund af [grund]. Er det muligt at nå [mål]?"
|
||||
|
||||
**Forhandling om pension / variabel løn:**
|
||||
> "For at sammenligne pakkerne retfærdigt -- kunne I specificere den faste bruttoløn, pensionsbidraget og en eventuel variabel del hver for sig?"
|
||||
|
||||
### Lokationspolitik (Location Policy)
|
||||
|
||||
<!-- [TILPAS] Tilpas til din situation. Læses fra config/profile.yml -> location -->
|
||||
|
||||
**I formularer:**
|
||||
- Binære spørgsmål "Kan du være på kontoret?": svar efter den reelle tilgængelighed i `profile.yml`
|
||||
- Fritekstfelter: angiv tidszoneoverlap og tilgængelighed eksplicit
|
||||
|
||||
**I evalueringer (scoring):**
|
||||
- Remote-dimension for hybrid uden for dit land: Score **3.0** (ikke 1.0)
|
||||
- Score 1.0 kun, hvis opslaget eksplicit siger "obligatorisk tilstedeværelse 4-5 dage/uge, ingen undtagelser"
|
||||
|
||||
### Time-to-offer-prioritet
|
||||
- Fungerende demo + metrics > perfektion
|
||||
- Ansøg hurtigt > lær mere
|
||||
- 80/20-tilgang, alt er timeboxet
|
||||
|
||||
---
|
||||
|
||||
## Globale regler
|
||||
|
||||
### ALDRIG
|
||||
|
||||
1. Opfinde erfaring eller metrics
|
||||
2. Ændre `cv.md` eller portfolio-filer
|
||||
3. Indsende ansøgninger på kandidatens vegne
|
||||
4. Dele et telefonnummer i genererede beskeder
|
||||
5. Anbefale aflønning under markedsniveau
|
||||
6. Generere en PDF uden at have læst opslaget først
|
||||
7. Bruge corporate-jargon eller tomme floskler
|
||||
8. Ignorere trackeren (hvert evalueret opslag registreres)
|
||||
|
||||
### ALTID
|
||||
|
||||
0. **Ansøgning (følgebrev):** Hvis formularen tillader det, så inkludér ALTID én. PDF i samme visuelle design som CV'et. Citater fra opslaget mappet til proof points. Maks. 1 side.
|
||||
1. Læs `cv.md` og `article-digest.md` (hvis den findes), før et opslag evalueres
|
||||
1b. **Første evaluering i hver session:** Kør `node cv-sync-check.mjs` via Bash. Ved advarsler, informér kandidaten
|
||||
2. Detektér rollens arketype og tilpas framingen
|
||||
3. Citér eksakte linjer fra CV'et ved matching
|
||||
4. Brug WebSearch til løn- og virksomhedsdata
|
||||
5. Registrér i trackeren efter hver evaluering
|
||||
6. Generér indhold på opslagets sprog (dansk hvis opslaget er på dansk, ellers engelsk)
|
||||
7. Vær direkte og konkret -- ingen smøren
|
||||
8. Naturligt tech-dansk til genererede tekster. Korte sætninger, aktive verber, undgå passiv. Oversæt ikke tekniske termer med tvang (stack, pipeline, deployment, embedding)
|
||||
8b. **Case-study-URL'er i PDF'ens Professional Summary:** Hvis PDF'en nævner case studies eller demoer, SKAL URL'erne optræde i det første afsnit (Professional Summary). Rekrutterere læser ofte kun summary. Alle URL'er i HTML med `white-space: nowrap`
|
||||
9. **Tracker-poster som TSV** -- rediger ALDRIG applications.md direkte for nye tilføjelser. Skriv TSV i `batch/tracker-additions/`, `merge-tracker.mjs` håndterer sammenfletningen
|
||||
10. **`**URL:**` i hver report-header** -- mellem Score og PDF
|
||||
|
||||
### Værktøjer
|
||||
|
||||
| Værktøj | Brug |
|
||||
|---------|------|
|
||||
| WebSearch | Lønundersøgelse, tendenser, virksomhedskultur, LinkedIn-kontakter, fallback for opslag |
|
||||
| WebFetch | Fallback til at udtrække opslag fra statiske sider |
|
||||
| Playwright | Tjek om opslag er aktive (browser_navigate + browser_snapshot), udtræk opslag fra SPAs. **KRITISK: ALDRIG 2+ agenter parallelt med Playwright -- de deler den samme browser-instans** |
|
||||
| Read | cv.md, article-digest.md, cv-template.html |
|
||||
| Write | Midlertidig HTML til PDF, applications.md, reports .md |
|
||||
| Edit | Opdatér trackeren |
|
||||
| Bash | `node generate-pdf.mjs` |
|
||||
@@ -0,0 +1,114 @@
|
||||
# Mode: apply -- Live-assistent til ansøgningsformularer
|
||||
|
||||
Interaktiv mode til det øjeblik, hvor kandidaten udfylder en ansøgningsformular i Chrome. Den læser, hvad der er på skærmen, indlæser konteksten fra opslagets tidligere evaluering og genererer personaliserede svar til hvert spørgsmål i formularen.
|
||||
|
||||
## Forudsætninger
|
||||
|
||||
- **Bedst med Playwright synlig**: I synlig tilstand ser kandidaten browseren, og Claude kan interagere med siden.
|
||||
- **Uden Playwright**: kandidaten deler et skærmbillede eller indsætter spørgsmålene manuelt.
|
||||
|
||||
## Workflow
|
||||
|
||||
```
|
||||
1. DETEKTÉR -> Læs den aktive Chrome-fane (skærmbillede/URL/titel)
|
||||
2. IDENTIFICÉR -> Udtræk virksomhed + rolle fra siden
|
||||
3. SØG -> Match mod eksisterende reports i reports/
|
||||
4. INDLÆS -> Læs den fulde report + Blok G (hvis den findes)
|
||||
5. SAMMENLIGN -> Svarer rollen på skærmen til den evaluerede? Hvis ændret -> advar
|
||||
6. ANALYSÉR -> Identificér ALLE synlige spørgsmål i formularen
|
||||
7. GENERÉR -> Generér et personaliseret svar til hvert spørgsmål
|
||||
8. PRÆSENTÉR -> Vis de formaterede svar til copy-paste
|
||||
```
|
||||
|
||||
## Trin 1 -- Detektér opslaget
|
||||
|
||||
**Med Playwright:** Snapshot af den aktive side. Læs titel, URL og synligt indhold.
|
||||
|
||||
**Uden Playwright:** Bed kandidaten om at:
|
||||
- Dele et skærmbillede af formularen (Read-værktøjet læser billeder)
|
||||
- Eller indsætte formularens spørgsmål som tekst
|
||||
- Eller angive virksomhed + rolle, så vi kan finde konteksten
|
||||
|
||||
## Trin 2 -- Identificér og indlæs konteksten
|
||||
|
||||
1. Udtræk virksomhedens navn og stillingstitlen fra siden
|
||||
2. Søg i `reports/` efter virksomhedsnavn (Grep case-insensitive)
|
||||
3. Hvis match -> indlæs den fulde report
|
||||
4. Hvis Blok G findes -> indlæs de tidligere svar-udkast som grundlag
|
||||
5. Hvis INTET match -> advar kandidaten og foreslå en hurtig auto-pipeline
|
||||
|
||||
## Trin 3 -- Detektér rolleændringer
|
||||
|
||||
Hvis rollen på skærmen afviger fra den evaluerede:
|
||||
- **Advar kandidaten**: "Rollen har ændret sig fra [X] til [Y]. Ønsker du, at jeg genevaluerer, eller at jeg tilpasser svarene til den nye titel?"
|
||||
- **Hvis tilpas**: Justér svarene til den nye rolle uden at genevaluere
|
||||
- **Hvis genevaluér**: Kør den fulde A-F-evaluering, opdatér report, regenerér Blok G
|
||||
- **Opdatér trackeren**: Ret rollens titel i applications.md om nødvendigt
|
||||
|
||||
## Trin 4 -- Analysér formularens spørgsmål
|
||||
|
||||
Identificér ALLE synlige spørgsmål:
|
||||
- Fritekstfelter (følgebrev, "hvorfor denne stilling", motivation, osv.)
|
||||
- Dropdowns (hvordan hørte du om virksomheden, arbejdstilladelse, osv.)
|
||||
- Ja/Nej (mobilitet, visum, tilgængelighed, osv.)
|
||||
- Lønfelter (interval, lønforventning -- i brutto årsløn for Danmark)
|
||||
- Upload-felter (CV, følgebrev som PDF, referencer)
|
||||
|
||||
Klassificér hvert spørgsmål:
|
||||
- **Allerede besvaret i Blok G** -> genbrug det eksisterende svar
|
||||
- **Nyt spørgsmål** -> generér svaret fra report + `cv.md`
|
||||
|
||||
## Trin 5 -- Generér svarene
|
||||
|
||||
For hvert spørgsmål, byg svaret efter dette skema:
|
||||
|
||||
1. **Kontekst fra report**: Brug proof points fra blok B, STAR-stories fra blok F
|
||||
2. **Tidligere Blok G**: Hvis et udkast findes, så brug det som grundlag og finpuds
|
||||
3. **Tonen "Jeg vælger jer"**: samme framework som i auto-pipeline -- selvsikker, ikke bønfaldende
|
||||
4. **Specificitet**: citér noget konkret fra opslaget, der er synligt på skærmen
|
||||
5. **career-ops proof point**: inkludér i "Yderligere oplysninger", hvis et sådant felt findes
|
||||
|
||||
**Felter, der er specifikke for almindelige danske formularer:**
|
||||
- **Lønforventning (brutto årsløn)** -> Interval fra `profile.yml`, i DKK, med bemærkningen "forhandlelig afhængigt af den samlede pakke"
|
||||
- **Startdato** -> Realistisk dato, der tager højde for opsigelsesvarsel (ofte 1-3 måneder)
|
||||
- **Arbejdstilladelse / Nationalitet** -> Ærligt og kortfattet; for EU-borgere: "Ingen opholdstilladelse påkrævet (EU-borger)"
|
||||
- **Sprog** -> Niveauer efter CEFR (A1-C2)
|
||||
- **Mobilitet** -> Angiv det acceptable geografiske område og hyppigheden af rejser
|
||||
|
||||
**Output-format:**
|
||||
|
||||
```
|
||||
## Svar til [Virksomhed] -- [Rolle]
|
||||
|
||||
Grundlag: Report #NNN | Score: X.X/5 | Arketype: [type]
|
||||
|
||||
---
|
||||
|
||||
### 1. [Eksakt spørgsmål fra formularen]
|
||||
> [Svar klar til copy-paste]
|
||||
|
||||
### 2. [Næste spørgsmål]
|
||||
> [Svar]
|
||||
|
||||
...
|
||||
|
||||
---
|
||||
|
||||
Noter:
|
||||
- [Observationer om rollen, ændringer, osv.]
|
||||
- [Forslag til personalisering, som kandidaten bør tjekke]
|
||||
```
|
||||
|
||||
## Trin 6 -- Efter ansøgningen (valgfrit)
|
||||
|
||||
Hvis kandidaten bekræfter, at ansøgningen er sendt:
|
||||
1. Opdatér status i `applications.md` fra "Evaluated" til "Applied"
|
||||
2. Opdatér report'ens Blok G med de endelige svar
|
||||
3. Foreslå næste trin: `/career-ops contacto` til LinkedIn-outreach mod den ansættende leder
|
||||
|
||||
## Håndtering af scroll
|
||||
|
||||
Hvis formularen har flere spørgsmål, end der er synlige:
|
||||
- Bed kandidaten om at scrolle og dele endnu et skærmbillede
|
||||
- Eller indsætte de resterende spørgsmål
|
||||
- Behandl i iterationer, indtil hele formularen er dækket
|
||||
@@ -0,0 +1,166 @@
|
||||
# Mode: oferta -- Fuld evaluering A-F
|
||||
|
||||
Når kandidaten indsætter et opslag (tekst eller URL), så lever ALTID alle 6 blokke.
|
||||
|
||||
## Trin 0 -- Arketype-detektion
|
||||
|
||||
Klassificér opslaget i en af de 6 arketyper (se `_shared.md`). Hvis hybrid, så angiv de 2 nærmeste. Det afgør:
|
||||
- Hvilke proof points der prioriteres i blok B
|
||||
- Hvordan summary omskrives i blok E
|
||||
- Hvilke STAR-stories der forberedes i blok F
|
||||
|
||||
## Blok A -- Rolleopsummering
|
||||
|
||||
Tabel med:
|
||||
- Detekteret arketype
|
||||
- Domain (Platform / Agentic / LLMOps / ML / Enterprise)
|
||||
- Funktion (Build / Consult / Manage / Deploy)
|
||||
- Senioritet
|
||||
- Remote (Fuld remote / Hybrid / På kontoret)
|
||||
- Teamstørrelse (hvis nævnt)
|
||||
- TL;DR i 1 sætning
|
||||
|
||||
## Blok B -- Match med CV'et
|
||||
|
||||
Læs `cv.md`. Lav en tabel, hvor hvert krav i opslaget mappes til eksakte linjer i CV'et.
|
||||
|
||||
**Tilpasset arketypen:**
|
||||
- FDE -> prioritér proof points om hurtig levering og kundenærhed
|
||||
- SA -> prioritér systemdesign og integrationer
|
||||
- PM -> prioritér product discovery og metrics
|
||||
- LLMOps -> prioritér evals, observability, pipelines
|
||||
- Agentic -> prioritér multi-agent, HITL, orkestrering
|
||||
- Transformation -> prioritér forandringsledelse, adoption, skalering
|
||||
|
||||
Afsnit om **Mangler (Gaps)** med en mitigeringsstrategi for hver enkelt. For hver mangel:
|
||||
1. Er det en hard blocker eller et nice-to-have?
|
||||
2. Kan kandidaten påvise tilstødende erfaring?
|
||||
3. Findes der et portfolio-projekt, der dækker manglen?
|
||||
4. Konkret mitigeringsplan (sætning til følgebrevet, hurtigt mini-projekt, osv.)
|
||||
|
||||
## Blok C -- Niveau og strategi
|
||||
|
||||
1. **Detekteret niveau** i opslaget vs **kandidatens naturlige niveau for denne arketype**
|
||||
2. **Plan "sælg senior uden at lyve"**: konkrete formuleringer tilpasset arketypen, konkrete resultater at fremhæve, hvordan founder-erfaring positioneres som en fordel
|
||||
3. **Plan "hvis jeg bliver downlevelet"**: accepter, hvis aflønningen er fair, forhandl en revision efter 6 måneder, klare forfremmelseskriterier
|
||||
|
||||
## Blok D -- Aflønning og efterspørgsel
|
||||
|
||||
Brug WebSearch til:
|
||||
- Aktuelle lønninger for rollen (Glassdoor, Levels.fyi, Jobindex Lønstatistik, IDA Lønstatistik, PROSA)
|
||||
- Virksomhedens lønreputation (Glassdoor)
|
||||
- Efterspørgselstendens for rollen på det danske marked
|
||||
|
||||
Tabel med data og citerede kilder. Hvis der ingen data er, så sig det klart -- opfind ikke noget.
|
||||
|
||||
**Det danske marked -- Obligatoriske tjek:**
|
||||
- Pension nævnt? Indregn arbejdsgiverbidraget (typisk 8-12%) i den samlede pakke.
|
||||
- Variabel del (bonus, provision, warrants / aktieoptioner)?
|
||||
- Feriepenge / feriefridage ud over ferielovens minimum?
|
||||
- Overenskomst eller funktionærvilkår? Hvis overenskomst: tjek løntrin og vilkår.
|
||||
- Fastansættelse eller tidsbegrænset? Hvis tidsbegrænset: varighed, begrundelse, mulighed for fastansættelse.
|
||||
- Freelance / selvstændig? Dagssats, opgavens varighed, risiko for omklassificering.
|
||||
|
||||
## Blok E -- Personaliseringsplan
|
||||
|
||||
| # | Sektion | Nuværende tilstand | Foreslået ændring | Begrundelse |
|
||||
|---|---------|--------------------|--------------------|-------------|
|
||||
| 1 | Summary | ... | ... | ... |
|
||||
| ... | ... | ... | ... | ... |
|
||||
|
||||
Top 5 ændringer i CV'et + Top 5 ændringer på LinkedIn for at maksimere matchet.
|
||||
|
||||
## Blok F -- Samtaleplan
|
||||
|
||||
6-10 STAR+R-stories mappet til opslagets krav (STAR + **Reflection**):
|
||||
|
||||
| # | Krav i opslaget | STAR+R-story | S | T | A | R | Reflection |
|
||||
|---|-----------------|--------------|---|---|---|---|------------|
|
||||
|
||||
Kolonnen **Reflection** indfanger, hvad der blev lært, eller hvad der ville blive gjort anderledes. Det signalerer senioritet -- juniorer beskriver, hvad der skete, seniorer drager læring af det.
|
||||
|
||||
**Story Bank:** Hvis `interview-prep/story-bank.md` findes, så tjek om disse stories allerede er der. Hvis ikke, så tilføj de nye. Med tiden opbygger det en genbrugelig bank på 5-10 master-stories, der kan tilpasses ethvert samtalespørgsmål.
|
||||
|
||||
**Udvalgt og rammesat efter arketypen:**
|
||||
- FDE -> fremhæv leveringstempo og kundenærhed
|
||||
- SA -> fremhæv arkitekturbeslutninger
|
||||
- PM -> fremhæv discovery og trade-offs
|
||||
- LLMOps -> fremhæv metrics, evals, production hardening
|
||||
- Agentic -> fremhæv orkestrering, error handling, HITL
|
||||
- Transformation -> fremhæv adoption og organisatorisk forandring
|
||||
|
||||
Inkludér også:
|
||||
- 1 anbefalet case study (hvilket projekt der præsenteres og hvordan)
|
||||
- Red-flag-spørgsmål og hvordan man besvarer dem (fx "Hvorfor solgte du din virksomhed?", "Havde du et team, der refererede til dig?", "Hvorfor et skifte efter så kort tid?")
|
||||
|
||||
---
|
||||
|
||||
## Efter evalueringen
|
||||
|
||||
**ALTID** efter blok A-F skal du udføre:
|
||||
|
||||
### 1. Gem report .md
|
||||
|
||||
Gem den fulde evaluering i `reports/{###}-{company-slug}-{YYYY-MM-DD}.md`.
|
||||
|
||||
- `{###}` = næste fortløbende nummer (3 cifre, nul-paddet). For at allokere det atomisk og undgå race conditions skal du køre `node reserve-report-num.mjs` for at reservere nummeret (stdout returnerer `{###}`), skrive rapporten og derefter køre `node reserve-report-num.mjs --release {###}` for at frigive sentinel'en.
|
||||
- `{company-slug}` = virksomhedsnavn i små bogstaver, uden mellemrum (brug bindestreger)
|
||||
- `{YYYY-MM-DD}` = dagens dato
|
||||
|
||||
**Report-format:**
|
||||
|
||||
```markdown
|
||||
# Evaluering: {Virksomhed} -- {Rolle}
|
||||
|
||||
**Dato:** {YYYY-MM-DD}
|
||||
**Arketype:** {detekteret}
|
||||
**Score:** {X/5}
|
||||
**URL:** {opslagets URL}
|
||||
**PDF:** {sti eller afventer}
|
||||
|
||||
---
|
||||
|
||||
## A) Rolleopsummering
|
||||
(fuldt indhold af blok A)
|
||||
|
||||
## B) Match med CV'et
|
||||
(fuldt indhold af blok B)
|
||||
|
||||
## C) Niveau og strategi
|
||||
(fuldt indhold af blok C)
|
||||
|
||||
## D) Aflønning og efterspørgsel
|
||||
(fuldt indhold af blok D)
|
||||
|
||||
## E) Personaliseringsplan
|
||||
(fuldt indhold af blok E)
|
||||
|
||||
## F) Samtaleplan
|
||||
(fuldt indhold af blok F)
|
||||
|
||||
## G) Udkast til svar til ansøgningen
|
||||
(kun ved score >= 4.5 -- udkast til svar til ansøgningsformularen)
|
||||
|
||||
---
|
||||
|
||||
## Udtrukne nøgleord
|
||||
(liste med 15-20 nøgleord fra opslaget til ATS-optimering)
|
||||
```
|
||||
|
||||
### 2. Registrér i trackeren
|
||||
|
||||
**ALTID** registrér i `data/applications.md`:
|
||||
- Næste fortløbende nummer
|
||||
- Dagens dato
|
||||
- Virksomhed
|
||||
- Rolle
|
||||
- Score: gennemsnit af matchet (1-5)
|
||||
- Status: `Evaluated`
|
||||
- PDF: nej (eller ja, hvis auto-pipeline har genereret en PDF)
|
||||
- Report: relativt link til report-filen (fx `[001](reports/001-company-2026-01-01.md)`)
|
||||
|
||||
**Tracker-format:**
|
||||
|
||||
```markdown
|
||||
| # | Dato | Virksomhed | Rolle | Score | Status | PDF | Report |
|
||||
```
|
||||
@@ -0,0 +1,63 @@
|
||||
# Mode: pipeline -- URL-indbakke (Second Brain)
|
||||
|
||||
Behandler URL'er til opslag, der er samlet i `data/pipeline.md`. Kandidaten tilføjer URL'er, når han vil, og kører derefter `/career-ops pipeline` for at behandle dem alle på én gang.
|
||||
|
||||
## Workflow
|
||||
|
||||
1. **Læs** `data/pipeline.md` -> find `- [ ]`-elementer i sektionen "Afventer" / "Pending" / "Pendientes"
|
||||
2. **For hver afventende URL**:
|
||||
a. Reservér det næste fortløbende `REPORT_NUM` atomisk ved at køre `node reserve-report-num.mjs` (og frigiv sentinel'en ved at køre `node reserve-report-num.mjs --release <num>`, når rapporten er skrevet)
|
||||
b. **Udtræk opslaget** med Playwright (`browser_navigate` + `browser_snapshot`) -> WebFetch -> WebSearch
|
||||
c. Hvis URL'en ikke er tilgængelig -> markér som `- [!]` med en note og fortsæt
|
||||
d. **Kør den fulde auto-pipeline**: Evaluering A-F -> Report .md -> PDF (hvis score >= 3.0) -> Tracker
|
||||
e. **Flyt fra "Afventer" til "Behandlede"**: `- [x] #NNN | URL | Virksomhed | Rolle | Score/5 | PDF ja/nej`
|
||||
3. **Hvis 3+ URL'er afventer**, så start agenter parallelt (Agent-værktøjet med `run_in_background`) for at maksimere hastigheden.
|
||||
4. **Til sidst** vis en opsummerende tabel:
|
||||
|
||||
```
|
||||
| # | Virksomhed | Rolle | Score | PDF | Anbefalet handling |
|
||||
```
|
||||
|
||||
## Format for pipeline.md
|
||||
|
||||
```markdown
|
||||
## Afventer
|
||||
- [ ] https://jobs.example.com/posting/123
|
||||
- [ ] https://boards.greenhouse.io/company/jobs/456 | Company ApS | Senior PM
|
||||
- [!] https://private.url/job -- Fejl: login påkrævet
|
||||
|
||||
## Behandlede
|
||||
- [x] #143 | https://jobs.example.com/posting/789 | Acme ApS | AI PM | 4.2/5 | PDF ja
|
||||
- [x] #144 | https://boards.greenhouse.io/xyz/jobs/012 | BigCo | SA | 2.1/5 | PDF nej
|
||||
```
|
||||
|
||||
> Note: Sektionsoverskrifterne kan være på EN ("Pending"/"Processed"), ES ("Pendientes"/"Procesadas"), DE ("Offen"/"Verarbeitet") eller DA ("Afventer"/"Behandlede"). Vær fleksibel ved læsning, tro mod den eksisterende stil ved skrivning.
|
||||
|
||||
## Intelligent detektion af opslaget fra URL'en
|
||||
|
||||
1. **Playwright (foretrukket):** `browser_navigate` + `browser_snapshot`. Fungerer med alle SPAs.
|
||||
2. **WebFetch (fallback):** Til statiske sider, eller når Playwright ikke er tilgængelig.
|
||||
3. **WebSearch (sidste udvej):** Søg på sekundære portaler, der indekserer opslaget.
|
||||
|
||||
**Særlige tilfælde:**
|
||||
- **LinkedIn**: Kan kræve login -> markér `[!]` og bed kandidaten om at indsætte teksten
|
||||
- **PDF**: Hvis URL'en peger på en PDF, så læs den direkte med Read-værktøjet
|
||||
- **Præfikset `local:`**: Læs den lokale fil. Eksempel: `local:jds/linkedin-pm-ai.md` -> læs `jds/linkedin-pm-ai.md`
|
||||
- **Jobindex / The Hub / LinkedIn DK**: Almindelige danske portaler. Playwright håndterer cookie-bannere godt
|
||||
- **Jobnet (Styrelsen for Arbejdsmarked)**: Strukturerede opslag, godt læsbare af maskine. WebFetch er som regel nok
|
||||
|
||||
## Automatisk nummerering
|
||||
|
||||
1. Kør `node reserve-report-num.mjs` for at reservere det næste fortløbende nummer atomisk (stdout returnerer `{###}`).
|
||||
2. Skriv rapporten med dette nummer.
|
||||
3. Frigiv sentinel'en ved at køre `node reserve-report-num.mjs --release {###}`, når rapporten er skrevet.
|
||||
|
||||
## Synkronisering af kilder
|
||||
|
||||
Før en URL behandles, tjek synkroniseringen:
|
||||
|
||||
```bash
|
||||
node cv-sync-check.mjs
|
||||
```
|
||||
|
||||
Ved desynkronisering, advar kandidaten, før du fortsætter.
|
||||
@@ -0,0 +1,112 @@
|
||||
# career-ops — Deutsche Modi (`modes/de/`)
|
||||
|
||||
Dieser Ordner enthält die deutschen Übersetzungen der wichtigsten career-ops-Modi für Bewerber:innen, die im DACH-Raum (Deutschland, Österreich, Schweiz) suchen oder mit deutschen Stellenanzeigen arbeiten.
|
||||
|
||||
## Wann diese Modi nutzen?
|
||||
|
||||
Verwende `modes/de/`, wenn mindestens eine der folgenden Bedingungen zutrifft:
|
||||
|
||||
- Du bewirbst dich vor allem auf **deutschsprachige Stellenanzeigen** (StepStone, XING, kununu, Bundesagentur für Arbeit, deutsche Karriereseiten)
|
||||
- Deine **Lebenslauf-Sprache** ist Deutsch oder du wechselst je nach Stellenanzeige zwischen DE und EN
|
||||
- Du brauchst Antworten und Anschreiben in **natürlichem Tech-Deutsch**, nicht maschinenübersetzt
|
||||
- Du musst mit **DACH-spezifischen Vertragselementen** umgehen: 13. Monatsgehalt, Probezeit, Kündigungsfrist, AGG, Tarifvertrag, Festanstellung vs. Freelance, VWL, bAV, Arbeitszeugnisse
|
||||
|
||||
Wenn die meisten deiner Stellenanzeigen auf Englisch sind, bleib bei den Standard-Modi unter `modes/`. Die englischen Modi greifen automatisch zu deutschen Anzeigen, sobald Claude sie als deutschsprachig erkennt — aber sie kennen die DACH-Marktbesonderheiten nicht im selben Detail.
|
||||
|
||||
## Wie aktivieren?
|
||||
|
||||
career-ops hat keinen "Sprach-Schalter" als Code-Flag. Stattdessen gibt es zwei Wege:
|
||||
|
||||
### Weg 1 — Pro Session, per Befehl
|
||||
|
||||
Sag Claude zu Beginn der Session ausdrücklich:
|
||||
|
||||
> "Nutze ab jetzt die deutschen Modi unter `modes/de/`."
|
||||
|
||||
oder
|
||||
|
||||
> "Bewerten und Bewerbungen auf Deutsch — verwende `modes/de/_shared.md` und `modes/de/angebot.md`."
|
||||
|
||||
Claude liest dann die Dateien aus diesem Ordner statt aus `modes/`.
|
||||
|
||||
### Weg 2 — Dauerhaft, per Profil
|
||||
|
||||
Trage in `config/profile.yml` eine Sprach-Präferenz ein, z. B.:
|
||||
|
||||
```yaml
|
||||
language:
|
||||
primary: de
|
||||
modes_dir: modes/de
|
||||
```
|
||||
|
||||
Erinnere Claude in deiner ersten Session daran, dieses Feld zu respektieren ("Schau in `profile.yml`, ich habe `language.modes_dir` gesetzt"). Ab dann nimmt Claude automatisch die deutschen Modi.
|
||||
|
||||
> Hinweis: Das `language.modes_dir`-Feld ist eine Konvention dieser PR, kein hartcodiertes Schema. Wenn die Maintainer es anders strukturieren wollen, kann das Feld jederzeit umbenannt werden.
|
||||
|
||||
## Was ist übersetzt?
|
||||
|
||||
Diese erste Iteration deckt die vier Modi mit dem höchsten Hebel ab:
|
||||
|
||||
| Datei | Übersetzt aus | Zweck |
|
||||
|-------|---------------|-------|
|
||||
| `_shared.md` | `modes/_shared.md` (EN) | Geteilter Kontext, Archetypen, globale Regeln, DACH-Markt-Spezifika |
|
||||
| `angebot.md` | `modes/oferta.md` (ES) | Vollständige Bewertung einer einzelnen Stellenanzeige (Blöcke A-F) |
|
||||
| `bewerben.md` | `modes/apply.md` (EN) | Live-Assistent fürs Bewerbungsformular |
|
||||
| `pipeline.md` | `modes/pipeline.md` (ES) | URL-Inbox / Second Brain für gesammelte Stellenanzeigen |
|
||||
|
||||
Die übrigen Modi (`scan`, `batch`, `pdf`, `tracker`, `auto-pipeline`, `deep`, `contacto`, `ofertas`, `project`, `training`) sind absichtlich nicht in diesem PR dabei. Sie funktionieren weiter über die EN/ES-Originale, weil ihr Inhalt zu großen Teilen aus Tooling, Pfaden und Konfigurationskommandos besteht — diese sollen sprachunabhängig bleiben.
|
||||
|
||||
Wenn die Community die deutschen Modi annimmt, werden weitere Modi in einem Folge-PR übersetzt.
|
||||
|
||||
## Was bleibt englisch?
|
||||
|
||||
Bewusst nicht eingedeutscht, weil Standard-Tech-Vokabular:
|
||||
|
||||
- `cv.md`, `pipeline`, `tracker`, `report`, `score`, `archetype`, `proof point`
|
||||
- Tool-Namen (`Playwright`, `WebSearch`, `WebFetch`, `Read`, `Write`, `Edit`, `Bash`)
|
||||
- Status-Werte im Tracker (`Evaluated`, `Applied`, `Interview`, `Offer`, `Rejected`)
|
||||
- Code-Snippets, Pfade, Befehle
|
||||
|
||||
Die Modi verwenden deutsches Tech-Deutsch, wie es in echten Engineering-Teams in Berlin, München oder Zürich gesprochen wird: deutscher Fließtext, englische Fachbegriffe da, wo sie üblich sind. Keine erzwungene Eindeutschung von "Pipeline" zu "Förderband", kein "Lebenslauf-Datei" für `cv.md`.
|
||||
|
||||
## Vokabular-Spickzettel
|
||||
|
||||
Wenn du Modi anpasst oder erweiterst, halte dich an dieses Vokabular — so bleibt der Ton konsistent:
|
||||
|
||||
| Englisch | Deutsch (in dieser Codebase) |
|
||||
|----------|------------------------------|
|
||||
| Job posting | Stellenanzeige |
|
||||
| Application | Bewerbung |
|
||||
| Cover letter | Anschreiben |
|
||||
| Resume / CV | Lebenslauf |
|
||||
| Salary | Gehalt / Vergütung |
|
||||
| Compensation | Vergütung |
|
||||
| Skills | Kenntnisse / Fähigkeiten |
|
||||
| Interview | Vorstellungsgespräch |
|
||||
| Hiring manager | Personalleiter / Hiring Manager |
|
||||
| Recruiter | Recruiter (etabliertes Lehnwort) |
|
||||
| AI | KI (Künstliche Intelligenz) |
|
||||
| Requirements | Anforderungen / Voraussetzungen |
|
||||
| Career history | Werdegang / Berufserfahrung |
|
||||
| Notice period | Kündigungsfrist |
|
||||
| Probation | Probezeit |
|
||||
| Vacation | Urlaub |
|
||||
| 13th month salary | 13. Monatsgehalt / Weihnachtsgeld |
|
||||
| Permanent employment | Festanstellung |
|
||||
| Freelance | Freelance / freie Mitarbeit |
|
||||
| Collective agreement | Tarifvertrag |
|
||||
| Anti-discrimination law | AGG (Allgemeines Gleichbehandlungsgesetz) |
|
||||
| Works council | Betriebsrat |
|
||||
| Reference letter | Arbeitszeugnis |
|
||||
| Pension scheme | Betriebliche Altersvorsorge (bAV) |
|
||||
| Capital formation benefit | Vermögenswirksame Leistungen (VWL) |
|
||||
|
||||
## Beitragen
|
||||
|
||||
Wenn du eine Übersetzung verbessern oder einen weiteren Modus eindeutschen willst:
|
||||
|
||||
1. Öffne ein Issue mit dem Vorschlag (laut `CONTRIBUTING.md`)
|
||||
2. Halte dich an das Vokabular oben, um den Ton konsistent zu halten
|
||||
3. Übersetze sinngemäß und idiomatisch — keine wörtlichen Wort-für-Wort-Übersetzungen
|
||||
4. Behalte die strukturellen Elemente (Block A-F, Tabellen, Code-Blöcke, Tool-Anweisungen) exakt bei
|
||||
5. Teste mit einer echten deutschen Stellenanzeige (z. B. von StepStone oder XING), bevor du den PR aufmachst
|
||||
@@ -0,0 +1,201 @@
|
||||
# Geteilter Kontext -- career-ops (Deutsch)
|
||||
|
||||
<!-- ============================================================
|
||||
ANPASSEN DIESER DATEI
|
||||
============================================================
|
||||
Diese Datei enthält den geteilten Kontext für alle career-ops-Modi
|
||||
in der deutschen Variante. Bevor du career-ops verwendest, MUSST du:
|
||||
1. config/profile.yml mit deinen persönlichen Daten ausfüllen
|
||||
2. cv.md im Projekt-Root anlegen (Lebenslauf in Markdown)
|
||||
3. (Optional) article-digest.md mit deinen Proof Points anlegen
|
||||
4. Die mit [ANPASSEN] markierten Abschnitte unten anpassen
|
||||
============================================================ -->
|
||||
|
||||
## Quellen der Wahrheit (IMMER vor jeder Bewertung lesen)
|
||||
|
||||
| Datei | Pfad | Wann |
|
||||
|-------|------|------|
|
||||
| cv.md | `cv.md` (Projekt-Root) | IMMER |
|
||||
| article-digest.md | `article-digest.md` (falls vorhanden) | IMMER (detaillierte Proof Points) |
|
||||
| profile.yml | `config/profile.yml` | IMMER (Identität und Zielrollen) |
|
||||
|
||||
**REGEL: Niemals Kennzahlen aus Proof Points hartcodieren.** Lies sie zur Bewertungszeit aus `cv.md` und `article-digest.md`.
|
||||
**REGEL: Bei Kennzahlen zu Artikeln/Projekten hat `article-digest.md` Vorrang vor `cv.md`** (in `cv.md` können ältere Zahlen stehen).
|
||||
|
||||
---
|
||||
|
||||
## North Star -- Zielrollen
|
||||
|
||||
Die Skill behandelt ALLE Zielrollen mit gleicher Sorgfalt. Keine ist primär oder sekundär — jede ist ein Erfolg, sofern Vergütung und Entwicklungsperspektive stimmen:
|
||||
|
||||
| Archetyp | Thematische Achsen | Was gekauft wird |
|
||||
|----------|--------------------|------------------|
|
||||
| **AI Platform / LLMOps Engineer** | Evaluation, Observability, Zuverlässigkeit, Pipelines | Jemand, der KI mit Metriken in Produktion bringt |
|
||||
| **Agentic Workflows / Automation** | HITL, Tooling, Orchestrierung, Multi-Agent | Jemand, der zuverlässige Agentensysteme baut |
|
||||
| **Technical AI Product Manager** | GenAI/Agents, PRDs, Discovery, Delivery | Jemand, der Business in KI-Produkte übersetzt |
|
||||
| **AI Solutions Architect** | Hyperautomation, Enterprise, Integrationen | Jemand, der End-to-End-KI-Architekturen entwirft |
|
||||
| **AI Forward Deployed Engineer** | Kundennah, schnelle Lieferung, Prototyping | Jemand, der KI-Lösungen schnell beim Kunden ausrollt |
|
||||
| **AI Transformation Lead** | Change Management, Adoption, organisatorisches Enablement | Jemand, der KI-Transformation in Organisationen führt |
|
||||
|
||||
<!-- [ANPASSEN] Passe die Archetypen oben an deine Zielrollen an.
|
||||
Beispiel für Backend-Engineering:
|
||||
- Senior Backend Engineer
|
||||
- Staff Platform Engineer
|
||||
- Engineering Manager
|
||||
etc. -->
|
||||
|
||||
### Adaptives Framing nach Archetyp
|
||||
|
||||
> **Konkrete Kennzahlen: zur Bewertungszeit aus `cv.md` und `article-digest.md` lesen. NIEMALS hier hartcodieren.**
|
||||
|
||||
| Wenn die Rolle ist... | Beim Kandidaten betonen... | Quellen für Proof Points |
|
||||
|-----------------------|----------------------------|--------------------------|
|
||||
| Platform / LLMOps | Production-Erfahrung, Observability, Evals, Closed-Loop | article-digest.md + cv.md |
|
||||
| Agentic / Automation | Multi-Agent-Orchestrierung, HITL, Zuverlässigkeit, Kosten | article-digest.md + cv.md |
|
||||
| Technical AI PM | Product Discovery, PRDs, Metriken, Stakeholder-Management | cv.md + article-digest.md |
|
||||
| Solutions Architect | Systemdesign, Integrationen, Enterprise-tauglich | article-digest.md + cv.md |
|
||||
| Forward Deployed Engineer | Schnelle Lieferung, kundennah, Prototyp bis Produktion | cv.md + article-digest.md |
|
||||
| AI Transformation Lead | Change Management, Team-Enablement, Adoption | cv.md + article-digest.md |
|
||||
|
||||
<!-- [ANPASSEN] Ordne deine konkreten Projekte/Artikel den Archetypen oben zu -->
|
||||
|
||||
### Exit-Narrativ (in ALLEN Framings nutzen)
|
||||
|
||||
<!-- [ANPASSEN] Ersetze durch dein eigenes Narrativ. Beispiele:
|
||||
- "Eigene SaaS nach 5 Jahren aufgebaut und verkauft. Jetzt voller Fokus auf angewandte KI im Enterprise."
|
||||
- "Engineering-Lead in einer Series-B während 10x-Wachstum. Suche jetzt die nächste Herausforderung."
|
||||
- "Wechsel von Beratung zu Produktentwicklung. Suche Rollen mit hoher Verantwortung."
|
||||
Wird gelesen aus config/profile.yml → narrative.exit_story -->
|
||||
|
||||
Verwende das Exit-Narrativ aus `config/profile.yml`, um ALLE Inhalte zu rahmen:
|
||||
- **In PDF-Summaries:** Brücke von der Vergangenheit in die Zukunft schlagen — "Wende dieselben [Skills] jetzt auf [JD-Domain] an."
|
||||
- **In STAR-Stories:** Auf Proof Points aus `article-digest.md` referenzieren.
|
||||
- **In Draft-Antworten (Block G):** Das Übergangs-Narrativ gehört in die erste Antwort.
|
||||
- **Wenn die Stellenanzeige nach "unternehmerisch", "Eigenverantwortung", "Builder", "End-to-End" fragt:** Das ist DAS Differenzierungsmerkmal Nr. 1. Match-Gewicht erhöhen.
|
||||
|
||||
### Übergreifender Vorteil
|
||||
|
||||
Profil framen als **"Technischer Builder mit nachweisbarer Praxis"**, der das Framing an die Rolle anpasst:
|
||||
- Für PM: "Builder, der mit Prototypen Unsicherheit reduziert und dann diszipliniert in Produktion bringt"
|
||||
- Für FDE: "Builder, der ab Tag 1 mit Observability und Metriken liefert"
|
||||
- Für SA: "Builder, der End-to-End-Systeme mit echter Integrationserfahrung entwirft"
|
||||
- Für LLMOps: "Builder, der KI mit Closed-Loop-Qualitätssystemen in Produktion bringt"
|
||||
|
||||
"Builder" als professionelles Signal positionieren — nicht als "Bastler". Reale Proof Points machen das glaubwürdig.
|
||||
|
||||
### Portfolio als Proof Point (bei wertvollen Bewerbungen einsetzen)
|
||||
|
||||
<!-- [ANPASSEN] Wenn du eine Live-Demo, ein Dashboard oder ein öffentliches Projekt hast, hier konfigurieren.
|
||||
Beispiel:
|
||||
dashboard:
|
||||
url: "https://deinedomain.dev/demo"
|
||||
password: "demo-2026"
|
||||
when_to_share: "LLMOps, AI-Platform, Observability-Rollen"
|
||||
Wird gelesen aus config/profile.yml → narrative.proof_points und narrative.dashboard -->
|
||||
|
||||
Wenn der Kandidat eine Live-Demo / ein Dashboard hat (`profile.yml` prüfen), in passenden Bewerbungen den Zugang anbieten.
|
||||
|
||||
### Vergütungsintelligenz (Comp Intelligence)
|
||||
|
||||
<!-- [ANPASSEN] Recherchiere Vergütungsspannen für deine Zielrollen und passe die Werte an -->
|
||||
|
||||
**Allgemeine Hinweise:**
|
||||
- WebSearch für aktuelle Marktdaten (Glassdoor, Levels.fyi, Kununu, Gehalt.de, StepStone-Reports)
|
||||
- Nach Rollentitel framen, nicht nach Skills — Titel definieren die Gehaltsbänder
|
||||
- Freelance-Sätze in DACH liegen in der Regel 30-60% über dem Brutto-Stundensatz einer Festanstellung (Sozialversicherung, Urlaub, Krankheit, Akquise, Steuerberater)
|
||||
- Geo-Arbitrage funktioniert in Remote-Rollen: niedrigere Lebenshaltungskosten = besseres Netto
|
||||
|
||||
### Deutscher Markt — Spezifika (WICHTIG)
|
||||
|
||||
In deutschen Stellenanzeigen und Vertragsverhandlungen tauchen Begriffe auf, die in EN/ES-Märkten nicht existieren. Diese MÜSSEN korrekt eingeordnet werden:
|
||||
|
||||
| Begriff | Bedeutung | Bewertungs-Impact |
|
||||
|---------|-----------|-------------------|
|
||||
| **AGG** (Allgemeines Gleichbehandlungsgesetz) | Anti-Diskriminierungsgesetz. Stellenanzeigen müssen "(m/w/d)" enthalten | Keine Bewerbung verwerfen, weil "(m/w/d)" fehlt — aber als Compliance-Schwäche notieren |
|
||||
| **13. Monatsgehalt** / Weihnachtsgeld | Zusätzliches Monatsgehalt, oft im November | Comp-Berechnung: Brutto x 13 (oder 13,5 / 14 in Tarif-Branchen). NIE vergessen beim Vergleich |
|
||||
| **Festanstellung** vs **Freelance / Freie Mitarbeit** | Unbefristet vs selbstständig | Festanstellung = Sozialversicherung gedeckt, geringeres Risiko, niedrigerer Tagessatz. Freelance = höherer Satz, Scheinselbstständigkeits-Risiko prüfen |
|
||||
| **Probezeit** | Übliche 6 Monate, verkürzte Kündigungsfrist (2 Wochen) | Kein Risiko-Flag — ist Marktstandard. Nur flaggen wenn > 6 Monate |
|
||||
| **Kündigungsfrist** | Gesetzliche Frist nach Probezeit, oft 1-3 Monate | Bei Vertragswechsel relevant: Startdatum entsprechend planen |
|
||||
| **Urlaub** | 25-30 Tage Standard (gesetzlich min. 20 bei 5-Tage-Woche) | < 28 Tage = unter Marktstandard für Tech. Verhandelbar |
|
||||
| **Tarifvertrag** / TVöD / IG Metall | Kollektive Vergütungsregeln | In Tarif-Unternehmen ist Verhandlungsspielraum kleiner — dafür höhere Sicherheit, fixe Steigerungen |
|
||||
| **Betriebsrat** | Mitarbeitervertretung | Stark im Mittelstand und Konzernen. Mitsprache bei Kündigung, Arbeitszeit. Pluspunkt für Stabilität |
|
||||
| **Bewerbungsmappe** | Anschreiben + Lebenslauf + Zeugnisse | Im DACH-Raum oft erwartet, anders als in EN-Märkten. Zeugnisse ggf. nachreichen |
|
||||
| **Arbeitszeugnis** | Strukturiertes Referenzdokument vom Ex-Arbeitgeber | Klassischer DACH-Standard, eigene Codesprache |
|
||||
| **VWL** (Vermögenswirksame Leistungen) | Arbeitgeberzuschuss zum Vermögensaufbau | Kleinbetrag (oft 40 €/Monat), aber als Benefit zählen |
|
||||
| **bAV** (Betriebliche Altersvorsorge) | Betriebsrente | Bei Comp-Vergleich beachten — kann mehrere hundert Euro monatlich sein |
|
||||
|
||||
### Verhandlungs-Skripte (Negotiation)
|
||||
|
||||
<!-- [ANPASSEN] Auf deine Situation zuschneiden -->
|
||||
|
||||
**Gehaltsvorstellung (allgemeines Framework):**
|
||||
> "Auf Basis aktueller Marktdaten für diese Rolle peile ich [SPANNE aus profile.yml] an. Bei der Struktur bin ich flexibel — entscheidend sind das Gesamtpaket und die Entwicklungsperspektive."
|
||||
|
||||
**Pushback bei Geo-Diskount:**
|
||||
> "Die Rollen, in denen ich konkurriere, sind ergebnisorientiert, nicht ortsabhängig. Mein Track Record ändert sich nicht mit der Postleitzahl."
|
||||
|
||||
**Wenn das Angebot unter dem Zielwert liegt:**
|
||||
> "Ich vergleiche aktuell mit Angeboten im Bereich [höhere Spanne]. [Firma] reizt mich wegen [Grund]. Lässt sich [Zielwert] gemeinsam erreichen?"
|
||||
|
||||
**Bei Verhandlung über das 13. Gehalt / Bonus:**
|
||||
> "Mir ist wichtig, das Gesamtpaket zu vergleichen. Können wir das fixe Bruttogehalt, das 13. Monatsgehalt und einen variablen Anteil getrennt aufschlüsseln?"
|
||||
|
||||
### Standort-Politik (Location Policy)
|
||||
|
||||
<!-- [ANPASSEN] An deine Situation anpassen. Wird gelesen aus config/profile.yml → location -->
|
||||
|
||||
**In Formularen:**
|
||||
- Binäre "Können Sie vor Ort sein?"-Fragen: nach tatsächlicher Verfügbarkeit aus `profile.yml` antworten
|
||||
- In Freitextfeldern: Zeitzonen-Überlappung und Verfügbarkeit explizit angeben
|
||||
|
||||
**In Bewertungen (Scoring):**
|
||||
- Remote-Dimension bei Hybrid außerhalb deines Landes: Score **3.0** (nicht 1.0)
|
||||
- Score 1.0 nur, wenn die Stellenanzeige explizit sagt "muss 4-5 Tage/Woche vor Ort, keine Ausnahmen"
|
||||
|
||||
### Time-to-Offer-Priorität
|
||||
- Funktionierende Demo + Metriken > Perfektion
|
||||
- Schneller bewerben > mehr lernen
|
||||
- 80/20-Ansatz, alles zeitlich begrenzen
|
||||
|
||||
---
|
||||
|
||||
## Globale Regeln
|
||||
|
||||
### NIEMALS
|
||||
|
||||
1. Erfahrung oder Kennzahlen erfinden
|
||||
2. `cv.md` oder Portfolio-Dateien verändern
|
||||
3. Bewerbungen im Namen des Kandidaten absenden
|
||||
4. Telefonnummer in generierten Nachrichten teilen
|
||||
5. Vergütung unter Marktniveau empfehlen
|
||||
6. PDF generieren, ohne vorher die Stellenanzeige gelesen zu haben
|
||||
7. Marketing-Floskeln oder "Corporate-Sprech" verwenden
|
||||
8. Den Tracker ignorieren (jede bewertete Stellenanzeige wird eingetragen)
|
||||
|
||||
### IMMER
|
||||
|
||||
0. **Anschreiben:** Wenn das Formular die Möglichkeit bietet, ein Anschreiben anzuhängen oder zu schreiben, IMMER eines mitliefern. PDF im selben visuellen Design wie der Lebenslauf erzeugen. Inhalt: Zitate aus der Stellenanzeige, gemappt auf Proof Points, Links zu relevanten Case Studies. Maximal 1 Seite.
|
||||
1. `cv.md` und `article-digest.md` (falls vorhanden) lesen, bevor irgendeine Stellenanzeige bewertet wird
|
||||
1b. **Bei der ersten Bewertung jeder Session:** `node cv-sync-check.mjs` per Bash ausführen. Bei Warnungen den Kandidaten informieren, bevor weitergearbeitet wird
|
||||
2. Den Rollen-Archetyp erkennen und das Framing anpassen
|
||||
3. Beim Matching exakte Zeilen aus dem Lebenslauf zitieren
|
||||
4. WebSearch für Vergütungs- und Firmendaten nutzen
|
||||
5. Nach jeder Bewertung im Tracker eintragen
|
||||
6. Inhalte in der Sprache der Stellenanzeige erzeugen (Deutsch, wenn die Anzeige deutsch ist; Englisch sonst)
|
||||
7. Direkt und konkret sein — keine Floskeln
|
||||
8. Beim Erzeugen deutscher Texte (PDF-Summaries, Bullets, LinkedIn-Nachrichten, STAR-Stories): natürliches Tech-Deutsch, keine wörtliche Übersetzung. Kurze Sätze, aktive Verben, Passiv vermeiden. Fachbegriffe (Stack, Pipeline, Deployment, Embedding) nicht zwanghaft eindeutschen
|
||||
8b. **Case-Study-URLs in der PDF Professional Summary:** Wenn das PDF Case Studies oder Demos erwähnt, MÜSSEN die URLs schon im ersten Absatz (Professional Summary) auftauchen. Recruiter lesen oft nur die Summary. Alle URLs im HTML mit `white-space: nowrap`
|
||||
9. **Tracker-Einträge als TSV** — `applications.md` NIEMALS direkt für neue Einträge editieren. TSV in `batch/tracker-additions/` schreiben, `merge-tracker.mjs` übernimmt das Mergen
|
||||
10. **`**URL:**` in jedem Report-Header** — zwischen Score und PDF
|
||||
|
||||
### Tools
|
||||
|
||||
| Tool | Einsatz |
|
||||
|------|---------|
|
||||
| WebSearch | Vergütungs-Recherche, Trends, Unternehmenskultur, LinkedIn-Kontakte, Fallback für Stellenanzeigen |
|
||||
| WebFetch | Fallback, um Stellenanzeigen aus statischen Seiten zu extrahieren |
|
||||
| Playwright | Prüfen, ob Stellenanzeigen noch aktiv sind (browser_navigate + browser_snapshot), Stellenanzeigen aus SPAs extrahieren. **KRITISCH: NIEMALS 2+ Agenten parallel mit Playwright starten — sie teilen sich eine Browser-Instanz** |
|
||||
| Read | cv.md, article-digest.md, cv-template.html |
|
||||
| Write | Temporäres HTML für PDF, applications.md, Reports .md |
|
||||
| Edit | Tracker aktualisieren |
|
||||
| Bash | `node generate-pdf.mjs` |
|
||||
@@ -0,0 +1,165 @@
|
||||
# Modus: angebot — Vollständige Bewertung A-F
|
||||
|
||||
Wenn der Kandidat eine Stellenanzeige einfügt (Text oder URL), IMMER alle 6 Blöcke liefern.
|
||||
|
||||
## Schritt 0 — Archetyp-Erkennung
|
||||
|
||||
Die Stellenanzeige einem der 6 Archetypen zuordnen (siehe `_shared.md`). Bei Hybriden die zwei nächstliegenden angeben. Daraus folgt:
|
||||
- Welche Proof Points in Block B Vorrang haben
|
||||
- Wie das Summary in Block E umgeschrieben wird
|
||||
- Welche STAR-Stories in Block F vorbereitet werden
|
||||
|
||||
## Block A — Rollen-Zusammenfassung
|
||||
|
||||
Tabelle mit:
|
||||
- Erkannter Archetyp
|
||||
- Domain (Platform / Agentic / LLMOps / ML / Enterprise)
|
||||
- Funktion (Build / Consult / Manage / Deploy)
|
||||
- Seniorität
|
||||
- Remote (Vollremote / Hybrid / Vor Ort)
|
||||
- Teamgröße (falls erwähnt)
|
||||
- TL;DR in einem Satz
|
||||
|
||||
## Block B — Match mit dem Lebenslauf
|
||||
|
||||
`cv.md` lesen. Tabelle erstellen, in der jede Anforderung aus der Stellenanzeige auf exakte Zeilen aus dem Lebenslauf gemappt wird.
|
||||
|
||||
**Angepasst an den Archetyp:**
|
||||
- FDE → Proof Points zu schneller Lieferung und Kundennähe priorisieren
|
||||
- SA → Systemdesign und Integrationen priorisieren
|
||||
- PM → Product Discovery und Metriken priorisieren
|
||||
- LLMOps → Evals, Observability, Pipelines priorisieren
|
||||
- Agentic → Multi-Agent, HITL, Orchestrierung priorisieren
|
||||
- Transformation → Change Management, Adoption, Skalierung priorisieren
|
||||
|
||||
Abschnitt **Lücken (Gaps)** mit Mitigationsstrategie für jede einzelne. Pro Gap:
|
||||
1. Ist das ein Hard Blocker oder ein Nice-to-have?
|
||||
2. Kann der Kandidat angrenzende Erfahrung nachweisen?
|
||||
3. Gibt es ein Portfolio-Projekt, das diesen Gap abdeckt?
|
||||
4. Konkreter Mitigationsplan (Satz fürs Anschreiben, schnelles Mini-Projekt, etc.)
|
||||
|
||||
## Block C — Level und Strategie
|
||||
|
||||
1. **Erkanntes Level** in der Stellenanzeige vs **natürliches Level des Kandidaten für diesen Archetyp**
|
||||
2. **Plan "Senior verkaufen, ohne zu lügen"**: konkrete Formulierungen, an den Archetyp angepasst, hervorzuhebende Erfolge, wie Founder-Erfahrung als Vorteil positioniert wird
|
||||
3. **Plan "Wenn ich downgelevelt werde"**: akzeptieren, wenn die Vergütung fair ist; Review nach 6 Monaten verhandeln; klare Beförderungskriterien festlegen
|
||||
|
||||
## Block D — Vergütung und Nachfrage
|
||||
|
||||
WebSearch nutzen für:
|
||||
- Aktuelle Gehälter für die Rolle (Glassdoor, Levels.fyi, Kununu, Gehalt.de, StepStone-Reports)
|
||||
- Vergütungs-Reputation des Unternehmens (Kununu, Glassdoor)
|
||||
- Nachfrage-Trend für die Rolle im DACH-Markt
|
||||
|
||||
Tabelle mit Daten und zitierten Quellen. Wenn keine Daten gefunden werden, das offen sagen — nichts erfinden.
|
||||
|
||||
**Deutscher Markt — Pflichtchecks:**
|
||||
- 13. Monatsgehalt / Weihnachtsgeld erwähnt? In die Brutto-Berechnung einrechnen.
|
||||
- Variable Anteile (Bonus, Provision, RSUs / VSOP)?
|
||||
- VWL und bAV erwähnt?
|
||||
- Tarifvertrag (TVöD, IG Metall) im Spiel? Wenn ja, Verhandlungsspielraum kleiner — dafür mehr Sicherheit.
|
||||
- Festanstellung oder Freelance? Bei Freelance: Tagessatz, Scheinselbstständigkeits-Risiko.
|
||||
|
||||
## Block E — Personalisierungs-Plan
|
||||
|
||||
| # | Abschnitt | Aktueller Stand | Vorgeschlagene Änderung | Begründung |
|
||||
|---|-----------|-----------------|-------------------------|------------|
|
||||
| 1 | Summary | ... | ... | ... |
|
||||
| ... | ... | ... | ... | ... |
|
||||
|
||||
Top 5 Änderungen am Lebenslauf + Top 5 Änderungen am LinkedIn-Profil, um den Match zu maximieren.
|
||||
|
||||
## Block F — Vorstellungsgesprächs-Plan
|
||||
|
||||
6-10 STAR+R-Stories, gemappt auf Anforderungen der Stellenanzeige (STAR + **Reflection**):
|
||||
|
||||
| # | JD-Anforderung | STAR+R-Story | S | T | A | R | Reflection |
|
||||
|---|----------------|--------------|---|---|---|---|------------|
|
||||
|
||||
Die Spalte **Reflection** erfasst, was gelernt wurde oder was man heute anders machen würde. Das signalisiert Seniorität — Junior-Kandidaten beschreiben, was passiert ist; Senior-Kandidaten ziehen Lehren daraus.
|
||||
|
||||
**Story Bank:** Wenn `interview-prep/story-bank.md` existiert, prüfen, ob die Stories schon dort stehen. Falls nicht, neue ergänzen. Mit der Zeit entsteht so eine wiederverwendbare Bank von 5-10 Master-Stories, die sich an jede Frage im Vorstellungsgespräch anpassen lassen.
|
||||
|
||||
**Ausgewählt und an den Archetyp angepasst:**
|
||||
- FDE → Lieferungs-Tempo und Kundennähe betonen
|
||||
- SA → Architektur-Entscheidungen betonen
|
||||
- PM → Discovery und Trade-offs betonen
|
||||
- LLMOps → Metriken, Evals, Production-Hardening betonen
|
||||
- Agentic → Orchestrierung, Error Handling, HITL betonen
|
||||
- Transformation → Adoption und organisatorischen Wandel betonen
|
||||
|
||||
Außerdem aufnehmen:
|
||||
- 1 empfohlene Case Study (welches Projekt vorgestellt wird und wie)
|
||||
- Red-Flag-Fragen und wie man darauf antwortet (z. B. "Warum haben Sie Ihre Firma verkauft?", "Hatten Sie ein Team, das an Sie berichtet hat?", "Warum ein Wechsel nach so kurzer Zeit?")
|
||||
|
||||
---
|
||||
|
||||
## Nach der Bewertung
|
||||
|
||||
**IMMER** nach den Blöcken A-F ausführen:
|
||||
|
||||
### 1. Report .md speichern
|
||||
|
||||
Die vollständige Bewertung in `reports/{###}-{company-slug}-{YYYY-MM-DD}.md` ablegen.
|
||||
|
||||
- `{###}` = nächste fortlaufende Nummer (3-stellig, mit führenden Nullen). Um diese Nummer atomar zuzuweisen und Race-Conditions zu vermeiden, MÜSSEN Sie `node reserve-report-num.mjs` ausführen, um die Nummer zu reservieren (die Ausgabe gibt `{###}` zurück), den Report schreiben und dann `node reserve-report-num.mjs --release {###}` ausführen, um den Sentinel freizugeben.
|
||||
- `{company-slug}` = Firmenname in Kleinbuchstaben, ohne Leerzeichen (Bindestriche verwenden)
|
||||
- `{YYYY-MM-DD}` = aktuelles Datum
|
||||
|
||||
**Report-Format:**
|
||||
|
||||
```markdown
|
||||
# Bewertung: {Firma} — {Rolle}
|
||||
|
||||
**Datum:** {YYYY-MM-DD}
|
||||
**Archetyp:** {erkannt}
|
||||
**Score:** {X/5}
|
||||
**URL:** {URL der Stellenanzeige}
|
||||
**PDF:** {Pfad oder ausstehend}
|
||||
|
||||
---
|
||||
|
||||
## A) Rollen-Zusammenfassung
|
||||
(vollständiger Inhalt von Block A)
|
||||
|
||||
## B) Match mit dem Lebenslauf
|
||||
(vollständiger Inhalt von Block B)
|
||||
|
||||
## C) Level und Strategie
|
||||
(vollständiger Inhalt von Block C)
|
||||
|
||||
## D) Vergütung und Nachfrage
|
||||
(vollständiger Inhalt von Block D)
|
||||
|
||||
## E) Personalisierungs-Plan
|
||||
(vollständiger Inhalt von Block E)
|
||||
|
||||
## F) Vorstellungsgesprächs-Plan
|
||||
(vollständiger Inhalt von Block F)
|
||||
|
||||
## G) Draft-Antworten für die Bewerbung
|
||||
(nur bei Score >= 4.5 — Entwürfe für die Antwortfelder im Bewerbungsformular)
|
||||
|
||||
---
|
||||
|
||||
## Extrahierte Keywords
|
||||
(Liste mit 15-20 Keywords aus der Stellenanzeige für ATS-Optimierung)
|
||||
```
|
||||
|
||||
### 2. Im Tracker eintragen
|
||||
|
||||
**IMMER** in `data/applications.md` eintragen:
|
||||
- Nächste fortlaufende Nummer
|
||||
- Aktuelles Datum
|
||||
- Firma
|
||||
- Rolle
|
||||
- Score: Match-Durchschnitt (1-5)
|
||||
- Status: `Evaluated`
|
||||
- PDF: ❌ (oder ✅, wenn Auto-Pipeline ein PDF erzeugt hat)
|
||||
- Report: relativer Link zur Report-Datei (z. B. `[001](reports/001-company-2026-01-01.md)`)
|
||||
|
||||
**Tracker-Format:**
|
||||
|
||||
```markdown
|
||||
| # | Datum | Firma | Rolle | Score | Status | PDF | Report |
|
||||
```
|
||||
@@ -0,0 +1,114 @@
|
||||
# Modus: bewerben — Live-Assistent fürs Bewerbungsformular
|
||||
|
||||
Interaktiver Modus für den Moment, in dem der Kandidat in Chrome ein Bewerbungsformular ausfüllt. Liest, was auf dem Bildschirm steht, lädt den Kontext der vorherigen Bewertung der Stellenanzeige und erzeugt passgenaue Antworten für jede Frage des Formulars.
|
||||
|
||||
## Voraussetzungen
|
||||
|
||||
- **Empfohlen mit sichtbarem Playwright**: Im sichtbaren Modus sieht der Kandidat den Browser, und Claude kann mit der Seite interagieren.
|
||||
- **Ohne Playwright**: Der Kandidat teilt einen Screenshot oder fügt die Fragen manuell ein.
|
||||
|
||||
## Workflow
|
||||
|
||||
```
|
||||
1. ERKENNEN → aktiven Chrome-Tab lesen (Screenshot / URL / Titel)
|
||||
2. IDENTIFIZIEREN → Firma + Rolle aus der Seite extrahieren
|
||||
3. SUCHEN → mit bestehenden Reports unter reports/ abgleichen
|
||||
4. LADEN → vollständigen Report lesen + Block G (falls vorhanden)
|
||||
5. VERGLEICHEN → Stimmt die Rolle auf dem Bildschirm mit der bewerteten überein? Wenn sie sich geändert hat → warnen
|
||||
6. ANALYSIEREN → ALLE sichtbaren Fragen des Formulars identifizieren
|
||||
7. ERZEUGEN → Für jede Frage eine passgenaue Antwort generieren
|
||||
8. PRÄSENTIEREN → Antworten formatiert zum Copy-Paste ausgeben
|
||||
```
|
||||
|
||||
## Schritt 1 — Stellenanzeige erkennen
|
||||
|
||||
**Mit Playwright:** Snapshot der aktiven Seite. Titel, URL und sichtbaren Inhalt lesen.
|
||||
|
||||
**Ohne Playwright:** Den Kandidaten bitten, eines der folgenden zu tun:
|
||||
- Einen Screenshot des Formulars teilen (das Read-Tool kann Bilder lesen)
|
||||
- Die Fragen des Formulars als Text einfügen
|
||||
- Firma + Rolle nennen, damit wir den Kontext suchen können
|
||||
|
||||
## Schritt 2 — Identifizieren und Kontext laden
|
||||
|
||||
1. Firmennamen und Rollentitel von der Seite extrahieren
|
||||
2. In `reports/` per Grep (case-insensitive) nach dem Firmennamen suchen
|
||||
3. Bei Treffer → vollständigen Report laden
|
||||
4. Wenn Block G vorhanden ist → die früheren Draft-Antworten als Basis laden
|
||||
5. Wenn KEIN Treffer → den Kandidaten warnen und eine schnelle Auto-Pipeline anbieten
|
||||
|
||||
## Schritt 3 — Änderungen an der Rolle erkennen
|
||||
|
||||
Wenn die Rolle auf dem Bildschirm von der bewerteten abweicht:
|
||||
- **Den Kandidaten warnen**: "Die Rolle hat sich von [X] zu [Y] geändert. Soll ich neu bewerten oder die Antworten an den neuen Titel anpassen?"
|
||||
- **Wenn anpassen**: Antworten ohne Neu-Bewertung an den neuen Titel angleichen
|
||||
- **Wenn neu bewerten**: vollständige A-F-Bewertung durchführen, Report aktualisieren, Block G neu erzeugen
|
||||
- **Tracker aktualisieren**: in `applications.md` den Rollentitel anpassen, falls nötig
|
||||
|
||||
## Schritt 4 — Fragen des Formulars analysieren
|
||||
|
||||
ALLE sichtbaren Fragen identifizieren:
|
||||
- Freitextfelder (Anschreiben, "Warum diese Rolle", Motivation, etc.)
|
||||
- Dropdowns (Wie haben Sie von uns erfahren, Arbeitserlaubnis, etc.)
|
||||
- Ja/Nein (Umzug, Visum, Verfügbarkeit, etc.)
|
||||
- Gehaltsfelder (Spanne, Gehaltsvorstellung — in Brutto-Jahresgehalt für DE)
|
||||
- Upload-Felder (Lebenslauf, Anschreiben als PDF, Zeugnisse)
|
||||
|
||||
Jede Frage klassifizieren:
|
||||
- **Bereits in Block G beantwortet** → bestehende Antwort übernehmen
|
||||
- **Neue Frage** → Antwort aus dem Report + `cv.md` generieren
|
||||
|
||||
## Schritt 5 — Antworten erzeugen
|
||||
|
||||
Für jede Frage die Antwort nach folgendem Schema bauen:
|
||||
|
||||
1. **Kontext aus dem Report**: Proof Points aus Block B, STAR-Stories aus Block F nutzen
|
||||
2. **Vorheriger Block G**: Wenn ein Draft existiert, als Basis nehmen und nachschärfen
|
||||
3. **Ton "Ich entscheide mich für euch"**: gleiches Framework wie in der Auto-Pipeline — selbstbewusst, nicht bittend
|
||||
4. **Spezifität**: etwas Konkretes aus der sichtbaren Stellenanzeige zitieren
|
||||
5. **career-ops Proof Point**: in "Zusätzliche Informationen" einbauen, falls ein solches Feld existiert
|
||||
|
||||
**Spezielle deutsche Formularfelder, die häufig auftauchen:**
|
||||
- **Gehaltsvorstellung (brutto, jährlich)** → Spanne aus `profile.yml`, in EUR, mit Hinweis "verhandelbar je nach Gesamtpaket"
|
||||
- **Eintrittsdatum / Verfügbarkeit** → Realistisches Datum unter Berücksichtigung der Kündigungsfrist (oft 1-3 Monate)
|
||||
- **Arbeitserlaubnis / Aufenthaltsstatus** → ehrlich und knapp; bei EU-Bürgern explizit "Keine Arbeitserlaubnis erforderlich (EU-Bürger:in)"
|
||||
- **Sprachkenntnisse** → Deutsch / Englisch nach GER-Niveau (A1-C2) angeben
|
||||
- **Anrede** → bei deutschen Formularen oft Pflichtfeld (Herr / Frau / Divers / Keine)
|
||||
|
||||
**Output-Format:**
|
||||
|
||||
```
|
||||
## Antworten für [Firma] — [Rolle]
|
||||
|
||||
Basis: Report #NNN | Score: X.X/5 | Archetyp: [Typ]
|
||||
|
||||
---
|
||||
|
||||
### 1. [Exakte Frage aus dem Formular]
|
||||
> [Antwort, fertig zum Kopieren]
|
||||
|
||||
### 2. [Nächste Frage]
|
||||
> [Antwort]
|
||||
|
||||
...
|
||||
|
||||
---
|
||||
|
||||
Hinweise:
|
||||
- [Beobachtungen zur Rolle, Änderungen, etc.]
|
||||
- [Personalisierungs-Vorschläge, die der Kandidat nochmal prüfen sollte]
|
||||
```
|
||||
|
||||
## Schritt 6 — Nach dem Absenden (optional)
|
||||
|
||||
Wenn der Kandidat bestätigt, dass die Bewerbung raus ist:
|
||||
1. Status in `applications.md` von "Evaluated" auf "Applied" setzen
|
||||
2. Block G im Report mit den finalen Antworten aktualisieren
|
||||
3. Nächsten Schritt vorschlagen: `/career-ops contacto` für LinkedIn-Outreach an den Personalleiter / Hiring Manager
|
||||
|
||||
## Scroll-Handling
|
||||
|
||||
Wenn das Formular mehr Fragen hat als sichtbar:
|
||||
- Den Kandidaten bitten, zu scrollen und einen weiteren Screenshot zu teilen
|
||||
- Oder die restlichen Fragen einzufügen
|
||||
- In Iterationen verarbeiten, bis das ganze Formular abgedeckt ist
|
||||
@@ -0,0 +1,63 @@
|
||||
# Modus: pipeline — URL-Inbox (Second Brain)
|
||||
|
||||
Verarbeitet URLs von Stellenanzeigen, die in `data/pipeline.md` gesammelt wurden. Der Kandidat wirft URLs ins Inbox, wann immer er eine entdeckt, und führt später `/career-ops pipeline` aus, um sie alle in einem Rutsch zu verarbeiten.
|
||||
|
||||
## Workflow
|
||||
|
||||
1. **Lesen** von `data/pipeline.md` → alle Items mit `- [ ]` im Abschnitt "Pendientes" / "Pending" / "Offen" finden
|
||||
2. **Für jede offene URL**:
|
||||
a. Die nächste fortlaufende `REPORT_NUM` atomar reservieren, indem `node reserve-report-num.mjs` ausgeführt wird (und den Sentinel mit `node reserve-report-num.mjs --release <num>` freigeben, sobald der Report geschrieben ist)
|
||||
b. **Stellenanzeige extrahieren** mit Playwright (`browser_navigate` + `browser_snapshot`) → WebFetch → WebSearch
|
||||
c. Wenn die URL nicht erreichbar ist → als `- [!]` mit Notiz markieren und weitermachen
|
||||
d. **Vollständige Auto-Pipeline ausführen**: A-F-Bewertung → Report .md → PDF (wenn Score >= 3.0) → Tracker
|
||||
e. **Von "Offen" nach "Verarbeitet" verschieben**: `- [x] #NNN | URL | Firma | Rolle | Score/5 | PDF ✅/❌`
|
||||
3. **Bei 3+ offenen URLs** Agenten parallel starten (Agent-Tool mit `run_in_background`), um Tempo zu machen.
|
||||
4. **Am Ende** eine Zusammenfassungstabelle ausgeben:
|
||||
|
||||
```
|
||||
| # | Firma | Rolle | Score | PDF | Empfohlene Aktion |
|
||||
```
|
||||
|
||||
## Format von pipeline.md
|
||||
|
||||
```markdown
|
||||
## Offen
|
||||
- [ ] https://jobs.example.com/posting/123
|
||||
- [ ] https://boards.greenhouse.io/company/jobs/456 | Company GmbH | Senior PM
|
||||
- [!] https://private.url/job — Fehler: Login erforderlich
|
||||
|
||||
## Verarbeitet
|
||||
- [x] #143 | https://jobs.example.com/posting/789 | Acme GmbH | AI PM | 4.2/5 | PDF ✅
|
||||
- [x] #144 | https://boards.greenhouse.io/xyz/jobs/012 | BigCo | SA | 2.1/5 | PDF ❌
|
||||
```
|
||||
|
||||
> Hinweis: Die Sektion-Überschriften können auf EN ("Pending"/"Processed"), ES ("Pendientes"/"Procesadas") oder DE ("Offen"/"Verarbeitet") sein. Beim Lesen flexibel sein, beim Schreiben dem Stil der bestehenden Datei treu bleiben.
|
||||
|
||||
## Intelligente Erkennung der Stellenanzeige aus der URL
|
||||
|
||||
1. **Playwright (bevorzugt):** `browser_navigate` + `browser_snapshot`. Funktioniert mit allen SPAs.
|
||||
2. **WebFetch (Fallback):** Für statische Seiten oder wenn Playwright nicht verfügbar ist.
|
||||
3. **WebSearch (letzter Ausweg):** In sekundären Portalen suchen, die die Stellenanzeige indexieren.
|
||||
|
||||
**Sonderfälle:**
|
||||
- **LinkedIn**: Kann Login erfordern → mit `[!]` markieren und den Kandidaten bitten, den Text einzufügen
|
||||
- **PDF**: Wenn die URL auf ein PDF zeigt, direkt mit dem Read-Tool lesen
|
||||
- **`local:`-Präfix**: Lokale Datei lesen. Beispiel: `local:jds/linkedin-pm-ai.md` → `jds/linkedin-pm-ai.md` lesen
|
||||
- **StepStone / XING / kununu**: Häufig deutscher Markt, oft Cookie-Banner. Playwright kann in Snapshot scrollen, um den Anzeigentext zu erfassen
|
||||
- **Bundesagentur für Arbeit (arbeitsagentur.de)**: Strukturierte Stellenanzeigen, gut maschinenlesbar. WebFetch reicht meist
|
||||
|
||||
## Automatische Nummerierung
|
||||
|
||||
1. Führen Sie `node reserve-report-num.mjs` aus, um die nächste fortlaufende Nummer atomar zu reservieren (die Ausgabe gibt `{###}` zurück).
|
||||
2. Schreiben Sie den Report mit dieser Nummer.
|
||||
3. Geben Sie den Sentinel mit `node reserve-report-num.mjs --release {###}` frei, sobald der Report geschrieben ist.
|
||||
|
||||
## Synchronisierung der Quellen
|
||||
|
||||
Vor dem Verarbeiten irgendeiner URL die Sync prüfen:
|
||||
|
||||
```bash
|
||||
node cv-sync-check.mjs
|
||||
```
|
||||
|
||||
Bei Abweichungen den Kandidaten warnen, bevor weitergearbeitet wird.
|
||||
@@ -0,0 +1,47 @@
|
||||
# Mode: deep — Deep Research Prompt
|
||||
|
||||
Generate a structured prompt for Perplexity/Claude/ChatGPT with 6 axes:
|
||||
|
||||
```text
|
||||
## Deep Research: [Company] — [Role]
|
||||
|
||||
Context: I am evaluating a candidacy for [role] at [company]. I need actionable information for the interview.
|
||||
|
||||
### 1. AI Strategy
|
||||
- What products/features use AI/ML?
|
||||
- What is their AI stack? (models, infrastructure, tools)
|
||||
- Do they have an engineering blog? What do they publish?
|
||||
- What papers or talks have they presented on AI?
|
||||
|
||||
### 2. Recent moves (last 6 months)
|
||||
- Relevant hires in AI/ML/product?
|
||||
- Acquisitions or partnerships?
|
||||
- Product launches or pivots?
|
||||
- Funding rounds or leadership changes?
|
||||
|
||||
### 3. Engineering culture
|
||||
- How do they ship? (deployment cadence, CI/CD)
|
||||
- Monorepo or multirepo?
|
||||
- What languages/frameworks do they use?
|
||||
- Remote-first or office-first?
|
||||
- Glassdoor/Blind reviews about engineering culture?
|
||||
|
||||
### 4. Likely challenges
|
||||
- What scaling problems do they have?
|
||||
- Reliability, cost, latency challenges?
|
||||
- Are they migrating anything? (infrastructure, models, platforms)
|
||||
- What pain points do people mention in reviews?
|
||||
|
||||
### 5. Competitors and differentiation
|
||||
- Who are their main competitors?
|
||||
- What is their moat/differentiator?
|
||||
- How are they positioned vs competitors?
|
||||
|
||||
### 6. Candidate angle
|
||||
Given my profile (read from cv.md and profile.yml for specific experience):
|
||||
- What unique value do I bring to this team?
|
||||
- Which of my projects are most relevant?
|
||||
- What story should I tell in the interview?
|
||||
```
|
||||
|
||||
Personalize each section with the specific context of the job being evaluated.
|
||||
+259
@@ -0,0 +1,259 @@
|
||||
# Mode: email — Application Email Drafts
|
||||
|
||||
Generate a formal application email body that the candidate can paste into an
|
||||
email client. This mode is for direct application emails, recruiter follow-up
|
||||
emails with a CV attached, referral request emails, and cold application emails.
|
||||
|
||||
It is NOT:
|
||||
- `contacto`: short LinkedIn / BOSS Zhipin / chat-style outreach.
|
||||
- `cover`: a full cover letter PDF.
|
||||
- `apply`: live application form filling.
|
||||
|
||||
**Never submit. Never send email. Never click send.** Draft only. The candidate
|
||||
must review and send manually.
|
||||
|
||||
---
|
||||
|
||||
## Invocation
|
||||
|
||||
Supported inputs:
|
||||
|
||||
1. `/career-ops email {report-number-or-slug}`
|
||||
- Load the matching `reports/{NNN}-*.md`.
|
||||
- Use the report header, score, archetype, PDF status, and evaluation content.
|
||||
- If `data/pdf-index.tsv` contains a PDF for that report, mention it as the CV
|
||||
attachment candidate. If no PDF is indexed, say that the CV should be
|
||||
generated first via `/career-ops pdf {slug}` or attached manually.
|
||||
|
||||
2. `/career-ops email {pasted JD}`
|
||||
- Use the pasted JD directly.
|
||||
- Do not create a report, tracker row, PDF, or cover letter.
|
||||
- Ask for company name if the JD lacks it and the email would otherwise read
|
||||
generic.
|
||||
|
||||
3. `/career-ops email`
|
||||
- If there is a most recent evaluated tracker row, offer to draft from that
|
||||
row.
|
||||
- If no usable context exists, ask for a report number, slug, or JD.
|
||||
|
||||
---
|
||||
|
||||
## Step 1 — Load Context
|
||||
|
||||
Read:
|
||||
- `config/profile.yml`
|
||||
- `cv.md`
|
||||
- `article-digest.md` if it exists
|
||||
- `modes/_profile.md` if it exists
|
||||
- `modes/_custom.md` if it exists
|
||||
- `voice-dna.md` if it exists, for writing style only
|
||||
- The selected report if invoked by report number or slug
|
||||
- `data/pdf-index.tsv` if present, to find generated PDF attachments
|
||||
|
||||
Use `modes/_custom.md` only for procedural output preferences such as whether to
|
||||
include a contact block, whether to show an attachment checklist, or how concise
|
||||
the email should be. It must never introduce contact details, work experience,
|
||||
or other factual claims.
|
||||
|
||||
Use `voice-dna.md` only as a writing guardrail. It must never introduce factual
|
||||
claims.
|
||||
|
||||
### Profile fields
|
||||
|
||||
Use these optional fields when present:
|
||||
- `candidate.full_name`
|
||||
- `candidate.chinese_name`
|
||||
- `candidate.email`
|
||||
- `candidate.phone`
|
||||
- `candidate.wechat`
|
||||
- `candidate.location`
|
||||
- `candidate.linkedin`
|
||||
- `candidate.github`
|
||||
- `candidate.portfolio_url`
|
||||
- `application_email.default_sender_note`
|
||||
- `application_email.include_contact_block`
|
||||
- `application_email.include_attachment_checklist`
|
||||
- `application_email.signature_name`
|
||||
- `contact_preferences.preferred_channel`
|
||||
- `contact_preferences.note`
|
||||
|
||||
If `candidate.wechat` is absent, omit WeChat. Do not invent one.
|
||||
|
||||
---
|
||||
|
||||
## Step 2 — Classify Email Type
|
||||
|
||||
Choose one of three variants from user wording or context:
|
||||
|
||||
| Variant | When | Tone |
|
||||
|---|---|---|
|
||||
| `hr_application` | Default. Sending CV to HR/recruiter for a posted role. | Formal, concise, screening-friendly |
|
||||
| `referral_request` | User asks for referral, internal contact, friend, alumni, or former colleague. | Warm, low-pressure, easy to forward |
|
||||
| `cold_application` | No posted role, speculative reach-out, "cold email". | Direct, value-first, no desperation |
|
||||
|
||||
If unclear, default to `hr_application`.
|
||||
|
||||
---
|
||||
|
||||
## Step 3 — Extract Fit Points
|
||||
|
||||
From the report/JD and source-of-truth files, select 2-3 fit points:
|
||||
|
||||
- One role-to-profile match: stack, domain, workflow, product type, or delivery
|
||||
style.
|
||||
- One proof point: project, metric, open-source contribution, or shipped system.
|
||||
- One differentiator: business ownership, domain knowledge, communication,
|
||||
open-source ecosystem, or production handover.
|
||||
|
||||
Use only facts from source-of-truth files. Reformulate keywords from the JD;
|
||||
never fabricate.
|
||||
|
||||
If a report has a score:
|
||||
- `>= 4.5`: confident, priority application.
|
||||
- `4.0-4.4`: good match, worth applying.
|
||||
- `< 4.0`: restrained; do not oversell. If below 4.0, warn the user before
|
||||
drafting that career-ops normally recommends against applying.
|
||||
|
||||
---
|
||||
|
||||
## Step 4 — Attachment Checklist
|
||||
|
||||
Before the draft, output:
|
||||
|
||||
```text
|
||||
Attachments to include:
|
||||
- CV: {pdf path or "attach your tailored CV"}
|
||||
- Cover letter: {path if known, otherwise "optional / not generated"}
|
||||
```
|
||||
|
||||
Rules:
|
||||
- If `application_email.include_attachment_checklist` is `false`, omit this
|
||||
checklist.
|
||||
- Mention only files that exist or are indexed. Do not claim a cover letter
|
||||
exists unless it does.
|
||||
- Do not attach files or send anything.
|
||||
|
||||
---
|
||||
|
||||
## Step 5 — Draft Structure
|
||||
|
||||
Always output:
|
||||
|
||||
```text
|
||||
Subject: {subject}
|
||||
|
||||
{email body}
|
||||
```
|
||||
|
||||
### HR application structure
|
||||
|
||||
1. Greeting
|
||||
2. Role intent and attachment sentence
|
||||
3. 2-3 fit points in one short paragraph or compact bullets
|
||||
4. Why this role is relevant, using JD language
|
||||
5. Contact block and signature
|
||||
|
||||
### Referral request structure
|
||||
|
||||
1. Greeting
|
||||
2. One-line context: role and company
|
||||
3. 2 concise proof points that are easy to forward
|
||||
4. Low-pressure ask: "If this looks aligned, would you be comfortable referring
|
||||
me or pointing me to the right person?"
|
||||
5. Contact block and signature
|
||||
|
||||
### Cold application structure
|
||||
|
||||
1. Greeting
|
||||
2. Value proposition first, not "I am looking for a job"
|
||||
3. 2 proof points tied to the company/domain
|
||||
4. Specific ask: short call, right contact, or permission to send CV
|
||||
5. Contact block and signature
|
||||
|
||||
---
|
||||
|
||||
## Language
|
||||
|
||||
- Match the JD/report language.
|
||||
- If the JD is Chinese, use Simplified Chinese.
|
||||
- If the company/recruiter language is unknown, default to the user's language.
|
||||
- Keep the subject line in the same language as the body unless the user asks
|
||||
otherwise.
|
||||
|
||||
---
|
||||
|
||||
## Contact Block
|
||||
|
||||
Default behavior:
|
||||
- Include contact block for direct application emails.
|
||||
- Omit phone in short social outreach; this mode is not short social outreach.
|
||||
|
||||
Use:
|
||||
|
||||
```text
|
||||
联系方式：
|
||||
{if candidate.wechat}微信：{candidate.wechat}{/if}
|
||||
{if candidate.phone}手机号：{candidate.phone}{/if}
|
||||
{if candidate.email or application_email.default_sender_note}邮箱：{candidate.email or application_email.default_sender_note}{/if}
|
||||
```
|
||||
|
||||
For English:
|
||||
|
||||
```text
|
||||
Contact:
|
||||
{if candidate.wechat}WeChat: {candidate.wechat}{/if}
|
||||
{if candidate.phone}Phone: {candidate.phone}{/if}
|
||||
{if candidate.email or application_email.default_sender_note}Email: {candidate.email or application_email.default_sender_note}{/if}
|
||||
```
|
||||
|
||||
If `application_email.default_sender_note` is set in `config/profile.yml` to a
|
||||
phrase such as "the email used to send this message", use that phrase instead of
|
||||
a concrete email address.
|
||||
|
||||
If `application_email.include_contact_block` is `false`, use a normal signature
|
||||
only.
|
||||
|
||||
**Contact channel preference:** If `application_email.include_contact_block` is
|
||||
`true` (or absent/default), check `contact_preferences.preferred_channel` in
|
||||
`config/profile.yml`. If it is absent or set to `"either"`, the contact block
|
||||
stays exactly as above — no change. If it is set to `"email"` or `"phone"`, add
|
||||
one short line directly under the contact block naming that preference, e.g.:
|
||||
|
||||
```text
|
||||
Contact:
|
||||
Email: jane@example.com
|
||||
Phone: +1-555-0123
|
||||
(Prefers email first.)
|
||||
```
|
||||
|
||||
If `contact_preferences.note` is set, use its wording (or a close paraphrase)
|
||||
for that line instead of a generic phrase. Keep it to one line, no bold, no
|
||||
extra emphasis -- it should read as a practical note, not a demand.
|
||||
|
||||
---
|
||||
|
||||
## Style Rules
|
||||
|
||||
- No corporate-speak.
|
||||
- No "passionate about", "perfect fit", "unique opportunity", or vague praise.
|
||||
- No exaggerated authorship claims.
|
||||
- Short paragraphs. Prefer 150-250 words for HR applications.
|
||||
- Keep the proof easy to scan.
|
||||
- Do not include salary unless the user asks.
|
||||
- Do not include private references, ID numbers, or unsupported claims.
|
||||
|
||||
---
|
||||
|
||||
## Output
|
||||
|
||||
Return in this order:
|
||||
|
||||
1. Context line:
|
||||
- `Source: report {NNN}` or `Source: pasted JD`
|
||||
- Variant
|
||||
- Language
|
||||
2. Attachment checklist, unless disabled
|
||||
3. Subject and email body
|
||||
4. One-line note with any missing inputs or assumptions
|
||||
|
||||
Do not write files unless the user explicitly asks to save the draft.
|
||||
@@ -0,0 +1,105 @@
|
||||
# career-ops -- Modos en español (`modes/es/`)
|
||||
|
||||
Esta carpeta contiene las traducciones al español de los principales modos de career-ops para candidatos que apuntan al mercado hispanohablante (España, México, Argentina, Colombia, Chile y otros países de LATAM).
|
||||
|
||||
## ¿Cuándo usar estos modos?
|
||||
|
||||
Usa `modes/es/` si se cumple al menos una de estas condiciones:
|
||||
|
||||
- Aplicas principalmente a **ofertas de empleo en español** (InfoJobs, LinkedIn ES, Indeed ES, Tecnoempleo, Computrabajo, portales de empleo corporativos)
|
||||
- Tu **CV está en español** o alternas entre ES e EN según la oferta
|
||||
- Necesitas respuestas y cartas de presentación en **español técnico natural**, no traducido por una máquina
|
||||
- Debes gestionar **especificidades contractuales hispanohablantes**: convenio colectivo, pagas extra, IRPF, Seguridad Social, período de prueba, preaviso, ticket restaurante, seguro médico, contrato indefinido/temporal
|
||||
|
||||
Si la mayoría de tus ofertas son en inglés, quédate con los modos estándar en `modes/`. Los modos en inglés funcionan para ofertas hispanohablantes, pero no conocen las especificidades del mercado en detalle.
|
||||
|
||||
## ¿Cómo activar?
|
||||
|
||||
### Opción 1 -- Por sesión
|
||||
|
||||
Di al agente al inicio de la sesión:
|
||||
|
||||
> "Usa los modos en español de `modes/es/`."
|
||||
|
||||
El agente leerá entonces los archivos de esta carpeta en lugar de `modes/`.
|
||||
|
||||
### Opción 2 -- De forma permanente
|
||||
|
||||
Añade en `config/profile.yml`:
|
||||
|
||||
```yaml
|
||||
language:
|
||||
primary: es
|
||||
modes_dir: modes/es
|
||||
```
|
||||
|
||||
Recuérdaselo al agente en tu primera sesión ("Mira en `profile.yml`, he configurado `language.modes_dir`"). El agente usará automáticamente los modos en español.
|
||||
|
||||
## ¿Qué modos están traducidos?
|
||||
|
||||
Esta primera iteración cubre los cuatro modos de mayor impacto:
|
||||
|
||||
| Archivo | Traducido desde | Rol |
|
||||
|---------|-----------------|-----|
|
||||
| `_shared.md` | `modes/_shared.md` (EN) | Contexto compartido, arquetipos, reglas globales, especificidades del mercado hispanohablante |
|
||||
| `oferta.md` | `modes/oferta.md` (ES) | Evaluación completa de una oferta (Bloques A-F) |
|
||||
| `aplicar.md` | `modes/apply.md` (EN) | Asistente en vivo para rellenar formularios de candidatura |
|
||||
| `pipeline.md` | `modes/pipeline.md` (ES) | Bandeja de URLs / Second Brain para las ofertas recopiladas |
|
||||
|
||||
Los demás modos (`scan`, `batch`, `pdf`, `tracker`, `auto-pipeline`, `deep`, `contacto`, `ofertas`, `project`, `training`) se mantienen en EN/ES. Su contenido es principalmente tooling, rutas y comandos — debe permanecer independiente del idioma.
|
||||
|
||||
## Lo que permanece en inglés
|
||||
|
||||
No traducido intencionadamente, por ser vocabulario técnico estándar:
|
||||
|
||||
- `cv.md`, `pipeline`, `tracker`, `report`, `score`, `archetype`, `proof point`
|
||||
- Nombres de herramientas (`Playwright`, `WebSearch`, `WebFetch`, `Read`, `Write`, `Edit`, `Bash`)
|
||||
- Valores de estado en el tracker (`Evaluated`, `Applied`, `Interview`, `Offer`, `Rejected`)
|
||||
- Fragmentos de código, rutas, comandos
|
||||
|
||||
Los modos usan español técnico natural, tal como se habla en equipos de ingeniería en Madrid, Barcelona, Ciudad de México o Buenos Aires: texto corriente en español, términos técnicos en inglés donde es el uso habitual. Sin traducción forzada de "Pipeline" a "Canalización" ni de "Deploy" a "Despliegue aplicativo".
|
||||
|
||||
## Glosario de referencia
|
||||
|
||||
Para mantener un tono coherente si modificas o amplías los modos:
|
||||
|
||||
| Inglés | Español (en esta codebase) |
|
||||
|--------|---------------------------|
|
||||
| Job posting | Oferta de empleo / Anuncio |
|
||||
| Application | Candidatura |
|
||||
| Cover letter | Carta de presentación |
|
||||
| Resume / CV | CV |
|
||||
| Salary | Salario / Remuneración |
|
||||
| Compensation | Remuneración / Paquete retributivo |
|
||||
| Skills | Competencias / Habilidades |
|
||||
| Interview | Entrevista |
|
||||
| Hiring manager | Manager de contratación / Hiring manager |
|
||||
| Recruiter | Reclutador (o Recruiter) |
|
||||
| AI | IA (Inteligencia Artificial) |
|
||||
| Requirements | Requisitos |
|
||||
| Career history | Trayectoria profesional |
|
||||
| Notice period | Preaviso |
|
||||
| Probation | Período de prueba |
|
||||
| Vacation | Vacaciones / Días de libre disposición |
|
||||
| Extra pay / 13th month | Pagas extra (14 pagas al año) |
|
||||
| Permanent employment | Contrato indefinido |
|
||||
| Fixed-term contract | Contrato temporal |
|
||||
| Freelance | Freelance / Autónomo |
|
||||
| Collective agreement | Convenio colectivo |
|
||||
| Works council | Comité de empresa |
|
||||
| Profit sharing | Participación en beneficios |
|
||||
| Meal vouchers | Ticket restaurante / Cheque gourmet |
|
||||
| Health insurance | Seguro médico privado |
|
||||
| Disability/life insurance | Seguro de vida / Incapacidad |
|
||||
| Income tax withholding | IRPF |
|
||||
| Social security | Seguridad Social |
|
||||
|
||||
## Contribuir
|
||||
|
||||
Para mejorar una traducción o añadir un modo:
|
||||
|
||||
1. Abre un Issue con tu propuesta (ver `CONTRIBUTING.md`)
|
||||
2. Respeta el glosario anterior para mantener un tono coherente
|
||||
3. Traduce de forma idiomática — sin traducción palabra por palabra
|
||||
4. Conserva los elementos estructurales (Bloques A-F, tablas, bloques de código, instrucciones de herramientas) tal cual
|
||||
5. Prueba con una oferta hispanohablante real (InfoJobs, LinkedIn ES, Indeed ES) antes de enviar el PR
|
||||
@@ -0,0 +1,203 @@
|
||||
# Contexto compartido -- career-ops (Español)
|
||||
|
||||
<!-- ============================================================
|
||||
PERSONALIZACIÓN DE ESTE ARCHIVO
|
||||
============================================================
|
||||
Este archivo contiene el contexto compartido para todos los modos
|
||||
career-ops en versión española. Antes de usar career-ops, DEBES:
|
||||
1. Rellenar config/profile.yml con tus datos personales
|
||||
2. Crear cv.md en la raíz del proyecto (CV en Markdown)
|
||||
3. (Opcional) Crear article-digest.md con tus proof points
|
||||
4. Adaptar las secciones marcadas como [PERSONALIZAR] más abajo
|
||||
============================================================ -->
|
||||
|
||||
## Fuentes de verdad (SIEMPRE leer antes de cada evaluación)
|
||||
|
||||
| Archivo | Ruta | Cuándo |
|
||||
|---------|------|--------|
|
||||
| cv.md | `cv.md` (raíz del proyecto) | SIEMPRE |
|
||||
| article-digest.md | `article-digest.md` (si existe) | SIEMPRE (proof points detallados) |
|
||||
| profile.yml | `config/profile.yml` | SIEMPRE (identidad y roles objetivo) |
|
||||
|
||||
**REGLA: NUNCA codificar métricas de los proof points en duro.** Leerlas desde `cv.md` y `article-digest.md` en el momento de la evaluación.
|
||||
**REGLA: Para métricas de artículos/proyectos, `article-digest.md` tiene prioridad sobre `cv.md`** (`cv.md` puede contener cifras más antiguas).
|
||||
|
||||
---
|
||||
|
||||
## North Star -- Roles objetivo
|
||||
|
||||
El skill trata TODOS los roles objetivo con el mismo cuidado. Ninguno es primario o secundario — cada uno es un éxito si la remuneración y las perspectivas de crecimiento son las adecuadas:
|
||||
|
||||
| Arquetipo | Ejes temáticos | Lo que la empresa compra |
|
||||
|-----------|----------------|--------------------------|
|
||||
| **AI Platform / LLMOps Engineer** | Evaluación, Observabilidad, Fiabilidad, Pipelines | Alguien que lleva la IA a producción con métricas |
|
||||
| **Agentic Workflows / Automation** | HITL, Tooling, Orchestration, Multi-Agent | Alguien que construye sistemas agénticos fiables |
|
||||
| **Technical AI Product Manager** | GenAI/Agents, PRDs, Discovery, Delivery | Alguien que traduce el negocio en productos de IA |
|
||||
| **AI Solutions Architect** | Hyperautomation, Enterprise, Integrations | Alguien que diseña arquitecturas de IA end-to-end |
|
||||
| **AI Forward Deployed Engineer** | Client-facing, Entrega rápida, Prototipado | Alguien que despliega soluciones de IA rápidamente en el cliente |
|
||||
| **AI Transformation Lead** | Gestión del cambio, Adopción, Enablement | Alguien que lidera la transformación de IA en organizaciones |
|
||||
|
||||
<!-- [PERSONALIZAR] Adapta los arquetipos anteriores a tus roles objetivo.
|
||||
Ejemplo para backend engineering:
|
||||
- Senior Backend Engineer
|
||||
- Staff Platform Engineer
|
||||
- Engineering Manager
|
||||
etc. -->
|
||||
|
||||
### Framing adaptativo por arquetipo
|
||||
|
||||
> **Métricas concretas: leerlas desde `cv.md` y `article-digest.md` en el momento de la evaluación. NUNCA codificarlas en duro aquí.**
|
||||
|
||||
| Si el rol es... | Destacar del candidato... | Fuentes de proof points |
|
||||
|-----------------|---------------------------|-------------------------|
|
||||
| Platform / LLMOps | Experiencia en producción, observabilidad, evals, closed-loop | article-digest.md + cv.md |
|
||||
| Agentic / Automation | Orquestación multi-agente, HITL, fiabilidad, costes | article-digest.md + cv.md |
|
||||
| Technical AI PM | Product discovery, PRDs, métricas, gestión de stakeholders | cv.md + article-digest.md |
|
||||
| Solutions Architect | Diseño de sistemas, integraciones, enterprise-ready | article-digest.md + cv.md |
|
||||
| Forward Deployed Engineer | Entrega rápida, cercanía al cliente, prototipo a producción | cv.md + article-digest.md |
|
||||
| AI Transformation Lead | Gestión del cambio, enablement de equipo, adopción | cv.md + article-digest.md |
|
||||
|
||||
<!-- [PERSONALIZAR] Asocia tus proyectos/artículos concretos a los arquetipos anteriores -->
|
||||
|
||||
### Narrativa de transición (usar en TODOS los framings)
|
||||
|
||||
<!-- [PERSONALIZAR] Reemplaza con tu propia narrativa. Ejemplos:
|
||||
- "SaaS construida y vendida tras 5 años. Ahora 100% enfocado en IA aplicada en empresa."
|
||||
- "Lead de ingeniería en una Series-B durante un crecimiento x10. Buscando el siguiente reto."
|
||||
- "Transición de consultoría a producto. En búsqueda de roles con alta responsabilidad."
|
||||
Leído desde config/profile.yml -> narrative.exit_story -->
|
||||
|
||||
Usar la narrativa de transición desde `config/profile.yml` para enmarcar TODOS los contenidos:
|
||||
- **En los summaries del PDF:** Tender el puente entre el pasado y el futuro — "Ahora aplico las mismas [competencias] al dominio [de la oferta]."
|
||||
- **En las stories STAR:** Hacer referencia a los proof points de `article-digest.md`.
|
||||
- **En los borradores de respuestas (Bloque G):** La narrativa de transición va en la primera respuesta.
|
||||
- **Cuando la oferta menciona "emprendedor", "autonomía", "builder", "end-to-end":** Es EL diferenciador n.º 1. Aumentar el peso del match.
|
||||
|
||||
### Ventaja transversal
|
||||
|
||||
Enmarcar el perfil como **"Builder técnico con una práctica demostrable"**, adaptando el framing al rol:
|
||||
- Para PM: "Builder que reduce la incertidumbre con prototipos y luego entrega en producción de forma disciplinada"
|
||||
- Para FDE: "Builder que entrega desde el día 1 con observabilidad y métricas"
|
||||
- Para SA: "Builder que diseña sistemas end-to-end con experiencia real de integración"
|
||||
- Para LLMOps: "Builder que lleva la IA a producción con sistemas de calidad en bucle cerrado"
|
||||
|
||||
Posicionar "Builder" como señal profesional — no como "artesano improvisado". Los proof points reales lo hacen creíble.
|
||||
|
||||
### Portfolio como proof point (usar en candidaturas de alto impacto)
|
||||
|
||||
<!-- [PERSONALIZAR] Si tienes una demo en vivo, un dashboard o un proyecto público, configúralo aquí.
|
||||
Ejemplo:
|
||||
dashboard:
|
||||
url: "https://tudominio.dev/demo"
|
||||
password: "demo-2026"
|
||||
when_to_share: "Roles LLMOps, AI Platform, Observability"
|
||||
Leído desde config/profile.yml -> narrative.proof_points y narrative.dashboard -->
|
||||
|
||||
Si el candidato tiene una demo en vivo / un dashboard (verificar `profile.yml`), ofrecer el acceso en las candidaturas relevantes.
|
||||
|
||||
### Inteligencia de remuneración (Comp Intelligence)
|
||||
|
||||
<!-- [PERSONALIZAR] Investiga los rangos salariales para tus roles objetivo y ajusta los valores -->
|
||||
|
||||
**Consejos generales:**
|
||||
- WebSearch para datos de mercado actuales (Glassdoor, LinkedIn Salary Insights, InfoJobs Estudios Salariales, Levels.fyi, Talent.io, Indeed Salarios)
|
||||
- Enmarcar por título del puesto, no por competencias — los títulos definen las bandas salariales
|
||||
- Las tarifas freelance/autónomo en España suelen ser un 30-50% por encima del equivalente bruto por hora en nómina (cuotas de autónomo, vacaciones, baja, prospección)
|
||||
- El geo-arbitraje funciona en remoto: menor coste de vida = mejor neto
|
||||
|
||||
### Mercado hispanohablante -- Especificidades (IMPORTANTE)
|
||||
|
||||
En las ofertas y negociaciones en español, ciertos términos no existen en los mercados EN/FR. Se DEBEN tener en cuenta correctamente:
|
||||
|
||||
| Término | Significado | Impacto en la evaluación |
|
||||
|---------|-------------|--------------------------|
|
||||
| **Contrato indefinido** | Equivalente al "permanent employment". El estándar en España | Lo esperado. Un contrato temporal para un senior es una señal de alerta |
|
||||
| **Contrato temporal / fijo-discontinuo** | Contrato de duración determinada o con actividad estacional | Aceptable para proyectos concretos. Si no, preguntar por qué no es indefinido |
|
||||
| **Período de prueba** | 6 meses para técnicos/directivos (España). Varía por convenio | Estándar de mercado. Señalar si supera los 6 meses |
|
||||
| **Preaviso** | 15 días a 3 meses según convenio y antigüedad | Planificar la fecha de incorporación en consecuencia |
|
||||
| **Convenio colectivo** | Acuerdo sectorial que regula condiciones mínimas (TIC, Consultoría, Metal…) | Verificar la categoría profesional para validar el salario |
|
||||
| **Pagas extra** | Habitualmente 2 pagas extra (junio/diciembre) = 14 pagas al año | Incluir en el cálculo: salario bruto anual ÷ 14 ≠ ÷ 12. NUNCA olvidar en la comparación |
|
||||
| **IRPF** | Retención fiscal sobre el salario (variable según tramo y situación personal) | Solicitar nómina estimada neta además del bruto. El neto real depende del tramo |
|
||||
| **Seguridad Social** | Cotización del trabajador (~6,35% aprox.). Descuento automático en nómina | Factor en el cálculo neto. El empleador cotiza adicionalmente ~30% aparte |
|
||||
| **Ticket restaurante / cheque gourmet** | Vales de comida (Sodexo, Edenred, Coverflex). Parte exenta de IRPF hasta 11 €/día | Beneficio habitual. ~1.500-2.500 €/año de ahorro efectivo en empresas grandes |
|
||||
| **Seguro médico privado** | Cobertura sanitaria privada aportada por la empresa | Beneficio valorado. Verificar si cubre familia, dental y óptica |
|
||||
| **Plan de pensiones** | Aportación empresa al plan de pensiones del empleado | Poco extendido en startups, más común en grandes corporaciones |
|
||||
| **Teletrabajo / Remoto / Híbrido** | Modalidad de trabajo. "Híbrido" varía mucho (1 día/sem ≠ 3 días/sem) | Concretar días presenciales exactos. "Flexible" sin cifra = señal de alerta |
|
||||
| **Autónomo / Freelance** | Trabajador por cuenta propia. Cuota de autónomo ~300-500 €/mes | Tarifa diaria o mensual. Sumar cuota + vacaciones + baja al calcular el coste real |
|
||||
| **ETT** (Empresa de Trabajo Temporal) | Contratación a través de una tercera empresa | Inferior al indefinido directo. Aceptable solo para proyectos muy concretos |
|
||||
|
||||
### Scripts de negociación
|
||||
|
||||
<!-- [PERSONALIZAR] Adapta a tu situación -->
|
||||
|
||||
**Pretensiones salariales (marco general):**
|
||||
> "Basándome en los datos de mercado actuales para este tipo de puesto, busco una horquilla de [HORQUILLA desde profile.yml]. Soy flexible en la estructura — lo que importa es el paquete global y las perspectivas de crecimiento."
|
||||
|
||||
**Respuesta a una reducción geográfica:**
|
||||
> "Los roles en los que compito están orientados a resultados, no a ubicación. Mi historial no cambia según el código postal."
|
||||
|
||||
**Si la oferta está por debajo del objetivo:**
|
||||
> "Actualmente estoy en conversaciones sobre paquetes en la horquilla [horquilla superior]. [Empresa] me atrae por [razón]. ¿Es posible llegar a [objetivo]?"
|
||||
|
||||
**Negociación sobre pagas extra / variable:**
|
||||
> "Para comparar los paquetes de forma justa, ¿podrían detallar el fijo bruto anual, las pagas extra y la parte variable por separado?"
|
||||
|
||||
### Política de localización (Location Policy)
|
||||
|
||||
<!-- [PERSONALIZAR] Adapta a tu situación. Leído desde config/profile.yml -> location -->
|
||||
|
||||
**En los formularios:**
|
||||
- Preguntas binarias "¿Puede estar en oficina?": responder según la disponibilidad real en `profile.yml`
|
||||
- Campos libres: indicar el solapamiento horario y la disponibilidad de forma explícita
|
||||
|
||||
**En las evaluaciones (scoring):**
|
||||
- Dimensión remoto para híbrido fuera de tu país: Score **3.0** (no 1.0)
|
||||
- Score 1.0 solo si la oferta dice explícitamente "presencia obligatoria 4-5 días/semana, sin excepciones"
|
||||
|
||||
### Prioridad time-to-offer
|
||||
- Demo funcional + métricas > perfección
|
||||
- Aplicar rápido > seguir aprendiendo
|
||||
- Enfoque 80/20, todo tiene timebox
|
||||
|
||||
---
|
||||
|
||||
## Reglas globales
|
||||
|
||||
### NUNCA
|
||||
|
||||
1. Inventar experiencia o métricas
|
||||
2. Modificar `cv.md` ni los archivos del portfolio
|
||||
3. Enviar candidaturas en nombre del candidato
|
||||
4. Compartir un número de teléfono en los mensajes generados
|
||||
5. Recomendar una remuneración por debajo del mercado
|
||||
6. Generar un PDF sin haber leído la oferta antes
|
||||
7. Usar jerga corporativa o fórmulas vacías
|
||||
8. Ignorar el tracker (cada oferta evaluada se registra)
|
||||
|
||||
### SIEMPRE
|
||||
|
||||
0. **Carta de presentación:** Si el formulario lo permite, SIEMPRE incluir una. PDF con el mismo diseño visual que el CV. Citas de la oferta mapeadas sobre los proof points. Máximo 1 página.
|
||||
1. Leer `cv.md` y `article-digest.md` (si existe) antes de evaluar una oferta
|
||||
1b. **Primera evaluación de cada sesión:** Ejecutar `node cv-sync-check.mjs` via Bash. Si hay alertas, avisar al candidato
|
||||
2. Detectar el arquetipo del rol y adaptar el framing
|
||||
3. Citar líneas exactas del CV en el matching
|
||||
4. Usar WebSearch para datos de remuneración y de empresa
|
||||
5. Registrar en el tracker después de cada evaluación
|
||||
6. Generar el contenido en el idioma de la oferta (español si la oferta está en español, inglés si no)
|
||||
7. Ser directo y concreto — sin relleno
|
||||
8. Español técnico natural en los textos generados. Frases cortas, verbos de acción, evitar la voz pasiva. No forzar la traducción de términos técnicos (stack, pipeline, deployment, embedding)
|
||||
8b. **URLs de case studies en el Professional Summary del PDF:** Si el PDF menciona case studies o demos, las URLs DEBEN aparecer en el primer párrafo (Professional Summary). Los reclutadores suelen leer solo el summary. Todas las URLs en HTML con `white-space: nowrap`
|
||||
9. **Entradas del tracker en TSV** — NUNCA editar applications.md directamente para nuevas entradas. Escribir el TSV en `batch/tracker-additions/`, `merge-tracker.mjs` gestiona la fusión
|
||||
10. **`**URL:**` en cada cabecera de report** — entre Score y PDF
|
||||
|
||||
### Herramientas
|
||||
|
||||
| Herramienta | Uso |
|
||||
|-------------|-----|
|
||||
| WebSearch | Búsqueda de remuneración, tendencias, cultura de empresa, contactos LinkedIn, fallback de ofertas |
|
||||
| WebFetch | Fallback para extraer ofertas desde páginas estáticas |
|
||||
| Playwright | Verificar si las ofertas están activas (browser_navigate + browser_snapshot), extraer ofertas desde SPAs. **CRÍTICO: NUNCA 2+ agentes en paralelo con Playwright — comparten la misma instancia del navegador** |
|
||||
| Read | cv.md, article-digest.md, cv-template.html |
|
||||
| Write | HTML temporal para PDF, applications.md, reports .md |
|
||||
| Edit | Actualizar el tracker |
|
||||
| Bash | `node generate-pdf.mjs` |
|
||||
@@ -0,0 +1,114 @@
|
||||
# Modo: aplicar -- Asistente en vivo para formularios de candidatura
|
||||
|
||||
Modo interactivo para el momento en que el candidato rellena un formulario de candidatura en Chrome. Lee lo que hay en pantalla, carga el contexto de la evaluación previa de la oferta y genera respuestas personalizadas para cada pregunta del formulario.
|
||||
|
||||
## Requisitos previos
|
||||
|
||||
- **Ideal con Playwright visible**: En modo visible, el candidato ve el navegador y el agente puede interactuar con la página.
|
||||
- **Sin Playwright**: el candidato comparte una captura de pantalla o pega las preguntas manualmente.
|
||||
|
||||
## Workflow
|
||||
|
||||
```
|
||||
1. DETECTAR -> Leer la pestaña activa de Chrome (captura/URL/título)
|
||||
2. IDENTIFICAR -> Extraer empresa + rol desde la página
|
||||
3. BUSCAR -> Hacer match con los reports existentes en reports/
|
||||
4. CARGAR -> Leer el report completo + Bloque G (si existe)
|
||||
5. COMPARAR -> ¿El rol en pantalla coincide con el evaluado? Si cambió -> avisar
|
||||
6. ANALIZAR -> Identificar TODAS las preguntas visibles del formulario
|
||||
7. GENERAR -> Para cada pregunta, generar una respuesta personalizada
|
||||
8. PRESENTAR -> Mostrar las respuestas formateadas para copiar y pegar
|
||||
```
|
||||
|
||||
## Paso 1 -- Detectar la oferta
|
||||
|
||||
**Con Playwright:** Snapshot de la página activa. Leer título, URL y contenido visible.
|
||||
|
||||
**Sin Playwright:** Pedir al candidato que:
|
||||
- Comparta una captura de pantalla del formulario (la herramienta Read lee imágenes)
|
||||
- O pegue las preguntas del formulario en texto
|
||||
- O indique empresa + rol para buscar el contexto
|
||||
|
||||
## Paso 2 -- Identificar y cargar el contexto
|
||||
|
||||
1. Extraer el nombre de la empresa y el título del puesto desde la página
|
||||
2. Buscar en `reports/` por nombre de empresa (Grep case-insensitive)
|
||||
3. Si hay match -> cargar el report completo
|
||||
4. Si hay Bloque G -> cargar los borradores de respuestas previos como base
|
||||
5. Si NO hay match -> avisar al candidato y proponer un auto-pipeline rápido
|
||||
|
||||
## Paso 3 -- Detectar cambios de rol
|
||||
|
||||
Si el rol en pantalla difiere del evaluado:
|
||||
- **Avisar al candidato**: "El rol ha cambiado de [X] a [Y]. ¿Quieres que reevalúe o que adapte las respuestas al nuevo título?"
|
||||
- **Si adaptar**: Ajustar las respuestas al nuevo rol sin reevaluar
|
||||
- **Si reevaluar**: Lanzar la evaluación completa A-F, actualizar el report, regenerar el Bloque G
|
||||
- **Actualizar el tracker**: Modificar el título del rol en applications.md si es necesario
|
||||
|
||||
## Paso 4 -- Analizar las preguntas del formulario
|
||||
|
||||
Identificar TODAS las preguntas visibles:
|
||||
- Campos de texto libre (carta de presentación, "¿por qué este puesto?", motivación, etc.)
|
||||
- Listas desplegables (cómo conociste la empresa, permiso de trabajo, etc.)
|
||||
- Sí/No (movilidad, visado, disponibilidad, etc.)
|
||||
- Campos de salario (horquilla, pretensiones salariales — en bruto anual)
|
||||
- Campos de subida de archivos (CV, carta de presentación en PDF, referencias)
|
||||
|
||||
Clasificar cada pregunta:
|
||||
- **Ya respondida en el Bloque G** -> retomar la respuesta existente
|
||||
- **Pregunta nueva** -> generar la respuesta desde el report + `cv.md`
|
||||
|
||||
## Paso 5 -- Generar las respuestas
|
||||
|
||||
Para cada pregunta, construir la respuesta según este esquema:
|
||||
|
||||
1. **Contexto del report**: Usar los proof points del bloque B, las stories STAR del bloque F
|
||||
2. **Bloque G previo**: Si existe un borrador, tomarlo como base y refinarlo
|
||||
3. **Tono "Te elijo a ti"**: mismo framework que en el auto-pipeline — confiado, no suplicante
|
||||
4. **Especificidad**: citar algo concreto de la oferta visible en pantalla
|
||||
5. **career-ops proof point**: incluir en "Información adicional" si existe ese campo
|
||||
|
||||
**Campos específicos en formularios hispanohablantes habituales:**
|
||||
- **Pretensiones salariales (bruto anual)** -> Horquilla desde `profile.yml`, en EUR (o divisa local), con la indicación "negociable según el paquete global"
|
||||
- **Fecha de disponibilidad** -> Fecha realista teniendo en cuenta el preaviso (habitualmente 15 días a 3 meses)
|
||||
- **Permiso de trabajo / Nacionalidad** -> Honesto y conciso; para ciudadanos UE: "Sin necesidad de permiso de trabajo (ciudadano UE)"
|
||||
- **Idiomas** -> Niveles según el MCER (A1-C2)
|
||||
- **Movilidad** -> Especificar la zona geográfica aceptable y la frecuencia de desplazamiento
|
||||
|
||||
**Formato de salida:**
|
||||
|
||||
```
|
||||
## Respuestas para [Empresa] -- [Rol]
|
||||
|
||||
Base: Report #NNN | Score: X.X/5 | Arquetipo: [tipo]
|
||||
|
||||
---
|
||||
|
||||
### 1. [Pregunta exacta del formulario]
|
||||
> [Respuesta lista para copiar y pegar]
|
||||
|
||||
### 2. [Siguiente pregunta]
|
||||
> [Respuesta]
|
||||
|
||||
...
|
||||
|
||||
---
|
||||
|
||||
Notas:
|
||||
- [Observaciones sobre el rol, cambios, etc.]
|
||||
- [Sugerencias de personalización que el candidato debería revisar]
|
||||
```
|
||||
|
||||
## Paso 6 -- Tras la candidatura (opcional)
|
||||
|
||||
Si el candidato confirma que la candidatura ha sido enviada:
|
||||
1. Actualizar el estado en `applications.md` de "Evaluated" a "Applied"
|
||||
2. Actualizar el Bloque G del report con las respuestas finales
|
||||
3. Sugerir el siguiente paso: `/career-ops contacto` para LinkedIn outreach hacia el hiring manager
|
||||
|
||||
## Gestión del desplazamiento
|
||||
|
||||
Si el formulario tiene más preguntas de las que son visibles:
|
||||
- Pedir al candidato que desplace y comparta otra captura de pantalla
|
||||
- O que pegue las preguntas restantes
|
||||
- Tratar por iteraciones hasta cubrir todo el formulario
|
||||
@@ -0,0 +1,200 @@
|
||||
# Mode: interview/debrief — Análisis Posterior a la Entrevista (Debrief)
|
||||
|
||||
Después de una entrevista real, captura qué se preguntó, evalúa qué funcionó y qué no, cubre las carencias antes de la siguiente ronda y actualiza el banco de preguntas.
|
||||
|
||||
---
|
||||
|
||||
## When to Run This Skill
|
||||
|
||||
- Inmediatamente después de una entrevista real (mientras la memoria está fresca)
|
||||
- Después de una llamada con el reclutador que haya revelado nueva información sobre el proceso
|
||||
- Cuando el candidato conozca el formato y el entrevistador de la siguiente ronda
|
||||
|
||||
---
|
||||
|
||||
## Inputs
|
||||
|
||||
1. **Análisis de la entrevista del candidato (Debrief)** — qué preguntas se hicieron, cómo respondió, qué sintió que fue sólido o débil
|
||||
2. **Nombre y rol del entrevistador** — informa la predicción de la siguiente ronda
|
||||
3. **Resultado de la ronda** (si se conoce) — avanzó / rechazado / pendiente
|
||||
4. **Detalles de la siguiente ronda** (si se conocen) — formato, entrevistadores, plazos
|
||||
5. **Banco de preguntas** en `interview-prep/question-bank.md` — actualizar con datos reales
|
||||
6. **Banco de historias** en `interview-prep/story-bank.md` — agregar nuevas historias si surgieron
|
||||
7. **CV** en `cv.md` + `article-digest.md` (si está presente) — para fundamentar las respuestas sugeridas en la experiencia real
|
||||
8. **Afirmaciones retractadas** en `interview-prep/retracted-claims.md` (si está presente) — barrera estricta (hard gate); nunca uses una afirmación retractada en una respuesta sugerida, incluso si el candidato la dijo en la entrevista
|
||||
9. **Archivo de preparación específico del rol** — para adjuntar las notas del análisis
|
||||
|
||||
---
|
||||
|
||||
## Step 1 — Capture What Was Asked
|
||||
|
||||
Pide al candidato que enumere cada pregunta que recuerde, en orden si es posible. No le sugieras opciones — deja que recuerde libremente primero.
|
||||
|
||||
Para cada pregunta capturada:
|
||||
- ¿Qué dijeron?
|
||||
- ¿Cómo reaccionó el entrevistador (señal positiva, neutral, mostró rechazo, pasó a otra cosa rápidamente)?
|
||||
- ¿Se sintieron seguros o con dudas?
|
||||
|
||||
Si la memoria está incompleta, haz preguntas dirigidas:
|
||||
- "¿Hubo alguna pregunta que te tomó por sorpresa?"
|
||||
- "¿Hubo algo que desearías haber respondido de otra manera?"
|
||||
- "¿El entrevistador hizo preguntas de seguimiento (follow-up) sobre algo? — eso generalmente significa que querían más."
|
||||
|
||||
---
|
||||
|
||||
## Step 2 — Honest Assessment Per Question
|
||||
|
||||
Para cada pregunta, produce:
|
||||
|
||||
```markdown
|
||||
**Q: [pregunta]**
|
||||
- What was said: [resumen de su respuesta]
|
||||
- What landed: [qué fue bueno — sé específico]
|
||||
- What was missing: [carencia — término técnico preciso, resultado faltante, sin reflexión, etc.]
|
||||
- Correct/complete answer: [lo que la respuesta completa debería incluir]
|
||||
- Status: ✅ Strong / 🟡 Solid / 🔴 Gap
|
||||
```
|
||||
|
||||
Sé directo. Si perdieron el concepto central que la pregunta estaba evaluando, dilo. Si una respuesta fue genuinamente sólida, dilo también. El análisis es el momento de aprendizaje más valioso — la vaguedad lo desperdicia.
|
||||
|
||||
---
|
||||
|
||||
## Step 3 — Update Question Bank
|
||||
|
||||
Para cada pregunta analizada, actualiza `interview-prep/question-bank.md`:
|
||||
- Cambia el estado a ✅ / 🟡 / 🔴 según el rendimiento real
|
||||
- Agrega notas de carencias del análisis
|
||||
- Agrega cualquier nueva pregunta que haya aparecido y que aún no estuviera en el banco
|
||||
|
||||
Si el banco de preguntas no existe, créalo con las preguntas de esta entrevista como semilla.
|
||||
|
||||
---
|
||||
|
||||
## Step 4 — Close the Gaps
|
||||
|
||||
Para cada 🔴 carencia identificada:
|
||||
|
||||
1. **Explica la respuesta correcta** — clara, concisa, con un ejemplo desarrollado (código, cálculo, diagrama) si es útil
|
||||
2. **Conecta con una historia real** si es posible — "realmente tienes esto en tu [historia existente del banco de historias] — aquí te muestro cómo usarlo"
|
||||
3. **Agrega al archivo de preparación del rol** bajo una sección "Gaps to Close Before Round N"
|
||||
4. **Agrega a `interview-prep/interview-prep-guide.md`** (si el candidato mantiene uno) cuando sea un principio reutilizable que se aplique más allá de este rol
|
||||
|
||||
---
|
||||
|
||||
## Step 5 — Extract New Stories
|
||||
|
||||
A veces, una entrevista real saca a relucir una historia que el candidato no había preparado. Si el candidato describió una experiencia que no había formalizado:
|
||||
|
||||
> "Mencionaste [X] en tu respuesta — parece que podría convertirse en una historia STAR+R adecuada. ¿Quieres desarrollarla ahora que está fresca?"
|
||||
|
||||
Si dice que sí, desarróllala como una historia STAR+R (Situación, Tarea, Acción, Resultado, Reflexión) y agrégala a `interview-prep/story-bank.md`.
|
||||
|
||||
---
|
||||
|
||||
## Step 6 — Next Round Intelligence
|
||||
|
||||
Si el candidato conoce el formato de la próxima ronda:
|
||||
|
||||
1. **Predice posibles preguntas** basándote en:
|
||||
- El rol del próximo entrevistador (ej., practitioner senior → profundidad en la habilidad central, diseño; colega interfuncional → colaboración, límites del dominio; ejecutivo → estrategia, impacto en el negocio)
|
||||
- Lo que se cubrió en esta ronda (la próxima ronda suele profundizar, no abarcar más)
|
||||
- En lo que el entrevistador de esta ronda pareció más interesado
|
||||
|
||||
Etiqueta cada predicción con `[inferred]` — nunca presentes una pregunta predicha como si se hubiera obtenido de candidatos reales o expertos internos.
|
||||
|
||||
2. **Construye una lista de prioridades** para la preparación de la próxima ronda — ordenada por gravedad de la carencia y probabilidad de ser evaluada
|
||||
|
||||
3. **Sugiere ejecutar** `interview/plan` con los detalles de la próxima ronda para crear un plan de preparación completo
|
||||
|
||||
---
|
||||
|
||||
## Step 7 — Probability Assessment (Optional)
|
||||
|
||||
Si el candidato pide una lectura honesta sobre sus posibilidades:
|
||||
|
||||
Evalúa en base a:
|
||||
- Número y gravedad de las carencias (🔴 en fundamentos = mayor riesgo que 🔴 en temas avanzados)
|
||||
- Señales del entrevistador (dio detalles específicos de la siguiente ronda = positivo; vago = neutral; llamada corta = riesgo)
|
||||
- Ajuste al rol (años de experiencia, coincidencia de dominio, ubicación)
|
||||
- Diferenciadores (cosas que dijo el candidato que la mayoría de los candidatos no dirían)
|
||||
|
||||
Sé honesto. Un rango de probabilidad con un razonamiento claro es más útil que la falsa confianza.
|
||||
|
||||
---
|
||||
|
||||
## Step 8 — Save Debrief
|
||||
|
||||
Agrega a `interview-prep/{company-slug}-{role-slug}.md`:
|
||||
|
||||
```markdown
|
||||
## Round [N] Debrief — [YYYY-MM-DD]
|
||||
|
||||
**Interviewer:** [nombre, rol]
|
||||
**Round type:** [screening / technical / design-case-study / behavioral]
|
||||
**Outcome:** [pending / moved forward / rejected]
|
||||
|
||||
### Questions Asked
|
||||
[lista]
|
||||
|
||||
### Gaps Identified
|
||||
[lista con las respuestas correctas]
|
||||
|
||||
### Next Round
|
||||
**Format:** [si se conoce]
|
||||
**Interviewers:** [si se conocen]
|
||||
**Priority prep:** [los 3 temas principales a cubrir antes de la siguiente ronda]
|
||||
|
||||
### Process Intel (recruiter / HM screens — omit if not applicable)
|
||||
**Comp discussed:** [sí / no — si es sí, qué se dijo y en qué se ancló]
|
||||
**Timeline:** [cualquier fecha o plazo mencionado]
|
||||
**Other candidates:** [si se revelaron]
|
||||
**Next steps:** [lo que el entrevistador dijo que sucede a continuación y para cuándo]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Step 9 — Write Session Transcript
|
||||
|
||||
Después del análisis, escribe también una transcripción de la sesión legible por máquina en `interview-prep/sessions/{company-slug}-{role-slug}-{round}-{YYYY-MM-DD}.md`. Este es un registro estructurado de la ronda para modos de análisis posteriores; los turnos etiquetados por hablante permiten a un consumidor leer cualquier lado sin tener que volver a inferir quién habló. El contrato completo vive en `interview-prep/sessions/README.md`.
|
||||
|
||||
Formato:
|
||||
|
||||
```markdown
|
||||
---
|
||||
company: [empresa]
|
||||
role: [rol]
|
||||
round: [screen | hiring-manager | technical | system-design | behavioral | onsite | final]
|
||||
date: YYYY-MM-DD
|
||||
interviewer_role: [rol, si se conoce]
|
||||
source: debrief
|
||||
---
|
||||
|
||||
## Q1
|
||||
**Interviewer:** [pregunta tal como se hizo]
|
||||
<!-- competency: tag[, tag...] -->
|
||||
**Candidate:** [respuesta tal como se entregó / reconstruida en este análisis]
|
||||
|
||||
## Q2
|
||||
...
|
||||
```
|
||||
|
||||
Reglas para la transcripción:
|
||||
|
||||
- **Asigna el tipo de ronda al enum** anterior (ej. filtro del reclutador → `screen`, filtro del HM → `hiring-manager`, inmersión técnica → `technical`, diseño/estudio de caso → `system-design`).
|
||||
- **Etiqueta cada respuesta.** En la línea directamente arriba de cada línea `**Candidate:**`, emite `<!-- competency: tag[, tag...] -->` — en minúsculas (lowercase-kebab-case), separado por comas para respuestas con múltiples competencias (ej. `system-design`, `people-leadership`, `incident-response`). Ya evaluaste cada respuesta en el Step 2, así que etiqueta a partir de esa evaluación en lugar de volver a leer. Las etiquetas son de formato libre; elige la competencia que la pregunta realmente evaluó.
|
||||
- **Reconstruye el turno del candidato fielmente.** Usa lo que el candidato informó haber dicho en el Step 1, no una respuesta idealizada. La "respuesta correcta/completa" del Step 2 pertenece al archivo de análisis, nunca a la transcripción — la transcripción registra lo que sucedió.
|
||||
- **`source: debrief`.**
|
||||
- El archivo de sesión aterriza en un directorio ignorado por git (los nombres/empresas reales nunca entran en el control de versiones); escríbelo sin censurar.
|
||||
|
||||
---
|
||||
|
||||
## Rules
|
||||
|
||||
- **Analiza inmediatamente.** La memoria de los detalles de la entrevista se degrada rápidamente — en cuestión de horas, las preguntas y reacciones específicas se olvidan. Ejecuta esta habilidad el mismo día.
|
||||
- **No suavices las carencias.** Una carencia 🔴 que se llama 🟡 por amabilidad volverá a aparecer en la siguiente ronda.
|
||||
- **Nunca pongas afirmaciones inventadas en boca del candidato.** Las respuestas correctas/completas pueden basarse en el conocimiento general del dominio, pero cualquier afirmación personal o métrica sugerida debe provenir de lo que dijo el candidato, `cv.md`, `article-digest.md` o el banco de historias.
|
||||
- **Las afirmaciones retractadas son una barrera estricta.** Si una afirmación aparece en `interview-prep/retracted-claims.md`, nunca sugieras que el candidato la use — incluso si la dijo en la entrevista real. Márcala: "Esa afirmación está en tu lista de retractadas — no es defendible bajo presión. Aquí tienes una versión que no depende de ella."
|
||||
- **Registra nuevas retractaciones.** Si el análisis revela una afirmación que el candidato usó en la entrevista real y que ahora acepta que no es defendible, ofrece agregarla a `interview-prep/retracted-claims.md`: `**"[afirmación]"** ([contexto]). Razón: [razón de una línea + encuadre correcto si aplica].`
|
||||
- **Extrae las carencias de vocabulario de forma explícita.** Si el candidato usó un término impreciso donde existe uno preciso, agrégalo a `interview-prep/interview-prep-guide.md` en la sección de vocabulario (si el candidato mantiene uno).
|
||||
- **Una carencia = una solución.** No abrumes con un plan de estudio completo para cada carencia. Prioriza las 1 o 2 con mayor probabilidad de ser evaluadas en la siguiente ronda.
|
||||
- **Celebra lo que funcionó.** El análisis no se trata solo de carencias. Nombra lo que fue sólido — refuerza el comportamiento correcto y construye confianza para la próxima ronda.
|
||||
@@ -0,0 +1,157 @@
|
||||
# Mode: interview/plan — Planificador de Preparación para Entrevistas
|
||||
|
||||
Dada una descripción de puesto (JD) y la fecha/hora de la entrevista, construye un plan de preparación estructurado y con bloques de tiempo, adaptado a las carencias específicas del candidato.
|
||||
|
||||
---
|
||||
|
||||
## Inputs
|
||||
|
||||
1. **Descripción del puesto (JD)** (requerido) — pégalo en línea o proporciona la URL
|
||||
2. **Fecha y hora de la entrevista** (requerido) — para calcular las horas disponibles
|
||||
3. **Nombre y rol del entrevistador** (si se conoce) — determina la profundidad y el tono de la preparación
|
||||
4. **Tipo de ronda** (si se conoce) — filtro (screening), técnico/específico del dominio, diseño/estudio de caso, panel conductual (behavioral)
|
||||
5. **CV** en `cv.md` + `article-digest.md` (si está presente) — lee para obtener experiencia, habilidades y puntos de prueba
|
||||
6. **Perfil** en `config/profile.yml` + `modes/_profile.md` — lee para la narrativa, arquetipos y objetivos
|
||||
7. **Banco de historias** en `interview-prep/story-bank.md` — historias STAR+R existentes
|
||||
8. **Banco de preguntas** en `interview-prep/question-bank.md` — carencias existentes (si el archivo existe)
|
||||
|
||||
---
|
||||
|
||||
## Step 1 — Evaluación de Ajuste
|
||||
|
||||
Lee el CV y la JD. Produce una evaluación de dos columnas:
|
||||
|
||||
**Fortalezas en las que anclarse:** experiencia, títulos, dominio, puntos de prueba que coincidan directamente con la JD.
|
||||
|
||||
**Carencias a cubrir:** habilidades, herramientas o experiencia mencionadas en la JD que estén ausentes o sean débiles en el CV. Clasifícalas por la probabilidad de ser evaluadas en este tipo de ronda específica.
|
||||
|
||||
Sé honesto. Una carencia es una carencia — márcala claramente para que el tiempo de preparación se dedique a los lugares correctos.
|
||||
|
||||
---
|
||||
|
||||
## Step 2 — Inteligencia de la Ronda
|
||||
|
||||
Identifica qué está evaluando realmente esta ronda basándote en:
|
||||
|
||||
- Rol del entrevistador (manager = comunicación + pasión + fundamentos; practitioner = profundidad + criterio)
|
||||
- Etiqueta de la ronda (filtro, técnico/dominio, diseño/caso de estudio, final)
|
||||
- Señales de la JD (qué enfatizan)
|
||||
|
||||
**Filtro del reclutador (Recruiter screen):**
|
||||
|
||||
- Verificación de requisitos: ajuste, alineación de compensación, logística, comunicación
|
||||
- No es una prueba técnica — las preguntas de profundidad vienen en las rondas con el HM (Hiring Manager) y posteriores
|
||||
- Probable: presentación de background, "por qué nosotros/por qué este rol", expectativa salarial, plazos, una pregunta de logística
|
||||
- Trata esto como el punto de control fácil; usa el tiempo de preparación para construir la base de lo que viene después
|
||||
|
||||
**Filtro del Hiring Manager:**
|
||||
|
||||
- Comunicación, pasión, ajuste — además de filosofía de liderazgo y criterio
|
||||
- Fundamentos de la habilidad central de la JD — no aspectos internos profundos
|
||||
- 1–2 historias conductuales
|
||||
- Probable: background, "por qué nosotros", un concepto central de la JD, una historia de liderazgo, pregunta situacional con visión de futuro
|
||||
|
||||
**Inmersión técnica / de dominio con un practitioner:**
|
||||
|
||||
- Profundidad en la habilidad central de la JD (ej. internals del runtime para ingeniería, opciones de modelado para datos, métodos de valoración para finanzas)
|
||||
- Escenarios aplicados del día a día del rol
|
||||
- Es posible un ejercicio en vivo o un recorrido guiado
|
||||
- Las historias se usan como evidencia, no como el evento principal
|
||||
|
||||
**Panel de diseño / caso de estudio:**
|
||||
|
||||
- Solución completa — restricciones, componentes, compensaciones (trade-offs), modos de fallo
|
||||
- Las dimensiones de calidad que enfatiza la JD (ej. escalabilidad, cumplimiento, medibilidad)
|
||||
- Nivel senior: establecer restricciones, hacer preguntas aclaratorias, dirigir la conversación
|
||||
|
||||
Calibra el plan según la ronda. Prepararse en exceso para un filtro desperdicia tiempo y crea la mentalidad equivocada.
|
||||
|
||||
---
|
||||
|
||||
## Step 3 — Construir el Plan de Bloques de Tiempo
|
||||
|
||||
Calcula las horas disponibles desde ahora hasta la hora de la entrevista. Divide en bloques:
|
||||
|
||||
Antes de dimensionar los bloques, revisa `interview-prep/question-bank.md` (si existe). Cualquier pregunta marcada con 🔴 de una ronda anterior es una carencia comprobada — obtiene un bloque dedicado independientemente de cómo la clasifique el análisis CV-vs-JD. Los datos de rendimiento reales superan al riesgo inferido.
|
||||
|
||||
**Plantilla (ajusta el tamaño de los bloques según el total de horas disponibles):**
|
||||
|
||||
```text
|
||||
Block 1 — Fija tu narrativa (primero, siempre)
|
||||
- Escribe la cronología de tu background explícitamente
|
||||
- Prepara "por qué esta empresa" con una conexión específica a tu historia
|
||||
- Prepara la historia de tu punto de prueba más fuerte (versión de 30 segundos)
|
||||
- Tiempo: ~15% de las horas disponibles
|
||||
|
||||
Block 2 — Tema de dominio prioritario (carencia de mayor riesgo primero)
|
||||
- Un tema por bloque — no mezclar
|
||||
- Para cada uno: concepto → gancho de tu historia → posibles preguntas de seguimiento
|
||||
- Tiempo: ~25% de las horas disponibles
|
||||
|
||||
Block 3 — Tema de dominio secundario
|
||||
- Segunda carencia de mayor riesgo
|
||||
- Tiempo: ~20% de las horas disponibles
|
||||
|
||||
Block 4 — Historias conductuales
|
||||
- Asigna las historias existentes a los tipos de preguntas probables
|
||||
- Practica la versión verbal de 2 minutos de cada una
|
||||
- Prepara la Reflexión para cada una — el diferenciador de un candidato senior
|
||||
- Tiempo: ~15% de las horas disponibles
|
||||
|
||||
Block 5 — Investigación de la empresa
|
||||
- Páginas de productos relevantes para el rol
|
||||
- Conexión entre tu historia y su dominio específico
|
||||
- 3–4 preguntas agudas para hacerles
|
||||
- Tiempo: ~10% de las horas disponibles
|
||||
|
||||
Block 6 — Ensayo práctico (si el tiempo lo permite)
|
||||
- Una pregunta por tema probable — en voz alta, cronometrada
|
||||
- Tiempo: ~10% de las horas disponibles
|
||||
|
||||
Block 7 — Búfer + descanso
|
||||
- Deja de estudiar 60–90 minutos antes de la entrevista
|
||||
- Estudiar de más en la última hora añade ruido, no señal
|
||||
- Tiempo: el restante
|
||||
```
|
||||
|
||||
Ajusta el tamaño de los bloques según la gravedad de la carencia y el tipo de ronda. Si es un filtro, el Block 4 (conductual) y el Block 5 (investigación) son más importantes que los bloques de dominio profundo.
|
||||
|
||||
---
|
||||
|
||||
## Step 4 — Referencia Rápida de Prioridad
|
||||
|
||||
Al final del plan, produce una referencia rápida de una página que el candidato pueda leer 15 minutos antes de la entrevista:
|
||||
|
||||
```markdown
|
||||
## 15-Minute Pre-Interview Review
|
||||
|
||||
**Your anchor sentence:** [una frase que capture por qué eres adecuado para este rol]
|
||||
|
||||
**Top 3 things to remember:**
|
||||
1. [el mensaje más importante a dejarle al entrevistador]
|
||||
2. [la pregunta más probable y tu primera frase de la respuesta]
|
||||
3. [la conexión entre tu historia y su dominio]
|
||||
|
||||
**Your questions to ask:**
|
||||
1. [pregunta 1]
|
||||
2. [pregunta 2]
|
||||
3. [pregunta 3]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Step 5 — Guardar Resultados
|
||||
|
||||
Guarda el plan en `interview-prep/{company-slug}-{role-slug}.md` si el archivo no existe, o añade una sección `## Prep Plan` si ya existe.
|
||||
|
||||
---
|
||||
|
||||
## Rules
|
||||
|
||||
- **Calibra según la ronda.** Un plan de preparación para un filtro se ve muy diferente a uno para un panel de diseño. No apliques profundidad máxima por defecto para todas las entrevistas.
|
||||
- **Las carencias primero.** El tiempo es finito. Las fortalezas del candidato no necesitan preparación — sus carencias sí.
|
||||
- **Las carencias marcadas con 🔴 en el banco de preguntas tienen prioridad sobre las carencias inferidas.** Los datos de rendimiento reales superan el análisis CV-vs-JD. Si el candidato ya sabe que le cuesta un tema, no lo ocultes.
|
||||
- **Un tema por bloque.** Mezclar temas en un solo bloque reduce la retención.
|
||||
- **Siempre incluye tiempo de descanso.** Un candidato descansado supera a uno que ha estudiado de más en el último momento.
|
||||
- **Nunca inventes información sobre la empresa.** Si no tienes investigación, dilo — no inventes afirmaciones sobre la cultura o detalles técnicos sobre la empresa.
|
||||
- **Nunca inventes afirmaciones para el candidato.** La frase ancla y los puntos de conversación previos a la entrevista en la referencia rápida (Step 4) deben estar basados en lo que el candidato realmente tiene — `cv.md`, `article-digest.md` o el banco de historias. No redactes afirmaciones que dependan de experiencia o métricas que el candidato no tiene. Si una afirmación aparece en `interview-prep/retracted-claims.md`, nunca la incluyas.
|
||||
@@ -0,0 +1,255 @@
|
||||
# Mode: interview/practice — Entrevistador de Práctica
|
||||
|
||||
Ejecuta una entrevista de práctica realista — una pregunta a la vez — y da comentarios estructurados después de cada respuesta. Realiza un seguimiento de lo que funcionó y lo que necesita mejorar.
|
||||
|
||||
---
|
||||
|
||||
## Inputs
|
||||
|
||||
1. **Tipo de ronda** (requerido) — filtro/reclutador (screening/recruiter), filtro/HM (screening/HM), técnico/específico del dominio, diseño/estudio de caso, conductual (behavioral)
|
||||
2. **Persona del entrevistador** (si se conoce) — nombre, rol, empresa; determina el estilo y profundidad de las preguntas
|
||||
3. **Lista de preguntas** (opcional) — preguntas específicas a cubrir; si no se proporcionan, generarlas a partir del tipo de ronda
|
||||
4. **CV** en `cv.md` + `article-digest.md` (si está presente) — para verificar las afirmaciones en las respuestas y fundamentar versiones más sólidas en la experiencia real
|
||||
5. **Perfil** en `config/profile.yml` + `modes/_profile.md` — narrativa del candidato, factores decisivos (deal-breakers), objetivos de compensación
|
||||
6. **Banco de historias** en `interview-prep/story-bank.md` — para verificar la precisión de la historia en los comentarios
|
||||
7. **Banco de preguntas** en `interview-prep/question-bank.md` — para actualizar el estado después de cada respuesta
|
||||
8. **Archivo de preparación específico del rol** — para inteligencia de la empresa, preguntas obtenidas, estrategia de compensación
|
||||
9. **Afirmaciones retractadas** en `interview-prep/retracted-claims.md` (si está presente) — afirmaciones que el candidato ha rechazado explícitamente como indefendibles; trátalo como una barrera estricta (hard gate)
|
||||
|
||||
---
|
||||
|
||||
## Protocol
|
||||
|
||||
### Preflight — Check Substance Files
|
||||
|
||||
Antes de establecer la escena, confirma qué archivos existen:
|
||||
|
||||
- `interview-prep/question-bank.md` (o un equivalente específico de la empresa)
|
||||
- El archivo de preparación específico del rol (`interview-prep/{company}-{role}.md`)
|
||||
- `cv.md`
|
||||
- `interview-prep/retracted-claims.md`
|
||||
|
||||
Si el banco de preguntas y el archivo de preparación del rol están ausentes, dile al candidato claramente:
|
||||
|
||||
> "Tienes el protocolo de práctica pero no tu banco de preguntas ni notas de preparación para este rol. Los comentarios serán genéricos hasta que estos existan. ¿Quieres ejecutar `interview-prep` o `interview/plan` primero para construirlos?"
|
||||
|
||||
No ejecutes silenciosamente una sesión superficial como si fuera completa. Si el candidato confirma que desea proceder de todos modos, continúa — pero anota en el resumen de la sesión que la obtención de preguntas recurrió a los valores predeterminados generados.
|
||||
|
||||
---
|
||||
|
||||
### Opening
|
||||
|
||||
Establece la escena brevemente:
|
||||
|
||||
> "Seré [nombre/rol del entrevistador]. Iremos una pregunta a la vez. Responde como lo harías en la entrevista real — en voz alta si es posible, escrito si no. Después de cada respuesta te daré retroalimentación (feedback), y luego pasaremos a la siguiente. Di 'pausa' si quieres detenerte a discutir antes de que te dé retroalimentación. ¿Listo?"
|
||||
|
||||
Luego, abre con la primera pregunta — sin preámbulos, sin "aquí está la pregunta 1". Simplemente hazla con naturalidad como lo haría el entrevistador.
|
||||
|
||||
---
|
||||
|
||||
### During the Session
|
||||
|
||||
**Haz una pregunta a la vez.** Espera la respuesta completa antes de dar retroalimentación.
|
||||
|
||||
**Mantente en el personaje** durante la respuesta. Si el candidato hace una pregunta aclaratoria a mitad de respuesta ("¿tiene sentido eso?"), responde como lo haría el entrevistador — brevemente, sin romper la escena.
|
||||
|
||||
**Preguntas de seguimiento (Follow-up):** después de una respuesta completa, haz una pregunta de seguimiento natural si:
|
||||
|
||||
- La respuesta fue incompleta pero iba por buen camino (tira del hilo)
|
||||
- La respuesta fue fuerte (profundiza — esto es lo que hacen los entrevistadores reales)
|
||||
- La respuesta perdió el punto clave por completo (dales la oportunidad de recuperarse)
|
||||
|
||||
**Haz un seguimiento de lo cubierto.** Mantén una lista mental continua de qué historias y ejemplos ha usado el candidato. Si recurren a la misma historia por segunda vez, márcalo después del feedback: "Has usado [historia] para [N] preguntas ya — los entrevistadores notan un conjunto de ejemplos limitado. ¿Qué ejemplo diferente podrías usar aquí?". También verifica el *cierre* de cada respuesta: si termina en un dominio que no coincide con el rol (ej. cerrar en e-commerce cuando el rol es fintech/fraude), anótalo: "Contenido fuerte, pero cerraste en [dominio incorrecto] — para este rol, enfoca la respuesta en [dominio correcto]."
|
||||
|
||||
---
|
||||
|
||||
### After Each Answer — Structured Feedback
|
||||
|
||||
```markdown
|
||||
**What landed:**
|
||||
- [cosa específica que funcionó — cita sus palabras si es posible]
|
||||
- [otra fortaleza]
|
||||
|
||||
**What to sharpen:**
|
||||
- [carencia específica — qué faltó o fue impreciso]
|
||||
- [vocabulario o encuadre a mejorar]
|
||||
|
||||
**The stronger version:**
|
||||
> "[Una o dos oraciones mostrando cómo la respuesta podría haber comenzado o cerrado más efectivamente]"
|
||||
|
||||
**Status update:** [✅ Strong / 🟡 Solid / 🔴 Gap]
|
||||
```
|
||||
|
||||
Mantén la retroalimentación concisa. Una o dos cosas a mejorar por respuesta — no una reescritura completa. El objetivo es mejorar en el siguiente intento, no desanimar.
|
||||
|
||||
---
|
||||
|
||||
### Feedback Principles
|
||||
|
||||
**Sé honesto, no solo alentador.** Un "Buena respuesta" sin sustancia desperdicia el tiempo de preparación del candidato. Si una respuesta fue débil, dilo claramente y explica por qué.
|
||||
|
||||
**Cita sus palabras exactas.** "Dijiste 'negociar entre consistencia y disponibilidad' — el término preciso es 'hacer un trade-off (compensar) consistencia por disponibilidad'" es más útil que "usa un mejor vocabulario técnico".
|
||||
|
||||
**Lidera con lo que funcionó.** Incluso una respuesta débil generalmente tiene algo correcto. Nombrarlo primero hace que la corrección sea mejor recibida.
|
||||
|
||||
**Marca explícitamente las carencias de vocabulario.** Los entrevistadores expertos notan el lenguaje impreciso. Cuando el candidato usa un término vago donde existe uno preciso, nómbralo.
|
||||
|
||||
**La comprobación de Reflexión.** Para las historias conductuales, siempre verifica: ¿incluyeron una Reflexión? ("Qué haría diferente / qué aprendí.") Esta es la señal de un candidato senior. Si falta, pregunta una vez después del feedback: "¿Qué harías diferente sabiendo lo que sabes ahora?"
|
||||
|
||||
**Regla de los dos minutos.** Si una respuesta dura más de dos minutos, anótalo. Los entrevistadores dejan de escuchar. La solución casi siempre es indicar la respuesta primero, y luego explicar — no cortar contenido. *En una sesión escrita no puedes cronometrar la entrega — sustituye esto por una comprobación de estructura:* marca las respuestas que entierran el titular (más de 4-5 oraciones de configuración antes de llegar al punto) y dile al candidato: el ritmo y las palabras de relleno solo se pueden diagnosticar en voz alta — grábate o ejecuta esta pregunta nuevamente de forma verbal.
|
||||
|
||||
**Verifica las afirmaciones sospechosas antes de asesorar sobre ellas.** Cuando el candidato indica una métrica específica o una afirmación de alcance (personal a cargo, AUM, cifra de ingresos, porcentaje de mejora) que no puedes confirmar en el contexto previo, compárala con `cv.md`, `article-digest.md` y `interview-prep/retracted-claims.md` antes de dar feedback. Si la afirmación no está respaldada, márcala: "No puedo encontrar ese número en tu CV — ¿es defendible si presionan? Si no, aquí tienes una versión que no depende de él". Nunca aconsejes a un candidato que repita una afirmación que no puede respaldar.
|
||||
|
||||
**Nunca inventes experiencia o métricas.** La versión más sólida solo puede usar hechos que el candidato indicó realmente, o afirmaciones que existen en `cv.md`, `article-digest.md` o el banco de historias. Ajustar el encuadre es tu trabajo — agregar logros es inventar. Si una afirmación aparece en `interview-prep/retracted-claims.md`, no la uses en una versión más sólida, incluso si el candidato lo dijo.
|
||||
|
||||
**Ofrece registrar retractaciones.** Cuando un candidato concede a mitad de sesión que una afirmación no es defendible bajo presión ("tienes razón, no puedo respaldar eso"), ofrece agregarla a `interview-prep/retracted-claims.md`: "¿Quieres que agregue eso a tu lista de afirmaciones retractadas para que no vuelva a surgir?". Si responde que sí, agrega: `**"[afirmación]"** ([contexto]). Razón: [razón de una línea + encuadre correcto si aplica].`
|
||||
|
||||
**Cuando la inteligencia de la empresa sea escasa a mitad de sesión.** Si al candidato le cuesta visiblemente una pregunta sobre "por qué esta empresa / por qué este rol" porque el archivo de preparación del rol carece de información, no inventes ni te quedes en silencio. Sal del personaje, ejecuta el paso de investigación `interview-prep` para esa única pregunta (la misma ruta de investigación referenciada que posee `interview-prep.md`), y vuelve con 2-3 ángulos concretos y citados. Luego retoma el personaje. Si la investigación no produce nada útil, dilo claramente. Esto no es un segundo ciclo de búsqueda — es invocar la etapa de investigación existente justo a tiempo cuando la ruta principal no se ejecutó primero.
|
||||
|
||||
**Cuando el candidato disputa una afirmación factual en los materiales de preparación.** Si el candidato cuestiona un hecho específico en el banco de preguntas o en el archivo de preparación (ej., una métrica, una especificación de producto, una cifra SLA), no defiendas la autoridad del archivo. Sal del personaje, verifica la afirmación en fuentes primarias, y corrige el archivo fuente si el candidato tiene razón. Regresa con la cifra verificada y reanuda. Si no se puede encontrar ninguna fuente primaria, dilo y marca la afirmación como no verificada — el candidato no debería usar un hecho inverificable en una entrevista real.
|
||||
|
||||
---
|
||||
|
||||
### After All Questions — Session Summary
|
||||
|
||||
```markdown
|
||||
## Practice Session Summary
|
||||
|
||||
**Round type:** [screening / technical / design-case-study / behavioral]
|
||||
**Questions covered:** [N]
|
||||
|
||||
**Ready:**
|
||||
- [pregunta] — [nota de una línea de por qué es sólida]
|
||||
|
||||
**Needs work before interview:**
|
||||
- [pregunta] — [carencia específica a cubrir]
|
||||
|
||||
**Vocabulary to fix:**
|
||||
- "[lo que dijeron]" → "[término correcto]"
|
||||
|
||||
**Overall read:** [una oración honesta sobre la preparación para la entrevista]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Write Session Transcript
|
||||
|
||||
Después del resumen, escribe una transcripción de la sesión legible por máquina en `interview-prep/sessions/{company-slug}-{role-slug}-{round}-{YYYY-MM-DD}.md` (usa `practice` para el slug de empresa/rol si no fue una sesión específica de empresa). Este es un registro estructurado de la ronda para modos de análisis posteriores; los turnos etiquetados por hablante permiten a un consumidor leer cualquier lado sin volver a inferir quién habló. El contrato completo vive en `interview-prep/sessions/README.md`.
|
||||
|
||||
Formato:
|
||||
|
||||
```markdown
|
||||
---
|
||||
company: [empresa, o "practice"]
|
||||
role: [rol]
|
||||
round: [screen | hiring-manager | technical | system-design | behavioral | onsite | final]
|
||||
date: YYYY-MM-DD
|
||||
interviewer_role: [rol de la persona, si se estableció]
|
||||
source: practice
|
||||
---
|
||||
|
||||
## Q1
|
||||
**Interviewer:** [la pregunta que hiciste]
|
||||
<!-- competency: tag[, tag...] -->
|
||||
**Candidate:** [la respuesta del candidato, textualmente]
|
||||
|
||||
## Q2
|
||||
...
|
||||
```
|
||||
|
||||
Reglas para la transcripción:
|
||||
|
||||
- **Asigna el tipo de ronda al enum** anterior (filtro del reclutador → `screen`, filtro del HM → `hiring-manager`, técnico/dominio → `technical`, diseño/estudio de caso → `system-design`, conductual → `behavioral`).
|
||||
- **Etiqueta cada respuesta.** En la línea directamente arriba de cada línea `**Candidate:**`, emite `<!-- competency: tag[, tag...] -->` — en minúsculas (lowercase-kebab-case), separado por comas para respuestas con múltiples competencias. Ya evaluaste cada respuesta durante la sesión, así que etiqueta a partir de eso. Las etiquetas son de formato libre; elige la competencia que la pregunta realmente evaluó.
|
||||
- **Registra la respuesta del candidato textualmente**, no la "versión más sólida" — la transcripción registra lo que sucedió, no el coaching.
|
||||
- **`source: practice`.**
|
||||
- El archivo de sesión aterriza en un directorio ignorado por git (los nombres/empresas reales nunca entran en el control de versiones); escríbelo sin censurar.
|
||||
|
||||
---
|
||||
|
||||
## Question Sets by Round Type
|
||||
|
||||
Si no se proporciona una lista de preguntas, obtén las preguntas en este orden de precedencia:
|
||||
|
||||
1. **Preguntas reales de `interview-prep/question-bank.md`** — preguntas que esta empresa (o en una ronda anterior) realmente hizo, capturadas por resúmenes (debriefs). Mayor valor: fundamentado empíricamente.
|
||||
2. **Preguntas obtenidas del archivo de preparación del rol** — preguntas que la investigación de interview-prep.md encontró y citó. Úsalas tal como están escritas; mantén sus citas fuera de la sesión pero respeta su redacción.
|
||||
3. **Los conjuntos predeterminados a continuación** — fallback generado para una primera sesión sin investigación aún. Llena los espacios entre corchetes con información de la JD.
|
||||
|
||||
Mezcla niveles cuando los niveles superiores sean escasos — ej., 3 preguntas reales del banco rellenadas con predeterminadas — pero nunca omitas un nivel superior que tenga preguntas relevantes para este tipo de ronda.
|
||||
|
||||
### Screening — Recruiter (20–30 min)
|
||||
|
||||
Un filtro de reclutador es una verificación de requisitos (box-checking), no una prueba de profundidad. Mantén las respuestas precisas; no las compliques demasiado. El reclutador está verificando el ajuste, la alineación de la compensación y la logística antes de pasarlo al Hiring Manager.
|
||||
|
||||
1. Háblame de tu trayectoria (background).
|
||||
2. ¿Por qué esta empresa / por qué este rol?
|
||||
3. ¿Por qué dejas tu rol actual?
|
||||
4. ¿Cuáles son tus expectativas salariales?
|
||||
5. [Logística: ubicación / híbrido / plazos / autorización de trabajo]
|
||||
6. ¿Qué preguntas tienes para nosotros?
|
||||
|
||||
**Coaching de compensación (solo filtro de reclutador).** Presta atención si el candidato menciona un salario mínimo (floor) de forma voluntaria (ej., "lo mínimo a lo que puedo bajar es X"). Si lo hacen, márcalo después de la respuesta: "Acabas de darles tu límite inferior — eso limita tu negociación antes de que comience. La jugada más fuerte es anclarte en un objetivo investigado y diferir al paquete completo: 'Estoy apuntando a la mitad superior del rango de mercado para este nivel — me gustaría entender el salario base, el bono y el equity juntos antes de fijar un número'". Si el archivo de preparación del rol define una estrategia de compensación, sigue esa; de lo contrario, dale solo esta nota genérica de mecánica — nunca inventes números objetivo.
|
||||
|
||||
### Screening — Hiring Manager (30–45 min)
|
||||
|
||||
Un filtro de HM sondea la filosofía de liderazgo, el criterio y la profundidad de la experiencia. Las respuestas pueden ser más largas y tener más peso narrativo. El HM está decidiendo si invertir rondas de tiempo de su equipo.
|
||||
|
||||
1. Háblame de tu trayectoria.
|
||||
2. ¿Por qué esta empresa / por qué este rol?
|
||||
3. Háblame del problema más difícil que has resuelto en tu campo.
|
||||
4. Háblame de una vez que enfrentaste resistencia a un cambio que propusiste.
|
||||
5. ¿Qué significa para ti ser [título de la JD]?
|
||||
6. ¿Cómo describirías tu enfoque hacia tu profesión (craft)?
|
||||
7. [Un concepto fundamental de la JD — ej., un método central, marco de trabajo, regulación o herramienta de la disciplina]
|
||||
|
||||
Mezcla al menos 2 preguntas situacionales / con visión de futuro del siguiente conjunto — estas evalúan el criterio y la autoconciencia, no historias pasadas:
|
||||
|
||||
**Visión de futuro / situacional:**
|
||||
|
||||
- "¿Cómo se ve el éxito para ti en los primeros 90 días?"
|
||||
- "Si te unes y el equipo está teniendo problemas — plazos incumplidos, moral baja — ¿cuál es tu primer movimiento?"
|
||||
- "¿Cómo decides qué delegar vs. qué asumir tú mismo?"
|
||||
- "¿Cómo manejas a un colega respetado que no está de acuerdo con una dirección que has establecido?"
|
||||
|
||||
**Autoconciencia / crecimiento:**
|
||||
|
||||
- "¿En qué te equivocaste profesionalmente y qué aprendiste?"
|
||||
- "¿Qué necesitas de tu mánager para hacer tu mejor trabajo?"
|
||||
- "¿En qué áreas sigues creciendo en tu rol?"
|
||||
|
||||
### Technical / Domain-Specific (practitioner, 45–60 min)
|
||||
|
||||
1. [Internals fundamentales de la principal herramienta o método de la disciplina — ej., internals del runtime para ingeniería, modelos de atribución para marketing, métodos de valoración para finanzas]
|
||||
2. [Patrón o marco de trabajo establecido relevante para el rol — extraído de la JD]
|
||||
3. [Profundización en un bloque de construcción fundamental — ej., una estructura de datos, una prueba estadística, un principio contable]
|
||||
4. [Tema avanzado que la JD enfatiza — el área donde la profundidad separa a los candidatos]
|
||||
5. Háblame de un fallo de alto impacto en tu trabajo — cómo lo diagnosticaste y qué hiciste.
|
||||
6. ¿Cómo elevas el estándar de calidad en un equipo?
|
||||
|
||||
### Design / Case Study (45–60 min)
|
||||
|
||||
1. Diseña [un sistema, proceso, campaña o producto relevante para el rol].
|
||||
2. [Pregunta de restricción — ¿cómo se comporta tu diseño cuando algo falla, escala 10x o pierde presupuesto?]
|
||||
3. [Pregunta de calidad/confiabilidad — ¿cómo garantizas la corrección o mides el éxito?]
|
||||
4. Explícame cómo sabrías que está funcionando después del lanzamiento.
|
||||
|
||||
### Behavioral Panel
|
||||
|
||||
1. Háblame de una vez que lideraste a un equipo a través de una entrega difícil.
|
||||
2. Describe un fallo importante en producción o en el mercado — ¿qué sucedió y qué cambió después?
|
||||
3. Háblame de una vez que influiste en la dirección de varios equipos o partes interesadas (stakeholders).
|
||||
4. ¿Cómo se ve un equipo de alto rendimiento para ti?
|
||||
5. Háblame de una vez que simplificaste algo complejo.
|
||||
6. Háblame de una vez que resolviste un problema que no te correspondía resolver.
|
||||
|
||||
---
|
||||
|
||||
## Rules
|
||||
|
||||
- **Una pregunta a la vez.** Nunca lances múltiples preguntas juntas. Los entrevistadores reales hacen una a la vez.
|
||||
- **Sin pistas antes de la respuesta.** No prepares al candidato con "esto trata sobre X". Pregunta en frío.
|
||||
- **Solo feedback honesto.** El falso aliento es peor que el silencio — envía al candidato a una entrevista real mal preparado.
|
||||
- **Sin afirmaciones inventadas en las respuestas sugeridas.** Las versiones más sólidas se basan solo en lo que dijo el candidato o lo que está en `cv.md`, `article-digest.md` o el banco de historias — nunca inventar experiencia o métricas.
|
||||
- **Las afirmaciones retractadas son una barrera estricta.** Si una afirmación aparece en `interview-prep/retracted-claims.md`, nunca la uses en una versión más sólida — incluso si el candidato la dijo en su respuesta. En su lugar, márcala.
|
||||
- **Rastrea el estado.** Actualiza `interview-prep/question-bank.md` después de la sesión si existe.
|
||||
- **Detente cuando te lo pidan.** Si el candidato dice "vamos a pausar" o "es suficiente por hoy", respétalo. No presiones para una pregunta más.
|
||||
@@ -0,0 +1,166 @@
|
||||
# Modo: oferta -- Evaluación completa A-F
|
||||
|
||||
Cuando el candidato pegue una oferta (texto o URL), SIEMPRE entregar los 6 bloques.
|
||||
|
||||
## Paso 0 -- Detección de arquetipo
|
||||
|
||||
Clasificar la oferta en uno de los 6 arquetipos (ver `_shared.md`). Si es híbrida, indicar los 2 más cercanos. Esto determina:
|
||||
- Qué proof points priorizar en el bloque B
|
||||
- Cómo reescribir el summary en el bloque E
|
||||
- Qué stories STAR preparar en el bloque F
|
||||
|
||||
## Bloque A -- Resumen del rol
|
||||
|
||||
Tabla con:
|
||||
- Arquetipo detectado
|
||||
- Dominio (Platform / Agentic / LLMOps / ML / Enterprise)
|
||||
- Función (Build / Consultoría / Management / Deploy)
|
||||
- Seniority
|
||||
- Remoto (Full remote / Híbrido / Presencial)
|
||||
- Tamaño del equipo (si se menciona)
|
||||
- TL;DR en 1 frase
|
||||
|
||||
## Bloque B -- Match con el CV
|
||||
|
||||
Leer `cv.md`. Crear una tabla donde cada requisito de la oferta se mapea sobre líneas exactas del CV.
|
||||
|
||||
**Adaptado al arquetipo:**
|
||||
- FDE -> priorizar los proof points de entrega rápida y cercanía al cliente
|
||||
- SA -> priorizar el diseño de sistemas y las integraciones
|
||||
- PM -> priorizar la product discovery y las métricas
|
||||
- LLMOps -> priorizar evals, observabilidad, pipelines
|
||||
- Agentic -> priorizar multi-agente, HITL, orquestación
|
||||
- Transformation -> priorizar gestión del cambio, adopción, escalado
|
||||
|
||||
Sección **Gaps** con estrategia de mitigación para cada uno. Para cada gap:
|
||||
1. ¿Es un bloqueador duro o un nice-to-have?
|
||||
2. ¿Puede el candidato demostrar experiencia adyacente?
|
||||
3. ¿Hay algún proyecto del portfolio que cubra este gap?
|
||||
4. Plan de mitigación concreto (frase para la carta de presentación, mini-proyecto rápido, etc.)
|
||||
|
||||
## Bloque C -- Nivel y estrategia
|
||||
|
||||
1. **Nivel detectado** en la oferta vs. **nivel natural del candidato para ese arquetipo**
|
||||
2. **Plan "vender senior sin mentir"**: formulaciones específicas adaptadas al arquetipo, logros concretos a destacar, cómo posicionar la experiencia de fundador como ventaja
|
||||
3. **Plan "si estoy downlevel"**: aceptar si la remuneración es justa, negociar una revisión a los 6 meses, criterios de promoción claros
|
||||
|
||||
## Bloque D -- Remuneración y demanda
|
||||
|
||||
Usar WebSearch para:
|
||||
- Salarios actuales del rol (Glassdoor, LinkedIn Salary Insights, InfoJobs Estudios Salariales, Levels.fyi, Talent.io, Indeed Salarios)
|
||||
- Reputación de remuneración de la empresa (Glassdoor, LinkedIn)
|
||||
- Tendencia de demanda del rol en el mercado hispanohablante
|
||||
|
||||
Tabla con datos y fuentes citadas. Si no hay datos, decirlo claramente — no inventar nada.
|
||||
|
||||
**Mercado español -- Verificaciones obligatorias:**
|
||||
- ¿Se mencionan pagas extra (14 pagas)? Incluirlas en el cálculo del bruto anual.
|
||||
- ¿Parte variable (bonus, comisión, stock options / phantom shares)?
|
||||
- ¿Plan de pensiones o seguro médico mencionados? ¿Histórico disponible?
|
||||
- ¿Qué convenio colectivo aplica (TIC, Consultoría, Metal…)? Si es así, verificar la categoría.
|
||||
- ¿Contrato indefinido o temporal? Si es temporal: duración, motivo, posibilidad de conversión a indefinido.
|
||||
- ¿Freelance / autónomo? Tarifa diaria o mensual, duración del proyecto, riesgo de falsa autonomía.
|
||||
|
||||
## Bloque E -- Plan de personalización
|
||||
|
||||
| # | Sección | Estado actual | Cambio propuesto | Justificación |
|
||||
|---|---------|---------------|------------------|---------------|
|
||||
| 1 | Summary | ... | ... | ... |
|
||||
| ... | ... | ... | ... | ... |
|
||||
|
||||
Top 5 modificaciones del CV + Top 5 modificaciones de LinkedIn para maximizar el match.
|
||||
|
||||
## Bloque F -- Plan de entrevistas
|
||||
|
||||
6-10 stories STAR+R mapeadas sobre los requisitos de la oferta (STAR + **Reflexión**):
|
||||
|
||||
| # | Requisito de la oferta | Story STAR+R | S | T | A | R | Reflexión |
|
||||
|---|------------------------|--------------|---|---|---|---|-----------|
|
||||
|
||||
La columna **Reflexión** captura lo aprendido o lo que se haría diferente. Señala la seniority — los juniors describen lo que ocurrió, los seniors extraen aprendizajes.
|
||||
|
||||
**Story Bank:** Si existe `interview-prep/story-bank.md`, verificar si estas stories ya están ahí. Si no, añadir las nuevas. Con el tiempo, esto construye un banco reutilizable de 5-10 stories maestras adaptables a cualquier pregunta de entrevista.
|
||||
|
||||
**Seleccionadas y enmarcadas según el arquetipo:**
|
||||
- FDE -> destacar la velocidad de entrega y la cercanía al cliente
|
||||
- SA -> destacar las decisiones de arquitectura
|
||||
- PM -> destacar la discovery y las decisiones de priorización
|
||||
- LLMOps -> destacar las métricas, evals, hardening en producción
|
||||
- Agentic -> destacar la orquestación, el manejo de errores, el HITL
|
||||
- Transformation -> destacar la adopción y el cambio organizacional
|
||||
|
||||
Incluir también:
|
||||
- 1 case study recomendado (qué proyecto presentar y cómo)
|
||||
- Preguntas red-flag y cómo responderlas (ej.: "¿Por qué dejaste tu empresa?", "¿Tenías equipo a cargo?", "¿Por qué un cambio tan pronto?")
|
||||
|
||||
---
|
||||
|
||||
## Post-evaluación
|
||||
|
||||
**SIEMPRE** ejecutar tras los bloques A-F:
|
||||
|
||||
### 1. Guardar el report .md
|
||||
|
||||
Guardar la evaluación completa en `reports/{###}-{company-slug}-{YYYY-MM-DD}.md`.
|
||||
|
||||
- `{###}` = siguiente número secuencial (3 dígitos, zero-padded). Para asignarlo de forma atómica y evitar condiciones de carrera, ejecutar `node reserve-report-num.mjs` para reservar el número (stdout devuelve `{###}`), escribir el report y luego ejecutar `node reserve-report-num.mjs --release {###}` para liberar el sentinel.
|
||||
- `{company-slug}` = nombre de empresa en minúsculas, sin espacios (usar guiones)
|
||||
- `{YYYY-MM-DD}` = fecha de hoy
|
||||
|
||||
**Formato del report:**
|
||||
|
||||
```markdown
|
||||
# Evaluación: {Empresa} -- {Rol}
|
||||
|
||||
**Fecha:** {YYYY-MM-DD}
|
||||
**Arquetipo:** {detectado}
|
||||
**Score:** {X/5}
|
||||
**URL:** {URL de la oferta}
|
||||
**PDF:** {ruta o pendiente}
|
||||
|
||||
---
|
||||
|
||||
## A) Resumen del rol
|
||||
(contenido completo del bloque A)
|
||||
|
||||
## B) Match con el CV
|
||||
(contenido completo del bloque B)
|
||||
|
||||
## C) Nivel y estrategia
|
||||
(contenido completo del bloque C)
|
||||
|
||||
## D) Remuneración y demanda
|
||||
(contenido completo del bloque D)
|
||||
|
||||
## E) Plan de personalización
|
||||
(contenido completo del bloque E)
|
||||
|
||||
## F) Plan de entrevistas
|
||||
(contenido completo del bloque F)
|
||||
|
||||
## G) Borradores de respuestas para la candidatura
|
||||
(solo si score >= 4.5 -- borradores de respuestas para el formulario de candidatura)
|
||||
|
||||
---
|
||||
|
||||
## Palabras clave extraídas
|
||||
(lista de 15-20 palabras clave de la oferta para optimización ATS)
|
||||
```
|
||||
|
||||
### 2. Registrar en el tracker
|
||||
|
||||
**SIEMPRE** registrar en `data/applications.md`:
|
||||
- Siguiente número secuencial
|
||||
- Fecha de hoy
|
||||
- Empresa
|
||||
- Rol
|
||||
- Score: media del match (1-5)
|
||||
- Estado: `Evaluated`
|
||||
- PDF: no (o sí si el auto-pipeline generó un PDF)
|
||||
- Report: enlace relativo al archivo del report (ej.: `[001](reports/001-company-2026-01-01.md)`)
|
||||
|
||||
**Formato del tracker:**
|
||||
|
||||
```markdown
|
||||
| # | Fecha | Empresa | Rol | Score | Estado | PDF | Report |
|
||||
```
|
||||
@@ -0,0 +1,63 @@
|
||||
# Modo: pipeline -- Bandeja de URLs (Second Brain)
|
||||
|
||||
Procesa las URLs de ofertas acumuladas en `data/pipeline.md`. El candidato añade URLs cuando quiere y luego lanza `/career-ops pipeline` para procesarlas todas de una vez.
|
||||
|
||||
## Workflow
|
||||
|
||||
1. **Leer** `data/pipeline.md` -> encontrar los ítems `- [ ]` en la sección "Pendientes" / "Pending" / "En attente"
|
||||
2. **Para cada URL pendiente**:
|
||||
a. Reservar el siguiente `REPORT_NUM` secuencial de forma atómica ejecutando `node reserve-report-num.mjs` (y liberar el sentinel ejecutando `node reserve-report-num.mjs --release <num>` una vez escrito el report)
|
||||
b. **Extraer la oferta** con Playwright (`browser_navigate` + `browser_snapshot`) -> WebFetch -> WebSearch
|
||||
c. Si la URL no es accesible -> marcar como `- [!]` con una nota y continuar
|
||||
d. **Ejecutar el auto-pipeline completo**: Evaluación A-F -> Report .md -> PDF (si score >= 3.0) -> Tracker
|
||||
e. **Mover de "Pendientes" a "Procesadas"**: `- [x] #NNN | URL | Empresa | Rol | Score/5 | PDF sí/no`
|
||||
3. **Si hay 3+ URLs pendientes**, lanzar agentes en paralelo (Agent tool con `run_in_background`) para maximizar la velocidad.
|
||||
4. **Al final**, mostrar una tabla resumen:
|
||||
|
||||
```
|
||||
| # | Empresa | Rol | Score | PDF | Acción recomendada |
|
||||
```
|
||||
|
||||
## Formato de pipeline.md
|
||||
|
||||
```markdown
|
||||
## Pendientes
|
||||
- [ ] https://jobs.example.com/posting/123
|
||||
- [ ] https://boards.greenhouse.io/company/jobs/456 | Company S.L. | Senior PM
|
||||
- [!] https://private.url/job -- Error: requiere inicio de sesión
|
||||
|
||||
## Procesadas
|
||||
- [x] #143 | https://jobs.example.com/posting/789 | Acme S.L. | AI PM | 4.2/5 | PDF sí
|
||||
- [x] #144 | https://boards.greenhouse.io/xyz/jobs/012 | BigCo | SA | 2.1/5 | PDF no
|
||||
```
|
||||
|
||||
> Nota: Las cabeceras de sección pueden estar en EN ("Pending"/"Processed"), ES ("Pendientes"/"Procesadas"), DE ("Offen"/"Verarbeitet") o FR ("En attente"/"Traitées"). Ser flexible al leer, fiel al estilo existente al escribir.
|
||||
|
||||
## Detección inteligente de la oferta desde la URL
|
||||
|
||||
1. **Playwright (preferido):** `browser_navigate` + `browser_snapshot`. Funciona con todas las SPAs.
|
||||
2. **WebFetch (fallback):** Para páginas estáticas o cuando Playwright no está disponible.
|
||||
3. **WebSearch (último recurso):** Buscar en portales secundarios que indexen la oferta.
|
||||
|
||||
**Casos especiales:**
|
||||
- **LinkedIn**: Puede requerir inicio de sesión -> marcar `[!]` y pedir al candidato que pegue el texto
|
||||
- **PDF**: Si la URL apunta a un PDF, leerlo directamente con la herramienta Read
|
||||
- **Prefijo `local:`**: Leer el archivo local. Ejemplo: `local:jds/linkedin-pm-ai.md` -> leer `jds/linkedin-pm-ai.md`
|
||||
- **InfoJobs / Indeed ES / LinkedIn ES**: Portales hispanohablantes habituales. Playwright gestiona bien los banners de cookies
|
||||
- **Infojobs.es / Tecnoempleo / Computrabajo**: Bien estructurados, generalmente legibles por máquina. WebFetch suele ser suficiente
|
||||
|
||||
## Numeración automática
|
||||
|
||||
1. Ejecutar `node reserve-report-num.mjs` para reservar el siguiente número secuencial de forma atómica (stdout devuelve `{###}`).
|
||||
2. Escribir el report con ese número.
|
||||
3. Liberar el sentinel ejecutando `node reserve-report-num.mjs --release {###}` una vez escrito el report.
|
||||
|
||||
## Sincronización de fuentes
|
||||
|
||||
Antes de procesar una URL, verificar la sincronización:
|
||||
|
||||
```bash
|
||||
node cv-sync-check.mjs
|
||||
```
|
||||
|
||||
Si hay desincronización, avisar al candidato antes de continuar.
|
||||
@@ -0,0 +1,198 @@
|
||||
# Mode: followup -- Follow-up Cadence Tracker
|
||||
|
||||
> **Read `voice-dna.md` (if present) and apply it to every generated email/LinkedIn draft.** This mode is standalone — it does NOT load `_shared.md`, so read `voice-dna.md` directly. Follow-up drafts are conversational, so apply the full guardrail: banned words/phrases/patterns, no em-dashes, no negative parallelisms (§3-4) AND conversational voice — contractions, varied rhythm, direct "I"/"you" (§1-2). Never drop or soften a real metric from `cv.md` for style.
|
||||
|
||||
## Purpose
|
||||
|
||||
Track follow-up cadence for active applications. Flag overdue follow-ups, extract contacts from notes, and generate tailored follow-up email/LinkedIn drafts using report context.
|
||||
|
||||
## Inputs
|
||||
|
||||
- `data/applications.md` — Application tracker
|
||||
- `data/follow-ups.md` — Follow-up history (created on first use)
|
||||
- `reports/` — Evaluation reports (for context in drafts)
|
||||
- `config/profile.yml` — User profile (name, identity)
|
||||
- `cv.md` — CV for proof points in drafts
|
||||
|
||||
## Step 1 — Run Cadence Script
|
||||
|
||||
Execute:
|
||||
|
||||
```bash
|
||||
node followup-cadence.mjs
|
||||
```
|
||||
|
||||
Parse the JSON output. It contains:
|
||||
|
||||
| Key | Contents |
|
||||
|-----|----------|
|
||||
| `metadata` | Analysis date, total tracked, actionable count, overdue/urgent/cold/waiting counts |
|
||||
| `entries` | Per-application: company, role, status, days since application, follow-up count, urgency, next follow-up date, extracted contacts, report path |
|
||||
| `cadenceConfig` | Cadence rules (applied: 7 days, responded: 3 days, interview: 1 day) |
|
||||
|
||||
If no actionable entries, tell the user:
|
||||
> "No active applications to follow up on. Apply to some roles first with `/career-ops` and come back when they're aging."
|
||||
|
||||
## Step 2 — Display Dashboard
|
||||
|
||||
Show a cadence dashboard sorted by urgency (urgent > overdue > waiting > cold):
|
||||
|
||||
```
|
||||
Follow-up Cadence Dashboard — {date}
|
||||
{N} applications tracked, {N} actionable
|
||||
|
||||
| # | Company | Role | Status | Days | Follow-ups | Next | Urgency | Contact |
|
||||
```
|
||||
|
||||
Use visual indicators:
|
||||
- **URGENT** — respond within 24 hours (company replied)
|
||||
- **OVERDUE** — follow-up is past due
|
||||
- **waiting (X days)** — on track, follow-up scheduled
|
||||
- **COLD** — 2+ follow-ups sent, suggest closing
|
||||
|
||||
## Step 3 — Generate Follow-up Drafts
|
||||
|
||||
For each **overdue** or **urgent** entry only:
|
||||
|
||||
1. Read the linked report (`reportPath` from JSON) for company context
|
||||
2. Read `cv.md` for proof points
|
||||
3. Read `config/profile.yml` for candidate name and identity
|
||||
|
||||
### Email Follow-up Framework (first follow-up, followupCount == 0)
|
||||
|
||||
Generate a 3-4 sentence email:
|
||||
|
||||
1. **Sentence 1:** Reference the specific role + when you applied. Be specific — mention the company name and role title.
|
||||
2. **Sentence 2:** One concrete value-add from the report's Block B match or a proof point from cv.md. Quantify if possible.
|
||||
3. **Sentence 3:** Soft ask + availability. Offer a specific time window ("this week" or "next Tuesday").
|
||||
4. **Sentence 4 (optional):** Brief mention of a relevant recent project or achievement.
|
||||
|
||||
**Rules:**
|
||||
- Professional but warm, NOT desperate
|
||||
- **NEVER** use "just checking in", "just following up", "touching base", or "circling back"
|
||||
- Lead with value, not with the ask
|
||||
- Reference something specific to THAT company (from report Block A)
|
||||
- Keep under 150 words
|
||||
- Include a subject line
|
||||
- Use the candidate's name from `config/profile.yml`
|
||||
|
||||
**Example tone:**
|
||||
> Subject: Re: Senior PHP/Laravel Developer — IxDF
|
||||
>
|
||||
> Hi [contact name or "team"],
|
||||
>
|
||||
> I submitted my application for the Senior PHP/Laravel Developer role on April 7th. I wanted to share that my production Laravel app (Barbeiro.app — 120 models, 315 API endpoints, full test suite) closely mirrors the TDD-driven culture described in the posting.
|
||||
>
|
||||
> I'd love to discuss how my 15 years of PHP experience and hands-on AI tooling workflow could contribute to IxDF's platform. Would any time this week work for a brief conversation?
|
||||
>
|
||||
> Best,
|
||||
> [Name]
|
||||
|
||||
### LinkedIn Follow-up (if no email contact found)
|
||||
|
||||
Reuse the contacto framework: 3 sentences, 300 character max.
|
||||
- Hook specific to company → proof point → soft ask
|
||||
- Suggest the user run `/career-ops contacto {company}` to find the right person first
|
||||
|
||||
### Second Follow-up (followupCount == 1)
|
||||
|
||||
Shorter than first (2-3 sentences). Take a **new angle**:
|
||||
- Share a relevant insight, article, or project update
|
||||
- Don't repeat the first follow-up's content
|
||||
- Still reference the role specifically
|
||||
|
||||
### Cold Application (followupCount >= 2)
|
||||
|
||||
Do NOT generate another follow-up. Instead suggest:
|
||||
> "This application has had {N} follow-ups with no response. Consider:
|
||||
> - Updating status to `Discarded` if the role seems filled
|
||||
> - Trying a different contact via `/career-ops contacto`
|
||||
> - Keeping in `Applied` status but deprioritizing"
|
||||
|
||||
## Step 4 — Present Drafts
|
||||
|
||||
For each draft, show:
|
||||
|
||||
```
|
||||
## Follow-up: {Company} — {Role} (#{num})
|
||||
|
||||
**To:** {email or "No contact found — run `/career-ops contacto` first"}
|
||||
**Subject:** {subject line}
|
||||
**Days since application:** {N}
|
||||
**Follow-ups sent:** {N}
|
||||
**Channel:** Email / LinkedIn
|
||||
|
||||
{draft text}
|
||||
```
|
||||
|
||||
## Step 5 — Record Follow-ups
|
||||
|
||||
After the user reviews and says they've sent a follow-up, record it:
|
||||
|
||||
1. If `data/follow-ups.md` doesn't exist, create it (this exact header — the
|
||||
same one the web UI writes; `followup-cadence.mjs` parses these columns):
|
||||
|
||||
```markdown
|
||||
# Follow-ups
|
||||
|
||||
| num | appNum | date | company | role | channel | contact | notes |
|
||||
|---|---|---|---|---|---|---|---|
|
||||
```
|
||||
|
||||
2. Append a row with:
|
||||
- `num` = next sequential number in the follow-ups table
|
||||
- `appNum` = application number from tracker
|
||||
- `date` = today's date (YYYY-MM-DD)
|
||||
- `company` = company name
|
||||
- `role` = role title
|
||||
- `channel` = Email / LinkedIn / Other
|
||||
- `contact` = who it was sent to
|
||||
- `notes` = brief note (e.g., "First follow-up, referenced Barbeiro.app")
|
||||
|
||||
3. Optionally update the Notes column in `data/applications.md` with "Follow-up {N} sent {YYYY-MM-DD}"
|
||||
|
||||
**IMPORTANT:** Only record follow-ups the user confirms they actually sent. Never record a draft as sent.
|
||||
|
||||
### Pinned next dates & automatic seeding
|
||||
|
||||
`data/follow-ups.md` also supports pin lines that override the computed
|
||||
schedule for a single application:
|
||||
|
||||
```text
|
||||
- next #42 2026-07-10 (set 2026-07-02)
|
||||
```
|
||||
|
||||
`#42` is the application number, the first date is the pinned NEXT follow-up
|
||||
date, and `(set …)` is the day the pin was made. Pins take precedence over
|
||||
the computed schedule until a follow-up is logged on or after the set-date;
|
||||
the latest pin per application wins; deleting the line clears the pin.
|
||||
|
||||
Pins may be seeded AUTOMATICALLY when an application turns Applied —
|
||||
`node followup-seed.mjs <num>` (run by the `apply` mode's Step 9) appends a
|
||||
pin scheduling the first follow-up at apply date + the `applied_first`
|
||||
cadence. Seeding is idempotent, and a stale pin left behind by a later
|
||||
Rejected/Discarded transition is harmless because the cadence analysis
|
||||
ignores non-actionable statuses.
|
||||
|
||||
## Step 6 — Summary
|
||||
|
||||
After showing all drafts, summarize:
|
||||
|
||||
> **Follow-up Dashboard** ({date})
|
||||
> - {N} applications being tracked
|
||||
> - {N} overdue — drafts generated above
|
||||
> - {N} urgent — respond today
|
||||
> - {N} waiting — next follow-up dates shown
|
||||
> - {N} cold — consider closing
|
||||
>
|
||||
> Review the drafts above and tell me which ones you've sent so I can record them.
|
||||
|
||||
## Cadence Rules Reference
|
||||
|
||||
| Status | First follow-up | Subsequent | Max attempts |
|
||||
|--------|----------------|------------|-------------|
|
||||
| Applied | 7 days after application | Every 7 days | 2 (then mark cold) |
|
||||
| Responded | 1 day (urgent reply) | Every 3 days | No limit |
|
||||
| Interview | 1 day after (thank-you) | Every 3 days | No limit |
|
||||
|
||||
These defaults can be overridden via `node followup-cadence.mjs --applied-days N`.
|
||||
@@ -0,0 +1,106 @@
|
||||
# career-ops -- Modes francophones (`modes/fr/`)
|
||||
|
||||
Ce dossier contient les traductions francaises des principaux modes career-ops pour les candidats qui ciblent le marche francophone (France, Belgique, Suisse romande, Luxembourg, Quebec).
|
||||
|
||||
## Quand utiliser ces modes ?
|
||||
|
||||
Utilise `modes/fr/` si au moins une de ces conditions est remplie :
|
||||
|
||||
- Tu postules principalement a des **offres d'emploi en francais** (Welcome to the Jungle, Indeed FR, APEC, Pole emploi / France Travail, LinkedIn FR, sites carrieres)
|
||||
- Ton **CV est en francais** ou tu alternes entre FR et EN selon l'offre
|
||||
- Tu as besoin de reponses et lettres de motivation en **francais tech naturel**, pas traduit par une machine
|
||||
- Tu dois gerer des **specificites contractuelles francophones** : convention collective, RTT, mutuelle, prevoyance, 13e mois, periode d'essai, preavis, cheques-dejeuner, interessement/participation, portage salarial
|
||||
|
||||
Si la plupart de tes offres sont en anglais, reste sur les modes standard dans `modes/`. Les modes anglais fonctionnent pour les offres francophones, mais ne connaissent pas les specificites du marche francophone en detail.
|
||||
|
||||
## Comment activer ?
|
||||
|
||||
### Option 1 -- Par session
|
||||
|
||||
Dis a Claude en debut de session :
|
||||
|
||||
> "Utilise les modes francais sous `modes/fr/`."
|
||||
|
||||
Claude lira alors les fichiers de ce dossier au lieu de `modes/`.
|
||||
|
||||
### Option 2 -- En permanence
|
||||
|
||||
Ajoute dans `config/profile.yml` :
|
||||
|
||||
```yaml
|
||||
language:
|
||||
primary: fr
|
||||
modes_dir: modes/fr
|
||||
```
|
||||
|
||||
Rappelle-le a Claude lors de ta premiere session ("Regarde dans `profile.yml`, j'ai configure `language.modes_dir`"). Claude utilisera automatiquement les modes francais.
|
||||
|
||||
## Quels modes sont traduits ?
|
||||
|
||||
Cette premiere iteration couvre les quatre modes a plus fort impact :
|
||||
|
||||
| Fichier | Traduit depuis | Role |
|
||||
|---------|----------------|------|
|
||||
| `_shared.md` | `modes/_shared.md` (EN) | Contexte partage, archetypes, regles globales, specificites marche francophone |
|
||||
| `offre.md` | `modes/oferta.md` (ES) | Evaluation complete d'une offre (Blocs A-F) |
|
||||
| `postuler.md` | `modes/apply.md` (EN) | Assistant live pour remplir les formulaires de candidature |
|
||||
| `pipeline.md` | `modes/pipeline.md` (ES) | Inbox d'URLs / Second Brain pour les offres collectees |
|
||||
|
||||
Les autres modes (`scan`, `batch`, `pdf`, `tracker`, `auto-pipeline`, `deep`, `contacto`, `ofertas`, `project`, `training`) restent en EN/ES. Leur contenu est surtout du tooling, des chemins et des commandes -- il doit rester independant de la langue.
|
||||
|
||||
## Ce qui reste en anglais
|
||||
|
||||
Volontairement non traduit car vocabulaire tech standard :
|
||||
|
||||
- `cv.md`, `pipeline`, `tracker`, `report`, `score`, `archetype`, `proof point`
|
||||
- Noms d'outils (`Playwright`, `WebSearch`, `WebFetch`, `Read`, `Write`, `Edit`, `Bash`)
|
||||
- Valeurs de statut dans le tracker (`Evaluated`, `Applied`, `Interview`, `Offer`, `Rejected`)
|
||||
- Extraits de code, chemins, commandes
|
||||
|
||||
Les modes utilisent du francais tech naturel, tel qu'il est parle dans les equipes engineering a Paris, Lyon ou Geneve : texte courant en francais, termes techniques en anglais la ou c'est l'usage. Pas de traduction forcee de "Pipeline" en "Canalisation" ni de "Deploy" en "Deploiement applicatif".
|
||||
|
||||
## Lexique de reference
|
||||
|
||||
Pour garder un ton coherent si tu modifies ou etends les modes :
|
||||
|
||||
| Anglais | Francais (dans cette codebase) |
|
||||
|---------|-------------------------------|
|
||||
| Job posting | Offre d'emploi / Annonce |
|
||||
| Application | Candidature |
|
||||
| Cover letter | Lettre de motivation |
|
||||
| Resume / CV | CV |
|
||||
| Salary | Salaire / Remuneration |
|
||||
| Compensation | Remuneration / Package |
|
||||
| Skills | Competences |
|
||||
| Interview | Entretien |
|
||||
| Hiring manager | Manager recruteur / Hiring manager |
|
||||
| Recruiter | Recruteur (ou Recruiter) |
|
||||
| AI | IA (Intelligence Artificielle) |
|
||||
| Requirements | Prerequis / Exigences |
|
||||
| Career history | Parcours professionnel |
|
||||
| Notice period | Preavis |
|
||||
| Probation | Periode d'essai |
|
||||
| Vacation | Conges payes (CP) |
|
||||
| 13th month salary | 13e mois / Prime de fin d'annee |
|
||||
| Permanent employment | CDI (Contrat a Duree Indeterminee) |
|
||||
| Fixed-term contract | CDD (Contrat a Duree Determinee) |
|
||||
| Freelance | Freelance / Independant / Auto-entrepreneur |
|
||||
| Collective agreement | Convention collective |
|
||||
| Works council | CSE (Comite Social et Economique) |
|
||||
| Profit sharing | Interessement / Participation |
|
||||
| Meal vouchers | Titres-restaurant / Cheques-dejeuner |
|
||||
| Health insurance | Mutuelle d'entreprise |
|
||||
| Disability/life insurance | Prevoyance |
|
||||
| RTT | RTT (Reduction du Temps de Travail) |
|
||||
| Cadre status | Statut cadre |
|
||||
| SYNTEC | Convention SYNTEC (IT/consulting) |
|
||||
|
||||
## Contribuer
|
||||
|
||||
Pour ameliorer une traduction ou ajouter un mode :
|
||||
|
||||
1. Ouvre une Issue avec ta proposition (voir `CONTRIBUTING.md`)
|
||||
2. Respecte le lexique ci-dessus pour garder le ton coherent
|
||||
3. Traduis de maniere idiomatique -- pas de traduction mot a mot
|
||||
4. Conserve les elements structurels (Blocs A-F, tableaux, blocs de code, instructions outils) a l'identique
|
||||
5. Teste avec une vraie offre francophone (Welcome to the Jungle, APEC, Indeed FR) avant de soumettre la PR
|
||||
@@ -0,0 +1,205 @@
|
||||
# Contexte partage -- career-ops (Francais)
|
||||
|
||||
<!-- ============================================================
|
||||
PERSONNALISATION DE CE FICHIER
|
||||
============================================================
|
||||
Ce fichier contient le contexte partage pour tous les modes
|
||||
career-ops en version francaise. Avant d'utiliser career-ops, tu DOIS :
|
||||
1. Remplir config/profile.yml avec tes informations personnelles
|
||||
2. Creer cv.md a la racine du projet (CV en Markdown)
|
||||
3. (Optionnel) Creer article-digest.md avec tes proof points
|
||||
4. Adapter les sections marquees [PERSONNALISER] ci-dessous
|
||||
============================================================ -->
|
||||
|
||||
## Sources de verite (TOUJOURS lire avant chaque evaluation)
|
||||
|
||||
| Fichier | Chemin | Quand |
|
||||
|---------|--------|-------|
|
||||
| cv.md | `cv.md` (racine du projet) | TOUJOURS |
|
||||
| article-digest.md | `article-digest.md` (si existant) | TOUJOURS (proof points detailles) |
|
||||
| profile.yml | `config/profile.yml` | TOUJOURS (identite et roles cibles) |
|
||||
|
||||
**REGLE : Ne JAMAIS coder en dur des metriques issues des proof points.** Les lire depuis `cv.md` et `article-digest.md` au moment de l'evaluation.
|
||||
**REGLE : Pour les metriques d'articles/projets, `article-digest.md` a priorite sur `cv.md`** (`cv.md` peut contenir des chiffres plus anciens).
|
||||
|
||||
---
|
||||
|
||||
## North Star -- Roles cibles
|
||||
|
||||
Le skill traite TOUS les roles cibles avec le meme soin. Aucun n'est primaire ou secondaire -- chacun est un succes si la remuneration et les perspectives d'evolution sont au rendez-vous :
|
||||
|
||||
| Archetype | Axes thematiques | Ce que l'entreprise achete |
|
||||
|-----------|------------------|----------------------------|
|
||||
| **AI Platform / LLMOps Engineer** | Evaluation, Observability, Fiabilite, Pipelines | Quelqu'un qui met l'IA en production avec des metriques |
|
||||
| **Agentic Workflows / Automation** | HITL, Tooling, Orchestration, Multi-Agent | Quelqu'un qui construit des systemes agents fiables |
|
||||
| **Technical AI Product Manager** | GenAI/Agents, PRDs, Discovery, Delivery | Quelqu'un qui traduit le business en produits IA |
|
||||
| **AI Solutions Architect** | Hyperautomation, Enterprise, Integrations | Quelqu'un qui concoit des architectures IA end-to-end |
|
||||
| **AI Forward Deployed Engineer** | Client-facing, Livraison rapide, Prototypage | Quelqu'un qui deploie des solutions IA rapidement chez le client |
|
||||
| **AI Transformation Lead** | Conduite du changement, Adoption, Enablement | Quelqu'un qui pilote la transformation IA dans les organisations |
|
||||
|
||||
<!-- [PERSONNALISER] Adapte les archetypes ci-dessus a tes roles cibles.
|
||||
Exemple pour le backend engineering :
|
||||
- Senior Backend Engineer
|
||||
- Staff Platform Engineer
|
||||
- Engineering Manager
|
||||
etc. -->
|
||||
|
||||
### Framing adaptatif par archetype
|
||||
|
||||
> **Metriques concretes : les lire depuis `cv.md` et `article-digest.md` au moment de l'evaluation. JAMAIS les coder en dur ici.**
|
||||
|
||||
| Si le role est... | Mettre en avant chez le candidat... | Sources de proof points |
|
||||
|-------------------|-------------------------------------|-------------------------|
|
||||
| Platform / LLMOps | Experience production, observability, evals, closed-loop | article-digest.md + cv.md |
|
||||
| Agentic / Automation | Orchestration multi-agent, HITL, fiabilite, couts | article-digest.md + cv.md |
|
||||
| Technical AI PM | Product discovery, PRDs, metriques, gestion des parties prenantes | cv.md + article-digest.md |
|
||||
| Solutions Architect | Conception systeme, integrations, pret pour l'entreprise | article-digest.md + cv.md |
|
||||
| Forward Deployed Engineer | Livraison rapide, proximite client, prototype a production | cv.md + article-digest.md |
|
||||
| AI Transformation Lead | Conduite du changement, enablement d'equipe, adoption | cv.md + article-digest.md |
|
||||
|
||||
<!-- [PERSONNALISER] Associe tes projets/articles concrets aux archetypes ci-dessus -->
|
||||
|
||||
### Narratif de transition (a utiliser dans TOUS les framings)
|
||||
|
||||
<!-- [PERSONNALISER] Remplace par ton propre narratif. Exemples :
|
||||
- "SaaS construite et vendue apres 5 ans. Desormais 100% focus sur l'IA appliquee en entreprise."
|
||||
- "Lead engineering dans une Series-B pendant une croissance x10. En quete du prochain defi."
|
||||
- "Transition du conseil vers le produit. Recherche de roles a forte responsabilite."
|
||||
Lu depuis config/profile.yml -> narrative.exit_story -->
|
||||
|
||||
Utiliser le narratif de transition depuis `config/profile.yml` pour cadrer TOUS les contenus :
|
||||
- **Dans les summaries PDF :** Faire le pont entre le passe et le futur -- "Applique desormais les memes [competences] au domaine [de l'offre]."
|
||||
- **Dans les stories STAR :** Faire reference aux proof points de `article-digest.md`.
|
||||
- **Dans les reponses draft (Bloc G) :** Le narratif de transition va dans la premiere reponse.
|
||||
- **Quand l'offre mentionne "entrepreneurial", "autonomie", "builder", "end-to-end" :** C'est LE differenciateur n.1. Augmenter le poids du match.
|
||||
|
||||
### Avantage transversal
|
||||
|
||||
Cadrer le profil comme **"Builder technique avec une pratique demontrable"**, en adaptant le framing au role :
|
||||
- Pour PM : "Builder qui reduit l'incertitude avec des prototypes puis livre en production de maniere disciplinee"
|
||||
- Pour FDE : "Builder qui livre des le jour 1 avec observability et metriques"
|
||||
- Pour SA : "Builder qui concoit des systemes end-to-end avec une vraie experience d'integration"
|
||||
- Pour LLMOps : "Builder qui met l'IA en production avec des systemes qualite en boucle fermee"
|
||||
|
||||
Positionner "Builder" comme signal professionnel -- pas comme "bricoleur". Les proof points reels rendent ca credible.
|
||||
|
||||
### Portfolio comme proof point (utiliser dans les candidatures a fort enjeu)
|
||||
|
||||
<!-- [PERSONNALISER] Si tu as une demo live, un dashboard ou un projet public, configure-le ici.
|
||||
Exemple :
|
||||
dashboard:
|
||||
url: "https://tondomaine.dev/demo"
|
||||
password: "demo-2026"
|
||||
when_to_share: "Roles LLMOps, AI Platform, Observability"
|
||||
Lu depuis config/profile.yml -> narrative.proof_points et narrative.dashboard -->
|
||||
|
||||
Si le candidat a une demo live / un dashboard (verifier `profile.yml`), proposer l'acces dans les candidatures pertinentes.
|
||||
|
||||
### Intelligence remuneration (Comp Intelligence)
|
||||
|
||||
<!-- [PERSONNALISER] Recherche les fourchettes de remuneration pour tes roles cibles et adapte les valeurs -->
|
||||
|
||||
**Conseils generaux :**
|
||||
- WebSearch pour les donnees marche actuelles (Glassdoor, Levels.fyi, Welcome to the Jungle, APEC, Talent.io, Indeed Salaires)
|
||||
- Cadrer par titre de poste, pas par competences -- les titres definissent les bandes salariales
|
||||
- Les taux freelance en France sont generalement 30-50% au-dessus du brut horaire equivalent CDI (charges sociales, conges, maladie, prospection)
|
||||
- Le geo-arbitrage fonctionne en remote : cout de la vie plus bas = meilleur net
|
||||
|
||||
### Marche francophone -- Specificites (IMPORTANT)
|
||||
|
||||
Dans les offres et negociations francophones, certains termes n'existent pas sur les marches EN/ES. Ils DOIVENT etre correctement pris en compte :
|
||||
|
||||
| Terme | Signification | Impact sur l'evaluation |
|
||||
|-------|---------------|-------------------------|
|
||||
| **CDI** (Contrat a Duree Indeterminee) | Equivalent du "permanent employment". Le graal en France | Standard attendu. Un CDD pour un senior est un signal d'alerte |
|
||||
| **CDD** (Contrat a Duree Determinee) | Contrat temporaire, duree fixe | Acceptable pour des missions specifiques. Sinon, questionner pourquoi pas CDI |
|
||||
| **Periode d'essai** | 3-4 mois cadre (renouvelable 1 fois, max 8 mois total) | Standard marche. Flaguer si > 4 mois initial |
|
||||
| **Preavis** | 1-3 mois selon convention collective et anciennete | Planifier la date de demarrage en consequence |
|
||||
| **Statut cadre** | Categorie socio-professionnelle specifique a la France. Implique forfait jours, cotisations differentes | La quasi-totalite des postes tech sont cadre. Verifier si mentionne |
|
||||
| **Convention collective SYNTEC** | Convention la plus courante en IT/conseil. Definit minima salariaux, classifications | Verifier la classification (position + coefficient) pour valider le salaire |
|
||||
| **RTT** (Reduction du Temps de Travail) | Jours de repos supplementaires (8-12/an en general) pour les cadres au forfait | Un vrai plus. Equivalent a 1-2 semaines de conges en plus |
|
||||
| **13e mois** | Mois de salaire supplementaire, souvent verse en decembre | Inclure dans le calcul : brut annuel = brut mensuel x 13. NE JAMAIS oublier dans la comparaison |
|
||||
| **Interessement / Participation** | Partage des benefices. Participation obligatoire > 50 salaries | Peut representer 1-3 mois de salaire. Verifier l'historique |
|
||||
| **Titres-restaurant** | Cheques-dejeuner (Swile, Edenred). Part employeur ~60% | Petit avantage mais courant. ~1000-1500 EUR/an d'economie |
|
||||
| **Mutuelle** | Complementaire sante obligatoire. Part employeur >= 50% | Standard. Verifier si la couverture est bonne (famille, optique, dentaire) |
|
||||
| **Prevoyance** | Assurance deces/invalidite/incapacite | Plus rare comme argument de vente, mais important a verifier |
|
||||
| **CSE** (Comite Social et Economique) | Instance representative du personnel | Avantages CSE (cheques vacances, culture, sport) = bonus non negligeable dans les grands groupes |
|
||||
| **Conges payes** | 25 jours legaux (5 semaines). Certaines conventions donnent plus | < 25 jours = illegal en France. 25 + RTT = standard tech. > 30 jours = excellent |
|
||||
| **Portage salarial** | Statut hybride entre salariat et freelance | Alternative au freelance pur. Simplifie l'administratif mais cout ~10% |
|
||||
| **Auto-entrepreneur / Micro-entreprise** | Statut freelance simplifie, plafond de CA | Pour les missions courtes. Attention au plafond et aux charges |
|
||||
|
||||
### Scripts de negociation
|
||||
|
||||
<!-- [PERSONNALISER] Adapte a ta situation -->
|
||||
|
||||
**Pretentions salariales (framework general) :**
|
||||
> "Sur la base des donnees marche actuelles pour ce type de poste, je vise une fourchette de [FOURCHETTE depuis profile.yml]. Je reste flexible sur la structure -- c'est le package global et les perspectives d'evolution qui comptent."
|
||||
|
||||
**Reponse a une decote geographique :**
|
||||
> "Les roles sur lesquels je suis en concurrence sont axes sur les resultats, pas sur la localisation. Mon track record ne change pas avec le code postal."
|
||||
|
||||
**Si l'offre est en dessous de la cible :**
|
||||
> "Je suis actuellement en discussion sur des packages dans la fourchette [fourchette superieure]. [Entreprise] m'attire pour [raison]. Est-il possible d'atteindre [cible] ?"
|
||||
|
||||
**Negociation sur le 13e mois / variable :**
|
||||
> "Pour comparer les packages de maniere equitable, pourriez-vous detailler le fixe brut annuel, le 13e mois eventuel, et la part variable separement ?"
|
||||
|
||||
### Politique de localisation (Location Policy)
|
||||
|
||||
<!-- [PERSONNALISER] Adapte a ta situation. Lu depuis config/profile.yml -> location -->
|
||||
|
||||
**Dans les formulaires :**
|
||||
- Questions binaires "Pouvez-vous etre sur site ?" : repondre selon la disponibilite reelle dans `profile.yml`
|
||||
- Champs libres : indiquer le chevauchement horaire et la disponibilite explicitement
|
||||
|
||||
**Dans les evaluations (scoring) :**
|
||||
- Dimension remote pour du hybride hors de ton pays : Score **3.0** (pas 1.0)
|
||||
- Score 1.0 uniquement si l'offre dit explicitement "presence obligatoire 4-5 jours/semaine, aucune exception"
|
||||
|
||||
### Priorite time-to-offer
|
||||
- Demo fonctionnelle + metriques > perfection
|
||||
- Postuler vite > apprendre davantage
|
||||
- Approche 80/20, tout est timebox
|
||||
|
||||
---
|
||||
|
||||
## Regles globales
|
||||
|
||||
### JAMAIS
|
||||
|
||||
1. Inventer de l'experience ou des metriques
|
||||
2. Modifier `cv.md` ou les fichiers portfolio
|
||||
3. Soumettre des candidatures au nom du candidat
|
||||
4. Partager un numero de telephone dans les messages generes
|
||||
5. Recommander une remuneration en dessous du marche
|
||||
6. Generer un PDF sans avoir lu l'offre avant
|
||||
7. Utiliser du jargon corporate ou des formules creuses
|
||||
8. Ignorer le tracker (chaque offre evaluee est enregistree)
|
||||
|
||||
### TOUJOURS
|
||||
|
||||
0. **Lettre de motivation :** Si le formulaire le permet, TOUJOURS en inclure une. PDF dans le meme design visuel que le CV. Citations de l'offre mappees sur les proof points. 1 page max.
|
||||
1. Lire `cv.md` et `article-digest.md` (si existant) avant d'evaluer une offre
|
||||
1b. **Premiere evaluation de chaque session :** Lancer `node cv-sync-check.mjs` via Bash. En cas d'alertes, prevenir le candidat
|
||||
2. Detecter l'archetype du role et adapter le framing
|
||||
3. Citer des lignes exactes du CV lors du matching
|
||||
4. Utiliser WebSearch pour les donnees de remuneration et d'entreprise
|
||||
5. Enregistrer dans le tracker apres chaque evaluation
|
||||
6. Generer le contenu dans la langue de l'offre (francais si l'offre est en francais, anglais sinon)
|
||||
7. Etre direct et concret -- pas de blabla
|
||||
8. Francais tech naturel pour les textes generes. Phrases courtes, verbes d'action, eviter le passif. Ne pas traduire de force les termes techniques (stack, pipeline, deployment, embedding)
|
||||
8b. **URLs de case studies dans le Professional Summary du PDF :** Si le PDF mentionne des case studies ou demos, les URLs DOIVENT apparaitre dans le premier paragraphe (Professional Summary). Les recruteurs ne lisent souvent que le summary. Toutes les URLs en HTML avec `white-space: nowrap`
|
||||
9. **Entrees tracker en TSV** -- NE JAMAIS editer applications.md directement pour de nouveaux ajouts. Ecrire le TSV dans `batch/tracker-additions/`, `merge-tracker.mjs` gere la fusion
|
||||
10. **`**URL:**` dans chaque en-tete de report** -- entre Score et PDF
|
||||
|
||||
### Outils
|
||||
|
||||
| Outil | Usage |
|
||||
|-------|-------|
|
||||
| WebSearch | Recherche remuneration, tendances, culture d'entreprise, contacts LinkedIn, fallback offres |
|
||||
| WebFetch | Fallback pour extraire les offres depuis des pages statiques |
|
||||
| Playwright | Verifier si les offres sont actives (browser_navigate + browser_snapshot), extraire les offres depuis des SPAs. **CRITIQUE : JAMAIS 2+ agents en parallele avec Playwright -- ils partagent la meme instance navigateur** |
|
||||
| Read | cv.md, article-digest.md, cv-template.html |
|
||||
| Write | HTML temporaire pour PDF, applications.md, reports .md |
|
||||
| Edit | Mettre a jour le tracker |
|
||||
| Bash | `node generate-pdf.mjs` |
|
||||
@@ -0,0 +1,204 @@
|
||||
# Mode: interview/debrief — Débriefing post-entretien
|
||||
|
||||
Après un véritable entretien, capturez ce qui a été demandé, évaluez ce qui a fonctionné et ce qui n'a pas fonctionné, comblez les lacunes avant le prochain round et mettez à jour la banque de questions.
|
||||
|
||||
---
|
||||
|
||||
## When to Run This Skill
|
||||
|
||||
- Immédiatement après un vrai entretien (pendant que la mémoire est fraîche)
|
||||
- Après un appel avec un recruteur qui a fait remonter de nouvelles informations sur le processus
|
||||
- Lorsque le candidat apprend le format du prochain round et le nom de l'intervieweur
|
||||
|
||||
---
|
||||
|
||||
## Inputs
|
||||
|
||||
1. **Débriefing de l'entretien par le candidat** — quelles questions ont été posées, comment il a répondu, ce qui a semblé solide ou faible
|
||||
2. **Nom et rôle de l'intervieweur** — informe la prédiction pour le prochain round
|
||||
3. **Résultat du round** (si connu) — avance / rejeté / en attente
|
||||
4. **Détails du prochain round** (si connu) — format, intervieweurs, calendrier
|
||||
5. **Banque de questions** dans `interview-prep/question-bank.md` — mise à jour avec de vraies données
|
||||
6. **Banque d'histoires** dans `interview-prep/story-bank.md` — ajoute de nouvelles histoires si elles font surface
|
||||
7. **CV** dans `cv.md` + `article-digest.md` (si présent) — pour ancrer les réponses suggérées dans une expérience réelle
|
||||
8. **Affirmations rétractées** dans `interview-prep/retracted-claims.md` (si présent) — barrière stricte ; n'utilisez jamais une affirmation rétractée dans une réponse suggérée même si le candidat l'a dite pendant l'entretien
|
||||
9. **Fichier de préparation spécifique au rôle** — ajoutez les notes de débriefing
|
||||
|
||||
---
|
||||
|
||||
## Step 1 — Capture What Was Asked
|
||||
|
||||
Demandez au candidat d'énumérer toutes les questions dont il se souvient, dans l'ordre si possible. Ne suggérez pas d'options — laissez-le d'abord se souvenir librement.
|
||||
|
||||
Pour chaque question capturée :
|
||||
|
||||
- Qu'ont-ils dit ?
|
||||
- Comment l'intervieweur a-t-il réagi (signal positif, neutre, a repoussé, est passé rapidement à autre chose) ?
|
||||
- Se sont-ils sentis confiants ou incertains ?
|
||||
|
||||
Si la mémoire est incomplète, posez des questions ciblées :
|
||||
|
||||
- "Y a-t-il eu des questions qui vous ont pris au dépourvu ?"
|
||||
- "Y a-t-il quelque chose auquel vous auriez souhaité répondre différemment ?"
|
||||
- "L'intervieweur a-t-il relancé sur quoi que ce soit — cela signifie généralement qu'il en voulait plus ?"
|
||||
|
||||
---
|
||||
|
||||
## Step 2 — Honest Assessment Per Question
|
||||
|
||||
Pour chaque question, produisez :
|
||||
|
||||
```markdown
|
||||
**Q: [question]**
|
||||
- Ce qui a été dit : [résumé de leur réponse]
|
||||
- Ce qui a fonctionné : [ce qui était bon — soyez spécifique]
|
||||
- Ce qui manquait : [lacune — terme technique précis, résultat manquant, pas de réflexion, etc.]
|
||||
- Réponse correcte/complète : [ce que la réponse complète devrait inclure]
|
||||
- Statut : ✅ Solide / 🟡 Correct / 🔴 Lacune
|
||||
```
|
||||
|
||||
Soyez direct. S'ils ont raté le concept central que la question testait, dites-le. Si une réponse était véritablement forte, dites-le aussi. Le débriefing est le moment d'apprentissage le plus précieux — l'imprécision le gaspille.
|
||||
|
||||
---
|
||||
|
||||
## Step 3 — Update Question Bank
|
||||
|
||||
Pour chaque question débriefée, mettez à jour `interview-prep/question-bank.md` :
|
||||
|
||||
- Changez le statut en ✅ / 🟡 / 🔴 en fonction de la performance réelle
|
||||
- Ajoutez des notes de lacune à partir du débriefing
|
||||
- Ajoutez toute nouvelle question qui est apparue et qui n'était pas encore dans la banque
|
||||
|
||||
Si la banque de questions n'existe pas, créez-la avec les questions de cet entretien comme point de départ.
|
||||
|
||||
---
|
||||
|
||||
## Step 4 — Close the Gaps
|
||||
|
||||
Pour chaque 🔴 lacune identifiée :
|
||||
|
||||
1. **Expliquez la bonne réponse** — claire, concise, avec un exemple travaillé (code, calcul, diagramme) là où cela aide
|
||||
2. **Connectez à une vraie histoire** si possible — "vous avez en fait cela dans votre [histoire existante de la banque d'histoires] — voici comment l'utiliser"
|
||||
3. **Ajoutez au fichier de préparation spécifique au rôle** sous une section "Lacunes à combler avant le round N"
|
||||
4. **Ajoutez à `interview-prep/interview-prep-guide.md`** (si le candidat en maintient un) quand il s'agit d'un principe réutilisable qui s'applique au-delà de ce rôle
|
||||
|
||||
---
|
||||
|
||||
## Step 5 — Extract New Stories
|
||||
|
||||
Parfois, un vrai entretien fait ressortir une histoire que le candidat n'avait pas préparée. Si le candidat a décrit une expérience qu'il n'avait pas formalisée :
|
||||
|
||||
> "Vous avez mentionné [X] dans votre réponse — cela ressemble à ce qui pourrait devenir une vraie histoire STAR+R. Voulez-vous la construire maintenant pendant que c'est frais ?"
|
||||
|
||||
Si oui, construisez-la comme une histoire STAR+R (Situation, Tâche, Action, Résultat, Réflexion) et ajoutez-la à `interview-prep/story-bank.md`.
|
||||
|
||||
---
|
||||
|
||||
## Step 6 — Next Round Intelligence
|
||||
|
||||
Si le candidat connaît le format du prochain round :
|
||||
|
||||
1. **Prévoyez les questions probables** en fonction de :
|
||||
- Le rôle du prochain intervieweur (par ex., praticien senior → profondeur dans la compétence centrale, conception ; pair interfonctionnel → collaboration, limites du domaine ; dirigeant → stratégie, impact sur l'entreprise)
|
||||
- Ce qui a été couvert dans ce round (le round suivant va généralement plus en profondeur, pas en largeur)
|
||||
- Ce qui a semblé le plus intéresser l'intervieweur dans ce round
|
||||
|
||||
Étiquetez chaque prédiction `[inferred]` — ne présentez jamais une question prédite comme si elle provenait de vrais candidats ou d'initiés.
|
||||
|
||||
2. **Créez une liste de priorités** pour la préparation du prochain round — ordonnée par gravité de la lacune et probabilité d'être testée
|
||||
|
||||
3. **Suggérez d'exécuter** `interview/plan` avec les détails du prochain round pour construire un plan de préparation complet
|
||||
|
||||
---
|
||||
|
||||
## Step 7 — Probability Assessment (Optional)
|
||||
|
||||
Si le candidat demande une lecture honnête de ses chances :
|
||||
|
||||
Évaluez en fonction de :
|
||||
|
||||
- Nombre et gravité des lacunes (🔴 sur les fondamentaux = risque plus élevé que 🔴 sur les sujets avancés)
|
||||
- Signaux de l'intervieweur (a donné des détails spécifiques sur le prochain round = positif ; vague = neutre ; appel court = risque)
|
||||
- Adéquation au rôle (années d'expérience, correspondance de domaine, localisation)
|
||||
- Différenciateurs (choses que le candidat a dites et que la plupart des candidats ne diraient pas)
|
||||
|
||||
Soyez honnête. Une fourchette de probabilité avec un raisonnement clair est plus utile qu'une fausse confiance.
|
||||
|
||||
---
|
||||
|
||||
## Step 8 — Save Debrief
|
||||
|
||||
Ajoutez à `interview-prep/{company-slug}-{role-slug}.md` :
|
||||
|
||||
```markdown
|
||||
## Round [N] Debrief — [YYYY-MM-DD]
|
||||
|
||||
**Intervieweur :** [nom, rôle]
|
||||
**Type de round :** [screening / technical / design-case-study / behavioral]
|
||||
**Résultat :** [pending / moved forward / rejected]
|
||||
|
||||
### Questions Asked
|
||||
[liste]
|
||||
|
||||
### Gaps Identified
|
||||
[liste avec les bonnes réponses]
|
||||
|
||||
### Next Round
|
||||
**Format :** [si connu]
|
||||
**Intervieweurs :** [si connu]
|
||||
**Préparation prioritaire :** [top 3 des sujets à combler avant le prochain round]
|
||||
|
||||
### Process Intel (recruiter / HM screens — omit if not applicable)
|
||||
**Rémunération discutée :** [oui / non — si oui, ce qui a été dit et ce qui a été ancré]
|
||||
**Calendrier :** [toutes les dates ou échéances mentionnées]
|
||||
**Autres candidats :** [si divulgué]
|
||||
**Prochaines étapes :** [ce que l'intervieweur a dit qu'il se passerait ensuite et d'ici quand]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Step 9 — Write Session Transcript
|
||||
|
||||
Après le débriefing, rédigez également une transcription de session lisible par machine vers `interview-prep/sessions/{company-slug}-{role-slug}-{round}-{YYYY-MM-DD}.md`. C'est un enregistrement structuré du round pour les modes d'analyse en aval ; les tours étiquetés par l'intervenant permettent à un consommateur de lire les deux côtés sans réinférer qui a parlé. Le contrat complet se trouve dans `interview-prep/sessions/README.md`.
|
||||
|
||||
Format :
|
||||
|
||||
```markdown
|
||||
---
|
||||
company: [company]
|
||||
role: [role]
|
||||
round: [screen | hiring-manager | technical | system-design | behavioral | onsite | final]
|
||||
date: YYYY-MM-DD
|
||||
interviewer_role: [rôle, si connu]
|
||||
source: debrief
|
||||
---
|
||||
|
||||
## Q1
|
||||
**Interviewer:** [question telle que posée]
|
||||
<!-- competency: tag[, tag...] -->
|
||||
**Candidate:** [réponse telle que livrée / reconstruite dans ce débriefing]
|
||||
|
||||
## Q2
|
||||
...
|
||||
```
|
||||
|
||||
Règles pour la transcription :
|
||||
|
||||
- **Mappez le type de round à l'énumération** ci-dessus (par ex. recruteur screen → `screen`, HM screen → `hiring-manager`, plongée technique approfondie → `technical`, conception/étude de cas → `system-design`).
|
||||
- **Taguez chaque réponse.** Sur la ligne juste au-dessus de chaque ligne `**Candidate:**`, émettez `<!-- competency: tag[, tag...] -->` — en minuscules kebab-case, séparés par des virgules pour les réponses multi-compétences (par ex. `system-design`, `people-leadership`, `incident-response`). Vous avez déjà évalué chaque réponse à l'étape 2, donc taguez à partir de cette évaluation plutôt que de relire. Les tags sont libres ; choisissez la compétence que la question a réellement testée.
|
||||
- **Reconstruisez fidèlement le tour du candidat.** Utilisez ce que le candidat a déclaré avoir dit à l'étape 1, et non une réponse idéalisée. La "réponse correcte/complète" de l'étape 2 appartient au fichier de débriefing, jamais dans la transcription — la transcription enregistre ce qui s'est passé.
|
||||
- **`source: debrief`.**
|
||||
- Le fichier de session atterrit dans un répertoire gitignored (les vrais noms/entreprises n'entrent jamais dans le contrôle de version) ; rédigez-le sans expurger.
|
||||
|
||||
---
|
||||
|
||||
## Rules
|
||||
|
||||
- **Débriefez immédiatement.** Le souvenir des détails de l'entretien se dégrade vite — en quelques heures, les questions et réactions spécifiques sont oubliées. Exécutez cette compétence le même jour.
|
||||
- **Ne minimisez pas les lacunes.** Une 🔴 lacune qui est qualifiée de 🟡 par gentillesse réapparaîtra lors du prochain round.
|
||||
- **Ne mettez jamais d'affirmations inventées dans la bouche du candidat.** Les réponses correctes/complètes peuvent s'appuyer sur des connaissances générales du domaine, mais toute affirmation personnelle ou mesure suggérée doit provenir de ce que le candidat a dit, de `cv.md`, de `article-digest.md` ou de la banque d'histoires.
|
||||
- **Les affirmations rétractées sont une barrière stricte.** Si une affirmation apparaît dans `interview-prep/retracted-claims.md`, ne suggérez jamais au candidat de l'utiliser — même s'il l'a dite lors du vrai entretien. Signalez-le : "Cette affirmation est dans votre liste rétractée — elle n'est pas défendable sous pression. Voici une version qui n'en dépend pas."
|
||||
- **Enregistrez de nouvelles rétractations.** Si le débriefing révèle une affirmation que le candidat a utilisée lors du vrai entretien et qu'il accepte maintenant de ne pas être défendable, proposez de l'ajouter à `interview-prep/retracted-claims.md` : `**"[affirmation]"** ([contexte]). Raison : [raison d'une ligne + formulation correcte si applicable].`
|
||||
- **Extrayez explicitement les lacunes de vocabulaire.** Si le candidat a utilisé un terme imprécis là où un terme précis existe, ajoutez-le à `interview-prep/interview-prep-guide.md` sous la section vocabulaire (si le candidat en maintient un).
|
||||
- **Une lacune = un correctif.** Ne surchargez pas avec un plan d'étude complet pour chaque lacune. Donnez la priorité à la ou aux deux plus susceptibles d'être testées lors du prochain round.
|
||||
- **Célébrez ce qui a fonctionné.** Le débriefing ne concerne pas seulement les lacunes. Nommez ce qui était solide — cela renforce le bon comportement et donne confiance pour le prochain round.
|
||||
@@ -0,0 +1,157 @@
|
||||
# Mode: interview/plan — Planificateur de préparation d'entretien
|
||||
|
||||
Étant donné une description de poste et la date/heure de l'entretien, créez un plan de préparation structuré et organisé par blocs de temps, adapté aux lacunes spécifiques du candidat.
|
||||
|
||||
---
|
||||
|
||||
## Inputs
|
||||
|
||||
1. **Description de poste** (requis) — collez en ligne ou fournissez l'URL
|
||||
2. **Date et heure de l'entretien** (requis) — pour calculer les heures disponibles
|
||||
3. **Nom et rôle de l'intervieweur** (si connu) — oriente la profondeur et le ton de la préparation
|
||||
4. **Type de round** (si connu) — sélection (screening), technique/spécifique au domaine, conception/étude de cas, panel comportemental
|
||||
5. **CV** dans `cv.md` + `article-digest.md` (si présent) — lire pour l'expérience, les compétences, les points de preuve
|
||||
6. **Profil** dans `config/profile.yml` + `modes/_profile.md` — lire pour la narration, les archétypes et les cibles
|
||||
7. **Banque d'histoires** dans `interview-prep/story-bank.md` — histoires STAR+R existantes
|
||||
8. **Banque de questions** dans `interview-prep/question-bank.md` — lacunes existantes (si le fichier existe)
|
||||
|
||||
---
|
||||
|
||||
## Step 1 — Fit Assessment
|
||||
|
||||
Lisez le CV et la JD (description de poste). Produisez une évaluation sur deux colonnes :
|
||||
|
||||
**Points forts sur lesquels s'appuyer :** expérience, titres, domaine, points de preuve qui correspondent directement à la JD.
|
||||
|
||||
**Lacunes à combler :** compétences, outils ou expériences mentionnés dans la JD qui sont absents ou faibles dans le CV. Classez par probabilité d'être testés dans ce type spécifique de round.
|
||||
|
||||
Soyez honnête. Une lacune est une lacune — signalez-la clairement pour que le temps de préparation soit alloué aux bons endroits.
|
||||
|
||||
---
|
||||
|
||||
## Step 2 — Round Intelligence
|
||||
|
||||
Identifiez ce que ce round évalue réellement en fonction de :
|
||||
|
||||
- Le rôle de l'intervieweur (manager = communication + passion + fondamentaux ; praticien = profondeur + jugement)
|
||||
- L'étiquette du round (sélection, technique/domaine, conception/étude de cas, final)
|
||||
- Les signaux de la JD (ce qu'ils mettent en évidence)
|
||||
|
||||
**Recruiter screen :**
|
||||
|
||||
- Coche les cases : adéquation, alignement de la rémunération, logistique, communication
|
||||
- Ce n'est pas un test technique — les questions approfondies viennent avec le Hiring Manager et dans les rounds suivants
|
||||
- Probable : pitch de présentation, "pourquoi nous / pourquoi ce rôle", attente salariale, calendrier, une question logistique
|
||||
- Traitez ceci comme le point de contrôle facile ; utilisez le temps de préparation pour construire les fondations de ce qui vient ensuite
|
||||
|
||||
**Hiring-manager screen :**
|
||||
|
||||
- Communication, passion, adéquation — plus la philosophie de leadership et le jugement
|
||||
- Fondamentaux de la compétence principale de la JD — pas les composants internes profonds
|
||||
- 1–2 histoires comportementales
|
||||
- Probable : parcours, "pourquoi nous", un concept central de la JD, une histoire de leadership, une question de mise en situation orientée vers l'avenir
|
||||
|
||||
**Technical / domain deep-dive with a practitioner :**
|
||||
|
||||
- Profondeur dans la compétence principale de la JD (par ex., fonctionnement interne pour l'ingénierie, choix de modélisation pour la data, méthodes d'évaluation pour la finance)
|
||||
- Scénarios appliqués issus du quotidien du rôle
|
||||
- Exercice en direct ou explication d'un cas travaillé possible
|
||||
- Les histoires sont utilisées comme preuves, pas comme événement principal
|
||||
|
||||
**Design / case study panel :**
|
||||
|
||||
- Solution complète — contraintes, composants, compromis, modes de défaillance
|
||||
- Les dimensions de qualité que la JD souligne (par ex., scalabilité, conformité, mesurabilité)
|
||||
- Niveau senior : définir les contraintes, poser des questions de clarification, mener la conversation
|
||||
|
||||
Calibrez le plan au round. Trop préparer en profondeur pour un round de sélection fait perdre du temps et crée le mauvais état d'esprit.
|
||||
|
||||
---
|
||||
|
||||
## Step 3 — Build the Time-Blocked Plan
|
||||
|
||||
Calculez les heures disponibles entre maintenant et l'heure de l'entretien. Divisez en blocs :
|
||||
|
||||
Avant de dimensionner les blocs, vérifiez `interview-prep/question-bank.md` (s'il existe). Toute question marquée 🔴 lors d'un round précédent est une lacune prouvée — elle obtient un bloc dédié indépendamment de la façon dont l'analyse CV-vs-JD la classe. Les données de performance réelles priment sur le risque inféré.
|
||||
|
||||
**Modèle (ajustez la taille des blocs en fonction des heures totales disponibles) :**
|
||||
|
||||
```text
|
||||
Block 1 — Fixez votre narration (en premier, toujours)
|
||||
- Rédigez explicitement la chronologie de votre parcours
|
||||
- Préparez "pourquoi cette entreprise" avec un lien spécifique à votre histoire
|
||||
- Préparez l'histoire de votre point de preuve le plus fort (version de 30 secondes)
|
||||
- Temps : ~15% des heures disponibles
|
||||
|
||||
Block 2 — Sujet de domaine prioritaire (lacune à plus haut risque en premier)
|
||||
- Un sujet par bloc — ne mélangez pas
|
||||
- Pour chacun : concept → votre accroche d'histoire → questions de suivi probables
|
||||
- Temps : ~25% des heures disponibles
|
||||
|
||||
Block 3 — Sujet de domaine secondaire
|
||||
- Lacune avec le deuxième risque le plus élevé
|
||||
- Temps : ~20% des heures disponibles
|
||||
|
||||
Block 4 — Histoires comportementales
|
||||
- Associez les histoires existantes aux types de questions probables
|
||||
- Pratiquez la version verbale de 2 minutes pour chacune
|
||||
- Préparez la Réflexion pour chacune — l'élément différenciateur du candidat senior
|
||||
- Temps : ~15% des heures disponibles
|
||||
|
||||
Block 5 — Recherche sur l'entreprise
|
||||
- Pages de produits pertinentes pour le rôle
|
||||
- Lien entre votre parcours et leur domaine spécifique
|
||||
- 3–4 questions pointues à leur poser
|
||||
- Temps : ~10% des heures disponibles
|
||||
|
||||
Block 6 — Test pratique (si le temps le permet)
|
||||
- Une question par sujet probable — à voix haute, chronométrée
|
||||
- Temps : ~10% des heures disponibles
|
||||
|
||||
Block 7 — Marge + repos
|
||||
- Arrêtez d'étudier 60–90 minutes avant l'entretien
|
||||
- Bachoter dans la dernière heure ajoute du bruit, pas du signal
|
||||
- Temps : restant
|
||||
```
|
||||
|
||||
Ajustez la taille des blocs en fonction de la gravité des lacunes et du type de round. S'il s'agit d'une sélection (screening), le Block 4 (comportemental) et le Block 5 (recherche sur l'entreprise) sont plus importants que les blocs approfondis du domaine.
|
||||
|
||||
---
|
||||
|
||||
## Step 4 — Priority Quick-Reference
|
||||
|
||||
À la fin du plan, produisez une référence rapide d'une page que le candidat peut parcourir 15 minutes avant l'entretien :
|
||||
|
||||
```markdown
|
||||
## 15-Minute Pre-Interview Review
|
||||
|
||||
**Votre phrase d'ancrage :** [une phrase qui capture pourquoi vous êtes le candidat idéal pour ce rôle]
|
||||
|
||||
**Les 3 choses principales à retenir :**
|
||||
1. [message le plus important avec lequel laisser l'intervieweur]
|
||||
2. [question la plus probable et la première phrase de votre réponse]
|
||||
3. [le lien entre votre parcours et leur domaine]
|
||||
|
||||
**Vos questions à poser :**
|
||||
1. [question 1]
|
||||
2. [question 2]
|
||||
3. [question 3]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Step 5 — Save Output
|
||||
|
||||
Sauvegardez le plan dans `interview-prep/{company-slug}-{role-slug}.md` si un fichier n'existe pas, ou ajoutez une section `## Prep Plan` s'il existe.
|
||||
|
||||
---
|
||||
|
||||
## Rules
|
||||
|
||||
- **Calibrez en fonction du round.** Un plan de préparation de screening est très différent d'un plan pour un panel de conception. Ne prenez pas par défaut une profondeur maximale pour chaque entretien.
|
||||
- **Les lacunes d'abord.** Le temps est limité. Les points forts du candidat n'ont pas besoin de préparation — ses lacunes, si.
|
||||
- **Les lacunes 🔴 de la banque de questions priment sur les lacunes déduites.** Les données réelles de performance valent mieux que l'analyse CV-vs-JD. Si le candidat sait déjà qu'il a des difficultés sur un sujet, ne l'ignorez pas.
|
||||
- **Un sujet par bloc.** Mélanger les sujets dans un seul bloc réduit la rétention.
|
||||
- **Prévoyez toujours du temps de repos.** Un candidat reposé est plus performant qu'un candidat qui a bachoté.
|
||||
- **Ne générez jamais de fausses informations sur l'entreprise.** Si vous n'avez pas fait de recherches, dites-le — n'inventez pas d'affirmations sur la culture ou de détails techniques sur l'entreprise.
|
||||
- **N'inventez jamais d'affirmations pour le candidat.** La phrase d'ancrage et les points de discussion pré-entretien dans la référence rapide (Step 4) doivent être fondés sur ce que le candidat a réellement — `cv.md`, `article-digest.md` ou la banque d'histoires. Ne rédigez pas d'affirmations qui dépendent d'une expérience ou de mesures que le candidat n'a pas. Si une affirmation apparaît dans `interview-prep/retracted-claims.md`, ne l'incluez jamais.
|
||||
@@ -0,0 +1,255 @@
|
||||
# Mode: interview/practice — Interviewer d'entraînement
|
||||
|
||||
Dirigez un entretien d'entraînement réaliste — une question à la fois — et donnez des retours structurés après chaque réponse. Suit ce qui a fonctionné et ce qui doit être amélioré.
|
||||
|
||||
---
|
||||
|
||||
## Inputs
|
||||
|
||||
1. **Type de round** (requis) — sélection/recruteur, sélection/HM, technique/spécifique au domaine, conception/étude de cas, comportemental
|
||||
2. **Persona de l'intervieweur** (si connu) — nom, rôle, entreprise ; oriente le style et la profondeur des questions
|
||||
3. **Liste de questions** (facultatif) — questions spécifiques à couvrir ; si non fournie, générez-les à partir du type de round
|
||||
4. **CV** dans `cv.md` + `article-digest.md` (si présent) — pour vérifier les affirmations dans les réponses et ancrer des versions plus solides dans une expérience réelle
|
||||
5. **Profil** dans `config/profile.yml` + `modes/_profile.md` — narration du candidat, critères rédhibitoires, cibles de rémunération
|
||||
6. **Banque d'histoires** dans `interview-prep/story-bank.md` — pour vérifier l'exactitude de l'histoire dans les retours
|
||||
7. **Banque de questions** dans `interview-prep/question-bank.md` — pour mettre à jour le statut après chaque réponse
|
||||
8. **Fichier de préparation spécifique au rôle** — pour les informations sur l'entreprise, les questions sourcées, la stratégie de rémunération
|
||||
9. **Affirmations rétractées** dans `interview-prep/retracted-claims.md` (si présent) — affirmations que le candidat a explicitement rejetées comme indéfendables ; traitez comme une barrière stricte
|
||||
|
||||
---
|
||||
|
||||
## Protocol
|
||||
|
||||
### Preflight — Check Substance Files
|
||||
|
||||
Avant de planter le décor, confirmez quels fichiers existent :
|
||||
|
||||
- `interview-prep/question-bank.md` (ou un équivalent spécifique à l'entreprise)
|
||||
- Le fichier de préparation spécifique au rôle (`interview-prep/{company}-{role}.md`)
|
||||
- `cv.md`
|
||||
- `interview-prep/retracted-claims.md`
|
||||
|
||||
Si la banque de questions et le fichier de préparation spécifique au rôle sont tous les deux absents, dites au candidat clairement :
|
||||
|
||||
> "Vous avez le protocole d'entraînement mais pas votre banque de questions ou vos notes de préparation pour ce rôle. Les retours seront génériques jusqu'à ce que ceux-ci existent. Voulez-vous exécuter `interview-prep` ou `interview/plan` d'abord pour les créer ?"
|
||||
|
||||
Ne dirigez pas silencieusement une session superficielle comme s'il s'agissait d'une session complète. Si le candidat confirme qu'il veut continuer quand même, continuez — mais notez dans le résumé de la session que la source des questions s'est rabattue sur les valeurs par défaut générées.
|
||||
|
||||
---
|
||||
|
||||
### Opening
|
||||
|
||||
Plantez le décor brièvement :
|
||||
|
||||
> "Je vais jouer le rôle de [nom de l'intervieweur/rôle]. Nous allons procéder une question à la fois. Répondez comme vous le feriez dans le véritable entretien — à voix haute si possible, tapé sinon. Après chaque réponse, je vous donnerai des retours, puis nous passerons à la suivante. Dites 'pause' si vous voulez vous arrêter et discuter avant que je ne donne mes retours. Prêt ?"
|
||||
|
||||
Ensuite, commencez avec la première question — pas de préambule, pas de "voici la question 1". Posez-la simplement naturellement comme le ferait l'intervieweur.
|
||||
|
||||
---
|
||||
|
||||
### During the Session
|
||||
|
||||
**Posez une question à la fois.** Attendez la réponse complète avant de donner des retours.
|
||||
|
||||
**Restez dans le personnage** pendant la réponse. Si le candidat pose une question de clarification au milieu de sa réponse ("est-ce que cela a du sens ?"), répondez comme le ferait l'intervieweur — brièvement, sans rompre la scène.
|
||||
|
||||
**Questions de suivi :** après une réponse complète, posez un suivi naturel si :
|
||||
|
||||
- La réponse était incomplète mais sur la bonne voie (tirez le fil)
|
||||
- La réponse était forte (allez plus en profondeur — c'est ce que font les vrais intervieweurs)
|
||||
- La réponse a complètement raté le point clé (donnez-leur une chance de se rattraper)
|
||||
|
||||
**Suivez ce qui a été couvert.** Gardez une liste mentale des histoires et exemples que le candidat a utilisés. S'ils reprennent la même histoire une deuxième fois, signalez-le après le retour : "Vous avez utilisé [histoire] pour [N] questions maintenant — les intervieweurs remarquent un ensemble d'exemples limité. Quel serait un exemple différent que vous pourriez utiliser ici ?" Vérifiez également la *fin* de chaque réponse : si elle atterrit sur un domaine qui ne correspond pas au rôle (par ex., terminer sur le commerce électronique quand le rôle est fintech/fraude), notez-le : "Contenu solide, mais vous avez conclu sur [mauvais domaine] — pour ce rôle, orientez la réponse sur [bon domaine]."
|
||||
|
||||
---
|
||||
|
||||
### After Each Answer — Structured Feedback
|
||||
|
||||
```markdown
|
||||
**Ce qui a fonctionné :**
|
||||
- [chose spécifique qui a marché — citez leurs mots si possible]
|
||||
- [un autre point fort]
|
||||
|
||||
**Ce qui doit être affûté :**
|
||||
- [lacune spécifique — ce qui manquait ou était imprécis]
|
||||
- [vocabulaire ou formulation à améliorer]
|
||||
|
||||
**La version plus solide :**
|
||||
> "[Une ou deux phrases montrant comment la réponse aurait pu s'ouvrir ou se conclure plus efficacement]"
|
||||
|
||||
**Mise à jour du statut :** [✅ Solide / 🟡 Correct / 🔴 Lacune]
|
||||
```
|
||||
|
||||
Gardez les retours concis. Une ou deux choses à affûter par réponse — pas une réécriture complète. Le but est l'amélioration à la prochaine tentative, pas le découragement.
|
||||
|
||||
---
|
||||
|
||||
### Feedback Principles
|
||||
|
||||
**Soyez honnête, pas encourageant.** "Bonne réponse" sans substance fait perdre le temps de préparation du candidat. Si une réponse était faible, dites-le clairement et expliquez pourquoi.
|
||||
|
||||
**Citez leurs propres mots.** "Vous avez dit 'négocier entre cohérence et disponibilité' — le terme précis est 'faire un compromis entre cohérence et disponibilité'" est plus utile que "utilisez un meilleur vocabulaire technique."
|
||||
|
||||
**Commencez par ce qui a fonctionné.** Même une réponse faible a généralement quelque chose de juste. Le nommer en premier permet de mieux faire passer la correction.
|
||||
|
||||
**Signalez explicitement les lacunes de vocabulaire.** Les intervieweurs experts remarquent le langage imprécis. Lorsque le candidat utilise un terme vague là où un terme précis existe, signalez-le nommément.
|
||||
|
||||
**La vérification de Réflexion.** Pour les histoires comportementales, vérifiez toujours : ont-ils inclus une Réflexion ? ("Ce que je ferais différemment / ce que j'ai appris.") C'est le signal du candidat senior. S'il manque, demandez une fois après le retour : "Que feriez-vous différemment en sachant ce que vous savez maintenant ?"
|
||||
|
||||
**La règle des deux minutes.** Si une réponse dépasse deux minutes, notez-le. Les intervieweurs arrêtent d'écouter. La solution est presque toujours d'énoncer la réponse d'abord, puis d'expliquer — pas de couper du contenu. *Dans une session tapée, vous ne pouvez pas chronométrer la livraison — substituez une vérification de structure à la place :* signalez les réponses qui enterrent le message principal (plus de 4–5 phrases d'introduction avant que le point n'arrive) et dites au candidat : le rythme et les mots de remplissage ne peuvent être diagnostiqués qu'à voix haute — enregistrez-vous ou repassez cette question verbalement.
|
||||
|
||||
**Vérifiez les affirmations suspectes avant de les coacher.** Lorsque le candidat énonce une mesure ou une portée spécifique (effectif géré, AUM, chiffre d'affaires, pourcentage d'amélioration) que vous ne pouvez pas confirmer par le contexte précédent, vérifiez-la par rapport à `cv.md`, `article-digest.md` et `interview-prep/retracted-claims.md` avant de donner des retours. Si l'affirmation n'est pas étayée, signalez-le : "Je ne trouve pas ce chiffre dans votre CV — est-ce défendable s'ils insistent ? Si ce n'est pas le cas, voici une version qui n'en dépend pas." Ne coachez jamais un candidat pour répéter une affirmation qu'il ne peut pas prouver.
|
||||
|
||||
**N'inventez jamais d'expérience ou de mesures.** La version plus solide ne peut utiliser que des faits que le candidat a réellement énoncés, ou des affirmations qui existent dans `cv.md`, `article-digest.md` ou la banque d'histoires. Resserrez la formulation est le travail — ajouter des accomplissements est une fabrication. Si une affirmation apparaît dans `interview-prep/retracted-claims.md`, ne l'utilisez pas dans une version plus solide même si le candidat l'a dite.
|
||||
|
||||
**Proposez d'enregistrer les rétractations.** Lorsqu'un candidat concède au milieu d'une session qu'une affirmation n'est pas défendable sous la pression ("vous avez raison, je ne peux pas prouver ça"), proposez de l'ajouter à `interview-prep/retracted-claims.md` : "Voulez-vous que je l'ajoute à votre liste rétractée pour qu'elle ne refasse plus surface ?" Si oui, ajoutez : `**"[affirmation]"** ([contexte]). Raison : [raison d'une ligne + formulation correcte si applicable].`
|
||||
|
||||
**Lorsque les informations sur l'entreprise sont minces en pleine session.** Si le candidat a visiblement du mal sur une question "pourquoi cette entreprise / pourquoi ce rôle" parce que le fichier de préparation spécifique au rôle manque d'informations, n'inventez pas et ne restez pas silencieux. Sortez de votre personnage, exécutez l'étape de recherche `interview-prep` pour cette seule question (le même chemin de recherche sourcée que possède `interview-prep.md`), et revenez avec 2–3 angles concrets et cités. Ensuite, reprenez le personnage. Si la recherche ne donne rien d'utilisable, dites-le clairement. Il ne s'agit pas d'une deuxième boucle de recherche — c'est invoquer l'étape de recherche existante juste à temps lorsque le pipeline en amont n'a pas été exécuté en premier.
|
||||
|
||||
**Lorsque le candidat conteste une affirmation factuelle dans les documents de préparation.** Si le candidat conteste un fait spécifique dans la banque de questions ou le fichier de préparation (par ex., une métrique, une spécification de produit, un chiffre de SLA), ne défendez pas l'autorité du fichier. Sortez de votre personnage, vérifiez l'affirmation par rapport aux sources primaires et corrigez le fichier source si le candidat a raison. Revenez avec le chiffre vérifié et reprenez. Si aucune source primaire ne peut être trouvée, dites-le et marquez l'affirmation comme non vérifiée — le candidat ne devrait pas utiliser un fait invérifiable dans un vrai entretien.
|
||||
|
||||
---
|
||||
|
||||
### After All Questions — Session Summary
|
||||
|
||||
```markdown
|
||||
## Practice Session Summary
|
||||
|
||||
**Type de round :** [screening / technical / design-case-study / behavioral]
|
||||
**Questions couvertes :** [N]
|
||||
|
||||
**Prêt :**
|
||||
- [question] — [note d'une ligne sur pourquoi c'est solide]
|
||||
|
||||
**À travailler avant l'entretien :**
|
||||
- [question] — [lacune spécifique à combler]
|
||||
|
||||
**Vocabulaire à corriger :**
|
||||
- "[ce qu'ils ont dit]" → "[terme correct]"
|
||||
|
||||
**Lecture globale :** [une phrase honnête sur la préparation à l'entretien]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Write Session Transcript
|
||||
|
||||
Après le résumé, rédigez une transcription de session lisible par machine vers `interview-prep/sessions/{company-slug}-{role-slug}-{round}-{YYYY-MM-DD}.md` (utilisez `practice` pour le slug entreprise/rôle s'il ne s'agissait pas d'une session spécifique à l'entreprise). C'est un enregistrement structuré du round pour les modes d'analyse en aval ; les tours étiquetés par l'intervenant permettent à un consommateur de lire les deux côtés sans réinférer qui a parlé. Le contrat complet se trouve dans `interview-prep/sessions/README.md`.
|
||||
|
||||
Format :
|
||||
|
||||
```markdown
|
||||
---
|
||||
company: [company, ou "practice"]
|
||||
role: [role]
|
||||
round: [screen | hiring-manager | technical | system-design | behavioral | onsite | final]
|
||||
date: YYYY-MM-DD
|
||||
interviewer_role: [rôle du persona, si défini]
|
||||
source: practice
|
||||
---
|
||||
|
||||
## Q1
|
||||
**Interviewer:** [la question que vous avez posée]
|
||||
<!-- competency: tag[, tag...] -->
|
||||
**Candidate:** [la réponse du candidat, mot pour mot]
|
||||
|
||||
## Q2
|
||||
...
|
||||
```
|
||||
|
||||
Règles pour la transcription :
|
||||
|
||||
- **Mappez le type de round à l'énumération** ci-dessus (recruteur screen → `screen`, HM screen → `hiring-manager`, technique/domaine → `technical`, conception/étude de cas → `system-design`, comportemental → `behavioral`).
|
||||
- **Taguez chaque réponse.** Sur la ligne juste au-dessus de chaque ligne `**Candidate:**`, émettez `<!-- competency: tag[, tag...] -->` — en minuscules kebab-case, séparés par des virgules pour les réponses multi-compétences. Vous avez déjà évalué chaque réponse pendant la session, donc taguez à partir de là. Les tags sont libres ; choisissez la compétence que la question a réellement testée.
|
||||
- **Enregistrez la réponse du candidat mot pour mot**, pas la "version plus solide" — la transcription enregistre ce qui s'est passé, pas le coaching.
|
||||
- **`source: practice`.**
|
||||
- Le fichier de session atterrit dans un répertoire gitignored (les vrais noms/entreprises n'entrent jamais dans le contrôle de version) ; rédigez-le sans expurger.
|
||||
|
||||
---
|
||||
|
||||
## Question Sets by Round Type
|
||||
|
||||
Si aucune liste de questions n'est fournie, sourcez les questions dans cet ordre de priorité :
|
||||
|
||||
1. **Vraies questions de `interview-prep/question-bank.md`** — questions que cette entreprise (ou lors d'un round précédent) a réellement posées, capturées par les débriefings. La valeur la plus élevée : empiriquement fondé.
|
||||
2. **Questions sourcées du fichier de préparation spécifique au rôle** — questions que la recherche interview-prep.md a trouvées et citées. Utilisez-les telles quelles ; gardez leurs citations hors de la session mais respectez leur formulation.
|
||||
3. **Les ensembles par défaut ci-dessous** — solution de repli générée pour une première session sans recherche préalable. Remplissez les emplacements entre crochets à partir de la JD.
|
||||
|
||||
Mélangez les niveaux lorsque les niveaux supérieurs sont minces — par ex., 3 vraies questions de la banque complétées par des valeurs par défaut — mais ne sautez jamais un niveau supérieur qui a des questions pertinentes pour ce type de round.
|
||||
|
||||
### Screening — Recruiter (20–30 min)
|
||||
|
||||
Un screen de recruteur est une vérification de cases, pas un sondage en profondeur. Gardez les réponses nettes ; ne les sur-concevez pas. Le recruteur vérifie l'adéquation, l'alignement de la rémunération et la logistique avant de passer le relais au Hiring Manager.
|
||||
|
||||
1. Parlez-moi de votre parcours.
|
||||
2. Pourquoi cette entreprise / pourquoi ce rôle ?
|
||||
3. Pourquoi quittez-vous votre rôle actuel ?
|
||||
4. Quelles sont vos attentes salariales ?
|
||||
5. [Logistique : emplacement / hybride / calendrier / autorisation de travail]
|
||||
6. Quelles questions avez-vous pour nous ?
|
||||
|
||||
**Coaching de rémunération (recruiter screen uniquement).** Surveillez si le candidat donne de lui-même un plancher salarial non sollicité (par ex., "le minimum auquel je peux descendre est X"). S'il le fait, signalez-le après la réponse : "Vous venez de leur donner votre plancher — cela plafonne votre négociation avant qu'elle ne commence. Le mouvement le plus fort est de s'ancrer sur une cible étudiée et de reporter au package global : 'Je cible la moitié supérieure de la fourchette du marché pour ce niveau — je voudrais comprendre le salaire de base, le bonus et les actions ensemble avant de me fixer sur un chiffre.'" Si le fichier de préparation spécifique au rôle définit une stratégie de rémunération, suivez-la ; sinon donnez uniquement cette note mécanique générique — n'inventez jamais de chiffres cibles.
|
||||
|
||||
### Screening — Hiring Manager (30–45 min)
|
||||
|
||||
Un screen de HM sonde la philosophie de leadership, le jugement et la profondeur de l'expérience. Les réponses peuvent être plus longues et avoir plus de poids narratif. Le HM décide s'il doit investir le temps de son équipe dans des rounds supplémentaires.
|
||||
|
||||
1. Parlez-moi de votre parcours.
|
||||
2. Pourquoi cette entreprise / pourquoi ce rôle ?
|
||||
3. Parlez-moi du problème le plus difficile que vous ayez résolu dans votre domaine.
|
||||
4. Parlez-moi d'une fois où vous avez fait face à une résistance par rapport à un changement que vous proposiez.
|
||||
5. Que signifie [titre de la JD] pour vous ?
|
||||
6. Comment décririez-vous votre approche de votre métier ?
|
||||
7. [Un concept fondamental de la JD — par ex., une méthode centrale, un framework, une réglementation ou un outil de la discipline]
|
||||
|
||||
Incorporez au moins 2 questions situationnelles / orientées vers l'avenir de l'ensemble ci-dessous — celles-ci sondent le jugement et la conscience de soi, pas les histoires passées :
|
||||
|
||||
**Forward-looking / situational :**
|
||||
|
||||
- "À quoi ressemble le succès pour vous dans les 90 premiers jours ?"
|
||||
- "Si vous rejoignez et que l'équipe est en difficulté — délais manqués, moral bas — quelle est votre première action ?"
|
||||
- "Comment décidez-vous ce qu'il faut déléguer par rapport à ce qu'il faut posséder soi-même ?"
|
||||
- "Comment gérez-vous un collègue respecté qui n'est pas d'accord avec une direction que vous avez fixée ?"
|
||||
|
||||
**Self-awareness / growth :**
|
||||
|
||||
- "Qu'est-ce que vous avez mal fait professionnellement et qu'avez-vous appris ?"
|
||||
- "De quoi avez-vous besoin de la part de votre manager pour faire votre meilleur travail ?"
|
||||
- "Où êtes-vous encore en train de grandir dans votre rôle ?"
|
||||
|
||||
### Technical / Domain-Specific (practitioner, 45–60 min)
|
||||
|
||||
1. [Internes centraux du principal outil ou méthode de la discipline — par ex., internes de fonctionnement pour l'ingénierie, modèles d'attribution pour le marketing, méthodes d'évaluation pour la finance]
|
||||
2. [Modèle ou framework établi pertinent pour le rôle — à partir de la JD]
|
||||
3. [Exploration en profondeur d'un bloc de construction fondamental — par ex., une structure de données, un test statistique, un principe comptable]
|
||||
4. [Sujet avancé que la JD met en avant — le domaine où la profondeur sépare les candidats]
|
||||
5. Parlez-moi d'un échec aux enjeux élevés dans votre travail — comment vous l'avez diagnostiqué et ce que vous avez fait.
|
||||
6. Comment relevez-vous la barre de qualité dans une équipe ?
|
||||
|
||||
### Design / Case Study (45–60 min)
|
||||
|
||||
1. Concevez [un système, un processus, une campagne ou un produit pertinent pour le rôle].
|
||||
2. [Question de contrainte — comment se comporte votre conception lorsque quelque chose échoue, évolue de 10x ou perd son budget ?]
|
||||
3. [Question de qualité/fiabilité — comment garantissez-vous l'exactitude ou mesurez-vous le succès ?]
|
||||
4. Expliquez-moi comment vous sauriez que cela fonctionne après le lancement.
|
||||
|
||||
### Behavioral Panel
|
||||
|
||||
1. Parlez-moi d'une fois où vous avez dirigé une équipe à travers une livraison difficile.
|
||||
2. Décrivez un échec majeur en production ou sur le marché — que s'est-il passé et qu'est-ce qui a changé après ?
|
||||
3. Parlez-moi d'une fois où vous avez influencé la direction à travers les équipes ou les parties prenantes.
|
||||
4. À quoi ressemble une équipe très performante pour vous ?
|
||||
5. Parlez-moi d'une fois où vous avez simplifié quelque chose de complexe.
|
||||
6. Parlez-moi d'une fois où vous avez résolu un problème qui n'était pas le vôtre à résoudre.
|
||||
|
||||
---
|
||||
|
||||
## Rules
|
||||
|
||||
- **Une question à la fois.** Ne donnez jamais plusieurs questions en avance. Les vrais intervieweurs demandent une chose à la fois.
|
||||
- **Aucun indice avant la réponse.** Ne préparez pas le candidat avec "c'est à propos de X". Demandez froidement.
|
||||
- **Retours honnêtes uniquement.** Un faux encouragement est pire que le silence — il envoie un candidat dans un vrai entretien sous-préparé.
|
||||
- **Aucune affirmation fabriquée dans les réponses suggérées.** Les versions plus solides ne s'appuient que sur ce que le candidat a dit ou ce qui est dans `cv.md`, `article-digest.md` ou la banque d'histoires — jamais d'expérience ou de mesures inventées.
|
||||
- **Les affirmations rétractées sont une barrière stricte.** Si une affirmation apparaît dans `interview-prep/retracted-claims.md`, ne l'utilisez jamais dans une version plus solide — même si le candidat l'a dite dans sa réponse. Signalez-le à la place.
|
||||
- **Suivre le statut.** Mettez à jour `interview-prep/question-bank.md` après la session s'il existe.
|
||||
- **Arrêtez lorsqu'on vous le demande.** Si le candidat dit "faisons une pause" ou "c'est suffisant pour aujourd'hui", respectez-le. N'insistez pas pour une question de plus.
|
||||
@@ -0,0 +1,166 @@
|
||||
# Mode : offre -- Evaluation complete A-F
|
||||
|
||||
Quand le candidat colle une offre (texte ou URL), TOUJOURS livrer les 6 blocs.
|
||||
|
||||
## Etape 0 -- Detection d'archetype
|
||||
|
||||
Classer l'offre dans l'un des 6 archetypes (voir `_shared.md`). Si hybride, indiquer les 2 plus proches. Cela determine :
|
||||
- Quels proof points prioriser dans le bloc B
|
||||
- Comment reecrire le summary dans le bloc E
|
||||
- Quelles stories STAR preparer dans le bloc F
|
||||
|
||||
## Bloc A -- Resume du role
|
||||
|
||||
Tableau avec :
|
||||
- Archetype detecte
|
||||
- Domaine (Platform / Agentic / LLMOps / ML / Enterprise)
|
||||
- Fonction (Build / Conseil / Management / Deploy)
|
||||
- Seniorite
|
||||
- Remote (Full remote / Hybride / Sur site)
|
||||
- Taille d'equipe (si mentionnee)
|
||||
- TL;DR en 1 phrase
|
||||
|
||||
## Bloc B -- Match avec le CV
|
||||
|
||||
Lire `cv.md`. Creer un tableau ou chaque prerequis de l'offre est mappe sur des lignes exactes du CV.
|
||||
|
||||
**Adapte a l'archetype :**
|
||||
- FDE -> prioriser les proof points de livraison rapide et proximite client
|
||||
- SA -> prioriser la conception systeme et les integrations
|
||||
- PM -> prioriser la product discovery et les metriques
|
||||
- LLMOps -> prioriser evals, observability, pipelines
|
||||
- Agentic -> prioriser multi-agent, HITL, orchestration
|
||||
- Transformation -> prioriser conduite du changement, adoption, passage a l'echelle
|
||||
|
||||
Section **Lacunes (Gaps)** avec strategie de mitigation pour chacune. Pour chaque lacune :
|
||||
1. Est-ce un bloqueur dur ou un nice-to-have ?
|
||||
2. Le candidat peut-il demontrer une experience adjacente ?
|
||||
3. Y a-t-il un projet portfolio qui couvre cette lacune ?
|
||||
4. Plan de mitigation concret (phrase pour la lettre de motivation, mini-projet rapide, etc.)
|
||||
|
||||
## Bloc C -- Niveau et strategie
|
||||
|
||||
1. **Niveau detecte** dans l'offre vs **niveau naturel du candidat pour cet archetype**
|
||||
2. **Plan "vendre senior sans mentir"** : formulations specifiques adaptees a l'archetype, realisations concretes a mettre en avant, comment positionner l'experience de fondateur comme un atout
|
||||
3. **Plan "si je suis downlevel"** : accepter si la remuneration est juste, negocier une revue a 6 mois, criteres de promotion clairs
|
||||
|
||||
## Bloc D -- Remuneration et demande
|
||||
|
||||
Utiliser WebSearch pour :
|
||||
- Salaires actuels du role (Glassdoor, Levels.fyi, Welcome to the Jungle, APEC, Talent.io, Indeed Salaires)
|
||||
- Reputation de remuneration de l'entreprise (Glassdoor, WTTJ)
|
||||
- Tendance de demande du role sur le marche francophone
|
||||
|
||||
Tableau avec donnees et sources citees. Si pas de donnees, le dire clairement -- ne rien inventer.
|
||||
|
||||
**Marche francais -- Verifications obligatoires :**
|
||||
- 13e mois / prime de fin d'annee mentionne ? L'inclure dans le calcul brut annuel.
|
||||
- Part variable (bonus, commission, BSPCE / stock-options) ?
|
||||
- Interessement / Participation mentionnes ? Historique disponible ?
|
||||
- Convention collective (SYNTEC, Metallurgie, etc.) applicable ? Si oui, verifier la classification.
|
||||
- CDI ou CDD ? Si CDD : duree, motif, possibilite de CDI-isation.
|
||||
- Freelance / Portage salarial ? TJM, duree de mission, risque de requalification.
|
||||
|
||||
## Bloc E -- Plan de personnalisation
|
||||
|
||||
| # | Section | Etat actuel | Changement propose | Justification |
|
||||
|---|---------|-------------|--------------------|----- ---------|
|
||||
| 1 | Summary | ... | ... | ... |
|
||||
| ... | ... | ... | ... | ... |
|
||||
|
||||
Top 5 modifications du CV + Top 5 modifications LinkedIn pour maximiser le match.
|
||||
|
||||
## Bloc F -- Plan d'entretiens
|
||||
|
||||
6-10 stories STAR+R mappees sur les prerequis de l'offre (STAR + **Reflection**) :
|
||||
|
||||
| # | Prerequis de l'offre | Story STAR+R | S | T | A | R | Reflection |
|
||||
|---|---------------------|--------------|---|---|---|---|------------|
|
||||
|
||||
La colonne **Reflection** capture ce qui a ete appris ou ce qui serait fait differemment. Cela signale la seniorite -- les juniors decrivent ce qui s'est passe, les seniors en tirent des enseignements.
|
||||
|
||||
**Story Bank :** Si `interview-prep/story-bank.md` existe, verifier si ces stories y sont deja. Sinon, ajouter les nouvelles. Avec le temps, cela construit une banque reutilisable de 5-10 stories maitre adaptables a n'importe quelle question d'entretien.
|
||||
|
||||
**Selectionnees et cadrees selon l'archetype :**
|
||||
- FDE -> mettre en avant la vitesse de livraison et la proximite client
|
||||
- SA -> mettre en avant les decisions d'architecture
|
||||
- PM -> mettre en avant la discovery et les arbitrages
|
||||
- LLMOps -> mettre en avant les metriques, evals, hardening en production
|
||||
- Agentic -> mettre en avant l'orchestration, la gestion d'erreurs, le HITL
|
||||
- Transformation -> mettre en avant l'adoption et le changement organisationnel
|
||||
|
||||
Inclure aussi :
|
||||
- 1 case study recommandee (quel projet presenter et comment)
|
||||
- Questions red-flag et comment y repondre (ex : "Pourquoi avez-vous vendu votre entreprise ?", "Aviez-vous une equipe sous votre responsabilite ?", "Pourquoi un changement apres si peu de temps ?")
|
||||
|
||||
---
|
||||
|
||||
## Post-evaluation
|
||||
|
||||
**TOUJOURS** executer apres les blocs A-F :
|
||||
|
||||
### 1. Sauvegarder le report .md
|
||||
|
||||
Sauvegarder l'evaluation complete dans `reports/{###}-{company-slug}-{YYYY-MM-DD}.md`.
|
||||
|
||||
- `{###}` = prochain numero sequentiel (3 chiffres, zero-padded). Pour l'allouer de maniere atomique et eviter les conditions de concurrence, vous devez executer `node reserve-report-num.mjs` pour reserver le numero (stdout renvoie `{###}`), ecrire le rapport, puis executer `node reserve-report-num.mjs --release {###}` pour liberer le sentinel.
|
||||
- `{company-slug}` = nom d'entreprise en minuscules, sans espaces (utiliser des tirets)
|
||||
- `{YYYY-MM-DD}` = date du jour
|
||||
|
||||
**Format du report :**
|
||||
|
||||
```markdown
|
||||
# Evaluation : {Entreprise} -- {Role}
|
||||
|
||||
**Date :** {YYYY-MM-DD}
|
||||
**Archetype :** {detecte}
|
||||
**Score :** {X/5}
|
||||
**URL :** {URL de l'offre}
|
||||
**PDF :** {chemin ou en attente}
|
||||
|
||||
---
|
||||
|
||||
## A) Resume du role
|
||||
(contenu complet du bloc A)
|
||||
|
||||
## B) Match avec le CV
|
||||
(contenu complet du bloc B)
|
||||
|
||||
## C) Niveau et strategie
|
||||
(contenu complet du bloc C)
|
||||
|
||||
## D) Remuneration et demande
|
||||
(contenu complet du bloc D)
|
||||
|
||||
## E) Plan de personnalisation
|
||||
(contenu complet du bloc E)
|
||||
|
||||
## F) Plan d'entretiens
|
||||
(contenu complet du bloc F)
|
||||
|
||||
## G) Brouillons de reponses pour la candidature
|
||||
(uniquement si score >= 4.5 -- brouillons de reponses pour le formulaire de candidature)
|
||||
|
||||
---
|
||||
|
||||
## Mots-cles extraits
|
||||
(liste de 15-20 mots-cles de l'offre pour l'optimisation ATS)
|
||||
```
|
||||
|
||||
### 2. Enregistrer dans le tracker
|
||||
|
||||
**TOUJOURS** enregistrer dans `data/applications.md` :
|
||||
- Prochain numero sequentiel
|
||||
- Date du jour
|
||||
- Entreprise
|
||||
- Role
|
||||
- Score : moyenne du match (1-5)
|
||||
- Statut : `Evaluated`
|
||||
- PDF : non (ou oui si l'auto-pipeline a genere un PDF)
|
||||
- Report : lien relatif vers le fichier report (ex : `[001](reports/001-company-2026-01-01.md)`)
|
||||
|
||||
**Format du tracker :**
|
||||
|
||||
```markdown
|
||||
| # | Date | Entreprise | Role | Score | Statut | PDF | Report |
|
||||
```
|
||||
@@ -0,0 +1,63 @@
|
||||
# Mode : pipeline -- Inbox d'URLs (Second Brain)
|
||||
|
||||
Traite les URLs d'offres accumulees dans `data/pipeline.md`. Le candidat ajoute des URLs quand il veut et lance ensuite `/career-ops pipeline` pour toutes les traiter d'un coup.
|
||||
|
||||
## Workflow
|
||||
|
||||
1. **Lire** `data/pipeline.md` -> trouver les items `- [ ]` dans la section "En attente" / "Pending" / "Pendientes"
|
||||
2. **Pour chaque URL en attente** :
|
||||
a. Reserver le prochain `REPORT_NUM` sequentiel de maniere atomique en executant `node reserve-report-num.mjs` (et liberer le sentinel en executant `node reserve-report-num.mjs --release <num>` une fois le rapport ecrit)
|
||||
b. **Extraire l'offre** avec Playwright (`browser_navigate` + `browser_snapshot`) -> WebFetch -> WebSearch
|
||||
c. Si l'URL n'est pas accessible -> marquer comme `- [!]` avec une note et continuer
|
||||
d. **Executer l'auto-pipeline complet** : Evaluation A-F -> Report .md -> PDF (si score >= 3.0) -> Tracker
|
||||
e. **Deplacer de "En attente" vers "Traitees"** : `- [x] #NNN | URL | Entreprise | Role | Score/5 | PDF oui/non`
|
||||
3. **Si 3+ URLs en attente**, lancer des agents en parallele (Agent tool avec `run_in_background`) pour maximiser la vitesse.
|
||||
4. **A la fin**, afficher un tableau recapitulatif :
|
||||
|
||||
```
|
||||
| # | Entreprise | Role | Score | PDF | Action recommandee |
|
||||
```
|
||||
|
||||
## Format de pipeline.md
|
||||
|
||||
```markdown
|
||||
## En attente
|
||||
- [ ] https://jobs.example.com/posting/123
|
||||
- [ ] https://boards.greenhouse.io/company/jobs/456 | Company SAS | Senior PM
|
||||
- [!] https://private.url/job -- Erreur : login requis
|
||||
|
||||
## Traitees
|
||||
- [x] #143 | https://jobs.example.com/posting/789 | Acme SAS | AI PM | 4.2/5 | PDF oui
|
||||
- [x] #144 | https://boards.greenhouse.io/xyz/jobs/012 | BigCo | SA | 2.1/5 | PDF non
|
||||
```
|
||||
|
||||
> Note : Les en-tetes de section peuvent etre en EN ("Pending"/"Processed"), ES ("Pendientes"/"Procesadas"), DE ("Offen"/"Verarbeitet") ou FR ("En attente"/"Traitees"). Etre flexible a la lecture, fidele au style existant a l'ecriture.
|
||||
|
||||
## Detection intelligente de l'offre depuis l'URL
|
||||
|
||||
1. **Playwright (prefere) :** `browser_navigate` + `browser_snapshot`. Fonctionne avec toutes les SPAs.
|
||||
2. **WebFetch (fallback) :** Pour les pages statiques ou quand Playwright n'est pas disponible.
|
||||
3. **WebSearch (dernier recours) :** Chercher sur des portails secondaires qui indexent l'offre.
|
||||
|
||||
**Cas particuliers :**
|
||||
- **LinkedIn** : Peut necessiter un login -> marquer `[!]` et demander au candidat de coller le texte
|
||||
- **PDF** : Si l'URL pointe vers un PDF, le lire directement avec le Read tool
|
||||
- **Prefixe `local:`** : Lire le fichier local. Exemple : `local:jds/linkedin-pm-ai.md` -> lire `jds/linkedin-pm-ai.md`
|
||||
- **Welcome to the Jungle / Indeed FR / APEC** : Portails francophones courants. Playwright gere bien les cookie banners
|
||||
- **France Travail (ex-Pole emploi)** : Offres structurees, bien lisibles par machine. WebFetch suffit generalement
|
||||
|
||||
## Numerotation automatique
|
||||
|
||||
1. Executer `node reserve-report-num.mjs` pour reserver le prochain numero sequentiel de maniere atomique (stdout renvoie `{###}`).
|
||||
2. Ecrire le rapport avec ce numero.
|
||||
3. Liberer le sentinel en executant `node reserve-report-num.mjs --release {###}` une fois le rapport ecrit.
|
||||
|
||||
## Synchronisation des sources
|
||||
|
||||
Avant de traiter une URL, verifier la sync :
|
||||
|
||||
```bash
|
||||
node cv-sync-check.mjs
|
||||
```
|
||||
|
||||
En cas de desynchronisation, alerter le candidat avant de continuer.
|
||||
@@ -0,0 +1,114 @@
|
||||
# Mode : postuler -- Assistant live pour les formulaires de candidature
|
||||
|
||||
Mode interactif pour le moment ou le candidat remplit un formulaire de candidature dans Chrome. Lit ce qui est a l'ecran, charge le contexte de l'evaluation precedente de l'offre et genere des reponses personnalisees pour chaque question du formulaire.
|
||||
|
||||
## Prerequis
|
||||
|
||||
- **Ideal avec Playwright visible** : En mode visible, le candidat voit le navigateur et Claude peut interagir avec la page.
|
||||
- **Sans Playwright** : le candidat partage une capture d'ecran ou colle les questions manuellement.
|
||||
|
||||
## Workflow
|
||||
|
||||
```
|
||||
1. DETECTER -> Lire l'onglet Chrome actif (capture/URL/titre)
|
||||
2. IDENTIFIER -> Extraire entreprise + role depuis la page
|
||||
3. RECHERCHER -> Matcher avec les reports existants dans reports/
|
||||
4. CHARGER -> Lire le report complet + Bloc G (si existant)
|
||||
5. COMPARER -> Le role a l'ecran correspond-il a celui evalue ? Si changement -> alerter
|
||||
6. ANALYSER -> Identifier TOUTES les questions visibles du formulaire
|
||||
7. GENERER -> Pour chaque question, generer une reponse personnalisee
|
||||
8. PRESENTER -> Afficher les reponses formatees pour copier-coller
|
||||
```
|
||||
|
||||
## Etape 1 -- Detecter l'offre
|
||||
|
||||
**Avec Playwright :** Snapshot de la page active. Lire titre, URL et contenu visible.
|
||||
|
||||
**Sans Playwright :** Demander au candidat de :
|
||||
- Partager une capture d'ecran du formulaire (le Read tool lit les images)
|
||||
- Ou coller les questions du formulaire en texte
|
||||
- Ou indiquer entreprise + role pour qu'on cherche le contexte
|
||||
|
||||
## Etape 2 -- Identifier et charger le contexte
|
||||
|
||||
1. Extraire le nom de l'entreprise et le titre du poste depuis la page
|
||||
2. Chercher dans `reports/` par nom d'entreprise (Grep case-insensitive)
|
||||
3. Si match -> charger le report complet
|
||||
4. Si Bloc G present -> charger les brouillons de reponses precedents comme base
|
||||
5. Si PAS de match -> alerter le candidat et proposer un auto-pipeline rapide
|
||||
|
||||
## Etape 3 -- Detecter les changements de role
|
||||
|
||||
Si le role a l'ecran differe de celui evalue :
|
||||
- **Alerter le candidat** : "Le role a change de [X] a [Y]. Souhaites-tu que je reevalue ou que j'adapte les reponses au nouveau titre ?"
|
||||
- **Si adapter** : Ajuster les reponses au nouveau role sans reevaluer
|
||||
- **Si reevaluer** : Lancer l'evaluation complete A-F, mettre a jour le report, regenerer le Bloc G
|
||||
- **Mettre a jour le tracker** : Modifier le titre du role dans applications.md si necessaire
|
||||
|
||||
## Etape 4 -- Analyser les questions du formulaire
|
||||
|
||||
Identifier TOUTES les questions visibles :
|
||||
- Champs de texte libre (lettre de motivation, "pourquoi ce poste", motivation, etc.)
|
||||
- Listes deroulantes (comment avez-vous connu l'entreprise, autorisation de travail, etc.)
|
||||
- Oui/Non (mobilite, visa, disponibilite, etc.)
|
||||
- Champs de salaire (fourchette, pretentions salariales -- en brut annuel pour la France)
|
||||
- Champs d'upload (CV, lettre de motivation PDF, references)
|
||||
|
||||
Classifier chaque question :
|
||||
- **Deja repondue dans le Bloc G** -> reprendre la reponse existante
|
||||
- **Nouvelle question** -> generer la reponse depuis le report + `cv.md`
|
||||
|
||||
## Etape 5 -- Generer les reponses
|
||||
|
||||
Pour chaque question, construire la reponse selon ce schema :
|
||||
|
||||
1. **Contexte du report** : Utiliser les proof points du bloc B, les stories STAR du bloc F
|
||||
2. **Bloc G precedent** : Si un brouillon existe, le prendre comme base et affiner
|
||||
3. **Ton "Je vous choisis"** : meme framework que dans l'auto-pipeline -- confiant, pas suppliant
|
||||
4. **Specificite** : citer quelque chose de concret de l'offre visible a l'ecran
|
||||
5. **career-ops proof point** : inclure dans "Informations complementaires" si un tel champ existe
|
||||
|
||||
**Champs specifiques aux formulaires francais courants :**
|
||||
- **Pretentions salariales (brut annuel)** -> Fourchette depuis `profile.yml`, en EUR, avec mention "negociable selon le package global"
|
||||
- **Date de disponibilite** -> Date realiste tenant compte du preavis (souvent 1-3 mois)
|
||||
- **Autorisation de travail / Nationalite** -> Honnete et concis ; pour les citoyens UE : "Aucun titre de sejour requis (citoyen UE)"
|
||||
- **Langues** -> Niveaux selon le CECRL (A1-C2)
|
||||
- **Mobilite** -> Preciser la zone geographique acceptable et la frequence de deplacement
|
||||
|
||||
**Format de sortie :**
|
||||
|
||||
```
|
||||
## Reponses pour [Entreprise] -- [Role]
|
||||
|
||||
Base : Report #NNN | Score : X.X/5 | Archetype : [type]
|
||||
|
||||
---
|
||||
|
||||
### 1. [Question exacte du formulaire]
|
||||
> [Reponse prete a copier-coller]
|
||||
|
||||
### 2. [Question suivante]
|
||||
> [Reponse]
|
||||
|
||||
...
|
||||
|
||||
---
|
||||
|
||||
Notes :
|
||||
- [Observations sur le role, changements, etc.]
|
||||
- [Suggestions de personnalisation que le candidat devrait verifier]
|
||||
```
|
||||
|
||||
## Etape 6 -- Apres la candidature (optionnel)
|
||||
|
||||
Si le candidat confirme que la candidature est envoyee :
|
||||
1. Mettre a jour le statut dans `applications.md` de "Evaluated" a "Applied"
|
||||
2. Mettre a jour le Bloc G du report avec les reponses finales
|
||||
3. Suggerer l'etape suivante : `/career-ops contacto` pour du LinkedIn outreach vers le hiring manager
|
||||
|
||||
## Gestion du defilement
|
||||
|
||||
Si le formulaire a plus de questions que ce qui est visible :
|
||||
- Demander au candidat de defiler et de partager une autre capture d'ecran
|
||||
- Ou de coller les questions restantes
|
||||
- Traiter par iterations jusqu'a couvrir tout le formulaire
|
||||
@@ -0,0 +1,63 @@
|
||||
# Recruiter-Side Application Heuristics
|
||||
|
||||
Use these rules for candidate-facing documents and answers: PDF summaries,
|
||||
bullets, cover letters, form answers, LinkedIn messages, recruiter scripts, and
|
||||
interview prep. They do not apply to internal evaluation reports unless a mode
|
||||
explicitly asks for analysis.
|
||||
|
||||
## Recruiter-Side Risk Map
|
||||
|
||||
Before generating a CV, cover letter, form answer, recruiter script, or
|
||||
interview prep, create a small internal risk map:
|
||||
|
||||
| Potential doubt | Evidence from CV/report | Candidate-facing fix |
|
||||
|-----------------|-------------------------|----------------------|
|
||||
| Can they do this stack? | Matching tools, systems, projects | Put the exact stack in truthful context |
|
||||
| Are they senior enough? | Ownership, scope, tradeoffs, mentoring | Lead with senior behaviors, not tenure alone |
|
||||
| Is the domain relevant? | Similar users, workflows, scale, constraints | Translate adjacent proof into the JD's language |
|
||||
| Is there a logistics blocker? | Location, comp, work-auth, availability | Answer only where the form/recruiter asks |
|
||||
| Is the application generic? | Weak or broad bullets | Rewrite around this role's concrete problems |
|
||||
|
||||
Use the map to reduce review risk. Do not print it unless the mode output
|
||||
explicitly asks for analysis. Never invent evidence to close a doubt.
|
||||
|
||||
## Six-Second Clarity Gate
|
||||
|
||||
For every CV/PDF and cover letter, the top third must make the target fit
|
||||
impossible to miss:
|
||||
|
||||
- target role/archetype
|
||||
- strongest matching stack or domain
|
||||
- one production or business outcome
|
||||
- location/remote fit only when appropriate for that document
|
||||
- portfolio/case-study link when available and relevant
|
||||
|
||||
If a recruiter must infer fit from scattered bullets, rewrite the summary and
|
||||
first experience bullets.
|
||||
|
||||
## Business-Value Bullets
|
||||
|
||||
Prefer:
|
||||
|
||||
`Action + system/scope + tool/approach + outcome + proof`
|
||||
|
||||
Good patterns:
|
||||
|
||||
- `Resolved [problem] in [system], improving [business/system effect].`
|
||||
- `Built [capability] with [tools], enabling [user/team outcome].`
|
||||
- `Migrated [old] to [new], reducing [risk/cost/latency/debt].`
|
||||
- `Improved [metric] from [before] to [after] by [technical action].`
|
||||
|
||||
Avoid weak starts when stronger ownership is true: "helped", "assisted",
|
||||
"responsible for", "worked on", "participated in".
|
||||
|
||||
## ATS Reality Check
|
||||
|
||||
Optimize for parseability and human review, not "ATS hacks":
|
||||
|
||||
- exact JD keywords only in truthful context
|
||||
- no hidden text
|
||||
- no keyword stuffing
|
||||
- no white-font tricks
|
||||
- no decorative layouts that break parsing
|
||||
- no skills or metrics not present in the user's sources of truth
|
||||
@@ -0,0 +1,259 @@
|
||||
# Mode: interview-prep — Company-Specific Interview Intelligence
|
||||
|
||||
When the user asks to prep for an interview at a specific company+role, or when an evaluation scores 4.0+ and the user updates status to `Interview`, run this mode.
|
||||
|
||||
## Inputs
|
||||
|
||||
1. **Company name** and **role title** (required)
|
||||
2. **Evaluation report** in `reports/` (if exists) — read for archetype, gaps, matched proof points
|
||||
3. **Story bank** at `interview-prep/story-bank.md` — read for existing prepared stories
|
||||
4. **CV** at `cv.md` + `article-digest.md` — read for proof points
|
||||
5. **Profile** at `config/profile.yml` + `modes/_profile.md` — read for candidate context
|
||||
6. **Recruiter-side risk map** from the evaluation/PDF/application flow if present — use `modes/heuristics/recruiter-side.md` for the risk categories the interview process must resolve
|
||||
|
||||
## Step 1 — Research
|
||||
|
||||
Run these WebSearch queries. Extract structured data, not summaries. Cite sources for every claim.
|
||||
|
||||
The first round of most processes is a recruiter / HR screen, not a technical panel — so research has to cover both. Group queries by the audience they inform:
|
||||
|
||||
**Recruiter / HR screen** (early-round fit, comp, logistics):
|
||||
|
||||
| Query | What to extract |
|
||||
|-------|-----------------|
|
||||
| `"{company} {role} salary" site:levels.fyi` and `"{company} {role} salary" site:glassdoor.com/Salary` (run both — `OR` inside a quoted phrase is taken literally by most engines) | Comp ranges (base / equity / bonus) by level |
|
||||
| `"{company} interview process site:glassdoor.com"` then manually filter retrieved reviews to those describing the recruiter / HR screen | Process timeline, screening criteria, common screening questions, recruiter behavior |
|
||||
| `"{company} site:teamblind.com" comp negotiation OR offer` | Candid comp/leverage details, what recruiters push back on |
|
||||
| `"{company} careers"` + `"{company} benefits"` | Official comp/benefits framing, work-auth/visa policy, location policy |
|
||||
|
||||
**Hiring manager / leadership** (motivation, scope alignment, team fit):
|
||||
|
||||
| Query | What to extract |
|
||||
|-------|-----------------|
|
||||
| `"{company} engineering blog"` and `"{company} {team} blog"` | Team's recent work, technical priorities, named challenges |
|
||||
| `"{company}" news OR launch OR roadmap` (last 12 months) | Recent milestones, public bets, hiring drivers |
|
||||
| `"{company} {role} interview process"` (general) | Hiring-manager round structure, what they evaluate, candidate write-ups |
|
||||
|
||||
**Peer / technical panel** (depth, collaboration, on-the-job realism):
|
||||
|
||||
| Query | What to extract |
|
||||
|-------|-----------------|
|
||||
| `"{company} {role} interview questions site:glassdoor.com"` | Actual questions asked, difficulty rating, experience rating, number of rounds, offer/reject ratio |
|
||||
| `"{company} {role} interview site:leetcode.com/discuss"` | Specific coding/technical problems, system design topics, round structure |
|
||||
| `"{company} interview process site:teamblind.com"` then manually filter retrieved threads to those describing technical rounds | Hiring bar, recent technical interview data points |
|
||||
|
||||
If the company is small or obscure and yields few results, broaden: search for the role archetype at similar-stage companies, and note that intel is sparse. Do the recruiter-screen queries even when intel is sparse — comp/logistics data exists for almost every company.
|
||||
|
||||
**Do NOT fabricate questions.** If a source says "they asked about distributed systems," report that. Do not invent a specific distributed systems question. When generating likely questions from JD analysis, label them clearly as `[inferred from JD]` not sourced from candidates.
|
||||
|
||||
**Tag conventions** (don't mix them):
|
||||
|
||||
- `[inferred from JD]` — questions derived from the job description rather than a candidate report.
|
||||
- `[inferred]` — audience classifications (Step 2.5) made from round duration / position when `Conducted by` is unknown.
|
||||
|
||||
## Step 2 — Process Overview
|
||||
|
||||
```markdown
|
||||
## Process Overview
|
||||
- **Rounds:** {N} rounds, ~{X} days end-to-end
|
||||
- **Format:** {e.g., recruiter screen → technical phone → take-home → onsite (4 rounds) → hiring manager}
|
||||
- **Difficulty:** {X}/5 (Glassdoor avg, N reviews)
|
||||
- **Positive experience rate:** {X}%
|
||||
- **Known quirks:** {e.g., "pair programming instead of whiteboard", "no LeetCode, all practical", "take-home is 4 hours"}
|
||||
- **Sources:** {links}
|
||||
```
|
||||
|
||||
If data is insufficient for any field, write "unknown — not enough data" rather than guessing.
|
||||
|
||||
## Step 2.5 — Audience Map
|
||||
|
||||
Classify each round from Step 2 into exactly one audience. The audience drives what gets prioritized in Steps 4 and 7.
|
||||
|
||||
| Audience | Typical round | Primary evaluation |
|
||||
|---------------------|----------------------------------------------|-----------------------------------------------------------------|
|
||||
| `recruiter-screen` | First call (15–30 min, recruiter / HR / TA) | Fit gate: motivation, comp, location/visa, timeline |
|
||||
| `hiring-manager` | Manager / skip-level (30–45 min) | Why this role, scope alignment, leadership signals |
|
||||
| `peer-tech` | IC technical (live coding, system design, take-home review) | Depth + collaboration on the actual stack |
|
||||
| `panel-mixed` | Onsite / loop with multiple interviewer types in one block | Cross-cuts the above |
|
||||
|
||||
If `Conducted by` is unknown for a round, infer cautiously from duration, position, and any signals from the JD or job posting. Common patterns:
|
||||
|
||||
- Round 1, short (15–30 min) → almost always `recruiter-screen`.
|
||||
- Round 2 — **do not default**. Many companies put a peer-led technical phone screen here, others put the hiring manager. Prefer `peer-tech` if the round is described as "technical screen" or has a coding/system-design component; prefer `hiring-manager` if it's described as a manager / skip-level / leadership conversation; otherwise mark as `panel-mixed [inferred]` and prep both packs.
|
||||
- Deep technical block (live coding, system design, take-home review) → `peer-tech`.
|
||||
- Onsite / loop with multiple back-to-back rounds → `panel-mixed`.
|
||||
|
||||
Mark inferred audiences with `[inferred]` and keep going — sparse intel is normal early in research.
|
||||
|
||||
```markdown
|
||||
## Audience Map
|
||||
- **Round 1** (recruiter screen, 30 min) → `recruiter-screen`
|
||||
- **Round 2** (technical phone screen, 60 min) → `peer-tech`
|
||||
- **Round 3** (hiring manager call, 45 min) → `hiring-manager`
|
||||
- **Round 4** (onsite loop, 4× 45 min) → `panel-mixed`
|
||||
- ...
|
||||
```
|
||||
|
||||
The example above shows a typical pattern but is not a default. Classify each round from the actual research above — round 2 in particular is often `peer-tech`, not `hiring-manager`.
|
||||
|
||||
## Step 3 — Round-by-Round Breakdown
|
||||
|
||||
For each round discovered in research:
|
||||
|
||||
```markdown
|
||||
### Round {N}: {Type} — audience: `{audience}`
|
||||
- **Duration:** {X} min
|
||||
- **Conducted by:** {peer / manager / skip-level / recruiter — if known}
|
||||
- **What they evaluate:** {specific skills or traits}
|
||||
- **Reported questions:**
|
||||
- {question} — [source: Glassdoor (URL/date)]
|
||||
- {question} — [source: Blind (URL/date)]
|
||||
- **How to prepare:** {1-2 concrete actions, audience-appropriate — see Step 4 for the full per-audience pack}
|
||||
```
|
||||
|
||||
If round structure is unknown, state that and provide the best available intel on what types of rounds to expect based on company size, stage, and role level.
|
||||
|
||||
## Step 4 — Likely Questions (per audience)
|
||||
|
||||
Group all discovered and inferred questions by the audience that asks them, not by question type. Within each audience, draft candidate-specific answers using `cv.md`, `article-digest.md`, `config/profile.yml`, and `modes/_profile.md`. **Never fabricate questions** — sourced questions must cite, inferred questions must be tagged `[inferred from JD]`.
|
||||
|
||||
If any of those profile files are missing, incomplete, or out-of-date, note the gap inline (e.g. "comp target unknown — defer to recruiter band") and proceed with what's available rather than blocking the prep. The mode's value is partial-but-honest output, not perfect-or-nothing.
|
||||
|
||||
For every answer, use result-first framing:
|
||||
|
||||
1. **Headline** — the result, decision, or point.
|
||||
2. **Effect** — why it mattered to the business, users, system, or team.
|
||||
3. **Rationale** — what tradeoff or constraint shaped the choice.
|
||||
4. **Operations** — what the candidate actually did, with enough implementation detail to be credible.
|
||||
|
||||
This is especially important for senior, technical, and leadership answers. Simple recruiter answers can be shorter, but should still start with the point.
|
||||
|
||||
### Audience: `recruiter-screen`
|
||||
|
||||
The recruiter is screening for fit, not testing skill. Wrong-foot answers (vague comp, fuzzy motivation, missing logistics) end the process before any technical signal is collected. Cover at minimum:
|
||||
|
||||
- **"Walk me through your CV / why are you looking?"** — 60–90s narrative anchored to `modes/_profile.md` narrative + the role's archetype.
|
||||
- **Comp expectation** — concrete range pulled from Step 1 Levels.fyi/Glassdoor data, anchored to `config/profile.yml` `compensation.target`. Note the leverage hand: if comp data is thin or the candidate has no competing offer, recommend deferring with a clean script ("I'm calibrating to market for {level}, can you share the band for this role?").
|
||||
- **Why this company** — 2–3 sentences referencing public signals from Step 1 (recent launch, named values, team work). Avoid generic praise.
|
||||
- **Location / remote / visa** — answer derived from `config/profile.yml` location policy and the role's posted policy. Flag deal-breakers from `modes/_profile.md` so the recruiter can route correctly.
|
||||
- **Timeline / availability / notice period** — numbers, not vibes.
|
||||
- **Other processes in flight** — recommended framing only; never push the candidate to lie.
|
||||
- **Background red flags** — gaps, transitions, unusual elements from `cv.md` + `_profile.md`. Honest, specific, forward-looking framing — never defensive.
|
||||
|
||||
### Audience: `hiring-manager`
|
||||
|
||||
The HM is screening for motivation + scope fit. They've already trusted the recruiter's logistics gate; they care whether you'd own the work. Cover at minimum:
|
||||
|
||||
- **"Why this role, why now?"** — connect candidate's last 1–2 roles + `_profile.md` narrative to the team's named challenge from Step 1.
|
||||
- **"What would your first 90 days look like here?"** — derived from JD scope + the team's recent work (engineering blog, public roadmap).
|
||||
- **Risk map closure** — make sure the strongest likely doubts from the evaluation are answered with concrete proof, not enthusiasm.
|
||||
- **Leadership / collaboration questions** — map to `interview-prep/story-bank.md`.
|
||||
- **Sharp questions to ask back** — 2–3 tied to a specific recent thing the team shipped or wrote about, not generic "what's the team like".
|
||||
|
||||
### Audience: `peer-tech`
|
||||
|
||||
This is where the original Technical / Role-Specific buckets live. Peers are evaluating depth and collaboration on the actual stack.
|
||||
|
||||
- **Technical questions** (system design, coding, architecture, domain) — for each: the question, source, and what a strong answer looks like for this candidate specifically (reference CV proof points).
|
||||
- **Role-specific questions** tied to the JD archetype — for each: the question, why they're likely asking it (which JD requirement it maps to), and the candidate's best angle.
|
||||
- **Reverse questions** — about on-call, code review culture, deployment cadence, what surprised them when they joined.
|
||||
|
||||
### Audience: `panel-mixed`
|
||||
|
||||
Onsite loops and mixed panels rarely give the candidate time to context-switch — preparation has to be pre-routed. For each panel slot:
|
||||
|
||||
- **If the interviewer is named in the schedule**, do a quick LinkedIn/blog look-up and tag them to one of the three audiences (recruiter / HM / peer-tech). Then pull from that audience's pack.
|
||||
- **If the slot is unlabeled**, prep all three packs but cap each to 3–5 highest-priority items so the candidate isn't drowning in notes.
|
||||
- **Hand-off discipline**: tell the candidate explicitly what NOT to repeat verbatim across slots (e.g. the same proof point told identically twice signals scripted answers; vary the angle).
|
||||
- **Energy management**: 4-hour onsites burn out less-experienced candidates first. Flag the slot most likely to test depth (usually peer-tech) and reserve the candidate's freshest material for it.
|
||||
|
||||
## Step 5 — Story Bank Mapping
|
||||
|
||||
Run this mapping **per audience pack** from Step 4 — same story can map differently to a recruiter prompt vs a peer-tech behavioral question, and a single un-segmented table risks cross-audience drift.
|
||||
|
||||
| # | Audience | Likely question/topic | Best story from story-bank.md | Fit | Gap? |
|
||||
|---|----------|----------------------|-------------------------------|-----|------|
|
||||
| 1 | recruiter-screen | ... | [Story Title] | strong/partial/none | |
|
||||
| 2 | hiring-manager | ... | [Story Title] | strong/partial/none | |
|
||||
| 3 | peer-tech | ... | [Story Title] | strong/partial/none | |
|
||||
|
||||
- **strong**: story directly answers the question
|
||||
- **partial**: story is adjacent, needs reframing
|
||||
- **none**: no existing story — flag for the user
|
||||
|
||||
For each gap, suggest: "You need a story about {topic}. Consider: {specific experience from cv.md that could become a STAR+R story}."
|
||||
|
||||
If the user wants to draft missing stories, help them build STAR+R format and append to `interview-prep/story-bank.md`.
|
||||
|
||||
## Step 6 — Technical Prep Checklist
|
||||
|
||||
Based on what the company actually tests, not generic advice:
|
||||
|
||||
```markdown
|
||||
- [ ] {topic} — why: "{evidence from research}"
|
||||
- [ ] {topic} — why: "{their blog/product suggests this matters}"
|
||||
- [ ] {topic} — why: "{asked in N/M recent Glassdoor reviews}"
|
||||
```
|
||||
|
||||
Prioritize by frequency and relevance to the role. Max 10 items.
|
||||
|
||||
## Step 7 — Company Signals (per audience)
|
||||
|
||||
Things to say, do, and avoid — segmented by who's listening. The same fact can be a strength to a peer engineer and a yellow flag to a recruiter; framing matters.
|
||||
|
||||
### To the recruiter / HR screen
|
||||
|
||||
- **What to volunteer**: motivation, location/visa fit, timeline, why this company.
|
||||
- **What NOT to volunteer**: hard comp number when leverage is uncertain (defer to band); ongoing process details; opinions on the company's recent layoffs / press.
|
||||
- **Vocabulary**: official company language for benefits and policies (from careers page).
|
||||
- **Red flags they screen for**: visa surprises, comp mismatch, "looking everywhere" energy.
|
||||
|
||||
### To the hiring manager
|
||||
|
||||
- **What to lead with**: connection between candidate narrative (`_profile.md`) and a named team challenge from Step 1.
|
||||
- **Vocabulary to use**: terms the company uses internally — shows homework (e.g., Stripe says "increase the GDP of the internet", Anthropic says "safety" not "alignment").
|
||||
- **Sharp questions to ask back**: 2–3 tied to recent news / blog posts from Step 1.
|
||||
|
||||
### To the peer / technical panel
|
||||
|
||||
- **What to lead with**: stack-relevant proof points from `cv.md` / `article-digest.md`.
|
||||
- **Things to avoid**: anti-patterns flagged in Glassdoor / Blind reviews specific to this company.
|
||||
- **Reverse questions**: on-call rotation, code review norms, deployment cadence, what surprised them when they joined.
|
||||
|
||||
### To a mixed panel
|
||||
|
||||
- **What to lead with**: a single 2-sentence framing that lands for all three audiences — usually narrative + named team challenge — then let each interviewer steer.
|
||||
- **What NOT to repeat**: same proof point told identically across slots; instead, vary the angle (recruiter hears the headline number, HM hears the team-impact framing, peer-tech hears the technical detail).
|
||||
- **Vocabulary**: keep recruiter-friendly language (impact, scope) when leadership is in the room; switch to peer-language (architecture, trade-offs, on-call) when only ICs are.
|
||||
- **What to avoid**: contradicting yourself across slots about comp, timeline, or what excites you. Interviewers compare notes.
|
||||
|
||||
## Output
|
||||
|
||||
Save the full report to `interview-prep/{company-slug}-{role-slug}.md` with this header:
|
||||
|
||||
```markdown
|
||||
# Interview Intel: {Company} — {Role}
|
||||
|
||||
**URL:** {job posting URL or company careers URL, or "N/A" if recruiter-sourced}
|
||||
**Legitimacy:** {tier copied from the evaluation report's Block G, or "unknown" if no report exists}
|
||||
**Report:** {link to evaluation report if exists, or "N/A"}
|
||||
**Researched:** {YYYY-MM-DD}
|
||||
**Sources:** {N} Glassdoor reviews, {N} Blind posts, {N} other
|
||||
**Audiences covered:** {recruiter-screen, hiring-manager, peer-tech, panel-mixed}
|
||||
```
|
||||
|
||||
## Post-Research
|
||||
|
||||
After delivering the report:
|
||||
|
||||
1. Ask the user if they want to draft stories for any gaps found in Step 5
|
||||
2. If they have a scheduled interview date, note it: "Your interview is in {X} days. Want me to set a reminder to review this prep?"
|
||||
3. Suggest running `deep` mode if the company research in Step 1 was thin — deep mode covers strategy, culture, and competitive landscape in more depth
|
||||
|
||||
## Rules
|
||||
|
||||
- **NEVER invent interview questions and attribute them to sources.** Inferred questions must be labeled `[inferred from JD]`.
|
||||
- **NEVER fabricate Glassdoor ratings or statistics.** If the data isn't there, say so.
|
||||
- **Cite everything.** Every question, every stat, every claim gets a source or an `[inferred]` tag.
|
||||
- Generate in the language of the JD (EN default).
|
||||
- Be direct. This is a working prep document, not a pep talk.
|
||||
@@ -0,0 +1,67 @@
|
||||
# Mode: interview — Interactive Profile & CV Onboarding
|
||||
|
||||
When the user runs `/career-ops interview`, execute this interactive profile/CV interview flow.
|
||||
|
||||
The purpose of this mode is to conduct a conversational interview to extract rich context, specific project tasks, technologies used, and measurable business impact to build or enhance `cv.md`, `config/profile.yml`, and `modes/_profile.md`.
|
||||
|
||||
---
|
||||
|
||||
## Guidelines for the AI Agent
|
||||
|
||||
### 1. Load Baseline Context
|
||||
|
||||
- Read `cv.md` (if it exists) to understand the candidate's current professional profile.
|
||||
- Read `config/profile.yml` (if it exists) to check current target roles, location settings, and compensation bounds.
|
||||
- Read `modes/_profile.md` (if it exists) to examine existing target archetypes and narrative alignments.
|
||||
|
||||
### 2. Interview Structure & Tone
|
||||
|
||||
- Keep it professional, conversational, and direct. Avoid generic corporate fluff.
|
||||
- **Rule: Ask exactly ONE question at a time.** Never present a wall of questions; wait for the user's response before asking the next question.
|
||||
- Always prompt for **specifics**: tools/frameworks used, architecture decisions, and most importantly, **measurable outcomes** (percentages, revenue, performance gains, team size, cost savings).
|
||||
|
||||
---
|
||||
|
||||
## Step-by-Step Interview Flow
|
||||
|
||||
### Step 1: Target Roles & Ambitions
|
||||
|
||||
Ask the user about their immediate goals:
|
||||
- What specific roles are they targeting?
|
||||
- What are their target salary and total compensation expectations?
|
||||
- What are their location preferences (remote, hybrid, on-site, geographic limits)?
|
||||
- Update `config/profile.yml` with the target role titles, locations, and salary bounds.
|
||||
|
||||
### Step 2: Experience & Core Achievements
|
||||
|
||||
Ask about their most significant professional achievements:
|
||||
- Focus on the last 2-3 roles.
|
||||
- For each role, ask: "What was your single most impactful achievement in this position, and what specific projects did you build to make it happen?"
|
||||
- Extract: What tools/architecture were used?
|
||||
|
||||
### Step 3: Digging for Metrics (Business Impact)
|
||||
|
||||
Recruiters and ATS scanners look for quantifiable metrics. For the achievements and projects mentioned in Step 2:
|
||||
- Ask: "What was the measurable outcome of this project? (e.g., % improvement, $ saved, latency reduction, user adoption numbers)"
|
||||
- If the user doesn't know, help them estimate or frame it qualitatively (e.g., "enabled 12 developers to ship 3x faster").
|
||||
|
||||
### Step 4: Uncovering Hidden Skills
|
||||
|
||||
Ask about adjacent experience or forgotten skills:
|
||||
- "What tools, languages, or methodologies do you have experience with that aren't on your main resume?"
|
||||
- "Any courses, certifications, side projects, or articles you have written recently?"
|
||||
|
||||
---
|
||||
|
||||
## Step 5 — Apply Updates
|
||||
|
||||
Once the interview is complete, or once enough new details have been collected:
|
||||
1. **Update `cv.md`**: Update the professional summary, rewrite project bullet points to incorporate the new keywords and metrics, and append new skills.
|
||||
2. **Update `config/profile.yml`**: Update the targets, compensation, and narrative sections.
|
||||
3. **Update `modes/_profile.md`**: Map the new projects/proof points to the target archetypes and update the adaptive framing rules.
|
||||
4. Run `node doctor.mjs` silently to verify project integrity.
|
||||
5. Provide a summary of the files updated:
|
||||
> "✅ Interactive interview completed! Updated your profile:
|
||||
> - **CV**: Refined summaries and project bullets with new metrics.
|
||||
> - **Profile config**: Updated target roles and comp expectations.
|
||||
> - **Custom framing**: Integrated project mappings into _profile.md."
|
||||
@@ -0,0 +1,33 @@
|
||||
# Interview Skills
|
||||
|
||||
A set of reusable skills for end-to-end interview preparation.
|
||||
|
||||
## Skills
|
||||
|
||||
| Skill | File | When to use |
|
||||
|---|---|---|
|
||||
| Prep Planner | `plan.md` | Given a JD and interview date, build a structured time-blocked prep plan |
|
||||
| Practice Interviewer | `practice.md` | Run practice interview questions with structured feedback |
|
||||
| Post-Interview Debrief | `debrief.md` | After a real interview, close gaps and update the question bank |
|
||||
|
||||
## Related Skills (in parent `modes/`)
|
||||
|
||||
| Skill | File | When to use |
|
||||
|---|---|---|
|
||||
| Company Research | `../interview-prep.md` | Research a specific company and role before interviewing |
|
||||
|
||||
## File Conventions
|
||||
|
||||
These skills assume the following files exist (career-ops defaults):
|
||||
|
||||
| File | Purpose |
|
||||
|---|---|
|
||||
| `cv.md` | Candidate CV — source of truth for experience and proof points |
|
||||
| `article-digest.md` | Compact proof points from portfolio (optional) |
|
||||
| `config/profile.yml` | Candidate profile — target roles, compensation, narrative |
|
||||
| `modes/_profile.md` | Candidate archetypes, narrative, and deal-breakers |
|
||||
| `interview-prep/story-bank.md` | Accumulated STAR+R stories |
|
||||
| `interview-prep/question-bank.md` | Question bank with gap tracking (created on first use) |
|
||||
| `interview-prep/interview-prep-guide.md` | General interview principles (optional) |
|
||||
| `interview-prep/{company}-{role}.md` | Role-specific prep file |
|
||||
| `interview-prep/retracted-claims.md` | Claims the candidate has rejected as indefensible — hard gate in practice and debrief (format: `**"[claim]"** ([context]). Reason: [one-line reason + correct framing if applicable].`) |
|
||||
@@ -0,0 +1,200 @@
|
||||
# Mode: interview/debrief — Post-Interview Debrief
|
||||
|
||||
After a real interview, capture what was asked, assess what landed and what didn't, close gaps before the next round, and update the question bank.
|
||||
|
||||
---
|
||||
|
||||
## When to Run This Skill
|
||||
|
||||
- Immediately after a real interview (while memory is fresh)
|
||||
- After a recruiter call that surfaced new information about the process
|
||||
- When the candidate learns the next round format and interviewer
|
||||
|
||||
---
|
||||
|
||||
## Inputs
|
||||
|
||||
1. **Interview debrief from candidate** — what questions were asked, how they answered, what felt strong or weak
|
||||
2. **Interviewer name and role** — informs next round prediction
|
||||
3. **Round outcome** (if known) — moved forward / rejected / pending
|
||||
4. **Next round details** (if known) — format, interviewers, timeline
|
||||
5. **Question bank** at `interview-prep/question-bank.md` — update with real data
|
||||
6. **Story bank** at `interview-prep/story-bank.md` — add new stories if surfaced
|
||||
7. **CV** at `cv.md` + `article-digest.md` (if present) — to ground suggested answers in real experience
|
||||
8. **Retracted claims** at `interview-prep/retracted-claims.md` (if present) — hard gate; never use a retracted claim in a suggested answer even if the candidate said it in the interview
|
||||
9. **Role-specific prep file** — append debrief notes
|
||||
|
||||
---
|
||||
|
||||
## Step 1 — Capture What Was Asked
|
||||
|
||||
Ask the candidate to list every question they remember, in order if possible. Don't prompt with options — let them recall freely first.
|
||||
|
||||
For each question captured:
|
||||
- What did they say?
|
||||
- How did the interviewer react (positive signal, neutral, pushed back, moved on quickly)?
|
||||
- Did they feel confident or uncertain?
|
||||
|
||||
If memory is incomplete, ask targeted prompts:
|
||||
- "Were there any questions that caught you off guard?"
|
||||
- "Was there anything you wished you'd answered differently?"
|
||||
- "Did the interviewer follow up on anything — that usually means they wanted more?"
|
||||
|
||||
---
|
||||
|
||||
## Step 2 — Honest Assessment Per Question
|
||||
|
||||
For each question, produce:
|
||||
|
||||
```markdown
|
||||
**Q: [question]**
|
||||
- What was said: [summary of their answer]
|
||||
- What landed: [what was good — be specific]
|
||||
- What was missing: [gap — precise technical term, missing result, no reflection, etc.]
|
||||
- Correct/complete answer: [what the full answer should include]
|
||||
- Status: ✅ Strong / 🟡 Solid / 🔴 Gap
|
||||
```
|
||||
|
||||
Be direct. If they missed the core concept the question was testing, say so. If an answer was genuinely strong, say that too. The debrief is the most valuable learning moment — vagueness wastes it.
|
||||
|
||||
---
|
||||
|
||||
## Step 3 — Update Question Bank
|
||||
|
||||
For each question debriefed, update `interview-prep/question-bank.md`:
|
||||
- Change status to ✅ / 🟡 / 🔴 based on real performance
|
||||
- Add gap notes from the debrief
|
||||
- Add any new questions that appeared and weren't in the bank yet
|
||||
|
||||
If the question bank doesn't exist, create it with the questions from this interview as the seed.
|
||||
|
||||
---
|
||||
|
||||
## Step 4 — Close the Gaps
|
||||
|
||||
For each 🔴 gap identified:
|
||||
|
||||
1. **Explain the correct answer** — clear, concise, with a worked example (code, calculation, diagram) where it helps
|
||||
2. **Connect to a real story** if possible — "you actually have this in your [existing story from the story bank] — here's how to use it"
|
||||
3. **Add to role-specific prep file** under a "Gaps to Close Before Round N" section
|
||||
4. **Add to `interview-prep/interview-prep-guide.md`** (if the candidate maintains one) when it's a reusable principle that applies beyond this role
|
||||
|
||||
---
|
||||
|
||||
## Step 5 — Extract New Stories
|
||||
|
||||
Sometimes a real interview surfaces a story the candidate hadn't prepared. If the candidate described an experience they hadn't formalized:
|
||||
|
||||
> "You mentioned [X] in your answer — that sounds like it could become a proper STAR+R story. Want to build it out now while it's fresh?"
|
||||
|
||||
If yes, build it out as a STAR+R story (Situation, Task, Action, Result, Reflection) and append it to `interview-prep/story-bank.md`.
|
||||
|
||||
---
|
||||
|
||||
## Step 6 — Next Round Intelligence
|
||||
|
||||
If the candidate knows the next round format:
|
||||
|
||||
1. **Predict likely questions** based on:
|
||||
- Next interviewer's role (e.g., senior practitioner → depth in the core skill, design; cross-functional peer → collaboration, domain boundaries; executive → strategy, business impact)
|
||||
- What was covered in this round (next round typically goes deeper, not wider)
|
||||
- What the interviewer in this round seemed most interested in
|
||||
|
||||
Label every prediction `[inferred]` — never present a predicted question as if it were sourced from real candidates or insiders.
|
||||
|
||||
2. **Build a priority list** for next round prep — ordered by gap severity and likelihood of being tested
|
||||
|
||||
3. **Suggest running** `interview/plan` with the next round details to build a full prep plan
|
||||
|
||||
---
|
||||
|
||||
## Step 7 — Probability Assessment (Optional)
|
||||
|
||||
If the candidate asks for an honest read on their chances:
|
||||
|
||||
Assess based on:
|
||||
- Number and severity of gaps (🔴 on fundamentals = higher risk than 🔴 on advanced topics)
|
||||
- Interviewer signals (gave specific next round details = positive; vague = neutral; short call = risk)
|
||||
- Role fit (years of experience, domain match, location)
|
||||
- Differentiators (things the candidate said that most candidates wouldn't)
|
||||
|
||||
Be honest. A probability range with clear reasoning is more useful than false confidence.
|
||||
|
||||
---
|
||||
|
||||
## Step 8 — Save Debrief
|
||||
|
||||
Append to `interview-prep/{company-slug}-{role-slug}.md`:
|
||||
|
||||
```markdown
|
||||
## Round [N] Debrief — [YYYY-MM-DD]
|
||||
|
||||
**Interviewer:** [name, role]
|
||||
**Round type:** [screening / technical / design-case-study / behavioral]
|
||||
**Outcome:** [pending / moved forward / rejected]
|
||||
|
||||
### Questions Asked
|
||||
[list]
|
||||
|
||||
### Gaps Identified
|
||||
[list with correct answers]
|
||||
|
||||
### Next Round
|
||||
**Format:** [if known]
|
||||
**Interviewers:** [if known]
|
||||
**Priority prep:** [top 3 topics to close before next round]
|
||||
|
||||
### Process Intel (recruiter / HM screens — omit if not applicable)
|
||||
**Comp discussed:** [yes / no — if yes, what was said and what was anchored]
|
||||
**Timeline:** [any dates or deadlines mentioned]
|
||||
**Other candidates:** [if disclosed]
|
||||
**Next steps:** [what the interviewer said happens next and by when]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Step 9 — Write Session Transcript
|
||||
|
||||
After the debrief, also write a machine-readable session transcript to `interview-prep/sessions/{company-slug}-{role-slug}-{round}-{YYYY-MM-DD}.md`. This is a structured record of the round for downstream analysis modes; the speaker-labelled turns let a consumer read either side without re-inferring who spoke. The full contract lives in `interview-prep/sessions/README.md`.
|
||||
|
||||
Format:
|
||||
|
||||
```markdown
|
||||
---
|
||||
company: [company]
|
||||
role: [role]
|
||||
round: [screen | hiring-manager | technical | system-design | behavioral | onsite | final]
|
||||
date: YYYY-MM-DD
|
||||
interviewer_role: [role, if known]
|
||||
source: debrief
|
||||
---
|
||||
|
||||
## Q1
|
||||
**Interviewer:** [question as asked]
|
||||
<!-- competency: tag[, tag...] -->
|
||||
**Candidate:** [answer as delivered / reconstructed in this debrief]
|
||||
|
||||
## Q2
|
||||
...
|
||||
```
|
||||
|
||||
Rules for the transcript:
|
||||
|
||||
- **Map the round type to the enum** above (e.g. recruiter screen → `screen`, HM screen → `hiring-manager`, technical deep-dive → `technical`, design/case-study → `system-design`).
|
||||
- **Tag each answer.** On the line directly above each `**Candidate:**` line, emit `<!-- competency: tag[, tag...] -->` — lowercase-kebab-case, comma-separated for multi-competency answers (e.g. `system-design`, `people-leadership`, `incident-response`). You already assessed each answer in Step 2, so tag from that assessment rather than re-reading. Tags are free-form; pick the competency the question actually tested.
|
||||
- **Reconstruct the candidate turn faithfully.** Use what the candidate reported saying in Step 1, not an idealized answer. The "correct/complete answer" from Step 2 belongs in the debrief file, never in the transcript — the transcript records what happened.
|
||||
- **`source: debrief`.**
|
||||
- The session file lands in a gitignored directory (real names/companies never enter version control); write it without redacting.
|
||||
|
||||
---
|
||||
|
||||
## Rules
|
||||
|
||||
- **Debrief immediately.** Memory of interview details degrades fast — within hours, specific questions and reactions are forgotten. Run this skill the same day.
|
||||
- **Don't soften gaps.** A 🔴 gap that gets called 🟡 out of kindness will show up again in the next round.
|
||||
- **Never put invented claims in the candidate's mouth.** Correct/complete answers may draw on general domain knowledge, but any suggested personal claim or metric must come from what the candidate said, `cv.md`, `article-digest.md`, or the story bank.
|
||||
- **Retracted claims are a hard gate.** If a claim appears in `interview-prep/retracted-claims.md`, never suggest the candidate use it — even if they said it in the real interview. Flag it: "That claim is in your retracted list — it's not defensible under pressure. Here's a version that doesn't depend on it."
|
||||
- **Record new retractions.** If the debrief reveals a claim the candidate used in the real interview that they now agree isn't defensible, offer to append it to `interview-prep/retracted-claims.md`: `**"[claim]"** ([context]). Reason: [one-line reason + correct framing if applicable].`
|
||||
- **Extract vocabulary gaps explicitly.** If the candidate used an imprecise term where a precise one exists, add it to `interview-prep/interview-prep-guide.md` under the vocabulary section (if the candidate maintains one).
|
||||
- **One gap = one fix.** Don't overwhelm with a full study plan for every gap. Prioritize the 1–2 most likely to be tested in the next round.
|
||||
- **Celebrate what worked.** Debrief isn't only about gaps. Name what was strong — it reinforces the right behaviour and builds confidence for the next round.
|
||||
@@ -0,0 +1,152 @@
|
||||
# Mode: interview/plan — Interview Prep Planner
|
||||
|
||||
Given a job description and interview date/time, build a structured, time-blocked preparation plan tailored to the candidate's specific gaps.
|
||||
|
||||
---
|
||||
|
||||
## Inputs
|
||||
|
||||
1. **Job description** (required) — paste inline or provide URL
|
||||
2. **Interview date and time** (required) — to calculate hours available
|
||||
3. **Interviewer name and role** (if known) — shapes depth and tone of prep
|
||||
4. **Round type** (if known) — screening, technical/domain-specific, design/case study, behavioral panel
|
||||
5. **CV** at `cv.md` + `article-digest.md` (if present) — read for experience, skills, proof points
|
||||
6. **Profile** at `config/profile.yml` + `modes/_profile.md` — read for narrative, archetypes, and targets
|
||||
7. **Story bank** at `interview-prep/story-bank.md` — existing STAR+R stories
|
||||
8. **Question bank** at `interview-prep/question-bank.md` — existing gaps (if file exists)
|
||||
|
||||
---
|
||||
|
||||
## Step 1 — Fit Assessment
|
||||
|
||||
Read CV and JD. Produce a two-column assessment:
|
||||
|
||||
**Strengths to anchor on:** experience, titles, domain, proof points that directly match the JD.
|
||||
|
||||
**Gaps to close:** skills, tools, or experience called out in JD that are absent or weak in CV. Rank by likelihood of being tested in this specific round type.
|
||||
|
||||
Be honest. A gap is a gap — flag it clearly so prep time goes to the right places.
|
||||
|
||||
---
|
||||
|
||||
## Step 2 — Round Intelligence
|
||||
|
||||
Identify what this round is actually evaluating based on:
|
||||
- Interviewer role (manager = communication + passion + fundamentals; practitioner = depth + judgment)
|
||||
- Round label (screening, technical/domain, design/case study, final)
|
||||
- JD signals (what they emphasize)
|
||||
|
||||
**Recruiter screen:**
|
||||
- Box-checking: fit, comp alignment, logistics, communication
|
||||
- Not a technical test — depth questions come in the HM and later rounds
|
||||
- Likely: background pitch, "why us/why this role", comp expectation, timeline, one logistical question
|
||||
- Treat this as the easy checkpoint; use prep time to build the foundation for what comes after
|
||||
|
||||
**Hiring-manager screen:**
|
||||
- Communication, passion, fit — plus leadership philosophy and judgment
|
||||
- Fundamentals of the core skill in the JD — not deep internals
|
||||
- 1–2 behavioral stories
|
||||
- Likely: background, "why us", one core concept from the JD, one leadership story, forward-looking situational question
|
||||
|
||||
**Technical / domain deep-dive with a practitioner:**
|
||||
- Depth in the core skill from the JD (e.g., runtime internals for engineering, modeling choices for data, valuation methods for finance)
|
||||
- Applied scenarios from the role's day-to-day
|
||||
- Live exercise or worked walkthrough possible
|
||||
- Stories used as evidence, not the main event
|
||||
|
||||
**Design / case study panel:**
|
||||
- Full solution — constraints, components, tradeoffs, failure modes
|
||||
- The quality dimensions the JD emphasizes (e.g., scalability, compliance, measurability)
|
||||
- Senior-level: set constraints, ask clarifying questions, drive the conversation
|
||||
|
||||
Calibrate the plan to the round. Over-preparing depth for a screening wastes time and creates the wrong mindset.
|
||||
|
||||
---
|
||||
|
||||
## Step 3 — Build the Time-Blocked Plan
|
||||
|
||||
Calculate hours available from now until interview time. Divide into blocks:
|
||||
|
||||
Before sizing the blocks, check `interview-prep/question-bank.md` (if it exists). Any question marked 🔴 from a prior round is a proven gap — it gets a dedicated block regardless of how the CV-vs-JD analysis ranks it. Real performance data outranks inferred risk.
|
||||
|
||||
**Template (adjust block sizes based on total hours available):**
|
||||
|
||||
```
|
||||
Block 1 — Lock your narrative (first, always)
|
||||
- Write out your background timeline explicitly
|
||||
- Prepare "why this company" with a specific connection to your history
|
||||
- Prepare your strongest proof point story (30-second version)
|
||||
- Time: ~15% of available hours
|
||||
|
||||
Block 2 — Priority domain topic (highest-risk gap first)
|
||||
- One topic per block — don't mix
|
||||
- For each: concept → your story hook → likely follow-up questions
|
||||
- Time: ~25% of available hours
|
||||
|
||||
Block 3 — Secondary domain topic
|
||||
- Second-highest-risk gap
|
||||
- Time: ~20% of available hours
|
||||
|
||||
Block 4 — Behavioral stories
|
||||
- Map existing stories to likely question types
|
||||
- Practice the 2-minute verbal version of each
|
||||
- Prepare the Reflection for each — the senior-candidate differentiator
|
||||
- Time: ~15% of available hours
|
||||
|
||||
Block 5 — Company research
|
||||
- Product pages relevant to the role
|
||||
- Connection between your history and their specific domain
|
||||
- 3–4 sharp questions to ask them
|
||||
- Time: ~10% of available hours
|
||||
|
||||
Block 6 — Practice run (if time permits)
|
||||
- One question per likely topic — out loud, timed
|
||||
- Time: ~10% of available hours
|
||||
|
||||
Block 7 — Buffer + rest
|
||||
- Stop studying 60–90 minutes before the interview
|
||||
- Cramming in the last hour adds noise, not signal
|
||||
- Time: remaining
|
||||
```
|
||||
|
||||
Adjust block sizes based on gap severity and round type. If it's a screening, Block 4 (behavioral) and Block 5 (company research) are more important than deep domain blocks.
|
||||
|
||||
---
|
||||
|
||||
## Step 4 — Priority Quick-Reference
|
||||
|
||||
At the end of the plan, produce a one-page quick-reference the candidate can skim 15 minutes before the interview:
|
||||
|
||||
```markdown
|
||||
## 15-Minute Pre-Interview Review
|
||||
|
||||
**Your anchor sentence:** [one sentence that captures why you're right for this role]
|
||||
|
||||
**Top 3 things to remember:**
|
||||
1. [most important message to leave the interviewer with]
|
||||
2. [most likely question and your first sentence of the answer]
|
||||
3. [the connection between your history and their domain]
|
||||
|
||||
**Your questions to ask:**
|
||||
1. [question 1]
|
||||
2. [question 2]
|
||||
3. [question 3]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Step 5 — Save Output
|
||||
|
||||
Save the plan to `interview-prep/{company-slug}-{role-slug}.md` if a file doesn't exist, or append a `## Prep Plan` section if it does.
|
||||
|
||||
---
|
||||
|
||||
## Rules
|
||||
|
||||
- **Calibrate to the round.** A screening prep plan looks very different from a design-panel prep plan. Don't default to maximum depth for every interview.
|
||||
- **Gaps first.** Time is finite. The candidate's strengths don't need prep — their gaps do.
|
||||
- **🔴 gaps from the question bank take priority over inferred gaps.** Real performance data beats CV-vs-JD analysis. If the candidate already knows they struggle on a topic, don't bury it.
|
||||
- **One topic per block.** Mixing topics in a single block reduces retention.
|
||||
- **Always include rest time.** A rested candidate outperforms a cramming one.
|
||||
- **Never generate fake company intel.** If you don't have research, say so — don't invent culture claims or technical details about the company.
|
||||
- **Never invent claims for the candidate.** The anchor sentence and pre-interview talking points in the quick-reference (Step 4) must be grounded in what the candidate actually has — `cv.md`, `article-digest.md`, or the story bank. Don't draft claims that depend on experience or metrics the candidate doesn't have. If a claim appears in `interview-prep/retracted-claims.md`, never include it.
|
||||
@@ -0,0 +1,249 @@
|
||||
# Mode: interview/practice — Practice Interviewer
|
||||
|
||||
Run a realistic practice interview — one question at a time — and give structured feedback after each answer. Tracks what landed and what needs work.
|
||||
|
||||
---
|
||||
|
||||
## Inputs
|
||||
|
||||
1. **Round type** (required) — screening/recruiter, screening/HM, technical/domain-specific, design/case study, behavioral
|
||||
2. **Interviewer persona** (if known) — name, role, company; shapes question style and depth
|
||||
3. **Question list** (optional) — specific questions to cover; if not provided, generate from round type
|
||||
4. **CV** at `cv.md` + `article-digest.md` (if present) — to verify claims in answers and ground stronger versions in real experience
|
||||
5. **Profile** at `config/profile.yml` + `modes/_profile.md` — candidate narrative, deal-breakers, comp targets
|
||||
6. **Story bank** at `interview-prep/story-bank.md` — to verify story accuracy in feedback
|
||||
7. **Question bank** at `interview-prep/question-bank.md` — to update status after each answer
|
||||
8. **Role-specific prep file** — for company intel, sourced questions, comp strategy
|
||||
9. **Retracted claims** at `interview-prep/retracted-claims.md` (if present) — claims the candidate has explicitly rejected as indefensible; treat as a hard gate
|
||||
|
||||
---
|
||||
|
||||
## Protocol
|
||||
|
||||
### Preflight — Check Substance Files
|
||||
|
||||
Before setting the scene, confirm which files exist:
|
||||
|
||||
- `interview-prep/question-bank.md` (or a company-specific equivalent)
|
||||
- The role-specific prep file (`interview-prep/{company}-{role}.md`)
|
||||
- `cv.md`
|
||||
- `interview-prep/retracted-claims.md`
|
||||
|
||||
If the question bank and role-specific prep file are both absent, tell the candidate plainly:
|
||||
|
||||
> "You have the practice protocol but not your question bank or prep notes for this role. Feedback will be generic until those exist. Want to run `interview-prep` or `interview/plan` first to build them?"
|
||||
|
||||
Don't silently run a thin session as if it were a full one. If the candidate confirms they want to proceed anyway, continue — but note in the session summary that question sourcing fell back to generated defaults.
|
||||
|
||||
---
|
||||
|
||||
### Opening
|
||||
|
||||
Set the scene briefly:
|
||||
|
||||
> "I'll play [interviewer name/role]. We'll go one question at a time. Answer as you would in the real interview — out loud if possible, typed if not. After each answer I'll give you feedback, then we move to the next. Say 'pause' if you want to stop and discuss before I give feedback. Ready?"
|
||||
|
||||
Then open with the first question — no preamble, no "here's question 1". Just ask it naturally as the interviewer would.
|
||||
|
||||
---
|
||||
|
||||
### During the Session
|
||||
|
||||
**Ask one question at a time.** Wait for the full answer before giving feedback.
|
||||
|
||||
**Stay in character** during the answer. If the candidate asks a clarifying question mid-answer ("does that make sense?"), respond as the interviewer would — briefly, without breaking the scene.
|
||||
|
||||
**Follow-up questions:** after a complete answer, ask one natural follow-up if:
|
||||
- The answer was incomplete but on the right track (pull the thread)
|
||||
- The answer was strong (go deeper — this is what real interviewers do)
|
||||
- The answer missed the key point entirely (give them a chance to recover)
|
||||
|
||||
**Track what's been covered.** Keep a running mental list of which stories and examples the candidate has used. If they reach for the same story a second time, flag it after feedback: "You've used [story] for [N] questions now — interviewers notice a thin example set. What's a different example you could use here?" Also check the *close* of each answer: if it lands on a domain that doesn't match the role (e.g., closing on e-commerce when the role is fintech/fraud), note it: "Strong content, but you closed on [wrong domain] — for this role, land the answer on [right domain]."
|
||||
|
||||
---
|
||||
|
||||
### After Each Answer — Structured Feedback
|
||||
|
||||
```markdown
|
||||
**What landed:**
|
||||
- [specific thing that worked — quote their words if possible]
|
||||
- [another strength]
|
||||
|
||||
**What to sharpen:**
|
||||
- [specific gap — what was missing or imprecise]
|
||||
- [vocabulary or framing to improve]
|
||||
|
||||
**The stronger version:**
|
||||
> "[One or two sentences showing how the answer could have opened or closed more effectively]"
|
||||
|
||||
**Status update:** [✅ Strong / 🟡 Solid / 🔴 Gap]
|
||||
```
|
||||
|
||||
Keep feedback tight. One or two things to sharpen per answer — not a full rewrite. The goal is improvement on the next attempt, not discouragement.
|
||||
|
||||
---
|
||||
|
||||
### Feedback Principles
|
||||
|
||||
**Be honest, not encouraging.** "Good answer" without substance wastes the candidate's prep time. If an answer was weak, say so clearly and explain why.
|
||||
|
||||
**Quote their actual words.** "You said 'negotiate between consistency and availability' — the precise term is 'trade off consistency for availability'" is more useful than "use better technical vocabulary."
|
||||
|
||||
**Lead with what landed.** Even a weak answer usually has something right. Naming it first makes the correction land better.
|
||||
|
||||
**Flag vocabulary gaps explicitly.** Expert interviewers notice imprecise language. When the candidate uses a vague term where a precise one exists, call it out by name.
|
||||
|
||||
**The Reflection check.** For behavioral stories, always check: did they include a Reflection? ("What I'd do differently / what I learned.") This is the senior-candidate signal. If it's missing, prompt once after feedback: "What would you do differently knowing what you know now?"
|
||||
|
||||
**Two-minute rule.** If an answer runs past two minutes, note it. Interviewers stop listening. The fix is almost always to state the answer first, then explain — not to cut content. *In a typed session you cannot time delivery — substitute a structure check instead:* flag answers that bury the headline (more than 4–5 sentences of setup before the point lands) and tell the candidate: pacing and filler words can only be diagnosed out loud — record yourself or run this question again verbally.
|
||||
|
||||
**Verify suspicious claims before coaching them.** When the candidate states a specific metric or scope claim (headcount managed, AUM, revenue figure, percentage improvement) that you cannot confirm from prior context, check it against `cv.md`, `article-digest.md`, and `interview-prep/retracted-claims.md` before giving feedback. If the claim isn't supported, flag it: "I can't find that number in your CV — is it defensible if they push? If not, here's a version that doesn't depend on it." Never coach a candidate to repeat a claim they can't back up.
|
||||
|
||||
**Never invent experience or metrics.** The stronger version may only use facts the candidate actually stated, or claims that exist in `cv.md`, `article-digest.md`, or the story bank. Tightening framing is the job — adding accomplishments is fabrication. If a claim appears in `interview-prep/retracted-claims.md`, do not use it in a stronger version even if the candidate said it.
|
||||
|
||||
**Offer to record retractions.** When a candidate concedes mid-session that a claim isn't defensible under pressure ("you're right, I can't back that up"), offer to append it to `interview-prep/retracted-claims.md`: "Want me to add that to your retracted list so it doesn't surface again?" If yes, append: `**"[claim]"** ([context]). Reason: [one-line reason + correct framing if applicable].`
|
||||
|
||||
**When company-intel is thin mid-session.** If the candidate visibly struggles on a "why this company / why this role" question because the role-specific prep file lacks the intel, don't fabricate and don't stay silent. Step out of character, run the `interview-prep` research step for that one question (the same sourced-research path `interview-prep.md` owns), and return with 2–3 concrete, cited angles. Then resume in character. If research yields nothing usable, say so plainly. This is not a second search loop — it is invoking the existing research stage just-in-time when the upstream pipeline wasn't run first.
|
||||
|
||||
**When the candidate disputes a factual claim in the prep materials.** If the candidate challenges a specific fact in the question bank or prep file (e.g., a metric, a product spec, an SLA figure), don't defend the file's authority. Step out of character, verify the claim against primary sources, and correct the source file if the candidate is right. Return with the verified figure and resume. If no primary source can be found, say so and flag the claim as unverified — the candidate should not use an unverifiable fact in a real interview.
|
||||
|
||||
---
|
||||
|
||||
### After All Questions — Session Summary
|
||||
|
||||
```markdown
|
||||
## Practice Session Summary
|
||||
|
||||
**Round type:** [screening / technical / design-case-study / behavioral]
|
||||
**Questions covered:** [N]
|
||||
|
||||
**Ready:**
|
||||
- [question] — [one-line note on why it's strong]
|
||||
|
||||
**Needs work before interview:**
|
||||
- [question] — [specific gap to close]
|
||||
|
||||
**Vocabulary to fix:**
|
||||
- "[what they said]" → "[correct term]"
|
||||
|
||||
**Overall read:** [one honest sentence on interview readiness]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Write Session Transcript
|
||||
|
||||
After the summary, write a machine-readable session transcript to `interview-prep/sessions/{company-slug}-{role-slug}-{round}-{YYYY-MM-DD}.md` (use `practice` for the company/role slug if this wasn't a company-specific session). This is a structured record of the round for downstream analysis modes; the speaker-labelled turns let a consumer read either side without re-inferring who spoke. The full contract lives in `interview-prep/sessions/README.md`.
|
||||
|
||||
Format:
|
||||
|
||||
```markdown
|
||||
---
|
||||
company: [company, or "practice"]
|
||||
role: [role]
|
||||
round: [screen | hiring-manager | technical | system-design | behavioral | onsite | final]
|
||||
date: YYYY-MM-DD
|
||||
interviewer_role: [persona role, if set]
|
||||
source: practice
|
||||
---
|
||||
|
||||
## Q1
|
||||
**Interviewer:** [the question you asked]
|
||||
<!-- competency: tag[, tag...] -->
|
||||
**Candidate:** [the candidate's answer, verbatim]
|
||||
|
||||
## Q2
|
||||
...
|
||||
```
|
||||
|
||||
Rules for the transcript:
|
||||
|
||||
- **Map the round type to the enum** above (recruiter screen → `screen`, HM screen → `hiring-manager`, technical/domain → `technical`, design/case study → `system-design`, behavioral → `behavioral`).
|
||||
- **Tag each answer.** On the line directly above each `**Candidate:**` line, emit `<!-- competency: tag[, tag...] -->` — lowercase-kebab-case, comma-separated for multi-competency answers. You already assessed each answer during the session, so tag from that. Tags are free-form; pick the competency the question actually tested.
|
||||
- **Record the candidate's answer verbatim**, not the "stronger version" — the transcript records what happened, not the coaching.
|
||||
- **`source: practice`.**
|
||||
- The session file lands in a gitignored directory (real names/companies never enter version control); write it without redacting.
|
||||
|
||||
---
|
||||
|
||||
## Question Sets by Round Type
|
||||
|
||||
If no question list is provided, source questions in this order of precedence:
|
||||
|
||||
1. **Real questions from `interview-prep/question-bank.md`** — questions this company (or a prior round) actually asked, captured by debriefs. Highest value: empirically grounded.
|
||||
2. **Sourced questions from the role-specific prep file** — questions interview-prep.md research found and cited. Use them as written; keep their citations out of the session but respect their wording.
|
||||
3. **The default sets below** — generated fallback for a first session with no research yet. Fill bracketed slots from the JD.
|
||||
|
||||
Mix tiers when the higher tiers are thin — e.g., 3 real questions from the bank padded with defaults — but never skip a higher tier that has relevant questions for this round type.
|
||||
|
||||
### Screening — Recruiter (20–30 min)
|
||||
|
||||
A recruiter screen is box-checking, not depth probing. Keep answers crisp; don't over-engineer. The recruiter is verifying fit, comp alignment, and logistics before passing to the hiring manager.
|
||||
|
||||
1. Walk me through your background.
|
||||
2. Why this company / why this role?
|
||||
3. Why are you leaving your current role?
|
||||
4. What are your comp expectations?
|
||||
5. [Logistics: location / hybrid / timeline / work authorization]
|
||||
6. What questions do you have for us?
|
||||
|
||||
**Comp coaching (recruiter screen only).** Watch for the candidate volunteering a salary floor unprompted (e.g., "the minimum I can go to is X"). If they do, flag it after the answer: "You just gave them your floor — that caps your negotiation before it starts. The stronger move is to anchor on a researched target and defer to the package: 'I'm targeting the upper half of the market range for this level — I'd want to understand base, bonus, and equity together before settling on a number.'" If the role-specific prep file defines a comp strategy, follow that; otherwise give only this generic mechanics note — never invent target numbers.
|
||||
|
||||
### Screening — Hiring Manager (30–45 min)
|
||||
|
||||
An HM screen probes leadership philosophy, judgment, and experience depth. Answers can be longer and carry more story weight. The HM is deciding whether to invest rounds of their team's time.
|
||||
|
||||
1. Walk me through your background.
|
||||
2. Why this company / why this role?
|
||||
3. Tell me about the hardest problem you've solved in your field.
|
||||
4. Tell me about a time you faced resistance to a change you proposed.
|
||||
5. What does [title from JD] mean to you?
|
||||
6. How would you describe your approach to your craft?
|
||||
7. [One fundamental concept from the JD — e.g., a core method, framework, regulation, or tool of the discipline]
|
||||
|
||||
Mix in at least 2 situational / forward-looking questions from the set below — these probe judgment and self-awareness, not past stories:
|
||||
|
||||
**Forward-looking / situational:**
|
||||
- "What does success look like for you in the first 90 days?"
|
||||
- "If you join and the team is struggling — missed deadlines, low morale — what's your first move?"
|
||||
- "How do you decide what to delegate vs. what to own yourself?"
|
||||
- "How do you handle a respected colleague who disagrees with a direction you've set?"
|
||||
|
||||
**Self-awareness / growth:**
|
||||
- "What's something you got wrong professionally and what did you learn?"
|
||||
- "What do you need from your manager to do your best work?"
|
||||
- "Where are you still growing in your role?"
|
||||
|
||||
### Technical / Domain-Specific (practitioner, 45–60 min)
|
||||
1. [Core internals of the discipline's main tool or method — e.g., runtime internals for engineering, attribution models for marketing, valuation methods for finance]
|
||||
2. [Established pattern or framework relevant to the role — from the JD]
|
||||
3. [Fundamental building block deep-dive — e.g., a data structure, a statistical test, an accounting principle]
|
||||
4. [Advanced topic the JD emphasizes — the area where depth separates candidates]
|
||||
5. Tell me about a high-stakes failure in your work — how you diagnosed it and what you did.
|
||||
6. How do you raise the quality bar on a team?
|
||||
|
||||
### Design / Case Study (45–60 min)
|
||||
1. Design [a system, process, campaign, or product relevant to the role].
|
||||
2. [Constraint question — how does your design behave when something fails, scales 10x, or loses budget?]
|
||||
3. [Quality/reliability question — how do you guarantee correctness or measure success?]
|
||||
4. Walk me through how you'd know it's working after launch.
|
||||
|
||||
### Behavioral Panel
|
||||
1. Tell me about a time you led a team through a difficult delivery.
|
||||
2. Describe a major failure in production or in market — what happened and what changed after?
|
||||
3. Tell me about a time you influenced direction across teams or stakeholders.
|
||||
4. What does a high-performing team look like to you?
|
||||
5. Tell me about a time you simplified something complex.
|
||||
6. Tell me about a time you solved a problem that wasn't yours to solve.
|
||||
|
||||
---
|
||||
|
||||
## Rules
|
||||
|
||||
- **One question at a time.** Never front-load multiple questions. Real interviewers ask one at a time.
|
||||
- **No hints before the answer.** Don't prime the candidate with "this is about X." Ask cold.
|
||||
- **Honest feedback only.** False encouragement is worse than silence — it sends a candidate into a real interview underprepared.
|
||||
- **No fabricated claims in suggested answers.** Stronger versions draw only on what the candidate said or what's in `cv.md`, `article-digest.md`, or the story bank — never invented experience or metrics.
|
||||
- **Retracted claims are a hard gate.** If a claim appears in `interview-prep/retracted-claims.md`, never use it in a stronger version — even if the candidate said it in their answer. Flag it instead.
|
||||
- **Track status.** Update `interview-prep/question-bank.md` after the session if it exists.
|
||||
- **Stop when asked.** If the candidate says "let's pause" or "that's enough for today," respect it. Don't push for one more question.
|
||||
@@ -0,0 +1,105 @@
|
||||
# career-ops -- Modalità in italiano (`modes/it/`)
|
||||
|
||||
Questa cartella contiene le traduzioni in italiano delle principali modalità di career-ops per i candidati che si rivolgono al mercato italiano.
|
||||
|
||||
## Quando usare queste modalità?
|
||||
|
||||
Usa `modes/it/` se si verifica almeno una di queste condizioni:
|
||||
|
||||
- Ti candidi principalmente ad **annunci di lavoro in italiano** (LinkedIn IT, Indeed IT, portali aziendali)
|
||||
- Il tuo **CV è in italiano** (o alterni tra italiano e inglese a seconda dell'annuncio)
|
||||
- Hai bisogno di risposte e lettere di presentazione scritte in un **italiano tech naturale**, non tradotte da una macchina
|
||||
- Devi gestire **specificità contrattuali italiane**: contratti a tempo indeterminato o determinato, CCNL, TFR, buoni pasto, assicurazione sanitaria integrativa, tredicesima, quattordicesima, periodo di prova, preavviso, permessi retribuiti e inquadramento come Quadro.
|
||||
|
||||
Se la maggior parte delle tue offerte è in inglese, ti conviene rimanere sulle modalità standard in `modes/`. Le modalità in inglese funzionano anche per le offerte in Italia, ma non conoscono in dettaglio le specificità del mercato italiano.
|
||||
|
||||
## Come attivarle?
|
||||
|
||||
### Opzione 1 -- Per singola sessione
|
||||
|
||||
All'inizio della sessione, dì all'agente:
|
||||
|
||||
> "Usa le modalità in italiano sotto `modes/it/`."
|
||||
|
||||
L'agente leggerà quindi i file di questa cartella anziché quelli di `modes/`.
|
||||
|
||||
### Opzione 2 -- In modo permanente
|
||||
|
||||
Aggiungi nel file `config/profile.yml`:
|
||||
|
||||
```yaml
|
||||
language:
|
||||
primary: it
|
||||
modes_dir: modes/it
|
||||
```
|
||||
|
||||
Ricordalo all'agente durante la tua prima sessione ("Guarda in `profile.yml`, ho configurato `language.modes_dir`"). L'agente utilizzerà automaticamente le modalità in italiano.
|
||||
|
||||
## Quali modalità sono tradotte?
|
||||
|
||||
Questa prima iterazione copre le quattro modalità a più alto impatto:
|
||||
|
||||
| File | Tradotto da | Ruolo |
|
||||
|------|-------------|-------|
|
||||
| `_shared.md` | `modes/_shared.md` (EN) | Contesto condiviso, archetipi, regole globali, specificità del mercato italiano |
|
||||
| `annuncio.md` | `modes/oferta.md` (ES) | Valutazione completa di un annuncio di lavoro (Blocchi A-F) |
|
||||
| `candidarsi.md` | `modes/apply.md` (EN) | Assistente live per compilare i moduli di candidatura |
|
||||
| `pipeline.md` | `modes/pipeline.md` (ES) | Inbox di URL / Second Brain per gli annunci raccolti |
|
||||
|
||||
Le altre modalità (`scan`, `batch`, `pdf`, `tracker`, `auto-pipeline`, `deep`, `contacto`, `ofertas`, `project`, `training`) rimangono in inglese/spagnolo. Il loro contenuto riguarda principalmente il tooling, i percorsi e i comandi, e deve rimanere indipendente dalla lingua.
|
||||
|
||||
## Cosa rimane in inglese
|
||||
|
||||
Volutamente non tradotto perché fa parte del vocabolario tecnologico standard:
|
||||
|
||||
- `cv.md`, `pipeline`, `tracker`, `report`, `score`, `archetype`, `proof point`
|
||||
- Nomi degli strumenti (`Playwright`, `WebSearch`, `WebFetch`, `Read`, `Write`, `Edit`, `Bash`)
|
||||
- Valori di stato nel tracker (`Evaluated`, `Applied`, `Interview`, `Offer`, `Rejected`)
|
||||
- Porzioni di codice, percorsi, comandi
|
||||
|
||||
Le modalità utilizzano un italiano tech naturale, come quello parlato nei team di engineering: testo corrente in italiano, termini tecnici in inglese laddove è d'uso comune. Evitiamo traduzioni forzate (ad esempio, lasciamo "Pipeline" invece di "Canalizzazione" o "Deploy" invece di "Dispiegamento").
|
||||
|
||||
## Lessico di riferimento
|
||||
|
||||
Per mantenere un tono coerente se decidi di modificare o estendere le modalità:
|
||||
|
||||
| Inglese | Italiano (in questa codebase) |
|
||||
|---------|-------------------------------|
|
||||
| Job posting | Annuncio di lavoro |
|
||||
| Application | Candidatura |
|
||||
| Cover letter | Lettera di presentazione |
|
||||
| Resume / CV | CV / Curriculum Vitae |
|
||||
| Salary | Stipendio / Retribuzione |
|
||||
| Compensation | Retribuzione |
|
||||
| Skills | Competenze |
|
||||
| Interview | Colloquio |
|
||||
| Hiring manager | Responsabile della selezione |
|
||||
| Recruiter | Recruiter / Selezionatore |
|
||||
| AI | IA (Intelligenza Artificiale) |
|
||||
| Requirements | Requisiti |
|
||||
| Career history | Percorso professionale |
|
||||
| Notice period | Periodo di preavviso |
|
||||
| Probation | Periodo di prova |
|
||||
| Vacation | Ferie |
|
||||
| 13th month salary | Tredicesima |
|
||||
| Permanent contract | Contratto a tempo indeterminato |
|
||||
| Fixed-term contract | Contratto a tempo determinato |
|
||||
| Freelance | Libero Professionista |
|
||||
| Collective agreement | CCNL (Contratto Collettivo Nazionale di Lavoro) |
|
||||
| Works council | RSU / Rappresentanza Sindacale |
|
||||
| Profit sharing | Premio di risultato / MBO / Partecipazione agli utili |
|
||||
| Meal vouchers | Buoni pasto |
|
||||
| Health insurance | Assicurazione sanitaria integrativa / Cassa sanitaria |
|
||||
| Disability/life insurance | Assicurazione vita |
|
||||
| RTT | Permessi retribuiti |
|
||||
| Cadre status | Quadro |
|
||||
|
||||
## Contribuire
|
||||
|
||||
Per migliorare una traduzione o aggiungere una modalità:
|
||||
|
||||
1. Apri una Issue con la tua proposta (vedi `CONTRIBUTING.md`)
|
||||
2. Rispetta il lessico indicato sopra per mantenere un tono coerente
|
||||
3. Traduci in modo idiomatico -- evita traduzioni letterali o da traduttore automatico
|
||||
4. Conserva gli elementi strutturali (Blocchi A-F, tabelle, blocchi di codice, istruzioni strumenti) esattamente come nell'originale
|
||||
5. Esegui un test con un vero annuncio in italiano prima di inviare la PR
|
||||
@@ -0,0 +1,206 @@
|
||||
# Contesto condiviso -- career-ops (Italiano)
|
||||
|
||||
<!-- ============================================================
|
||||
PERSONALIZZAZIONE DI QUESTO FILE
|
||||
============================================================
|
||||
Questo file contiene il contesto condiviso per tutte le modalità
|
||||
career-ops in versione italiana. Prima di usare career-ops, DEVI:
|
||||
1. Compilare config/profile.yml con le tue informazioni personali
|
||||
2. Creare cv.md nella cartella principale del progetto (CV in Markdown)
|
||||
3. (Opzionale) Creare article-digest.md con i tuoi proof point misurabili
|
||||
4. Adattare le sezioni contrassegnate come [PERSONALIZZARE] qui sotto
|
||||
============================================================ -->
|
||||
|
||||
## Fonti di verità (Leggere SEMPRE prima di ogni valutazione)
|
||||
|
||||
| File | Percorso | Quando |
|
||||
|------|----------|--------|
|
||||
| cv.md | `cv.md` (radice del progetto) | SEMPRE |
|
||||
| article-digest.md | `article-digest.md` (se presente) | SEMPRE (proof point dettagliati) |
|
||||
| profile.yml | `config/profile.yml` | SEMPRE (identità e ruoli target) |
|
||||
|
||||
**REGOLA: Non hardcodare MAI metriche provenienti dai proof point.** Leggerle da `cv.md` e `article-digest.md` al momento della valutazione.
|
||||
**REGOLA: Per metriche di articoli/progetti, `article-digest.md` ha priorità su `cv.md`** (`cv.md` può contenere dati meno recenti).
|
||||
|
||||
---
|
||||
|
||||
## North Star -- Ruoli target
|
||||
|
||||
Il sistema tratta TUTTI i ruoli target con la stessa cura. Nessuno è primario o secondario: ognuno è un successo se retribuzione e prospettive di crescita sono in linea:
|
||||
|
||||
| Archetipo | Assi tematici | Cosa compra l'azienda |
|
||||
|-----------|---------------|-----------------------|
|
||||
| **AI Platform / LLMOps Engineer** | Evaluation, Observability, Affidabilità, Pipeline | Qualcuno che porta l'IA in produzione con metriche concrete |
|
||||
| **Agentic Workflows / Automation** | HITL, Tooling, Orchestrazione, Multi-Agent | Qualcuno che costruisce sistemi agentici affidabili |
|
||||
| **Technical AI Product Manager** | GenAI/Agent, PRD, Discovery, Delivery | Qualcuno che traduce il business in prodotti IA |
|
||||
| **AI Solutions Architect** | Iperautomazione, Enterprise, Integrazioni | Qualcuno che progetta architetture IA end-to-end |
|
||||
| **AI Forward Deployed Engineer** | Client-facing, Consegna rapida, Prototipazione | Qualcuno che distribuisce soluzioni IA rapidamente dal cliente |
|
||||
| **AI Transformation Lead** | Change management, Adozione, Enablement | Qualcuno che guida la trasformazione IA nelle organizzazioni |
|
||||
|
||||
<!-- [PERSONALIZZARE] Adatta gli archetipi sopra ai tuoi ruoli target.
|
||||
Esempio per backend engineering:
|
||||
- Senior Backend Engineer
|
||||
- Staff Platform Engineer
|
||||
- Engineering Manager
|
||||
ecc. -->
|
||||
|
||||
### Framing adattivo per archetipo
|
||||
|
||||
> **Metriche concrete: leggerle da `cv.md` e `article-digest.md` al momento della valutazione. Non hardcodarle MAI qui.**
|
||||
|
||||
| Se il ruolo è... | Mettere in evidenza... | Fonti di proof point |
|
||||
|------------------|------------------------|----------------------|
|
||||
| Platform / LLMOps | Esperienza in produzione, observability, evals, closed-loop | article-digest.md + cv.md |
|
||||
| Agentic / Automation | Orchestrazione multi-agent, HITL, affidabilità, ottimizzazione costi | article-digest.md + cv.md |
|
||||
| Technical AI PM | Product discovery, PRD, metriche, gestione degli stakeholder | cv.md + article-digest.md |
|
||||
| Solutions Architect | Progettazione di sistemi, integrazioni, enterprise-ready | article-digest.md + cv.md |
|
||||
| Forward Deployed Engineer | Consegna rapida, vicinanza al cliente, da prototipo a produzione | cv.md + article-digest.md |
|
||||
| AI Transformation Lead | Change management, enablement dei team, adozione | cv.md + article-digest.md |
|
||||
|
||||
<!-- [PERSONALIZZARE] Associa i tuoi progetti/articoli concreti agli archetipi qui sopra -->
|
||||
|
||||
### Narrativa di transizione (usare in TUTTI i framing)
|
||||
|
||||
<!-- [PERSONALIZZARE] Sostituisci con la tua narrativa personale. Esempi:
|
||||
- "SaaS costruita e venduta dopo 5 anni. Ora 100% focus sull'IA applicata in azienda."
|
||||
- "Lead engineer in una startup Series-B durante una crescita x10. In cerca della prossima sfida."
|
||||
- "Transizione dalla consulenza al prodotto. Ricerca di ruoli ad alta responsabilità."
|
||||
Letta da config/profile.yml -> narrative.exit_story -->
|
||||
|
||||
Usare la narrativa di transizione da `config/profile.yml` per inquadrare TUTTI i contenuti:
|
||||
- **Nei summary PDF:** Fare il ponte tra passato e futuro -- "Applica ora le stesse [competenze] al dominio [dell'annuncio]."
|
||||
- **Nelle storie STAR:** Fare riferimento ai proof point di `article-digest.md`.
|
||||
- **Nelle bozze di risposta (Blocco G):** La narrativa di transizione va nella prima risposta.
|
||||
- **Quando l'annuncio menziona "imprenditoriale", "autonomia", "builder", "end-to-end":** È IL differenziatore n.1. Aumentare il peso del match.
|
||||
|
||||
### Vantaggio trasversale
|
||||
|
||||
Inquadrare il profilo come **"Builder tecnico con pratica dimostrabile"**, adattando il framing al ruolo:
|
||||
- Per PM: "Builder che riduce l'incertezza con prototipi veloci, poi rilascia in produzione in modo disciplinato"
|
||||
- Per FDE: "Builder che consegna valore dal giorno 1 con observability e metriche"
|
||||
- Per SA: "Builder che progetta sistemi end-to-end con vera esperienza di integrazione"
|
||||
- Per LLMOps: "Builder che porta l'IA in produzione con sistemi di quality assurance a ciclo chiuso"
|
||||
|
||||
Posizionare "Builder" come segnale professionale -- non come hobby. I proof point reali lo rendono credibile.
|
||||
|
||||
### Portfolio come proof point (usare nelle candidature ad alto impatto)
|
||||
|
||||
<!-- [PERSONALIZZARE] Se hai una demo live, un dashboard o un progetto pubblico, configuralo qui.
|
||||
Esempio:
|
||||
dashboard:
|
||||
url: "https://tuodominio.dev/demo"
|
||||
password: "demo-2026"
|
||||
when_to_share: "Ruoli LLMOps, AI Platform, Observability"
|
||||
Letto da config/profile.yml -> narrative.proof_points e narrative.dashboard -->
|
||||
|
||||
Se il candidato ha una demo live o un dashboard (verificare in `profile.yml`), proporne l'accesso nelle candidature pertinenti.
|
||||
|
||||
### Intelligence sulle retribuzioni (Comp Intelligence)
|
||||
|
||||
<!-- [PERSONALIZZARE] Cerca le fasce retributive per i tuoi ruoli target e adatta i valori -->
|
||||
|
||||
**Consigli generali:**
|
||||
- WebSearch per i dati di mercato attuali (Glassdoor, Levels.fyi, LinkedIn IT, portali locali)
|
||||
- Inquadrare per titolo di ruolo, non per singole competenze -- i titoli definiscono le fasce salariali
|
||||
- Le tariffe per Liberi Professionisti in Italia devono coprire tasse, contributi previdenziali (INPS Gestione Separata o Cassa di categoria), ferie e assenze -- generalmente il 40-60% in più rispetto al costo lordo di un dipendente equivalente
|
||||
- Il geo-arbitraggio funziona anche in remote: costo della vita più basso = risparmio netto maggiore
|
||||
|
||||
### Mercato italiano -- Specificità (IMPORTANTE)
|
||||
|
||||
Negli annunci e nelle trattative in Italia si usano termini e tutele specifici che vanno considerati con precisione:
|
||||
|
||||
| Termine | Significato | Impatto sulla valutazione |
|
||||
|---------|-------------|---------------------------|
|
||||
| **Contratto a tempo indeterminato** | Lavoro permanente. È lo standard in Italia | Standard atteso. Un contratto a termine per un profilo senior è un segnale d'allerta |
|
||||
| **Contratto a tempo determinato** | Contratto con durata prestabilita | Accettabile per progetti specifici. Altrimenti, capire perché non viene offerto l'indeterminato |
|
||||
| **Periodo di prova** | Fase iniziale per verificare la compatibilità (1-6 mesi a seconda del CCNL) | Standard. Segnalare se supera i limiti legali o previsti dal CCNL applicato |
|
||||
| **Periodo di preavviso** | Tempo minimo prima di potersi dimettere (di solito 1-3 mesi) | Da verificare per pianificare la data di inizio del nuovo ruolo |
|
||||
| **Quadro** | Categoria contrattuale per impiegati con mansioni direttive o alta specializzazione | La maggior parte dei ruoli senior/lead nel tech rientra qui. Verificare se menzionato |
|
||||
| **CCNL** (Contratto Collettivo Nazionale) | Accordo quadro di settore (es. Metalmeccanico, Terziario/Commercio). Fissa minimi salariali e scatti | Verificare CCNL e livello proposto per calcolare correttamente superminimo e retribuzione |
|
||||
| **Permessi retribuiti** | Ore di riposo accumulate (es. ex-festività) in aggiunta alle ferie | Un plus concreto da valorizzare nel calcolo del tempo libero annuale |
|
||||
| **Tredicesima** | Mensilità aggiuntiva erogata tipicamente a dicembre | Da includere nel calcolo della RAL (mensile x 13 + superminimo/bonus). Non dimenticarla nei confronti |
|
||||
| **TFR** (Trattamento di Fine Rapporto) | Liquidazione accumulata mensilmente (~7,4% della RAL) e liquidata a fine rapporto | Elemento fondamentale della retribuzione differita nel valore complessivo del pacchetto |
|
||||
| **Premio di risultato / MBO / Partecipazione utili** | Bonus variabili legati a performance individuali o aziendali | Può incrementare significativamente la retribuzione. Verificare i criteri di erogazione |
|
||||
| **Buoni pasto** | Ticket per il pranzo (es. Edenred, Ticket Restaurant), esenti da tasse entro soglie giornaliere | Benefit standard ma concreto. Può valere 1.000-2.000 EUR netti all'anno |
|
||||
| **Assicurazione sanitaria integrativa** | Fondo sanitario previsto dai CCNL (es. Metasalute, Fondo Est) | Standard contrattuale. Verificare se la copertura è estesa al nucleo familiare |
|
||||
| **Assicurazione vita** | Polizza vita obbligatoria secondo CCNL per Dirigenti | Importante da verificare in caso di inquadramento Quadro |
|
||||
| **RSU / Rappresentanza Sindacale** | Organo di rappresentanza sindacale in azienda | Più comune nei grandi gruppi, impatto minore nelle trattative individuali tech |
|
||||
| **Ferie** | Minimo di legge di 4 settimane (20-22 giorni), spesso estese dal CCNL | Sotto il minimo legale è illegale. Ottimo se superiore a 25 giorni più permessi retribuiti |
|
||||
| **Libero Professionista** | Collaborazione a Partita IVA | Alternativa al rapporto di lavoro dipendente. Attenzione alla gestione fiscale (regime forfettario) e alle clausole di esclusività |
|
||||
|
||||
### Script di negoziazione
|
||||
|
||||
<!-- [PERSONALIZZARE] Adatta alla tua situazione -->
|
||||
|
||||
**Aspettative retributive (framework generale):**
|
||||
> "Sulla base dei dati di mercato attuali per questo ruolo, miro a una fascia di [FASCIA da profile.yml] come RAL. Resto flessibile sulla struttura: ciò che conta è il valore complessivo del pacchetto e le prospettive di crescita."
|
||||
|
||||
**Risposta a offerte ridotte per localizzazione:**
|
||||
> "I ruoli per cui sono in selezione sono orientati ai risultati, non alla posizione geografica. Il mio track record non cambia con il codice postale."
|
||||
|
||||
**Se l'offerta è sotto il target:**
|
||||
> "In questo momento sto discutendo con altre aziende pacchetti nella fascia [fascia superiore]. La vostra realtà mi interessa molto per [motivo]. C'è margine per arrivare a [target]?"
|
||||
|
||||
**Chiarimento su Tredicesima / CCNL / Bonus:**
|
||||
> "Per confrontare i pacchetti in modo equo, potremmo dettagliare separatamente la RAL fissa (inclusa la tredicesima ed eventuali superminimi), la parte variabile e gli altri benefit?"
|
||||
|
||||
### Politica di localizzazione (Location Policy)
|
||||
|
||||
<!-- [PERSONALIZZARE] Adatta alla tua situazione. Letta da config/profile.yml -> location -->
|
||||
|
||||
**Nei moduli di candidatura:**
|
||||
- Domande binarie "Puoi lavorare in sede?": rispondere in base alla disponibilità reale in `profile.yml`
|
||||
- Campi liberi: indicare esplicitamente il fuso orario di lavoro e la disponibilità a trasferte
|
||||
|
||||
**Nelle valutazioni (scoring):**
|
||||
- Posizioni ibride fuori dal proprio paese di residenza: punteggio **3.0** (non 1.0)
|
||||
- Punteggio 1.0 solo se l'annuncio dichiara esplicitamente "presenza obbligatoria in sede 4-5 giorni a settimana, nessuna eccezione"
|
||||
|
||||
### Priorità time-to-offer
|
||||
|
||||
- Demo funzionante + metriche > perfezione formale
|
||||
- Candidarsi subito > approfondire all'infinito
|
||||
- Approccio 80/20, ogni attività è in timebox
|
||||
|
||||
---
|
||||
|
||||
## Regole globali
|
||||
|
||||
### MAI
|
||||
|
||||
1. Inventare esperienze o metriche
|
||||
2. Modificare `cv.md` o i file del portfolio
|
||||
3. Inviare candidature a nome del candidato senza il suo consenso
|
||||
4. Condividere un numero di telefono nei messaggi generati
|
||||
5. Raccomandare una retribuzione sotto il mercato
|
||||
6. Generare un PDF senza aver prima letto l'annuncio
|
||||
7. Usare jargon corporate o formule vuote
|
||||
8. Ignorare il tracker (ogni annuncio valutato va registrato)
|
||||
|
||||
### SEMPRE
|
||||
|
||||
0. **Lettera di presentazione:** Se il modulo lo consente, includerla SEMPRE. PDF con lo stesso design visivo del CV. Citazioni dell'annuncio mappate sui proof point. Massimo 1 pagina.
|
||||
1. Leggere `cv.md` e `article-digest.md` (se presente) prima di valutare un annuncio
|
||||
1b. **Prima valutazione di ogni sessione:** eseguire `node cv-sync-check.mjs` via Bash. In caso di avvisi, informare il candidato.
|
||||
2. Rilevare l'archetipo del ruolo e adattare il framing
|
||||
3. Citare righe esatte del CV durante il matching
|
||||
4. Usare WebSearch per dati retributivi e informazioni sull'azienda
|
||||
5. Registrare nel tracker dopo ogni valutazione
|
||||
6. Generare il contenuto nella lingua dell'annuncio (italiano se l'annuncio è in italiano, inglese altrimenti)
|
||||
7. Essere diretti e concreti -- nessun giro di parole
|
||||
8. Italiano tech naturale per i testi generati. Frasi brevi, verbi d'azione, evitare il passivo. Non tradurre forzatamente i termini tecnici (stack, pipeline, deployment, embedding, ecc.)
|
||||
8b. **URL dei case study nel Professional Summary del PDF:** Se il PDF menziona demo o case study, i relativi URL DEVONO comparire nel primo paragrafo (Professional Summary) -- i recruiter spesso leggono solo quello. Tutti gli URL in HTML con `white-space: nowrap`
|
||||
9. **Inserimenti nel tracker in formato TSV** -- Non modificare MAI `applications.md` direttamente per nuovi inserimenti. Scrivere il file TSV in `batch/tracker-additions/`, sarà `merge-tracker.mjs` a gestire la fusione
|
||||
10. **`**URL:**` in ogni intestazione di report** -- inserito tra Score e PDF
|
||||
|
||||
### Strumenti
|
||||
|
||||
| Strumento | Utilizzo |
|
||||
|-----------|----------|
|
||||
| WebSearch | Ricerca retribuzioni, tendenze, cultura aziendale, contatti LinkedIn, fallback annunci |
|
||||
| WebFetch | Fallback per estrarre annunci da pagine statiche |
|
||||
| Playwright | Verificare se gli annunci sono attivi (browser_navigate + browser_snapshot), estrarre annunci da Single Page Application (SPA). **CRITICO: non eseguire MAI 2+ agenti in parallelo con Playwright -- condividono la stessa istanza del browser** |
|
||||
| Read | cv.md, article-digest.md, cv-template.html |
|
||||
| Write | HTML temporaneo per PDF, applications.md, report .md |
|
||||
| Edit | Aggiornare il tracker |
|
||||
| Bash | `node generate-pdf.mjs` |
|
||||
@@ -0,0 +1,166 @@
|
||||
# Modalità: annuncio -- Valutazione completa A-F
|
||||
|
||||
Quando il candidato incolla o fornisce un annuncio di lavoro (testo o URL), fornire SEMPRE i 6 blocchi di valutazione.
|
||||
|
||||
## Blocco 0 -- Rilevamento dell'archetipo
|
||||
|
||||
Classificare l'annuncio in uno dei 6 archetipi di riferimento (vedi `_shared.md`). Se è un ruolo ibrido, indicare i 2 archetipi più vicini. Questa classificazione determina:
|
||||
- Quali proof point prioritizzare nel Blocco B
|
||||
- Come riformulare il summary del CV nel Blocco E
|
||||
- Quali storie STAR preparare nel Blocco F
|
||||
|
||||
## Blocco A -- Riepilogo del ruolo
|
||||
|
||||
Tabella con:
|
||||
- Archetipo rilevato
|
||||
- Settore (Platform / Agentic / LLMOps / ML / Enterprise)
|
||||
- Funzione (Build / Consulenza / Management / Deploy)
|
||||
- Seniority
|
||||
- Localizzazione (Full remote / Ibrido / In sede)
|
||||
- Dimensione del team (se menzionata)
|
||||
- TL;DR in una sola frase
|
||||
|
||||
## Blocco B -- Corrispondenza con il CV
|
||||
|
||||
Leggere `cv.md`. Creare una tabella che mappa ogni requisito dell'annuncio su righe esatte del CV.
|
||||
|
||||
**Adattamento per archetipo:**
|
||||
- FDE -> priorità a proof point su velocità di consegna e vicinanza al cliente
|
||||
- SA -> priorità a progettazione di sistemi e integrazioni complesse
|
||||
- PM -> priorità a product discovery e metriche di prodotto/business
|
||||
- LLMOps -> priorità a evals, observability e pipeline in produzione
|
||||
- Agentic -> priorità a orchestrazione multi-agent, HITL e gestione affidabile degli errori
|
||||
- Transformation -> priorità a change management, enablement e adozione organizzativa
|
||||
|
||||
Aggiungere una sezione **Gap** con strategia di mitigazione per ogni lacuna rilevata:
|
||||
1. È un blocco insormontabile o un nice-to-have?
|
||||
2. Il candidato può dimostrare un'esperienza affine o complementare?
|
||||
3. C'è un progetto nel portfolio che copre questa lacuna?
|
||||
4. Piano di mitigazione concreto (es. frase per la lettera di presentazione, mini-progetto rapido, ecc.)
|
||||
|
||||
## Blocco C -- Inquadramento e strategia
|
||||
|
||||
1. **Livello rilevato** nell'annuncio rispetto al **livello naturale del candidato** per questo archetipo.
|
||||
2. **Piano "valorizzare la seniority in modo autentico"**: formulazioni specifiche per l'archetipo, risultati concreti da evidenziare, come posizionare l'esperienza da founder/imprenditore come valore aggiunto.
|
||||
3. **Piano "se proposto per un livello inferiore (downlevel)"**: accettare solo se la retribuzione è equa, negoziare revisione a 6 mesi, concordare criteri di promozione chiari fin dall'inizio.
|
||||
|
||||
## Blocco D -- Retribuzione e mercato
|
||||
|
||||
Usare WebSearch per raccogliere:
|
||||
- Stipendi attuali per lo stesso ruolo (Glassdoor, Levels.fyi, LinkedIn IT, portali locali)
|
||||
- Reputazione retributiva dell'azienda (Glassdoor, recensioni online)
|
||||
- Andamento della domanda per questo ruolo sul mercato italiano
|
||||
|
||||
Presentare i dati in tabella con le fonti. Se non ci sono dati, dichiararlo esplicitamente -- non inventare.
|
||||
|
||||
**Mercato italiano -- Verifiche obbligatorie:**
|
||||
- La tredicesima / quattordicesima è menzionata? Includerla nel calcolo della RAL.
|
||||
- È prevista una parte variabile (bonus, MBO, stock option)?
|
||||
- Si fa riferimento a Premio di risultato o partecipazione agli utili? Verificare lo storico aziendale.
|
||||
- Quale CCNL viene applicato? Verificare inquadramento e livello contrattuale proposto.
|
||||
- Contratto a tempo indeterminato o determinato? Se determinato: durata, motivazione e possibilità di conversione.
|
||||
- Libero Professionista? Tariffa giornaliera, durata della collaborazione e rischio di contestazione per "falsa Partita IVA" (vincoli di orario e sede).
|
||||
|
||||
## Blocco E -- Piano di personalizzazione
|
||||
|
||||
| # | Sezione | Stato attuale | Modifica proposta | Giustificazione |
|
||||
|---|---------|---------------|-------------------|--------------------|
|
||||
| 1 | Summary | ... | ... | ... |
|
||||
| ... | ... | ... | ... | ... |
|
||||
|
||||
Fornire le 5 modifiche principali al CV + le 5 modifiche principali al profilo LinkedIn per massimizzare il match con l'annuncio.
|
||||
|
||||
## Blocco F -- Piano dei colloqui
|
||||
|
||||
6-10 storie in formato STAR+R mappate sui requisiti dell'annuncio (STAR + **Reflection**):
|
||||
|
||||
| # | Requisito dell'annuncio | Storia STAR+R | S | T | A | R | Reflection |
|
||||
|---|-------------------------|---------------|---|---|---|---|------------|
|
||||
|
||||
La colonna **Reflection** cattura cosa si è imparato o cosa si farebbe diversamente. Questo elemento segnala seniority: i profili junior descrivono cosa è successo, i senior ne traggono insegnamenti e linee guida.
|
||||
|
||||
**Story Bank:** Se `interview-prep/story-bank.md` esiste, verificare se le storie sono già presenti. In caso contrario, aggiungerle. Con il tempo si costruisce un archivio riutilizzabile di 5-10 storie principali adattabili a qualsiasi colloquio.
|
||||
|
||||
**Storie inquadrate per archetipo:**
|
||||
- FDE -> evidenziare velocità di consegna e vicinanza al cliente
|
||||
- SA -> evidenziare decisioni di architettura e trade-off tecnici
|
||||
- PM -> evidenziare product discovery e arbitraggi tra priorità
|
||||
- LLMOps -> evidenziare metriche, evals e hardening in produzione
|
||||
- Agentic -> evidenziare orchestrazione, gestione degli errori e cicli HITL
|
||||
- Transformation -> evidenziare adozione dell'IA e change management su persone e processi
|
||||
|
||||
Includere anche:
|
||||
- 1 case study raccomandato (quale progetto presentare e con quale struttura)
|
||||
- Domande a rischio (red flag) e come rispondere (es. "Perché ha venduto la sua azienda?", "Aveva un team sotto di sé?", "Come mai ha cambiato dopo poco tempo?")
|
||||
|
||||
---
|
||||
|
||||
## Post-valutazione
|
||||
|
||||
Eseguire **SEMPRE** dopo i blocchi A-F:
|
||||
|
||||
### 1. Salvare il report .md
|
||||
|
||||
Salvare la valutazione completa in `reports/{###}-{company-slug}-{YYYY-MM-DD}.md`.
|
||||
|
||||
- `{###}` = prossimo numero sequenziale a 3 cifre, zero-padded. Allocarlo in modo atomico eseguendo `node reserve-report-num.mjs` (restituisce `{###}` su stdout), scrivere il report, poi eseguire `node reserve-report-num.mjs --release {###}` per liberare la prenotazione.
|
||||
- `{company-slug}` = nome dell'azienda in minuscolo senza spazi (usare i trattini)
|
||||
- `{YYYY-MM-DD}` = data odierna
|
||||
|
||||
**Formato del report:**
|
||||
|
||||
```markdown
|
||||
# Valutazione: {Azienda} -- {Ruolo}
|
||||
|
||||
**Data:** {YYYY-MM-DD}
|
||||
**Archetipo:** {rilevato}
|
||||
**Punteggio:** {X/5}
|
||||
**URL:** {URL dell'annuncio}
|
||||
**PDF:** {percorso del file o in attesa}
|
||||
|
||||
---
|
||||
|
||||
## A) Riepilogo del ruolo
|
||||
(contenuto completo del blocco A)
|
||||
|
||||
## B) Corrispondenza con il CV
|
||||
(contenuto completo del blocco B)
|
||||
|
||||
## C) Inquadramento e strategia
|
||||
(contenuto completo del blocco C)
|
||||
|
||||
## D) Retribuzione e mercato
|
||||
(contenuto completo del blocco D)
|
||||
|
||||
## E) Piano di personalizzazione
|
||||
(contenuto completo del blocco E)
|
||||
|
||||
## F) Piano dei colloqui
|
||||
(contenuto completo del blocco F)
|
||||
|
||||
## G) Bozze di risposta per la candidatura
|
||||
(solo se punteggio >= 4.5 -- risposte pronte per i moduli del portale aziendale)
|
||||
|
||||
---
|
||||
|
||||
## Parole chiave estratte
|
||||
(15-20 parole chiave estratte dall'annuncio per il superamento dei filtri ATS)
|
||||
```
|
||||
|
||||
### 2. Registrare nel tracker
|
||||
|
||||
Registrare **SEMPRE** la valutazione in `data/applications.md`:
|
||||
- Prossimo numero sequenziale
|
||||
- Data odierna
|
||||
- Azienda
|
||||
- Ruolo
|
||||
- Punteggio: media del match (da 1 a 5)
|
||||
- Stato: `Evaluated`
|
||||
- PDF: no (o sì se l'auto-pipeline ha generato il PDF direttamente)
|
||||
- Report: link relativo al file del report (es: `[001](reports/001-azienda-2026-01-01.md)`)
|
||||
|
||||
**Formato del tracker:**
|
||||
|
||||
```markdown
|
||||
| # | Data | Azienda | Ruolo | Punteggio | Stato | PDF | Report |
|
||||
```
|
||||
@@ -0,0 +1,114 @@
|
||||
# Modalità: candidarsi -- Assistente live per i moduli di candidatura
|
||||
|
||||
Modalità interattiva per quando il candidato compila un modulo di candidatura (es. su LinkedIn o un portale aziendale). Legge lo schermo, carica il contesto della valutazione precedente dell'annuncio e genera risposte personalizzate per ogni domanda del modulo.
|
||||
|
||||
## Prerequisiti
|
||||
|
||||
- **Ottimale con Playwright visibile:** il candidato vede il browser e l'agente può interagire direttamente con la pagina.
|
||||
- **Senza Playwright:** il candidato condivide uno screenshot o incolla le domande manualmente.
|
||||
|
||||
## Workflow
|
||||
|
||||
```
|
||||
1. RILEVARE -> Leggere la scheda attiva del browser (screenshot/URL/titolo)
|
||||
2. IDENTIFICARE -> Estrarre azienda + ruolo dalla pagina
|
||||
3. CERCARE -> Trovare corrispondenze con i report esistenti in reports/
|
||||
4. CARICARE -> Leggere il report completo + Blocco G (se esiste)
|
||||
5. CONFRONTARE -> Il ruolo a schermo corrisponde a quello valutato? Se cambia -> avvisare
|
||||
6. ANALIZZARE -> Identificare TUTTE le domande visibili nel modulo
|
||||
7. GENERARE -> Per ogni domanda, generare una risposta personalizzata
|
||||
8. PRESENTARE -> Mostrare le risposte formattate pronte per il copia-incolla
|
||||
```
|
||||
|
||||
## Fase 1 -- Rilevare l'annuncio
|
||||
|
||||
**Con Playwright:** Snapshot della pagina attiva. Leggere titolo, URL e contenuto visibile.
|
||||
|
||||
**Senza Playwright:** Chiedere al candidato di:
|
||||
- Condividere uno screenshot del modulo (il Read tool legge il testo dall'immagine)
|
||||
- Oppure incollare le domande in formato testo
|
||||
- Oppure indicare azienda e ruolo per cercare il report corrispondente
|
||||
|
||||
## Fase 2 -- Identificare e caricare il contesto
|
||||
|
||||
1. Estrarre il nome dell'azienda e il titolo del ruolo dalla pagina.
|
||||
2. Cercare in `reports/` per nome azienda (Grep case-insensitive).
|
||||
3. Se c'è corrispondenza -> caricare il report completo.
|
||||
4. Se il Blocco G è presente -> usare le bozze precedenti come base di partenza.
|
||||
5. Se NON c'è corrispondenza -> avvisare il candidato e proporre un auto-pipeline rapido.
|
||||
|
||||
## Fase 3 -- Rilevare variazioni nel ruolo
|
||||
|
||||
Se il ruolo a schermo differisce da quello valutato:
|
||||
- **Avvisare il candidato:** "Il ruolo rilevato è [Y], il report fa riferimento a [X]. Vuoi che riesegua la valutazione o che adatti le risposte al nuovo titolo?"
|
||||
- **Se adattare:** Aggiornare le risposte al nuovo ruolo senza rieseguire la valutazione completa.
|
||||
- **Se rivalutare:** Avviare la valutazione completa A-F, aggiornare il report e rigenerare il Blocco G.
|
||||
- **Aggiornare il tracker:** Modificare il titolo del ruolo in `applications.md` se necessario.
|
||||
|
||||
## Fase 4 -- Analizzare le domande del modulo
|
||||
|
||||
Identificare tutte le domande visibili a schermo:
|
||||
- Campi di testo libero (lettera di presentazione, "perché questa posizione", motivazione, ecc.)
|
||||
- Elenchi a discesa (come hai conosciuto l'azienda, permessi di lavoro, ecc.)
|
||||
- Domande Sì/No (disponibilità al trasferimento, necessità di visto, disponibilità temporale, ecc.)
|
||||
- Campi retribuzione (retribuzione desiderata -- indicare la RAL in euro per l'Italia)
|
||||
- Campi di upload (CV, lettera di presentazione PDF, referenze)
|
||||
|
||||
Classificare ogni domanda:
|
||||
- **Già nel Blocco G:** riprendere la risposta esistente
|
||||
- **Nuova domanda:** generare la risposta partendo dal report e da `cv.md`
|
||||
|
||||
## Fase 5 -- Generare le risposte
|
||||
|
||||
Per ogni domanda, costruire la risposta seguendo questo schema:
|
||||
|
||||
1. **Contesto del report:** usare i proof point del Blocco B e le storie STAR del Blocco F.
|
||||
2. **Blocco G precedente:** se esiste una bozza, usarla come base e affinarla.
|
||||
3. **Tono "Vi scelgo":** sicuro e professionale, non implorante né puramente descrittivo.
|
||||
4. **Specificità:** citare qualcosa di concreto dell'annuncio visibile a schermo.
|
||||
5. **career-ops proof point:** includerlo nel campo "Informazioni aggiuntive" se presente nel modulo.
|
||||
|
||||
**Campi specifici per i moduli di candidatura italiani:**
|
||||
- **Retribuzione desiderata (RAL):** fascia definita in `profile.yml` in euro, con l'aggiunta "negoziabile in base al pacchetto complessivo di benefit e welfare".
|
||||
- **Data di disponibilità:** data realistica tenendo conto del periodo di preavviso (di solito 1-3 mesi).
|
||||
- **Permesso di lavoro / Cittadinanza:** risposte concise; per i cittadini italiani/UE: "Nessun visto richiesto (cittadino UE)".
|
||||
- **Lingue:** livelli secondo il Quadro Comune Europeo di Riferimento (QCER, A1-C2).
|
||||
- **Mobilità:** specificare le aree geografiche accettabili e la frequenza massima delle trasferte (es. "disponibile a trasferte fino al 20% del tempo").
|
||||
|
||||
**Formato di output:**
|
||||
|
||||
```
|
||||
## Risposte per [Azienda] -- [Ruolo]
|
||||
|
||||
Base: Report #NNN | Punteggio: X.X/5 | Archetipo: [tipo]
|
||||
|
||||
---
|
||||
|
||||
### 1. [Domanda esatta del modulo]
|
||||
> [Risposta pronta per il copia-incolla]
|
||||
|
||||
### 2. [Domanda successiva]
|
||||
> [Risposta]
|
||||
|
||||
...
|
||||
|
||||
---
|
||||
|
||||
Note:
|
||||
- [Osservazioni sul ruolo, variazioni, ecc.]
|
||||
- [Suggerimenti di personalizzazione che il candidato dovrebbe verificare]
|
||||
```
|
||||
|
||||
## Fase 6 -- Dopo la candidatura (opzionale)
|
||||
|
||||
Se il candidato conferma di aver inviato il modulo:
|
||||
1. Aggiornare lo stato in `applications.md` da "Evaluated" a "Applied".
|
||||
2. Aggiornare il Blocco G del report con le risposte effettivamente inviate.
|
||||
3. Suggerire il passo successivo: `/career-ops contacto` per avviare il contatto su LinkedIn con il responsabile della selezione.
|
||||
|
||||
## Gestione dello scorrimento
|
||||
|
||||
Se il modulo contiene più domande rispetto a quelle visibili:
|
||||
- Chiedere al candidato di scorrere la pagina e condividere un altro screenshot.
|
||||
- Oppure incollare le domande restanti.
|
||||
- Procedere per iterazioni fino a coprire l'intero modulo.
|
||||
@@ -0,0 +1,62 @@
|
||||
# Modalità: pipeline -- Inbox degli URL (Second Brain)
|
||||
|
||||
Elabora gli URL degli annunci accumulati in `data/pipeline.md`. Il candidato aggiunge gli URL quando vuole, poi esegue `/career-ops pipeline` per elaborarli tutti in una volta.
|
||||
|
||||
## Workflow
|
||||
|
||||
1. **Leggere** `data/pipeline.md` -> trovare gli elementi contrassegnati come `- [ ]` nella sezione "In attesa" / "Pending" / "Pendientes" / "En attente"
|
||||
2. **Per ogni URL in attesa**:
|
||||
a. Riservare il prossimo `REPORT_NUM` sequenziale eseguendo `node reserve-report-num.mjs` (liberare la prenotazione con `node reserve-report-num.mjs --release <num>` una volta scritto il report)
|
||||
b. **Estrarre l'annuncio** con Playwright (`browser_navigate` + `browser_snapshot`) -> WebFetch -> WebSearch
|
||||
c. Se l'URL non è accessibile -> contrassegnarlo come `- [!]` con una nota e passare al successivo
|
||||
d. **Auto-pipeline completo**: Valutazione A-F -> Report .md -> PDF (se punteggio >= 3.0) -> Tracker
|
||||
e. **Spostare da "In attesa" a "Elaborati"**: `- [x] #NNN | URL | Azienda | Ruolo | Punteggio/5 | PDF sì/no`
|
||||
3. **Se ci sono 3+ URL in attesa**, avviare gli agenti in parallelo (strumento Agent con `run_in_background`) per massimizzare la velocità.
|
||||
4. **Al termine**, mostrare una tabella riassuntiva:
|
||||
|
||||
```
|
||||
| # | Azienda | Ruolo | Punteggio | PDF | Azione raccomandata |
|
||||
```
|
||||
|
||||
## Formato di pipeline.md
|
||||
|
||||
```markdown
|
||||
## In attesa
|
||||
- [ ] https://jobs.example.com/posting/123
|
||||
- [ ] https://boards.greenhouse.io/company/jobs/456 | Azienda SRL | Senior PM
|
||||
- [!] https://private.url/job -- Errore: richiesto login
|
||||
|
||||
## Elaborati
|
||||
- [x] #143 | https://jobs.example.com/posting/789 | Acme SRL | AI PM | 4.2/5 | PDF sì
|
||||
- [x] #144 | https://boards.greenhouse.io/xyz/jobs/012 | BigCo | SA | 2.1/5 | PDF no
|
||||
```
|
||||
|
||||
> Nota: Le intestazioni delle sezioni possono essere in inglese ("Pending"/"Processed"), spagnolo ("Pendientes"/"Procesadas"), tedesco ("Offen"/"Verarbeitet"), francese ("En attente"/"Traitees") o italiano ("In attesa"/"Elaborati"). Flessibili in lettura, fedeli allo stile esistente in scrittura.
|
||||
|
||||
## Rilevamento dell'annuncio dall'URL
|
||||
|
||||
1. **Playwright (preferito):** `browser_navigate` + `browser_snapshot`. Funziona con tutte le Single Page Application (SPA).
|
||||
2. **WebFetch (fallback):** Per le pagine statiche o quando Playwright non è disponibile.
|
||||
3. **WebSearch (ultima risorsa):** Per cercare su portali secondari che indicizzano l'annuncio.
|
||||
|
||||
**Casi particolari:**
|
||||
- **LinkedIn:** può richiedere login -> contrassegnare come `[!]` e chiedere al candidato di incollare il testo dell'annuncio
|
||||
- **PDF:** se l'URL punta a un PDF, leggerlo direttamente con il Read tool
|
||||
- **Prefisso `local:`:** legge un file locale. Esempio: `local:jds/linkedin-pm-ai.md` -> legge `jds/linkedin-pm-ai.md`
|
||||
- **Indeed IT / LinkedIn IT:** portali molto diffusi in Italia. Playwright gestisce bene i cookie banner.
|
||||
|
||||
## Numerazione automatica
|
||||
|
||||
1. Eseguire `node reserve-report-num.mjs` per riservare in modo atomico il prossimo numero sequenziale (restituisce `{###}` su stdout).
|
||||
2. Scrivere il report con questo numero.
|
||||
3. Liberare la prenotazione con `node reserve-report-num.mjs --release {###}` una volta scritto il report.
|
||||
|
||||
## Sincronizzazione delle fonti
|
||||
|
||||
Prima di elaborare un URL, verificare la sincronizzazione:
|
||||
|
||||
```bash
|
||||
node cv-sync-check.mjs
|
||||
```
|
||||
|
||||
In caso di desincronizzazione, avvisare il candidato prima di procedere.
|
||||
@@ -0,0 +1,114 @@
|
||||
# career-ops -- 日本語モード (`modes/ja/`)
|
||||
|
||||
このフォルダには、日本市場または日本語で運営される企業での求職活動を行う候補者向けに、career-ops の主要モードを日本語に翻訳したファイルが含まれています。
|
||||
|
||||
## いつこれらのモードを使うか？
|
||||
|
||||
以下のいずれかに該当する場合は `modes/ja/` を使用してください：
|
||||
|
||||
- 主に**日本語の求人**（Wantedly、Green、doda、リクナビNEXT、ビズリーチ、LinkedIn JP、Indeed JP、Findy など）に応募している
|
||||
- **履歴書・職務経歴書の言語**が日本語、または求人に応じて日本語と英語を使い分けている
|
||||
- 機械翻訳ではない、**自然な日本語のテック系表現**で書かれた回答やカバーレターが必要
|
||||
- **日本市場特有の事項**に対応する必要がある：正社員 vs 業務委託、賞与（ボーナス）、退職金、有給休暇、試用期間、36協定、通勤手当、住宅手当、みなし残業、年俸制など
|
||||
|
||||
ほとんどの求人が英語の場合は、デフォルトの `modes/` を使ってください。英語モードでも Claude が日本語の求人を検出すれば自動的に対応しますが、日本市場の細かい慣習までは同じレベルで把握していません。
|
||||
|
||||
## どうやって有効化する？
|
||||
|
||||
career-ops にはコード上の「言語スイッチ」フラグはありません。代わりに 2 つの方法があります：
|
||||
|
||||
### 方法 1 -- セッション単位で指示
|
||||
|
||||
セッションの冒頭で Claude にこう伝えます：
|
||||
|
||||
> 「`modes/ja/` の日本語モードを使って。」
|
||||
|
||||
または
|
||||
|
||||
> 「評価と応募を日本語で。`modes/ja/_shared.md` と `modes/ja/kyujin.md` を読んで。」
|
||||
|
||||
Claude は `modes/` の代わりにこのフォルダのファイルを読み込みます。
|
||||
|
||||
### 方法 2 -- プロファイルで恒久設定
|
||||
|
||||
`config/profile.yml` に言語設定を追加します：
|
||||
|
||||
```yaml
|
||||
language:
|
||||
primary: ja
|
||||
modes_dir: modes/ja
|
||||
```
|
||||
|
||||
最初のセッションで Claude にこのフィールドを尊重するよう伝えてください（「`profile.yml` を見て、`language.modes_dir` を設定してある」）。以降、Claude は自動的に日本語モードを使用します。
|
||||
|
||||
> 注：`language.modes_dir` は慣習であり厳密なスキーマではありません。メンテナが別の構造にしたい場合、このフィールド名はいつでも変更される可能性があります。
|
||||
|
||||
## 何が翻訳されているか？
|
||||
|
||||
この最初のイテレーションでは、インパクトの大きい 4 つのモードをカバーしています：
|
||||
|
||||
| ファイル | 翻訳元 | 用途 |
|
||||
|---------|-------|------|
|
||||
| `_shared.md` | `modes/_shared.md` (EN) | 共通コンテキスト、アーキタイプ、グローバルルール、日本市場の特記事項 |
|
||||
| `kyujin.md` | `modes/oferta.md` (EN) | 求人の完全評価（A-F + G legitimacy ブロック） |
|
||||
| `oubo.md` | `modes/apply.md` (EN) | 応募フォーム記入のライブアシスタント |
|
||||
| `pipeline.md` | `modes/pipeline.md` (EN) | URL のインボックス / 求人の Second Brain |
|
||||
|
||||
残りのモード（`scan`、`batch`、`pdf`、`tracker`、`auto-pipeline`、`deep`、`contacto`、`ofertas`、`project`、`training`）は意図的にこの PR に含めていません。これらは主にツール配管、パス、設定コマンドで構成されており、言語非依存であるべきだからです。
|
||||
|
||||
コミュニティが日本語モードを採用すれば、今後の PR でさらにモードを翻訳します。
|
||||
|
||||
## 英語のまま残しているもの
|
||||
|
||||
これらは意図的に翻訳していません。標準的なテック用語だからです：
|
||||
|
||||
- `cv.md`、`pipeline`、`tracker`、`report`、`score`、`archetype`、`proof point`
|
||||
- ツール名（`Playwright`、`WebSearch`、`WebFetch`、`Read`、`Write`、`Edit`、`Bash`）
|
||||
- tracker のステータス値（`Evaluated`、`Applied`、`Interview`、`Offer`、`Rejected`）
|
||||
- コードスニペット、ファイルパス、コマンド
|
||||
|
||||
モードは、東京・大阪・福岡の実際のエンジニアリングチームで使われているような自然な日本語テック表現を使います：地の文は日本語、定着しているテック用語は英語のままです。「pipeline」を「配管」と訳したり、「cv.md」を「履歴書.md」にしたりはしません。
|
||||
|
||||
## 参考用語集
|
||||
|
||||
モードを拡張・改変する際は、トーンの一貫性を保つためこの用語を参考にしてください：
|
||||
|
||||
| 英語 | 日本語（このコードベース） |
|
||||
|-----|--------------------------|
|
||||
| Job posting | 求人 / 求人票 / 職務記述書 |
|
||||
| Application | 応募 |
|
||||
| Cover letter | カバーレター / 志望動機書 |
|
||||
| Resume / CV | 履歴書 / 職務経歴書 |
|
||||
| Salary | 給与 / 年収 |
|
||||
| Compensation | 報酬 / 待遇 |
|
||||
| Skills | スキル |
|
||||
| Interview | 面接 |
|
||||
| Hiring manager | 採用責任者 / Hiring manager |
|
||||
| Recruiter | 採用担当 / リクルーター |
|
||||
| AI | AI（人工知能） |
|
||||
| Requirements | 必須要件 / 歓迎要件 |
|
||||
| Career history | 職務経歴 |
|
||||
| Notice period | 退職予告期間 |
|
||||
| Probation | 試用期間 |
|
||||
| Vacation | 有給休暇 |
|
||||
| Bonus | 賞与 / ボーナス |
|
||||
| Full-time employment | 正社員 |
|
||||
| Contractor | 業務委託 / フリーランス |
|
||||
| Annual salary | 年俸制 |
|
||||
| Health insurance | 健康保険 |
|
||||
| Overtime allowance | 残業代 / 時間外手当 |
|
||||
| Fixed overtime | みなし残業 |
|
||||
| Commuting allowance | 通勤手当 |
|
||||
| Housing allowance | 住宅手当 |
|
||||
| Stock options | ストックオプション（そのまま使用） |
|
||||
| Severance | 退職金 |
|
||||
|
||||
## 貢献方法
|
||||
|
||||
翻訳を改善したり、追加のモードを翻訳したりしたい場合：
|
||||
|
||||
1. `CONTRIBUTING.md` に沿って issue を立てて提案する
|
||||
2. トーンの一貫性のため上記の用語集に従う
|
||||
3. 自然で慣用的な翻訳を行う — 一語一語の直訳はしない
|
||||
4. 構造要素（A-F + G ブロック、テーブル、コードブロック、ツール指示）は原文と完全に一致させる
|
||||
5. PR を出す前に実際の日本の求人（Wantedly や LinkedIn JP など）でテストする
|
||||
@@ -0,0 +1,284 @@
|
||||
# 共通コンテキスト -- career-ops（日本語）
|
||||
|
||||
<!-- ============================================================
|
||||
THIS FILE IS AUTO-UPDATABLE. Don't put personal data here.
|
||||
|
||||
Your customizations go in modes/_profile.md (never auto-updated).
|
||||
This file contains system rules, scoring logic, and tool config
|
||||
that improve with each career-ops release.
|
||||
============================================================ -->
|
||||
|
||||
## 真実のソース（EXCLUSIVE）
|
||||
|
||||
以下のファイルだけが、ユーザー向けコンテンツ（CV、カバーレター、フォーム回答、リクルーター向けメッセージ）の情報源です。Auto-memory、親ディレクトリの repo、セッションをまたいだ推測は対象外です。完全なルールは `AGENTS.md` / `CLAUDE.md` の "Source-of-Truth Boundary" を参照してください。
|
||||
|
||||
| ファイル | パス | いつ |
|
||||
|---------|------|------|
|
||||
| cv.md | `cv.md`（プロジェクトルート） | 常に |
|
||||
| article-digest.md | `article-digest.md`（存在する場合） | 常に（詳細な proof points） |
|
||||
| profile.yml | `config/profile.yml` | 常に（候補者の identity と target） |
|
||||
| _profile.md | `modes/_profile.md` | 常に（ユーザー固有のアーキタイプ、ナラティブ、交渉） |
|
||||
| writing-samples/ | `writing-samples/` | 候補者が外部に出す文章を生成する場合。まず `_profile.md` のキャッシュ済み `## Writing Style` を確認し、存在しない場合だけファイルを読む |
|
||||
| voice-dna.md | `voice-dna.md`（プロジェクトルート、存在する場合） | 候補者が外部に出す文章を生成する場合。AI っぽさを避ける guardrail + voice。下の Voice DNA precedence を参照 |
|
||||
| interview-prep | `interview-prep/story-bank.md`, `interview-prep/{company}-{role}.md` | ATS フォーム回答 / 面接コンテンツを生成する場合。ユーザー自身の STAR stories と prep notes（`cv.md` と同じ信頼レベル）。`apply` / `match-star` と interview modes が使用 |
|
||||
|
||||
**ルール：proof point のメトリクスを絶対にハードコードしない。** 評価時に `cv.md` と `article-digest.md` から読み取ること。
|
||||
**ルール：記事・プロジェクトのメトリクスは、`article-digest.md` が `cv.md` より優先される。**
|
||||
**ルール：このファイルの後に `_profile.md` を読む。`_profile.md` のユーザーカスタマイズはここのデフォルト値を上書きする。**
|
||||
**ルール：`cv.md` または `article-digest.md` で明示されていない限り、ユーザーが project、repo、library、tool、framework、open-source artifact を authored したと主張してはならない。** 「使ったツール」を「作ったもの」と混同するのが最も多い捏造パターンであり、禁止。
|
||||
**ルール：Keywords get reformulated, never fabricated.** 並べ替える、言い換える、強調するのはよい。ただし発明しない。根拠が in-scope file にない claim はユーザーに確認する。答えがない場合は省く。沈黙は捏造よりよい。
|
||||
|
||||
---
|
||||
|
||||
## スコアリングシステム
|
||||
|
||||
評価は 6 ブロック（A-F）と 1-5 の global score で行う：
|
||||
|
||||
| Dimension | 測定する内容 |
|
||||
|-----------|-------------|
|
||||
| Match con CV | スキル、経験、proof point の整合 |
|
||||
| North Star alignment | 求人がユーザーの target archetypes（`_profile.md` より）にどれだけ合うか |
|
||||
| Comp | 給与 vs 市場（5=上位四分位、1=大幅に下回る） |
|
||||
| Cultural signals | 企業文化、成長性、安定性、remote policy |
|
||||
| Red flags | ブロッカー、警告（negative adjustments） |
|
||||
| **Global** | 上記の weighted average |
|
||||
|
||||
**Score interpretation:**
|
||||
- 4.5+ → 強いマッチ、今すぐ応募を推奨
|
||||
- 4.0-4.4 → 良好なマッチ、応募する価値あり
|
||||
- 3.5-3.9 → まずまずだが理想ではない、特別な理由がある場合のみ応募
|
||||
- Below 3.5 → 応募非推奨（AGENTS.md の Ethical Use を参照）
|
||||
|
||||
## Posting Legitimacy (Block G)
|
||||
|
||||
Block G は、求人が real, active opening である可能性を評価する。1-5 の global score には影響しない。独立した qualitative assessment として扱う。
|
||||
|
||||
**Three tiers:**
|
||||
- **High Confidence** -- Real, active opening（多くの signal が positive）
|
||||
- **Proceed with Caution** -- Mixed signals, worth noting（一部懸念あり）
|
||||
- **Suspicious** -- 複数の ghost indicator があり、ユーザーが先に確認すべき
|
||||
|
||||
**Key signals（reliability で重み付け）:**
|
||||
|
||||
| Signal | Source | Reliability | Notes |
|
||||
|--------|--------|-------------|-------|
|
||||
| Posting age | Page snapshot | High | Under 30d=good, 30-60d=mixed, 60d+=concerning（role type に応じて調整） |
|
||||
| Apply button active | Page snapshot | High | 直接観測できる事実 |
|
||||
| Tech specificity in JD | JD text | Medium | Generic JDs は ghost postings と相関するが、単に書き方が粗い場合もある |
|
||||
| Requirements realism | JD text | Medium | 矛盾は強い signal、曖昧さは弱い signal |
|
||||
| Recent layoff news | WebSearch | Medium | department、timing、company size を考慮する |
|
||||
| Reposting pattern | scan-history.tsv | Medium | 同じ role が 90 日以内に 2 回以上 repost されていれば concerning |
|
||||
| Salary transparency | JD text | Low | jurisdiction-dependent。非公開には legitimate reasons が多い |
|
||||
| Role-company fit | Qualitative | Low | 主観的。supporting signal としてのみ使う |
|
||||
|
||||
**Ethical framing（MANDATORY）:**
|
||||
- ユーザーが real opportunities に時間を優先配分するための補助
|
||||
- 企業を dishonest と非難する形で提示しない
|
||||
- Signals を提示し、判断はユーザーに委ねる
|
||||
- Concerning signals には必ず legitimate explanations も添える
|
||||
|
||||
## Archetype Detection
|
||||
|
||||
すべての求人を以下の type のいずれか（または 2 つの hybrid）に分類する：
|
||||
|
||||
| Archetype | Key signals in JD |
|
||||
|-----------|-------------------|
|
||||
| AI Platform / LLMOps | "observability", "evals", "pipelines", "monitoring", "reliability" |
|
||||
| Agentic / Automation | "agent", "HITL", "orchestration", "workflow", "multi-agent" |
|
||||
| Technical AI PM | "PRD", "roadmap", "discovery", "stakeholder", "product manager" |
|
||||
| AI Solutions Architect | "architecture", "enterprise", "integration", "design", "systems" |
|
||||
| AI Forward Deployed | "client-facing", "deploy", "prototype", "fast delivery", "field" |
|
||||
| AI Transformation | "change management", "adoption", "enablement", "transformation" |
|
||||
|
||||
Archetype を検出した後、`modes/_profile.md` を読み、該当 archetype に対するユーザー固有の framing と proof points を使う。
|
||||
|
||||
## 日本市場 -- 特記事項（重要）
|
||||
|
||||
日本の求人や交渉には、英語圏の求人だけでは出てこない用語や慣習がある。評価では以下を正しく扱う：
|
||||
|
||||
| 用語 | 意味 | 評価への影響 |
|
||||
|-----|------|-------------|
|
||||
| **正社員** | 無期雇用の正規雇用。社会保険、有給、賞与、退職金の対象 | 総額比較では年間報酬 = 月給 x 12 + 賞与（通常 2-6 ヶ月分）で計算 |
|
||||
| **業務委託（フリーランス）** | 請負契約、個人事業主として働く | 月額が高く見えても社会保険・賞与・退職金なし。公正な比較のため正社員換算を計算 |
|
||||
| **賞与 / ボーナス** | 年 2 回（夏・冬）支給される追加給与 | 正社員では給与の大きな割合。年収 = 月給 x（12 + 賞与月数）。比較で忘れない |
|
||||
| **年俸制** | 年間総額を 12 または 14-16 で割る方式 | 賞与が年俸に含まれる場合があるため、内訳を確認 |
|
||||
| **みなし残業 / 固定残業代** | 一定時間分の残業代があらかじめ月給に含まれる方式 | 何時間分か、超過分が別途支払われるかを確認。Red flag になり得る |
|
||||
| **36 協定** | 時間外労働に関する労使協定 | 残業時間の上限を規定。働き方の健全性を測る signal |
|
||||
| **試用期間** | 通常 3-6 ヶ月 | 日本では標準的。単体では red flag ではない |
|
||||
| **退職金** | 退職時に支給される一時金 | 大企業・伝統企業で一般的。スタートアップでは少ない。長期前提の待遇 |
|
||||
| **通勤手当** | 通勤交通費の実費支給 | 日本では標準的。上限（月 5 万円など）を確認 |
|
||||
| **住宅手当 / 家賃補助** | 住居関連の手当 | 大企業や一部スタートアップで提供。月 2-10 万円程度 |
|
||||
| **健康保険 / 厚生年金** | 社会保険（正社員は強制加入、会社が半分負担） | 正社員の隠れた報酬。業務委託との比較で重要 |
|
||||
| **有給休暇** | 法定最低 10-20 日/年 | 取得率を確認。低すぎると red flag |
|
||||
| **退職予告** | 正社員は通常 1-2 ヶ月前に通知 | 開始日を現職の退職予告期間込みで考える |
|
||||
| **ストックオプション** | スタートアップの equity | vesting、cliff、税制（税制適格 vs 非適格）を評価 |
|
||||
|
||||
## グローバルルール
|
||||
|
||||
### 絶対にしない
|
||||
|
||||
1. 経験やメトリクスを捏造する
|
||||
2. `cv.md` やポートフォリオファイルを変更する
|
||||
3. 候補者の代わりに応募を送信する
|
||||
4. 生成メッセージで電話番号を共有する
|
||||
5. 市場以下の報酬を推奨する
|
||||
6. 求人を読まずに PDF を生成する
|
||||
7. corporate-speak を使う
|
||||
8. tracker を無視する（評価したすべての求人を記録する）
|
||||
|
||||
### 常にする
|
||||
|
||||
0. **Cover letter:** フォームが許可する場合は必ず含める。CV と同じ visual design。JD quotes を proof points に mapping。最大 1 ページ。
|
||||
1. 評価前に `cv.md`、`_profile.md`、`article-digest.md`（存在する場合）を読む
|
||||
1b. **各セッションの最初の評価で:** `node cv-sync-check.mjs` を実行。warnings があればユーザーに知らせる
|
||||
2. 求人の archetype を検出し、`_profile.md` に従って framing を適応させる
|
||||
3. マッチング時、CV の exact lines を引用する
|
||||
4. comp と company data のために WebSearch を使う
|
||||
5. 評価後に tracker に登録する
|
||||
6. 求人の言語で生成する（EN default）
|
||||
7. 直接的で actionable に書く。fluff を避ける
|
||||
8. 日本語で生成する場合は、自然な tech Japanese を使う。短い文、action verbs、不要な受動態を避ける
|
||||
8b. PDF Professional Summary に case study URLs を含める（recruiter はそこだけ読む可能性がある）
|
||||
9. **Tracker additions as TSV** -- `applications.md` を新規追加のために直接編集しない。`batch/tracker-additions/` に TSV を書く
|
||||
10. **すべての report header に `**URL:**` を含める**
|
||||
|
||||
### Tools
|
||||
|
||||
| Tool | Use |
|
||||
|------|-----|
|
||||
| WebSearch | Comp research, trends, company culture, LinkedIn contacts, fallback for JDs |
|
||||
| WebFetch | Static pages から JD を抽出する fallback |
|
||||
| Playwright | 求人検証（browser_navigate + browser_snapshot）。**NEVER 2+ agents with Playwright in parallel.** |
|
||||
| Read | cv.md, _profile.md, article-digest.md, cv-template.html |
|
||||
| Write | Temporary HTML for PDF, applications.md, reports .md |
|
||||
| Edit | tracker 更新 |
|
||||
| Canva MCP | Optional visual CV generation. Base design を duplicate し、text を edit して PDF export。`profile.yml` の `cv.canva_resume_design_id` が必要 |
|
||||
| Bash | `node generate-pdf.mjs` |
|
||||
|
||||
### Time-to-offer priority
|
||||
- Working demo + metrics > perfection
|
||||
- Apply sooner > learn more
|
||||
- 80/20 approach, timebox everything
|
||||
|
||||
---
|
||||
|
||||
## Voice DNA (writing guardrail)
|
||||
|
||||
`voice-dna.md` が project root に存在する場合、生成文章の guardrail として使う。これは user-layer で optional。存在を仮定しない。なければ静かに skip する。これはユーザー個人の style の下に置かれる。AI っぽさを抑え、足りない部分を補うが、`_profile.md` にあるユーザー自身の voice rules を常に優先する（Precedence を参照）。
|
||||
|
||||
**Two-tier scope（CV の正確性を守るための分離）:**
|
||||
|
||||
- **Tier 1 -- anti-AI-slop guardrail**（voice-dna §3 Banned List、§4 Patterns to Avoid: banned words、dead phrases、no em-dashes、no negative parallelisms、formatting rules）。HARD RULES。CV bullets と Professional Summary を含む **all generated text** に適用する。
|
||||
- **Tier 2 -- conversational voice**（voice-dna §1-2: contractions、And/But sentence openers、"I think" / "maybe" のような hedging、parenthetical asides、direct "I"/"you"）。cover letters、LinkedIn outreach、follow-up emails など conversational candidate-facing prose のみに適用する。**CV/ATS text**（PDF bullets、Professional Summary）には Tier 2 を適用しない。そこでは formal, keyword-dense register を維持する。
|
||||
|
||||
**Accuracy always wins over style.** `cv.md` と `article-digest.md` の facts は voice-dna によって上書きされない。実在する metric を rhythm のために落とす、弱める、hedge することはしない。人間らしく見せるために detail を発明しない。voice-dna は wording を shaping するだけで content を変えない。
|
||||
|
||||
**Precedence with personal style（`_profile.md` always wins）:** `_profile.md` の `## Writing Style` が voice と tone の authority。`voice-dna.md` と `_profile.md` が衝突する場合は `_profile.md` が勝つ。例：`_profile.md` が em-dashes を使う style なら、voice-dna が避けるとしていても維持する。voice-dna の anti-AI-slop rules は `_profile.md` が silent な箇所にだけ適用する。`voice-dna.md` 自体も user file なので、strict guardrail を優先したいユーザーはその preference を `_profile.md` に書かなければよい。
|
||||
|
||||
---
|
||||
|
||||
## Writing Style Calibration
|
||||
|
||||
**まず `_profile.md` を確認する。** そこに `## Writing Style` section がある場合は直接使い、`writing-samples/` を再スキャンしない。再スキャンは new samples が追加された場合、またはユーザーが明示的に recalibrate を求めた場合のみ。
|
||||
|
||||
**When to apply:** ユーザーが送信または公開する文章を生成する前。cover letters、LinkedIn outreach、application form answers、follow-up emails、executive summaries、profile blurbs。Internal evaluation reports（A-F blocks、scores、analysis）には適用しない。
|
||||
|
||||
**If no cached style in `_profile.md`:** `writing-samples/` の全ファイルを読み、**`README.md` という名前のファイルは skip** する。user-provided samples が見つからなければ style calibration を skip し、writing sample（過去の cover letter、LinkedIn About、professional writing など）があると tailoring に役立つと一度だけ軽く伝える。samples がある場合、下の markers を抽出し、`_profile.md` の `## Writing Style` に書く。以後の session はこの step を skip する。
|
||||
|
||||
### What to extract
|
||||
|
||||
**Tone & register**
|
||||
- Formal vs. conversational
|
||||
- Confident vs. hedging（"I think", "perhaps", "somewhat" のような qualifiers を見る）
|
||||
- Warm vs. transactional
|
||||
- Degree of self-promotion。undersell するか、match するか、achievements を前に出すか
|
||||
|
||||
**Sentence structure**
|
||||
- Average sentence length。short and punchy か、long and layered か
|
||||
- Fragments for emphasis の有無
|
||||
- Clause nesting and complexity
|
||||
- Sentence openings。subject-first、action-first、context-first か
|
||||
|
||||
**Punctuation habits**
|
||||
- Em dashes、en dashes、parentheses の使い方
|
||||
- Oxford comma の有無
|
||||
- Ellipses の有無
|
||||
- Exclamation marks の頻度
|
||||
- Semicolons vs. full stops
|
||||
|
||||
**Vocabulary**
|
||||
- Technical density。1 paragraph あたりの jargon 量
|
||||
- Preferred synonyms（例："built" vs "developed" vs "engineered"）
|
||||
- 繰り返し使う words / phrases は維持する
|
||||
- 出てこない words は導入しない
|
||||
|
||||
**Paragraph and structure patterns**
|
||||
- Paragraph length。one-liners か developed blocks か
|
||||
- Bullet-heavy or prose-heavy
|
||||
- Idea sequencing。problem → solution、result-first、chronological か
|
||||
- Headers の使い方
|
||||
|
||||
**Voice signatures**
|
||||
- First-person patterns（"I led", "we built", "our team"）
|
||||
- Active vs. passive ratio
|
||||
- Habitual openers and closers
|
||||
- Rhetorical moves。questions、contrast、micro-stories の有無
|
||||
|
||||
### Rules
|
||||
|
||||
- **Only extract what is demonstrably present.** 1 つの data point から推測しない。
|
||||
- **Idiosyncratic choices are intentional.** 独特な punctuation や phrasing はユーザーの voice。勝手に直さない。
|
||||
- **If samples conflict**, 最も新しいもの、または用途が近いものを重視する。
|
||||
- **If samples are sparse**, reliable に抽出できるものだけ適用し、残りは defaults に fallback する。
|
||||
- **Style calibration applies to tone and structure only.** Samples から content、claims、metrics を CVs、reports、evaluations に取り込まない。
|
||||
- **No verbatim copying or personal identifiers.** 抽象的な style descriptors のみ保存する。ユーザーの文を verbatim quote しない。names、emails、phone numbers を保持しない。"Preserve idiosyncratic choices" は stylistic traits にだけ適用する。
|
||||
|
||||
### Persisting the extracted style
|
||||
|
||||
Scan 後、user-provided sample が少なくとも 1 つあった場合のみ `modes/_profile.md` に書く。既存の `## Writing Style` section を見つけ、その section 全体を次の `##` heading（または EOF）まで置き換える。なければ append する。これにより canonical section は常に 1 つだけになる。Samples がなければ section を書かない、変更しない。
|
||||
|
||||
```markdown
|
||||
## Writing Style
|
||||
|
||||
_Extracted from writing-samples/ on {date}. Re-run if new samples are added._
|
||||
|
||||
**Tone:** {e.g. conversational, confident, no hedging qualifiers}
|
||||
**Sentence length:** {e.g. short and punchy, avg 12 words}
|
||||
**Openings:** {e.g. action-first, subject-first}
|
||||
**Punctuation:** {e.g. em dashes for asides, Oxford comma, no ellipses}
|
||||
**Vocabulary:** {e.g. prefers "built"/"ran"/"cut" over "developed"/"led"/"reduced"}
|
||||
**Structure:** {e.g. prose-heavy, result-first sequencing}
|
||||
**Voice:** {e.g. "I led", active voice dominant, no rhetorical questions}
|
||||
**Avoid:** {words or patterns absent from samples}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Professional Writing & ATS Compatibility
|
||||
|
||||
これらの rules は、candidate-facing documents に入るすべての generated text に適用する。PDF summaries、bullets、cover letters、form answers、LinkedIn messages。Internal evaluation reports には適用しない。
|
||||
|
||||
Recruiter-side risk mapping、six-second clarity、business-value bullets、ATS reality checks については `modes/heuristics/recruiter-side.md` を読む。
|
||||
|
||||
### Avoid cliché phrases
|
||||
_`voice-dna.md` が存在する場合、その §3 Banned List が canonical でより完全な list になり、この fallback list より優先される。_
|
||||
- "passionate about" / "results-oriented" / "proven track record"
|
||||
- "leveraged"（"used" または tool 名を書く）
|
||||
- "spearheaded"（"led" または "ran" を使う）
|
||||
- "facilitated"（"ran" または "set up" を使う）
|
||||
- "synergies" / "robust" / "seamless" / "cutting-edge" / "innovative"
|
||||
- "in today's fast-paced world"
|
||||
- "demonstrated ability to" / "best practices"（practice 名を具体的に書く）
|
||||
|
||||
### Unicode normalization for ATS
|
||||
`generate-pdf.mjs` は em-dashes、smart quotes、zero-width characters を ATS 互換のため ASCII equivalents に自動 normalize する。ただし生成時点で避ける。
|
||||
|
||||
### Vary sentence structure
|
||||
- すべての bullet を同じ verb で始めない
|
||||
- Sentence length を混ぜる（短い文。Context 付きの少し長い文。また短い文）
|
||||
- いつも "X, Y, and Z" にしない。2 items のときも 4 items のときもある
|
||||
|
||||
### Prefer specifics over abstractions
|
||||
- "Cut p95 latency from 2.1s to 380ms" は "improved performance" よりよい
|
||||
- "Postgres + pgvector for retrieval over 12k docs" は "designed scalable RAG architecture" よりよい
|
||||
- 許可される範囲で tools、projects、customers を名指しする
|
||||
@@ -0,0 +1,297 @@
|
||||
# モード: kyujin -- 完全評価 A-G
|
||||
|
||||
候補者が求人（テキストまたは URL）を貼り付けたら、必ず 7 ブロック（A-F の評価 + G の legitimacy）を出力する：
|
||||
|
||||
## Liveness gate (URL inputs)
|
||||
|
||||
候補者が **URL**（JD テキストではなく）を貼り付けた場合、評価を始める前に求人がまだ live であることを確認する。Dead link は Block A に進めない。404 / expired page に対して A-G 評価、report、PDF を作るのは無駄。
|
||||
|
||||
1. ページ内容を取得する。`auto-pipeline` から来た場合（Step 0.5 がすでに navigate し、link を確認済み）、その snapshot を再利用する。直接 URL が渡された場合は Playwright（`browser_navigate` + `browser_snapshot`）で navigate し、title、URL、visible content を読む。
|
||||
2. 投稿を分類する：
|
||||
- **active posting evidence:** title/role + 実際の job description または application/apply path
|
||||
- **closed posting evidence:** expired/closed/"no longer accepting applications"、JD がなく nav/footer だけ、generic careers/search page への hard redirect、404/410
|
||||
3. 投稿が closed に見える場合は、**Block A の前で stop**：候補者に link が dead であると伝える。entry が `data/pipeline.md` 由来なら、`- [x] ~~Company | Role~~ -- 求人非アクティブ` として mark する。評価、report、CV は生成しない。
|
||||
4. 候補者が JD テキストだけを貼った場合（URL なし）、liveness は確認できない。その limitation を note して進む。確認する link がないため。
|
||||
|
||||
この gate が解決するまで Block A に進まない。ここで取得した snapshot は Block G の freshness signals に再利用する。
|
||||
|
||||
## Step 0 -- Archetype Detection
|
||||
|
||||
求人を 6 つの archetype のいずれかに分類する（`_shared.md` 参照）。Hybrid の場合は最も近い 2 つを示す。これにより以下が決まる：
|
||||
- Block B でどの proof points を優先するか
|
||||
- Block E で summary をどう書き換えるか
|
||||
- Block F でどの STAR stories を準備するか
|
||||
|
||||
## Block A -- Role Summary
|
||||
|
||||
Table with:
|
||||
- Archetype detected
|
||||
- Domain (platform/agentic/LLMOps/ML/enterprise)
|
||||
- Function (build/consult/manage/deploy)
|
||||
- Seniority
|
||||
- Remote (full/hybrid/onsite)
|
||||
- Team size (if mentioned)
|
||||
- TL;DR in 1 sentence
|
||||
|
||||
## Block B -- Match with CV
|
||||
|
||||
`cv.md` を読む。JD の各 requirement を CV の exact lines に mapping した table を作る。
|
||||
|
||||
**Adapted to the archetype:**
|
||||
- If FDE → delivery speed と client-facing proof points を優先
|
||||
- If SA → system design と integrations を優先
|
||||
- If PM → product discovery と metrics を優先
|
||||
- If LLMOps → evals、observability、pipelines を優先
|
||||
- If Agentic → multi-agent、HITL、orchestration を優先
|
||||
- If Transformation → change management、adoption、scaling を優先
|
||||
|
||||
**Gaps** section with mitigation strategy for each. 各 gap について：
|
||||
1. Hard blocker か nice-to-have か
|
||||
2. 候補者は adjacent experience を示せるか
|
||||
3. Portfolio project がこの gap を cover しているか
|
||||
4. Concrete mitigation plan（cover letter 用 phrase、quick project など）
|
||||
|
||||
## Block C -- Level and Strategy
|
||||
|
||||
1. **Level detected** in the JD vs **candidate's natural level for that archetype**
|
||||
2. **"Sell senior without lying" plan**: archetype に適応した specific phrases、highlight すべき concrete achievements、founder experience を advantage として position する方法
|
||||
3. **"If they downlevel me" plan**: compensation が fair なら受け入れる、6-month review を交渉する、clear promotion criteria を求める
|
||||
|
||||
## Block D -- Comp and Demand
|
||||
|
||||
WebSearch を使って調べる：
|
||||
- その role の current salaries（OpenWork、ビズリーチ、Glassdoor、Levels.fyi、Blind）
|
||||
- Company の compensation reputation
|
||||
- その role の demand trend
|
||||
|
||||
Data と cited sources 付きの table を作る。Data がない場合は、捏造せずその旨を書く。
|
||||
|
||||
**日本市場 -- 必須チェック：**
|
||||
- 正社員か業務委託か。正社員なら賞与、有給、社会保険、通勤・住宅手当、退職金を比較に含める
|
||||
- 業務委託なら月額と正社員換算を計算する
|
||||
- 賞与の記載はあるか。月給何ヶ月分か
|
||||
- ストックオプションはあるか。vesting、cliff、税制を評価する
|
||||
- 年俸制か。賞与が含まれるか別か
|
||||
- みなし残業はあるか。何時間分含まれ、超過分は支払われるか
|
||||
- 住宅・通勤手当はあるか。月額はいくらか
|
||||
- 健康保険・厚生年金は標準か手厚いか
|
||||
|
||||
## Block E -- Customization Plan
|
||||
|
||||
| # | Section | Current status | Proposed change | Why |
|
||||
|---|---------|---------------|------------------|-----|
|
||||
| 1 | Summary | ... | ... | ... |
|
||||
| ... | ... | ... | ... | ... |
|
||||
|
||||
Top 5 changes to CV + Top 5 changes to LinkedIn to maximize match.
|
||||
|
||||
## Block F -- Interview Plan
|
||||
|
||||
JD requirements に mapping した 6-10 STAR+R stories（STAR + **Reflection**）：
|
||||
|
||||
| # | JD Requirement | STAR+R Story | S | T | A | R | Reflection |
|
||||
|---|----------------|--------------|---|---|---|---|------------|
|
||||
|
||||
**Reflection** column は、何を学んだか、または次に何を変えるかを捉える。これは seniority の signal。Junior candidates は起きたことを説明する。Senior candidates は lessons を抽出する。
|
||||
|
||||
**Story Bank:** `interview-prep/story-bank.md` が存在する場合、これらの stories がすでにあるか確認する。なければ新しいものを append する。時間とともに、どの interview question にも適応できる 5-10 master stories の reusable bank を作る。
|
||||
|
||||
**Selected and framed according to the archetype:**
|
||||
- FDE → delivery speed と client-facing を強調
|
||||
- SA → architectural decisions を強調
|
||||
- PM → discovery と trade-offs を強調
|
||||
- LLMOps → metrics、evals、production hardening を強調
|
||||
- Agentic → orchestration、error handling、HITL を強調
|
||||
- Transformation → adoption、organizational change を強調
|
||||
|
||||
Also include:
|
||||
- 1 recommended case study（どの project をどう present するか）
|
||||
- Red-flag questions and how to answer them（例："why did you sell your company?", "do you have a team of reports?"）
|
||||
|
||||
## Block G -- Posting Legitimacy
|
||||
|
||||
Job posting を分析し、real, active opening かどうかを示す signals を出す。これは、ユーザーが hiring process につながりやすい機会に effort を優先配分するためのもの。
|
||||
|
||||
**Ethical framing:** Observations を提示し、accusations にしない。どの signal にも legitimate explanations があり得る。判断はユーザーが行う。
|
||||
|
||||
### Signals to analyze (in order):
|
||||
|
||||
**1. Posting Freshness**（liveness gate または `auto-pipeline` Step 0 で取得した Playwright snapshot から。JD テキストだけの場合は unavailable）:
|
||||
- Date posted または "X days ago" を page から抽出
|
||||
- Apply button state（active / closed / missing / redirects to generic page）
|
||||
- URL が generic careers page に redirect された場合は note する
|
||||
|
||||
**2. Description Quality**（JD text から）:
|
||||
- Specific technologies, frameworks, tools を named しているか
|
||||
- Team size、reporting structure、org context に触れているか
|
||||
- Requirements は realistic か（years of experience vs technology age）
|
||||
- 最初の 6-12 months の scope が clear か
|
||||
- Salary/compensation に触れているか
|
||||
- JD のうち role-specific vs generic boilerplate の比率
|
||||
- Internal contradictions があるか（entry-level title + staff requirements など）
|
||||
|
||||
**3. Company Hiring Signals**（2-3 WebSearch queries。Block D research と combine）:
|
||||
- Search: `"{company}" layoffs {year}` -- date、scale、departments を note
|
||||
- Search: `"{company}" hiring freeze {year}` -- announcements を note
|
||||
- Layoffs が見つかった場合、この role と同じ department か確認
|
||||
|
||||
**4. Reposting Detection**（scan-history.tsv から）:
|
||||
- company + similar role title が別 URL で過去に出ているか確認
|
||||
- 回数と期間を note
|
||||
|
||||
**5. Role Market Context**（qualitative、additional queries なし）:
|
||||
- この role は通常 4-6 weeks で埋まる common role か
|
||||
- Role が company business に合っているか
|
||||
- Seniority level が長く open になりやすい type か
|
||||
|
||||
### Output format:
|
||||
|
||||
**Assessment:** One of three tiers:
|
||||
- **High Confidence** -- Multiple signals suggest a real, active opening
|
||||
- **Proceed with Caution** -- Mixed signals worth noting
|
||||
- **Suspicious** -- Multiple ghost job indicators, investigate before investing time
|
||||
|
||||
**Signals table:** 観測した各 signal、finding、weight（Positive / Neutral / Concerning）を table にする。
|
||||
|
||||
**Context Notes:** Niche role、government job、evergreen position など、concerning signals を説明し得る caveats を書く。
|
||||
|
||||
### Edge case handling:
|
||||
- **Government/academic postings:** Timeline が長いのが標準。Threshold を調整（60-90 days は normal）。
|
||||
- **Evergreen/continuous hire postings:** JD が "ongoing" / "rolling" と明示する場合は context として note。これは ghost job ではなく pipeline role。
|
||||
- **Niche/executive roles:** Staff+、VP、Director、highly specialized roles は months open でも legitimate。Age thresholds を調整。
|
||||
- **Startup / pre-revenue:** Early-stage companies は role が genuinely undefined で JD が vague なことがある。Description vagueness の重みを下げる。
|
||||
- **No date available:** Posting age が判断できず、他に concerning signals がない場合、limited data の note 付きで default to "Proceed with Caution"。Evidence なしで "Suspicious" にしない。
|
||||
- **Recruiter-sourced (no public posting):** Freshness signals unavailable。Active recruiter contact 自体を positive legitimacy signal として note。
|
||||
|
||||
---
|
||||
|
||||
## Cover Letter Draft (auto-generated after Block G)
|
||||
|
||||
Report を保存し tracker に記録した後、report file に `## Cover Letter Draft` として cover letter draft を append する。これは starting point であり final letter ではない。ユーザーは `/career-ops cover {slug}` で完成させる。
|
||||
|
||||
**How to generate the draft:**
|
||||
|
||||
1. `cv.md` を読む。JD の top requirements に最も relevant な achievement bullets を 4 つ選ぶ（exact wording、real metrics only）
|
||||
2. `config/profile.yml` を読む。candidate name、current role、years of experience を抽出する
|
||||
3. Role title と JD mission language に基づく 2-sentence opening を書く
|
||||
4. `cv.md` summary から 1-paragraph profile intro を書き、JD domain に合わせる
|
||||
5. "Problems / Why this company / Approach" section は placeholder にする。ここは user input が必要
|
||||
6. Gaps（domain mismatch、language requirement、start date urgency）を detect and flag し、ユーザーがすぐ確認できるようにする
|
||||
|
||||
**Draft format to append to the report:**
|
||||
|
||||
```markdown
|
||||
## Cover Letter Draft
|
||||
|
||||
> Draft generated at evaluation time. Complete via `/career-ops cover {slug}` to fill in angles, confirm research, and generate the PDF.
|
||||
> Gaps flagged below -- address them during the cover flow.
|
||||
|
||||
---
|
||||
|
||||
**Opening** *(placeholder -- refine with your "why this role" angle)*
|
||||
{2-sentence opening based on JD role title and mission language}
|
||||
|
||||
**Profile introduction**
|
||||
{1 paragraph from cv.md summary, adapted to JD domain and required competencies}
|
||||
|
||||
**Key achievements** *(selected from cv.md -- exact wording preserved)*
|
||||
- **{lead from cv.md},** {impact sentence with metric}.
|
||||
- **{lead from cv.md},** {impact sentence with metric}.
|
||||
- **{lead from cv.md},** {impact sentence with metric}.
|
||||
- **{lead from cv.md},** {impact sentence with metric}.
|
||||
|
||||
**Problems I will solve** *(placeholder -- requires company research + your input)*
|
||||
> To be completed: what challenges does {company} face that you'd address? How would you approach them?
|
||||
|
||||
**Closing**
|
||||
I am happy to discuss further at your convenience.
|
||||
|
||||
---
|
||||
|
||||
**Gaps flagged:**
|
||||
{List any detected gaps -- domain mismatch, language requirement, start date urgency, title mismatch. If none, write "None detected."}
|
||||
|
||||
**JD keywords to mirror** *(extracted for ATS + human read)*
|
||||
{8-10 exact phrases from the JD}
|
||||
|
||||
---
|
||||
*Run `/career-ops cover {slug}` to complete angles, confirm company research, and generate the PDF.*
|
||||
```
|
||||
|
||||
`_shared.md` の Professional Writing section にある language rules を draft content にすべて適用する。No em dashes、no buzzwords、active voice、concrete claims only。
|
||||
|
||||
---
|
||||
|
||||
## Post-evaluation
|
||||
|
||||
**ALWAYS** after generating blocks A-G:
|
||||
|
||||
### 1. Save report .md
|
||||
|
||||
Full evaluation を `reports/{###}-{company-slug}-{YYYY-MM-DD}.md` に保存する。
|
||||
|
||||
- `{###}` = next sequential number（3 digits, zero-padded）。競合を防ぐため、必ず `node reserve-report-num.mjs` を実行して番号を claim し（stdout returns `{###}`）、report を write してから `node reserve-report-num.mjs --release {###}` を実行して sentinel を release する。
|
||||
- `{company-slug}` = company name in lowercase, without spaces（use hyphens）
|
||||
- `{YYYY-MM-DD}` = current date
|
||||
|
||||
**Report format:**
|
||||
|
||||
```markdown
|
||||
# Evaluation: {Company} -- {Role}
|
||||
|
||||
**Date:** {YYYY-MM-DD}
|
||||
**URL:**
|
||||
**Archetype:** {detected}
|
||||
**Score:** {X/5}
|
||||
**Legitimacy:** {High Confidence | Proceed with Caution | Suspicious}
|
||||
**PDF:** {path or pending}
|
||||
|
||||
---
|
||||
|
||||
## A) Role Summary
|
||||
(full content of block A)
|
||||
|
||||
## B) Match with CV
|
||||
(full content of block B)
|
||||
|
||||
## C) Level and Strategy
|
||||
(full content of block C)
|
||||
|
||||
## D) Comp and Demand
|
||||
(full content of block D)
|
||||
|
||||
## E) Customization Plan
|
||||
(full content of block E)
|
||||
|
||||
## F) Interview Plan
|
||||
(full content of block F)
|
||||
|
||||
## G) Posting Legitimacy
|
||||
(full content of block G)
|
||||
|
||||
## H) Draft Application Answers
|
||||
(only if score >= 4.5 -- draft answers for the application form)
|
||||
|
||||
---
|
||||
|
||||
## Keywords extracted
|
||||
(list of 15-20 keywords from the JD for ATS optimization)
|
||||
```
|
||||
|
||||
### 2. Record in tracker
|
||||
|
||||
**ALWAYS** record in `data/applications.md`:
|
||||
- Next sequential number
|
||||
- Current date
|
||||
- Company
|
||||
- Role
|
||||
- Score: match average (1-5)
|
||||
- Status: `Evaluated`
|
||||
- PDF: ❌（または auto-pipeline が PDF を生成した場合は ✅）
|
||||
- Report: root-relative link `[001](reports/001-company-2026-01-01.md)`（`merge-tracker.mjs` 経由で merge されると tracker file からの相対 link に normalize される。例：`../reports/...`。#760 参照）
|
||||
|
||||
**Tracker format:**
|
||||
|
||||
```markdown
|
||||
| # | Date | Company | Role | Score | Status | PDF | Report |
|
||||
```
|
||||
@@ -0,0 +1,146 @@
|
||||
# モード: oubo -- 応募ライブアシスタント
|
||||
|
||||
> Free-text answers と cover-letter fields には `voice-dna.md`（存在する場合）を適用する。Full guardrail、conversational voice included（Tier 1 + Tier 2）。`_shared.md` → Voice DNA を参照。
|
||||
|
||||
候補者が Chrome で応募フォームを入力しているときの interactive mode。画面上の内容を読み、事前評価済みの求人 context を読み込み、フォームの各質問に personalized responses を生成する。
|
||||
|
||||
## Requirements
|
||||
|
||||
- **Best with Playwright in visible mode:** visible mode では、候補者が browser を見られ、Claude が page と interact できる。
|
||||
- **Without Playwright:** 候補者が screenshot を共有するか、質問を手動で貼り付ける。
|
||||
|
||||
## Workflow
|
||||
|
||||
```text
|
||||
1. DETECT → Read active Chrome tab (screenshot/URL/title)
|
||||
2. IDENTIFY → Extract company + role from the page
|
||||
3. SEARCH → Match against existing reports in reports/
|
||||
4. LOAD → Read full report + Section G (if it exists)
|
||||
5. PREFLIGHT → Confirm posting liveness + company/role match before drafting
|
||||
6. ANALYZE → Identify ALL visible form questions
|
||||
7. GENERATE → For each question, generate a personalized response
|
||||
8. PRESENT → Show formatted responses for copy-paste
|
||||
```
|
||||
|
||||
## Step 5 -- Preflight gate
|
||||
|
||||
Application answers を生成する前に、form が意図した active job を指していることを確認する。この gate は page detection、company/role identification、matching report load の後に実行する。
|
||||
|
||||
1. Visible URL、page title、company、role、closed/expired signals を読む。
|
||||
2. URL がある場合、Playwright で liveness を確認する：
|
||||
- active posting evidence: title/role + job description または form fields + submit/apply path
|
||||
- closed posting evidence: expired/closed/no longer accepting applications、JD がなく nav/footer だけ、generic careers/search への hard redirect、404/410
|
||||
3. Visible company and role を matched report と比較する。
|
||||
4. Company または title が materially changed している場合、drafting 前に stop して聞く：
|
||||
"The form appears to be for [visible company] -- [visible role], but the matched report is [report company] -- [report role]. Do you want me to re-evaluate, adapt with this mismatch, or stop?"
|
||||
5. Posting が closed に見える場合、candidate が known reason で明示的に override しない限り、final copy の生成を拒否する。
|
||||
6. Candidate が questions だけ、または screenshot だけを貼ったため liveness を確認できない場合、その limitation を明示し、drafting 前に company、role、active posting の確認を求める。
|
||||
|
||||
この preflight が解決するまで Step 6 に進まない。
|
||||
|
||||
**Applying to several roles in one sitting?** この preflight は目の前の単一 form を確認する。Multi-role session の前、特に scanner entries が `**Verification:** unconfirmed (batch mode)` と marked されている場合は、`pipeline` mode の **Liveness sweep** を先に実行する（`node check-liveness.mjs --file <urls>`）。これにより `data/pipeline.md` から dead postings がまとめて落ち、expired role の tab を開かずに済む。
|
||||
|
||||
## Step 1 -- Detect the job
|
||||
|
||||
**With Playwright:** active page の snapshot を取得する。Title、URL、visible content を読む。
|
||||
|
||||
**Without Playwright:** 候補者に以下を依頼する：
|
||||
- Form の screenshot を共有（Read tool で画像を読める）
|
||||
- または form questions を text として貼り付け
|
||||
- または company + role を伝えてもらい、こちらで検索する
|
||||
|
||||
## Step 2 -- Identify and search for context
|
||||
|
||||
1. Page から company name と role title を抽出
|
||||
2. `reports/` を company name で検索（case-insensitive grep）
|
||||
3. Match があれば full report を load
|
||||
4. Section G があれば previous draft answers を base として load
|
||||
5. Match がなければ notify し、quick auto-pipeline の実行を提案
|
||||
|
||||
## Step 3 -- Detect changes in the role
|
||||
|
||||
画面上の role が evaluation 済みの role と異なる場合：
|
||||
- **Notify the candidate:** "The role has changed from [X] to [Y]. Do you want me to re-evaluate or adapt the responses to the new title?"
|
||||
- **If adapt:** Candidate が mismatch を明示的に accept した後に限り、re-evaluate せず新しい role に responses を adjust
|
||||
- **If re-evaluate:** Full A-F evaluation を実行し、report を update し、Section G を regenerate
|
||||
- **Update tracker:** 必要に応じて `applications.md` の role title を変更
|
||||
|
||||
## Step 6 -- Analyze form questions
|
||||
|
||||
Visible questions をすべて特定する：
|
||||
- Free text fields（cover letter、why this role など）
|
||||
- Dropdowns（how did you hear、work authorization など）
|
||||
- Yes/No（relocation、visa など）
|
||||
- Salary fields（range、expectation）
|
||||
- Upload fields（resume、cover letter PDF）
|
||||
|
||||
各 question を分類する：
|
||||
- **Already answered in Section G** → 既存 response を adapt
|
||||
- **New question** → report + `cv.md` から response を generate
|
||||
|
||||
各 field について、application form contract を preserve する：
|
||||
- `field_type`: `text`, `textarea`, `select`, `radio`, `checkbox`, `number`, `file`, or `unknown`
|
||||
- `required`: `yes`, `no`, or `unknown`
|
||||
- `limit`: exact character/word limit if visible; otherwise `unknown`
|
||||
- `options`: visible options for select/radio/checkbox fields
|
||||
- `needs_candidate_confirmation`: `yes` for legal, demographic, work authorization, visa, relocation, salary, disability, veteran, sponsorship, background-check, or self-identification questions unless the answer is explicitly present in `config/profile.yml`
|
||||
|
||||
Legal、demographic、work-authorization、visa/sponsorship、salary、disability、veteran、background-check、relocation、self-identification fields の回答を捏造してはならない。回答が `config/profile.yml` または visible context に明示されていない場合は、`needs_candidate_confirmation` として mark し、候補者に確認するための最も安全な質問を出す。
|
||||
|
||||
## Step 7 -- Generate responses
|
||||
|
||||
各 question について、以下に従って response を生成する：
|
||||
|
||||
1. **Report context:** Block B の proof points、Block F の STAR stories を使う
|
||||
2. **Previous Section G:** Draft response があれば base として使い refine
|
||||
3. **"I'm choosing you" tone:** Same auto-pipeline framework
|
||||
4. **Specificity:** 画面上に見える JD の specific detail を reference
|
||||
5. **career-ops proof point:** "Additional info" field があれば含める
|
||||
6. **Recruiter-side risk map:** `modes/heuristics/recruiter-side.md` を使い、question が解消しようとしている doubt（motivation、stack fit、logistics、comp、work-auth、availability、seniority）を特定し、そこに直接答える
|
||||
7. **Disclosure discipline:** Logistics questions には truthfully に答えるが、unrelated motivation/fit answers で sensitive or HR-only details を自発的に出さない
|
||||
|
||||
**日本市場で頻出するフォーム特有の質問：**
|
||||
- **希望年収（月額/年額、税込み）** → `profile.yml` のレンジを日本円で示し、「パッケージ全体に応じて応相談」と注記
|
||||
- **雇用形態の希望（正社員/業務委託）** → `profile.yml` に従って回答。該当する場合は「どちらも対応可能」
|
||||
- **稼働開始可能日** → 現在の退職予告期間を考慮した現実的な日付（正社員なら通常 1-2 ヶ月）
|
||||
- **就労資格** → 明確に回答。未記載なら candidate confirmation が必要
|
||||
- **語学力** → 言語ごとに level を記載（native、business、conversational、basic）
|
||||
- **転居の可否** → `profile.yml` の location settings に従う
|
||||
|
||||
**Output format:**
|
||||
|
||||
```text
|
||||
## Responses for [Company] -- [Role]
|
||||
|
||||
Based on: Report #NNN | Score: X.X/5 | Archetype: [type]
|
||||
|
||||
---
|
||||
|
||||
### 1. [Exact form question]
|
||||
> [Response ready for copy-paste, or "Ask candidate: ..." if the field needs confirmation]
|
||||
|
||||
### 2. [Next question]
|
||||
> [Response]
|
||||
|
||||
...
|
||||
|
||||
---
|
||||
|
||||
Notes:
|
||||
- [Any observations about the role, changes, etc.]
|
||||
- [Personalization suggestions the candidate should review]
|
||||
```
|
||||
|
||||
## Step 8 -- Post-apply (optional)
|
||||
|
||||
候補者が application を submitted したと確認した場合：
|
||||
1. `applications.md` の status を "Evaluated" から "Applied" に update
|
||||
2. Report の Section G を final responses で update
|
||||
3. Next step として LinkedIn outreach 用の `/career-ops contacto` を提案
|
||||
|
||||
## Scroll handling
|
||||
|
||||
Form questions が visible area を超える場合：
|
||||
- 候補者に scroll して別 screenshot を共有してもらう
|
||||
- または remaining questions を paste してもらう
|
||||
- Form 全体を cover するまで iteration で処理
|
||||
@@ -0,0 +1,86 @@
|
||||
# モード: pipeline -- URL Inbox (Second Brain)
|
||||
|
||||
`data/pipeline.md` に保存された job URLs を処理する。ユーザーはいつでも URL を追加し、後から `/career-ops pipeline` を実行してまとめて処理する。
|
||||
|
||||
## Liveness sweep
|
||||
|
||||
**URLs を処理する前に必ず実行する。** Scanner が headless/batch mode で追加した entries は、Playwright が使えなかったため `**Verification:** unconfirmed (batch mode)` を持つ。つまり liveness は未確認。Sweep なしでは dead postings が 1 tab ずつ evaluation に到達し、phantom roles に時間と tokens を使ってしまう（8 件の stale URLs がある inbox なら 8 回分の無駄な evaluations になる）。
|
||||
|
||||
Per-URL loop の前に、zero-token liveness checker で pending URLs をまとめて sweep する：
|
||||
|
||||
1. "Pending" section のすべての `- [ ]` URL を temp file に集める（1 URL per line）。
|
||||
2. `node check-liveness.mjs --file <tmpfile>` を実行する（large batches では WAF rate limits を避けるため `--throttle` を追加。pure Playwright、zero Claude tokens）。Checker は URL ごとの verdict を出し、expired/uncertain がある場合は non-zero で終了する。
|
||||
3. Checker が **expired/closed** と報告した URL は処理せず pipeline entry を resolve する：`- [x] ~~URL | Company | Role~~ -- posting expired (liveness sweep)` として "Processed" に移し、すでに tracker row がある場合は `Discarded` にする。**JD extraction、evaluation、report/PDF generation はしない。**
|
||||
4. `uncertain` results は残し、normal per-URL extraction 中に確認する（一時的な timeout で live posting を落とさないため）。
|
||||
5. 生き残った live URLs だけが下の per-URL processing loop に進む。
|
||||
|
||||
これは `auto-pipeline` の per-URL liveness gate（Step 0.5）や `apply` preflight を置き換えるものではなく補完するもの。Dead postings を upfront, in bulk で落とし、ユーザーが expired role の tab を開いたり token を使ったりしないようにする。
|
||||
|
||||
## Workflow
|
||||
|
||||
1. **Read** `data/pipeline.md` → "Pending" section の `- [ ]` items を探す。最初に上の **Liveness sweep** を実行し、expired entries を落としてから続行する。
|
||||
2. **For each surviving pending URL**:
|
||||
a. `node reserve-report-num.mjs` を実行して次の `REPORT_NUM` を atomically claim する（report が書き込まれたら `node reserve-report-num.mjs --release <num>` で sentinel を release）
|
||||
b. **Extract JD** using Playwright（browser_navigate + browser_snapshot）→ WebFetch → WebSearch
|
||||
c. URL に access できない場合 → note 付きで `- [!]` と mark し、次へ進む
|
||||
d. **Execute full auto-pipeline**: Evaluation A-F → Report .md → PDF（score >= `auto_pdf_score_threshold` の場合）→ Tracker
|
||||
e. **Move from "Pending" to "Processed"**: `- [x] #NNN | URL | Company | Role | Score/5 | PDF ✅/❌`
|
||||
|
||||
**About the PDF gate (configurable):** `config/profile.yml` → `auto_pdf_score_threshold` を読む。Key がなければ default は `3.0`（この mode の original gate）。Evaluation score が threshold 未満なら PDF generation を skip する。Report は通常通り書き、header に `**PDF:** not generated -- run /career-ops pdf {company-slug} to create on demand` と表示し、tracker では PDF ❌。Score が threshold 以上なら通常通り PDF を生成する。
|
||||
|
||||
**Tuning it:** Tailored PDF generation は entry あたり ~30-60s かかる（Playwright launch + HTML render）うえ、使われないことも多い。多くの roles は 2.x/3.x で application stage まで進まない。`auto_pdf_score_threshold` を上げる（例：`4.0`）と marginal offers では report のみを書き、PDF は `/career-ops pdf {slug}` で on demand に作れる。`0` にするとすべての offers で PDF を生成する。Path A `/career-ops pipeline` と Path B `batch/batch-runner.sh` は同じ key を読むため、どちらで処理しても behavior は同じ。
|
||||
3. **If there are 3+ pending URLs**, speed を上げるため agents を並列起動する（Agent tool with `run_in_background`）。
|
||||
4. **At the end**, summary table を表示：
|
||||
|
||||
```markdown
|
||||
| # | Company | Role | Score | PDF | Recommended action |
|
||||
```
|
||||
|
||||
## Format of pipeline.md
|
||||
|
||||
```markdown
|
||||
## Pending
|
||||
- [ ] https://jobs.example.com/posting/123
|
||||
- [ ] https://boards.greenhouse.io/company/jobs/456 | Company Inc | Senior PM
|
||||
- [ ] https://jobs.ashbyhq.com/acme/789 | Acme Corp | Solutions Architect | Remote (US)
|
||||
- [!] https://private.url/job -- Error: login required
|
||||
|
||||
## Processed
|
||||
- [x] #143 | https://jobs.example.com/posting/789 | Acme Corp | AI PM | 4.2/5 | PDF ✅
|
||||
- [x] #144 | https://boards.greenhouse.io/xyz/jobs/012 | BigCo | SA | 2.1/5 | PDF ❌
|
||||
```
|
||||
|
||||
Pending lines are `- [ ] {url} | {company} | {title} | {location}`. Scanner は ATS が location を expose する場合、末尾の `| {location}` column を埋める。古い 3-column lines（location なし）も valid で、empty location として読む。
|
||||
|
||||
> 注：既存ファイルが日本語 section headings（`未処理` / `処理済み`）を使っている場合は、その style を維持してよい。読み取りは柔軟に行い、書き込み時は既存 file の style を保つ。
|
||||
|
||||
## Intelligent JD detection from URL
|
||||
|
||||
1. **Playwright (preferred):** `browser_navigate` + `browser_snapshot`. すべての SPA で動く。
|
||||
2. **WebFetch (fallback):** Static pages または Playwright が unavailable な場合。
|
||||
3. **WebSearch (last resort):** JD を index している secondary portals で検索。
|
||||
|
||||
**Special cases:**
|
||||
- **LinkedIn:** login が必要な場合あり → `[!]` と mark し、ユーザーに text paste を依頼
|
||||
- **PDF:** URL が PDF を指す場合、Read tool で直接読む
|
||||
- **`local:` prefix:** Local file を読む。Example: `local:jds/linkedin-pm-ai.md` → `jds/linkedin-pm-ai.md`
|
||||
- **Wantedly / Green / Findy:** 日本の主要 platforms。まず Playwright で確認
|
||||
- **doda / リクナビNEXT / マイナビ転職:** 日本の大手 job portals。Usually WebFetch または Playwright で確認
|
||||
- **ビズリーチ:** ハイクラス求人。Login が必要な場合あり
|
||||
- **LinkedIn JP:** Global LinkedIn と同じ constraints。Login が必要な場合あり
|
||||
|
||||
## Automatic numbering
|
||||
|
||||
1. `node reserve-report-num.mjs` を実行して next sequential number を claim する（stdout returns `{###}`）。
|
||||
2. その number を使って report file を書く。
|
||||
3. Report が書けたら `node reserve-report-num.mjs --release {###}` を実行して sentinel を release する。
|
||||
|
||||
## Source synchronization
|
||||
|
||||
URL を処理する前に sync を verify：
|
||||
|
||||
```bash
|
||||
node cv-sync-check.mjs
|
||||
```
|
||||
|
||||
Desynchronization があれば、続行前にユーザーに warn する。
|
||||
@@ -0,0 +1,107 @@
|
||||
# career-ops -- 한국어 모드 (`modes/ko/`)
|
||||
|
||||
이 디렉터리는 한국어권 후보자와 한국 채용 시장을 대상으로 career-ops의 주요 모드를 한국어로 번역한 파일을 담고 있습니다.
|
||||
|
||||
## 언제 이 모드를 사용하나요?
|
||||
|
||||
다음 중 하나라도 해당하면 `modes/ko/`를 사용하세요.
|
||||
|
||||
- 주로 **한국어 채용 공고**에 지원하는 경우
|
||||
- CV/이력서, 커버레터, 지원서 답변을 **한국어**로 작성해야 하는 경우
|
||||
- 기계 번역투가 아니라 **한국 테크 채용 문맥에 맞는 자연스러운 한국어**가 필요한 경우
|
||||
- 한국 채용 시장의 조건을 평가해야 하는 경우: 정규직, 계약직, 수습기간, 포괄임금제, 퇴직금, 4대 보험, 성과급, 스톡옵션/RSU, 재택/하이브리드 근무 등
|
||||
|
||||
대부분의 공고가 영어이고 글로벌/외국계 채용 프로세스라면 기본 `modes/`를 사용하세요. 기본 영어 모드도 한국 기업의 영어 공고를 처리할 수 있지만, 한국 채용 시장 특유의 보상/계약 조건을 세밀하게 반영하지는 않습니다.
|
||||
|
||||
## 어떻게 활성화하나요?
|
||||
|
||||
### 옵션 1 -- 세션 단위
|
||||
|
||||
세션 시작 시 Claude에게 이렇게 말하세요.
|
||||
|
||||
> "`modes/ko/` 아래의 한국어 모드를 사용해."
|
||||
|
||||
그러면 Claude는 기본 `modes/` 대신 이 디렉터리의 파일을 읽습니다.
|
||||
|
||||
### 옵션 2 -- 영구 설정
|
||||
|
||||
`config/profile.yml`에 다음을 추가하세요.
|
||||
|
||||
```yaml
|
||||
language:
|
||||
primary: ko
|
||||
modes_dir: modes/ko
|
||||
```
|
||||
|
||||
첫 세션에서 Claude에게 이 설정을 확인하라고 알려주세요. 예: "`profile.yml`에 `language.modes_dir`를 설정해뒀어." 이후 Claude는 자동으로 한국어 모드를 사용합니다.
|
||||
|
||||
## 어떤 모드가 번역되어 있나요?
|
||||
|
||||
이번 첫 버전은 영향도가 가장 큰 네 가지 모드를 다룹니다.
|
||||
|
||||
| 파일 | 번역 기준 | 역할 |
|
||||
|---------|----------------|------|
|
||||
| `_shared.md` | `modes/_shared.md` (EN) | 공통 컨텍스트, archetype, 전역 규칙, 한국 채용 시장 특화 맥락 |
|
||||
| `gonggo.md` | `modes/oferta.md` (ES) | 채용 공고 전체 평가 (블록 A-F) |
|
||||
| `jiwon.md` | `modes/apply.md` (EN) | 지원서 입력 폼을 채우는 live assistant |
|
||||
| `pipeline.md` | `modes/pipeline.md` (ES) | 수집한 채용 공고 URL inbox / Second Brain |
|
||||
|
||||
다른 모드(`scan`, `batch`, `pdf`, `tracker`, `auto-pipeline`, `deep`, `contacto`, `ofertas`, `project`, `training`)는 기존 EN/ES 모드를 그대로 사용합니다. 해당 파일들은 주로 tooling, 경로, 명령어 중심이라 언어와 독립적으로 동작합니다.
|
||||
|
||||
## 영어로 유지하는 것
|
||||
|
||||
테크 채용에서 표준적으로 쓰이는 표현은 의도적으로 번역하지 않습니다.
|
||||
|
||||
- `cv.md`, `pipeline`, `tracker`, `report`, `score`, `archetype`, `proof point`
|
||||
- 도구 이름(`Playwright`, `WebSearch`, `WebFetch`, `Read`, `Write`, `Edit`, `Bash`)
|
||||
- tracker 상태값(`Evaluated`, `Applied`, `Interview`, `Offer`, `Rejected`)
|
||||
- 코드 조각, 경로, 명령어
|
||||
|
||||
이 모드는 한국 테크 업계에서 실제로 쓰는 자연스러운 문체를 지향합니다. 본문은 한국어로 쓰되, `pipeline`, `deployment`, `embedding`, `stack`처럼 현장에서 영어로 쓰는 용어는 억지로 번역하지 않습니다.
|
||||
|
||||
## 기준 용어집
|
||||
|
||||
모드를 수정하거나 확장할 때 문체를 일관되게 유지하기 위한 기준입니다.
|
||||
|
||||
| 영어 | 한국어 (이 codebase 기준) |
|
||||
|---------|-------------------------------|
|
||||
| Job posting | 채용 공고 |
|
||||
| Application | 지원 / 지원서 |
|
||||
| Cover letter | 커버레터 |
|
||||
| Resume / CV | CV / 이력서 |
|
||||
| Salary | 연봉 |
|
||||
| Compensation | 보상 / 보상 패키지 |
|
||||
| Skills | 역량 / 기술 역량 |
|
||||
| Interview | 면접 |
|
||||
| Hiring manager | 채용 매니저 / 실무 리더 |
|
||||
| Recruiter | 리크루터 |
|
||||
| AI | AI / 인공지능 |
|
||||
| Requirements | 자격 요건 / 요구사항 |
|
||||
| Career history | 경력 |
|
||||
| Notice period | 퇴사 통보 기간 |
|
||||
| Probation | 수습기간 |
|
||||
| Vacation | 연차 / 유급휴가 |
|
||||
| Permanent employment | 정규직 |
|
||||
| Fixed-term contract | 계약직 |
|
||||
| Freelance | 프리랜서 / 개인사업자 |
|
||||
| Gross annual salary | 세전 연봉 |
|
||||
| Net salary | 실수령액 |
|
||||
| Severance pay | 퇴직금 |
|
||||
| Social insurance | 4대 보험 |
|
||||
| Inclusive wage system | 포괄임금제 |
|
||||
| Bonus | 성과급 / 보너스 |
|
||||
| Stock option / RSU | 스톡옵션 / RSU |
|
||||
| Meal allowance | 식대 |
|
||||
| Flexible work | 유연근무 |
|
||||
| Remote work | 재택근무 / 원격근무 |
|
||||
| Hybrid work | 하이브리드 근무 |
|
||||
|
||||
## 기여하기
|
||||
|
||||
번역을 개선하거나 새 모드를 추가하려면:
|
||||
|
||||
1. 제안을 담은 Issue를 엽니다 (`CONTRIBUTING.md` 참고)
|
||||
2. 위 용어집을 따라 문체를 일관되게 유지합니다
|
||||
3. 직역이 아니라 자연스러운 한국어로 번역합니다
|
||||
4. 구조 요소(블록 A-F, 표, 코드블록, 도구 지시문)는 그대로 유지합니다
|
||||
5. 실제 한국어 채용 공고(원티드, 리멤버, 잡코리아, 사람인, LinkedIn KR 등)로 테스트한 뒤 PR을 보냅니다
|
||||
@@ -0,0 +1,204 @@
|
||||
# 공통 컨텍스트 -- career-ops (한국어)
|
||||
|
||||
<!-- ============================================================
|
||||
사용 전 개인 설정 안내
|
||||
============================================================
|
||||
이 파일은 한국어 career-ops 모드 전체에서 공유하는 컨텍스트입니다.
|
||||
career-ops를 사용하기 전에 반드시 다음을 준비하세요.
|
||||
1. config/profile.yml에 개인 정보를 입력
|
||||
2. 프로젝트 루트에 cv.md 생성 (Markdown CV)
|
||||
3. (선택) article-digest.md에 proof point 정리
|
||||
4. 아래 [개인화] 표시가 있는 섹션을 자신의 상황에 맞게 조정
|
||||
============================================================ -->
|
||||
|
||||
## Source of Truth (매 평가 전 항상 읽기)
|
||||
|
||||
| 파일 | 경로 | 언제 |
|
||||
|------|------|------|
|
||||
| cv.md | `cv.md` (프로젝트 루트) | 항상 |
|
||||
| article-digest.md | `article-digest.md` (있다면) | 항상 (상세 proof point) |
|
||||
| profile.yml | `config/profile.yml` | 항상 (신원 정보와 목표 역할) |
|
||||
|
||||
**규칙: proof point의 metric을 절대 하드코딩하지 않습니다.** 평가 시점에 `cv.md`와 `article-digest.md`에서 읽습니다.
|
||||
**규칙: article/project metric은 `article-digest.md`가 `cv.md`보다 우선합니다** (`cv.md`에는 더 오래된 수치가 있을 수 있음).
|
||||
|
||||
---
|
||||
|
||||
## North Star -- 목표 역할
|
||||
|
||||
이 skill은 모든 목표 역할을 같은 비중으로 다룹니다. primary/secondary 구분은 없습니다. 보상과 성장 가능성이 맞다면 각 역할은 모두 성공입니다.
|
||||
|
||||
| Archetype | 주제 축 | 회사가 구매하는 가치 |
|
||||
|-----------|---------|----------------------|
|
||||
| **AI Platform / LLMOps Engineer** | Evaluation, Observability, Reliability, Pipelines | metric 기반으로 AI를 production에 올리는 사람 |
|
||||
| **Agentic Workflows / Automation** | HITL, Tooling, Orchestration, Multi-Agent | 신뢰할 수 있는 agent system을 만드는 사람 |
|
||||
| **Technical AI Product Manager** | GenAI/Agents, PRDs, Discovery, Delivery | business 요구를 AI product로 번역하는 사람 |
|
||||
| **AI Solutions Architect** | Hyperautomation, Enterprise, Integrations | end-to-end AI architecture를 설계하는 사람 |
|
||||
| **AI Forward Deployed Engineer** | Client-facing, Fast delivery, Prototyping | 고객 현장에서 AI solution을 빠르게 배포하는 사람 |
|
||||
| **AI Transformation Lead** | Change management, Adoption, Enablement | 조직의 AI transformation을 이끄는 사람 |
|
||||
|
||||
<!-- [개인화] 위 archetype을 자신의 목표 역할에 맞게 조정하세요.
|
||||
Backend engineering 예시:
|
||||
- Senior Backend Engineer
|
||||
- Staff Platform Engineer
|
||||
- Engineering Manager
|
||||
등 -->
|
||||
|
||||
### Archetype별 adaptive framing
|
||||
|
||||
> **구체적인 수치는 평가 시점에 `cv.md`와 `article-digest.md`에서 읽습니다. 이 파일에 고정값으로 적어두지 마세요.**
|
||||
|
||||
| 역할이... | 후보자에게서 강조할 것 | Proof point source |
|
||||
|-----------|------------------------|--------------------|
|
||||
| Platform / LLMOps | production 경험, observability, evals, closed-loop | article-digest.md + cv.md |
|
||||
| Agentic / Automation | multi-agent orchestration, HITL, reliability, cost | article-digest.md + cv.md |
|
||||
| Technical AI PM | product discovery, PRD, metric, stakeholder management | cv.md + article-digest.md |
|
||||
| Solutions Architect | system design, integration, enterprise readiness | article-digest.md + cv.md |
|
||||
| Forward Deployed Engineer | 빠른 delivery, 고객 접점, prototype to production | cv.md + article-digest.md |
|
||||
| AI Transformation Lead | change management, team enablement, adoption | cv.md + article-digest.md |
|
||||
|
||||
<!-- [개인화] 자신의 구체적인 project/article을 위 archetype에 연결하세요. -->
|
||||
|
||||
### 전환 narrative (모든 framing에 사용)
|
||||
|
||||
<!-- [개인화] 자신의 narrative로 바꾸세요. 예:
|
||||
- "5년간 SaaS를 만들고 매각. 이제 enterprise applied AI에 100% 집중."
|
||||
- "Series-B에서 x10 성장기를 겪은 engineering lead. 다음 도전을 찾는 중."
|
||||
- "컨설팅에서 product로 전환. 높은 책임 범위의 역할을 찾는 중."
|
||||
config/profile.yml -> narrative.exit_story에서 읽음 -->
|
||||
|
||||
모든 콘텐츠에서 `config/profile.yml`의 전환 narrative를 사용해 framing합니다.
|
||||
- **PDF summary:** 과거와 미래를 연결합니다 -- "이제 같은 [역량]을 [공고의 domain]에 적용합니다."
|
||||
- **STAR story:** `article-digest.md`의 proof point를 참조합니다.
|
||||
- **답변 초안(블록 G):** 전환 narrative는 첫 답변에 넣습니다.
|
||||
- **공고가 "entrepreneurial", "autonomy", "builder", "end-to-end"를 언급할 때:** 이것이 핵심 차별점입니다. match weight를 높입니다.
|
||||
|
||||
### Cross-cutting advantage
|
||||
|
||||
프로필을 **"실제 실행 경험을 가진 technical builder"**로 framing하고, 역할에 맞게 조정합니다.
|
||||
- PM: "prototype으로 불확실성을 줄이고 discipline 있게 production까지 전달하는 builder"
|
||||
- FDE: "day 1부터 observability와 metric을 갖춰 delivery하는 builder"
|
||||
- SA: "실제 integration 경험으로 end-to-end system을 설계하는 builder"
|
||||
- LLMOps: "closed-loop quality system으로 AI를 production에 올리는 builder"
|
||||
|
||||
"Builder"를 전문성의 신호로 positioning합니다. "그냥 이것저것 만드는 사람"처럼 보이면 안 됩니다. 실제 proof point가 credibility를 만듭니다.
|
||||
|
||||
### Portfolio as proof point (중요 지원에 사용)
|
||||
|
||||
<!-- [개인화] live demo, dashboard, public project가 있다면 여기에 설정하세요.
|
||||
예:
|
||||
dashboard:
|
||||
url: "https://yourdomain.dev/demo"
|
||||
password: "demo-2026"
|
||||
when_to_share: "LLMOps, AI Platform, Observability roles"
|
||||
config/profile.yml -> narrative.proof_points 및 narrative.dashboard에서 읽음 -->
|
||||
|
||||
후보자에게 live demo / dashboard가 있다면(`profile.yml` 확인), 관련성 높은 지원에서 접근 정보를 제안합니다.
|
||||
|
||||
### 보상 정보 (Comp Intelligence)
|
||||
|
||||
<!-- [개인화] 목표 역할의 보상 범위를 조사해 값을 조정하세요. -->
|
||||
|
||||
**일반 가이드:**
|
||||
- 현재 시장 데이터는 WebSearch로 확인합니다(원티드, 리멤버, 잡플래닛, 블라인드, Levels.fyi, Glassdoor 등).
|
||||
- 직무 title 기준으로 framing합니다. salary band는 보통 skill보다 title이 정의합니다.
|
||||
- 한국에서는 base salary, performance bonus, stock option/RSU, signing bonus, welfare benefit이 섞여 제시될 수 있으므로 total compensation을 분해해서 봅니다.
|
||||
- remote role의 geo-arbitrage는 가능하지만, 일부 회사는 한국 거주 여부, 시차, 고용 형태(EOR/contractor)를 기준으로 보상을 조정할 수 있습니다.
|
||||
|
||||
### 한국 채용 시장 -- 특이사항 (중요)
|
||||
|
||||
한국어 공고와 협상에서는 EN/ES 시장과 다른 용어가 등장합니다. 반드시 정확히 반영하세요.
|
||||
|
||||
| 용어 | 의미 | 평가 영향 |
|
||||
|------|------|-----------|
|
||||
| **정규직** | 기간의 정함이 없는 고용 형태 | senior tech role의 기본값. 계약직이면 이유와 전환 가능성 확인 |
|
||||
| **계약직** | 기간이 정해진 고용 형태 | 특정 project/전환형이면 가능. 기간, 연장/전환 가능성, 종료 리스크 확인 |
|
||||
| **수습기간** | 보통 3개월. 일부 회사는 급여 감액 조건을 둠 | 급여 100% 지급 여부, 평가 기준, 해고 조건 확인 |
|
||||
| **포괄임금제** | 연장/야간/휴일근로 수당을 연봉에 포함하는 구조 | 근무시간 리스크. 고정 OT 시간과 실제 야근 culture 확인 |
|
||||
| **퇴직금** | 1년 이상 근무 시 발생하는 법정 퇴직급여 | 연봉에 포함/별도 표현이 혼동될 수 있으므로 확인 |
|
||||
| **4대 보험** | 국민연금, 건강보험, 고용보험, 산재보험 | 정규직/계약직의 기본 위생 요건. 프리랜서는 다를 수 있음 |
|
||||
| **세전 연봉** | 세금/보험료 공제 전 연봉 | 한국 연봉 협상은 보통 세전 기준. 실수령액과 구분 |
|
||||
| **성과급 / 인센티브** | 개인/회사 성과에 따른 변동 보상 | target, payout history, 지급 조건 확인 |
|
||||
| **스톡옵션 / RSU** | equity compensation | vesting schedule, exercise price, liquidity 가능성 확인 |
|
||||
| **사이닝 보너스** | 입사 보너스 | clawback 조건이 있는지 확인 |
|
||||
| **연차 / 유급휴가** | 근로기준법상 유급휴가 | 최소 기준 미달은 red flag. 사용 문화도 중요 |
|
||||
| **식대 / 복지포인트** | 현금성 또는 준현금성 복지 | 작은 항목이지만 total package 비교에 포함 |
|
||||
| **재택근무** | 원격 근무 | "가능"과 "상시 가능"은 다릅니다. 출근 빈도 확인 |
|
||||
| **하이브리드 근무** | 재택 + 오피스 출근 혼합 | 주 n회 출근, team day, 지역 제한 확인 |
|
||||
| **프리랜서 / 개인사업자** | 고용계약이 아닌 용역/위탁 계약 | rate, 세금, 보험, 계약 종료 리스크를 별도로 평가 |
|
||||
|
||||
### 협상 스크립트
|
||||
|
||||
<!-- [개인화] 자신의 상황에 맞게 조정하세요. -->
|
||||
|
||||
**희망 연봉 (일반 framework):**
|
||||
> "이 역할의 시장 기준과 제 경험 범위를 고려하면, 저는 [profile.yml의 범위] 수준을 기대하고 있습니다. 다만 base, bonus, equity, 복지까지 포함한 전체 보상 패키지 기준으로 유연하게 논의할 수 있습니다."
|
||||
|
||||
**지역 기반 discount에 대한 답변:**
|
||||
> "제가 비교 중인 역할들은 location보다 delivery와 impact를 기준으로 평가합니다. 제 track record는 근무지와 관계없이 동일하게 적용됩니다."
|
||||
|
||||
**제안이 목표보다 낮을 때:**
|
||||
> "현재 [더 높은 범위] 수준의 package를 기준으로 논의 중입니다. [회사]에는 [구체적 이유] 때문에 관심이 큽니다. [목표 금액/구조]까지 맞출 수 있을까요?"
|
||||
|
||||
**성과급 / equity 협상:**
|
||||
> "공정하게 비교하려면 base salary, target bonus, equity/stock option, signing bonus를 나눠서 보고 싶습니다. 각 항목의 지급 조건과 과거 payout range도 확인할 수 있을까요?"
|
||||
|
||||
### Location Policy
|
||||
|
||||
<!-- [개인화] 자신의 상황에 맞게 조정하세요. config/profile.yml -> location에서 읽음 -->
|
||||
|
||||
**지원서 폼에서:**
|
||||
- "출근 가능 여부" 같은 binary 질문: `profile.yml`의 실제 availability에 따라 답합니다.
|
||||
- 자유 입력 필드: 시차 overlap, 출근 가능 빈도, 지역 제한을 명확히 씁니다.
|
||||
|
||||
**평가 scoring에서:**
|
||||
- 국내 하이브리드인데 출근 빈도가 불명확하면 remote dimension을 **3.0**으로 둡니다.
|
||||
- Score 1.0은 공고가 "주 4-5일 필수 출근, 예외 없음"처럼 명시할 때만 사용합니다.
|
||||
|
||||
### Time-to-offer priority
|
||||
- 작동하는 demo + metric > 완벽함
|
||||
- 더 많이 조사하기보다 빠르게 지원
|
||||
- 80/20 접근, 모든 작업은 timebox
|
||||
|
||||
---
|
||||
|
||||
## 전역 규칙
|
||||
|
||||
### 절대 하지 말 것
|
||||
|
||||
1. 경험이나 metric을 지어내기
|
||||
2. `cv.md` 또는 portfolio 파일을 임의로 수정하기
|
||||
3. 후보자 대신 지원서를 제출하기
|
||||
4. 생성 메시지에 전화번호 공유하기
|
||||
5. 시장가보다 낮은 보상을 추천하기
|
||||
6. 공고를 읽기 전에 PDF 생성하기
|
||||
7. 공허한 corporate jargon 사용하기
|
||||
8. tracker 무시하기 (평가한 모든 공고는 기록)
|
||||
|
||||
### 항상 할 것
|
||||
|
||||
0. **커버레터:** 폼이 허용하면 항상 포함합니다. CV와 같은 visual design의 PDF. 공고 문구를 proof point와 매핑. 최대 1페이지.
|
||||
1. 공고 평가 전 `cv.md`와 `article-digest.md`(있다면)를 읽습니다.
|
||||
1b. **세션 첫 평가:** Bash로 `node cv-sync-check.mjs`를 실행합니다. 경고가 있으면 후보자에게 알립니다.
|
||||
2. 역할 archetype을 감지하고 framing을 조정합니다.
|
||||
3. matching 시 CV의 정확한 문장을 인용합니다.
|
||||
4. 보상/회사 데이터에는 WebSearch를 사용합니다.
|
||||
5. 매 평가 후 tracker에 기록합니다.
|
||||
6. 생성 콘텐츠는 공고 언어에 맞춥니다(한국어 공고면 한국어, 영어 공고면 영어).
|
||||
7. 직접적이고 구체적으로 씁니다. 불필요한 말은 줄입니다.
|
||||
8. 한국 테크 채용 문맥에 맞는 자연스러운 한국어를 사용합니다. 짧은 문장, 동사 중심, 수동태 회피. stack, pipeline, deployment, embedding 같은 현장 용어는 억지로 번역하지 않습니다.
|
||||
8b. **PDF Professional Summary의 case study URL:** PDF가 case study나 demo를 언급하면 URL은 반드시 첫 문단(Professional Summary)에 들어갑니다. recruiter는 summary만 읽는 경우가 많습니다. HTML에서는 모든 URL에 `white-space: nowrap` 적용.
|
||||
9. **Tracker entry는 TSV로 작성** -- 새 항목을 위해 applications.md를 직접 수정하지 않습니다. `batch/tracker-additions/`에 TSV를 쓰고 `merge-tracker.mjs`가 병합합니다.
|
||||
10. **모든 report header에 `**URL:**` 포함** -- Score와 PDF 사이에 둡니다.
|
||||
|
||||
### 도구
|
||||
|
||||
| 도구 | 용도 |
|
||||
|------|------|
|
||||
| WebSearch | 보상, 시장 trend, 회사 culture, LinkedIn contact, 공고 fallback 조사 |
|
||||
| WebFetch | 정적 페이지의 공고 추출 fallback |
|
||||
| Playwright | 공고 활성 여부 확인(browser_navigate + browser_snapshot), SPA에서 공고 추출. **중요: Playwright를 쓰는 agent를 2개 이상 병렬로 띄우지 않습니다 -- 같은 browser instance를 공유합니다** |
|
||||
| Read | cv.md, article-digest.md, cv-template.html |
|
||||
| Write | PDF용 임시 HTML, applications.md, reports .md |
|
||||
| Edit | tracker 업데이트 |
|
||||
| Bash | `node generate-pdf.mjs` |
|
||||
@@ -0,0 +1,164 @@
|
||||
# 모드: gonggo -- 전체 평가 A-F
|
||||
|
||||
후보자가 채용 공고(텍스트 또는 URL)를 붙여넣으면 항상 6개 블록을 제공합니다.
|
||||
|
||||
## Step 0 -- Archetype 감지
|
||||
|
||||
공고를 6개 archetype 중 하나로 분류합니다(`_shared.md` 참고). 하이브리드 역할이면 가장 가까운 2개를 표시합니다. 이 분류는 다음을 결정합니다.
|
||||
- 블록 B에서 우선순위를 둘 proof point
|
||||
- 블록 E에서 summary를 다시 쓰는 방식
|
||||
- 블록 F에서 준비할 STAR story
|
||||
|
||||
## 블록 A -- 역할 요약
|
||||
|
||||
다음 항목이 포함된 표를 작성합니다.
|
||||
- 감지된 archetype
|
||||
- 도메인 (Platform / Agentic / LLMOps / ML / Enterprise)
|
||||
- 기능 (Build / Consulting / Management / Deploy)
|
||||
- Seniority
|
||||
- Remote (Full remote / Hybrid / On-site)
|
||||
- 팀 규모(언급된 경우)
|
||||
- 한 문장 TL;DR
|
||||
|
||||
## 블록 B -- CV와의 매치
|
||||
|
||||
`cv.md`를 읽습니다. 공고의 각 자격 요건을 CV의 정확한 문장과 매핑한 표를 만듭니다.
|
||||
|
||||
**Archetype에 맞게 조정:**
|
||||
- FDE -> 빠른 delivery와 고객 접점 proof point 우선
|
||||
- SA -> 시스템 설계와 integration 우선
|
||||
- PM -> product discovery와 metric 우선
|
||||
- LLMOps -> evals, observability, pipeline 우선
|
||||
- Agentic -> multi-agent, HITL, orchestration 우선
|
||||
- Transformation -> change management, adoption, scale-up 우선
|
||||
|
||||
**Gaps** 섹션을 만들고 각 gap에 대한 mitigation 전략을 제시합니다. 각 gap마다 다음을 판단합니다.
|
||||
1. hard blocker인가, nice-to-have인가?
|
||||
2. 후보자가 인접 경험으로 증명할 수 있는가?
|
||||
3. 이 gap을 커버하는 portfolio project가 있는가?
|
||||
4. 구체적인 mitigation plan은 무엇인가? (커버레터 문장, 빠른 mini-project 등)
|
||||
|
||||
## 블록 C -- 레벨과 전략
|
||||
|
||||
1. 공고에서 감지된 **레벨** vs 해당 archetype에서 후보자의 **자연스러운 레벨**
|
||||
2. **"거짓 없이 senior로 포지셔닝하기" 계획**: archetype에 맞춘 구체적인 표현, 강조할 실제 성과, founder 경험을 장점으로 배치하는 방법
|
||||
3. **"downlevel될 경우" 계획**: 보상이 적절하면 수락, 6개월 리뷰 협상, 명확한 promotion criteria 요구
|
||||
|
||||
## 블록 D -- 보상과 시장 수요
|
||||
|
||||
WebSearch를 사용합니다.
|
||||
- 해당 역할의 현재 연봉 범위(원티드, 리멤버, 잡플래닛, 블라인드, Levels.fyi, Glassdoor 등)
|
||||
- 회사의 보상 평판(가능한 경우)
|
||||
- 한국/아시아 또는 해당 시장에서 역할 수요 추세
|
||||
|
||||
데이터와 출처를 표로 정리합니다. 데이터가 없으면 명확히 없다고 말합니다. 절대 지어내지 않습니다.
|
||||
|
||||
**한국 시장 -- 필수 확인 사항:**
|
||||
- 세전 연봉 기준인가? 월급/연봉/총보상 기준이 섞여 있지 않은가?
|
||||
- 성과급, 인센티브, 사이닝 보너스가 별도로 언급되어 있는가?
|
||||
- 스톡옵션, RSU, 지분 보상이 있는가? vesting 조건은 명시되어 있는가?
|
||||
- 정규직인가 계약직인가? 계약직이면 기간, 전환 가능성, 계약 종료 리스크를 확인합니다.
|
||||
- 수습기간이 있는가? 기간과 급여 차감 여부가 명시되어 있는가?
|
||||
- 포괄임금제, 고정 OT, 야근/휴일근무 조건이 언급되어 있는가?
|
||||
- 퇴직금, 4대 보험, 연차/휴가, 식대/복지포인트 등 기본 복지가 명시되어 있는가?
|
||||
- 재택/하이브리드라면 실제 출근 빈도와 지역 제한이 명확한가?
|
||||
|
||||
## 블록 E -- 개인화 계획
|
||||
|
||||
| # | Section | Current state | Proposed change | Rationale |
|
||||
|---|---------|---------------|-----------------|-----------|
|
||||
| 1 | Summary | ... | ... | ... |
|
||||
| ... | ... | ... | ... | ... |
|
||||
|
||||
매치를 극대화하기 위한 Top 5 CV 수정 + Top 5 LinkedIn 수정 제안을 제공합니다.
|
||||
|
||||
## 블록 F -- 면접 준비 계획
|
||||
|
||||
공고의 자격 요건에 매핑한 6-10개 STAR+R story를 준비합니다 (STAR + **Reflection**).
|
||||
|
||||
| # | 공고 자격 요건 | STAR+R story | S | T | A | R | Reflection |
|
||||
|---|----------------|--------------|---|---|---|---|------------|
|
||||
|
||||
**Reflection** 열은 무엇을 배웠는지 또는 다시 한다면 무엇을 다르게 할지를 담습니다. 이는 seniority를 보여주는 신호입니다. junior는 무슨 일이 있었는지를 설명하고, senior는 그 경험에서 무엇을 배웠는지까지 설명합니다.
|
||||
|
||||
**Story Bank:** `interview-prep/story-bank.md`가 있으면 해당 story들이 이미 있는지 확인합니다. 없으면 새 story를 추가합니다. 시간이 지나면 어떤 면접 질문에도 재사용 가능한 5-10개의 master story bank가 만들어집니다.
|
||||
|
||||
**Archetype에 맞춰 선택하고 framing합니다:**
|
||||
- FDE -> delivery 속도와 고객 접점을 강조
|
||||
- SA -> architecture decision을 강조
|
||||
- PM -> discovery와 trade-off를 강조
|
||||
- LLMOps -> metric, eval, production hardening을 강조
|
||||
- Agentic -> orchestration, error handling, HITL을 강조
|
||||
- Transformation -> adoption과 조직 변화 관리를 강조
|
||||
|
||||
추가로 포함합니다.
|
||||
- 추천 case study 1개(어떤 프로젝트를 어떻게 보여줄지)
|
||||
- red-flag 질문과 답변 전략 (예: "왜 회사를 매각했나요?", "직접 관리한 팀이 있었나요?", "왜 짧은 기간 후 전환하려 하나요?")
|
||||
|
||||
---
|
||||
|
||||
## 평가 후 작업
|
||||
|
||||
블록 A-F 이후 항상 실행합니다.
|
||||
|
||||
### 1. report .md 저장
|
||||
|
||||
전체 평가를 `reports/{###}-{company-slug}-{YYYY-MM-DD}.md`에 저장합니다.
|
||||
|
||||
- `{###}` = 다음 순차 번호(3자리, zero-padded). 동시성 문제를 피하기 위해 반드시 `node reserve-report-num.mjs`를 실행해 번호를 예약합니다(stdout이 `{###}`를 반환). report를 작성한 뒤 `node reserve-report-num.mjs --release {###}`를 실행해 sentinel을 해제합니다.
|
||||
- `{company-slug}` = 회사명을 소문자와 하이픈으로 만든 slug
|
||||
- `{YYYY-MM-DD}` = 오늘 날짜
|
||||
|
||||
**Report format:**
|
||||
|
||||
```markdown
|
||||
# Evaluation : {Company} -- {Role}
|
||||
|
||||
**Date:** {YYYY-MM-DD}
|
||||
**Archetype:** {detected}
|
||||
**Score:** {X/5}
|
||||
**URL:** {job URL}
|
||||
**PDF:** {path or pending}
|
||||
|
||||
---
|
||||
|
||||
## A) 역할 요약
|
||||
(블록 A 전체 내용)
|
||||
|
||||
## B) CV와의 매치
|
||||
(블록 B 전체 내용)
|
||||
|
||||
## C) 레벨과 전략
|
||||
(블록 C 전체 내용)
|
||||
|
||||
## D) 보상과 시장 수요
|
||||
(블록 D 전체 내용)
|
||||
|
||||
## E) 개인화 계획
|
||||
(블록 E 전체 내용)
|
||||
|
||||
## F) 면접 준비 계획
|
||||
(블록 F 전체 내용)
|
||||
|
||||
## G) 지원서 답변 초안
|
||||
(score >= 4.5일 때만 -- 지원서 폼 답변 초안)
|
||||
|
||||
---
|
||||
|
||||
## 추출한 키워드
|
||||
(ATS 최적화를 위한 공고 키워드 15-20개)
|
||||
```
|
||||
|
||||
### 2. tracker 추가 항목 작성
|
||||
|
||||
새 tracker row를 위해 `data/applications.md`를 직접 수정하지 않습니다. 평가마다 `batch/tracker-additions/{num}-{company-slug}.tsv`에 TSV 한 줄을 쓰고, 이후 `node merge-tracker.mjs`로 병합합니다.
|
||||
|
||||
**TSV format (status before score):**
|
||||
|
||||
```text
|
||||
{num}\t{date}\t{company}\t{role}\tEvaluated\t{score}/5\t{pdf}\t[{num}](reports/{num}-{company-slug}-{date}.md)\t{note}
|
||||
```
|
||||
|
||||
- `pdf`는 PDF가 생성되면 `✅`, 아니면 `❌`
|
||||
- report 링크는 root-relative로 작성합니다: `[001](reports/001-company-2026-01-01.md)`
|
||||
- 이미 같은 company + role이 있으면 새 row를 만들지 말고 기존 entry 업데이트 흐름을 따릅니다.
|
||||
@@ -0,0 +1,115 @@
|
||||
# 모드: jiwon -- 지원서 작성 live assistant
|
||||
|
||||
후보자가 Chrome에서 지원서 폼을 작성하는 순간 사용하는 interactive mode입니다. 화면에 보이는 내용을 읽고, 이전에 평가한 채용 공고의 context를 불러온 뒤, 폼의 각 질문에 맞는 개인화 답변을 생성합니다.
|
||||
|
||||
## 사전 조건
|
||||
|
||||
- **Visible Playwright가 가장 이상적**: visible mode에서는 후보자가 브라우저를 직접 볼 수 있고, Claude가 페이지와 상호작용할 수 있습니다.
|
||||
- **Playwright 없이 진행하는 경우**: 후보자가 스크린샷을 공유하거나 질문을 직접 붙여넣습니다.
|
||||
|
||||
## Workflow
|
||||
|
||||
```text
|
||||
1. DETECT -> 활성 Chrome 탭 읽기 (스크린샷/URL/title)
|
||||
2. IDENTIFY -> 페이지에서 회사 + 역할 추출
|
||||
3. SEARCH -> reports/ 안의 기존 report와 매칭
|
||||
4. LOAD -> 전체 report + 블록 G(있다면) 읽기
|
||||
5. COMPARE -> 화면의 역할이 평가한 역할과 같은지 확인. 바뀌었다면 알림
|
||||
6. ANALYZE -> 화면에 보이는 모든 지원서 질문 식별
|
||||
7. GENERATE -> 각 질문에 대해 개인화 답변 생성
|
||||
8. PRESENT -> 복사/붙여넣기 가능한 형식으로 답변 표시
|
||||
```
|
||||
|
||||
## Step 1 -- 공고 감지
|
||||
|
||||
**Playwright 사용 시:** 활성 페이지 snapshot을 뜹니다. title, URL, 보이는 내용을 읽습니다.
|
||||
|
||||
**Playwright 없이 진행 시:** 후보자에게 다음 중 하나를 요청합니다.
|
||||
- 지원서 폼 스크린샷 공유 (Read tool이 이미지를 읽을 수 있음)
|
||||
- 또는 지원서 질문을 텍스트로 붙여넣기
|
||||
- 또는 회사 + 역할을 알려주면 context를 검색
|
||||
|
||||
## Step 2 -- context 식별 및 불러오기
|
||||
|
||||
1. 페이지에서 회사명과 역할명을 추출합니다.
|
||||
2. `reports/`에서 회사명으로 검색합니다 (case-insensitive grep).
|
||||
3. 매칭되는 report가 있으면 전체 report를 불러옵니다.
|
||||
4. 블록 G가 있으면 이전 답변 초안을 base로 불러옵니다.
|
||||
5. 매칭되는 report가 없으면 후보자에게 알리고 빠른 auto-pipeline 실행을 제안합니다.
|
||||
|
||||
## Step 3 -- 역할 변경 감지
|
||||
|
||||
화면의 역할이 평가한 역할과 다르면:
|
||||
- **후보자에게 알림**: "역할이 [X]에서 [Y]로 바뀐 것 같습니다. 새 역할로 다시 평가할까요, 아니면 새 title에 맞춰 답변만 조정할까요?"
|
||||
- **조정 선택 시**: 재평가 없이 새 역할에 맞춰 답변을 조정합니다.
|
||||
- **재평가 선택 시**: 전체 A-F 평가를 실행하고, report를 업데이트하고, 블록 G를 다시 생성합니다.
|
||||
- **tracker 업데이트**: 필요한 경우 `applications.md`의 역할명을 수정합니다.
|
||||
|
||||
## Step 4 -- 지원서 질문 분석
|
||||
|
||||
화면에 보이는 모든 질문을 식별합니다.
|
||||
- 자유 입력 필드 (커버레터, "왜 이 역할인가요", 지원 동기 등)
|
||||
- 드롭다운 (어디서 공고를 봤는지, 근무 자격 등)
|
||||
- Yes/No 질문 (이직 가능 여부, 비자, 근무 가능 지역 등)
|
||||
- 연봉 입력 필드 (희망 연봉, range, 총보상 기대치)
|
||||
- 업로드 필드 (CV, 커버레터 PDF, 추천인 등)
|
||||
|
||||
각 질문을 분류합니다.
|
||||
- **이미 블록 G에서 답변한 질문** -> 기존 답변을 가져와 조정
|
||||
- **새 질문** -> report + `cv.md`를 바탕으로 답변 생성
|
||||
|
||||
## Step 5 -- 답변 생성
|
||||
|
||||
각 질문에 대해 다음 구조로 답변을 만듭니다.
|
||||
|
||||
1. **Report context**: 블록 B의 proof point와 블록 F의 STAR story 사용
|
||||
2. **이전 블록 G**: 기존 초안이 있으면 base로 가져와 다듬기
|
||||
3. **"제가 귀사를 선택합니다" 톤**: auto-pipeline과 같은 framework 사용 -- 자신감 있게, 애원하지 않게
|
||||
4. **구체성**: 화면에 보이는 공고 내용 중 구체적인 요소 언급
|
||||
5. **career-ops proof point**: "추가 정보" 같은 필드가 있으면 포함
|
||||
|
||||
**한국 지원서 폼에서 자주 나오는 필드:**
|
||||
- **희망 연봉 / 처우** -> `profile.yml`의 range를 사용. 세전 연봉 기준인지 명확히 쓰고, "전체 보상 패키지에 따라 협의 가능"이라고 덧붙임
|
||||
- **입사 가능일** -> 현재 재직/퇴사 통보 기간을 고려한 현실적인 날짜
|
||||
- **근무 가능 지역 / 출근 가능 여부** -> 실제 가능한 지역과 출근 빈도를 명확히 작성
|
||||
- **비자 / 근무 자격** -> 사실에 맞게 간결히 답변
|
||||
- **언어 능력** -> 실제 수준에 맞춰 작성. 필요하면 CEFR 또는 비즈니스/실무 가능 수준으로 표현
|
||||
- **포트폴리오 / GitHub / 블로그** -> `profile.yml`, `cv.md`, `article-digest.md`에 있는 검증된 링크만 사용
|
||||
|
||||
**출력 형식:**
|
||||
|
||||
```text
|
||||
## [회사] -- [역할] 지원서 답변
|
||||
|
||||
Base: Report #NNN | Score: X.X/5 | Archetype: [type]
|
||||
|
||||
---
|
||||
|
||||
### 1. [지원서의 정확한 질문]
|
||||
> [바로 복사/붙여넣기 가능한 답변]
|
||||
|
||||
### 2. [다음 질문]
|
||||
> [답변]
|
||||
|
||||
...
|
||||
|
||||
---
|
||||
|
||||
Notes:
|
||||
- [역할 변경, 공고 관련 관찰 등]
|
||||
- [후보자가 직접 확인해야 할 개인화 포인트]
|
||||
```
|
||||
|
||||
## Step 6 -- 지원 후 처리 (선택)
|
||||
|
||||
후보자가 지원서를 제출했다고 확인하면:
|
||||
1. tracker status 변경은 `data/applications.md`를 직접 수정하지 않습니다. `batch/tracker-additions/`에 `Applied` 상태의 TSV update를 쓰고 `node merge-tracker.mjs`로 병합합니다.
|
||||
2. 최종 답변을 report의 블록 G에 업데이트합니다.
|
||||
3. 다음 단계로 `/career-ops contacto`를 제안해 hiring manager 또는 recruiter에게 LinkedIn outreach를 할 수 있게 합니다.
|
||||
|
||||
## 스크롤 처리
|
||||
|
||||
지원서 폼에 화면에 보이는 것보다 질문이 더 많으면:
|
||||
- 후보자에게 아래로 스크롤한 뒤 다른 스크린샷을 공유해달라고 요청합니다.
|
||||
- 또는 남은 질문을 붙여넣어달라고 요청합니다.
|
||||
- 전체 폼을 다룰 때까지 반복해서 처리합니다.
|
||||
@@ -0,0 +1,62 @@
|
||||
# 모드: pipeline -- URL Inbox (Second Brain)
|
||||
|
||||
`data/pipeline.md`에 쌓인 채용 공고 URL을 처리합니다. 후보자는 원할 때 URL을 추가하고, 이후 `/career-ops pipeline`을 실행해 한 번에 처리합니다.
|
||||
|
||||
## Workflow
|
||||
|
||||
1. **읽기** `data/pipeline.md` -> "대기" / "Pending" / "Pendientes" 섹션의 `- [ ]` item 찾기
|
||||
2. **각 대기 URL에 대해**:
|
||||
a. `node reserve-report-num.mjs`를 실행해 다음 sequential `REPORT_NUM`을 atomic하게 예약합니다(report 작성 후 `node reserve-report-num.mjs --release <num>`으로 sentinel 해제).
|
||||
b. **공고 추출**: Playwright(`browser_navigate` + `browser_snapshot`) -> WebFetch -> WebSearch
|
||||
c. URL에 접근할 수 없으면 note와 함께 `- [!]`로 표시하고 계속합니다.
|
||||
d. **전체 auto-pipeline 실행**: Evaluation A-F -> Report .md -> PDF(score >= 3.0이면) -> Tracker
|
||||
e. **"대기"에서 "처리 완료"로 이동**: `- [x] #NNN | URL | Company | Role | Score/5 | PDF yes/no`
|
||||
3. **대기 URL이 3개 이상이어도 Playwright-backed 처리는 직렬로 실행합니다.** Playwright browser instance를 공유하므로 여러 browser-backed agent를 동시에 띄우지 않습니다. 병렬화가 필요하면 Playwright를 쓰지 않는 non-browser 작업에만 제한합니다.
|
||||
4. **마지막에** 요약 표를 표시합니다.
|
||||
|
||||
```markdown
|
||||
| # | Company | Role | Score | PDF | Recommended action |
|
||||
```
|
||||
|
||||
## pipeline.md format
|
||||
|
||||
```markdown
|
||||
## 대기
|
||||
- [ ] https://jobs.example.com/posting/123
|
||||
- [ ] https://boards.greenhouse.io/company/jobs/456 | Company Ltd | Senior PM
|
||||
- [!] https://private.url/job -- Error: login required
|
||||
|
||||
## 처리 완료
|
||||
- [x] #143 | https://jobs.example.com/posting/789 | Acme Korea | AI PM | 4.2/5 | PDF yes
|
||||
- [x] #144 | https://boards.greenhouse.io/xyz/jobs/012 | BigCo | SA | 2.1/5 | PDF no
|
||||
```
|
||||
|
||||
> Note: 섹션 heading은 EN("Pending"/"Processed"), ES("Pendientes"/"Procesadas"), DE("Offen"/"Verarbeitet"), FR("En attente"/"Traitees"), KO("대기"/"처리 완료") 모두 유연하게 읽습니다. 쓸 때는 기존 파일의 style을 따릅니다.
|
||||
|
||||
## URL에서 공고를 지능적으로 감지
|
||||
|
||||
1. **Playwright (preferred):** `browser_navigate` + `browser_snapshot`. 모든 SPA에 대응합니다.
|
||||
2. **WebFetch (fallback):** 정적 페이지 또는 Playwright를 사용할 수 없을 때 사용합니다.
|
||||
3. **WebSearch (last resort):** 공고를 index하는 secondary portal에서 검색합니다.
|
||||
|
||||
**특수 케이스:**
|
||||
- **LinkedIn**: login이 필요할 수 있음 -> `[!]`로 표시하고 후보자에게 공고 text를 붙여넣어 달라고 요청
|
||||
- **PDF**: URL이 PDF를 가리키면 Read tool로 직접 읽기
|
||||
- **`local:` prefix**: 로컬 파일 읽기. 예: `local:jds/linkedin-pm-ai.md` -> `jds/linkedin-pm-ai.md` 읽기
|
||||
- **원티드 / 리멤버 / 잡코리아 / 사람인 / LinkedIn KR**: 한국 시장에서 자주 쓰는 portal. cookie banner나 login wall이 있으면 Playwright로 먼저 확인
|
||||
|
||||
## 자동 번호 부여
|
||||
|
||||
1. `node reserve-report-num.mjs`를 실행해 다음 sequential number를 예약합니다(stdout이 `{###}` 반환).
|
||||
2. 해당 번호로 report를 작성합니다.
|
||||
3. report 작성 후 `node reserve-report-num.mjs --release {###}`를 실행해 sentinel을 해제합니다.
|
||||
|
||||
## Source sync
|
||||
|
||||
URL을 처리하기 전에 sync를 확인합니다.
|
||||
|
||||
```bash
|
||||
node cv-sync-check.mjs
|
||||
```
|
||||
|
||||
sync 문제가 있으면 계속하기 전에 후보자에게 알립니다.
|
||||
+153
@@ -0,0 +1,153 @@
|
||||
# Mode: latex — LaTeX/Overleaf CV Export
|
||||
|
||||
Export a tailored, ATS-optimized CV as a `.tex` file and compile it to PDF via `tectonic` or `pdflatex`.
|
||||
|
||||
## Pipeline
|
||||
|
||||
1. Read `cv.md` as source of truth
|
||||
2. Read `config/profile.yml` for candidate identity and contact info
|
||||
3. Ask the user for the JD if not already in context (text or URL)
|
||||
4. Extract 15-20 keywords from the JD
|
||||
5. Detect JD language → CV language (EN default)
|
||||
6. Detect role archetype → adapt framing
|
||||
7. Rewrite Professional Summary injecting JD keywords (same rules as `pdf` mode — NEVER invent skills)
|
||||
8. Select top 3-4 most relevant projects for the offer
|
||||
9. Reorder experience bullets by JD relevance
|
||||
10. Inject keywords naturally into existing achievements
|
||||
11. Build a JSON payload (see schema below) and write to `/tmp/cv-{candidate}-{company}.json`
|
||||
12. Run: `node build-cv-latex.mjs /tmp/cv-{candidate}-{company}.json output/cv-{candidate}-{company}-{YYYY-MM-DD}.tex`
|
||||
13. Run: `node generate-latex.mjs output/cv-{candidate}-{company}-{YYYY-MM-DD}.tex output/cv-{candidate}-{company}-{YYYY-MM-DD}.pdf`
|
||||
*(Replace `{candidate}`, `{company}`, `{YYYY-MM-DD}` with actual values.)*
|
||||
14. Report: .tex path, .pdf path, file sizes, section count, keyword coverage %
|
||||
|
||||
**Requires:** `tectonic` (preferred — `brew install tectonic`, auto-downloads packages) or `pdflatex` (MiKTeX / TeX Live) on PATH.
|
||||
|
||||
## Language support
|
||||
|
||||
- **Localized section titles are fine.** The validator counts `\section{}` blocks instead of matching English titles, so a Spanish/French/German CV (e.g. `\section{Educación}`) validates normally.
|
||||
- **CJK (Japanese / Chinese / Korean) is NOT supported on this path yet.** The template is a pdfLaTeX / Computer-Modern setup with no CJK font, so kana/kanji/hangul cannot render. `generate-latex.mjs` detects CJK characters and stops with guidance. For a Japanese CV, use `pdf` mode (HTML → PDF), which renders CJK via a `lang="ja"` font fallback.
|
||||
|
||||
## JSON Input Schema
|
||||
|
||||
Write a JSON file with this structure. `build-cv-latex.mjs` handles template merge and LaTeX escaping — no need to escape special characters yourself.
|
||||
|
||||
```json
|
||||
{
|
||||
"name": "Jane Smith",
|
||||
"contact_line": "San Francisco, CA | +1 415 555 0100",
|
||||
"email": { "url": "jane@example.com", "display": "jane@example.com" },
|
||||
"linkedin": { "url": "https://linkedin.com/in/janesmith", "display": "linkedin.com/in/janesmith" },
|
||||
"github": { "url": "https://github.com/janesmith", "display": "github.com/janesmith" },
|
||||
"education": [
|
||||
{
|
||||
"institution": "University Name",
|
||||
"location": "City, State",
|
||||
"degree": "Bachelor of Science in Computer Science",
|
||||
"dates": "2018 - 2022",
|
||||
"coursework": ["Data Structures", "Algorithms", "Machine Learning"]
|
||||
}
|
||||
],
|
||||
"experience": [
|
||||
{
|
||||
"company": "Company Name",
|
||||
"role": "Job Title",
|
||||
"location": "Remote",
|
||||
"dates": "June 2022 - Present",
|
||||
"bullets": [
|
||||
"Achievement bullet with JD keywords injected",
|
||||
"Another bullet with quantified impact"
|
||||
]
|
||||
}
|
||||
],
|
||||
"projects": [
|
||||
{
|
||||
"name": "Project Name",
|
||||
"context": "Tech stack summary for the project line",
|
||||
"dates": "",
|
||||
"bullets": [
|
||||
"What you built and what it does"
|
||||
]
|
||||
}
|
||||
],
|
||||
"skills": [
|
||||
{ "category": "Languages", "items": "Python, JavaScript, C++" },
|
||||
{ "category": "Frameworks", "items": "FastAPI, React, PyTorch" }
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
### Field reference
|
||||
|
||||
| Field | Type | Source |
|
||||
|-------|------|--------|
|
||||
| `name` | string | `profile.yml → candidate.full_name` |
|
||||
| `contact_line` | string | Phone / City, State / Visa — built from profile.yml |
|
||||
| `email.url` | string | Email for `\href{mailto:...}` (sanitized via sanitizeUrl, not LaTeX-escaped) |
|
||||
| `email.display` | string | Display text for the email link |
|
||||
| `linkedin.url` | string | Full URL with scheme for `\href{}` (sanitized via sanitizeUrl, not LaTeX-escaped) |
|
||||
| `linkedin.display` | string | Display text only (no scheme) |
|
||||
| `github.url` | string | Full URL with scheme for `\href{}` (sanitized via sanitizeUrl, not LaTeX-escaped) |
|
||||
| `github.display` | string | Display text only (no scheme) |
|
||||
| `education[].institution` | string | From cv.md Education |
|
||||
| `education[].location` | string | Institution location |
|
||||
| `education[].degree` | string | Degree name |
|
||||
| `education[].dates` | string | Date range |
|
||||
| `education[].coursework` | string[] | Optional — generates a coursework line if present |
|
||||
| `experience[].company` | string | From cv.md Experience |
|
||||
| `experience[].role` | string | Job title |
|
||||
| `experience[].location` | string | Work location |
|
||||
| `experience[].dates` | string | Date range |
|
||||
| `experience[].bullets` | string[] | Reordered and keyword-injected achievement bullets |
|
||||
| `projects[].name` | string | From cv.md Projects |
|
||||
| `projects[].context` | string | Tech stack — appears next to project name |
|
||||
| `projects[].dates` | string | Date range (or empty) |
|
||||
| `projects[].bullets` | string[] | Selected project achievements |
|
||||
| `skills[].category` | string | Skill category name (e.g. "Languages", "Frameworks") |
|
||||
| `skills[].items` | string | Comma-separated skills in that category |
|
||||
|
||||
## LaTeX Escaping (handled by the script)
|
||||
|
||||
`build-cv-latex.mjs` automatically escapes all user-supplied text before insertion:
|
||||
|
||||
| Character | Escape |
|
||||
|-----------|--------|
|
||||
| `&` | `\&` |
|
||||
| `%` | `\%` |
|
||||
| `$` | `\$` |
|
||||
| `#` | `\#` |
|
||||
| `_` | `\_` |
|
||||
| `{` | `\{` |
|
||||
| `}` | `\}` |
|
||||
| `~` | `\textasciitilde{}` |
|
||||
| `^` | `\textasciicircum{}` |
|
||||
| `\` | `\textbackslash{}` |
|
||||
| `±` | `$\pm$` |
|
||||
| `→` | `$\rightarrow$` |
|
||||
|
||||
**Exception:** URLs inside `\href{}` are NOT escaped by the LaTeX escaper, but `sanitizeUrl()` still validates the scheme (mailto/http/https) and removes dangerous characters to prevent injection.
|
||||
|
||||
## ATS Rules (same as pdf mode)
|
||||
|
||||
- Single-column layout (enforced by template)
|
||||
- Standard section headers: Education, Work Experience, Personal Projects, Technical Skills
|
||||
- UTF-8, machine-readable via `\pdfgentounicode=1`
|
||||
- Keywords distributed: first bullet of each role, skills section
|
||||
- No images, no graphics, no color in body text
|
||||
|
||||
## Keyword Injection Strategy
|
||||
|
||||
Same ethical rules as `modes/pdf.md`:
|
||||
- NEVER add skills the candidate doesn't have
|
||||
- Only reformulate existing experience using JD vocabulary
|
||||
- Examples:
|
||||
- JD says "RAG pipelines" → reword "LLM workflows with retrieval" to "RAG pipeline design"
|
||||
- JD says "MLOps" → reword "observability, evals" to "MLOps and observability"
|
||||
|
||||
## Overleaf Compatibility
|
||||
|
||||
The generated `.tex` file uses only standard CTAN packages (no custom or bundled dependencies):
|
||||
|
||||
- `latexsym`, `fullpage`, `titlesec`, `marvosym`, `color`, `verbatim`, `enumitem`
|
||||
- `hyperref`, `fancyhdr`, `babel`, `tabularx`, `fontawesome5`, `multicol`, `glyphtounicode`
|
||||
|
||||
Upload the `.tex` file directly to Overleaf — compiles with no extra configuration.
|
||||
+315
@@ -0,0 +1,315 @@
|
||||
# Mode: job — Full A-G Evaluation
|
||||
|
||||
When the candidate pastes a job (text or URL), ALWAYS deliver the 7 blocks (A-F evaluation + G legitimacy):
|
||||
|
||||
## Liveness gate (URL inputs)
|
||||
|
||||
When the candidate pastes a **URL** (not JD text), confirm the posting is still live before doing any evaluation. A dead link must never reach Block A — a 404/expired page wastes a full A-G evaluation, report, and PDF on phantom content.
|
||||
|
||||
1. Get the page content: if you arrived here from `auto-pipeline` (its Step 0.5 already navigated and cleared the link), reuse that snapshot — do not navigate again. On a direct URL entry, navigate with Playwright (`browser_navigate` + `browser_snapshot`) and read the title, URL, and visible content.
|
||||
2. Classify the posting:
|
||||
- **active posting evidence:** title/role + a real job description or an application/apply path
|
||||
- **closed posting evidence:** expired/closed/"no longer accepting applications", missing JD with only nav/footer, hard redirect to a generic careers/search page, or 404/410
|
||||
3. If the posting appears closed, **stop before Block A**: tell the candidate the link is dead, and if the entry came from `data/pipeline.md`, mark it `- [x] ~~Company | Role~~ — oferta nieaktywna`. Do not generate an evaluation, report, or CV.
|
||||
4. If the candidate pasted JD text (no URL), liveness cannot be verified — note that and proceed; there is no link to check.
|
||||
|
||||
Do not continue to Block A until this gate is resolved. The snapshot captured here is reused by Block G's freshness signals.
|
||||
|
||||
## Bounded Research Budget
|
||||
|
||||
Company, compensation, and hiring-signal research must be a single-pass lookup, not an open-ended investigation. This mode is an evaluation workflow, not deep company research.
|
||||
|
||||
Hard limits for Blocks D and G combined:
|
||||
- hard cap: 5 total WebSearch queries
|
||||
- Prefer targeted queries that answer more than one question; stop early when enough evidence exists.
|
||||
- Do not invoke `deep-research`, `deep`, or any other research skill.
|
||||
- Do not spawn subagents or delegate research to another agent.
|
||||
- Do not continue researching after the query cap is reached; summarize the evidence found and explicitly mark missing data as unavailable.
|
||||
|
||||
If deeper company research is useful, recommend running `/career-ops deep` separately after the evaluation.
|
||||
|
||||
## Step 0 — Archetype Detection
|
||||
|
||||
Classify the job into one of the 6 archetypes (see `_shared.md`). If it is a hybrid, indicate the 2 closest ones. This determines:
|
||||
- Which proof points to prioritize in block B
|
||||
- How to rewrite the summary in block E
|
||||
- Which STAR stories to prepare in block F
|
||||
|
||||
## Block A — Role Summary
|
||||
|
||||
Table with:
|
||||
- Archetype detected
|
||||
- Domain (platform/agentic/LLMOps/ML/enterprise)
|
||||
- Function (build/consult/manage/deploy)
|
||||
- Seniority
|
||||
- Remote (full/hybrid/onsite)
|
||||
- Team size (if mentioned)
|
||||
- TL;DR in 1 sentence
|
||||
|
||||
### Geo-mismatch check
|
||||
|
||||
After filling the Remote row, cross-check the posting's **structured location field** (the location/remote designation shown on the posting page or in ATS metadata — not the Remote row you just wrote) against the JD body:
|
||||
|
||||
- **Contradiction** = the location field says remote, but the JD body states a **binding attendance requirement**: "hybrid", "X days per week/month" in office, "in-office", "onsite"/"on-site", mandatory office attendance, or a relocation requirement.
|
||||
- **Not a contradiction:** negations ("no onsite requirement"), optional or occasional in-person events ("quarterly offsites", "optional co-working space"), or generic benefits boilerplate.
|
||||
- If the JD body says nothing about location or attendance, emit no flag — silence is absence of signal, not agreement.
|
||||
- If the input has no structured location field (pasted JD text only), skip this check.
|
||||
|
||||
On contradiction, add exactly one flag line at the top of Block B in the report, quoting the evidence **verbatim** (never paraphrase):
|
||||
|
||||
`⚠️ **Geo-mismatch:** location field says remote, but JD body says "{verbatim JD line}"`
|
||||
|
||||
The flag is an additive line only — Block B's existing content stays unchanged below it, and no flag line appears when there is no contradiction.
|
||||
|
||||
## Block B — Match with CV
|
||||
|
||||
Read `cv.md`. Create a table with each JD requirement mapped to exact lines in the CV.
|
||||
|
||||
**Adapted to the archetype:**
|
||||
- If FDE → prioritize delivery speed and client-facing proof points
|
||||
- If SA → prioritize system design and integrations
|
||||
- If PM → prioritize product discovery and metrics
|
||||
- If LLMOps → prioritize evals, observability, pipelines
|
||||
- If Agentic → prioritize multi-agent, HITL, orchestration
|
||||
- If Transformation → prioritize change management, adoption, scaling
|
||||
|
||||
**Gaps** section with mitigation strategy for each. For each gap:
|
||||
1. Is it a hard blocker or a nice-to-have?
|
||||
2. Can the candidate demonstrate adjacent experience?
|
||||
3. Is there a portfolio project that covers this gap?
|
||||
4. Concrete mitigation plan (phrase for cover letter, quick project, etc.)
|
||||
|
||||
## Block C — Level and Strategy
|
||||
|
||||
1. **Level detected** in the JD vs **candidate's natural level for that archetype**
|
||||
2. **"Sell senior without lying" plan**: specific phrases adapted to the archetype, concrete achievements to highlight, how to position founder experience as an advantage
|
||||
3. **"If they downlevel me" plan**: accept if compensation is fair, negotiate 6-month review, clear promotion criteria
|
||||
|
||||
## Block D — Comp and Demand
|
||||
|
||||
Use the bounded research budget above for:
|
||||
- Current salaries for the role (Glassdoor, Levels.fyi, Blind)
|
||||
- Company's compensation reputation
|
||||
- Demand trend for the role
|
||||
|
||||
Table with data and cited sources. If there is no data, state it instead of inventing.
|
||||
|
||||
## Block E — Customization Plan
|
||||
|
||||
| # | Section | Current status | Proposed change | Why |
|
||||
|---|---------|---------------|------------------|---------|
|
||||
| 1 | Summary | ... | ... | ... |
|
||||
| ... | ... | ... | ... | ... |
|
||||
|
||||
Top 5 changes to CV + Top 5 changes to LinkedIn to maximize match.
|
||||
|
||||
## Block F — Interview Plan
|
||||
|
||||
6-10 STAR+R stories mapped to JD requirements (STAR + **Reflection**):
|
||||
|
||||
| # | JD Requirement | STAR+R Story | S | T | A | R | Reflection |
|
||||
|---|-----------------|-----------------|---|---|---|---|------------|
|
||||
|
||||
The **Reflection** column captures what was learned or what would be done differently. This signals seniority — junior candidates describe what happened, senior candidates extract lessons.
|
||||
|
||||
**Story Bank:** If `interview-prep/story-bank.md` exists, check if any of these stories are already there. If not, append new ones. Over time this builds a reusable bank of 5-10 master stories that can be adapted to any interview question.
|
||||
|
||||
**Selected and framed according to the archetype:**
|
||||
- FDE → emphasize delivery speed and client-facing
|
||||
- SA → emphasize architectural decisions
|
||||
- PM → emphasize discovery and trade-offs
|
||||
- LLMOps → emphasize metrics, evals, production hardening
|
||||
- Agentic → emphasize orchestration, error handling, HITL
|
||||
- Transformation → emphasize adoption, organizational change
|
||||
|
||||
Also include:
|
||||
- 1 recommended case study (which of their projects to present and how)
|
||||
- Red-flag questions and how to answer them (e.g., "why did you sell your company?", "do you have a team of reports?")
|
||||
|
||||
## Block G — Posting Legitimacy
|
||||
|
||||
Analyze the job posting for signals that indicate whether this is a real, active opening. This helps the user prioritize their effort on opportunities most likely to result in a hiring process.
|
||||
|
||||
**Ethical framing:** Present observations, not accusations. Every signal has legitimate explanations. The user decides how to weigh them.
|
||||
|
||||
### Signals to analyze (in order):
|
||||
|
||||
**1. Posting Freshness** (from the Playwright snapshot captured during the liveness gate, or in `auto-pipeline` Step 0; unavailable if only JD text was pasted):
|
||||
- Date posted or "X days ago" -- extract from page
|
||||
- Apply button state (active / closed / missing / redirects to generic page)
|
||||
- If URL redirected to generic careers page, note it
|
||||
|
||||
**2. Description Quality** (from JD text):
|
||||
- Does it name specific technologies, frameworks, tools?
|
||||
- Does it mention team size, reporting structure, or org context?
|
||||
- Are requirements realistic? (years of experience vs technology age)
|
||||
- Is there a clear scope for the first 6-12 months?
|
||||
- Is salary/compensation mentioned?
|
||||
- What ratio of the JD is role-specific vs generic boilerplate?
|
||||
- Any internal contradictions? (entry-level title + staff requirements, etc.)
|
||||
|
||||
**3. Company Hiring Signals** (use remaining queries from the bounded research budget, combine with Block D research):
|
||||
- Search: `"{company}" layoffs {year}` -- note date, scale, departments
|
||||
- Search: `"{company}" hiring freeze {year}` -- note any announcements
|
||||
- If layoffs found: are they in the same department as this role?
|
||||
|
||||
**4. Reposting Detection** (from scan-history.tsv):
|
||||
- Check if company + similar role title appeared before with a different URL
|
||||
- Note how many times and over what period
|
||||
|
||||
**5. Role Market Context** (qualitative, no additional queries):
|
||||
- Is this a common role that typically fills in 4-6 weeks?
|
||||
- Does the role make sense for this company's business?
|
||||
- Is the seniority level one that legitimately takes longer to fill?
|
||||
|
||||
### Output format:
|
||||
|
||||
**Assessment:** One of three tiers:
|
||||
- **High Confidence** -- Multiple signals suggest a real, active opening
|
||||
- **Proceed with Caution** -- Mixed signals worth noting
|
||||
- **Suspicious** -- Multiple ghost job indicators, investigate before investing time
|
||||
|
||||
**Signals table:** Each signal observed with its finding and weight (Positive / Neutral / Concerning).
|
||||
|
||||
**Context Notes:** Any caveats (niche role, government job, evergreen position, etc.) that explain potentially concerning signals.
|
||||
|
||||
### Edge case handling:
|
||||
- **Government/academic postings:** Longer timelines are standard. Adjust thresholds (60-90 days is normal).
|
||||
- **Evergreen/continuous hire postings:** If the JD explicitly says "ongoing" or "rolling," note it as context -- this is not a ghost job, it is a pipeline role.
|
||||
- **Niche/executive roles:** Staff+, VP, Director, or highly specialized roles legitimately stay open for months. Adjust age thresholds accordingly.
|
||||
- **Startup / pre-revenue:** Early-stage companies may have vague JDs because the role is genuinely undefined. Weight description vagueness less heavily.
|
||||
- **No date available:** If posting age cannot be determined and no other signals are concerning, default to "Proceed with Caution" with a note that limited data was available. NEVER default to "Suspicious" without evidence.
|
||||
- **Recruiter-sourced (no public posting):** Freshness signals unavailable. Note that active recruiter contact is itself a positive legitimacy signal.
|
||||
|
||||
---
|
||||
|
||||
## Cover Letter Draft (auto-generated after Block G)
|
||||
|
||||
After saving the report and recording in the tracker, append a cover letter draft to the report file under `## Cover Letter Draft`. This is a starting point — not the final letter. The user completes it via `/career-ops cover {slug}`.
|
||||
|
||||
**How to generate the draft:**
|
||||
|
||||
1. Read `cv.md` — select 4 achievement bullets most relevant to the JD's top requirements (exact wording, real metrics only)
|
||||
2. Read `config/profile.yml` — extract candidate name, current role, years of experience
|
||||
3. Write a 2-sentence opening based on the role title and JD mission language
|
||||
4. Write a 1-paragraph profile intro from the cv.md summary, adapted to the JD domain
|
||||
5. Leave the "Problems / Why this company / Approach" section as a placeholder — this requires user input
|
||||
6. Detect and flag any gaps (domain mismatch, language requirement, start date urgency) so the user sees them immediately
|
||||
|
||||
**Draft format to append to the report:**
|
||||
|
||||
```markdown
|
||||
## Cover Letter Draft
|
||||
|
||||
> Draft generated at evaluation time. Complete via `/career-ops cover {slug}` to fill in angles, confirm research, and generate the PDF.
|
||||
> Gaps flagged below — address them during the cover flow.
|
||||
|
||||
---
|
||||
|
||||
**Opening** *(placeholder — refine with your "why this role" angle)*
|
||||
{2-sentence opening based on JD role title and mission language}
|
||||
|
||||
**Profile introduction**
|
||||
{1 paragraph from cv.md summary, adapted to JD domain and required competencies}
|
||||
|
||||
**Key achievements** *(selected from cv.md — exact wording preserved)*
|
||||
- **{lead from cv.md},** {impact sentence with metric}.
|
||||
- **{lead from cv.md},** {impact sentence with metric}.
|
||||
- **{lead from cv.md},** {impact sentence with metric}.
|
||||
- **{lead from cv.md},** {impact sentence with metric}.
|
||||
|
||||
**Problems I will solve** *(placeholder — requires company research + your input)*
|
||||
> To be completed: what challenges does {company} face that you'd address? How would you approach them?
|
||||
|
||||
**Closing**
|
||||
I am happy to discuss further at your convenience.
|
||||
|
||||
---
|
||||
|
||||
**Gaps flagged:**
|
||||
{List any detected gaps — domain mismatch, language requirement, start date urgency, title mismatch. If none, write "None detected."}
|
||||
|
||||
**JD keywords to mirror** *(extracted for ATS + human read)*
|
||||
{8-10 exact phrases from the JD}
|
||||
|
||||
---
|
||||
*Run `/career-ops cover {slug}` to complete angles, confirm company research, and generate the PDF.*
|
||||
```
|
||||
|
||||
Apply all language rules from `_shared.md` Professional Writing section to the draft content. No em dashes, no buzzwords, active voice, concrete claims only.
|
||||
|
||||
---
|
||||
|
||||
## Post-evaluation
|
||||
|
||||
**ALWAYS** after generating blocks A-G:
|
||||
|
||||
### 1. Save report .md
|
||||
|
||||
Save full evaluation in `reports/{###}-{company-slug}-{YYYY-MM-DD}.md`.
|
||||
|
||||
- `{###}` = next sequential number (3 digits, zero-padded). To allocate it atomically and prevent race conditions, you MUST run `node reserve-report-num.mjs` to claim the number (stdout returns `{###}`), write the report, and then run `node reserve-report-num.mjs --release {###}` to release the sentinel.
|
||||
- `{company-slug}` = company name in lowercase, without spaces (use hyphens)
|
||||
- `{YYYY-MM-DD}` = current date
|
||||
|
||||
**Report format:**
|
||||
|
||||
```markdown
|
||||
# Evaluation: {Company} — {Role}
|
||||
|
||||
**Date:** {YYYY-MM-DD}
|
||||
**URL:**
|
||||
**Archetype:** {detected}
|
||||
**Score:** {X/5}
|
||||
**Legitimacy:** {High Confidence | Proceed with Caution | Suspicious}
|
||||
**PDF:** {path or pending}
|
||||
|
||||
---
|
||||
|
||||
## A) Role Summary
|
||||
(full content of block A)
|
||||
|
||||
## B) Match with CV
|
||||
(full content of block B)
|
||||
|
||||
## C) Level and Strategy
|
||||
(full content of block C)
|
||||
|
||||
## D) Comp and Demand
|
||||
(full content of block D)
|
||||
|
||||
## E) Customization Plan
|
||||
(full content of block E)
|
||||
|
||||
## F) Interview Plan
|
||||
(full content of block F)
|
||||
|
||||
## G) Posting Legitimacy
|
||||
(full content of block G)
|
||||
|
||||
## H) Draft Application Answers
|
||||
(only if score >= 4.5 — draft answers for the application form)
|
||||
|
||||
---
|
||||
|
||||
## Keywords extracted
|
||||
(list of 15-20 keywords from the JD for ATS optimization)
|
||||
```
|
||||
|
||||
### 2. Record in tracker
|
||||
|
||||
**ALWAYS** record in `data/applications.md`:
|
||||
- Next sequential number
|
||||
- Current date
|
||||
- Company
|
||||
- Role
|
||||
- Score: match average (1-5)
|
||||
- Status: `Evaluated`
|
||||
- PDF: ❌ (or ✅ if auto-pipeline generated PDF)
|
||||
- Report: root-relative link `[001](reports/001-company-2026-01-01.md)` (when merged via `merge-tracker.mjs` it is normalized to be relative to the tracker's own dir, e.g. `../reports/...`; see #760)
|
||||
|
||||
**Tracker format:**
|
||||
|
||||
```markdown
|
||||
| # | Date | Company | Role | Score | Status | PDF | Report |
|
||||
```
|
||||
@@ -0,0 +1,22 @@
|
||||
# Mode: jobs — Multi-Job Comparison
|
||||
|
||||
Scoring matrix with 10 weighted dimensions:
|
||||
|
||||
| Dimension | Weight | Criteria 1-5 |
|
||||
|-----------|------|----------------|
|
||||
| North Star alignment | 25% | 5=exact target role, 1=unrelated |
|
||||
| CV match | 15% | 5=90%+ match, 1=<40% match |
|
||||
| Level (senior+) | 15% | 5=staff+, 4=senior, 3=mid-senior, 2=mid, 1=junior |
|
||||
| Estimated compensation | 10% | 5=top quartile, 1=below market |
|
||||
| Growth trajectory | 10% | 5=clear path to next level, 1=dead end |
|
||||
| Remote quality | 5% | 5=full remote async, 1=onsite only |
|
||||
| Company reputation | 5% | 5=top employer, 1=red flags |
|
||||
| Tech stack modernity | 5% | 5=cutting-edge AI/ML, 1=legacy |
|
||||
| Time-to-offer speed | 5% | 5=fast process, 1=6+ months |
|
||||
| Cultural signals | 5% | 5=builder culture, 1=bureaucratic |
|
||||
|
||||
For each job: score per dimension and total weighted score.
|
||||
Final ranking + recommendation with time-to-offer considerations.
|
||||
All reports must include **URL:** and **Legitimacy:** fields in the output header.
|
||||
|
||||
Ask the user for job postings if they are not in context. These can be text, URLs, or references to jobs already evaluated in the tracker.
|
||||
@@ -0,0 +1,214 @@
|
||||
# Mode: patterns -- Rejection Pattern Detector
|
||||
|
||||
## Purpose
|
||||
|
||||
Analyze all tracked applications to find patterns in outcomes and surface actionable insights. Identifies what's working (archetypes, remote policies, score ranges) and what's wasting time (geo-restricted roles, stack mismatches, low-score applications).
|
||||
|
||||
When interview sessions are available, it also reads *what the candidate actually says in the room* — a higher-resolution, lower-noise signal of role-fit than win/loss — to detect role **misfit**: when the candidate's strongest, most fluent answers point at a different role-type than the one they keep applying to (Step 1b).
|
||||
|
||||
## Inputs
|
||||
|
||||
- `data/applications.md` — Application tracker
|
||||
- `reports/` — Individual evaluation reports
|
||||
- `config/profile.yml` — User profile (for recommendation context)
|
||||
- `modes/_profile.md` — User archetypes and framing
|
||||
- `portals.yml` — Portal config (for filter update recommendations)
|
||||
- `interview-prep/sessions/*.md` — Interview sessions (optional; drives Step 1b). Drop real-interview transcripts and mock-session files here.
|
||||
|
||||
## Minimum Threshold
|
||||
|
||||
Before running analysis, check: does `data/applications.md` have at least 5 entries with status beyond "Evaluated" (i.e., Applied, Responded, Interview, Offer, Rejected, Discarded, SKIP)?
|
||||
|
||||
If not, tell the user:
|
||||
> "Not enough data yet -- {N}/5 applications have progressed beyond evaluation. Keep applying and come back when you have more outcomes to analyze."
|
||||
|
||||
Exit gracefully.
|
||||
|
||||
## Step 1 — Run Analysis Script
|
||||
|
||||
Execute:
|
||||
|
||||
```bash
|
||||
node analyze-patterns.mjs
|
||||
```
|
||||
|
||||
Parse the JSON output. It contains:
|
||||
|
||||
| Key | Contents |
|
||||
|-----|----------|
|
||||
| `metadata` | Total entries, date range, analysis date, counts by outcome |
|
||||
| `funnel` | Count per status stage (evaluated, applied, interview, offer, etc.) |
|
||||
| `scoreComparison` | Avg/min/max score per outcome group (positive, negative, self_filtered, pending) |
|
||||
| `archetypeBreakdown` | Per-archetype: total, positive, negative, self_filtered, conversion rate |
|
||||
| `blockerAnalysis` | Most frequent hard blockers: geo-restriction, stack-mismatch, seniority, onsite |
|
||||
| `remotePolicy` | Per-policy bucket: total, positive, negative, conversion rate |
|
||||
| `companySizeBreakdown` | Per-size bucket: startup, scaleup, enterprise |
|
||||
| `vendorAnalysis` | ATS channel analysis: per-vendor advance rate + coverage (see below) |
|
||||
| `scoreThreshold` | Recommended minimum score + reasoning |
|
||||
| `techStackGaps` | Most frequent tech gaps in negative outcomes |
|
||||
| `recommendations` | Top 5 actionable items with reasoning and impact level |
|
||||
|
||||
If the script returns `error`, display the error message and exit.
|
||||
|
||||
### `vendorAnalysis` — how to present it (IMPORTANT: causal humility)
|
||||
|
||||
`vendorAnalysis` groups **submitted** applications by the ATS vendor detected from
|
||||
each report's `**URL:**` (community ATS with clean fingerprints only: Greenhouse,
|
||||
Lever, Ashby, Workday — white-labeled ATS are not URL-detectable and fall into an
|
||||
unreported `unknown` bucket). `advanceRate` = share that reached
|
||||
`Responded`/`Interview`/`Offer` (a bare `Applied` does **not** count).
|
||||
|
||||
Motivation: *Algorithmic Monocultures in Hiring* (Bommasani et al., FAccT 2026,
|
||||
[arXiv:2605.27371](https://arxiv.org/abs/2605.27371)) — rejections through a shared
|
||||
screener are correlated, not independent, so a concentrated dead channel has
|
||||
diminishing returns.
|
||||
|
||||
When you narrate this to the user:
|
||||
- **Report channel yield, NOT discrimination.** A single tracker cannot separate
|
||||
"the vendor's algorithm filters me" from "that vendor skews toward a segment I
|
||||
fit poorly." Never claim bias. The honest, useful framing is: *"X% of your
|
||||
applications go through {vendor} and it's advancing far less than your other
|
||||
channels — route those companies through referral/direct contact instead."*
|
||||
- Respect `sufficientSample`: if false, mention the vendor only as an observation
|
||||
("too few to conclude"), never as a recommendation.
|
||||
- Always state coverage (`coveragePct`) so the user knows the stats cover a subset.
|
||||
- The `recommendations` array already contains the `high`-impact channel action
|
||||
when one qualifies — surface it verbatim rather than inventing a stronger claim.
|
||||
|
||||
## Step 1b — Session-Content Targeting Signal (optional)
|
||||
|
||||
Outcome data (Step 1) tells you *whether* you're winning. Interview sessions tell you *what role you're actually selling* in the room — a higher-resolution, lower-noise signal of role-fit than win/loss, which is confounded by comp, timing, headcount, and a dozen reasons unrelated to fit.
|
||||
|
||||
**Run this step only if session data exists.** Check: `interview-prep/sessions/*.md` (excluding `README.md` and `.gitkeep`).
|
||||
|
||||
If no sessions are present, **skip this step silently** and proceed with outcome-only analysis. This step is purely additive — the mode works fully without it, and gains resolution once sessions accumulate.
|
||||
|
||||
If sessions exist, for each one:
|
||||
1. Separate the candidate's answers from the interviewer's questions. If speaker labels are missing, infer them (turns tagged `**Interviewer:**` / `**Candidate:**` per the session format).
|
||||
2. Determine the competency / role-signal each substantive answer demonstrates (e.g. *instructional-design*, *systems-architecture*, *data-analysis*, *stakeholder-management*, *people-leadership*). **Tags first, inference as fallback:** if the answer already carries an explicit competency tag — `<!-- competency: ... -->` per the convention in `interview-prep/sessions/README.md`, whether written by hand or emitted by a debrief tool (e.g. `interview/debrief`) — use it directly. Only infer the competency yourself when no tag is present.
|
||||
3. Mark whether the answer is **fluent and specific** (concrete metrics, named tools, real decisions) or **flat and generic** (hedged, vague, textbook).
|
||||
|
||||
Then aggregate across all sessions:
|
||||
- **Where do the fluent/specific answers cluster?** That competency cluster is the role-type the candidate is *actually* strongest at — regardless of the title on their résumé.
|
||||
- Compare that cluster against (a) the archetypes in `modes/_profile.md` and (b) the distribution of roles actually applied to in `data/applications.md`.
|
||||
- **Surface the misfit:** if the strongest cluster (X) is under-represented in the roles applied to (Y), that is a targeting-correction signal:
|
||||
> "Your answers consistently light up around **X**, but you're mostly applying to **Y**. Consider adding archetype X and reweighting `portals.yml` `title_filter.positive` toward it."
|
||||
|
||||
This is the difference between *"you're losing"* (Step 1, outcomes) and *"you're aiming at the wrong target"* (Step 1b, content). Feed the result into the Step 2 report and Step 4 recommendations.
|
||||
|
||||
**Privacy:** sessions contain real interviewer names and companies. Read them locally only; **never quote a real name or company into a committed report.** Summarize the signal (competency clusters), never the content.
|
||||
|
||||
## Step 2 — Generate Report
|
||||
|
||||
Write the report to `reports/pattern-analysis-{YYYY-MM-DD}.md`.
|
||||
|
||||
### Report Structure
|
||||
|
||||
```markdown
|
||||
# Pattern Analysis -- {YYYY-MM-DD}
|
||||
|
||||
**Applications analyzed:** {total}
|
||||
**Date range:** {from} to {to}
|
||||
**Outcomes:** {positive} positive, {negative} negative, {self_filtered} self-filtered, {pending} pending
|
||||
|
||||
---
|
||||
|
||||
## Conversion Funnel
|
||||
|
||||
Show each status with count and percentage of total. Use a simple table:
|
||||
|
||||
| Stage | Count | % |
|
||||
|-------|-------|---|
|
||||
| Evaluated | X | X% |
|
||||
| Applied | X | X% |
|
||||
| ... | | |
|
||||
|
||||
## Score vs Outcome
|
||||
|
||||
| Outcome | Avg Score | Min | Max | Count |
|
||||
|---------|-----------|-----|-----|-------|
|
||||
| Positive | X.X/5 | X.X | X.X | X |
|
||||
| Negative | ... | | | |
|
||||
| Self-filtered | ... | | | |
|
||||
| Pending | ... | | | |
|
||||
|
||||
## Archetype Performance
|
||||
|
||||
Table with each archetype, total applications, positive outcomes, conversion rate.
|
||||
Highlight the best-performing archetype and the worst.
|
||||
|
||||
## Top Blockers
|
||||
|
||||
Frequency table of recurring hard blockers (geo-restriction, stack-mismatch, etc.).
|
||||
Note the percentage of all applications affected by each.
|
||||
|
||||
## Remote Policy Patterns
|
||||
|
||||
Table showing conversion rate by remote policy bucket (global, regional, geo-restricted, hybrid/onsite).
|
||||
|
||||
## Tech Stack Gaps
|
||||
|
||||
List of most common missing skills in negative/self-filtered outcomes with frequency.
|
||||
|
||||
## Recommended Score Threshold
|
||||
|
||||
State the data-driven minimum score and reasoning.
|
||||
|
||||
## Targeting Signal (interview sessions)
|
||||
|
||||
*Include this section only if Step 1b ran.* Summarize, in competency terms only (no real names/companies):
|
||||
- Which competency cluster the candidate's answers are strongest at (X)
|
||||
- Which role-types they're actually applying to (Y)
|
||||
- The misfit gap and the suggested realignment (add archetype X / reweight `portals.yml`)
|
||||
|
||||
## Recommendations
|
||||
|
||||
Number the top recommendations (from the script output). For each:
|
||||
1. **[IMPACT]** Action to take
|
||||
Reasoning behind the recommendation.
|
||||
```
|
||||
|
||||
## Step 3 — Present Summary
|
||||
|
||||
Show the user a condensed version with:
|
||||
1. One-line stat summary (X applications, Y% applied, Z% positive outcome)
|
||||
2. Top 3 findings (most impactful patterns)
|
||||
3. Link to full report
|
||||
|
||||
Example:
|
||||
> **Pattern Analysis Complete** (24 applications, Apr 7-8)
|
||||
>
|
||||
> Key findings:
|
||||
> - Geo-restricted roles are 0% conversion (7 of 24) -- stop evaluating US/Canada-only postings
|
||||
> - Regional/global remote roles convert at 57-67% -- these are your sweet spot
|
||||
> - No positive outcomes below 4.2/5 -- consider this your score floor
|
||||
>
|
||||
> Full report: `reports/pattern-analysis-2026-04-08.md`
|
||||
|
||||
## Step 4 — Offer to Apply Recommendations
|
||||
|
||||
Ask the user if they want to act on any recommendations:
|
||||
|
||||
> "Want me to apply any of these recommendations? I can:
|
||||
> - Update `portals.yml` to filter out geo-restricted roles
|
||||
> - Set a score threshold in `_profile.md` for PDF generation
|
||||
> - Adjust archetype targeting based on what's converting
|
||||
> - Realign targeting from the session signal — add the under-targeted archetype X to `modes/_profile.md` and reweight `portals.yml` `title_filter.positive` (if Step 1b ran)
|
||||
>
|
||||
> Just say which ones, or 'all' to apply everything."
|
||||
|
||||
If the user agrees:
|
||||
- For portal filter changes: edit `portals.yml`
|
||||
- For profile/archetype changes: edit `modes/_profile.md` (NEVER `_shared.md`)
|
||||
- For score threshold: add to `config/profile.yml` under a `patterns` key
|
||||
|
||||
## Outcome Classification
|
||||
|
||||
For reference, outcomes are classified as:
|
||||
|
||||
| Status | Outcome |
|
||||
|--------|---------|
|
||||
| Interview, Offer, Responded, Applied | **Positive** (invested effort or got traction) |
|
||||
| Rejected, Discarded | **Negative** (company said no or offer closed) |
|
||||
| SKIP, NO APLICAR | **Self-filtered** (user decided not to apply) |
|
||||
| Evaluated | **Pending** (no action taken yet) |
|
||||
+225
@@ -0,0 +1,225 @@
|
||||
# Mode: pdf — ATS-Optimized PDF Generation
|
||||
|
||||
## Full pipeline
|
||||
|
||||
1. Read `cv.md` as the source of truth
|
||||
2. Ask the user for the JD if it is not in context (text or URL)
|
||||
3. Extract 15-20 keywords from the JD
|
||||
4. Detect JD language → CV language (EN default)
|
||||
5. Detect company location → paper format:
|
||||
- US/Canada → `letter`
|
||||
- Rest of the world → `a4`
|
||||
6. Detect role archetype → adapt framing
|
||||
7. Build an internal recruiter-side risk map from the JD using `modes/heuristics/recruiter-side.md`: likely doubts, matching evidence, and which document section should address each doubt
|
||||
8. Rewrite Professional Summary by injecting JD keywords + exit narrative bridge ("Built and sold a business. Now applying systems thinking to [JD domain].")
|
||||
9. Select top 3-4 most relevant projects for the job
|
||||
10. Reorder experience bullets by JD relevance and by the risk map: strongest matching evidence first
|
||||
11. Build competency grid from JD requirements (6-8 keyword phrases)
|
||||
12. Inject keywords naturally into existing achievements (NEVER invent)
|
||||
13. Apply the six-second clarity gate from `modes/heuristics/recruiter-side.md`: top third must make target role, strongest fit, and proof obvious
|
||||
14. Generate full HTML from template + personalized content
|
||||
15. Read `name` from `config/profile.yml` → normalize to kebab-case lowercase (e.g. "John Doe" → "john-doe") → `{candidate}`
|
||||
16. Write HTML to `output/cv-{candidate}-{company}.html` (NOT a temp dir — the recorded HTML is what the dashboard's `D` hotkey regenerates from, so it must survive temp cleanup)
|
||||
17. Execute: `node generate-pdf.mjs output/cv-{candidate}-{company}.html output/cv-{candidate}-{company}-{YYYY-MM-DD}.pdf --format={letter|a4} --report={report number}` — `{report number}` is the NNN from the report filename/link (e.g. `008` for `reports/008-acme-….md`), not the tracker `#` column. Pass it whenever the application has (or will have) a report; it records the PDF↔report linkage in `data/pdf-index.tsv` so the dashboard can open and regenerate the exact PDF. Omit it only for one-off CVs with no tracker entry.
|
||||
18. Report: PDF path, number of pages, keyword coverage %
|
||||
|
||||
## ATS Rules (clean parsing)
|
||||
|
||||
- Single-column layout (no sidebars, no parallel columns)
|
||||
- Standard headers: "Professional Summary", "Work Experience", "Education", "Skills", "Certifications", "Projects"
|
||||
- No text in images/SVGs
|
||||
- No critical info in PDF headers/footers (ATS ignores them)
|
||||
- UTF-8, selectable text (not rasterized)
|
||||
- No nested tables
|
||||
- Distributed JD keywords: Summary (top 5), first bullet of each role, Skills section
|
||||
- No hidden text, keyword stuffing, or white-font tricks. Optimize for parseability plus human review.
|
||||
|
||||
## Recruiter Review Gates
|
||||
|
||||
- The summary should answer: "What role is this person targeting, and why this one?"
|
||||
- The first screen should show 1-2 proof points that map to the JD's highest-risk requirements.
|
||||
- Bullets should emphasize outcomes, systems, users, or business effects rather than task history.
|
||||
- Logistics such as location, work authorization, salary, and availability belong in the CV only when appropriate for the market and profile; otherwise handle them in form answers or recruiter scripts.
|
||||
|
||||
## PDF Design
|
||||
|
||||
- **Fonts**: Space Grotesk (headings, 600-700) + DM Sans (body, 400-500)
|
||||
- **Fonts self-hosted**: `fonts/`
|
||||
- **Header**: name in Space Grotesk 24px bold + gradient line `linear-gradient(to right, hsl(187,74%,32%), hsl(270,70%,45%))` 2px + contact row
|
||||
- **Section headers**: Space Grotesk 13px, uppercase, letter-spacing 0.05em, color cyan primary
|
||||
- **Body**: DM Sans 11px, line-height 1.5
|
||||
- **Company names**: accent purple color `hsl(270,70%,45%)`
|
||||
- **Margins**: 0.6in
|
||||
- **Background**: pure white
|
||||
|
||||
## Section order (optimized "6-second recruiter scan")
|
||||
|
||||
1. Header (large name, gradient, contact, portfolio link)
|
||||
2. Professional Summary (3-4 lines, keyword-dense)
|
||||
3. Core Competencies (6-8 keyword phrases in flex-grid)
|
||||
4. Work Experience (reverse chronological)
|
||||
5. Projects (top 3-4 most relevant)
|
||||
6. Education & Certifications
|
||||
7. Skills (languages + technical)
|
||||
|
||||
## Keyword injection strategy (ethical, truth-based)
|
||||
|
||||
Examples of legitimate reformulation:
|
||||
- JD says "RAG pipelines" and CV says "LLM workflows with retrieval" → change to "RAG pipeline design and LLM orchestration workflows"
|
||||
- JD says "MLOps" and CV says "observability, evals, error handling" → change to "MLOps and observability: evals, error handling, cost monitoring"
|
||||
- JD says "stakeholder management" and CV says "collaborated with team" → change to "stakeholder management across engineering, operations, and business"
|
||||
|
||||
**NEVER add skills that the candidate does not have. Only reword real experience using the exact JD vocabulary.**
|
||||
|
||||
## Template HTML
|
||||
|
||||
Use the template in `cv-template.html`. Replace the `{{...}}` placeholders with personalized content:
|
||||
|
||||
| Placeholder | Content |
|
||||
|-------------|-----------|
|
||||
| `{{LANG}}` | CV language code (e.g. `en`, `es`, `ja`, `ar`). Drives language-specific CSS in the template: `ja` enables a CJK font fallback so Japanese renders instead of tofu (□); `ar` enables RTL + Arabic fonts. Use the BCP-47/ISO-639 code that matches the CV language. |
|
||||
| `{{PAGE_WIDTH}}` | `8.5in` (letter) or `210mm` (A4) |
|
||||
| `{{PHOTO}}` | Opt-in profile photo (#264). When `profile.yml` has a non-empty `candidate.photo`, replace with `<img class="cv-photo" src="<path-or-data-URL>" alt="{{NAME}}">`; otherwise **remove the whole `{{PHOTO}}` line** so no markup (and no `<img>`) is emitted. Opt-in for DACH/European markets — an absent photo renders identically (pixel-for-pixel) to the photoless layout (US/UK and many-market ATS penalize photos). |
|
||||
| `{{NAME}}` | (from profile.yml) |
|
||||
| `{{PHONE}}` | (from profile.yml — include with its separator only when `profile.yml` has a non-empty `phone` value; omit both the `<a href="tel:…">` element and the following `<span class="separator">` otherwise) |
|
||||
| `{{EMAIL}}` | (from profile.yml) |
|
||||
| `{{LINKEDIN_URL}}` | [from profile.yml] |
|
||||
| `{{LINKEDIN_DISPLAY}}` | [from profile.yml] |
|
||||
| `{{PORTFOLIO_URL}}` | [from profile.yml] (or /es depending on language) |
|
||||
| `{{PORTFOLIO_DISPLAY}}` | [from profile.yml] (or /es depending on language) |
|
||||
| `{{LOCATION}}` | [from profile.yml] |
|
||||
| `{{SECTION_SUMMARY}}` | Professional Summary |
|
||||
| `{{SUMMARY_TEXT}}` | Personalized summary with keywords |
|
||||
| `{{SECTION_COMPETENCIES}}` | Core Competencies |
|
||||
| `{{COMPETENCIES}}` | `<span class="competency-tag">keyword</span>` × 6-8 |
|
||||
| `{{SECTION_EXPERIENCE}}` | Work Experience |
|
||||
| `{{EXPERIENCE}}` | HTML for each job with reordered bullets |
|
||||
| `{{SECTION_PROJECTS}}` | Projects |
|
||||
| `{{PROJECTS}}` | HTML for top 3-4 projects |
|
||||
| `{{SECTION_EDUCATION}}` | Education |
|
||||
| `{{EDUCATION}}` | Education HTML |
|
||||
| `{{SECTION_CERTIFICATIONS}}` | Certifications |
|
||||
| `{{CERTIFICATIONS}}` | Certifications HTML |
|
||||
| `{{SECTION_SKILLS}}` | Skills |
|
||||
| `{{SKILLS}}` | Skills HTML |
|
||||
|
||||
### Profile photo (opt-in, market-specific)
|
||||
|
||||
The `{{PHOTO}}` slot is **off by default** and intentionally market-specific:
|
||||
|
||||
- **DACH / much of continental Europe** (Germany, Austria, Switzerland): a professional photo is standard and often expected. Opt in by setting `candidate.photo` in `config/profile.yml` (a local file path or a `data:` URL).
|
||||
- **US / UK / Canada / Australia and many ATS-first markets**: photos are discouraged and can trip bias-avoidance filters. Leave `candidate.photo` empty — the `{{PHOTO}}` line is dropped entirely, no `<img>` is emitted, and the CV renders **pixel-for-pixel identical** to today's photoless layout.
|
||||
|
||||
When set, the photo floats into the top corner (mirrored for RTL/Arabic) and the header/summary text wraps beside it; `.cv-photo` in `cv-template.html` controls its size and framing.
|
||||
|
||||
## Canva CV Generation (optional)
|
||||
|
||||
If `config/profile.yml` has `cv.canva_resume_design_id` set, offer the user a choice before generating:
|
||||
- **"HTML/PDF (fast, ATS-optimized)"** — existing flow above
|
||||
- **"Canva CV (visual, design-preserving)"** — new flow below
|
||||
|
||||
If the user has no `cv.canva_resume_design_id`, skip this prompt and use the HTML/PDF flow.
|
||||
|
||||
### Canva workflow
|
||||
|
||||
#### Step 1 — Duplicate the base design
|
||||
|
||||
a. `export-design` the base design (using `cv.canva_resume_design_id`) as PDF → get download URL
|
||||
b. `import-design-from-url` using that download URL → creates a new editable design (the duplicate)
|
||||
c. Note the new `design_id` for the duplicate
|
||||
|
||||
#### Step 2 — Read the design structure
|
||||
|
||||
a. `get-design-content` on the new design → returns all text elements (richtexts) with their content
|
||||
b. Map text elements to CV sections by content matching:
|
||||
- Look for the candidate's name → header section
|
||||
- Look for "Summary" or "Professional Summary" → summary section
|
||||
- Look for company names from cv.md → experience sections
|
||||
- Look for degree/school names → education section
|
||||
- Look for skill keywords → skills section
|
||||
c. If mapping fails, show the user what was found and ask for guidance
|
||||
|
||||
#### Step 3 — Generate tailored content
|
||||
|
||||
Same content generation as the HTML flow (Steps 1-11 above):
|
||||
- Rewrite Professional Summary with JD keywords + exit narrative
|
||||
- Reorder experience bullets by JD relevance
|
||||
- Select top competencies from JD requirements
|
||||
- Inject keywords naturally (NEVER invent)
|
||||
|
||||
**IMPORTANT — Character budget rule:** Each replacement text MUST be approximately the same length as the original text it replaces (within ±15% character count). If tailored content is longer, condense it. The Canva design has fixed-size text boxes — longer text causes overlapping with adjacent elements. Count the characters in each original element from Step 2 and enforce this budget when generating replacements.
|
||||
|
||||
#### Step 4 — Apply edits
|
||||
|
||||
a. `start-editing-transaction` on the duplicate design
|
||||
b. `perform-editing-operations` with `find_and_replace_text` for each section:
|
||||
- Replace summary text with tailored summary
|
||||
- Replace each experience bullet with reordered/rewritten bullets
|
||||
- Replace competency/skills text with JD-matched terms
|
||||
- Replace project descriptions with top relevant projects
|
||||
c. **Reflow layout after text replacement:**
|
||||
After applying all text replacements, the text boxes auto-resize but neighboring elements stay in place. This causes uneven spacing between work experience sections. Fix this:
|
||||
1. Read the updated element positions and dimensions from the `perform-editing-operations` response
|
||||
2. For each work experience section (top to bottom), calculate where the bullets text box ends: `end_y = top + height`
|
||||
3. The next section's header should start at `end_y + consistent_gap` (use the original gap from the template, typically ~30px)
|
||||
4. Use `position_element` to move the next section's date, company name, role title, and bullets elements to maintain even spacing
|
||||
5. Repeat for all work experience sections
|
||||
d. **Verify layout before commit:**
|
||||
- `get-design-thumbnail` with the transaction_id and page_index=1
|
||||
- Visually inspect the thumbnail for: text overlapping, uneven spacing, text cut off, text too small
|
||||
- If issues remain, adjust with `position_element`, `resize_element`, or `format_text`
|
||||
- Repeat until layout is clean
|
||||
e. Show the user the final preview and ask for approval
|
||||
f. `commit-editing-transaction` to save (ONLY after user approval)
|
||||
|
||||
#### Step 5 — Export and download PDF
|
||||
|
||||
a. `export-design` the duplicate as PDF (format: a4 or letter based on JD location)
|
||||
b. **IMMEDIATELY** download the PDF using Bash:
|
||||
```bash
|
||||
curl -sL -o "output/cv-{candidate}-{company}-canva-{YYYY-MM-DD}.pdf" "{download_url}"
|
||||
```
|
||||
The export URL is a pre-signed S3 link that expires in ~2 hours. Download it right away.
|
||||
c. Verify the download:
|
||||
```bash
|
||||
file output/cv-{candidate}-{company}-canva-{YYYY-MM-DD}.pdf
|
||||
```
|
||||
Must show "PDF document". If it shows XML or HTML, the URL expired — re-export and retry.
|
||||
d. Report: PDF path, file size, Canva design URL (for manual tweaking)
|
||||
|
||||
#### Error handling
|
||||
|
||||
- If `import-design-from-url` fails → fall back to HTML/PDF pipeline with message
|
||||
- If text elements can't be mapped → warn user, show what was found, ask for manual mapping
|
||||
- If `find_and_replace_text` finds no matches → try broader substring matching
|
||||
- Always provide the Canva design URL so the user can edit manually if auto-edit fails
|
||||
|
||||
## Cover Letter Sub-flow
|
||||
|
||||
After generating the CV PDF, offer to generate a cover letter:
|
||||
|
||||
```text
|
||||
CV PDF generated: output/{path}
|
||||
|
||||
Want a cover letter for this role too?
|
||||
- Say "yes" or "cover letter" to generate one now
|
||||
- Or run `/career-ops cover {slug}` later
|
||||
```
|
||||
|
||||
Apply `voice-dna.md` (if present) to the cover letter — full guardrail, conversational voice included (Tier 1 + Tier 2). The CV PDF itself stays Tier 1 only (formal ATS register). See `_shared.md` → Voice DNA.
|
||||
|
||||
If the user says yes, run the full cover letter flow from `modes/cover.md` in slug mode:
|
||||
1. Load the existing `## Cover Letter Draft` from the evaluation report as a starting point
|
||||
2. Run company research (Step 3 of cover.md)
|
||||
3. Present keyword list for confirmation (Step 4)
|
||||
4. Surface any gaps (Step 5)
|
||||
5. Ask the four prompts: why / problems / approach / tone (Step 6)
|
||||
6. Draft in chat, wait for approval (Steps 7-8)
|
||||
7. Generate cover letter PDF via `node generate-cover-letter.mjs` (Step 9)
|
||||
8. Report both PDF paths
|
||||
|
||||
Do not auto-generate the cover letter PDF without going through the interactive steps above.
|
||||
|
||||
## Post-generation
|
||||
|
||||
Update tracker if the job is already registered: change PDF from ❌ to ✅.
|
||||
@@ -0,0 +1,97 @@
|
||||
# Mode: pipeline — URL Inbox (Second Brain)
|
||||
|
||||
Process job URLs stored in `data/pipeline.md`. The user adds URLs at any time and then executes `/career-ops pipeline` to process them all.
|
||||
|
||||
## Liveness sweep
|
||||
|
||||
**Run this before processing any URLs.** Entries added by the scanner in headless/batch mode carry `**Verification:** unconfirmed (batch mode)` because Playwright was unavailable at scan time — they were never checked for liveness. Without a sweep, dead postings reach evaluation one tab at a time, burning time and tokens on phantom roles (a single inbox of 8 stale URLs produces 8 wasted evaluations).
|
||||
|
||||
Sweep all pending URLs in one batch with the zero-token liveness checker before the per-URL loop:
|
||||
|
||||
1. Collect every `- [ ]` URL from the "Pending" section into a temp file (one URL per line).
|
||||
2. Run `node check-liveness.mjs --file <tmpfile>` (add `--throttle` for large batches to stay under WAF rate limits; it's pure Playwright, zero Claude tokens). The checker prints a per-URL verdict and exits non-zero if any are expired/uncertain.
|
||||
3. For every URL the checker reports as **expired/closed**, resolve the pipeline entry instead of processing it: move it to "Processed" as `- [x] ~~URL | Company | Role~~ — posting expired (liveness sweep)` and, if it already has a tracker row, mark it `Discarded`. **Do not** extract the JD, evaluate, or generate a report/PDF for it.
|
||||
4. Leave `uncertain` results in place to be confirmed during normal per-URL extraction (a transient timeout shouldn't drop a possibly-live posting).
|
||||
5. Only the surviving live URLs continue to the per-URL processing loop below.
|
||||
|
||||
This complements — does not replace — the per-URL liveness gate in `auto-pipeline` (Step 0.5) and the `apply` preflight: the sweep drops the dead postings up front, in bulk, so the user never opens a tab or spends a token on them.
|
||||
|
||||
## Workflow
|
||||
|
||||
1. **Read** `data/pipeline.md` → search for `- [ ]` items in the "Pending" section. Run the **Liveness sweep** (above) first and drop any expired entries before continuing.
|
||||
2. **For each surviving pending URL**:
|
||||
a. Claim the next sequential `REPORT_NUM` atomically by running `node reserve-report-num.mjs` (and release the sentinel using `node reserve-report-num.mjs --release <num>` after the report is written)
|
||||
b. **Extract JD** using Playwright (browser_navigate + browser_snapshot) → WebFetch → WebSearch
|
||||
c. If the URL is not accessible → mark as `- [!]` with a note and continue
|
||||
d. **Execute full auto-pipeline**: Evaluation A-F → Report .md → PDF (if score >= `auto_pdf_score_threshold`) → Tracker
|
||||
e. **Move from "Pending" to "Processed"**: `- [x] #NNN | URL | Company | Role | Score/5 | PDF ✅/❌`
|
||||
|
||||
**About the PDF gate (configurable):** Read `config/profile.yml` → `auto_pdf_score_threshold`. If the key does not exist, default to `3.0` (this mode's original gate). If the evaluation score is less than the threshold, skip PDF generation: write the report normally, show in the header `**PDF:** not generated — run /career-ops pdf {company-slug} to create on demand`, and mark PDF ❌ in the tracker. If the score is ≥ threshold, generate the PDF as usual.
|
||||
|
||||
**Tuning it:** Generating a tailored PDF costs ~30–60s per entry (Playwright launch + HTML render) and produces files that often go unused — most roles score in the 2.x/3.x range and never reach the application stage. Raise `auto_pdf_score_threshold` (e.g. `4.0`) to write only the report for marginal offers and produce the PDF on demand via `/career-ops pdf {slug}`; set `0` to generate one for every offer. Both modes (Path A `/career-ops pipeline` and Path B `batch/batch-runner.sh`) read the same key, so behavior is identical regardless of which path processes an offer.
|
||||
3. **If there are 3+ pending URLs**, launch agents in parallel (Agent tool with `run_in_background`) to maximize speed — at most one agent per pending URL. Each is a **single-pass worker**: it evaluates its one URL and must **not** spawn further subagents or invoke other skills; its company/comp research stays inline and bounded (see `modes/_shared.md` → Subagent delegation). This keeps a pipeline run from fanning out into a recursive agent swarm.
|
||||
4. **At the end**, show summary table:
|
||||
|
||||
```
|
||||
| # | Company | Role | Score | PDF | Recommended action |
|
||||
```
|
||||
|
||||
## Format of pipeline.md
|
||||
|
||||
```markdown
|
||||
## Pending
|
||||
- [ ] https://jobs.example.com/posting/123
|
||||
- [ ] https://boards.greenhouse.io/company/jobs/456 | Company Inc | Senior PM
|
||||
- [ ] https://jobs.ashbyhq.com/acme/789 | Acme Corp | Solutions Architect | Remote (US)
|
||||
- [ ] https://jobs.ashbyhq.com/acme/790 | Acme Corp | AI Engineer | Remote (US) | 180000-220000 USD
|
||||
- [ ] https://jobs.ashbyhq.com/acme/791 | Acme Corp | Staff PM | note: curated shortlist
|
||||
- [!] https://private.url/job — Error: login required
|
||||
|
||||
## Processed
|
||||
- [x] #143 | https://jobs.example.com/posting/789 | Acme Corp | AI PM | 4.2/5 | PDF ✅
|
||||
- [x] #144 | https://boards.greenhouse.io/xyz/jobs/012 | BigCo | SA | 2.1/5 | PDF ❌
|
||||
```
|
||||
|
||||
Pending lines are variable-width. The rawest form is a bare pasted URL,
|
||||
`- [ ] {url}` (1 column) — what you drop into the inbox by hand. Scanner-written
|
||||
entries add `| {company} | {title}` (3 columns) plus two optional trailing
|
||||
columns: `| {location}` (4th) and `| {compensation}` (5th). The scanner fills the
|
||||
trailing columns only when the ATS exposes them, so 1-, 3-, 4-, and 5-column rows
|
||||
are all valid — `{url} | {company} | {title} | {location} | {compensation}` is the
|
||||
maximum (canonical) shape, not the only one. The columns are positional, so a row
|
||||
carrying compensation always includes the location cell (empty if unknown); a row
|
||||
with only a location stays 4 columns. Existing shorter rows remain valid and are
|
||||
read as having empty values for the missing trailing columns.
|
||||
|
||||
One further trailing segment is optional and **labeled**, not positional:
|
||||
`| note: {text}`. Unlike the positional cells above, it can ride on any row shape
|
||||
(`- [ ] {url} | {company} | {title} | note: curated shortlist` is valid), because
|
||||
the `note:` prefix identifies it regardless of column position. It carries a
|
||||
free-text ranking signal an importer attached to the offer (the deterministic
|
||||
scanner never sets it). Treat it as a hint when triaging; it does not change how
|
||||
you process the URL.
|
||||
|
||||
## Intelligent JD detection from URL
|
||||
|
||||
1. **Playwright (preferred):** `browser_navigate` + `browser_snapshot`. Works with all SPAs.
|
||||
2. **WebFetch (fallback):** For static pages or when Playwright is unavailable.
|
||||
3. **WebSearch (last resort):** Search in secondary portals that index the JD.
|
||||
|
||||
**Special cases:**
|
||||
- **LinkedIn**: May require login → mark `[!]` and ask the user to paste the text
|
||||
- **PDF**: If the URL points to a PDF, read it directly with the Read tool
|
||||
- **`local:` prefix**: Read the local file. Example: `local:jds/linkedin-pm-ai.md` → read `jds/linkedin-pm-ai.md`
|
||||
|
||||
## Automatic numbering
|
||||
|
||||
1. Run `node reserve-report-num.mjs` to claim the next sequential number (stdout returns `{###}`).
|
||||
2. Write the report file using that number.
|
||||
3. Release the sentinel by running `node reserve-report-num.mjs --release {###}` once the report is written.
|
||||
|
||||
## Source synchronization
|
||||
|
||||
Before processing any URL, verify sync:
|
||||
```bash
|
||||
node cv-sync-check.mjs
|
||||
```
|
||||
If there is a desynchronization, warn the user before continuing.
|
||||
@@ -0,0 +1,106 @@
|
||||
# career-ops -- Tryby polskie (`modes/pl/`)
|
||||
|
||||
Ten folder zawiera polskie tłumaczenia głównych trybów career-ops dla kandydatów celujących w polski rynek pracy (Polska oraz polskojęzyczne zespoły).
|
||||
|
||||
## Kiedy używać tych trybów?
|
||||
|
||||
Użyj `modes/pl/`, jeśli spełniony jest co najmniej jeden z poniższych warunków:
|
||||
|
||||
- Aplikujesz głównie na **ogłoszenia o pracę po polsku** (Pracuj.pl, No Fluff Jobs, Just Join IT, LinkedIn PL, Bulldogjob, strony karierowe firm)
|
||||
- Twoje **CV jest po polsku** albo przełączasz się między PL i EN w zależności od ogłoszenia
|
||||
- Potrzebujesz odpowiedzi i listów motywacyjnych w **naturalnym, technicznym języku polskim**, a nie tłumaczonym maszynowo
|
||||
- Musisz ogarnąć **specyfikę umów na polskim rynku**: umowa o pracę (UoP), B2B, umowa zlecenie, okres próbny, okres wypowiedzenia, prywatna opieka medyczna, karta sportowa, premia, ZUS, PPK
|
||||
|
||||
Jeśli większość Twoich ogłoszeń jest po angielsku, zostań przy standardowych trybach w `modes/`. Tryby angielskie działają dla ogłoszeń polskojęzycznych, ale nie znają specyfiki polskiego rynku w szczegółach.
|
||||
|
||||
## Jak aktywować?
|
||||
|
||||
### Opcja 1 -- Na sesję
|
||||
|
||||
Powiedz Claude'owi na początku sesji:
|
||||
|
||||
> "Używaj polskich trybów z `modes/pl/`."
|
||||
|
||||
Claude będzie wtedy czytał pliki z tego folderu zamiast z `modes/`.
|
||||
|
||||
### Opcja 2 -- Na stałe
|
||||
|
||||
Dodaj w `config/profile.yml`:
|
||||
|
||||
```yaml
|
||||
language:
|
||||
primary: pl
|
||||
modes_dir: modes/pl
|
||||
```
|
||||
|
||||
Przypomnij o tym Claude'owi podczas pierwszej sesji ("Zajrzyj do `profile.yml`, ustawiłem `language.modes_dir`"). Claude automatycznie użyje polskich trybów.
|
||||
|
||||
## Które tryby są przetłumaczone?
|
||||
|
||||
Ta pierwsza iteracja obejmuje cztery tryby o najwyższym wpływie:
|
||||
|
||||
| Plik | Przetłumaczony z | Rola |
|
||||
|---------|----------------|------|
|
||||
| `_shared.md` | `modes/_shared.md` (EN) | Wspólny kontekst, archetypy, reguły globalne, specyfika polskiego rynku |
|
||||
| `oferta.md` | `modes/oferta.md` (ES) | Pełna ocena oferty (Bloki A-F) |
|
||||
| `aplikuj.md` | `modes/apply.md` (EN) | Asystent na żywo do wypełniania formularzy aplikacyjnych |
|
||||
| `pipeline.md` | `modes/pipeline.md` (ES) | Inbox URL-i / Second Brain dla zebranych ofert |
|
||||
|
||||
Pozostałe tryby (`scan`, `batch`, `pdf`, `tracker`, `auto-pipeline`, `deep`, `contacto`, `ofertas`, `project`, `training`) zostają w EN/ES. Ich treść to głównie tooling, ścieżki i komendy -- musi pozostać niezależna od języka.
|
||||
|
||||
## Co zostaje po angielsku
|
||||
|
||||
Świadomie nieprzetłumaczone, bo to standardowe słownictwo techniczne:
|
||||
|
||||
- `cv.md`, `pipeline`, `tracker`, `report`, `score`, `archetype`, `proof point`
|
||||
- Nazwy narzędzi (`Playwright`, `WebSearch`, `WebFetch`, `Read`, `Write`, `Edit`, `Bash`)
|
||||
- Wartości statusu w trackerze (`Evaluated`, `Applied`, `Interview`, `Offer`, `Rejected`)
|
||||
- Fragmenty kodu, ścieżki, komendy
|
||||
|
||||
Tryby używają naturalnego, technicznego języka polskiego, takiego, jakim mówi się w zespołach engineeringowych w Warszawie, Krakowie czy Wrocławiu: tekst po polsku, terminy techniczne po angielsku tam, gdzie tak się ich używa. Bez wymuszonego tłumaczenia "Pipeline" na "Potok" ani "Deploy" na "Wdrożenie aplikacyjne".
|
||||
|
||||
## Słownik referencyjny
|
||||
|
||||
Aby zachować spójny ton, jeśli modyfikujesz lub rozszerzasz tryby:
|
||||
|
||||
| Angielski | Polski (w tej codebase) |
|
||||
|---------|-------------------------------|
|
||||
| Job posting | Oferta pracy / Ogłoszenie |
|
||||
| Application | Aplikacja / Kandydatura |
|
||||
| Cover letter | List motywacyjny |
|
||||
| Resume / CV | CV |
|
||||
| Salary | Wynagrodzenie / Pensja |
|
||||
| Compensation | Wynagrodzenie / Pakiet |
|
||||
| Skills | Umiejętności / Kompetencje |
|
||||
| Interview | Rozmowa kwalifikacyjna |
|
||||
| Hiring manager | Manager rekrutujący / Hiring manager |
|
||||
| Recruiter | Rekruter (lub Recruiter) |
|
||||
| AI | AI / SI (Sztuczna Inteligencja) |
|
||||
| Requirements | Wymagania |
|
||||
| Career history | Doświadczenie zawodowe / Przebieg kariery |
|
||||
| Notice period | Okres wypowiedzenia |
|
||||
| Probation | Okres próbny |
|
||||
| Vacation | Urlop wypoczynkowy |
|
||||
| 13th month salary | 13. pensja / Trzynastka |
|
||||
| Permanent employment | Umowa o pracę na czas nieokreślony (UoP) |
|
||||
| Fixed-term contract | Umowa o pracę na czas określony |
|
||||
| Freelance | Freelance / B2B / Samozatrudnienie |
|
||||
| Mandate contract | Umowa zlecenie |
|
||||
| Specific-task contract | Umowa o dzieło |
|
||||
| Profit sharing | Udział w zyskach / Premia |
|
||||
| Health insurance | Prywatna opieka medyczna |
|
||||
| Sports card | Karta sportowa (Multisport / Medicover Sport) |
|
||||
| Social security | ZUS (Zakład Ubezpieczeń Społecznych) |
|
||||
| Employee pension scheme | PPK (Pracownicze Plany Kapitałowe) |
|
||||
| Net / Gross | Netto / Brutto |
|
||||
| Day rate (B2B) | Stawka dzienna |
|
||||
|
||||
## Wkład (Contribute)
|
||||
|
||||
Aby ulepszyć tłumaczenie lub dodać tryb:
|
||||
|
||||
1. Otwórz Issue z propozycją (zobacz `CONTRIBUTING.md`)
|
||||
2. Trzymaj się powyższego słownika, aby zachować spójny ton
|
||||
3. Tłumacz idiomatycznie -- bez tłumaczenia słowo w słowo
|
||||
4. Zachowaj elementy strukturalne (Bloki A-F, tabele, bloki kodu, instrukcje narzędzi) identycznie
|
||||
5. Przetestuj na prawdziwej polskiej ofercie (Pracuj.pl, No Fluff Jobs, Just Join IT) przed wysłaniem PR-a
|
||||
@@ -0,0 +1,204 @@
|
||||
# Wspólny kontekst -- career-ops (Polski)
|
||||
|
||||
<!-- ============================================================
|
||||
PERSONALIZACJA TEGO PLIKU
|
||||
============================================================
|
||||
Ten plik zawiera wspólny kontekst dla wszystkich trybów
|
||||
career-ops w wersji polskiej. Zanim użyjesz career-ops, MUSISZ:
|
||||
1. Wypełnić config/profile.yml swoimi danymi osobowymi
|
||||
2. Utworzyć cv.md w katalogu głównym projektu (CV w Markdown)
|
||||
3. (Opcjonalnie) Utworzyć article-digest.md ze swoimi proof points
|
||||
4. Dostosować sekcje oznaczone [PERSONALIZUJ] poniżej
|
||||
============================================================ -->
|
||||
|
||||
## Źródła prawdy (ZAWSZE czytaj przed każdą oceną)
|
||||
|
||||
| Plik | Ścieżka | Kiedy |
|
||||
|---------|--------|-------|
|
||||
| cv.md | `cv.md` (katalog główny projektu) | ZAWSZE |
|
||||
| article-digest.md | `article-digest.md` (jeśli istnieje) | ZAWSZE (szczegółowe proof points) |
|
||||
| profile.yml | `config/profile.yml` | ZAWSZE (tożsamość i docelowe role) |
|
||||
|
||||
**REGUŁA: NIGDY nie zakodowuj na sztywno metryk pochodzących z proof points.** Czytaj je z `cv.md` i `article-digest.md` w momencie oceny.
|
||||
**REGUŁA: Dla metryk z artykułów/projektów `article-digest.md` ma priorytet nad `cv.md`** (`cv.md` może zawierać starsze liczby).
|
||||
|
||||
---
|
||||
|
||||
## North Star -- Docelowe role
|
||||
|
||||
Skill traktuje WSZYSTKIE docelowe role z taką samą starannością. Żadna nie jest podstawowa ani drugorzędna -- każda jest sukcesem, jeśli wynagrodzenie i perspektywy rozwoju są na właściwym poziomie:
|
||||
|
||||
| Archetyp | Osie tematyczne | Co kupuje firma |
|
||||
|-----------|------------------|----------------------------|
|
||||
| **AI Platform / LLMOps Engineer** | Evaluation, Observability, Niezawodność, Pipelines | Kogoś, kto wdraża AI na produkcję z metrykami |
|
||||
| **Agentic Workflows / Automation** | HITL, Tooling, Orkiestracja, Multi-Agent | Kogoś, kto buduje niezawodne systemy agentowe |
|
||||
| **Technical AI Product Manager** | GenAI/Agents, PRD-y, Discovery, Delivery | Kogoś, kto przekłada biznes na produkty AI |
|
||||
| **AI Solutions Architect** | Hyperautomation, Enterprise, Integracje | Kogoś, kto projektuje architektury AI end-to-end |
|
||||
| **AI Forward Deployed Engineer** | Client-facing, szybkie dostarczanie, Prototypowanie | Kogoś, kto szybko wdraża rozwiązania AI u klienta |
|
||||
| **AI Transformation Lead** | Zarządzanie zmianą, Adopcja, Enablement | Kogoś, kto prowadzi transformację AI w organizacjach |
|
||||
|
||||
<!-- [PERSONALIZUJ] Dostosuj powyższe archetypy do swoich docelowych ról.
|
||||
Przykład dla backend engineering:
|
||||
- Senior Backend Engineer
|
||||
- Staff Platform Engineer
|
||||
- Engineering Manager
|
||||
itd. -->
|
||||
|
||||
### Adaptacyjne framing według archetypu
|
||||
|
||||
> **Konkretne metryki: czytaj je z `cv.md` i `article-digest.md` w momencie oceny. NIGDY nie zakodowuj ich na sztywno tutaj.**
|
||||
|
||||
| Jeśli rola to... | Podkreśl u kandydata... | Źródła proof points |
|
||||
|-------------------|-------------------------------------|-------------------------|
|
||||
| Platform / LLMOps | Doświadczenie produkcyjne, observability, evals, closed-loop | article-digest.md + cv.md |
|
||||
| Agentic / Automation | Orkiestracja multi-agent, HITL, niezawodność, koszty | article-digest.md + cv.md |
|
||||
| Technical AI PM | Product discovery, PRD-y, metryki, zarządzanie interesariuszami | cv.md + article-digest.md |
|
||||
| Solutions Architect | Projektowanie systemów, integracje, gotowość enterprise | article-digest.md + cv.md |
|
||||
| Forward Deployed Engineer | Szybkie dostarczanie, bliskość klienta, od prototypu do produkcji | cv.md + article-digest.md |
|
||||
| AI Transformation Lead | Zarządzanie zmianą, enablement zespołu, adopcja | cv.md + article-digest.md |
|
||||
|
||||
<!-- [PERSONALIZUJ] Powiąż swoje konkretne projekty/artykuły z powyższymi archetypami -->
|
||||
|
||||
### Narracja przejścia (do użycia we WSZYSTKICH framingach)
|
||||
|
||||
<!-- [PERSONALIZUJ] Zastąp własną narracją. Przykłady:
|
||||
- "SaaS zbudowany i sprzedany po 5 latach. Teraz 100% fokus na stosowanej AI w enterprise."
|
||||
- "Engineering lead w spółce Series-B podczas wzrostu x10. W poszukiwaniu kolejnego wyzwania."
|
||||
- "Przejście z konsultingu do produktu. Szukam ról z dużą odpowiedzialnością."
|
||||
Czytane z config/profile.yml -> narrative.exit_story -->
|
||||
|
||||
Używaj narracji przejścia z `config/profile.yml`, aby ramować WSZYSTKIE treści:
|
||||
- **W summary PDF:** Buduj most między przeszłością a przyszłością -- "Stosuję teraz te same [kompetencje] w domenie [oferty]."
|
||||
- **W historiach STAR:** Odwołuj się do proof points z `article-digest.md`.
|
||||
- **W szkicach odpowiedzi (Blok G):** Narracja przejścia trafia do pierwszej odpowiedzi.
|
||||
- **Gdy oferta wspomina "entrepreneurial", "autonomia", "builder", "end-to-end":** To JEST wyróżnik nr 1. Zwiększ wagę dopasowania.
|
||||
|
||||
### Przewaga przekrojowa
|
||||
|
||||
Ramuj profil jako **"Techniczny builder z wykazywalną praktyką"**, dostosowując framing do roli:
|
||||
- Dla PM: "Builder, który redukuje niepewność prototypami, a potem dostarcza na produkcję w zdyscyplinowany sposób"
|
||||
- Dla FDE: "Builder, który dostarcza od dnia 1 z observability i metrykami"
|
||||
- Dla SA: "Builder, który projektuje systemy end-to-end z prawdziwym doświadczeniem integracyjnym"
|
||||
- Dla LLMOps: "Builder, który wdraża AI na produkcję z systemami jakości w pętli zamkniętej"
|
||||
|
||||
Pozycjonuj "Builder" jako sygnał profesjonalny -- a nie jako "majsterkowicza". Prawdziwe proof points czynią to wiarygodnym.
|
||||
|
||||
### Portfolio jako proof point (używaj w aplikacjach o wysokiej stawce)
|
||||
|
||||
<!-- [PERSONALIZUJ] Jeśli masz demo na żywo, dashboard lub publiczny projekt, skonfiguruj go tutaj.
|
||||
Przykład:
|
||||
dashboard:
|
||||
url: "https://twojadomena.dev/demo"
|
||||
password: "demo-2026"
|
||||
when_to_share: "Role LLMOps, AI Platform, Observability"
|
||||
Czytane z config/profile.yml -> narrative.proof_points i narrative.dashboard -->
|
||||
|
||||
Jeśli kandydat ma demo na żywo / dashboard (sprawdź `profile.yml`), zaproponuj dostęp w odpowiednich aplikacjach.
|
||||
|
||||
### Wywiad wynagrodzeniowy (Comp Intelligence)
|
||||
|
||||
<!-- [PERSONALIZUJ] Zbadaj widełki wynagrodzeń dla swoich docelowych ról i dostosuj wartości -->
|
||||
|
||||
**Ogólne wskazówki:**
|
||||
- WebSearch dla aktualnych danych rynkowych (Glassdoor, Levels.fyi, No Fluff Jobs, Just Join IT, Raport Płacowy Pracuj.pl, justjoin.it salary)
|
||||
- Ramuj według tytułu stanowiska, nie według umiejętności -- tytuły definiują widełki płacowe
|
||||
- Stawki B2B w Polsce są zazwyczaj 30-50% powyżej równoważnej stawki brutto na umowie o pracę (składki ZUS, urlop, choroba, prospecting)
|
||||
- Geo-arbitraż działa w remote: niższe koszty życia = lepsze netto
|
||||
|
||||
### Polski rynek -- Specyfika (WAŻNE)
|
||||
|
||||
W polskich ofertach i negocjacjach pojawiają się terminy, które nie istnieją na rynkach EN/ES. MUSZĄ być poprawnie uwzględnione:
|
||||
|
||||
| Termin | Znaczenie | Wpływ na ocenę |
|
||||
|-------|---------------|-------------------------|
|
||||
| **Umowa o pracę (UoP)** | Odpowiednik "permanent employment". Standard z pełną ochroną Kodeksu pracy | Standard oczekiwany. Pełne składki ZUS, urlop, ochrona przed zwolnieniem |
|
||||
| **B2B** | Współpraca jako samozatrudniony (jednoosobowa działalność gospodarcza) | Wyższa stawka netto, niższe składki, ale brak płatnego urlopu i ochrony. Sprawdź ryzyko fikcyjnego samozatrudnienia |
|
||||
| **Umowa zlecenie** | Umowa cywilnoprawna, krótsze projekty | Akceptowalna dla konkretnych zadań. Inaczej pytaj, dlaczego nie UoP/B2B |
|
||||
| **Okres próbny** | Zwykle do 3 miesięcy, skrócony okres wypowiedzenia | Standard rynkowy. Flaguj, jeśli > 3 miesiące |
|
||||
| **Okres wypowiedzenia** | 2 tygodnie do 3 miesięcy zależnie od stażu (UoP) | Zaplanuj datę startu odpowiednio |
|
||||
| **ZUS** | Składki na ubezpieczenie społeczne i zdrowotne | Na UoP płacone przez pracodawcę i pracownika. Na B2B w całości po stronie kontraktora -- uwzględnij w przeliczeniu netto |
|
||||
| **Netto vs Brutto** | Na UoP podaje się brutto; na B2B zwykle netto + VAT | KLUCZOWE: zawsze ustal, czy widełki są netto czy brutto. Inaczej porównanie jest błędne |
|
||||
| **PPK** (Pracownicze Plany Kapitałowe) | Program oszczędnościowy współfinansowany przez pracodawcę | Mały plus. Dopłata pracodawcy ~1,5% wynagrodzenia |
|
||||
| **Trzynastka / 13. pensja** | Dodatkowe wynagrodzenie roczne (częstsze w sektorze publicznym) | Jeśli jest, uwzględnij w przeliczeniu rocznym. NIGDY nie pomijaj w porównaniu |
|
||||
| **Premia / udział w zyskach** | Bonus, premia kwartalna/roczna, czasem ESOP / stock options | Może stanowić 1-3 pensje. Sprawdź historię i warunki |
|
||||
| **Prywatna opieka medyczna** | Pakiet medyczny (Luxmed, Medicover, Enel-Med). Częsty benefit | Standard w IT. Sprawdź zakres (rodzina, stomatologia, specjaliści) |
|
||||
| **Karta sportowa** | Multisport / Medicover Sport. Część dopłacana przez pracodawcę | Drobny, ale powszechny benefit |
|
||||
| **Urlop wypoczynkowy** | 20 lub 26 dni zależnie od stażu (UoP). B2B zwykle bez płatnego urlopu | < 20 dni na UoP = niezgodne z Kodeksem pracy. 26 dni = standard. B2B: wlicz brak urlopu w stawkę |
|
||||
| **Praca zdalna / hybrydowa** | Coraz częstszy standard w polskim IT | Sprawdź liczbę dni w biurze i czy "remote-first" |
|
||||
| **VAT (na B2B)** | Kontraktor zwykle wystawia fakturę + 23% VAT | Sprawdź, czy stawka jest "netto + VAT", czy "brutto" -- różnica jest istotna |
|
||||
|
||||
### Skrypty negocjacyjne
|
||||
|
||||
<!-- [PERSONALIZUJ] Dostosuj do swojej sytuacji -->
|
||||
|
||||
**Oczekiwania płacowe (ogólny framework):**
|
||||
> "Na podstawie aktualnych danych rynkowych dla tego typu stanowiska celuję w widełki [WIDEŁKI z profile.yml]. Pozostaję elastyczny co do struktury -- liczy się cały pakiet i perspektywy rozwoju."
|
||||
|
||||
**Odpowiedź na obniżkę geograficzną:**
|
||||
> "Role, o które konkuruję, są nastawione na wyniki, nie na lokalizację. Mój track record nie zmienia się wraz z kodem pocztowym."
|
||||
|
||||
**Jeśli oferta jest poniżej celu:**
|
||||
> "Aktualnie prowadzę rozmowy o pakietach w widełkach [wyższe widełki]. [Firma] przyciąga mnie [powodem]. Czy da się osiągnąć [cel]?"
|
||||
|
||||
**Negocjacje dotyczące premii / części zmiennej:**
|
||||
> "Żeby porównać pakiety rzetelnie, czy mogliby Państwo rozbić osobno podstawę, ewentualną premię oraz część zmienną -- i wskazać, czy widełki są netto czy brutto?"
|
||||
|
||||
### Polityka lokalizacji (Location Policy)
|
||||
|
||||
<!-- [PERSONALIZUJ] Dostosuj do swojej sytuacji. Czytane z config/profile.yml -> location -->
|
||||
|
||||
**W formularzach:**
|
||||
- Pytania binarne "Czy może Pan/Pani być na miejscu?": odpowiadaj zgodnie z rzeczywistą dostępnością w `profile.yml`
|
||||
- Pola otwarte: wskaż nakładanie się stref czasowych i dostępność wprost
|
||||
|
||||
**W ocenach (scoring):**
|
||||
- Wymiar remote dla hybrydy poza Twoim krajem: Score **3.0** (nie 1.0)
|
||||
- Score 1.0 tylko, jeśli oferta wprost mówi "obecność obowiązkowa 4-5 dni/tydzień, bez wyjątków"
|
||||
|
||||
### Priorytet time-to-offer
|
||||
- Działające demo + metryki > perfekcja
|
||||
- Aplikować szybko > uczyć się więcej
|
||||
- Podejście 80/20, wszystko w timeboxie
|
||||
|
||||
---
|
||||
|
||||
## Reguły globalne
|
||||
|
||||
### NIGDY
|
||||
|
||||
1. Nie wymyślaj doświadczenia ani metryk
|
||||
2. Nie modyfikuj `cv.md` ani plików portfolio
|
||||
3. Nie wysyłaj aplikacji w imieniu kandydata
|
||||
4. Nie udostępniaj numeru telefonu w generowanych wiadomościach
|
||||
5. Nie rekomenduj wynagrodzenia poniżej rynku
|
||||
6. Nie generuj PDF bez wcześniejszego przeczytania oferty
|
||||
7. Nie używaj korporacyjnego żargonu ani pustych formułek
|
||||
8. Nie ignoruj trackera (każda oceniona oferta jest zapisywana)
|
||||
|
||||
### ZAWSZE
|
||||
|
||||
0. **List motywacyjny:** Jeśli formularz na to pozwala, ZAWSZE dołącz jeden. PDF w tym samym projekcie wizualnym co CV. Cytaty z oferty zmapowane na proof points. Maks. 1 strona.
|
||||
1. Czytaj `cv.md` i `article-digest.md` (jeśli istnieje) przed oceną oferty
|
||||
1b. **Pierwsza ocena każdej sesji:** Uruchom `node cv-sync-check.mjs` przez Bash. W razie ostrzeżeń poinformuj kandydata
|
||||
2. Wykryj archetyp roli i dostosuj framing
|
||||
3. Cytuj dokładne wiersze z CV podczas matchingu
|
||||
4. Używaj WebSearch do danych o wynagrodzeniach i firmie
|
||||
5. Zapisuj w trackerze po każdej ocenie
|
||||
6. Generuj treść w języku oferty (polski, jeśli oferta jest po polsku; angielski w przeciwnym razie)
|
||||
7. Bądź bezpośredni i konkretny -- bez gadania
|
||||
8. Naturalny, techniczny język polski dla generowanych tekstów. Krótkie zdania, czasowniki czynności, unikaj strony biernej. Nie tłumacz na siłę terminów technicznych (stack, pipeline, deployment, embedding)
|
||||
8b. **URL-e case studies w Professional Summary PDF-a:** Jeśli PDF wspomina case studies lub dema, URL-e MUSZĄ pojawić się w pierwszym akapicie (Professional Summary). Rekruterzy często czytają tylko summary. Wszystkie URL-e w HTML z `white-space: nowrap`
|
||||
9. **Wpisy do trackera w TSV** -- NIGDY nie edytuj applications.md bezpośrednio dla nowych dodań. Zapisz TSV do `batch/tracker-additions/`, `merge-tracker.mjs` zarządza scalaniem
|
||||
10. **`**URL:**` w każdym nagłówku reportu** -- między Score a PDF
|
||||
|
||||
### Narzędzia
|
||||
|
||||
| Narzędzie | Użycie |
|
||||
|-------|---------|
|
||||
| WebSearch | Wyszukiwanie wynagrodzeń, trendów, kultury firmy, kontaktów LinkedIn, fallback dla ofert |
|
||||
| WebFetch | Fallback do ekstrakcji ofert ze stron statycznych |
|
||||
| Playwright | Sprawdzenie, czy oferty są aktywne (browser_navigate + browser_snapshot), ekstrakcja ofert ze SPA. **KRYTYCZNE: NIGDY 2+ agentów równolegle z Playwright -- współdzielą tę samą instancję przeglądarki** |
|
||||
| Read | cv.md, article-digest.md, cv-template.html |
|
||||
| Write | Tymczasowy HTML dla PDF, applications.md, reporty .md |
|
||||
| Edit | Aktualizacja trackera |
|
||||
| Bash | `node generate-pdf.mjs` |
|
||||
@@ -0,0 +1,114 @@
|
||||
# Tryb: aplikuj -- Asystent na żywo do formularzy aplikacyjnych
|
||||
|
||||
Tryb interaktywny na moment, gdy kandydat wypełnia formularz aplikacyjny w Chrome. Czyta to, co jest na ekranie, ładuje kontekst poprzedniej oceny oferty i generuje spersonalizowane odpowiedzi na każde pytanie formularza.
|
||||
|
||||
## Wymagania wstępne
|
||||
|
||||
- **Idealnie z widocznym Playwright**: W trybie widocznym kandydat widzi przeglądarkę, a Claude może wchodzić w interakcję ze stroną.
|
||||
- **Bez Playwright**: kandydat udostępnia zrzut ekranu lub wkleja pytania ręcznie.
|
||||
|
||||
## Workflow
|
||||
|
||||
```
|
||||
1. WYKRYJ -> Przeczytaj aktywną kartę Chrome (zrzut/URL/tytuł)
|
||||
2. ZIDENTYFIKUJ -> Wyciągnij firmę + rolę ze strony
|
||||
3. WYSZUKAJ -> Dopasuj do istniejących reportów w reports/
|
||||
4. ZAŁADUJ -> Przeczytaj pełny report + Blok G (jeśli istnieje)
|
||||
5. PORÓWNAJ -> Czy rola na ekranie odpowiada ocenionej? Jeśli zmiana -> ostrzeż
|
||||
6. PRZEANALIZUJ -> Zidentyfikuj WSZYSTKIE widoczne pytania formularza
|
||||
7. WYGENERUJ -> Dla każdego pytania wygeneruj spersonalizowaną odpowiedź
|
||||
8. ZAPREZENTUJ -> Wyświetl odpowiedzi sformatowane do skopiowania
|
||||
```
|
||||
|
||||
## Krok 1 -- Wykryj ofertę
|
||||
|
||||
**Z Playwright:** Snapshot aktywnej strony. Przeczytaj tytuł, URL i widoczną treść.
|
||||
|
||||
**Bez Playwright:** Poproś kandydata, aby:
|
||||
- Udostępnił zrzut ekranu formularza (narzędzie Read czyta obrazy)
|
||||
- Lub wkleił pytania formularza jako tekst
|
||||
- Lub podał firmę + rolę, abyśmy mogli wyszukać kontekst
|
||||
|
||||
## Krok 2 -- Zidentyfikuj i załaduj kontekst
|
||||
|
||||
1. Wyciągnij nazwę firmy i tytuł stanowiska ze strony
|
||||
2. Wyszukaj w `reports/` po nazwie firmy (Grep case-insensitive)
|
||||
3. Jeśli dopasowanie -> załaduj pełny report
|
||||
4. Jeśli Blok G obecny -> załaduj poprzednie szkice odpowiedzi jako bazę
|
||||
5. Jeśli BRAK dopasowania -> ostrzeż kandydata i zaproponuj szybki auto-pipeline
|
||||
|
||||
## Krok 3 -- Wykryj zmiany roli
|
||||
|
||||
Jeśli rola na ekranie różni się od ocenionej:
|
||||
- **Ostrzeż kandydata**: "Rola zmieniła się z [X] na [Y]. Czy chcesz, żebym ocenił ją ponownie, czy dostosował odpowiedzi do nowego tytułu?"
|
||||
- **Jeśli dostosować**: Dostosuj odpowiedzi do nowej roli bez ponownej oceny
|
||||
- **Jeśli ocenić ponownie**: Uruchom pełną ocenę A-F, zaktualizuj report, wygeneruj ponownie Blok G
|
||||
- **Zaktualizuj tracker**: Zmień tytuł roli w applications.md, jeśli to konieczne
|
||||
|
||||
## Krok 4 -- Przeanalizuj pytania formularza
|
||||
|
||||
Zidentyfikuj WSZYSTKIE widoczne pytania:
|
||||
- Pola tekstu otwartego (list motywacyjny, "dlaczego to stanowisko", motywacja itp.)
|
||||
- Listy rozwijane (skąd dowiedziałeś się o firmie, pozwolenie na pracę itp.)
|
||||
- Tak/Nie (mobilność, wiza, dostępność itp.)
|
||||
- Pola wynagrodzenia (widełki, oczekiwania płacowe -- ustal, czy netto czy brutto)
|
||||
- Pola upload (CV, list motywacyjny PDF, referencje)
|
||||
|
||||
Sklasyfikuj każde pytanie:
|
||||
- **Już odpowiedziane w Bloku G** -> wykorzystaj istniejącą odpowiedź
|
||||
- **Nowe pytanie** -> wygeneruj odpowiedź z reportu + `cv.md`
|
||||
|
||||
## Krok 5 -- Wygeneruj odpowiedzi
|
||||
|
||||
Dla każdego pytania zbuduj odpowiedź według tego schematu:
|
||||
|
||||
1. **Kontekst z reportu**: Użyj proof points z bloku B, historii STAR z bloku F
|
||||
2. **Poprzedni Blok G**: Jeśli szkic istnieje, weź go jako bazę i dopracuj
|
||||
3. **Ton "To ja wybieram Was"**: ten sam framework co w auto-pipeline -- pewny siebie, nie błagalny
|
||||
4. **Konkretność**: zacytuj coś konkretnego z oferty widocznej na ekranie
|
||||
5. **career-ops proof point**: dołącz w "Informacje dodatkowe", jeśli takie pole istnieje
|
||||
|
||||
**Pola specyficzne dla typowych polskich formularzy:**
|
||||
- **Oczekiwania płacowe** -> Widełki z `profile.yml`, w PLN, z zaznaczeniem, czy netto czy brutto (oraz UoP/B2B) i dopiskiem "do negocjacji w zależności od całego pakietu"
|
||||
- **Data dostępności** -> Realistyczna data uwzględniająca okres wypowiedzenia (często 2 tygodnie do 3 miesięcy)
|
||||
- **Pozwolenie na pracę / Obywatelstwo** -> Uczciwie i zwięźle; dla obywateli UE: "Brak wymogu zezwolenia na pracę (obywatel UE)"
|
||||
- **Języki** -> Poziomy według ESOKJ/CEFR (A1-C2)
|
||||
- **Mobilność** -> Sprecyzuj akceptowalny obszar geograficzny i częstotliwość wyjazdów
|
||||
|
||||
**Format wyjścia:**
|
||||
|
||||
```
|
||||
## Odpowiedzi dla [Firma] -- [Rola]
|
||||
|
||||
Baza: Report #NNN | Score: X.X/5 | Archetyp: [typ]
|
||||
|
||||
---
|
||||
|
||||
### 1. [Dokładne pytanie z formularza]
|
||||
> [Odpowiedź gotowa do skopiowania]
|
||||
|
||||
### 2. [Następne pytanie]
|
||||
> [Odpowiedź]
|
||||
|
||||
...
|
||||
|
||||
---
|
||||
|
||||
Notatki:
|
||||
- [Obserwacje dotyczące roli, zmiany itp.]
|
||||
- [Sugestie personalizacji, które kandydat powinien zweryfikować]
|
||||
```
|
||||
|
||||
## Krok 6 -- Po aplikacji (opcjonalnie)
|
||||
|
||||
Jeśli kandydat potwierdzi, że aplikacja została wysłana:
|
||||
1. Zaktualizuj status w `applications.md` z "Evaluated" na "Applied"
|
||||
2. Zaktualizuj Blok G reportu finalnymi odpowiedziami
|
||||
3. Zasugeruj następny krok: `/career-ops contacto` dla LinkedIn outreach do hiring managera
|
||||
|
||||
## Obsługa przewijania
|
||||
|
||||
Jeśli formularz ma więcej pytań niż widać:
|
||||
- Poproś kandydata, aby przewinął i udostępnił kolejny zrzut ekranu
|
||||
- Lub wkleił pozostałe pytania
|
||||
- Przetwarzaj iteracyjnie, aż pokryjesz cały formularz
|
||||
@@ -0,0 +1,166 @@
|
||||
# Tryb: oferta -- Pełna ocena A-F
|
||||
|
||||
Gdy kandydat wkleja ofertę (tekst lub URL), ZAWSZE dostarcz wszystkie 6 bloków.
|
||||
|
||||
## Krok 0 -- Wykrycie archetypu
|
||||
|
||||
Sklasyfikuj ofertę do jednego z 6 archetypów (zobacz `_shared.md`). Jeśli hybrydowa, wskaż 2 najbliższe. To determinuje:
|
||||
- Które proof points priorytetyzować w bloku B
|
||||
- Jak przepisać summary w bloku E
|
||||
- Które historie STAR przygotować w bloku F
|
||||
|
||||
## Blok A -- Podsumowanie roli
|
||||
|
||||
Tabela z:
|
||||
- Wykrytym archetypem
|
||||
- Domeną (Platform / Agentic / LLMOps / ML / Enterprise)
|
||||
- Funkcją (Build / Doradztwo / Zarządzanie / Deploy)
|
||||
- Poziomem seniority
|
||||
- Remote (Full remote / Hybryda / Na miejscu)
|
||||
- Wielkością zespołu (jeśli podana)
|
||||
- TL;DR w 1 zdaniu
|
||||
|
||||
## Blok B -- Dopasowanie do CV
|
||||
|
||||
Przeczytaj `cv.md`. Stwórz tabelę, w której każde wymaganie z oferty jest zmapowane na dokładne wiersze z CV.
|
||||
|
||||
**Dostosowane do archetypu:**
|
||||
- FDE -> priorytetyzuj proof points szybkiego dostarczania i bliskości klienta
|
||||
- SA -> priorytetyzuj projektowanie systemów i integracje
|
||||
- PM -> priorytetyzuj product discovery i metryki
|
||||
- LLMOps -> priorytetyzuj evals, observability, pipelines
|
||||
- Agentic -> priorytetyzuj multi-agent, HITL, orkiestrację
|
||||
- Transformation -> priorytetyzuj zarządzanie zmianą, adopcję, skalowanie
|
||||
|
||||
Sekcja **Luki (Gaps)** ze strategią mitygacji dla każdej. Dla każdej luki:
|
||||
1. Czy to twardy bloker czy nice-to-have?
|
||||
2. Czy kandydat może wykazać sąsiednie doświadczenie?
|
||||
3. Czy istnieje projekt portfolio, który pokrywa tę lukę?
|
||||
4. Konkretny plan mitygacji (zdanie do listu motywacyjnego, szybki mini-projekt itp.)
|
||||
|
||||
## Blok C -- Poziom i strategia
|
||||
|
||||
1. **Wykryty poziom** w ofercie vs **naturalny poziom kandydata dla tego archetypu**
|
||||
2. **Plan "sprzedać senior bez kłamstwa"**: konkretne sformułowania dostosowane do archetypu, konkretne osiągnięcia do podkreślenia, jak pozycjonować doświadczenie założycielskie jako atut
|
||||
3. **Plan "jeśli dostanę downlevel"**: zaakceptować, jeśli wynagrodzenie jest sprawiedliwe, wynegocjować przegląd po 6 miesiącach, jasne kryteria awansu
|
||||
|
||||
## Blok D -- Wynagrodzenie i popyt
|
||||
|
||||
Użyj WebSearch dla:
|
||||
- Aktualnych wynagrodzeń dla roli (Glassdoor, Levels.fyi, No Fluff Jobs, Just Join IT, Raport Płacowy Pracuj.pl)
|
||||
- Reputacji wynagrodzeniowej firmy (Glassdoor, GoWork)
|
||||
- Trendu popytu na rolę na polskim rynku
|
||||
|
||||
Tabela z danymi i cytowanymi źródłami. Jeśli brak danych, powiedz to jasno -- nic nie wymyślaj.
|
||||
|
||||
**Polski rynek -- Obowiązkowe weryfikacje:**
|
||||
- Czy widełki są netto czy brutto? Ustal to zawsze -- to fundament porównania.
|
||||
- Umowa o pracę (UoP) czy B2B? Jeśli B2B: stawka dzienna/miesięczna, ryzyko fikcyjnego samozatrudnienia, kwestia VAT.
|
||||
- Część zmienna (premia, prowizja, ESOP / stock options)?
|
||||
- Trzynastka / premia roczna wspomniana? Uwzględnij w przeliczeniu rocznym.
|
||||
- ZUS i PPK -- po czyjej stronie składki (zwłaszcza przy B2B)?
|
||||
- Benefity (prywatna opieka medyczna, karta sportowa) wspomniane? Wlicz w wartość pakietu.
|
||||
|
||||
## Blok E -- Plan personalizacji
|
||||
|
||||
| # | Sekcja | Stan obecny | Proponowana zmiana | Uzasadnienie |
|
||||
|---|---------|-------------|--------------------|----- ---------|
|
||||
| 1 | Summary | ... | ... | ... |
|
||||
| ... | ... | ... | ... | ... |
|
||||
|
||||
Top 5 zmian w CV + Top 5 zmian na LinkedIn, aby zmaksymalizować dopasowanie.
|
||||
|
||||
## Blok F -- Plan rozmów kwalifikacyjnych
|
||||
|
||||
6-10 historii STAR+R zmapowanych na wymagania oferty (STAR + **Reflection**):
|
||||
|
||||
| # | Wymaganie z oferty | Historia STAR+R | S | T | A | R | Reflection |
|
||||
|---|---------------------|--------------|---|---|---|---|------------|
|
||||
|
||||
Kolumna **Reflection** ujmuje, czego się nauczono lub co zrobiono by inaczej. To sygnalizuje seniority -- juniorzy opisują, co się wydarzyło, seniorzy wyciągają z tego wnioski.
|
||||
|
||||
**Story Bank:** Jeśli `interview-prep/story-bank.md` istnieje, sprawdź, czy te historie już tam są. Jeśli nie, dodaj nowe. Z czasem buduje to wielokrotnego użytku bank 5-10 historii master, które można dopasować do każdego pytania na rozmowie.
|
||||
|
||||
**Wyselekcjonowane i sformowane według archetypu:**
|
||||
- FDE -> podkreśl szybkość dostarczania i bliskość klienta
|
||||
- SA -> podkreśl decyzje architektoniczne
|
||||
- PM -> podkreśl discovery i kompromisy
|
||||
- LLMOps -> podkreśl metryki, evals, hardening na produkcji
|
||||
- Agentic -> podkreśl orkiestrację, obsługę błędów, HITL
|
||||
- Transformation -> podkreśl adopcję i zmianę organizacyjną
|
||||
|
||||
Dołącz także:
|
||||
- 1 rekomendowane case study (który projekt zaprezentować i jak)
|
||||
- Pytania red-flag i jak na nie odpowiadać (np. "Dlaczego sprzedał Pan swoją firmę?", "Czy miał Pan zespół pod sobą?", "Dlaczego zmiana po tak krótkim czasie?")
|
||||
|
||||
---
|
||||
|
||||
## Po ocenie
|
||||
|
||||
**ZAWSZE** wykonaj po blokach A-F:
|
||||
|
||||
### 1. Zapisz report .md
|
||||
|
||||
Zapisz pełną ocenę w `reports/{###}-{company-slug}-{YYYY-MM-DD}.md`.
|
||||
|
||||
- `{###}` = następny kolejny numer (3 cyfry, dopełnione zerami). Aby przydzielić go atomowo i uniknąć race conditions, musisz uruchomić `node reserve-report-num.mjs`, by zarezerwować numer (stdout zwraca `{###}`), zapisać report, a następnie uruchomić `node reserve-report-num.mjs --release {###}`, by zwolnić sentinel.
|
||||
- `{company-slug}` = nazwa firmy małymi literami, bez spacji (użyj myślników)
|
||||
- `{YYYY-MM-DD}` = dzisiejsza data
|
||||
|
||||
**Format reportu:**
|
||||
|
||||
```markdown
|
||||
# Ocena: {Firma} -- {Rola}
|
||||
|
||||
**Data:** {YYYY-MM-DD}
|
||||
**Archetyp:** {wykryty}
|
||||
**Score:** {X/5}
|
||||
**URL:** {URL oferty}
|
||||
**PDF:** {ścieżka lub w toku}
|
||||
|
||||
---
|
||||
|
||||
## A) Podsumowanie roli
|
||||
(pełna zawartość bloku A)
|
||||
|
||||
## B) Dopasowanie do CV
|
||||
(pełna zawartość bloku B)
|
||||
|
||||
## C) Poziom i strategia
|
||||
(pełna zawartość bloku C)
|
||||
|
||||
## D) Wynagrodzenie i popyt
|
||||
(pełna zawartość bloku D)
|
||||
|
||||
## E) Plan personalizacji
|
||||
(pełna zawartość bloku E)
|
||||
|
||||
## F) Plan rozmów kwalifikacyjnych
|
||||
(pełna zawartość bloku F)
|
||||
|
||||
## G) Szkice odpowiedzi do aplikacji
|
||||
(tylko jeśli score >= 4.5 -- szkice odpowiedzi do formularza aplikacyjnego)
|
||||
|
||||
---
|
||||
|
||||
## Wyekstrahowane słowa kluczowe
|
||||
(lista 15-20 słów kluczowych z oferty do optymalizacji ATS)
|
||||
```
|
||||
|
||||
### 2. Zapisz w trackerze
|
||||
|
||||
**ZAWSZE** zapisz w `data/applications.md`:
|
||||
- Następny kolejny numer
|
||||
- Dzisiejsza data
|
||||
- Firma
|
||||
- Rola
|
||||
- Score: średnia dopasowania (1-5)
|
||||
- Status: `Evaluated`
|
||||
- PDF: nie (lub tak, jeśli auto-pipeline wygenerował PDF)
|
||||
- Report: względny link do pliku reportu (np. `[001](reports/001-company-2026-01-01.md)`)
|
||||
|
||||
**Format trackera:**
|
||||
|
||||
```markdown
|
||||
| # | Data | Firma | Rola | Score | Status | PDF | Report |
|
||||
```
|
||||
@@ -0,0 +1,63 @@
|
||||
# Tryb: pipeline -- Inbox URL-i (Second Brain)
|
||||
|
||||
Przetwarza URL-e ofert nagromadzone w `data/pipeline.md`. Kandydat dodaje URL-e, kiedy chce, a potem uruchamia `/career-ops pipeline`, by przetworzyć je wszystkie naraz.
|
||||
|
||||
## Workflow
|
||||
|
||||
1. **Przeczytaj** `data/pipeline.md` -> znajdź itemy `- [ ]` w sekcji "Oczekujące" / "Pending" / "Pendientes"
|
||||
2. **Dla każdego oczekującego URL-a**:
|
||||
a. Zarezerwuj następny kolejny `REPORT_NUM` atomowo, uruchamiając `node reserve-report-num.mjs` (i zwolnij sentinel, uruchamiając `node reserve-report-num.mjs --release <num>`, gdy report zostanie zapisany)
|
||||
b. **Wyciągnij ofertę** za pomocą Playwright (`browser_navigate` + `browser_snapshot`) -> WebFetch -> WebSearch
|
||||
c. Jeśli URL jest niedostępny -> oznacz jako `- [!]` z notatką i kontynuuj
|
||||
d. **Wykonaj pełny auto-pipeline**: Ocena A-F -> Report .md -> PDF (jeśli score >= 3.0) -> Tracker
|
||||
e. **Przenieś z "Oczekujące" do "Przetworzone"**: `- [x] #NNN | URL | Firma | Rola | Score/5 | PDF tak/nie`
|
||||
3. **Jeśli 3+ oczekujących URL-i**, uruchom agentów równolegle (Agent tool z `run_in_background`), aby zmaksymalizować szybkość.
|
||||
4. **Na końcu** wyświetl tabelę podsumowującą:
|
||||
|
||||
```
|
||||
| # | Firma | Rola | Score | PDF | Rekomendowana akcja |
|
||||
```
|
||||
|
||||
## Format pipeline.md
|
||||
|
||||
```markdown
|
||||
## Oczekujące
|
||||
- [ ] https://jobs.example.com/posting/123
|
||||
- [ ] https://boards.greenhouse.io/company/jobs/456 | Company Sp. z o.o. | Senior PM
|
||||
- [!] https://private.url/job -- Błąd: wymagane logowanie
|
||||
|
||||
## Przetworzone
|
||||
- [x] #143 | https://jobs.example.com/posting/789 | Acme Sp. z o.o. | AI PM | 4.2/5 | PDF tak
|
||||
- [x] #144 | https://boards.greenhouse.io/xyz/jobs/012 | BigCo | SA | 2.1/5 | PDF nie
|
||||
```
|
||||
|
||||
> Uwaga: Nagłówki sekcji mogą być w EN ("Pending"/"Processed"), ES ("Pendientes"/"Procesadas"), DE ("Offen"/"Verarbeitet") lub PL ("Oczekujące"/"Przetworzone"). Bądź elastyczny przy czytaniu, wierny istniejącemu stylowi przy pisaniu.
|
||||
|
||||
## Inteligentne wykrywanie oferty z URL-a
|
||||
|
||||
1. **Playwright (preferowane):** `browser_navigate` + `browser_snapshot`. Działa ze wszystkimi SPA.
|
||||
2. **WebFetch (fallback):** Dla stron statycznych lub gdy Playwright jest niedostępny.
|
||||
3. **WebSearch (ostateczność):** Szukaj na portalach drugorzędnych, które indeksują ofertę.
|
||||
|
||||
**Przypadki szczególne:**
|
||||
- **LinkedIn**: Może wymagać logowania -> oznacz `[!]` i poproś kandydata o wklejenie tekstu
|
||||
- **PDF**: Jeśli URL wskazuje na PDF, przeczytaj go bezpośrednio narzędziem Read
|
||||
- **Prefiks `local:`**: Przeczytaj plik lokalny. Przykład: `local:jds/linkedin-pm-ai.md` -> przeczytaj `jds/linkedin-pm-ai.md`
|
||||
- **Pracuj.pl / No Fluff Jobs / Just Join IT**: Popularne polskie portale. Playwright dobrze radzi sobie z bannerami cookie
|
||||
- **Bulldogjob / LinkedIn PL**: Oferty ustrukturyzowane, dobrze czytelne maszynowo. WebFetch zwykle wystarcza
|
||||
|
||||
## Automatyczna numeracja
|
||||
|
||||
1. Uruchom `node reserve-report-num.mjs`, aby zarezerwować następny kolejny numer atomowo (stdout zwraca `{###}`).
|
||||
2. Zapisz report z tym numerem.
|
||||
3. Zwolnij sentinel, uruchamiając `node reserve-report-num.mjs --release {###}`, gdy report zostanie zapisany.
|
||||
|
||||
## Synchronizacja źródeł
|
||||
|
||||
Przed przetworzeniem URL-a sprawdź synchronizację:
|
||||
|
||||
```bash
|
||||
node cv-sync-check.mjs
|
||||
```
|
||||
|
||||
W razie desynchronizacji ostrzeż kandydata przed kontynuowaniem.
|
||||
@@ -0,0 +1,33 @@
|
||||
# Mode: project — Portfolio Project Evaluation
|
||||
|
||||
**URL:** {project-url}
|
||||
**Legitimacy:** {High Confidence | Proceed with Caution | Suspicious}
|
||||
|
||||
Scoring matrix with 6 dimensions (1–5):
|
||||
|
||||
| Dimension | Weight | 5 = ... | 1 = ... |
|
||||
|-----------|------|---------|---------|
|
||||
| Signal for target roles | 25% | Directly demonstrates JD skill | Not related |
|
||||
| Uniqueness | 20% | Nobody has done this | Very common |
|
||||
| Demo ability | 20% | Live demo in 2 min | Code only, not visual |
|
||||
| Metrics potential | 15% | Clear metrics (latency, cost, accuracy) | No metrics possible |
|
||||
| Time to MVP | 10% | 1 week | 3+ months |
|
||||
| STAR story potential | 10% | Rich story with trade-offs | Implementation only |
|
||||
|
||||
## "Interview Pack" Requirements
|
||||
|
||||
For each approved project:
|
||||
1. **One-pager**: product + architecture + metrics + evaluation plan
|
||||
2. **Demo**: live URL or 2 min recorded walkthrough
|
||||
3. **Postmortem**: what worked, what didn’t, mitigations
|
||||
|
||||
## 80/20 Plan
|
||||
|
||||
- Week 1 → MVP with core metric
|
||||
- Week 2 → polish + interview pack
|
||||
|
||||
## Verdicts
|
||||
|
||||
- **BUILD** → plan with weekly milestones
|
||||
- **SKIP** → why and what to do instead
|
||||
- **PIVOT TO [alternative]** → more impactful variant
|
||||
@@ -0,0 +1,111 @@
|
||||
# career-ops -- Modos em Português BR (`modes/pt/`)
|
||||
|
||||
Esta pasta contém as traduções em português brasileiro dos principais modos do career-ops para candidatos que buscam vagas no mercado brasileiro ou em empresas que operam em português.
|
||||
|
||||
## Quando usar estes modos?
|
||||
|
||||
Use `modes/pt/` se pelo menos uma das condições abaixo for verdadeira:
|
||||
|
||||
- Você se candidata principalmente a **vagas em português** (Gupy, Greenhouse BR, LinkedIn BR, Vagas.com.br, Catho, InfoJobs)
|
||||
- Sua **língua do currículo** é português ou você alterna entre PT-BR e EN conforme a vaga
|
||||
- Você precisa de respostas e cartas de apresentação em **português tech natural**, não traduzido por máquina
|
||||
- Você precisa lidar com **especificidades do mercado brasileiro**: CLT vs PJ, 13º salário, FGTS, PLR, vale-refeição, plano de saúde, aviso prévio, período de experiência
|
||||
|
||||
Se a maioria das suas vagas é em inglês, fique com os modos padrão em `modes/`. Os modos em inglês funcionam automaticamente quando Claude detecta uma vaga em português — mas não conhecem as particularidades do mercado brasileiro no mesmo nível de detalhe.
|
||||
|
||||
## Como ativar?
|
||||
|
||||
O career-ops não tem um "switch de idioma" como flag de código. Em vez disso, existem dois caminhos:
|
||||
|
||||
### Caminho 1 -- Por sessão, via comando
|
||||
|
||||
Diga ao Claude no início da sessão:
|
||||
|
||||
> "Use os modos em português de `modes/pt/`."
|
||||
|
||||
ou
|
||||
|
||||
> "Avaliar e candidaturas em português -- use `modes/pt/_shared.md` e `modes/pt/oferta.md`."
|
||||
|
||||
Claude vai ler os arquivos desta pasta em vez de `modes/`.
|
||||
|
||||
### Caminho 2 -- Permanente, via perfil
|
||||
|
||||
Adicione em `config/profile.yml` uma preferência de idioma:
|
||||
|
||||
```yaml
|
||||
language:
|
||||
primary: pt-br
|
||||
modes_dir: modes/pt
|
||||
```
|
||||
|
||||
Lembre o Claude na primeira sessão de respeitar esse campo ("Olha no `profile.yml`, eu configurei `language.modes_dir`"). A partir daí, Claude usa automaticamente os modos em português.
|
||||
|
||||
> Nota: O campo `language.modes_dir` é uma convenção, não um schema rígido. Se os mantenedores quiserem estruturar diferente, o campo pode ser renomeado a qualquer momento.
|
||||
|
||||
## O que foi traduzido?
|
||||
|
||||
Esta primeira iteração cobre os quatro modos com maior impacto:
|
||||
|
||||
| Arquivo | Traduzido de | Finalidade |
|
||||
|---------|-------------|------------|
|
||||
| `_shared.md` | `modes/_shared.md` (EN) | Contexto compartilhado, arquétipos, regras globais, especificidades do mercado BR |
|
||||
| `oferta.md` | `modes/oferta.md` (ES) | Avaliação completa de uma vaga (Blocos A-F) |
|
||||
| `aplicar.md` | `modes/apply.md` (EN) | Assistente ao vivo para formulários de candidatura |
|
||||
| `pipeline.md` | `modes/pipeline.md` (ES) | Inbox de URLs / Second Brain para vagas acumuladas |
|
||||
|
||||
Os demais modos (`scan`, `batch`, `pdf`, `tracker`, `auto-pipeline`, `deep`, `contacto`, `ofertas`, `project`, `training`) não estão neste PR de propósito. Eles continuam funcionando via os originais em EN/ES, pois seu conteúdo é majoritariamente tooling, caminhos e comandos de configuração — que devem ser independentes de idioma.
|
||||
|
||||
Se a comunidade adotar os modos em português, mais modos serão traduzidos em PRs futuros.
|
||||
|
||||
## O que continua em inglês?
|
||||
|
||||
Propositalmente não traduzido, porque é vocabulário padrão de tech:
|
||||
|
||||
- `cv.md`, `pipeline`, `tracker`, `report`, `score`, `archetype`, `proof point`
|
||||
- Nomes de tools (`Playwright`, `WebSearch`, `WebFetch`, `Read`, `Write`, `Edit`, `Bash`)
|
||||
- Valores de status no tracker (`Evaluated`, `Applied`, `Interview`, `Offer`, `Rejected`)
|
||||
- Code snippets, caminhos de arquivo, comandos
|
||||
|
||||
Os modos usam português tech brasileiro, como se fala em times de engenharia reais em São Paulo, Florianópolis ou Belo Horizonte: texto corrido em português, termos técnicos em inglês onde são de uso comum. Nada de traduzir "pipeline" para "tubulação" ou "cv.md" para "curriculo.md".
|
||||
|
||||
## Vocabulário de Referência
|
||||
|
||||
Se você for adaptar ou expandir os modos, siga este vocabulário para manter a consistência de tom:
|
||||
|
||||
| Inglês | Português BR (nesta codebase) |
|
||||
|--------|-------------------------------|
|
||||
| Job posting | Vaga / Descrição da vaga |
|
||||
| Application | Candidatura |
|
||||
| Cover letter | Carta de apresentação |
|
||||
| Resume / CV | Currículo |
|
||||
| Salary | Salário / Remuneração |
|
||||
| Compensation | Remuneração |
|
||||
| Skills | Habilidades / Competências |
|
||||
| Interview | Entrevista |
|
||||
| Hiring manager | Gestor da vaga / Hiring manager |
|
||||
| Recruiter | Recrutador(a) |
|
||||
| AI | IA (Inteligência Artificial) |
|
||||
| Requirements | Requisitos |
|
||||
| Career history | Trajetória profissional / Experiência |
|
||||
| Notice period | Aviso prévio |
|
||||
| Probation | Período de experiência |
|
||||
| Vacation | Férias |
|
||||
| 13th month salary | 13º salário |
|
||||
| Formal employment (CLT) | CLT / Carteira assinada |
|
||||
| Contractor (PJ) | PJ (Pessoa Jurídica) |
|
||||
| Profit sharing | PLR (Participação nos Lucros e Resultados) |
|
||||
| Health insurance | Plano de saúde |
|
||||
| Meal voucher | Vale-refeição / Vale-alimentação |
|
||||
| Severance fund | FGTS (Fundo de Garantia) |
|
||||
| Stock options | Stock options (termo já usado em PT-BR) |
|
||||
|
||||
## Contribuir
|
||||
|
||||
Se quiser melhorar uma tradução ou traduzir um modo adicional:
|
||||
|
||||
1. Abra uma issue com a proposta (conforme `CONTRIBUTING.md`)
|
||||
2. Siga o vocabulário acima para manter o tom consistente
|
||||
3. Traduza de forma natural e idiomática — nada de tradução literal palavra por palavra
|
||||
4. Mantenha os elementos estruturais (Bloco A-F, tabelas, blocos de código, instruções de tools) exatamente iguais
|
||||
5. Teste com uma vaga real brasileira (ex: do Gupy ou LinkedIn BR) antes de abrir o PR
|
||||
@@ -0,0 +1,218 @@
|
||||
# Contexto Compartilhado -- career-ops (Português BR)
|
||||
|
||||
<!-- ============================================================
|
||||
THIS FILE IS AUTO-UPDATABLE. Don't put personal data here.
|
||||
|
||||
Your customizations go in modes/_profile.md (never auto-updated).
|
||||
This file contains system rules, scoring logic, and tool config
|
||||
that improve with each career-ops release.
|
||||
============================================================ -->
|
||||
|
||||
## Fontes da Verdade (SEMPRE ler antes de cada avaliação)
|
||||
|
||||
| Arquivo | Caminho | Quando |
|
||||
|---------|---------|--------|
|
||||
| cv.md | `cv.md` (raiz do projeto) | SEMPRE |
|
||||
| article-digest.md | `article-digest.md` (se existir) | SEMPRE (proof points detalhados) |
|
||||
| profile.yml | `config/profile.yml` | SEMPRE (identidade e vagas-alvo) |
|
||||
| _profile.md | `modes/_profile.md` | SEMPRE (arquétipos, narrativa, negociação do usuário) |
|
||||
|
||||
**REGRA: NUNCA fazer hardcode de métricas de proof points.** Leia-as de `cv.md` e `article-digest.md` no momento da avaliação.
|
||||
**REGRA: Para métricas de artigos/projetos, `article-digest.md` tem prioridade sobre `cv.md`** (`cv.md` pode conter números desatualizados).
|
||||
**REGRA: Leia `_profile.md` DEPOIS deste arquivo. As personalizações do usuário em `_profile.md` sobrescrevem os valores padrão aqui.**
|
||||
|
||||
---
|
||||
|
||||
## Sistema de Pontuação
|
||||
|
||||
A avaliação usa 6 blocos (A-F) com uma nota global de 1-5:
|
||||
|
||||
| Dimensão | O que mede |
|
||||
|----------|------------|
|
||||
| Match com CV | Habilidades, experiência, alinhamento de proof points |
|
||||
| Alinhamento North Star | Quão bem a vaga encaixa nos arquétipos-alvo do usuário (de `_profile.md`) |
|
||||
| Remuneração | Salário vs mercado (5=quartil superior, 1=bem abaixo) |
|
||||
| Sinais culturais | Cultura da empresa, crescimento, estabilidade, política de trabalho remoto |
|
||||
| Red flags | Bloqueadores, alertas (ajustes negativos) |
|
||||
| **Global** | Média ponderada dos itens acima |
|
||||
|
||||
**Interpretação da nota:**
|
||||
- 4.5+ → Match forte, recomendado aplicar imediatamente
|
||||
- 4.0-4.4 → Bom match, vale a pena aplicar
|
||||
- 3.5-3.9 → Razoável mas não ideal, aplicar apenas se houver motivo específico
|
||||
- Abaixo de 3.5 → Recomendado não aplicar (veja Ethical Use no AGENTS.md)
|
||||
|
||||
## North Star -- Vagas-Alvo
|
||||
|
||||
O skill trata TODAS as vagas-alvo com o mesmo cuidado. Nenhuma é primária ou secundária — qualquer uma é uma vitória, desde que a remuneração e a perspectiva de crescimento estejam adequadas:
|
||||
|
||||
| Arquétipo | Eixos temáticos | O que estão comprando |
|
||||
|-----------|-----------------|----------------------|
|
||||
| **AI Platform / LLMOps Engineer** | Avaliação, Observability, Confiabilidade, Pipelines | Alguém que coloca IA em produção com métricas |
|
||||
| **Agentic Workflows / Automation** | HITL, Tooling, Orquestração, Multi-Agent | Alguém que constrói sistemas de agentes confiáveis |
|
||||
| **Technical AI Product Manager** | GenAI/Agents, PRDs, Discovery, Delivery | Alguém que traduz negócios em produtos de IA |
|
||||
| **AI Solutions Architect** | Hiperautomação, Enterprise, Integrações | Alguém que projeta arquiteturas de IA de ponta a ponta |
|
||||
| **AI Forward Deployed Engineer** | Cliente-próximo, entrega rápida, Prototipagem | Alguém que implanta soluções de IA rapidamente no cliente |
|
||||
| **AI Transformation Lead** | Gestão de mudança, Adoção, Enablement organizacional | Alguém que lidera transformação de IA em organizações |
|
||||
|
||||
<!-- [PERSONALIZAR] Adapte os arquétipos acima para suas vagas-alvo.
|
||||
Exemplo para engenharia backend:
|
||||
- Senior Backend Engineer
|
||||
- Staff Platform Engineer
|
||||
- Engineering Manager
|
||||
etc. -->
|
||||
|
||||
### Framing Adaptativo por Arquétipo
|
||||
|
||||
> **Métricas concretas: ler de `cv.md` e `article-digest.md` no momento da avaliação. NUNCA fazer hardcode aqui.**
|
||||
|
||||
| Se a vaga é... | Enfatizar no candidato... | Fontes de Proof Points |
|
||||
|----------------|--------------------------|------------------------|
|
||||
| Platform / LLMOps | Experiência em produção, Observability, Evals, Closed-Loop | article-digest.md + cv.md |
|
||||
| Agentic / Automation | Orquestração multi-agent, HITL, Confiabilidade, Custos | article-digest.md + cv.md |
|
||||
| Technical AI PM | Product Discovery, PRDs, Métricas, Gestão de stakeholders | cv.md + article-digest.md |
|
||||
| Solutions Architect | Design de sistemas, Integrações, Enterprise-ready | article-digest.md + cv.md |
|
||||
| Forward Deployed Engineer | Entrega rápida, próximo do cliente, Protótipo a produção | cv.md + article-digest.md |
|
||||
| AI Transformation Lead | Gestão de mudança, Enablement de equipe, Adoção | cv.md + article-digest.md |
|
||||
|
||||
<!-- [PERSONALIZAR] Mapeie seus projetos/artigos concretos para os arquétipos acima -->
|
||||
|
||||
### Narrativa de Transição (usar em TODOS os framings)
|
||||
|
||||
<!-- [PERSONALIZAR] Substitua pela sua própria narrativa. Exemplos:
|
||||
- "Construí e vendi minha própria SaaS em 5 anos. Agora foco total em IA aplicada no Enterprise."
|
||||
- "Lead de engenharia em uma Series-B durante crescimento 10x. Buscando o próximo desafio."
|
||||
- "Transição de consultoria para produto. Buscando vagas com alta responsabilidade."
|
||||
Lido de config/profile.yml -> narrative.exit_story -->
|
||||
|
||||
Use a narrativa de transição de `config/profile.yml` para enquadrar TODO o conteúdo:
|
||||
- **Em PDF Summaries:** Construir a ponte do passado para o futuro — "Aplico as mesmas [habilidades] agora em [domínio do JD]."
|
||||
- **Em histórias STAR:** Referenciar proof points de `article-digest.md`.
|
||||
- **Em respostas rascunho (Bloco G):** A narrativa de transição vai na primeira resposta.
|
||||
- **Quando a vaga menciona "empreendedor", "ownership", "builder", "end-to-end":** Esse é o diferencial número 1. Aumentar peso de match.
|
||||
|
||||
### Vantagem Transversal
|
||||
|
||||
Enquadrar o perfil como **"Builder técnico com prática comprovada"**, adaptando o framing à vaga:
|
||||
- Para PM: "Builder que reduz incerteza com protótipos e depois leva à produção com disciplina"
|
||||
- Para FDE: "Builder que entrega desde o dia 1 com observability e métricas"
|
||||
- Para SA: "Builder que projeta sistemas end-to-end com experiência real de integração"
|
||||
- Para LLMOps: "Builder que coloca IA em produção com sistemas de qualidade closed-loop"
|
||||
|
||||
Posicionar "Builder" como sinal profissional — não como "hobbyista". Proof points reais tornam isso crível.
|
||||
|
||||
### Portfolio como Proof Point (usar em candidaturas de alto valor)
|
||||
|
||||
<!-- [PERSONALIZAR] Se você tem uma demo ao vivo, dashboard ou projeto público, configure aqui.
|
||||
Exemplo:
|
||||
dashboard:
|
||||
url: "https://seudominio.dev/demo"
|
||||
password: "demo-2026"
|
||||
when_to_share: "LLMOps, AI-Platform, vagas de Observability"
|
||||
Lido de config/profile.yml -> narrative.proof_points e narrative.dashboard -->
|
||||
|
||||
Quando o candidato tem uma demo ao vivo / dashboard (verificar `profile.yml`), oferecer acesso em candidaturas relevantes.
|
||||
|
||||
### Inteligência de Remuneração (Comp Intelligence)
|
||||
|
||||
<!-- [PERSONALIZAR] Pesquise faixas salariais para suas vagas-alvo e ajuste os valores -->
|
||||
|
||||
**Orientações gerais:**
|
||||
- WebSearch para dados atuais de mercado (Glassdoor, Levels.fyi, Blind)
|
||||
- Enquadrar por título da vaga, não por skills — títulos definem as faixas salariais
|
||||
- Taxas de freelance geralmente ficam 30-60% acima da hora bruta de CLT (encargos, férias, FGTS, INSS, contador)
|
||||
- Geo-arbitragem funciona em vagas remotas: custo de vida menor = melhor líquido
|
||||
|
||||
### Mercado Brasileiro -- Especificidades (IMPORTANTE)
|
||||
|
||||
Em vagas e negociações brasileiras, existem termos e práticas que não aparecem nos mercados EN/ES/DE. Eles DEVEM ser avaliados corretamente:
|
||||
|
||||
| Termo | Significado | Impacto na Avaliação |
|
||||
|-------|-------------|----------------------|
|
||||
| **CLT** (Consolidação das Leis do Trabalho) | Contrato formal com carteira assinada | Inclui FGTS, INSS, férias, 13º, aviso prévio. Na comparação, considerar o custo total empregador |
|
||||
| **PJ** (Pessoa Jurídica) | Contratação como prestador de serviços (nota fiscal) | Valor mensal mais alto, mas sem benefícios CLT. Calcular equivalente CLT para comparação justa |
|
||||
| **13º Salário** | Pagamento extra obrigatório para CLT | Comp CLT = salário x 13 (ou 13,33 com 1/3 de férias). NUNCA esquecer na comparação |
|
||||
| **FGTS** (Fundo de Garantia) | 8% do salário depositado pelo empregador | Benefício CLT, não aparece no contra-cheque mas é remuneração real |
|
||||
| **Vale-Refeição / Vale-Alimentação** | Benefício alimentação (iFood, Sodexo, Alelo) | Comum em vagas CLT, pode chegar a R$ 1.500+/mês. Incluir na comp total |
|
||||
| **PLR** (Participação nos Lucros e Resultados) | Bônus atrelado a resultados da empresa | Pode ser 1-3 salários extras/ano. Variável — ponderar com cautela |
|
||||
| **Stock Options / VSOP** | Equity em startups | Comum em startups brasileiras. Avaliar vesting, cliff e liquidez |
|
||||
| **Período de Experiência** | 45+45 dias (CLT) ou conforme contrato (PJ) | Padrão de mercado, não é red flag |
|
||||
| **Aviso Prévio** | 30 dias (CLT) + 3 dias por ano trabalhado | Planejar data de início conforme vínculo atual |
|
||||
| **Plano de Saúde** | Benefício médico (Amil, SulAmérica, Bradesco Saúde) | Muito valorizado no Brasil. Sem plano = red flag em vagas CLT |
|
||||
| **Cooperativa / MEI** | Formas alternativas de contratação | Avaliar com cautela — pode indicar precarização trabalhista |
|
||||
|
||||
### Scripts de Negociação
|
||||
|
||||
<!-- [PERSONALIZAR] Adapte para sua situação -->
|
||||
|
||||
**Pretensão salarial (framework geral):**
|
||||
> "Com base em dados atuais de mercado para essa vaga, minha expectativa está na faixa de [FAIXA do profile.yml]. Tenho flexibilidade na estrutura — o que importa é o pacote total e a perspectiva de crescimento."
|
||||
|
||||
**Pushback contra desconto geográfico:**
|
||||
> "As vagas em que estou concorrendo são orientadas a resultados, não a localização. Meu track record não muda com o CEP."
|
||||
|
||||
**Quando a oferta está abaixo do alvo:**
|
||||
> "Estou comparando com ofertas na faixa de [faixa mais alta]. [Empresa] me atrai por [motivo]. É possível chegarmos em [valor-alvo] juntos?"
|
||||
|
||||
**CLT vs PJ:**
|
||||
> "Para comparar de forma justa, preciso entender a composição completa: salário-base, 13º, férias, FGTS, vale-refeição, plano de saúde e PLR. Se for PJ, qual o valor mensal equivalente considerando esses itens?"
|
||||
|
||||
### Política de Localização (Location Policy)
|
||||
|
||||
<!-- [PERSONALIZAR] Adapte para sua situação. Lido de config/profile.yml -> location -->
|
||||
|
||||
**Em formulários:**
|
||||
- Perguntas binárias "Você pode trabalhar presencialmente?": responder conforme disponibilidade real de `profile.yml`
|
||||
- Em campos de texto livre: informar fuso horário e disponibilidade explicitamente
|
||||
|
||||
**Em avaliações (Scoring):**
|
||||
- Dimensão remoto em híbrido fora do seu estado/país: Score **3.0** (não 1.0)
|
||||
- Score 1.0 apenas se a vaga diz explicitamente "deve estar presencial 4-5 dias/semana, sem exceções"
|
||||
|
||||
### Prioridade Time-to-Offer
|
||||
- Demo funcional + métricas > perfeição
|
||||
- Aplicar mais rápido > aprender mais
|
||||
- Abordagem 80/20, tudo com prazo definido
|
||||
|
||||
---
|
||||
|
||||
## Regras Globais
|
||||
|
||||
### NUNCA
|
||||
|
||||
1. Inventar experiência ou métricas
|
||||
2. Modificar `cv.md` ou arquivos do portfolio
|
||||
3. Enviar candidaturas em nome do candidato
|
||||
4. Compartilhar número de telefone em mensagens geradas
|
||||
5. Recomendar remuneração abaixo do mercado
|
||||
6. Gerar PDF sem ter lido a descrição da vaga antes
|
||||
7. Usar jargão corporativo ou "corporates"
|
||||
8. Ignorar o tracker (toda vaga avaliada é registrada)
|
||||
|
||||
### SEMPRE
|
||||
|
||||
0. **Carta de apresentação:** Se o formulário permite anexar ou escrever uma carta, SEMPRE inclua uma. PDF no mesmo design visual do currículo. Conteúdo: citações da descrição da vaga mapeadas para proof points, links para case studies relevantes. Máximo 1 página.
|
||||
1. Ler `cv.md`, `_profile.md` e `article-digest.md` (se existir) antes de avaliar qualquer vaga
|
||||
1b. **Na primeira avaliação de cada sessão:** Executar `node cv-sync-check.mjs` via Bash. Se houver avisos, informar o candidato antes de continuar
|
||||
2. Detectar o arquétipo da vaga e adaptar o framing conforme `_profile.md`
|
||||
3. Ao fazer matching, citar linhas exatas do currículo
|
||||
4. Usar WebSearch para dados de remuneração e empresa
|
||||
5. Registrar no tracker após cada avaliação
|
||||
6. Gerar conteúdo na língua da descrição da vaga (PT-BR padrão)
|
||||
7. Ser direto e prático — sem enrolação
|
||||
8. Ao gerar texto em português (PDF summaries, bullets, mensagens LinkedIn, histórias STAR): português tech natural, não tradução literal. Frases curtas, verbos de ação, evitar voz passiva. Termos técnicos (stack, pipeline, deployment, embedding) não precisam ser traduzidos
|
||||
8b. **URLs de case studies no PDF Professional Summary:** Se o PDF menciona case studies ou demos, as URLs DEVEM aparecer já no primeiro parágrafo (Professional Summary). Recrutadores frequentemente só leem o resumo. Todos os URLs no HTML com `white-space: nowrap`
|
||||
9. **Entradas no tracker como TSV** — NUNCA editar `applications.md` diretamente para novos registros. Escrever TSV em `batch/tracker-additions/`, `merge-tracker.mjs` cuida do merge
|
||||
10. **Incluir `**URL:**` em todo header de report** — entre Score e PDF
|
||||
|
||||
### Tools
|
||||
|
||||
| Tool | Uso |
|
||||
|------|-----|
|
||||
| WebSearch | Pesquisa de remuneração, tendências, cultura da empresa, contatos LinkedIn, fallback para descrições de vagas |
|
||||
| WebFetch | Fallback para extrair descrições de vagas de páginas estáticas |
|
||||
| Playwright | Verificar se vagas ainda estão ativas (browser_navigate + browser_snapshot), extrair descrições de SPAs. **CRÍTICO: NUNCA iniciar 2+ agentes com Playwright em paralelo — eles compartilham a mesma instância do navegador** |
|
||||
| Read | cv.md, _profile.md, article-digest.md, cv-template.html |
|
||||
| Write | HTML temporário para PDF, reports .md, TSV em `batch/tracker-additions/` |
|
||||
| Edit | Ajustes de conteúdo (não usar para criar novos registros no tracker) |
|
||||
| Bash | `node generate-pdf.mjs`, `node merge-tracker.mjs` |
|
||||
@@ -0,0 +1,114 @@
|
||||
# Modo: aplicar -- Assistente de Candidatura ao Vivo
|
||||
|
||||
Modo interativo para quando o candidato está preenchendo um formulário de candidatura no Chrome. Lê o que está na tela, carrega o contexto da avaliação prévia da vaga e gera respostas personalizadas para cada pergunta do formulário.
|
||||
|
||||
## Requisitos
|
||||
|
||||
- **Melhor com Playwright visível**: No modo visível, o candidato vê o navegador e Claude pode interagir com a página.
|
||||
- **Sem Playwright**: o candidato compartilha um screenshot ou cola as perguntas manualmente.
|
||||
|
||||
## Workflow
|
||||
|
||||
```
|
||||
1. DETECTAR → Ler aba ativa do Chrome (screenshot/URL/título)
|
||||
2. IDENTIFICAR → Extrair empresa + vaga da página
|
||||
3. BUSCAR → Match contra reports existentes em reports/
|
||||
4. CARREGAR → Ler report completo + Bloco G (se existir)
|
||||
5. COMPARAR → A vaga na tela coincide com a avaliada? Se mudou → avisar
|
||||
6. ANALISAR → Identificar TODAS as perguntas visíveis do formulário
|
||||
7. GERAR → Para cada pergunta, gerar resposta personalizada
|
||||
8. APRESENTAR → Mostrar respostas formatadas para copy-paste
|
||||
```
|
||||
|
||||
## Passo 1 -- Detectar a vaga
|
||||
|
||||
**Com Playwright:** Tirar snapshot da página ativa. Ler título, URL e conteúdo visível.
|
||||
|
||||
**Sem Playwright:** Pedir ao candidato que:
|
||||
- Compartilhe um screenshot do formulário (o Read tool lê imagens)
|
||||
- Ou cole as perguntas do formulário como texto
|
||||
- Ou diga empresa + vaga para buscarmos o contexto
|
||||
|
||||
## Passo 2 -- Identificar e buscar contexto
|
||||
|
||||
1. Extrair nome da empresa e título da vaga da página
|
||||
2. Buscar em `reports/` pelo nome da empresa (Grep case-insensitive)
|
||||
3. Se houver match → carregar o report completo
|
||||
4. Se houver Bloco G → carregar os rascunhos de respostas anteriores como base
|
||||
5. Se NÃO houver match → avisar e oferecer executar auto-pipeline rápida
|
||||
|
||||
## Passo 3 -- Detectar mudanças na vaga
|
||||
|
||||
Se a vaga na tela difere da avaliada:
|
||||
- **Avisar o candidato**: "A vaga mudou de [X] para [Y]. Quer que eu reavalie ou adapto as respostas ao novo título?"
|
||||
- **Se adaptar**: Ajustar as respostas ao novo título sem reavaliar
|
||||
- **Se reavaliar**: Executar avaliação completa A-F, atualizar report, regenerar Bloco G
|
||||
- **Atualizar tracker**: Alterar título da vaga em `applications.md` se necessário
|
||||
|
||||
## Passo 4 -- Analisar perguntas do formulário
|
||||
|
||||
Identificar TODAS as perguntas visíveis:
|
||||
- Campos de texto livre (carta de apresentação, por que essa vaga, motivação, etc.)
|
||||
- Dropdowns (como ficou sabendo da vaga, autorização de trabalho, etc.)
|
||||
- Sim/Não (mudança de cidade, visto, disponibilidade, etc.)
|
||||
- Campos de salário (faixa, pretensão salarial)
|
||||
- Campos de upload (currículo, carta de apresentação em PDF)
|
||||
|
||||
Classificar cada pergunta:
|
||||
- **Já respondida no Bloco G** → adaptar a resposta existente
|
||||
- **Pergunta nova** → gerar resposta a partir do report + `cv.md`
|
||||
|
||||
## Passo 5 -- Gerar respostas
|
||||
|
||||
Para cada pergunta, gerar a resposta seguindo:
|
||||
|
||||
1. **Contexto do report**: Usar proof points do Bloco B, histórias STAR do Bloco F
|
||||
2. **Bloco G anterior**: Se existe um rascunho, usar como base e refinar
|
||||
3. **Tom "Estou escolhendo vocês"**: Mesmo framework da auto-pipeline — confiante, não suplicante
|
||||
4. **Especificidade**: Referenciar algo concreto do JD visível na tela
|
||||
5. **career-ops proof point**: Incluir em "Informações adicionais" se houver campo para isso
|
||||
|
||||
**Campos específicos do mercado brasileiro que aparecem com frequência:**
|
||||
- **Pretensão salarial (bruto, mensal ou anual)** → Faixa de `profile.yml`, em BRL, com nota "negociável conforme pacote total"
|
||||
- **Regime de contratação preferido (CLT/PJ)** → Responder conforme `profile.yml`, ou "aberto a ambos" se aplicável
|
||||
- **Disponibilidade / prazo para início** → Data realista considerando aviso prévio atual (CLT: 30 dias + 3 dias/ano)
|
||||
- **Autorização de trabalho** → Responder com clareza; se brasileiro: "Cidadão brasileiro, não necessita autorização"
|
||||
- **Idiomas** → Informar nível por idioma (nativo, fluente, intermediário, básico)
|
||||
|
||||
**Formato de output:**
|
||||
|
||||
```
|
||||
## Respostas para [Empresa] -- [Vaga]
|
||||
|
||||
Base: Report #NNN | Score: X.X/5 | Arquétipo: [tipo]
|
||||
|
||||
---
|
||||
|
||||
### 1. [Pergunta exata do formulário]
|
||||
> [Resposta pronta para copy-paste]
|
||||
|
||||
### 2. [Próxima pergunta]
|
||||
> [Resposta]
|
||||
|
||||
...
|
||||
|
||||
---
|
||||
|
||||
Notas:
|
||||
- [Qualquer observação sobre a vaga, mudanças, etc.]
|
||||
- [Sugestões de personalização que o candidato deveria revisar]
|
||||
```
|
||||
|
||||
## Passo 6 -- Pós-candidatura (opcional)
|
||||
|
||||
Se o candidato confirmar que enviou a candidatura:
|
||||
1. Atualizar status em `applications.md` de "Evaluated" para "Applied"
|
||||
2. Atualizar Bloco G do report com as respostas finais
|
||||
3. Sugerir próximo passo: `/career-ops contacto` para LinkedIn outreach
|
||||
|
||||
## Scroll handling
|
||||
|
||||
Se o formulário tem mais perguntas do que as visíveis:
|
||||
- Pedir ao candidato para dar scroll e compartilhar outro screenshot
|
||||
- Ou colar as perguntas restantes
|
||||
- Processar em iterações até cobrir todo o formulário
|
||||
@@ -0,0 +1,166 @@
|
||||
# Modo: oferta -- Avaliação Completa A-F
|
||||
|
||||
Quando o candidato cola uma vaga (texto ou URL), entregar SEMPRE os 6 blocos:
|
||||
|
||||
## Passo 0 -- Detecção de Arquétipo
|
||||
|
||||
Classificar a vaga em um dos 6 arquétipos (ver `_shared.md`). Se for híbrido, indicar os 2 mais próximos. Isso determina:
|
||||
- Quais proof points priorizar no bloco B
|
||||
- Como reescrever o summary no bloco E
|
||||
- Quais histórias STAR preparar no bloco F
|
||||
|
||||
## Bloco A -- Resumo da Vaga
|
||||
|
||||
Tabela com:
|
||||
- Arquétipo detectado
|
||||
- Domain (platform/agentic/LLMOps/ML/enterprise)
|
||||
- Função (build/consult/manage/deploy)
|
||||
- Senioridade
|
||||
- Remoto (full/híbrido/presencial)
|
||||
- Tamanho do time (se mencionado)
|
||||
- TL;DR em 1 frase
|
||||
|
||||
## Bloco B -- Match com o Currículo
|
||||
|
||||
Ler `cv.md`. Criar tabela com cada requisito do JD mapeado para linhas exatas do currículo.
|
||||
|
||||
**Adaptado ao arquétipo:**
|
||||
- Se FDE → priorizar proof points de entrega rápida e proximidade com cliente
|
||||
- Se SA → priorizar design de sistemas e integrações
|
||||
- Se PM → priorizar product discovery e métricas
|
||||
- Se LLMOps → priorizar evals, observability, pipelines
|
||||
- Se Agentic → priorizar multi-agent, HITL, orquestração
|
||||
- Se Transformation → priorizar gestão de mudança, adoção, escalabilidade
|
||||
|
||||
Seção de **gaps** com estratégia de mitigação para cada um. Para cada gap:
|
||||
1. É um hard blocker ou um nice-to-have?
|
||||
2. O candidato consegue demonstrar experiência adjacente?
|
||||
3. Existe um projeto do portfolio que cubra esse gap?
|
||||
4. Plano de mitigação concreto (frase para carta de apresentação, projeto rápido, etc.)
|
||||
|
||||
## Bloco C -- Nível e Estratégia
|
||||
|
||||
1. **Nível detectado** no JD vs **nível natural do candidato para esse arquétipo**
|
||||
2. **Plano "vender senior sem mentir"**: frases específicas adaptadas ao arquétipo, conquistas concretas a destacar, como posicionar experiência de founder como vantagem
|
||||
3. **Plano "se me downlevelearem"**: aceitar se a remuneração for justa, negociar revisão em 6 meses, critérios claros de promoção
|
||||
|
||||
## Bloco D -- Remuneração e Demanda
|
||||
|
||||
Usar WebSearch para:
|
||||
- Salários atuais da vaga (Glassdoor, Levels.fyi, Blind, Glassdoor BR)
|
||||
- Reputação de remuneração da empresa
|
||||
- Tendência de demanda da vaga
|
||||
|
||||
Tabela com dados e fontes citadas. Se não houver dados, dizer isso em vez de inventar.
|
||||
|
||||
**Mercado Brasileiro -- Checks obrigatórios:**
|
||||
- CLT ou PJ? Se CLT: considerar 13º, férias, FGTS, plano de saúde, VR/VA na comparação.
|
||||
- Se PJ: qual o valor mensal? Calcular equivalente CLT.
|
||||
- PLR mencionado? Quantos salários extras?
|
||||
- Stock options / VSOP? Avaliar vesting, cliff e liquidez.
|
||||
- Vale-refeição / vale-alimentação? Valor mensal?
|
||||
- Plano de saúde? Coparticipação ou integral?
|
||||
|
||||
## Bloco E -- Plano de Personalização
|
||||
|
||||
| # | Seção | Estado atual | Mudança proposta | Por que |
|
||||
|---|-------|-------------|------------------|---------|
|
||||
| 1 | Summary | ... | ... | ... |
|
||||
| ... | ... | ... | ... | ... |
|
||||
|
||||
Top 5 mudanças no currículo + Top 5 mudanças no LinkedIn para maximizar o match.
|
||||
|
||||
## Bloco F -- Plano de Entrevistas
|
||||
|
||||
6-10 histórias STAR+R mapeadas para requisitos do JD (STAR + **Reflection**):
|
||||
|
||||
| # | Requisito do JD | História STAR+R | S | T | A | R | Reflection |
|
||||
|---|----------------|-----------------|---|---|---|---|------------|
|
||||
|
||||
A coluna **Reflection** captura o que foi aprendido ou o que seria feito diferente. Isso sinaliza senioridade — candidatos juniores descrevem o que aconteceu, candidatos seniores extraem lições.
|
||||
|
||||
**Story Bank:** Se `interview-prep/story-bank.md` existir, verificar se alguma dessas histórias já está lá. Se não, adicionar as novas. Com o tempo, isso constrói um banco reutilizável de 5-10 histórias-mestre que podem ser adaptadas para qualquer pergunta de entrevista.
|
||||
|
||||
**Selecionadas e enquadradas conforme o arquétipo:**
|
||||
- FDE → enfatizar velocidade de entrega e proximidade com cliente
|
||||
- SA → enfatizar decisões de arquitetura
|
||||
- PM → enfatizar discovery e trade-offs
|
||||
- LLMOps → enfatizar métricas, evals, production hardening
|
||||
- Agentic → enfatizar orquestração, tratamento de erros, HITL
|
||||
- Transformation → enfatizar adoção e mudança organizacional
|
||||
|
||||
Incluir também:
|
||||
- 1 case study recomendado (qual projeto apresentar e como)
|
||||
- Perguntas red-flag e como respondê-las (ex: "Por que você vendeu sua empresa?", "Você tinha reports diretos?")
|
||||
|
||||
---
|
||||
|
||||
## Pós-avaliação
|
||||
|
||||
**SEMPRE** após gerar os blocos A-F:
|
||||
|
||||
### 1. Salvar report .md
|
||||
|
||||
Salvar avaliação completa em `reports/{###}-{company-slug}-{YYYY-MM-DD}.md`.
|
||||
|
||||
- `{###}` = próximo número sequencial (3 dígitos, zero-padded). Para alocar de forma atômica e evitar condições de corrida, você DEVE executar `node reserve-report-num.mjs` para reservar o número (a saída retornará `{###}`), escrever o relatório, e em seguida executar `node reserve-report-num.mjs --release {###}` para liberar o sentinel.
|
||||
- `{company-slug}` = nome da empresa em lowercase, sem espaços (usar hifens)
|
||||
- `{YYYY-MM-DD}` = data atual
|
||||
|
||||
**Formato do report:**
|
||||
|
||||
```markdown
|
||||
# Avaliação: {Empresa} -- {Vaga}
|
||||
|
||||
**Data:** {YYYY-MM-DD}
|
||||
**Arquétipo:** {detectado}
|
||||
**Score:** {X/5}
|
||||
**URL:** {URL da vaga}
|
||||
**PDF:** {caminho ou pendente}
|
||||
|
||||
---
|
||||
|
||||
## A) Resumo da Vaga
|
||||
(conteúdo completo do bloco A)
|
||||
|
||||
## B) Match com o Currículo
|
||||
(conteúdo completo do bloco B)
|
||||
|
||||
## C) Nível e Estratégia
|
||||
(conteúdo completo do bloco C)
|
||||
|
||||
## D) Remuneração e Demanda
|
||||
(conteúdo completo do bloco D)
|
||||
|
||||
## E) Plano de Personalização
|
||||
(conteúdo completo do bloco E)
|
||||
|
||||
## F) Plano de Entrevistas
|
||||
(conteúdo completo do bloco F)
|
||||
|
||||
## G) Rascunhos de Respostas para Candidatura
|
||||
(apenas se score >= 4.5 -- rascunhos de respostas para o formulário de candidatura)
|
||||
|
||||
---
|
||||
|
||||
## Keywords extraídas
|
||||
(lista de 15-20 keywords do JD para otimização ATS)
|
||||
```
|
||||
|
||||
### 2. Registrar no tracker
|
||||
|
||||
**SEMPRE** registrar em `data/applications.md`:
|
||||
- Próximo número sequencial
|
||||
- Data atual
|
||||
- Empresa
|
||||
- Vaga
|
||||
- Score: média do match (1-5)
|
||||
- Status: `Evaluated`
|
||||
- PDF: ❌ (ou ✅ se a auto-pipeline gerou PDF)
|
||||
- Report: link relativo ao report .md (ex: `[001](reports/001-company-2026-01-01.md)`)
|
||||
|
||||
**Formato do tracker:**
|
||||
|
||||
```markdown
|
||||
| # | Data | Empresa | Vaga | Score | Status | PDF | Report |
|
||||
```
|
||||
@@ -0,0 +1,65 @@
|
||||
# Modo: pipeline -- Inbox de URLs (Second Brain)
|
||||
|
||||
Processa URLs de vagas acumuladas em `data/pipeline.md`. O candidato adiciona URLs quando quiser e depois executa `/career-ops pipeline` para processar todas de uma vez.
|
||||
|
||||
## Workflow
|
||||
|
||||
1. **Ler** `data/pipeline.md` → buscar itens `- [ ]` na seção "Pendentes"
|
||||
2. **Para cada URL pendente**:
|
||||
a. Reservar o próximo `REPORT_NUM` sequencial de forma atômica executando `node reserve-report-num.mjs` (e liberar o sentinel executando `node reserve-report-num.mjs --release <num>` após a gravação do relatório)
|
||||
b. **Extrair JD** usando Playwright (browser_navigate + browser_snapshot) → WebFetch → WebSearch
|
||||
c. Se a URL não for acessível → marcar como `- [!]` com nota e continuar
|
||||
d. **Executar auto-pipeline completa**: Avaliação A-F → Report .md → PDF (se score >= 3.0) → Tracker
|
||||
e. **Mover de "Pendentes" para "Processadas"**: `- [x] #NNN | URL | Empresa | Vaga | Score/5 | PDF ✅/❌`
|
||||
3. **Se houver 3+ URLs pendentes**, lançar agentes em paralelo apenas para etapas sem Playwright (ex.: organização, WebSearch/WebFetch).
|
||||
Se a extração exigir Playwright, processar serialmente (1 vaga por vez) para evitar conflito de sessão.
|
||||
4. **Ao terminar**, mostrar tabela resumo:
|
||||
|
||||
```
|
||||
| # | Empresa | Vaga | Score | PDF | Ação recomendada |
|
||||
```
|
||||
|
||||
## Formato de pipeline.md
|
||||
|
||||
```markdown
|
||||
## Pendentes
|
||||
- [ ] https://jobs.example.com/posting/123
|
||||
- [ ] https://boards.greenhouse.io/company/jobs/456 | Company Inc | Senior PM
|
||||
- [!] https://private.url/job — Erro: login necessário
|
||||
|
||||
## Processadas
|
||||
- [x] #143 | https://jobs.example.com/posting/789 | Acme Corp | AI PM | 4.2/5 | PDF ✅
|
||||
- [x] #144 | https://boards.greenhouse.io/xyz/jobs/012 | BigCo | SA | 2.1/5 | PDF ❌
|
||||
```
|
||||
|
||||
> Nota: Os títulos das seções podem estar em EN ("Pending"/"Processed"), ES ("Pendientes"/"Procesadas"), DE ("Offen"/"Verarbeitet") ou PT-BR ("Pendentes"/"Processadas"). Ao ler, ser flexível; ao escrever, manter o estilo do arquivo existente.
|
||||
|
||||
## Detecção inteligente de JD a partir da URL
|
||||
|
||||
1. **Playwright (preferido):** `browser_navigate` + `browser_snapshot`. Funciona com todas as SPAs.
|
||||
2. **WebFetch (fallback):** Para páginas estáticas ou quando Playwright não está disponível.
|
||||
3. **WebSearch (último recurso):** Buscar em portais secundários que indexam o JD.
|
||||
|
||||
**Casos especiais:**
|
||||
- **LinkedIn**: Pode exigir login → marcar com `[!]` e pedir ao candidato para colar o texto
|
||||
- **PDF**: Se a URL aponta para um PDF, ler diretamente com o Read tool
|
||||
- **`local:` prefix**: Ler arquivo local. Exemplo: `local:jds/linkedin-pm-ai.md` → ler `jds/linkedin-pm-ai.md`
|
||||
- **Gupy / Greenhouse / Lever**: Plataformas comuns no Brasil. Playwright funciona bem com todas
|
||||
- **Vagas.com.br / InfoJobs / Catho**: Portais brasileiros, geralmente acessíveis via WebFetch
|
||||
- **LinkedIn BR**: Mesmas restrições do LinkedIn global — pode exigir login
|
||||
|
||||
## Numeração automática
|
||||
|
||||
1. Executar `node reserve-report-num.mjs` para reservar o próximo número sequencial de forma atômica (a saída retornará `{###}`).
|
||||
2. Gravar o arquivo de relatório usando esse número.
|
||||
3. Liberar o sentinel executando `node reserve-report-num.mjs --release {###}` após a gravação do relatório.
|
||||
|
||||
## Sincronização de fontes
|
||||
|
||||
Antes de processar qualquer URL, verificar sincronização:
|
||||
|
||||
```bash
|
||||
node cv-sync-check.mjs
|
||||
```
|
||||
|
||||
Se houver dessincronização, avisar o candidato antes de continuar.
|
||||
@@ -0,0 +1,105 @@
|
||||
# Mode: eu-swe — European SWE Application Calibration
|
||||
|
||||
Use this mode when the candidate is targeting software engineering roles in Europe and wants market-specific application calibration before CV generation, form answers, or interview prep.
|
||||
|
||||
This mode is advisory. It must not replace official immigration, tax, labor, or salary-threshold research.
|
||||
|
||||
## Inputs
|
||||
|
||||
1. **JD text or URL** — role title, country, city, work model, stack, seniority, language, and application portal.
|
||||
2. **CV** at `cv.md` + `article-digest.md` — proof points and real achievements.
|
||||
3. **Profile** at `config/profile.yml` + `modes/_profile.md` — location, targets, constraints, compensation, and user-specific rules.
|
||||
4. **Evaluation report** in `reports/` if one already exists.
|
||||
|
||||
## Step 1 — Market and Role Classification
|
||||
|
||||
Classify the opportunity:
|
||||
|
||||
- country and city
|
||||
- role family: backend, frontend, full-stack, platform, data, ML, DevOps, mobile, security, engineering management
|
||||
- seniority and level signals
|
||||
- work model: remote, hybrid, office-first, relocation
|
||||
- core stack and domain
|
||||
- language expectations
|
||||
- application portal and required fields
|
||||
|
||||
If the country or city is unclear, say so and proceed with generic European SWE guidance.
|
||||
|
||||
## Step 2 — Hard Filters
|
||||
|
||||
Build a table:
|
||||
|
||||
| Filter | JD signal | Candidate signal | Risk | Action |
|
||||
|--------|-----------|------------------|------|--------|
|
||||
| Location/work model | | | pass/risk/blocker/unknown | |
|
||||
| Work authorization/sponsorship | | | pass/risk/blocker/unknown | |
|
||||
| Language | | | pass/risk/blocker/unknown | |
|
||||
| Seniority | | | pass/risk/blocker/unknown | |
|
||||
| Core stack | | | pass/risk/blocker/unknown | |
|
||||
| Domain | | | pass/risk/blocker/unknown | |
|
||||
| Compensation feasibility | | | pass/risk/blocker/unknown | |
|
||||
| Background checks | | | pass/risk/blocker/unknown | |
|
||||
|
||||
Do not guess missing candidate facts. Mark unknowns and ask only when the answer changes apply/no-apply or generated text.
|
||||
|
||||
## Step 3 — Country Notes
|
||||
|
||||
Use these as prompts for what to verify, not as final legal advice.
|
||||
|
||||
| Country/market | Common checks for SWE applications |
|
||||
|----------------|------------------------------------|
|
||||
| Netherlands | Sponsor readiness, recognized employer requirements, office/hybrid expectations, English vs Dutch, finance/security screening such as VOG/PES when relevant. Verify immigration and salary threshold facts from official Dutch sources at runtime. |
|
||||
| Germany / DACH | Blue Card or residence/work permit fit, German vs English expectations, city-specific compensation, notice/probation norms, and highly formal application expectations in some companies. Verify legal and permit facts from official sources at runtime. |
|
||||
| Ireland | Employment permit or local work authorization fit, Dublin vs regional compensation, English-language expectations, and multinational hiring-process norms. Verify permit facts from official Irish sources at runtime. |
|
||||
| France | French vs English expectations, CDI/CDD or contract framing, Paris vs regional compensation, and sector-specific benefits or collective-agreement context when visible in the JD. Verify work authorization and labor facts from official sources at runtime. |
|
||||
| UK | Skilled Worker sponsorship, salary/visa feasibility, London vs regional compensation, and right-to-work wording. Verify legal and immigration facts from official UK sources at runtime. |
|
||||
| Other Europe | Use generic SWE screening plus country-specific official verification for work authorization, salary thresholds, tax/legal constraints, and language expectations. |
|
||||
|
||||
Never hardcode current thresholds. If a threshold matters, search official government sources before advising.
|
||||
|
||||
## Step 4 — Application Calibration
|
||||
|
||||
Produce a concise addendum:
|
||||
|
||||
```markdown
|
||||
## EU SWE Calibration: {Company} — {Role}
|
||||
|
||||
**Market:** {country/city or unknown}
|
||||
**Role family:** {family}
|
||||
**Primary hard filters:** {top 3}
|
||||
**Main reviewer doubts:** {top 3}
|
||||
|
||||
### CV Adjustments
|
||||
- {top-third summary adjustment}
|
||||
- {stack/domain keyword adjustment}
|
||||
- {business-value bullet adjustment}
|
||||
|
||||
### Application Answers
|
||||
- {work authorization / sponsorship answer if asked}
|
||||
- {location / hybrid answer if asked}
|
||||
- {language answer if asked}
|
||||
- {compensation strategy if asked}
|
||||
|
||||
### Interview Prep Handoff
|
||||
- {recruiter screen risks}
|
||||
- {hiring-manager proof points}
|
||||
- {technical topics to prep}
|
||||
|
||||
### Facts To Verify
|
||||
- {official-source checks}
|
||||
- {candidate facts to confirm}
|
||||
```
|
||||
|
||||
## Step 5 — Handoff
|
||||
|
||||
- Use `pdf` mode for the submit-ready CV after calibration.
|
||||
- Use `apply` mode for portal answers after calibration.
|
||||
- Use `interview-prep` mode when the candidate reaches recruiter, hiring-manager, or technical rounds.
|
||||
- Store user-specific rules in `modes/_profile.md` or `config/profile.yml`, not in this mode.
|
||||
|
||||
## Rules
|
||||
|
||||
- Do not invent work authorization, language level, compensation targets, degree equivalence, or relocation availability.
|
||||
- Do not put sensitive logistics in the CV unless the user explicitly wants that or the local market clearly expects it.
|
||||
- Do not provide legal advice. Provide verification prompts and cite official sources when legal facts are used.
|
||||
- Keep output in the JD language unless the user asks otherwise.
|
||||
@@ -0,0 +1,113 @@
|
||||
# career-ops — Русские режимы (`modes/ru/`)
|
||||
|
||||
Этот каталог содержит русскоязычные версии режимов career-ops для соискателей, работающих на российском рынке труда или с русскоязычными вакансиями.
|
||||
|
||||
## Когда использовать?
|
||||
|
||||
Используй `modes/ru/`, если выполняется хотя бы одно из условий:
|
||||
|
||||
- Ты откликаешься на **русскоязычные вакансии** (hh.ru, Хабр Карьера, trudvsem.ru, rabota.ru, Superjob, Geekjob, budu.jobs)
|
||||
- Твоё **резюме на русском** или ты переключаешься между RU и EN в зависимости от вакансии
|
||||
- Тебе нужны ответы и сопроводительные письма на **естественном техническом русском**, а не машинный перевод
|
||||
- Ты работаешь с **особенностями российского рынка**: ТК РФ, НДФЛ 13%, ДМС, испытательный срок, оформление по ТК / ГПХ / самозанятость, зарплата gross vs net
|
||||
|
||||
Если большинство вакансий на английском, используй стандартные режимы из `modes/`. Английские режимы работают и с русскоязычными вакансиями, но не учитывают специфику российского рынка в полном объёме.
|
||||
|
||||
## Как активировать?
|
||||
|
||||
### Способ 1 — Per session, по команде
|
||||
|
||||
Скажи Claude в начале сессии:
|
||||
|
||||
> "Используй русские режимы из `modes/ru/`."
|
||||
|
||||
или
|
||||
|
||||
> "Оценки и отклики на русском — используй `modes/ru/_shared.md` и `modes/ru/oferta.md`."
|
||||
|
||||
Claude будет читать файлы из этого каталога. Если режима нет в `modes/ru/` (например, `scan`, `batch`, `pdf`), используется оригинал из `modes/`.
|
||||
|
||||
### Способ 2 — Постоянно, через профиль
|
||||
|
||||
Добавь в `config/profile.yml`:
|
||||
|
||||
```yaml
|
||||
language:
|
||||
primary: ru
|
||||
modes_dir: modes/ru
|
||||
```
|
||||
|
||||
Напомни Claude в первой сессии: "Смотри в `profile.yml`, я указал `language.modes_dir`".
|
||||
|
||||
> Примечание: `language.modes_dir` — конвенция проекта (аналогично `modes/de/` и `modes/fr/`), а не автоматический механизм в коде. Claude следует ей как указанию при наличии напоминания. Если агент не подхватил настройку — напомните ещё раз.
|
||||
|
||||
## Что переведено?
|
||||
|
||||
Первая итерация охватывает режимы с наибольшим влиянием:
|
||||
|
||||
| Файл | Оригинал | Назначение |
|
||||
|------|----------|------------|
|
||||
| `_shared.md` | `modes/_shared.md` (EN) | Общий контекст, архетипы, глобальные правила, специфика рынка РФ |
|
||||
| `oferta.md` | `modes/oferta.md` (ES) | Полная оценка вакансии (блоки A-F) |
|
||||
| `apply.md` | `modes/apply.md` (ES) | Ассистент заполнения форм откликов |
|
||||
| `pipeline.md` | `modes/pipeline.md` (ES) | Очередь URL-ов / Second Brain для собранных вакансий |
|
||||
| `interview-prep.md` | `modes/interview-prep.md` (EN) | Подготовка к собеседованию |
|
||||
|
||||
Остальные режимы (`scan`, `batch`, `pdf`, `tracker`, `auto-pipeline`, `deep`, `contacto`, `ofertas`, `project`, `training`) остаются на EN/ES. Их содержимое — в основном tooling, пути и команды — не зависит от языка.
|
||||
|
||||
## Что остаётся на английском?
|
||||
|
||||
Сознательно не переведено, т.к. это стандартный tech-словарь:
|
||||
|
||||
- `cv.md`, `pipeline`, `tracker`, `report`, `score`, `archetype`, `proof point`
|
||||
- Имена инструментов (`Playwright`, `WebSearch`, `WebFetch`, `Read`, `Write`, `Edit`, `Bash`)
|
||||
- Статусы в трекере (`Evaluated`, `Applied`, `Interview`, `Offer`, `Rejected`)
|
||||
- Код, пути, команды
|
||||
|
||||
Режимы используют технический русский, как его говорят в реальных инженерных командах: русский текст, английские термины там, где они общеприняты. Никакой принудительной русификации "pipeline" → "конвейер", "cv.md" → "резюме-файл".
|
||||
|
||||
## Словарь
|
||||
|
||||
| English | Русский (в этой кодовой базе) |
|
||||
|---------|-------------------------------|
|
||||
| Job posting | Вакансия |
|
||||
| Application | Отклик / заявка |
|
||||
| Cover letter | Сопроводительное письмо |
|
||||
| Resume / CV | Резюме |
|
||||
| Salary | Зарплата |
|
||||
| Compensation | Компенсация / вознаграждение |
|
||||
| Skills | Навыки |
|
||||
| Interview | Собеседование |
|
||||
| Hiring manager | Нанимающий менеджер |
|
||||
| Recruiter | Рекрутер |
|
||||
| AI | ИИ (Искусственный интеллект) |
|
||||
| Requirements | Требования |
|
||||
| Career history | Опыт работы |
|
||||
| Notice period | Срок уведомления / отработка |
|
||||
| Probation | Испытательный срок |
|
||||
| Vacation | Отпуск |
|
||||
| Remote | Удалённо / удалёнка |
|
||||
| Hybrid | Гибрид |
|
||||
| On-site | Офис |
|
||||
| Benefits | Бенефиты / льготы |
|
||||
| Gross salary | Зарплата до вычета НДФЛ (gross) |
|
||||
| Net salary | Зарплата на руки (net) |
|
||||
| Employment contract (TK RF) | Оформление по ТК РФ |
|
||||
| Civil contract (GPH) | Договор ГПХ |
|
||||
| Self-employed | Самозанятость |
|
||||
| Voluntary health insurance | ДМС (добровольное медицинское страхование) |
|
||||
| Dental insurance | ДМС стоматология |
|
||||
| Food allowance | Компенсация питания |
|
||||
| Sport allowance | Компенсация спорта |
|
||||
| Education budget | Бюджет на обучение |
|
||||
| Works council | Профсоюз |
|
||||
|
||||
## Вклад
|
||||
|
||||
Если хочешь улучшить перевод или добавить новый режим:
|
||||
|
||||
1. Открой issue с предложением (см. `CONTRIBUTING.md`)
|
||||
2. Придерживайся словаря выше для единообразия
|
||||
3. Переводи по смыслу и идиоматично — без дословных переводов
|
||||
4. Сохраняй структурные элементы (блоки A-F, таблицы, код, инструкции для инструментов)
|
||||
5. Протестируй с реальной русскоязычной вакансией (например, с hh.ru или Хабр Карьера)
|
||||
@@ -0,0 +1,217 @@
|
||||
# Общий контекст — career-ops (Русский)
|
||||
|
||||
<!-- ============================================================
|
||||
ЭТОТ ФАЙЛ — СИСТЕМНЫЙ.
|
||||
НЕ добавляйте сюда персональные данные.
|
||||
============================================================
|
||||
Персонализация → modes/_profile.md и config/profile.yml.
|
||||
Этот файл содержит общий контекст, архетипы и правила
|
||||
для русскоязычных режимов.
|
||||
Примечание: modes/ru/ пока не включён в auto-update
|
||||
(update-system.mjs). Обновления применяются вручную.
|
||||
|
||||
Перед использованием career-ops убедитесь:
|
||||
1. config/profile.yml заполнен вашими данными
|
||||
2. cv.md создан в корне проекта (резюме в Markdown)
|
||||
3. (Опционально) article-digest.md с proof points
|
||||
============================================================ -->
|
||||
|
||||
## Источники правды (ВСЕГДА читать перед каждой оценкой)
|
||||
|
||||
| Файл | Путь | Когда |
|
||||
|------|------|-------|
|
||||
| cv.md | `cv.md` (корень проекта) | ВСЕГДА |
|
||||
| article-digest.md | `article-digest.md` (если есть) | ВСЕГДА (детальные proof points) |
|
||||
| profile.yml | `config/profile.yml` | ВСЕГДА (идентичность кандидата и целевые роли) |
|
||||
| _profile.md | `modes/_profile.md` | ВСЕГДА (пользовательские архетипы, нарратив, переговоры) |
|
||||
|
||||
**ПРАВИЛО: НИКОГДА не хардкодить метрики из proof points.** Читать их из cv.md + article-digest.md во время оценки.
|
||||
**ПРАВИЛО: Для метрик статей/проектов `article-digest.md` имеет приоритет над `cv.md`.**
|
||||
**ПРАВИЛО: Читать `_profile.md` ПОСЛЕ этого файла. Пользовательские настройки в `_profile.md` перезаписывают значения по умолчанию.**
|
||||
|
||||
---
|
||||
|
||||
## North Star — Целевые роли
|
||||
|
||||
<!-- [НАСТРОИТЬ] Замени архетипы ниже на СВОИ целевые роли. -->
|
||||
|
||||
### Универсальные архетипы
|
||||
|
||||
| Архетип | Тематические оси | Что покупают |
|
||||
|---------|-------------------|--------------|
|
||||
| **AI Platform / LLMOps Engineer** | Evaluation, observability, надёжность, pipelines | Того, кто выводит ИИ в продакшн с метриками |
|
||||
| **Agentic Workflows / Automation** | HITL, тулинг, оркестрация, мульти-агенты | Того, кто строит надёжные агентные системы |
|
||||
| **Technical AI Product Manager** | GenAI/Agents, PRD, discovery, delivery | Того, кто переводит бизнес в ИИ-продукты |
|
||||
| **AI Solutions Architect** | Гиперавтоматизация, enterprise, интеграции | Того, кто проектирует end-to-end ИИ-архитектуры |
|
||||
| **AI Forward Deployed Engineer** | Клиентский фокус, быстрая поставка, прототипирование | Того, кто быстро внедряет ИИ-решения у клиента |
|
||||
| **AI Transformation Lead** | Change management, adoption, enablement | Того, кто ведёт ИИ-трансформацию в организации |
|
||||
|
||||
### Архетипы для российского рынка
|
||||
|
||||
| Архетип | Тематические оси | Что покупают |
|
||||
|---------|-------------------|--------------|
|
||||
| **Backend-разработчик** | PHP/Go/Java/Python, микросервисы, highload, PostgreSQL, Kafka | Инженера, строящего масштабируемые серверные системы |
|
||||
| **Frontend-разработчик** | React/Vue/Angular, TypeScript, performance, accessibility | Инженера, создающего быстрые и удобные интерфейсы |
|
||||
| **DevOps/SRE-инженер** | Kubernetes, CI/CD, мониторинг, автоматизация инфраструктуры | Инженера, обеспечивающего надёжность и автоматизацию поставки |
|
||||
| **Системный аналитик** | Бизнес-анализ, проектирование API, интеграции, документация | Того, кто переводит бизнес-задачи в технические требования |
|
||||
| **Продуктовый менеджер** | Discovery, delivery, метрики, roadmap, стейкхолдеры | Того, кто определяет что строить и почему |
|
||||
| **Тимлид / Engineering Manager** | People management, tech strategy, delivery, найм | Того, кто строит и ведёт инженерные команды |
|
||||
| **Data Engineer / ML Engineer** | ETL, Spark, Airflow, ML pipelines, feature stores | Инженера данных, строящего data/ML платформы |
|
||||
| **QA-инженер / SDET** | Автоматизация тестирования, CI/CD, нагрузочное тестирование | Инженера качества, обеспечивающего надёжность продукта |
|
||||
| **Архитектор (Solution / Enterprise)** | Системный дизайн, интеграции, масштабирование, стандарты | Того, кто проектирует архитектуру на уровне системы/компании |
|
||||
|
||||
<!-- [НАСТРОИТЬ] Адаптируй архетипы под свой профиль.
|
||||
Пример для backend-инженера:
|
||||
- Senior Backend Engineer (Go/PHP)
|
||||
- Staff Platform Engineer
|
||||
- Engineering Manager
|
||||
и т.д. -->
|
||||
|
||||
### Адаптивный фрейминг по архетипу
|
||||
|
||||
> **Конкретные метрики: читать во время оценки из `cv.md` и `article-digest.md`. НИКОГДА не хардкодить.**
|
||||
|
||||
| Если роль... | Подчеркнуть о кандидате... | Источники proof points |
|
||||
|--------------|---------------------------|------------------------|
|
||||
| Platform / LLMOps | Продакшн-системы, observability, evals | article-digest.md + cv.md |
|
||||
| Agentic / Automation | Мульти-агентная оркестрация, HITL, надёжность | article-digest.md + cv.md |
|
||||
| Technical AI PM | Product discovery, PRD, метрики | cv.md + article-digest.md |
|
||||
| Solutions Architect | Системный дизайн, интеграции, enterprise-ready | article-digest.md + cv.md |
|
||||
| Forward Deployed Engineer | Быстрая поставка, клиентский фокус, прототип → прод | cv.md + article-digest.md |
|
||||
| Backend-разработчик | Highload, микросервисы, масштабирование | cv.md |
|
||||
| DevOps/SRE | Инфраструктура, автоматизация, мониторинг | cv.md |
|
||||
| Тимлид / EM | Лидерство, найм, техническая стратегия | cv.md |
|
||||
|
||||
---
|
||||
|
||||
## Система оценивания
|
||||
|
||||
Оценка использует 6 блоков (A-F) с глобальным баллом 1-5:
|
||||
|
||||
| Измерение | Что оценивает |
|
||||
|-----------|---------------|
|
||||
| Совпадение с CV | Навыки, опыт, proof points alignment |
|
||||
| Соответствие North Star | Насколько роль совпадает с целевыми архетипами кандидата |
|
||||
| Компенсация | Зарплата vs рынок (5 = верхний квартиль, 1 = значительно ниже) |
|
||||
| Культурные сигналы | Культура компании, рост, стабильность, удалёнка |
|
||||
| Red flags | Блокеры, предупреждения (негативные корректировки) |
|
||||
| **Глобальный** | Взвешенное среднее |
|
||||
|
||||
**Интерпретация баллов:**
|
||||
- 4.5+ → Сильное совпадение, рекомендуется откликнуться сразу
|
||||
- 4.0-4.4 → Хорошее совпадение, стоит откликнуться
|
||||
- 3.5-3.9 → Нормально, но не идеально; откликаться только при наличии конкретной причины
|
||||
- Ниже 3.5 → Настоятельно рекомендуется не откликаться
|
||||
|
||||
> **Канонический порог (Ethical Use):** AGENTS.md устанавливает порог **4.0/5** — при баллах ниже 4.0 агент настоятельно рекомендует не откликаться. Диапазон 3.5–3.9 допускается только при наличии весомой причины и требует явного решения пользователя.
|
||||
|
||||
---
|
||||
|
||||
## Специфика российского рынка 🇷🇺
|
||||
|
||||
### Компенсация
|
||||
|
||||
- **Gross vs Net**: В России зарплата часто указывается gross (до вычета НДФЛ 13%). ВСЕГДА уточнять: `gross` или `на руки (net)`. Приблизительная формула: `net ≈ gross × 0.87` (стандартная ставка НДФЛ 13%; реальная ставка может отличаться в зависимости от дохода и статуса).
|
||||
- **Валюта**: Рубли (₽ / RUB). Для международных сравнений использовать USD/EUR по текущему курсу.
|
||||
- **Источники данных**: habr.com/salary, hh.ru/salary, levels.fyi (для международных), Glassdoor, Blind.
|
||||
- **Бонусы**: Годовой бонус (обычно 1-3 оклада), квартальные KPI-бонусы, 13-я зарплата.
|
||||
|
||||
### Оформление трудовых отношений
|
||||
|
||||
| Тип | Описание | Влияние на оценку |
|
||||
|-----|----------|-------------------|
|
||||
| **ТК РФ** | Оформление по Трудовому кодексу. Максимальная защита | +0.3 к стабильности |
|
||||
| **ГПХ** | Договор гражданско-правового характера. Меньше защиты | -0.1 к стабильности |
|
||||
| **Самозанятость** | НПД 6%. Минимальная защита | -0.2 к стабильности |
|
||||
| **ИП** | Индивидуальный предприниматель | Нейтрально (зависит от контекста) |
|
||||
|
||||
### Бенефиты (типичные для РФ)
|
||||
|
||||
- **ДМС** (добровольное медицинское страхование) — стандарт в крупных компаниях
|
||||
- **ДМС стоматология** — расширенный пакет, хороший сигнал
|
||||
- **Компенсация питания** — 5-15 тыс. ₽/мес
|
||||
- **Компенсация спорта** — 3-10 тыс. ₽/мес
|
||||
- **Бюджет на обучение** — конференции, курсы, книги (30-150 тыс. ₽/год)
|
||||
- **Компенсация удалённой работы** — оборудование, интернет (3-10 тыс. ₽/мес)
|
||||
|
||||
### Трудовое право (ТК РФ)
|
||||
|
||||
- **Испытательный срок**: до 3 месяцев (до 6 месяцев для руководителей)
|
||||
- **Отпуск**: минимум 28 календарных дней по ТК + дополнительные дни (ненормированный рабочий день, вредные условия)
|
||||
- **Больничный**: оплачивается из ФСС + доплата от работодателя
|
||||
- **Увольнение**: отработка 2 недели (по соглашению сторон можно без)
|
||||
|
||||
---
|
||||
|
||||
## Глобальные правила
|
||||
|
||||
### НИКОГДА
|
||||
|
||||
1. Выдумывать опыт или метрики
|
||||
2. Модифицировать cv.md или файлы портфолио
|
||||
3. Отправлять отклики от имени кандидата
|
||||
4. Делиться телефоном в генерируемых сообщениях
|
||||
5. Рекомендовать компенсацию ниже рынка
|
||||
6. Генерировать PDF без предварительного чтения JD
|
||||
7. Использовать канцелярит и корпоративный язык
|
||||
8. Игнорировать трекер (каждая оценённая вакансия регистрируется)
|
||||
|
||||
### ВСЕГДА
|
||||
|
||||
0. **Сопроводительное письмо:** Если форма позволяет, ВСЕГДА включать. Тот же дизайн, что и CV. Цитаты из JD, привязанные к proof points. Максимум 1 страница.
|
||||
1. Читать cv.md, _profile.md и article-digest.md (если есть) перед оценкой
|
||||
1b. **Первая оценка в сессии:** Запустить `node cv-sync-check.mjs`. Если предупреждения — уведомить пользователя.
|
||||
2. Определить архетип роли и адаптировать фрейминг по _profile.md
|
||||
3. Цитировать точные строки из CV при совпадении
|
||||
4. Использовать WebSearch для исследования компенсации и данных о компании
|
||||
5. Регистрировать в трекере после оценки
|
||||
6. Генерировать контент на языке JD (RU по умолчанию для русскоязычных вакансий)
|
||||
7. Быть прямым и конкретным — без воды
|
||||
8. Для русскоязычных вакансий: технический русский, короткие предложения, глаголы действия.
|
||||
8b. URL-ы кейсов в Professional Summary PDF (рекрутер может прочитать только это).
|
||||
9. **Добавления в трекер как TSV** — не добавлять НОВЫЕ записи в `data/applications.md` напрямую; для новых записей писать TSV в `batch/tracker-additions/` и делать merge. Прямое редактирование существующих строк допустимо для обновления `status`/`notes`.
|
||||
10. **Включать `**URL:**` в заголовок каждого отчёта.**
|
||||
|
||||
### Инструменты
|
||||
|
||||
| Инструмент | Применение |
|
||||
|------------|------------|
|
||||
| WebSearch | Исследование компенсации, тренды, культура компании, контакты в LinkedIn, fallback для JD |
|
||||
| WebFetch | Fallback для извлечения JD со статических страниц |
|
||||
| Playwright | Верификация вакансий (browser_navigate + browser_snapshot). **НИКОГДА 2+ агентов с Playwright параллельно.** |
|
||||
| Read | cv.md, _profile.md, article-digest.md, cv-template.html |
|
||||
| Write | Временный HTML для PDF, data/applications.md, отчёты .md |
|
||||
| Edit | Обновление трекера |
|
||||
| Bash | `node generate-pdf.mjs` |
|
||||
|
||||
### Приоритет скорости
|
||||
- Рабочее демо + метрики > перфекционизм
|
||||
- Откликнуться раньше > изучить больше
|
||||
- Подход 80/20, таймбоксить всё
|
||||
|
||||
---
|
||||
|
||||
## Профессиональное письмо и ATS-совместимость
|
||||
|
||||
Эти правила применяются ко ВСЕМУ генерируемому тексту для кандидата: PDF-резюме, буллеты, сопроводительные письма, ответы в формах, сообщения в LinkedIn. НЕ применяются к внутренним отчётам оценки.
|
||||
|
||||
### Избегать клише
|
||||
- "Я увлечён..." / "результат-ориентированный" / "обширный опыт"
|
||||
- "Задействовал" (использовать "применил" или назвать инструмент)
|
||||
- "Возглавил" (использовать "руководил" или "запустил")
|
||||
- "Обеспечил взаимодействие" (использовать "организовал" или "настроил")
|
||||
- "Синергия" / "комплексный" / "инновационный"
|
||||
- "В современном быстро меняющемся мире"
|
||||
|
||||
### Юникод-нормализация для ATS
|
||||
`generate-pdf.mjs` автоматически нормализует em-dash, умные кавычки и zero-width символы в ASCII для максимальной ATS-совместимости. Но лучше не генерировать их изначально.
|
||||
|
||||
### Разнообразие структуры предложений
|
||||
- Не начинать каждый буллет одним и тем же глаголом
|
||||
- Чередовать длину предложений
|
||||
- Не всегда использовать "X, Y и Z" — иногда два пункта, иногда четыре
|
||||
|
||||
### Конкретика вместо абстракций
|
||||
- "Снизил p95 latency с 2.1с до 380мс" лучше, чем "улучшил производительность"
|
||||
- "Postgres + pgvector для поиска по 12к документов" лучше, чем "спроектировал масштабируемую RAG-архитектуру"
|
||||
- Называть инструменты, проекты и клиентов, когда разрешено
|
||||
@@ -0,0 +1,94 @@
|
||||
# Режим: apply — Ассистент отклика в реальном времени
|
||||
|
||||
Интерактивный режим для заполнения формы отклика в Chrome. Читает экран, загружает контекст вакансии, генерирует персонализированные ответы.
|
||||
|
||||
## Требования
|
||||
|
||||
- **Лучше с Playwright**: Кандидат видит браузер, Claude взаимодействует со страницей.
|
||||
- **Без Playwright**: Кандидат делится скриншотом или вставляет вопросы вручную.
|
||||
|
||||
## Workflow
|
||||
|
||||
```
|
||||
1. ОПРЕДЕЛИТЬ → Прочитать активную вкладку Chrome (скриншот/URL/заголовок)
|
||||
2. РАСПОЗНАТЬ → Извлечь компанию + роль со страницы
|
||||
3. НАЙТИ → Совпадение с существующими отчётами в reports/
|
||||
4. ЗАГРУЗИТЬ → Прочитать полный отчёт + секцию G (если есть)
|
||||
5. СРАВНИТЬ → Роль на экране совпадает с оценённой? Если изменилась → предупредить
|
||||
6. АНАЛИЗ → Определить ВСЕ видимые вопросы формы
|
||||
7. ГЕНЕРАЦИЯ → Для каждого вопроса — персонализированный ответ
|
||||
8. ПОКАЗАТЬ → Отформатированные ответы для copy-paste
|
||||
```
|
||||
|
||||
## Шаг 1 — Определить вакансию
|
||||
|
||||
**С Playwright:** Snapshot активной страницы. Прочитать заголовок, URL, видимое содержимое.
|
||||
|
||||
**Без Playwright:** Попросить кандидата:
|
||||
- Поделиться скриншотом формы
|
||||
- Или вставить вопросы как текст
|
||||
- Или назвать компанию + роль
|
||||
|
||||
## Шаг 2 — Найти контекст
|
||||
|
||||
1. Извлечь название компании и должность
|
||||
2. Искать в `reports/` по названию компании (Grep, case-insensitive)
|
||||
3. Если есть совпадение → загрузить полный отчёт
|
||||
4. Если есть секция G → загрузить черновики как базу
|
||||
5. Если НЕТ совпадения → предупредить и предложить запустить auto-pipeline
|
||||
|
||||
## Шаг 3 — Обнаружить изменения
|
||||
|
||||
Если роль на экране отличается от оценённой:
|
||||
- **Предупредить кандидата**: "Роль изменилась с [X] на [Y]. Переоценить или адаптировать ответы?"
|
||||
- Обновить трекер при необходимости
|
||||
|
||||
## Шаг 4 — Анализировать вопросы формы
|
||||
|
||||
Определить ВСЕ видимые вопросы:
|
||||
- Поля свободного текста (сопроводительное, "почему эта роль" и т.д.)
|
||||
- Выпадающие списки (откуда узнали, разрешение на работу и т.д.)
|
||||
- Да/Нет (переезд, виза и т.д.)
|
||||
- Поля зарплаты (диапазон, ожидания)
|
||||
- Поля загрузки (резюме, сопроводительное PDF)
|
||||
|
||||
## Шаг 5 — Генерировать ответы
|
||||
|
||||
Для каждого вопроса:
|
||||
|
||||
1. **Контекст отчёта**: Proof points из блока B, истории STAR из блока F
|
||||
2. **Секция G**: Если есть черновик — использовать как базу и улучшить
|
||||
3. **Тон "Я выбираю вас"**: Кандидат имеет варианты и выбирает эту компанию по конкретным причинам
|
||||
4. **Конкретика**: Ссылка на что-то конкретное из видимого JD
|
||||
5. **Язык ответов**: На языке JD. Для русскоязычных вакансий — на русском.
|
||||
|
||||
**Формат вывода:**
|
||||
|
||||
```
|
||||
## Ответы для [Компания] — [Роль]
|
||||
|
||||
На основе: Отчёт #NNN | Балл: X.X/5 | Архетип: [тип]
|
||||
|
||||
---
|
||||
|
||||
### 1. [Точный вопрос из формы]
|
||||
> [Ответ, готовый для copy-paste]
|
||||
|
||||
### 2. [Следующий вопрос]
|
||||
> [Ответ]
|
||||
|
||||
...
|
||||
|
||||
---
|
||||
|
||||
Заметки:
|
||||
- [Наблюдения о роли, изменениях и т.д.]
|
||||
- [Предложения по персонализации для проверки кандидатом]
|
||||
```
|
||||
|
||||
## Шаг 6 — После отклика (опционально)
|
||||
|
||||
Если кандидат подтвердил отправку:
|
||||
1. Обновить статус в `data/applications.md` с "Evaluated" на "Applied"
|
||||
2. Обновить секцию G отчёта финальными ответами
|
||||
3. Предложить: `/career-ops contacto` для LinkedIn outreach
|
||||
@@ -0,0 +1,136 @@
|
||||
# Режим: interview-prep — Подготовка к собеседованию
|
||||
|
||||
Когда пользователь просит подготовиться к собеседованию в конкретной компании, или оценка ≥ 4.0 и статус обновлён на `Interview`.
|
||||
|
||||
## Входные данные
|
||||
|
||||
1. **Название компании** и **должность** (обязательно)
|
||||
2. **Отчёт оценки** в `reports/` (если есть)
|
||||
3. **Банк историй** `interview-prep/story-bank.md`
|
||||
4. **CV** `cv.md` + `article-digest.md`
|
||||
5. **Профиль** `config/profile.yml` + `modes/_profile.md`
|
||||
|
||||
## Шаг 1 — Исследование
|
||||
|
||||
WebSearch-запросы. Извлекать структурированные данные, не пересказы. Цитировать источники.
|
||||
|
||||
| Запрос | Что извлечь |
|
||||
|--------|-------------|
|
||||
| `"{company} {role} interview questions site:glassdoor.com"` | Реальные вопросы, сложность, таймлайн, кол-во раундов |
|
||||
| `"{company} interview process site:teamblind.com"` | Описания процесса, данные о компенсации |
|
||||
| `"{company} {role} interview site:leetcode.com/discuss"` | Конкретные задачи, темы system design |
|
||||
| `"{company} engineering blog"` | Стек, ценности, технические приоритеты |
|
||||
| `"{company} собеседование отзывы site:habr.com"` | Отзывы на русском о процессе собеседования |
|
||||
| `"{company} отзывы собеседование site:hh.ru"` | Отзывы кандидатов на hh.ru |
|
||||
|
||||
**НЕ выдумывать вопросы.** Выведенные из JD — помечать `[выведено из JD]`.
|
||||
|
||||
## Шаг 2 — Обзор процесса
|
||||
|
||||
```markdown
|
||||
## Обзор процесса
|
||||
- **Раунды:** {N} раундов, ~{X} дней от начала до конца
|
||||
- **Формат:** {напр., скрининг HR → техническое интервью → тестовое → onsite → нанимающий менеджер}
|
||||
- **Сложность:** {X}/5 (среднее Glassdoor, N отзывов)
|
||||
- **Позитивный опыт:** {X}%
|
||||
- **Особенности:** {напр., "парное программирование вместо доски", "без LeetCode, только практические задачи"}
|
||||
- **Источники:** {ссылки}
|
||||
```
|
||||
|
||||
## Шаг 3 — Разбор по раундам
|
||||
|
||||
```markdown
|
||||
### Раунд {N}: {Тип}
|
||||
- **Длительность:** {X} мин
|
||||
- **Проводит:** {коллега / менеджер / skip-level / рекрутер}
|
||||
- **Что оценивают:** {конкретные навыки}
|
||||
- **Зафиксированные вопросы:**
|
||||
- {вопрос} — [источник: Glassdoor 2026-Q1]
|
||||
- **Как готовиться:** {1-2 конкретных действия}
|
||||
```
|
||||
|
||||
## Шаг 4 — Вероятные вопросы
|
||||
|
||||
### Технические
|
||||
Вопросы по system design, кодированию, архитектуре, domain knowledge.
|
||||
|
||||
### Поведенческие
|
||||
Вопросы про лидерство, конфликты, коллаборацию, неудачи.
|
||||
Для каждого — какая история из `story-bank.md` подходит лучше всего.
|
||||
|
||||
### Специфичные для роли
|
||||
Вопросы, привязанные к конкретному JD (с учётом архетипа).
|
||||
|
||||
### Red flags в бэкграунде
|
||||
Вопросы, которые интервьюер вероятно задаст про пробелы, переходы или необычные элементы в бэкграунде. Читать `_profile.md` и `cv.md`.
|
||||
|
||||
## Шаг 5 — Маппинг банка историй
|
||||
|
||||
| # | Вероятный вопрос/тема | Лучшая история из story-bank.md | Fit | Пробел? |
|
||||
|---|----------------------|-------------------------------|-----|---------|
|
||||
|
||||
- **strong**: история прямо отвечает на вопрос
|
||||
- **partial**: история смежная, нужен рефрейминг
|
||||
- **none**: нет подходящей → отметить для пользователя
|
||||
|
||||
## Шаг 6 — Чеклист технической подготовки
|
||||
|
||||
```markdown
|
||||
- [ ] {тема} — почему: "{доказательство из исследования}"
|
||||
- [ ] {тема} — почему: "{их блог/продукт говорит, что это важно}"
|
||||
```
|
||||
|
||||
Приоритизировать по частоте и релевантности. Максимум 10 пунктов.
|
||||
|
||||
## Шаг 7 — Сигналы компании
|
||||
|
||||
- **Ценности, на которые скринят:** назвать, цитировать источник
|
||||
- **Словарь для использования:** внутренние термины компании
|
||||
- **Чего избегать:** анти-паттерны из отзывов
|
||||
- **Вопросы им:** 2-3 острых вопроса, демонстрирующих домашнюю работу
|
||||
|
||||
## Специфика российских собеседований 🇷🇺
|
||||
|
||||
### Типичные раунды в российских компаниях
|
||||
1. **Скрининг HR** (20-30 мин): мотивация, зарплатные ожидания, готовность к переезду/формату
|
||||
2. **Техническое интервью** (60-90 мин): алгоритмы, system design, знание стека
|
||||
3. **Live coding** (45-60 мин): задачи на алгоритмы или практические задачи
|
||||
4. **System design** (60 мин): проектирование систем (особенно Яндекс, Авито, VK, Ozon, Т-Банк)
|
||||
5. **Культурный fit** (30-45 мин): ценности, командная работа, конфликты
|
||||
6. **Бар-рейзер** (в крупных компаниях): финальное одобрение от senior-инженера
|
||||
|
||||
### Частые вопросы на российских собеседованиях
|
||||
- "Расскажите о себе" (2-3 минуты, структурированно)
|
||||
- "Почему уходите с текущего места?"
|
||||
- "Зарплатные ожидания?" (уточнить gross/net)
|
||||
- "Готовность к переезду / формату работы?"
|
||||
- "Расскажите о самом сложном проекте"
|
||||
- "Как решаете конфликты в команде?"
|
||||
- System design: "Спроектируйте {URL shortener / чат / лента новостей / платёжная система}"
|
||||
|
||||
### Формат STAR+R на русском
|
||||
- **С (Ситуация):** Контекст и вводные
|
||||
- **З (Задача):** Что нужно было сделать
|
||||
- **Д (Действия):** Что конкретно сделал
|
||||
- **Р (Результат):** Измеримый результат
|
||||
- **О (Осмысление):** Что понял, что сделал бы иначе
|
||||
|
||||
## Вывод
|
||||
|
||||
Сохранить отчёт в `interview-prep/{company-slug}-{role-slug}.md`.
|
||||
|
||||
```markdown
|
||||
# Подготовка к собеседованию: {Компания} — {Роль}
|
||||
|
||||
**Отчёт:** {ссылка на отчёт оценки или "N/A"}
|
||||
**Исследовано:** {YYYY-MM-DD}
|
||||
**Источники:** {N} отзывов Glassdoor, {N} постов Blind, {N} прочих
|
||||
```
|
||||
|
||||
## Правила
|
||||
|
||||
- **НИКОГДА не выдумывать вопросы и приписывать их источникам.**
|
||||
- **НИКОГДА не фабриковать рейтинги Glassdoor.**
|
||||
- **Цитировать всё.** Каждый вопрос, каждая статистика получает источник или тег `[выведено]`.
|
||||
- Генерировать на языке JD (RU по умолчанию для русскоязычных вакансий).
|
||||
- Быть прямым. Это рабочий документ подготовки, не мотивационная речь.
|
||||
@@ -0,0 +1,165 @@
|
||||
# Режим: oferta — Полная оценка A-F
|
||||
|
||||
Когда кандидат вставляет вакансию (текст или URL), ВСЕГДА выдать 6 блоков:
|
||||
|
||||
## Шаг 0 — Определение архетипа
|
||||
|
||||
Классифицировать вакансию по одному из архетипов (см. `_shared.md`). Если гибрид — указать 2 ближайших. Это определяет:
|
||||
- Какие proof points приоритизировать в блоке B
|
||||
- Как переписать summary в блоке E
|
||||
- Какие истории STAR готовить в блоке F
|
||||
|
||||
## Блок A — Резюме роли
|
||||
|
||||
Таблица с:
|
||||
- Определённый архетип
|
||||
- Domain (platform/agentic/LLMOps/ML/enterprise/backend/frontend/devops)
|
||||
- Function (build/consult/manage/deploy)
|
||||
- Seniority
|
||||
- Формат работы (удалённо/гибрид/офис)
|
||||
- Размер команды (если указано)
|
||||
- Оформление (ТК РФ / ГПХ / самозанятость — если указано)
|
||||
- TL;DR в 1 предложении
|
||||
|
||||
## Блок B — Совпадение с CV
|
||||
|
||||
Прочитать `cv.md`. Создать таблицу: каждое требование JD → точные строки CV.
|
||||
|
||||
**Адаптировано под архетип:**
|
||||
- Если FDE → приоритизировать proof points быстрой поставки и клиентской работы
|
||||
- Если SA → приоритизировать системный дизайн и интеграции
|
||||
- Если PM → приоритизировать product discovery и метрики
|
||||
- Если LLMOps → приоритизировать evals, observability, pipelines
|
||||
- Если Agentic → приоритизировать мульти-агент, HITL, оркестрацию
|
||||
- Если Backend → приоритизировать highload, микросервисы, масштабирование
|
||||
- Если DevOps/SRE → приоритизировать инфраструктуру, CI/CD, мониторинг
|
||||
|
||||
Раздел **пробелов** со стратегией закрытия каждого:
|
||||
1. Это hard blocker или nice-to-have?
|
||||
2. Может ли кандидат продемонстрировать смежный опыт?
|
||||
3. Есть ли портфолио-проект, закрывающий этот пробел?
|
||||
4. Конкретный план закрытия (фраза для сопроводительного, быстрый проект и т.д.)
|
||||
|
||||
## Блок C — Уровень и стратегия
|
||||
|
||||
1. **Уровень в JD** vs **естественный уровень кандидата для этого архетипа**
|
||||
2. **План "продать senior без обмана"**: конкретные фразы, адаптированные под архетип, достижения для акцента, как позиционировать опыт
|
||||
3. **План "если понизят уровень"**: принять если компенсация справедлива, договориться о пересмотре через 6 месяцев, чёткие критерии роста
|
||||
|
||||
## Блок D — Компенсация и спрос
|
||||
|
||||
Использовать WebSearch для:
|
||||
- Актуальные зарплаты по роли (habr.com/salary, hh.ru/salary, Glassdoor, Levels.fyi, Blind)
|
||||
- Репутация компании по компенсации
|
||||
- Тренд спроса на роль
|
||||
- **Gross vs Net**: уточнить, что указано в JD (до вычета НДФЛ 13% или на руки)
|
||||
|
||||
Таблица с данными и цитированием источников. Если данных нет — сказать об этом вместо выдумывания.
|
||||
|
||||
**Специфика РФ:**
|
||||
- Если зарплата указана gross → показать приблизительный net: `net ≈ gross × 0.87` (стандартный НДФЛ 13%; реальная ставка может отличаться)
|
||||
- Учесть бенефиты: ДМС, питание, спорт, обучение
|
||||
- Оформление: ТК РФ даёт больше гарантий, чем ГПХ/самозанятость
|
||||
|
||||
## Блок E — План персонализации
|
||||
|
||||
| # | Раздел | Текущее состояние | Предлагаемое изменение | Почему |
|
||||
|---|--------|-------------------|------------------------|--------|
|
||||
| 1 | Summary | ... | ... | ... |
|
||||
| ... | ... | ... | ... | ... |
|
||||
|
||||
Топ 5 изменений CV + Топ 5 изменений в LinkedIn/hh.ru для максимального совпадения.
|
||||
|
||||
## Блок F — План собеседований
|
||||
|
||||
6-10 историй STAR+R, привязанных к требованиям JD (STAR + **Reflection**):
|
||||
|
||||
| # | Требование JD | История STAR+R | S | T | A | R | Reflection |
|
||||
|---|---------------|----------------|---|---|---|---|------------|
|
||||
|
||||
Столбец **Reflection** фиксирует, что было изучено или что можно было бы сделать иначе. Это сигнал сеньорности — джуниоры описывают что произошло, сеньоры извлекают уроки.
|
||||
|
||||
**Банк историй:** Если `interview-prep/story-bank.md` существует, проверить, есть ли там эти истории. Если нет — добавить новые. Со временем это формирует банк из 5-10 мастер-историй для любого вопроса на собеседовании.
|
||||
|
||||
**Подобранные и обрамлённые по архетипу:**
|
||||
- FDE → акцент на скорости поставки и клиентской работе
|
||||
- SA → акцент на архитектурных решениях
|
||||
- PM → акцент на discovery и trade-offs
|
||||
- Backend → акцент на highload, масштабировании, надёжности
|
||||
- DevOps → акцент на автоматизации, инцидентах, reliability
|
||||
|
||||
Включить также:
|
||||
- 1 рекомендуемый кейс (какой проект представить и как)
|
||||
- Вопросы-ловушки и как на них отвечать (напр.: "Почему ушли с прошлого места?", "Почему решили сменить стек?")
|
||||
|
||||
---
|
||||
|
||||
## Пост-оценка
|
||||
|
||||
**ВСЕГДА** после генерации блоков A-F:
|
||||
|
||||
### 1. Сохранить отчёт .md
|
||||
|
||||
Сохранить полную оценку в `reports/{###}-{company-slug}-{YYYY-MM-DD}.md`.
|
||||
|
||||
- `{###}` = следующий порядковый номер (3 цифры, zero-padded). Чтобы выделить этот номер атомарно и избежать состояний гонки, вы ДОЛЖНЫ выполнить `node reserve-report-num.mjs` для резервирования номера (stdout вернет `{###}`), записать отчет, а затем выполнить `node reserve-report-num.mjs --release {###}` для освобождения маркера (sentinel).
|
||||
- `{company-slug}` = название компании: lowercase, пробелы заменить на `-`, убрать спецсимволы (например, `Acme Corp` → `acme-corp`)
|
||||
- `{YYYY-MM-DD}` = текущая дата
|
||||
|
||||
**Формат отчёта:**
|
||||
|
||||
```markdown
|
||||
# Оценка: {Компания} — {Роль}
|
||||
|
||||
**Дата:** {YYYY-MM-DD}
|
||||
**Архетип:** {определённый}
|
||||
**Балл:** {X/5}
|
||||
**URL:** {ссылка на вакансию}
|
||||
**PDF:** {путь или "ожидается"}
|
||||
|
||||
---
|
||||
|
||||
## A) Резюме роли
|
||||
(полное содержание блока A)
|
||||
|
||||
## B) Совпадение с CV
|
||||
(полное содержание блока B)
|
||||
|
||||
## C) Уровень и стратегия
|
||||
(полное содержание блока C)
|
||||
|
||||
## D) Компенсация и спрос
|
||||
(полное содержание блока D)
|
||||
|
||||
## E) План персонализации
|
||||
(полное содержание блока E)
|
||||
|
||||
## F) План собеседований
|
||||
(полное содержание блока F)
|
||||
|
||||
## G) Черновики ответов на форму
|
||||
(только если балл >= 4.5 — черновики ответов для формы отклика)
|
||||
|
||||
---
|
||||
|
||||
## Извлечённые ключевые слова
|
||||
(список из 15-20 keywords из JD для ATS-оптимизации)
|
||||
```
|
||||
|
||||
### 2. Зарегистрировать в трекере
|
||||
|
||||
Для **новой** записи не редактировать `data/applications.md` напрямую. Вместо этого записать одну TSV-строку в `batch/tracker-additions/{num}-{company-slug}.tsv` с 8 или 9 колонками через табуляцию:
|
||||
|
||||
```
|
||||
{num}\t{date}\t{company}\t{role}\t{status}\t{score}\t{pdf_emoji}\t[{num}](reports/{num}-{slug}-{date}.md)\t{note}
|
||||
```
|
||||
|
||||
- `{num}` = следующий порядковый номер (целое число, вычислить из `reports/`)
|
||||
- `{status}` = `Evaluated`
|
||||
- `{score}` = формат `X.X/5` (например, `4.2/5`)
|
||||
- `{pdf_emoji}` = `✅` или `❌`
|
||||
- `{note}` = краткий комментарий (опционально, колонку можно опустить)
|
||||
|
||||
Затем выполнить `node merge-tracker.mjs` для слияния в `data/applications.md`.
|
||||
|
||||
Для **существующей** записи допустимо прямое обновление в `data/applications.md` (статус, PDF, ссылка на отчёт).
|
||||
@@ -0,0 +1,58 @@
|
||||
# Режим: pipeline — Очередь URL (Second Brain)
|
||||
|
||||
Обрабатывает URL вакансий из `data/pipeline.md`. Пользователь добавляет URL когда угодно, затем запускает `/career-ops pipeline` для обработки.
|
||||
|
||||
## Workflow
|
||||
|
||||
1. **Прочитать** `data/pipeline.md` → найти `- [ ]` в секции "Ожидающие" (или "Pendientes" / "Pending" — pipeline.md может содержать заголовки на любом языке)
|
||||
2. **Для каждого URL**:
|
||||
a. Зарезервировать следующий `REPORT_NUM` атомарно, запустив `node reserve-report-num.mjs` (и освободить маркер, запустив `node reserve-report-num.mjs --release <num>` после записи отчета)
|
||||
b. **Извлечь JD** через Playwright → WebFetch → WebSearch
|
||||
c. Если URL недоступен → пометить `- [!]` с заметкой, продолжить
|
||||
d. **Выполнить auto-pipeline**: Оценка A-F → Отчёт .md → PDF (если балл >= 3.0) → Трекер
|
||||
e. **Переместить из "Ожидающие" в "Обработанные"**: `- [x] #NNN | URL | Компания | Роль | Балл/5 | PDF ✅/❌`
|
||||
3. **Если 3+ URL**, запустить агентов параллельно (Agent tool с `run_in_background`). **Ограничение:** Playwright требует ресурсов — использовать **только один** Playwright-агент одновременно (правило `_shared.md`). Все прочие шаги (WebFetch, оценка, генерация отчёта) допускают полную параллелизацию. Рекомендуемая схема: один агент с Playwright верифицирует активность вакансии; остальные агенты получают JD через WebFetch и параллельно проводят оценку.
|
||||
4. **По завершении** показать таблицу:
|
||||
|
||||
```
|
||||
| # | Компания | Роль | Балл | PDF | Рекомендуемое действие |
|
||||
```
|
||||
|
||||
## Формат pipeline.md
|
||||
|
||||
```markdown
|
||||
## Ожидающие
|
||||
- [ ] https://jobs.example.com/posting/123
|
||||
- [ ] https://hh.ru/vacancy/12345678 | Компания | Senior Backend
|
||||
- [!] https://private.url/job — Ошибка: требуется авторизация
|
||||
|
||||
## Обработанные
|
||||
- [x] #143 | https://jobs.example.com/posting/789 | Acme Corp | AI PM | 4.2/5 | PDF ✅
|
||||
- [x] #144 | https://hh.ru/vacancy/87654321 | BigCo | Backend | 2.1/5 | PDF ❌
|
||||
```
|
||||
|
||||
## Определение JD из URL
|
||||
|
||||
1. **Playwright (предпочтительно):** `browser_navigate` + `browser_snapshot`. Работает со всеми SPA.
|
||||
2. **WebFetch (fallback):** Для статических страниц.
|
||||
3. **WebSearch (последний ресурс):** Поиск на вторичных порталах.
|
||||
|
||||
**Особые случаи:**
|
||||
- **hh.ru**: API доступен: `https://api.hh.ru/vacancies/{id}` — JSON с полным описанием
|
||||
- **LinkedIn**: Может требовать логин → пометить `[!]`, попросить вставить текст
|
||||
- **PDF**: Если URL на PDF — прочитать через Read tool
|
||||
- **`local:` префикс**: Читать локальный файл. Пример: `local:jds/company-role.md`
|
||||
|
||||
## Нумерация
|
||||
|
||||
1. Запустить `node reserve-report-num.mjs` для атомарного резервирования следующего порядкового номера (stdout вернет `{###}`).
|
||||
2. Записать файл отчета, используя этот номер.
|
||||
3. Освободить маркер, запустив `node reserve-report-num.mjs --release {###}` после записи отчета.
|
||||
|
||||
## Синхронизация источников
|
||||
|
||||
Перед обработкой URL:
|
||||
```bash
|
||||
node cv-sync-check.mjs
|
||||
```
|
||||
Если рассинхронизация — предупредить пользователя.
|
||||
+346
@@ -0,0 +1,346 @@
|
||||
# Mode: scan — Portal Scanner (Job Discovery)
|
||||
|
||||
Scans configured job portals, filters by title relevance, and adds new offers to the pipeline for subsequent evaluation.
|
||||
|
||||
> **Note (v1.6+):** The default scanner (`scan.mjs` / `npm run scan`) is **zero-token** and uses structured sources: local parsers configured per company and public Greenhouse, Ashby, and Lever APIs. The levels with Playwright/WebSearch described below represent the **agent** workflow (executed by the AI agent), not what `scan.mjs` does. If a company does not have a local parser or a Greenhouse/Ashby/Lever API, `scan.mjs` will ignore it; in those cases, the agent must manually complete Level 1 (Playwright) or Level 3 (WebSearch).
|
||||
>
|
||||
> **Rule (v1.8+):** If a company's local parser completes successfully in Level 0, the agent **must not** repeat that company in Playwright (Level 1) or API (Level 2). In Level 3, general queries remain active, but results from companies already covered by a parser are discarded. See [Rule: Successful Local Parser](#rule-successful-local-parser--no-expensive-scraping-repetition).
|
||||
|
||||
## Recommended Execution
|
||||
|
||||
Execute as a worker/subagent if your CLI supports it, to avoid consuming the main interactive context:
|
||||
|
||||
```python
|
||||
Agent(
|
||||
subagent_type="general-purpose",
|
||||
prompt="[content of this file + specific data]",
|
||||
run_in_background=True
|
||||
)
|
||||
```
|
||||
|
||||
The spawned subagent is a **single-pass worker**: it runs the scan with the parsers/APIs/Playwright/WebSearch named below, directly. It must **not** spawn further subagents or invoke other skills (see `modes/_shared.md` → Subagent delegation). Scanning is bounded by `portals.yml`; it is never an open-ended research task.
|
||||
|
||||
## Configuration
|
||||
|
||||
Read `portals.yml` which contains:
|
||||
- `search_queries`: List of WebSearch queries with `site:` filters per portal (broad discovery)
|
||||
- `tracked_companies`: Specific companies with `careers_url` for direct navigation
|
||||
- `tracked_companies[].parser`: Optional local parser for SSR pages or stable HTML
|
||||
- `title_filter`: Keywords (positive/negative/seniority_boost) for filtering job titles
|
||||
|
||||
## Discovery Strategy (4 Levels)
|
||||
|
||||
### Level 0 — Local Parser (CHEAPEST)
|
||||
|
||||
**For each company in `tracked_companies` with a configured `parser`:** execute the local parser defined in `portals.yml`. This level is ideal when the careers page uses SSR or stable HTML and there is already a local JavaScript, Python, or other runtime script that extracts jobs without agent assistance.
|
||||
|
||||
Recommended Contract:
|
||||
|
||||
```yaml
|
||||
- name: Example Company
|
||||
careers_url: https://example.com/careers
|
||||
scan_method: local_parser
|
||||
parser:
|
||||
command: node
|
||||
script: scripts/parsers/example-company-jobs.js
|
||||
format: jobs-json-v1
|
||||
enabled: true
|
||||
```
|
||||
|
||||
Typically, the parser is company-specific and already knows the URL, selectors, and pagination. `args` is optional: use it however it helps the script author, for example, to reuse it across companies, pass `{careers_url}` or `{company}`, activate a debug flag, save a JSON snapshot, or control any parser-specific behavior.
|
||||
|
||||
The parser must output JSON to stdout:
|
||||
|
||||
Array format:
|
||||
|
||||
```json
|
||||
[
|
||||
{ "title": "Senior AI Engineer", "url": "https://example.com/jobs/123", "location": "Remote" }
|
||||
]
|
||||
```
|
||||
|
||||
Object format with `jobs`:
|
||||
|
||||
```json
|
||||
{
|
||||
"jobs": [
|
||||
{ "title": "Senior AI Engineer", "url": "https://example.com/jobs/123", "location": "Remote" }
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
Object format with `results`:
|
||||
|
||||
```json
|
||||
{
|
||||
"results": [
|
||||
{ "title": "Senior AI Engineer", "url": "https://example.com/jobs/123", "location": "Remote" }
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
`company` is optional; if not provided, `scan.mjs` uses the name from `tracked_companies`.
|
||||
|
||||
The scanner does not need to persist the full JSON after reading stdout. If a parser also generates an artifact for auditing or debugging, save it under `data/parser-output/{company}/` and keep it out of git (JSON files in `.gitignore`; `.gitkeep` files are kept in git to preserve the directory structure).
|
||||
|
||||
### Rule: Successful Local Parser — No Expensive Scraping Repetition
|
||||
|
||||
The goal of `scan_method: local_parser` is to **reduce tokens**: prevent the LLM from rescraping the same company using Playwright or redundant APIs.
|
||||
|
||||
During the agent's scan, keep the **`local_parser_ok`** set in memory. This set contains the names of companies (`tracked_companies[].name`) for which Level 0 completed successfully:
|
||||
|
||||
- `parser.command` + `parser.script` exist and the script executed without a fatal error.
|
||||
- stdout was valid JSON (`[]`, `{ jobs: [] }`, or `{ results: [] }`).
|
||||
- There was no timeout or process crash.
|
||||
|
||||
| Level | If the company is in `local_parser_ok` |
|
||||
|-------|----------------------------------------|
|
||||
| **1 — Playwright** | **Skip** — do not `browser_navigate` to its `careers_url` (most expensive token-consuming method) |
|
||||
| **2 — API** | **Skip** — do not WebFetch its `api:` (already covered by parser; `scan.mjs` does not use API after a successful parser either) |
|
||||
| **3 — WebSearch** | Run **general** queries (`site:`, role titles); **discard** any hit whose normalized company matches `local_parser_ok` |
|
||||
|
||||
**Exceptions:**
|
||||
|
||||
- Parser **failed** → the company is **not** added to `local_parser_ok`; Levels 1 and 2 apply normally (same criteria as the fallback in `scan.mjs` when the parser fails and an ATS API is available).
|
||||
- Level 3: do not deactivate cross-cutting queries (`site:jobs.ashbyhq.com`, `site:boards.greenhouse.io`, etc.) — these are used to discover **new** companies. Only filter out results for companies already in `tracked_companies` with a successful parser.
|
||||
- Do not create dedicated `search_queries` for a company with an active local parser (e.g. `site:jobs.ashbyhq.com/cohere "AI Engineer"`); use the parser or, if it fails, Playwright/API.
|
||||
|
||||
**Recommended Level 0:** run `node scan.mjs` (or `npm run scan`) at the start of the agent's workflow. This covers local parsers + APIs in a single zero-token step and returns which companies used the `local-parser` successfully.
|
||||
|
||||
### Level 1 — Direct Playwright (PRIMARY)
|
||||
|
||||
**For each company in `tracked_companies` that is not in `local_parser_ok`:** Navigate to its `careers_url` with Playwright (`browser_navigate` + `browser_snapshot`), read ALL visible job listings, and extract the title + URL for each. This is the most reliable method because:
|
||||
- It views the page in real time (not cached Google results)
|
||||
- It works with SPAs (Ashby, Lever, Workday)
|
||||
- It detects new offers instantly
|
||||
- It does not depend on Google indexing
|
||||
|
||||
**Every company MUST have a `careers_url` in portals.yml.** If it does not, search for it once, save it, and use it in future scans.
|
||||
|
||||
### Level 2 — ATS APIs / Feeds (COMPLEMENTARY)
|
||||
|
||||
For companies with a public API or structured feed **that are not in `local_parser_ok`**, use the JSON/XML response as a fast complement to Level 1. This is faster than Playwright and reduces visual scraping errors.
|
||||
|
||||
**Current Support (variables inside `{}`):**
|
||||
- Full provider table: [Supported job boards](../docs/SUPPORTED_JOB_BOARDS.md)
|
||||
|
||||
- **Greenhouse**: `https://boards-api.greenhouse.io/v1/boards/{company}/jobs`
|
||||
- **Ashby**: `https://jobs.ashbyhq.com/api/non-user-graphql?op=ApiJobBoardWithTeams`
|
||||
- **BambooHR**: list `https://{company}.bamboohr.com/careers/list`; job details `https://{company}.bamboohr.com/careers/{id}/detail`
|
||||
- **Lever**: `https://api.lever.co/v0/postings/{company}?mode=json`
|
||||
- **Teamtailor**: `https://{company}.teamtailor.com/jobs.rss`
|
||||
- **Workday**: `https://{company}.{shard}.myworkdayjobs.com/wday/cxs/{company}/{site}/jobs`
|
||||
- **Breezy**: `https://{company}.breezy.hr/json`
|
||||
|
||||
**Parsing Conventions by Provider:**
|
||||
- `greenhouse`: `jobs[]` → `title`, `absolute_url`
|
||||
- `ashby`: GraphQL `ApiJobBoardWithTeams` with `organizationHostedJobsPageName={company}` → `jobBoard.jobPostings[]` (`title`, `id`; build public URL if not present in payload)
|
||||
- `bamboohr`: list `result[]` → `jobOpeningName`, `id`; build detail URL `https://{company}.bamboohr.com/careers/{id}/detail`; to read full JD, make a GET request to the detail URL and use `result.jobOpening` (`jobOpeningName`, `description`, `datePosted`, `minimumExperience`, `compensation`, `jobOpeningShareUrl`)
|
||||
- `lever`: root array `[]` → `text`, `hostedUrl` (fallback: `applyUrl`)
|
||||
- `teamtailor`: RSS items → `title`, `link`
|
||||
- `workday`: `jobPostings[]`/`jobPostings` (based on tenant) → `title`, `externalPath` or URL built from the host
|
||||
- `breezy`: top-level array `[]` → `name`, `url` (absolute), `location.name` (or city/state/country + `is_remote`), `published_date`
|
||||
|
||||
### Level 3 — WebSearch Queries (BROAD DISCOVERY)
|
||||
|
||||
The `search_queries` with `site:` filters cover portals transversally (all Ashby, all Greenhouse, etc.). Useful for discovering NEW companies that are not yet in `tracked_companies`, but results might be outdated. After filtering out hits from companies in `local_parser_ok`, the remaining results are deduplicated with Levels 0–2.
|
||||
|
||||
**Execution Priority:**
|
||||
1. Level 0: Local Parser → companies with a configured `parser:` and existing script; build `local_parser_ok`
|
||||
2. Level 1: Playwright → `tracked_companies` with a `careers_url`, **except** `local_parser_ok`
|
||||
3. Level 2: API → `tracked_companies` with an `api:`, **except** `local_parser_ok`
|
||||
4. Level 3: WebSearch → all `search_queries` with `enabled: true`; discard hits from companies in `local_parser_ok`
|
||||
|
||||
Levels are additive — they are executed in order, and results are merged and deduplicated. Companies in `local_parser_ok` **do not** go through Levels 1 or 2; in Level 3, they only contribute transversal discovery (other companies on the same portal).
|
||||
|
||||
## Workflow
|
||||
|
||||
1. **Read Configuration**: `portals.yml`
|
||||
2. **Read History**: `data/scan-history.tsv` → already seen URLs
|
||||
3. **Read Dedup Sources**: `data/applications.md` + `data/pipeline.md`
|
||||
|
||||
3.5. **Level 0 — Local Parser** (`scan.mjs`, zero-token):
|
||||
Initialize `local_parser_ok = []`.
|
||||
Prefer running `node scan.mjs` once to cover all zero-token local parsers + APIs; if executing manually, repeat the following logic.
|
||||
For each company in `tracked_companies` with `enabled: true`, `parser.command`, and an existing script:
|
||||
a. Execute `parser.command` with `parser.script` + `parser.args` using local process execution without shell.
|
||||
b. Expand `{careers_url}` and `{company}` placeholders in arguments.
|
||||
c. Read JSON from stdout (`[]`, `{ jobs: [] }`, or `{ results: [] }`).
|
||||
d. Normalize each job to `{title, url, company, location}`.
|
||||
e. Resolve relative URLs against `careers_url`.
|
||||
f. If the parser fails, log the error, attempt fallback via the ATS API if it exists, and continue with the other companies (**do not** add to `local_parser_ok`).
|
||||
g. If the parser completes successfully (steps c–e without fatal error), add `entry.name` to `local_parser_ok` and accumulate jobs in candidates.
|
||||
|
||||
4. **Level 1 — Playwright Scan** (parallel in batches of 3-5):
|
||||
For each company in `tracked_companies` with `enabled: true`, a defined `careers_url`, and a **name not listed in `local_parser_ok`**:
|
||||
a. `browser_navigate` to `careers_url`.
|
||||
b. `browser_snapshot` to read all job listings.
|
||||
c. If the page has filters/departments, navigate the relevant sections.
|
||||
d. For each job listing, extract: `{title, url, company}`.
|
||||
e. If the page has pagination, navigate subsequent pages.
|
||||
f. Accumulate in the candidates list.
|
||||
g. If `careers_url` fails (404, redirect), attempt `scan_query` as a fallback and note it to update the URL later.
|
||||
|
||||
5. **Level 2 — ATS APIs / Feeds** (parallel):
|
||||
For each company in `tracked_companies` with a defined `api:`, `enabled: true`, and a **name not listed in `local_parser_ok`**:
|
||||
a. WebFetch the API/feed URL.
|
||||
b. If `api_provider` is defined, use its parser; if undefined, infer by domain (`boards-api.greenhouse.io`, `jobs.ashbyhq.com`, `api.lever.co`, `*.bamboohr.com`, `*.teamtailor.com`, `*.myworkdayjobs.com`, `*.breezy.hr`).
|
||||
c. For **Ashby**, send a POST request with:
|
||||
- `operationName: ApiJobBoardWithTeams`
|
||||
- `variables.organizationHostedJobsPageName: {company}`
|
||||
- GraphQL query of `jobBoardWithTeams` + `jobPostings { id title locationName employmentType compensationTierSummary }`
|
||||
d. For **BambooHR**, the list only returns basic metadata. For each relevant item, retrieve the `id`, make a GET request to `https://{company}.bamboohr.com/careers/{id}/detail`, and extract the full JD from `result.jobOpening`. Use `jobOpeningShareUrl` as the public URL if present; otherwise, use the detail URL.
|
||||
e. For **Workday**, send a JSON POST request with at least `{"appliedFacets":{},"limit":20,"offset":0,"searchText":""}` and paginate by `offset` until results are exhausted.
|
||||
f. For each job, extract and normalize: `{title, url, company}`.
|
||||
g. Accumulate in the candidates list (deduplicated against Level 1).
|
||||
|
||||
6. **Level 3 — WebSearch Queries** (parallel if possible):
|
||||
For each query in `search_queries` with `enabled: true` (general queries by portal/role — not dedicated queries for a company with an active local parser):
|
||||
a. Execute WebSearch with the defined `query`.
|
||||
b. From each result, extract: `{title, url, company}`.
|
||||
- **title**: from the result title (before " @ " or " | ")
|
||||
- **url**: URL of the result
|
||||
- **company**: after " @ " in the title, or extract from the domain/path
|
||||
c. **Skip** the result if the normalized `company` matches any name in `local_parser_ok`.
|
||||
d. Accumulate the rest in the candidates list (deduplicated against Levels 0+1+2).
|
||||
|
||||
6. **Filter by Title** using `title_filter` from `portals.yml`:
|
||||
- At least 1 keyword from `positive` must appear in the title (case-insensitive).
|
||||
- 0 keywords from `negative` must appear.
|
||||
- `seniority_boost` keywords give priority but are not mandatory.
|
||||
|
||||
6b. **Filter by Location (Optional)** using `location_filter` from `portals.yml`:
|
||||
- If the `location_filter` block is absent, all locations pass (default behavior).
|
||||
- Empty location on a posting → passes (do not penalize missing data).
|
||||
- Any keyword from `block` present → reject (precedes allow).
|
||||
- Empty `allow` → passes (already cleared block).
|
||||
- Non-empty `allow` → must match at least one keyword.
|
||||
- All matches are case-insensitive substring matches.
|
||||
- The location is persisted as the 7th column in `scan-history.tsv` for later auditing.
|
||||
|
||||
7. **Deduplicate** against 3 sources:
|
||||
- `scan-history.tsv` → exact URL already seen
|
||||
- `applications.md` → normalized company + role already evaluated
|
||||
- `pipeline.md` → exact URL already in pending or processed list
|
||||
|
||||
7.5. **Verify Liveness of WebSearch Results (Level 3)** — BEFORE adding to pipeline:
|
||||
|
||||
WebSearch results can be outdated (Google caches results for weeks or months). To avoid evaluating expired offers, verify every new URL coming from Level 3 using Playwright. Levels 1 and 2 are inherently real-time and do not require this verification.
|
||||
|
||||
For each new Level 3 URL (sequential — NEVER parallel Playwright):
|
||||
a. `browser_navigate` to the URL.
|
||||
b. `browser_snapshot` to read the content.
|
||||
c. Classify:
|
||||
- **Active**: visible job title + role description + visible Apply/Submit/Apply Now control inside the main content area. Do not count generic header/navbar/footer text.
|
||||
- **Expired** (any of these signals):
|
||||
- Final URL contains `?error=true` (Greenhouse redirects here when an offer is closed).
|
||||
- Page contains: "job no longer available" / "no longer open" / "position has been filled" / "this job has expired" / "page not found".
|
||||
- Only navbar and footer are visible, with no JD content (content < ~300 characters).
|
||||
d. If expired: record in `scan-history.tsv` with status `skipped_expired` and discard.
|
||||
e. If active: continue to step 8.
|
||||
|
||||
**Do not interrupt the entire scan if a single URL fails.** If `browser_navigate` errors (timeout, 403, etc.), mark as `skipped_expired` and continue with the next one.
|
||||
|
||||
8. **For each new verified offer that passes filters**:
|
||||
a. Add to the `pipeline.md` "Pending" section: `- [ ] {url} | {company} | {title}`
|
||||
b. Record in `scan-history.tsv`: `{url}\t{date}\t{query_name}\t{title}\t{company}\tadded`
|
||||
|
||||
9. **Offers filtered by title**: record in `scan-history.tsv` with status `skipped_title`.
|
||||
10. **Duplicate offers**: record with status `skipped_dup`.
|
||||
11. **Expired offers (Level 3)**: record with status `skipped_expired`.
|
||||
|
||||
## Extraction of Title and Company from WebSearch Results
|
||||
|
||||
WebSearch results typically come in the format: `"Job Title @ Company"`, `"Job Title | Company"`, or `"Job Title — Company"`.
|
||||
|
||||
Extraction patterns by portal:
|
||||
- **Ashby**: `"Senior AI PM (Remote) @ EverAI"` → title: `Senior AI PM`, company: `EverAI`
|
||||
- **Greenhouse**: `"AI Engineer at Anthropic"` → title: `AI Engineer`, company: `Anthropic`
|
||||
- **Lever**: `"Product Manager - AI @ Temporal"` → title: `Product Manager - AI`, company: `Temporal`
|
||||
|
||||
Generic regex: `(.+?)(?:\s*[@|—–-]\s*|\s+at\s+)(.+?)$`
|
||||
|
||||
## Private URLs
|
||||
|
||||
If a non-publicly accessible URL is found:
|
||||
1. Save the JD in `jds/{company}-{role-slug}.md`.
|
||||
2. Add to `pipeline.md` as: `- [ ] local:jds/{company}-{role-slug}.md | {company} | {title}`
|
||||
|
||||
## Scan History
|
||||
|
||||
`data/scan-history.tsv` tracks ALL seen URLs:
|
||||
|
||||
```tsv
|
||||
url first_seen portal title company status
|
||||
https://... 2026-02-10 Ashby — AI PM PM AI Acme added
|
||||
```
|
||||
|
||||
## Output Summary
|
||||
|
||||
```text
|
||||
Portal Scan — {YYYY-MM-DD}
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
Queries executed: N
|
||||
Offers found: N total
|
||||
Filtered by title: N relevant
|
||||
Duplicates: N (already evaluated or in pipeline)
|
||||
Expired discarded: N (dead links, Level 3)
|
||||
New added to pipeline.md: N
|
||||
|
||||
+ {company} | {title} | {query_name}
|
||||
...
|
||||
|
||||
→ Run the `pipeline` mode to evaluate the new offers (`/career-ops pipeline` where available, or ask the agent to run `pipeline`).
|
||||
```
|
||||
|
||||
## Managing careers_url
|
||||
|
||||
Every company in `tracked_companies` must have a `careers_url` — the direct URL to its offers page. This avoids searching for it every time.
|
||||
|
||||
**RULE: Always use the corporate careers URL of the company; fallback to the direct ATS endpoint only if no corporate careers page exists.**
|
||||
|
||||
The `careers_url` should point to the company's own careers page whenever available. Many companies use Workday, Greenhouse, or Lever under the hood, but expose vacancy IDs only through their corporate domain. Using the direct ATS URL when a corporate careers page exists can cause false 410 errors because job IDs do not match.
|
||||
|
||||
| ✅ Correct (corporate) | ❌ Incorrect as first choice (direct ATS) |
|
||||
|---|---|
|
||||
| `https://careers.mastercard.com` | `https://mastercard.wd1.myworkdayjobs.com` |
|
||||
| `https://openai.com/careers` | `https://job-boards.greenhouse.io/openai` |
|
||||
| `https://stripe.com/jobs` | `https://jobs.lever.co/stripe` |
|
||||
|
||||
Fallback: if you only have the direct ATS URL, navigate first to the company's website and locate their corporate careers page. Use the direct ATS URL only if the company does not have its own corporate careers page.
|
||||
|
||||
**Known Patterns by Platform:**
|
||||
- **Ashby:** `https://jobs.ashbyhq.com/{slug}`
|
||||
- **Greenhouse:** `https://job-boards.greenhouse.io/{slug}` or `https://job-boards.eu.greenhouse.io/{slug}`
|
||||
- **Lever:** `https://jobs.lever.co/{slug}`
|
||||
- **BambooHR:** list `https://{company}.bamboohr.com/careers/list`; detail `https://{company}.bamboohr.com/careers/{id}/detail`
|
||||
- **Teamtailor:** `https://{company}.teamtailor.com/jobs`
|
||||
- **Workday:** `https://{company}.{shard}.myworkdayjobs.com/{site}`
|
||||
- **Custom:** The company's own URL (e.g. `https://openai.com/careers`)
|
||||
|
||||
**API/Feed Patterns by Platform:**
|
||||
- **Ashby API:** `https://jobs.ashbyhq.com/api/non-user-graphql?op=ApiJobBoardWithTeams`
|
||||
- **BambooHR API:** list `https://{company}.bamboohr.com/careers/list`; detail `https://{company}.bamboohr.com/careers/{id}/detail` (`result.jobOpening`)
|
||||
- **Lever API:** `https://api.lever.co/v0/postings/{company}?mode=json`
|
||||
- **Teamtailor RSS:** `https://{company}.teamtailor.com/jobs.rss`
|
||||
- **Workday API:** `https://{company}.{shard}.myworkdayjobs.com/wday/cxs/{company}/{site}/jobs`
|
||||
|
||||
**If `careers_url` does not exist** for a company:
|
||||
1. Attempt the pattern of its known platform.
|
||||
2. If it fails, do a quick WebSearch: `"{company}" careers jobs`.
|
||||
3. Navigate with Playwright to confirm it works.
|
||||
4. **Save the found URL in portals.yml** for future scans.
|
||||
|
||||
**If `careers_url` returns 404 or redirect:**
|
||||
1. Note it in the output summary.
|
||||
2. Attempt `scan_query` as a fallback.
|
||||
3. Mark it for manual update.
|
||||
|
||||
## Maintenance of portals.yml
|
||||
|
||||
- **ALWAYS save `careers_url`** when adding a new company.
|
||||
- Add new queries as interesting portals or roles are discovered.
|
||||
- Deactivate noisy queries with `enabled: false`.
|
||||
- Adjust filter keywords as target roles evolve.
|
||||
- Add companies to `tracked_companies` when you want to follow them closely.
|
||||
- Verify `careers_url` periodically — companies change ATS platforms.
|
||||
@@ -0,0 +1,118 @@
|
||||
# career-ops — Türkçe Modlar (`modes/tr/`)
|
||||
|
||||
Bu klasör, Türkiye iş piyasasında iş arayanlar veya Türkçe ilanlarla çalışanlar için career-ops modlarının Türkçe çevirilerini içerir.
|
||||
|
||||
## Ne Zaman Kullanılır?
|
||||
|
||||
Aşağıdaki koşullardan en az biri geçerliyse `modes/tr/` kullan:
|
||||
|
||||
- Ağırlıklı olarak **Türkçe iş ilanlarına** başvuruyorsun (Kariyer.net, Yenibiris.com, Secretcv.com, LinkedIn TR)
|
||||
- **CV dilinin** Türkçe olmasını veya ilana göre TR/EN arasında geçiş yapmayı istiyorsun
|
||||
- **Doğal Türkçe** yanıtlar ve ön yazılar gerekiyor — makine çevirisi değil
|
||||
- **Türkiye'ye özgü sözleşme maddeleriyle** uğraşman gerekiyor: kıdem tazminatı, ihbar süresi, SGK, net/brüt maaş farkı, yemek kartı, TÜFE zammı
|
||||
|
||||
İlanların çoğu İngilizce ise standart `modes/` klasörünü kullanmaya devam et.
|
||||
|
||||
## Nasıl Etkinleştirilir?
|
||||
|
||||
### Yol 1 — Oturum bazında, komutla
|
||||
|
||||
Oturumun başında Claude'a açıkça söyle:
|
||||
|
||||
> "Bundan sonra `modes/tr/` altındaki Türkçe modları kullan."
|
||||
|
||||
veya
|
||||
|
||||
> "Değerlendirme ve başvuruları Türkçe yap — `modes/tr/_shared.md` ve `modes/tr/is-ilani.md` kullan."
|
||||
|
||||
### Yol 2 — Kalıcı olarak, profil üzerinden
|
||||
|
||||
`config/profile.yml` dosyasına dil tercihini ekle:
|
||||
|
||||
```yaml
|
||||
language:
|
||||
primary: tr
|
||||
modes_dir: modes/tr
|
||||
```
|
||||
|
||||
Ardından ilk oturumda Claude'a bu ayarı hatırlat ("profile.yml'e baktım, `language.modes_dir` ayarlanmış"). Bundan sonra Claude otomatik olarak Türkçe modları kullanır.
|
||||
|
||||
## Mevcut Modlar
|
||||
|
||||
| Dosya | Kaynak | Amaç |
|
||||
|-------|--------|------|
|
||||
| `_shared.md` | `modes/_shared.md` (EN) | Paylaşılan bağlam, arketipler, global kurallar, Türkiye piyasa özelinde terimler |
|
||||
| `is-ilani.md` | `modes/oferta.md` (ES) | Tek bir ilanın tam değerlendirmesi (Bloklar A-G) |
|
||||
| `basvuru.md` | `modes/apply.md` (EN) | Başvuru formu için canlı asistan |
|
||||
| `pipeline.md` | `modes/pipeline.md` (ES) | URL gelen kutusu / biriktirilmiş ilanlar için ikinci beyin |
|
||||
|
||||
Diğer modlar (`scan`, `batch`, `pdf`, `tracker`, `auto-pipeline`, `deep`, `contacto`, `ofertas`, `project`, `training`) İngilizce/İspanyolca orijinalleriyle çalışmaya devam eder — içerikleri büyük ölçüde araç komutları, dosya yolları ve yapılandırma talimatlarından oluştuğundan dilden bağımsız kalmaları tercih edilmiştir.
|
||||
|
||||
## Türkiye'ye Özgü Piyasa Kapsamı
|
||||
|
||||
`_shared.md` dosyası aşağıdaki Türkiye'ye özgü kavramları kapsar:
|
||||
|
||||
- **SGK** — Sosyal güvenlik primleri ve brüt/net maaş hesabı
|
||||
- **Kıdem tazminatı** — Her hizmet yılı için yasal tazminat
|
||||
- **İhbar süresi** — Kanuni bildirim süreleri (2-8 hafta, kıdeme göre)
|
||||
- **Deneme süresi** — Yasal maksimum 2 ay
|
||||
- **Yıllık izin** — Kıdeme göre 14-26 gün yasal minimum
|
||||
- **Prim/Bonus** — Performans primleri
|
||||
- **Yemek kartı** — Ticket Restaurant, Sodexo, Multinet gibi kartlar
|
||||
- **Özel sağlık sigortası** — SGK'ya ek sigorta (premium yan hak)
|
||||
- **Servis** — İşveren ulaşımı
|
||||
- **TÜFE zammı** — Enflasyona endeksli yıllık zam
|
||||
- **İş Kanunu No. 4857** — Temel iş kanunu referansı
|
||||
|
||||
## Türkçe Olmayan Terimler
|
||||
|
||||
Kasıtlı olarak çevrilmedi — standart teknik kelime dağarcığı:
|
||||
|
||||
- `cv.md`, `pipeline`, `tracker`, `report`, `score`, `archetype`, `proof point`
|
||||
- Araç adları (`Playwright`, `WebSearch`, `WebFetch`, `Read`, `Write`, `Edit`, `Bash`)
|
||||
- Takipçideki durum değerleri (`Evaluated`, `Applied`, `Interview`, `Offer`, `Rejected`)
|
||||
- Kod parçacıkları, dosya yolları, komutlar
|
||||
|
||||
Modlar, İstanbul ve Ankara'daki gerçek mühendislik ekiplerinde konuşulduğu gibi Türkçe teknik dil kullanır: Türkçe akıcı metin, yaygın kullanımda yerleşmiş İngilizce teknik terimler. "Pipeline" kelimesinin zorla "boru hattı"na çevrilmesi gibi uygulamalardan kaçınılmıştır.
|
||||
|
||||
## Kelime Kılavuzu
|
||||
|
||||
Modları özelleştirirken veya genişletirken bu kelime dağarcığına uy — tutarlı bir ton sağlar:
|
||||
|
||||
| İngilizce | Türkçe (bu kod tabanında) |
|
||||
|-----------|--------------------------|
|
||||
| Job posting | İş ilanı |
|
||||
| Application | Başvuru |
|
||||
| Cover letter | Ön yazı |
|
||||
| Resume / CV | Özgeçmiş |
|
||||
| Salary | Maaş / Ücret |
|
||||
| Compensation | Tazminat |
|
||||
| Skills | Beceriler |
|
||||
| Interview | Mülakat |
|
||||
| Hiring manager | İşe alım yöneticisi / Hiring Manager |
|
||||
| Recruiter | İK uzmanı / Recruiter |
|
||||
| Requirements | Gereksinimler |
|
||||
| Career history | İş deneyimi |
|
||||
| Notice period | İhbar süresi |
|
||||
| Probation | Deneme süresi |
|
||||
| Annual leave | Yıllık izin |
|
||||
| Severance pay | Kıdem tazminatı |
|
||||
| Gross / Net salary | Brüt / Net maaş |
|
||||
| Social security | SGK |
|
||||
| Permanent employment | Belirsiz süreli sözleşme |
|
||||
| Fixed-term employment | Belirli süreli sözleşme |
|
||||
| Remote / Hybrid | Uzaktan / Hibrit |
|
||||
| Meal card | Yemek kartı |
|
||||
| Private health insurance | Özel sağlık sigortası |
|
||||
| Company shuttle | Servis |
|
||||
| Inflation adjustment | TÜFE zammı / Enflasyon zammı |
|
||||
|
||||
## Katkı
|
||||
|
||||
Bir çeviriyi iyileştirmek veya başka bir modu Türkçeleştirmek istersen:
|
||||
|
||||
1. `CONTRIBUTING.md`'ye göre bir Issue aç
|
||||
2. Yukarıdaki kelime kılavuzuna uy — tutarlı ton için
|
||||
3. Kelimesi kelimesine çeviri değil, anlam ve deyim bakımından doğal çeviri yap
|
||||
4. Yapısal öğeleri (Blok A-G, tablolar, kod blokları, araç talimatları) aynen koru
|
||||
5. PR açmadan önce gerçek bir Türkçe ilan (Kariyer.net veya Yenibiris.com) üzerinde test et
|
||||
@@ -0,0 +1,276 @@
|
||||
# Ortak Bağlam -- career-ops (Türkçe)
|
||||
|
||||
<!-- ============================================================
|
||||
BU DOSYA OTOMATİK GÜNCELLENEBİLİR. Buraya kişisel veri ekleme.
|
||||
|
||||
Özelleştirmeler modes/_profile.md dosyasına gider (hiçbir zaman
|
||||
otomatik güncellenmez). Bu dosya sistem kurallarını, puanlama
|
||||
mantığını ve her sürümde gelişen araç yapılandırmasını içerir.
|
||||
============================================================ -->
|
||||
|
||||
## Temel Kaynaklar (Her değerlendirmeden önce MUTLAKA okunacak)
|
||||
|
||||
| Dosya | Konum | Ne zaman |
|
||||
|-------|-------|----------|
|
||||
| cv.md | `cv.md` (proje kök dizini) | Her zaman |
|
||||
| article-digest.md | `article-digest.md` (varsa) | Her zaman — ayrıntılı kanıtlar |
|
||||
| profile.yml | `config/profile.yml` | Her zaman — kişisel bilgiler ve hedef roller |
|
||||
| _profile.md | `modes/_profile.md` | Her zaman — kullanıcı arketipleri, anlatı, müzakere |
|
||||
|
||||
**KURAL: Kanıt noktalarındaki ölçüm değerlerini ASLA sabit kodlama.** Değerlendirme sırasında bunları cv.md + article-digest.md dosyalarından oku.
|
||||
**KURAL: Makale/proje metrikleri için `article-digest.md`, `cv.md`'ye göre önceliklidir.**
|
||||
**KURAL: `_profile.md`'yi bu dosyadan SONRA oku. Kullanıcının `_profile.md`'deki özelleştirmeleri buradaki varsayılanları geçersiz kılar.**
|
||||
|
||||
---
|
||||
|
||||
## Puanlama Sistemi
|
||||
|
||||
Değerlendirme 6 blok (A-F) üzerinden yapılır ve 1-5 arası global bir puan verilir:
|
||||
|
||||
| Boyut | Ne ölçülüyor |
|
||||
|-------|-------------|
|
||||
| CV Eşleşmesi | Beceriler, deneyim ve kanıt noktalarının örtüşmesi |
|
||||
| North Star Uyumu | Rolün hedef arketiplerle uyumu (`_profile.md`'den) |
|
||||
| Ücret | Teklifin piyasa konumu (5=üst çeyrek, 1=çok altında) |
|
||||
| Kültürel Sinyaller | Şirket kültürü, büyüme, istikrar, uzaktan çalışma politikası |
|
||||
| Kırmızı Bayraklar | Engelleyiciler ve uyarılar (negatif düzeltme) |
|
||||
| **Global** | Yukarıdakilerin ağırlıklı ortalaması |
|
||||
|
||||
**Puan yorumu:**
|
||||
- 4,5+ → Güçlü eşleşme, hemen başvur
|
||||
- 4,0-4,4 → İyi eşleşme, başvurmaya değer
|
||||
- 3,5-3,9 → Kabul edilebilir ama ideal değil; özel bir neden olmadıkça geç
|
||||
- 3,5'in altı → Başvuru önerilmez (CLAUDE.md'deki Etik Kullanım bölümüne bakın)
|
||||
|
||||
## İlan Meşruiyeti (Blok G)
|
||||
|
||||
Blok G, ilanın gerçek ve aktif bir açık pozisyon olup olmadığını değerlendirir. 1-5 global puanı **etkilemez** — ayrı bir nitel tespittir.
|
||||
|
||||
**Üç seviye:**
|
||||
- **Güvenilir** — Gerçek, aktif ilan; sinyallerin büyük çoğunluğu olumlu
|
||||
- **Dikkatli İlerle** — Karma sinyaller; bazı endişe noktaları mevcut
|
||||
- **Şüpheli** — Birden fazla hayalet ilan göstergesi var; kullanıcı önce araştırmalı
|
||||
|
||||
**Temel sinyaller (güvenilirlik ağırlığına göre):**
|
||||
|
||||
| Sinyal | Kaynak | Güvenilirlik | Notlar |
|
||||
|--------|--------|-------------|--------|
|
||||
| İlan yaşı | Sayfa snapshot | Yüksek | 30 gün altı = iyi, 30-60 gün = karma, 60+ gün = endişe verici (rol tipine göre ayarla) |
|
||||
| Başvur butonu aktif mi | Sayfa snapshot | Yüksek | Doğrudan gözlemlenebilir gerçek |
|
||||
| İlanda teknik özgüllük | İlan metni | Orta | Genel ilanlar hayalet ilanla örtüşür ama zayıf yazarlıkla da açıklanabilir |
|
||||
| Gereksinimlerin gerçekçiliği | İlan metni | Orta | Çelişkiler güçlü sinyal; muğlaklık daha zayıf |
|
||||
| Son dönem işten çıkarma haberleri | WebSearch | Orta | Departman, zamanlama ve şirket büyüklüğü dikkate alınmalı |
|
||||
| Yeniden yayın örüntüsü | scan-history.tsv | Orta | 90 günde 2+ kez aynı rol endişe verici |
|
||||
| Maaş şeffaflığı | İlan metni | Düşük | Yargı bölgesine bağlı; atlanması için birçok meşru neden olabilir |
|
||||
| Rol-şirket uyumu | Nitel | Düşük | Öznel; yalnızca destekleyici sinyal olarak kullan |
|
||||
|
||||
**Etik çerçeve (ZORUNLU):**
|
||||
- Bu, kullanıcının zamanını gerçek fırsatlara yönlendirmesine yardımcı olur
|
||||
- Bulguları asla dürüstsüzlük suçlaması olarak sunma
|
||||
- Sinyalleri sun ve kararı kullanıcıya bırak
|
||||
- Endişe veren sinyaller için her zaman meşru açıklamalara yer ver
|
||||
|
||||
---
|
||||
|
||||
## North Star — Hedef Roller
|
||||
|
||||
Sistem tüm hedef rollere eşit özenle yaklaşır. Maaş ve gelişim fırsatı uygunsa her biri başarıdır:
|
||||
|
||||
| Arketip | Odak alanları | İşverenin aradığı |
|
||||
|---------|--------------|-------------------|
|
||||
| **AI Platform / LLMOps Engineer** | Değerlendirme, gözlemlenebilirlik, güvenilirlik, pipeline'lar | Yapay zekayı metriklerle production'a taşıyan biri |
|
||||
| **Agentic Workflows / Automation** | HITL, tooling, orchestration, multi-agent | Güvenilir ajan sistemleri kuran biri |
|
||||
| **Technical AI Product Manager** | GenAI/Agents, PRD, discovery, delivery | İş gereksinimlerini AI ürününe çeviren biri |
|
||||
| **AI Solutions Architect** | Hyperautomation, enterprise, entegrasyonlar | Uçtan uca AI mimarileri tasarlayan biri |
|
||||
| **AI Forward Deployed Engineer** | Müşteri yönlü, hızlı teslimat, prototipleme | AI çözümlerini müşteride hızlıca hayata geçiren biri |
|
||||
| **AI Transformation Lead** | Değişim yönetimi, benimseme, kurumsal enablement | Organizasyonlarda AI dönüşümünü yöneten biri |
|
||||
|
||||
|
||||
### Arketip Tespiti
|
||||
|
||||
Her ilanı aşağıdaki türlerden birine (ya da en fazla ikisine) sınıflandır:
|
||||
|
||||
| Arketip | İlanda öne çıkan sinyaller |
|
||||
|---------|---------------------------|
|
||||
| AI Platform / LLMOps | "observability", "evals", "pipelines", "monitoring", "reliability" |
|
||||
| Agentic / Automation | "agent", "HITL", "orchestration", "workflow", "multi-agent" |
|
||||
| Technical AI PM | "PRD", "roadmap", "discovery", "stakeholder", "product manager" |
|
||||
| AI Solutions Architect | "architecture", "enterprise", "integration", "design", "systems" |
|
||||
| AI Forward Deployed | "client-facing", "deploy", "prototype", "fast delivery", "field" |
|
||||
| AI Transformation | "change management", "adoption", "enablement", "transformation" |
|
||||
|
||||
Arketipi tespit ettikten sonra kullanıcıya özgü çerçeveleme ve kanıt noktaları için `modes/_profile.md` dosyasını oku.
|
||||
|
||||
### Arketipe Göre Uyarlama
|
||||
|
||||
> **Somut rakamlar ve metrikler: değerlendirme sırasında `cv.md` ve `article-digest.md` dosyalarından okunacak. Buraya sabit yazma.**
|
||||
|
||||
|
||||
| Rol ise... | Adayda şunu öne çıkar... | Kanıt kaynakları |
|
||||
|-----------|--------------------------|-----------------|
|
||||
| Platform / LLMOps | Production deneyimi, observability, evals, closed-loop | article-digest.md + cv.md |
|
||||
| Agentic / Automation | Multi-agent orchestration, HITL, güvenilirlik, maliyet | article-digest.md + cv.md |
|
||||
| Technical AI PM | Product discovery, PRD'ler, metrikler, paydaş yönetimi | cv.md + article-digest.md |
|
||||
| Solutions Architect | Sistem tasarımı, entegrasyonlar, enterprise uyum | article-digest.md + cv.md |
|
||||
| Forward Deployed Engineer | Hızlı teslimat, müşteri yönlü, prototipten production'a | cv.md + article-digest.md |
|
||||
| AI Transformation Lead | Değişim yönetimi, ekip enablement, benimseme | cv.md + article-digest.md |
|
||||
|
||||
### Kariyer Anlatısı (Tüm içeriklerde kullanılacak)
|
||||
|
||||
|
||||
`config/profile.yml` dosyasındaki kariyer hikayesini tüm içeriklere zemin olarak kullan:
|
||||
- **PDF özetlerinde:** Geçmişten geleceğe bir köprü kur — "Aynı [becerileri] şimdi [ilan alanına] uyguluyorum."
|
||||
- **STAR hikayelerinde:** `article-digest.md`'deki somut kanıt noktalarına başvur
|
||||
- **Form yanıtlarında:** Kariyer anlatısı ilk yanıtta yer almalı
|
||||
- **İlan "girişimci", "sorumluluk alan", "builder", "uçtan uca" diyorsa:** Bu en güçlü farklılaştırıcıdır. Eşleşme ağırlığını artır.
|
||||
|
||||
### Temel Güç
|
||||
|
||||
|
||||
Profili **"Gerçek dünya kanıtına sahip teknik builder"** olarak çerçevele — role göre uyarla:
|
||||
- PM için: "Prototiplerle belirsizliği azaltıp sonra disiplinli biçimde üretime taşıyan builder"
|
||||
- FDE için: "İlk günden observability ve metriklerle teslim eden builder"
|
||||
- SA için: "Gerçek entegrasyon deneyimiyle uçtan uca sistemler tasarlayan builder"
|
||||
- LLMOps için: "Kapalı döngü kalite sistemleriyle yapay zekayı production'a taşıyan builder"
|
||||
|
||||
"Builder"ı profesyonel bir sinyal olarak konumlandır — hobici değil. Gerçek kanıt noktaları bunu inandırıcı kılar.
|
||||
|
||||
### Portfolyo / Demo
|
||||
|
||||
|
||||
Adayın canlı bir demosu veya dashboardu varsa (`profile.yml`'ye bak), ilgili başvurularda erişim bilgisini paylaş.
|
||||
|
||||
### Ücret Araştırması
|
||||
|
||||
|
||||
**Genel notlar:**
|
||||
- Güncel piyasa verisi için WebSearch kullan (Kariyer.net Maaş Rehberi, Glassdoor TR, LinkedIn Maaş, Secretcv.com)
|
||||
- Rolün başlığı üzerinden karşılaştır — başlıklar maaş bantlarını belirler
|
||||
- Türkiye'de maaşlar genellikle **net** olarak belirtilir; brüt/net farkı yaklaşık %25-30'dur
|
||||
- Enflasyon zammı beklentisini müzakere kozu olarak kullan
|
||||
|
||||
---
|
||||
|
||||
## Türkiye İş Piyasası — Bilmen Gereken Terimler
|
||||
|
||||
Türkçe iş ilanlarında ve sözleşme müzakerelerinde, yabancı piyasalarda karşılığı olmayan kavramlar çıkar. Bunları doğru yorumlamak kritiktir:
|
||||
|
||||
| Terim | Açıklama | Değerlendirmeye etkisi |
|
||||
|-------|----------|------------------------|
|
||||
| **SGK** (Sosyal Güvenlik Kurumu) | Zorunlu sosyal güvenlik. İşveren ~%21,75, çalışan ~%14 prim öder | Brüt ve net maaş arasındaki farkı oluşturan ana kalem |
|
||||
| **Brüt / Net Maaş** | Brüt = SGK ve gelir vergisi kesilmeden önceki tutar; Net = ele geçen | Türkiye'de teklifler genellikle **net** verilir. Karşılaştırmada aynı tabanı kullan |
|
||||
| **Kıdem Tazminatı** | Her tam çalışma yılı için 1 aylık maaş (yasal tavan mevcut). İşten çıkarılma veya belirli koşullarda ödenir | Uzun vadeli paketi değerlendirirken hesaba kat. Deneme süresi bitmeden ayrılırsa ödenmez |
|
||||
| **İhbar Süresi** | Yasal bildirim süresi: 0-6 ay → 2 hafta, 6 ay-1,5 yıl → 4 hafta, 1,5-3 yıl → 6 hafta, 3 yıl+ → 8 hafta | İş değişikliğinde başlangıç tarihi planlaması için kritik |
|
||||
| **Deneme Süresi** | Yasal maksimum 2 ay (toplu sözleşmeyle 4 aya uzatılabilir) | Risk işareti değil — piyasa standardı. 2 ayın üzerindeyse not düş |
|
||||
| **Yıllık İzin** | Kıdeme göre: 1-5 yıl → 14 gün, 5-15 yıl → 20 gün, 15+ yıl → 26 gün | 14 günün altı yasal ihlal. 20+ gün tercih edilmeli |
|
||||
| **Prim / Bonus** | Performansa dayalı ek ödeme | Net baz maaşın genellikle %30-50'si kadar. Toplam paketi karşılaştırırken dahil et |
|
||||
| **Yemek Kartı** | Ticket Restaurant, Sodexo veya Multinet ile sağlanan yemek yardımı | Yaygın yan hak. Aylık 5.000–7.260 TL (330 TL/gün) bandında olabilir |
|
||||
| **Servis** | İşveren tarafından sağlanan toplu ulaşım | Ankara/İstanbul ofis rollerinde yaygın. Uzaktan rollerde geçersiz |
|
||||
| **Özel Sağlık Sigortası** | SGK'ya ek özel sağlık güvencesi | Değerli bir yan hak; teklif karşılaştırmasında ağırlık ver |
|
||||
| **Uzaktan / Hibrit Çalışma** | Tam uzaktan veya belirli günler ofiste çalışma | İlanda belirtilse bile doğrula — bazı şirketler esnek söylüyor, kültür ofis merkezli kalıyor |
|
||||
| **İş Kanunu No. 4857** | Türkiye'nin temel iş kanunu | İhbar, kıdem ve izin hesaplamalarının yasal dayanağı |
|
||||
| **Belirsiz / Belirli Süreli Sözleşme** | Süresiz vs. sabit vadeli iş sözleşmesi | Belirli süreli → sözleşme bitiminde kıdem tazminatı riski taşıyabilir |
|
||||
| **TÜFE Zammı** | Yıllık enflasyon (TÜFE) oranına dayalı maaş artışı | Türkiye'de kritik: zam garantisi yoksa yüksek enflasyon dönemlerinde gerçek ücret erir |
|
||||
| **AGİ** (Asgari Geçim İndirimi) | 2022'de kaldırıldı, yerini asgari ücrete kadar gelir vergisi muafiyeti aldı | Sözleşme müzakerelerinde ayrıca gündemin dışında tutulabilir |
|
||||
|
||||
### Maaş Müzakere Kalıpları
|
||||
|
||||
|
||||
**Maaş beklentisi:**
|
||||
> "Bu rol için piyasa araştırmama göre [profile.yml'deki ARALIK] aralığını hedefliyorum. Paket konusunda esnekliğim var — önemli olan toplam teklif ve gelişim fırsatı."
|
||||
|
||||
**Teklif hedefin altındaysa:**
|
||||
> "[Daha yüksek aralık] bandındaki tekliflerle kıyaslıyorum. [Şirket] beni çekiyor çünkü [neden]. [Hedef rakama] ulaşma şansımız var mı?"
|
||||
|
||||
**Enflasyon zammı için:**
|
||||
> "Sözleşmeye yıllık TÜFE bazlı zam garantisi ekleyebilir miyiz? Uzun vadeli planlama açısından önemli."
|
||||
|
||||
### Lokasyon Politikası
|
||||
|
||||
|
||||
**Formlarda:**
|
||||
- "Ofise gelebilir misiniz?" sorularını `profile.yml`'deki gerçek duruma göre yanıtla
|
||||
- Serbest metin alanlarında saat dilimi örtüşmesini ve müsaitliği açıkça yaz
|
||||
|
||||
**Değerlendirmelerde (puanlama):**
|
||||
- Uzaktan rol → lokasyon boyutunda tam puan
|
||||
- Adayın ülkesi dışında hibrit rol → **3.0** (1.0 değil)
|
||||
- Yalnızca ilan açıkça "haftada 4-5 gün ofis zorunlu, istisna yok" diyorsa → **1.0**
|
||||
|
||||
### Teklif Hızı Önceliği
|
||||
|
||||
- Çalışan demo + metrikler > mükemmellik
|
||||
- Erken başvur > daha fazla araştır
|
||||
- %80/20 yaklaşımı, her şeyi zamanlı tut
|
||||
|
||||
---
|
||||
|
||||
## Genel Kurallar
|
||||
|
||||
### ASLA
|
||||
|
||||
1. Deneyim veya metrik uydurma
|
||||
2. `cv.md` ya da portfolyo dosyalarını değiştirme
|
||||
3. Adayın onayı olmadan başvuru gönderme
|
||||
4. Üretilen mesajlarda telefon numarası paylaşma
|
||||
5. Piyasa fiyatının altında ücret önerme
|
||||
6. İlanı okumadan PDF oluşturma
|
||||
7. Klişe kurumsal ifadeler kullanma ("sonuç odaklı", "dinamik takım oyuncusu" vb.)
|
||||
8. Takipçiyi atlama — değerlendirilen her ilan kaydedilir
|
||||
|
||||
### HER ZAMAN
|
||||
|
||||
0. **Ön yazı:** Form izin veriyorsa HER ZAMAN ön yazı ekle. CV ile aynı görsel tasarımda PDF olarak üret. İçerik: ilandan doğrudan alıntılar + kanıt noktalarıyla eşleştirme. Maksimum 1 sayfa.
|
||||
1. Herhangi bir ilanı değerlendirmeden önce `cv.md` ve `article-digest.md` dosyalarını oku (varsa)
|
||||
1b. **Her oturumun ilk değerlendirmesinde:** `node cv-sync-check.mjs` çalıştır. Uyarı varsa adayı bilgilendirmeden devam etme
|
||||
2. Rol arketipini belirle ve çerçevelemeyi buna göre uyarla
|
||||
3. CV eşleştirmesinde dosyadan tam satır alıntıla
|
||||
4. Maaş ve şirket bilgisi için WebSearch kullan
|
||||
5. Değerlendirmeden sonra takipçiye kaydet
|
||||
6. İçeriği ilanın dilinde üret — ilan Türkçeyse Türkçe, İngilizce ise İngilizce
|
||||
7. Doğrudan ve eyleme dönük ol — gereksiz ayrıntı yazma
|
||||
8. Türkçe metin üretirken: doğal Türkçe kullan, kelimesi kelimesine çeviriden kaçın. Kısa cümleler, aktif fiiller. Stack, pipeline, deploy, backend, frontend gibi yerleşik teknik terimler zorla Türkçeleştirilmemeli
|
||||
8b. **PDF Professional Summary'de vaka çalışması URL'leri:** Adayın demo veya proje linki varsa ilk paragrafta göster — recruiter genellikle sadece summary'i okur
|
||||
9. **Takipçi eklemeleri TSV olarak** — `applications.md`'ye doğrudan yeni satır ekleme. TSV'yi `batch/tracker-additions/` klasörüne yaz, `merge-tracker.mjs` halleder
|
||||
10. Her rapor başlığına `**URL:**` alanını ekle — Puan ile PDF arasına
|
||||
|
||||
### Araçlar
|
||||
|
||||
| Araç | Kullanım |
|
||||
|------|----------|
|
||||
| WebSearch | Maaş araştırması, şirket kültürü, Kariyer.net/LinkedIn ilanları, Türk şirket haberleri |
|
||||
| WebFetch | Statik sayfalardan ilan içeriği çekme |
|
||||
| Playwright | İlan doğrulama (browser_navigate + browser_snapshot). **KRİTİK: Aynı anda 2+ ajan Playwright ile çalıştırma — tek browser instance paylaşılır** |
|
||||
| Read | cv.md, _profile.md, article-digest.md, cv-template.html |
|
||||
| Write | PDF için geçici HTML, rapor .md dosyaları, `batch/tracker-additions/*.tsv` (yeni takipçi girişleri) |
|
||||
| Edit | `data/applications.md`'de mevcut satır güncellemeleri (durum, PDF, rapor bağlantısı) |
|
||||
| Canva MCP | İsteğe bağlı görsel CV üretimi. Temel tasarımı çoğalt, metni düzenle, PDF olarak dışa aktar. `profile.yml`'de `canva_resume_design_id` gerektirir. |
|
||||
| Bash | `node generate-pdf.mjs` |
|
||||
|
||||
---
|
||||
|
||||
## Profesyonel Yazım ve ATS Uyumluluğu
|
||||
|
||||
Bu kurallar adaya giden tüm üretilmiş metinler için geçerlidir: PDF özetleri, maddeler, ön yazılar, form yanıtları, LinkedIn mesajları. Dahili değerlendirme raporları için geçerli **değildir**.
|
||||
|
||||
### Klişe ifadelerden kaçın
|
||||
- "sonuç odaklı" / "takım oyuncusu" / "kanıtlanmış başarı geçmişi"
|
||||
- "leveraged" yerine → kullandığı aracı ya da fiili yaz
|
||||
- "spearheaded" yerine → "yönetti" veya "kurdu"
|
||||
- "facilitated" yerine → "yürüttü" veya "kurdu"
|
||||
- "sinerji" / "güçlü" / "kesintisiz" / "yenilikçi" / "çığır açan"
|
||||
- "günümüzün hızla değişen dünyasında"
|
||||
- "kanıtlanmış yetenek" / "en iyi uygulamalar" → spesifik uygulamayı adlandır
|
||||
|
||||
### ATS için Unicode normalleştirme
|
||||
`generate-pdf.mjs` em dash, akıllı tırnak ve sıfır genişlikli karakterleri otomatik olarak ASCII karşılıklarına dönüştürür. Yine de en başından üretmekten kaçın.
|
||||
|
||||
### Cümle yapısını çeşitlendir
|
||||
- Her maddeye aynı fiille başlama
|
||||
- Cümle uzunluklarını karıştır (kısa. Sonra bağlamlı daha uzun. Kısa.)
|
||||
- Her seferinde "X, Y ve Z" kalıbını kullanma — bazen iki öğe, bazen dört
|
||||
|
||||
### Soyutlamalar yerine özgüllüğü tercih et
|
||||
- "p95 gecikmesini 2,1 saniyeden 380ms'ye düşürdüm" → "performansı iyileştirdim"den çok daha iyi
|
||||
- "12 bin belge üzerinde Postgres + pgvector ile retrieval" → "ölçeklenebilir RAG mimarisi tasarladım"dan çok daha iyi
|
||||
- İzin verilen durumlarda araç, proje ve müşteri adlarını ver
|
||||
@@ -0,0 +1,120 @@
|
||||
# Mod: basvuru — Canlı Başvuru Asistanı
|
||||
|
||||
Aday bir başvuru formunu doldururken çalışan etkileşimli mod. Ekrandakileri okur, önceki ilan raporunu yükler ve formun her alanı için kişiselleştirilmiş yanıtlar üretir.
|
||||
|
||||
## Gereksinimler
|
||||
|
||||
- **Playwright varsa (tercih edilen):** Claude tarayıcıyla etkileşime geçebilir, formu doğrudan okuyabilir.
|
||||
- **Playwright yoksa:** Aday ekran görüntüsü paylaşır veya soruları metin olarak yapıştırır.
|
||||
|
||||
## İş Akışı
|
||||
|
||||
```
|
||||
1. TESPİT ET → Aktif sekmeyi oku (ekran görüntüsü / URL / sayfa başlığı)
|
||||
2. TANI KOY → Sayfadan şirket adını ve rolü çıkar
|
||||
3. RAPORU BUL → reports/ klasöründe bu ilana ait raporu ara
|
||||
4. YÜKLE → Tam raporu oku (önceki değerlendirme + Blok G varsa)
|
||||
5. KARŞILAŞTIR → Ekrandaki rol raporla eşleşiyor mu? Farklıysa adayı uyar
|
||||
6. FORMU ANALİZ ET → Görünen tüm alanları ve soruları tespit et
|
||||
7. YANIT ÜRET → Her alan için kişiselleştirilmiş yanıt oluştur
|
||||
8. SUN → Kopyalanabilir biçimde göster
|
||||
```
|
||||
|
||||
## Adım 1 — İlanı Tespit Et
|
||||
|
||||
**Playwright ile:** Aktif sayfanın snapshot'ını al; başlık, URL ve içeriği oku.
|
||||
|
||||
**Playwright olmadan:** Adaydan şunları iste:
|
||||
- Formun ekran görüntüsünü paylaşması (Read aracı görselleri okuyabilir)
|
||||
- Soruları metin olarak yapıştırması
|
||||
- Şirket adı + rol başlığını söylemesi (ardından `reports/` klasöründe arama yapılır)
|
||||
|
||||
## Adım 2 — Bağlamı Tespit Et ve Yükle
|
||||
|
||||
1. Sayfadan şirket adını ve rol başlığını çıkar
|
||||
2. `reports/` klasöründe şirket adına göre Grep yap (büyük/küçük harf duyarsız)
|
||||
3. Eşleşme bulunursa → tam raporu yükle
|
||||
4. Blok G varsa → önceki taslak yanıtları temel olarak al
|
||||
5. Eşleşme bulunamazsa → adayı bilgilendirip hızlı auto-pipeline öner
|
||||
|
||||
## Adım 3 — Rol Değişikliğini Tespit Et
|
||||
|
||||
Ekrandaki rol önceki değerlendirmedekinden farklıysa:
|
||||
- **Adayı uyar:** "Rol [X]'den [Y]'ye değişmiş görünüyor. Yeniden değerlendireyim mi, yoksa yanıtları yeni başlığa uyarlayayım mı?"
|
||||
- **Uyarlama:** Yeniden değerlendirmeden yanıtları yeni role göre ayarla
|
||||
- **Yeniden değerlendirme:** Tam A-F değerlendirmesi yap, raporu güncelle, Blok G'yi yeniden üret
|
||||
- **Takipçiyi güncelle:** Gerekirse `applications.md`'deki rol başlığını düzelt
|
||||
|
||||
## Adım 4 — Form Alanlarını Analiz Et
|
||||
|
||||
Görünen tüm alanları tespit et:
|
||||
- Serbest metin (ön yazı, "neden bu rol?", motivasyon vb.)
|
||||
- Açılır menüler (nereden duydunuz, çalışma izni vb.)
|
||||
- Evet/Hayır (taşınma, vize, müsaitlik vb.)
|
||||
- Maaş alanları (beklenti, aralık)
|
||||
- Dosya yükleme alanları (CV, ön yazı PDF'i)
|
||||
|
||||
Her soruyu sınıflandır:
|
||||
- **Blok G'de zaten yanıtlanmış** → mevcut yanıtı uyarla
|
||||
- **Yeni soru** → rapor + `cv.md`'den yanıt üret
|
||||
|
||||
## Adım 5 — Yanıtları Üret
|
||||
|
||||
Her soru için yanıtı şu şemaya göre oluştur:
|
||||
|
||||
1. **Rapor bağlamı:** Blok B'deki kanıt noktalarını ve Blok F'teki STAR hikayelerini kullan
|
||||
2. **Önceki Blok G:** Taslak yanıt varsa temel al ve geliştir
|
||||
3. **"Sizi seçiyorum" tonu:** Özgüvenli, yalvaran değil
|
||||
4. **Özgüllük:** Ekrandaki ilandan somut bir şeye doğrudan değin
|
||||
5. **Kanıt URL'si:** "Ek bilgi" alanı varsa demo/proje linkini ekle
|
||||
|
||||
**Türkiye'ye özgü form alanları:**
|
||||
- **Maaş beklentisi (net TL):** `profile.yml`'deki aralık, "paket yapısına göre müzakereye açığım" notu ekle
|
||||
- **Başlangıç tarihi / Müsaitlik:** İhbar süresi gerçekçi biçimde hesaba katılarak tarih ver
|
||||
- **Çalışma izni / Vatandaşlık:** Yabancı uyruklu adaylar için net ve özlü yaz
|
||||
- **Yabancı dil seviyesi:** Gerçek seviyeyi yaz; varsa YDS/YÖKDİL/TOEFL puanını ekle
|
||||
- **Askerlik durumu:** Tamamlandı / tecilli / muaf — kısaca belirt
|
||||
- **Referans:** Önceden haberdar ettiğin kişilerin adını ver; telefon numarası verme
|
||||
|
||||
**Çıktı formatı:**
|
||||
|
||||
```
|
||||
## [Şirket] — [Rol] için Yanıtlar
|
||||
|
||||
Dayanak: Rapor #NNN | Puan: X.X/5 | Arketip: [tür]
|
||||
|
||||
---
|
||||
|
||||
### 1. [Formdaki tam soru metni]
|
||||
> [Kopyalamaya hazır yanıt]
|
||||
|
||||
### 2. [Sonraki soru]
|
||||
> [Yanıt]
|
||||
|
||||
...
|
||||
|
||||
---
|
||||
|
||||
Notlar:
|
||||
- [Rol, değişiklikler vb. hakkında gözlemler]
|
||||
- [Adayın gözden geçirmesi gereken kişiselleştirme önerileri]
|
||||
```
|
||||
|
||||
## Adım 6 — Başvuru Sonrası (isteğe bağlı)
|
||||
|
||||
Aday başvuruyu gönderdiğini onaylarsa:
|
||||
1. `applications.md`'de durumu `Evaluated`'dan `Applied`'a güncelle
|
||||
2. Blok G'yi final yanıtlarla güncelle
|
||||
3. Sonraki adımı öner: İşe alım sorumlusuna LinkedIn erişimi için `/career-ops contacto`
|
||||
|
||||
## Scroll Yönetimi
|
||||
|
||||
Formda görünenden fazla soru varsa:
|
||||
- Adaydan scroll yapıp yeni bir ekran görüntüsü paylaşmasını iste
|
||||
- Ya da kalan soruları yapıştırmasını iste
|
||||
- Formun tamamı kapsanana kadar iterasyon halinde işle
|
||||
|
||||
## Kritik Kural
|
||||
|
||||
**Adayın onayı olmadan hiçbir şeye tıklama, form gönderme.**
|
||||
Doldur, taslak oluştur, hazırla — ama "Gönder" veya "Başvur" düğmesine basmak her zaman adayın kararıdır.
|
||||
@@ -0,0 +1,250 @@
|
||||
# Mod: is-ilani — Tam Değerlendirme A-G
|
||||
|
||||
Aday bir ilan yapıştırdığında (metin veya URL) HER ZAMAN 7 bloğun tamamını sun (A-F değerlendirme + G meşruiyet).
|
||||
|
||||
## Adım 0 — Arketip Tespiti
|
||||
|
||||
İlanı `_shared.md`'deki arketiplerden birine sınıflandır. Hibrit ise en yakın ikisini belirt. Bu tespite göre:
|
||||
- B bloğunda hangi kanıt noktalarını öne çıkaracağın belirlenir
|
||||
- E bloğunda CV özeti nasıl yeniden yazılacağı belirlenir
|
||||
- F bloğunda hangi STAR hikayeleri hazırlanacağı belirlenir
|
||||
|
||||
## Blok A — Rol Özeti
|
||||
|
||||
Şu alanları içeren bir tablo oluştur:
|
||||
- Tespit edilen arketip
|
||||
- Alan (fintech / e-ticaret / kurumsal yazılım / SaaS / oyun / telekom vb.)
|
||||
- İşlev (geliştirme / danışmanlık / yönetim / deployment)
|
||||
- Kıdem seviyesi (junior / mid / senior / staff)
|
||||
- Çalışma şekli (tam uzaktan / hibrit / ofis)
|
||||
- Takım büyüklüğü (ilanda belirtilmişse)
|
||||
- 1 cümlelik TL;DR
|
||||
|
||||
## Blok B — CV Eşleştirmesi
|
||||
|
||||
`cv.md` dosyasını oku. İlandaki her gereksinimi CV'deki tam satırlarla karşılaştıran bir tablo oluştur.
|
||||
|
||||
**Arketipe göre öne çıkarılacaklar:**
|
||||
- FDE → hızlı teslimat ve müşteri yönlü kanıt noktaları
|
||||
- SA → sistem tasarımı ve entegrasyon deneyimi
|
||||
- PM → product discovery ve metrikler
|
||||
- LLMOps → evals, observability, pipeline'lar
|
||||
- Agentic → multi-agent, HITL, orchestration
|
||||
- Transformation → değişim yönetimi, benimseme, ölçekleme
|
||||
|
||||
**Eksikler bölümü** — her eksiklik için şunları değerlendir:
|
||||
1. Sert engel mi yoksa "olsa iyi olur" mu?
|
||||
2. Aday yakın bir deneyimle telafi edebilir mi?
|
||||
3. Portfolyoda bu boşluğu kapatan bir proje var mı?
|
||||
4. Somut azaltma planı (ön yazıda kullanılacak ifade, kısa proje vb.)
|
||||
|
||||
## Blok C — Seviye ve Strateji
|
||||
|
||||
1. **İlanda belirtilen seviye** ile **adayın bu arketip için doğal seviyesi** karşılaştırması
|
||||
2. **"Kıdemliyi dürüstçe sat" planı:** Arketipe göre uyarlanmış somut ifadeler, öne çıkarılacak başarılar, özgün geçmiş deneyimi nasıl avantaja çevireceğin
|
||||
3. **"Seviye düşürülürsem" planı:** Teklif adil ise kabul et, 6. ay incelemesi müzakere et, terfi kriterlerini netleştir
|
||||
|
||||
## Blok D — Maaş ve Piyasa
|
||||
|
||||
WebSearch ile araştır:
|
||||
- Rolün güncel maaş aralıkları (Kariyer.net Maaş Rehberi, Glassdoor TR, LinkedIn Maaş, Secretcv.com)
|
||||
- Şirketin ücret itibarı (Glassdoor/Kariyer.net yorumları varsa)
|
||||
- Bu rolün Türkiye'deki ve küresel talep trendi
|
||||
|
||||
Tablo olarak sun: veriler + kaynaklar. Veri bulunamazsa uydurmak yerine açıkça belirt.
|
||||
|
||||
**Türkiye'ye özgü kontrol listesi:**
|
||||
- İlan net mi brüt mu belirtiyor?
|
||||
- Yemek kartı, özel sağlık sigortası, servis var mı?
|
||||
- Yıllık TÜFE bazlı zam garantisi sunuluyor mu?
|
||||
- Prim/bonus yapısı nedir?
|
||||
|
||||
## Blok E — Kişiselleştirme Planı
|
||||
|
||||
| # | CV Bölümü | Mevcut hali | Önerilen değişiklik | Gerekçe |
|
||||
|---|-----------|-------------|---------------------|---------|
|
||||
| 1 | Özet | ... | ... | ... |
|
||||
| ... | ... | ... | ... | ... |
|
||||
|
||||
CV için en etkili 5 değişiklik + LinkedIn profili için en etkili 5 değişiklik.
|
||||
|
||||
## Blok F — Mülakat Hazırlığı
|
||||
|
||||
İlanın gereksinimlerine eşlenmiş 6-10 STAR+R hikayesi (STAR + **Yansıma**):
|
||||
|
||||
| # | İlan Gereksinimi | STAR+R Hikayesi | S | T | A | R | Yansıma |
|
||||
|---|-----------------|-----------------|---|---|---|---|---------|
|
||||
|
||||
**Yansıma** sütunu: öğrenilen dersi veya bugün farklı yapılacak şeyi yakalar. Bu kıdemi gösterir — junior adaylar ne olduğunu anlatır, kıdemli adaylar ders çıkarır.
|
||||
|
||||
**Story Bank:** `interview-prep/story-bank.md` varsa bu hikayelerin orada olup olmadığını kontrol et. Yoksa ekle. Zamanla her mülakat sorusuna uyarlanabilecek 5-10 ana hikayeden oluşan yeniden kullanılabilir bir banka oluşur.
|
||||
|
||||
**Arketipe göre seçim ve çerçeveleme:**
|
||||
- FDE → teslimat hızı ve müşteri yönlü yaklaşım ön planda
|
||||
- SA → mimari kararlar ön planda
|
||||
- PM → discovery süreci ve trade-off'lar ön planda
|
||||
- LLMOps → metrikler, evals, production sağlamlaştırma ön planda
|
||||
- Agentic → orchestration, hata yönetimi, HITL ön planda
|
||||
- Transformation → benimseme ve kurumsal değişim ön planda
|
||||
|
||||
Ayrıca ekle:
|
||||
- 1 önerilen vaka çalışması (hangi projeyi nasıl sunacağın)
|
||||
- Kırmızı bayrak sorular ve nasıl yanıtlanacağı (örn. "Neden bu kadar kısa sürede ayrılıyorsunuz?", "Yönettiğiniz bir ekip var mıydı?")
|
||||
|
||||
---
|
||||
|
||||
## Değerlendirme Sonrası
|
||||
|
||||
Bloklar A-F tamamlandıktan sonra **HER ZAMAN** şunları yap:
|
||||
|
||||
### 1. Rapor .md Kaydet
|
||||
|
||||
Değerlendirmenin tamamını `reports/{###}-{sirket-slug}-{YYYY-MM-DD}.md` olarak kaydet.
|
||||
|
||||
- `{###}` = sıradaki numara (3 haneli, sıfır dolgulu). Bu numarayı atomik olarak atamak ve yarış durumlarını (race condition) önlemek için, numarayı rezerve etmek üzere `node reserve-report-num.mjs` komutunu çalıştırmalısınız (standart çıktı `{###}` değerini döndürür), raporu yazmalı ve ardından sentineli serbest bırakmak için `node reserve-report-num.mjs --release {###}` komutunu çalıştırmalısınız.
|
||||
- `{sirket-slug}` = şirket adı küçük harfle, boşluksuz (tire kullan)
|
||||
- `{YYYY-MM-DD}` = bugünün tarihi
|
||||
|
||||
**Rapor formatı:**
|
||||
|
||||
```markdown
|
||||
# Değerlendirme: {Şirket} — {Rol}
|
||||
|
||||
**Tarih:** {YYYY-MM-DD}
|
||||
**Arketip:** {tespit edilen}
|
||||
**Puan:** {X.X}/5
|
||||
**URL:** {ilan URL'si}
|
||||
**PDF:** ✅/❌
|
||||
**Meşruiyet:** {Güvenilir | Dikkatli İlerle | Şüpheli}
|
||||
|
||||
---
|
||||
|
||||
## A) Rol Özeti
|
||||
(Blok A'nın tam içeriği)
|
||||
|
||||
## B) CV Eşleştirmesi
|
||||
(Blok B'nin tam içeriği)
|
||||
|
||||
## C) Seviye ve Strateji
|
||||
(Blok C'nin tam içeriği)
|
||||
|
||||
## D) Maaş ve Piyasa
|
||||
(Blok D'nin tam içeriği)
|
||||
|
||||
## E) Kişiselleştirme Planı
|
||||
(Blok E'nin tam içeriği)
|
||||
|
||||
## F) Mülakat Hazırlığı
|
||||
(Blok F'nin tam içeriği)
|
||||
|
||||
## G) İlan Meşruiyeti
|
||||
(Blok G'nin tam içeriği)
|
||||
|
||||
## H) Başvuru Formu Taslak Yanıtları
|
||||
(yalnızca puan >= 4,5 ise — form alanları için taslak yanıtlar)
|
||||
|
||||
---
|
||||
|
||||
## Çıkarılan Anahtar Kelimeler
|
||||
(ATS optimizasyonu için ilandan 15-20 anahtar kelime)
|
||||
```
|
||||
|
||||
### 2. Takipçiye Kaydet
|
||||
|
||||
**Yeni** kayıt için `data/applications.md`'yi doğrudan düzenleme. Bunun yerine `batch/tracker-additions/{num}-{sirket-slug}.tsv` dosyasına tek satır TSV yaz (8 veya 9 sekme ile ayrılmış sütun):
|
||||
|
||||
```tsv
|
||||
{num}\t{date}\t{company}\t{role}\t{status}\t{score}\t{pdf_emoji}\t[{num}](reports/{num}-{slug}-{date}.md)\t{note}
|
||||
```
|
||||
|
||||
- `{num}` = sıradaki numara (tam sayı, `reports/` klasöründen hesapla)
|
||||
- `{status}` = `Evaluated`
|
||||
- `{score}` = `X.X/5` formatı (örn. `4.2/5`)
|
||||
- `{pdf_emoji}` = `✅` veya `❌`
|
||||
- `{note}` = kısa not (isteğe bağlı, sütun atlanabilir)
|
||||
|
||||
Ardından `node merge-tracker.mjs` çalıştır.
|
||||
|
||||
**Mevcut** kayıt için `data/applications.md`'de ilgili satırı doğrudan güncelle (durum, PDF, rapor bağlantısı).
|
||||
|
||||
---
|
||||
|
||||
## İlan Meşruiyeti (Blok G)
|
||||
|
||||
İlanın gerçek ve aktif olup olmadığını değerlendir. Bu değerlendirme global puanı (1-5) **etkilemez** — ayrı bir nitel tespittir.
|
||||
|
||||
**Etik çerçeve:** Gözlemler sun, iddialarda bulunma. Her sinyalin meşru açıklaması olabilir. Kararı kullanıcı verir.
|
||||
|
||||
### Analiz Edilecek Sinyaller (önem sırasıyla):
|
||||
|
||||
**1. İlan Tazeliği** (Playwright snapshot'ından):
|
||||
- Yayın tarihi veya "X gün önce" bilgisi — sayfadan çıkar
|
||||
- Başvur butonu durumu (aktif / kapalı / yok / genel sayfaya yönlendiriyor)
|
||||
- URL genel kariyer sayfasına yönlendirdiyse not düş
|
||||
|
||||
**2. İlan İçerik Kalitesi** (ilan metninden):
|
||||
- Belirli teknoloji, framework veya araçlar adlandırıyor mu?
|
||||
- Takım büyüklüğü, raporlama yapısı veya organizasyon bağlamı var mı?
|
||||
- Gereksinimler gerçekçi mi? (deneyim yılı vs. teknolojinin yaşı)
|
||||
- İlk 6-12 ay için net bir kapsam var mı?
|
||||
- Maaş/ücret bilgisi var mı?
|
||||
- İlanın role özgü vs. genel şablon oranı nedir?
|
||||
- İç çelişki var mı? (junior başlık + kıdemli gereksinimler gibi)
|
||||
|
||||
**3. Şirketin İşe Alım Sinyalleri** (2-3 WebSearch sorgusu, Blok D araştırmasıyla birleştir):
|
||||
- `"{şirket}" işten çıkarma {yıl}` — tarih, kapsam, departmanları not et
|
||||
- `"{şirket}" işe alım dondurma {yıl}` — varsa duyuruları not et
|
||||
- İşten çıkarma varsa: bu roldeki departmanı etkiliyor mu?
|
||||
|
||||
**4. Yeniden Yayın Tespiti** (`scan-history.tsv`'den):
|
||||
- Şirket + benzer rol başlığının farklı URL ile daha önce göründüğünü kontrol et
|
||||
- Kaç kez ve hangi süre içinde tekrarlandığını not et
|
||||
|
||||
**5. Rol Piyasa Bağlamı** (ek sorgu gerektirmez):
|
||||
- Bu, genellikle 4-6 haftada dolan yaygın bir rol mü?
|
||||
- Rol bu şirketin işine uygun mu?
|
||||
|
||||
### Çıktı Formatı:
|
||||
|
||||
**Değerlendirme:** Üç seviyeden biri:
|
||||
- **Güvenilir** — Birden fazla sinyal gerçek ve aktif bir ilan olduğunu gösteriyor
|
||||
- **Dikkatli İlerle** — Dikkat edilmesi gereken karma sinyaller var
|
||||
- **Şüpheli** — Birden fazla hayalet ilan göstergesi mevcut; zaman harcamadan önce araştır
|
||||
|
||||
**Sinyaller tablosu:** Her sinyal, bulgusu ve ağırlığıyla (Olumlu / Nötr / Endişe Verici).
|
||||
|
||||
**Bağlam Notları:** İlgili uyarılar (niş rol, kamu kurumu ilanı, sürekli açık pozisyon vb.).
|
||||
|
||||
**Türkiye'ye özgü sinyaller:**
|
||||
- Kariyer.net / Yenibiris.com'da yayın tarihi (30 günden eski mi?)
|
||||
- Şirket köklü mü yoksa yeni kurulan mı?
|
||||
- İlan çok genel mi (kopyala-yapıştır şablonu gibi görünüyor mu)?
|
||||
- Maaş "rekabetçi" dışında herhangi bir bilgi içeriyor mu?
|
||||
- Şirkete ilişkin son dönemde işten çıkarma veya kapanma haberleri var mı?
|
||||
|
||||
### Özel durumlar:
|
||||
- **Kamu/akademik ilanlar:** Uzun süreçler standarttır. Eşikleri ayarla (60-90 gün normal kabul edilir).
|
||||
- **Sürekli açık pozisyonlar:** İlan "süregelen" veya "dönemsel alım" diyorsa not düş — bu hayalet ilan değil, pipeline rolüdür.
|
||||
- **Üst düzey / niş roller:** Staff+, VP, Direktör veya yüksek uzmanlaşma gerektiren roller meşru olarak aylarca açık kalabilir.
|
||||
- **Erken aşama startup:** Rol henüz tam şekillenmemiş olduğundan ilanın muğlak yazılmış olması normaldir. İçerik belirsizliğine daha az ağırlık ver.
|
||||
- **Tarih bilgisi yok:** Yayın tarihi belirlenemiyorsa ve başka endişe verici sinyal yoksa varsayılan olarak "Dikkatli İlerle" kullan. Kanıt olmaksızın asla "Şüpheli" deme.
|
||||
- **Recruiter kaynağı (kamuya açık ilan yok):** Tazelik sinyali alınamaz. Aktif recruiter temasının kendisinin olumlu bir meşruiyet sinyali olduğunu not et.
|
||||
|
||||
---
|
||||
|
||||
## Puanlama (1-5 global)
|
||||
|
||||
| Boyut | Ne ölçülüyor |
|
||||
|-------|-------------|
|
||||
| CV Eşleşmesi | Beceriler, deneyim ve kanıt noktalarının örtüşmesi |
|
||||
| Hedef Rol Uyumu | İlanın hedef arketiplerle uyumu (`_profile.md`'den) |
|
||||
| Maaş | Teklifin piyasa konumu |
|
||||
| Kültürel Sinyaller | Şirket kültürü, büyüme, istikrar, çalışma şekli |
|
||||
| Kırmızı Bayraklar | Engelleyiciler ve uyarılar (negatif düzeltme) |
|
||||
| **Global** | Yukarıdakilerin ağırlıklı ortalaması |
|
||||
|
||||
**Puan yorumu:**
|
||||
- 4,5+ → Güçlü eşleşme, hemen başvur
|
||||
- 4,0-4,4 → İyi eşleşme, başvurmaya değer
|
||||
- 3,5-3,9 → Kabul edilebilir ama ideal değil; özel bir neden olmadıkça geç
|
||||
- 3,5'in altı → Başvuru önerilmez
|
||||
@@ -0,0 +1,61 @@
|
||||
# Mod: pipeline — İlan Gelen Kutusu
|
||||
|
||||
`data/pipeline.md` dosyasına biriktirilen iş ilanı URL'lerini işler. İstediğin zaman URL ekle, hazır olduğunda `/career-ops pipeline` komutunu çalıştır.
|
||||
|
||||
## İş Akışı
|
||||
|
||||
1. **Oku** `data/pipeline.md` → "Bekleyenler" bölümündeki `- [ ]` satırlarını bul
|
||||
2. **Her bekleyen URL için:**
|
||||
a. Sıradaki `REPORT_NUM` değerini atomik olarak rezerve etmek üzere `node reserve-report-num.mjs` komutunu çalıştır (ve rapor yazıldıktan sonra `node reserve-report-num.mjs --release <num>` çalıştırarak sentineli serbest bırak)
|
||||
b. **İlan içeriğini çek:** Playwright (browser_navigate + browser_snapshot) → WebFetch → WebSearch. **Playwright kullanılmadıysa** (toplu/headless mod veya yedek yola düşüldüyse) rapor başlığına `**Doğrulama:** doğrulanmamış (toplu mod)` etiketini ekle.
|
||||
c. URL erişilemiyorsa → `- [!]` olarak işaretle, not ekle ve bir sonrakine geç
|
||||
d. **Tam pipeline'ı çalıştır:** A-G değerlendirmesi → Rapor (.md) → PDF (puan ≥ 3,0 ise) → Takipçi
|
||||
e. **"Bekleyenler"den "İşlenenler"e taşı:** `- [x] #NNN | URL | Şirket | Rol | Puan/5 | PDF ✅/❌`
|
||||
3. **3 veya daha fazla URL varsa ve Playwright kullanılmıyorsa** paralel ajan başlat (Agent aracı, `run_in_background`) — hızı artırır. Playwright etkinse tek tarayıcı örneği paylaşıldığından sıralı işle.
|
||||
4. **Tamamlanınca** özet tabloyu göster:
|
||||
|
||||
```text
|
||||
| # | Şirket | Rol | Puan | PDF | Önerilen eylem |
|
||||
```
|
||||
|
||||
## pipeline.md Formatı
|
||||
|
||||
```markdown
|
||||
## Bekleyenler
|
||||
- [ ] https://kariyer.net/is-ilani/12345
|
||||
- [ ] https://boards.greenhouse.io/sirket/jobs/456 | Şirket A.Ş. | Senior Backend Engineer
|
||||
- [!] https://ozel.url/ilan — Hata: giriş gerekiyor
|
||||
|
||||
## İşlenenler
|
||||
- [x] #143 | https://kariyer.net/is-ilani/789 | Acme Teknoloji | Backend Developer | 4.2/5 | PDF ✅
|
||||
- [x] #144 | https://boards.greenhouse.io/xyz/jobs/012 | BigCo | Frontend Engineer | 2.1/5 | PDF ❌
|
||||
```
|
||||
|
||||
> Not: Bölüm başlıkları EN ("Pending"/"Processed"), ES ("Pendientes"/"Procesadas") veya TR ("Bekleyenler"/"İşlenenler") olabilir. Okurken esnek ol; yazarken mevcut dosyanın stilini koru.
|
||||
|
||||
## URL'den İlan İçeriği Çekme
|
||||
|
||||
1. **Playwright (tercih edilen):** `browser_navigate` + `browser_snapshot` — tüm SPA'larla çalışır.
|
||||
2. **WebFetch (yedek):** Playwright mevcut değilse (toplu/headless mod). Bu durumda rapor başlığına `**Doğrulama:** doğrulanmamış (toplu mod)` ekle — kullanıcı daha sonra manuel doğrulayabilir.
|
||||
3. **WebSearch (son çare):** İlanı indeksleyen diğer platformlarda ara. WebFetch'te olduğu gibi rapor başlığına `**Doğrulama:** doğrulanmamış (toplu mod)` ekle.
|
||||
|
||||
**Özel durumlar:**
|
||||
- **Kariyer.net:** Playwright ile sorunsuz çalışır; giriş gerektirmez.
|
||||
- **Yenibiris.com:** Playwright ile çalışır.
|
||||
- **LinkedIn:** Giriş gerektirebilir → `[!]` olarak işaretle, adaydan ilan metnini yapıştırmasını iste.
|
||||
- **PDF linki:** URL doğrudan bir PDF'e işaret ediyorsa Read aracıyla oku.
|
||||
- **`local:` öneki:** Yerel dosyayı oku. Örnek: `local:jds/kariyer-backend.md` → `jds/kariyer-backend.md` oku.
|
||||
|
||||
## Rapor Numaralandırma
|
||||
|
||||
1. Sıradaki rapor numarasını atomik olarak rezerve etmek için `node reserve-report-num.mjs` komutunu çalıştır (standart çıktı `{###}` değerini döndürür).
|
||||
2. Bu numarayı kullanarak rapor dosyasını yaz.
|
||||
3. Rapor yazıldıktan sonra `node reserve-report-num.mjs --release {###}` komutunu çalıştırarak sentineli serbest bırak.
|
||||
|
||||
## Başlamadan Önce
|
||||
|
||||
Herhangi bir URL'yi işlemeden önce yapılandırma kontrolü çalıştır:
|
||||
```bash
|
||||
node cv-sync-check.mjs
|
||||
```
|
||||
Uyarı varsa adayı bilgilendirmeden devam etme.
|
||||
@@ -0,0 +1,29 @@
|
||||
# Mode: tracker — Applications Tracker
|
||||
|
||||
Read and display `data/applications.md`.
|
||||
|
||||
**Tracker Format:**
|
||||
|
||||
```markdown
|
||||
| # | Date | Company | Role | Score | Status | PDF | Report | Notes |
|
||||
```
|
||||
|
||||
Possible states: `Evaluated` → `Applied` → `Responded` → `Interview` → `Offer` / `Rejected` / `Discarded` / `SKIP`
|
||||
|
||||
- `Evaluated` = offer evaluated with report, pending decision
|
||||
- `Applied` = the candidate submitted their application
|
||||
- `Responded` = Company has responded (not yet interview)
|
||||
- `Interview` = active interview process
|
||||
- `Offer` = job offer received
|
||||
- `Rejected` = rejected by company
|
||||
- `Discarded` = discarded by candidate or offer closed
|
||||
- `SKIP` = doesn't fit, don't apply
|
||||
|
||||
If the user asks to update a state, edit the corresponding row.
|
||||
|
||||
Also show statistics:
|
||||
- Total applications
|
||||
- Breakdown by state
|
||||
- Average score
|
||||
- % with PDF generated
|
||||
- % with report generated
|
||||
@@ -0,0 +1,27 @@
|
||||
# Mode: training — Training & Course Evaluation
|
||||
|
||||
For each course/cert the candidate asks about, evaluate 6 dimensions:
|
||||
|
||||
| Dimension | What it evaluates |
|
||||
|-----------|-------------------|
|
||||
| North Star alignment | Does it bring closer to or further from the target goal? |
|
||||
| Recruiter signal | What do HMs think when they see this on a CV? |
|
||||
| Time and effort | Weeks × hours/week |
|
||||
| Opportunity cost | What else could be done during that time? |
|
||||
| Risks | Is content outdated? Weak brand? Too basic? |
|
||||
| Portfolio deliverable | Does it produce a demonstrable artifact? |
|
||||
|
||||
## Verdicts
|
||||
|
||||
- **DO** → 4-12 week plan with weekly deliverables and scoreboard
|
||||
- **DON'T DO** → better alternative with justification
|
||||
- **DO WITH TIMEBOX** (max X weeks) → condensed plan, essentials only
|
||||
|
||||
## Priority
|
||||
|
||||
Training that improves credibility in "production-grade AI":
|
||||
1. LLM evaluation and testing
|
||||
2. Observability and monitoring
|
||||
3. Cost/reliability trade-offs
|
||||
4. AI governance and safety
|
||||
5. Enterprise AI architecture
|
||||
Loaded 100 of 1527 files, more files were not shown because too many files have changed in this diff.
Show more
Reference in new issue
Block a user