init

modes/heuristics/recruiter-side.md

@@ -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