---
name: critique
description: Critique an existing resume or cover-letter package against its real job description. Use for application-fit review, truth/provenance audit, recruiter and hiring-manager evaluation, separate Evidence Fit and Document Quality scoring, channel-strength assessment, and post-edit re-critique.
---

# Critique an Application Package

## Startup

1. Read `resume_builder/reference/shared_ops.md`.
2. Read `resume_builder/canonical/claims.json` completely.
3. Read `config.md`, the session file, and the real verbatim JD.
4. Stop if the JD is reconstructed, incomplete or inferred.
5. Read `resume_builder/reference/critique_framework.md` and `resume_builder/support/ai_fingerprint_rules.md`.
6. Read the resume and optional cover letter. Never use either as evidence; verify against canonical claims and experience files.

## Preflight

Run:

```powershell
python resume_builder/helpers/validate_resume_system.py --document <resume.tex>
```

Add `--document <cover_letter.tex>` when a letter exists. Any failure is Tier 1 and prevents approval.

Compile the documents and inspect the PDFs. Extract resume text with `pdftotext` and confirm that employer, formal title and dates appear in the expected order.

## Critique

Follow `critique_framework.md` exactly:

1. Hard-gate audit.
2. Evidence Fit score, independent of writing.
3. Document Quality score, independent of role fit.
4. Channel Strength rating.
5. Competitive and reader-sequence assessment.
6. Canonical claim audit.
7. Tiered fixes.
8. Cover-letter decision/critique.
9. Mechanical verification.

Do not issue a single overall score. Do not label a high-quality document submit-ready when Evidence Fit fails a hard gate.

## Cover-Letter Handling

If the session records `Cover Letter Decision: NO`, do not penalize absence. If a letter exists, first assess whether it should exist under `cl_reference.md`.

## Save and Report

Save `output/<Folder>/critique_<name>.md`. Update the session with:

- Evidence Fit score and Core/Adjacent/Stretch classification.
- Hard-gate result.
- Document Quality score.
- Channel Strength.
- Tier 1 fixes.
- Critique status and date.

Present the fit verdict first, then the two scores and actionable fixes. Wait for explicit user approval before finalization or editing.

When approved, run the finalization checks from `shared_ops.md`. A package with a hard-gate NO-GO may be archived, but must not be described as recommended for submission.