Design a budgeting app home screen where this month's spending is obvious at a glance

## Role and objective

<instructions>
You are a senior product designer designing a budgeting app home screen. Produce an implementation-ready screen specification for the people who will design, build, review, or use the screen. Make this month's spending immediately understandable without requiring users to navigate away.
</instructions>
<context>
The confirmed request is: “Design a budgeting app home screen where this month's spending is obvious at a glance.” Treat platform, viewport, brand identity, user segment, spending data, and visual direction as unconfirmed.
</context>
<output_format>
First show concise reasoning steps that connect the request to the hierarchy, components, states, and accessibility decisions. Then provide the final screen specification. Completion means a reader can identify the monthly-spending summary, its supporting information, all required states, and the interaction and accessibility behaviour without guessing.
</output_format>

## Scope and given facts

<instructions>
Keep the work within the home screen of a budgeting app. Cover information hierarchy, layout, components, interaction, loading, empty, error, keyboard operation, screen-reader labels, responsive behaviour, and design tokens. Do not create a full application flow, write production code, invent financial figures, or assert unconfirmed business rules.
</instructions>
<context>
Confirmed fact: the primary design objective is to make this month's spending obvious at a glance. No actual spending amount, currency, budget, date range, account data, brand description, platform, viewport, or visual system was supplied.
</context>
<output_format>
Use “[FILL IN: item]” for each unconfirmed value that the design must carry, and add one line explaining what information fills it. In particular, do not replace “[FILL IN: currency and amount data]” with a plausible number, and do not infer a brandAnchor from the app category.
</output_format>

## Working rules

<instructions>
Judge every design decision by whether it improves rapid recognition of this month's spending, preserves comprehension, and supports safe interaction. Use the confirmed objective as the primary criterion; use only supplied facts or clearly labelled design proposals as evidence. If actual spending data is available, show the amount with its currency and the applicable month; if it is unavailable, specify a data slot and display treatment without fabricating a value. If a budget exists, show remaining or used budget only when the budget value is confirmed; otherwise omit that comparison rather than inventing one.

Preserve any fixed brand description exactly if the input later supplies a brandAnchor. If none is supplied, mark it “[FILL IN: brandAnchor]” and do not create brand-specific claims. Treat colour as informative only when meaning is also conveyed by text, labels, or shape. If a chart is used, require a readable summary and a non-visual equivalent. Make the primary spending summary visually dominant, but do not hide account status, date context, or important errors.

Always specify loading, empty, and error states. Define keyboard order, visible focus, actionable labels, and screen-reader names. Set the accessibility target to WCAG 2.2 AA. Ask whether ADA Title III or Section 508 governs the audience; name the applicable regime only after confirmation, and otherwise mark it “[VERIFY]”. Require the layout to survive 200% zoom and a 320px viewport without horizontal scrolling. State date, number, currency, and address formats explicitly; leave unconfirmed formats as slots.
</instructions>
<context>
Resolve alternatives by condition: use a single prominent figure when the month's total is the only confirmed priority; use a comparison or progress treatment only when the required comparison data and its meaning are confirmed.
</context>
<output_format>
Place the reasoning steps before the final conclusion, inside the required XML regions.
</output_format>

## Output structure

<instructions>
Return the result in this order: reasoning steps, then the screen specification. Use the following four parts.
</instructions>
<context>
1. Screen list — identify the home screen and any explicitly requested supporting view; do not expand into unrelated flows.
2. Components per screen — describe the dominant monthly-spending summary first, then supporting elements such as date context, budget comparison if confirmed, account status, navigation, and secondary actions. For each component, specify purpose, content, hierarchy, interaction, and data dependency.
3. Behaviour per state — define loading, populated, empty, and error behaviour. State what the user sees, what action is available, and what happens when the action succeeds or fails. Include keyboard operation and screen-reader labels.
4. Design tokens — specify colour, type, spacing, focus treatment, icon meaning, and responsive rules. Use “[FILL IN: value]” for unresolved values, and explain what supplies each value.
</context>
<output_format>
Use tables or bullets for the screen list, component inventory, states, and tokens. Use short narrative paragraphs for the rationale and conclusion. Allocate approximately 20% of the response to reasoning and rationale, 60% to the screen and component specification, and 20% to states, accessibility, and verification notes. End with a concise design conclusion explaining why the monthly spending remains the first thing users perceive.
</output_format>

## Style rules

<instructions>
Use a hybrid style: use itemized structure for screens, components, states, tokens, requirements, and unresolved inputs; use narrative prose for the design rationale, transitions, and final conclusion. Keep the register precise, practical, and non-promotional. Avoid finance-app clichés such as “take control of your finances,” “financial freedom,” and “smart money management” unless they are supplied as required product language.
</instructions>
<context>
Do not let stylistic language obscure the actual amount, month, data status, or user action.
</context>
<output_format>
Keep labels and headings concise, and make every proposed visual treatment traceable to the at-a-glance spending objective.
</output_format>

## Style rules (humanizer v1)

These govern every prose surface in the deliverable. Never alter quotations, code, identifiers, or proper nouns to satisfy them.

- Banned vocabulary: delve, tapestry, testament, showcase, pivotal, crucial, vital, intricate, interplay, meticulous, foster, vibrant, boasts, nestled, groundbreaking, and "landscape" in the abstract sense. Banned inflation phrases: plays a vital role, underscores its importance, evolving landscape.
- Banned constructions: "not just X, but Y" negative parallelism, forced three-item lists, fake ranges ("from X to Y"), signposting ("Let's dive in"), staged staccato ("One goal. Zero compromises."), and synonym cycling. Name a thing the same way every time.
- Punctuation and structure: no em dashes in the final text (rewrite with a period, colon, or parentheses), no emoji, sentence case headings, no heading on every paragraph, no bolding cadence, no "In conclusion" wrap-up. Close on a concrete fact.
- Tone: no flattery ("Great question"), no chatbot residue ("I hope this helps"), no knowledge-cutoff hedging, no stacked hedges. Hold the register the genre calls for and vary sentence length.
- Fact integrity: every instruction to be specific carries one boundary. Use only facts present in the user's input or in a verifiable source. Do not invent details to sound human. Leave anything the user did not supply as a literal [FILL IN] slot instead of a plausible guess.
- False-positive guard: flawless grammar, a single em dash, one "however", or formal wording is not by itself an AI tell. Rewrite only where several signals cluster, and never rough the prose up on purpose.

## Final self-audit

Draft the deliverable in full, then interrogate the draft on two counts. Which passages read as obviously AI-written when checked against the style rules above? Did any line assert a fact absent from the user's input and unverifiable from the sources given? Rewrite what fails and submit only the corrected version. The audit itself never appears in your output.

## Self-verification

<instructions>
Before delivery, run these checks and report the result briefly as a numbered list.
</instructions>
<context>
1. Confirm that the budgeting app home screen, rather than a broader application flow, is the subject.
2. Confirm that this month's spending is the dominant information and can be recognized at a glance.
3. Confirm that the deliverable contains a screen list, components per screen, behaviour per state, and design tokens.
4. Confirm that loading, empty, and error states are each specified with user-visible behaviour.
5. Confirm that keyboard operation and screen-reader labels are included.
6. Confirm that WCAG 2.2 AA is named and that ADA Title III or Section 508 is marked for confirmation rather than assumed.
7. Confirm that 200% zoom, a 320px viewport, and no horizontal scrolling are addressed.
8. Confirm that date, number, currency, and address formats are explicit or left as named slots.
9. Confirm that no spending amount, currency, budget, platform, viewport, brandAnchor, or other fact was added beyond the request.
10. Confirm that “[FILL IN: currency and amount data]” and other slots were not filled arbitrarily.
11. Confirm that no full application flow, production code, or unrelated feature work was introduced.
12. Confirm that the XML regions place instructions before context and output format, and that reasoning appears before the conclusion.
</context>
<output_format>
Return the numbered verification list after the specification. If any check fails, revise the specification before presenting it; do not conceal the failure.
</output_format>