# Readiness Assessment

## Objective

Tell users whether they are ready for an offer, launch, project, or next step.

Build a readiness assessment that diagnoses gaps and gives a prioritized action plan.

## 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 readiness assessment that diagnoses gaps and gives a prioritized action plan.

1. Inspect the requirements, success criteria, prerequisites, and common failure points.
2. Create sections and weighted questions that cover each readiness area.
3. Show a readiness score, category breakdown, gap list, and recommended next steps.
4. Add share, save, or email-result hooks where the app already supports them.

## 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.