# Resume Scorecard

## Objective

Grade a resume on clarity, impact, keywords, and formatting.

Build a resume scorecard that turns rubric answers into a score, gap list, and prioritized improvements.

## Before You Begin

This tool is being added to an application or site that may already exist.
Do not scaffold a new project unless the user explicitly asks for one, and
do not assume a blank slate.

Inspect the codebase first and establish:

- The source Markdown files, docs, URLs, or repo files supplied for this tool build.
- The audience, primary job, required inputs, expected output, and desired next action.
- The existing application structure and where pages, forms, widgets, data capture, or tracking code already live.
- The framework and version in use.
- The existing design system — colours, spacing, typography, and component conventions.
- Existing UI components you can reuse instead of writing new ones.
- The existing database structure, if this tool needs to persist submissions, saved progress, votes, reports, or events.
- The existing authentication and authorization system, if this tool is user-scoped.
- Dependencies already installed, so you don't add a library that duplicates one.
- The existing test setup and conventions.

Only start writing code once you understand the above. If the application
already implements part of this tool, extend it rather than replacing it.

Do not invent testimonials, revenue claims, scarcity, guarantees, legal
disclaimers, or endorsement language. Use only what appears in the source
files, and call out missing claims or assets in your final summary.

## Implementation Instructions

Build a resume scorecard that turns rubric answers into a score, gap list, and prioritized improvements.

1. Inspect the rubric, role type, and examples of strong resumes in the source files.
2. Create scoring sections for clarity, impact, keywords, formatting, and length.
3. Calculate an overall score and section scores with plain-language recommendations.
4. Add an action plan and a CTA to download the report or request a review.

## Edge Cases

- Keep the tool focused on one primary job. If the source asks for a suite, build the first usable tool and list the obvious follow-ups.
- Do not invent testimonials, guarantees, legal disclaimers, revenue numbers, scarcity, or unverifiable claims.
- If formulas, scoring weights, or recommendation rules are missing, create editable placeholders and call out the assumptions.
- If payment, email, analytics, CRM, or storage integrations are missing, build clear seams and document the variables or endpoints still needed.
- Match the existing app or page design system unless the user explicitly asks for a standalone visual direction.

## Acceptance Criteria

- [ ] The tool is buildable as a standalone page, lightweight SPA, embeddable widget, or cleanly integrated app screen.
- [ ] The primary input, primary output, and primary action are obvious without extra instructions.
- [ ] The implementation includes empty, loading, error, and completed states.
- [ ] Mobile, tablet, and desktop layouts are accounted for.
- [ ] The agent reports the source files used, assumptions made, and any formulas or rules that still need owner review.

## Adaptation Rules

- Match the existing design system. Do not introduce a new colour palette,
  spacing scale, or component library.
- Reuse existing components and utilities wherever they fit.
- Follow the naming, file layout, and code style already present.
- Do not upgrade, replace, or remove existing dependencies to make this
  tool fit. Adapt the tool to the app, not the app to the tool.
- Do not break existing functionality. If a change is genuinely required in
  existing code, make the smallest one that works and say so.
- If something in these instructions conflicts with how the application is
  built, follow the application and explain the deviation.
- Use generic tool strategy language. Do not name or imply endorsement by
  any specific public marketer, course, book, or software brand.

## Final Verification

Before you report the work as done:

1. Re-read the acceptance criteria above and check each one against what you
   actually built.
2. Run the application and exercise the tool end to end.
3. Run the existing test suite and confirm you have broken nothing.
4. Check the tool on mobile, tablet, and desktop widths.
5. Check forms, buttons, keyboard navigation, and focus handling.
6. Summarize what changed: files added, files modified, source files used,
   assumptions made, and anything you deliberately did differently because
   of how this application is built.

If any acceptance criterion is unmet, fix it before reporting completion.