Conciseness

The body is efficient and directive — framework selection criteria, specific design tokens ('zinc color palette', 'DM Sans', 'JetBrains Mono'), and a concrete acceptance checklist with no explanation of concepts Claude already knows. Minor trims possible: the chat-offer prompt is stated twice with near-duplicate wording, decorative horizontal rules, and GitHub-style callouts wrapped in code fences add tokens; not 5 because of those small redundancies, not 3 because nothing rises to 'unnecessary explanation'.

Actionability

Some concrete guidance exists (framework decision criteria like 'if you see a package.json with React dependencies, use React', and verifiable checklist items like 'date fields formatted... (e.g., MMM dd, yyyy)' and 'relative z-30'), but the substantive executable content is delegated to files that do not exist in the bundle: 'Read resources/shared_design_system.md', 'Read resources/streamlit_framework.md', 'Read resources/react_framework.md', 'Read resources/chat_integration.md', and 'examples/react_chat_panel.jsx' / 'examples/fastapi_chat.py' / 'examples/express_chat.ts' all point to missing paths. This is 'concrete guidance but incomplete; missing key details' rather than a 2, since the in-body orchestration and verification guidance is specific and followable.

Workflow Clarity

Clear sequence (Step 0 framework selection → Step 1 implementation plan → shared design standards → framework implementation → optional chat feature) with an explicit validation checkpoint ('MUST use browser testing capabilities... to visually verify the frontend application is working correctly before notifying the user that the task is complete') and a work-tracking checklist. Not 5 because there is no error-recovery feedback loop (what to do when browser verification or API calls fail) and the chat-interface flow is somewhat convoluted; not 3 because checkpoints are explicit, not merely implied.

Progressive Disclosure

The structure is well designed — the body stays an orchestration overview with clearly signaled, one-level-deep pointers ('Read resources/streamlit_framework.md for detailed CSS and component patterns', 'Adapt the patterns in examples/react_chat_panel.jsx') — but scored against the actual bundle, none of the seven referenced files (resources/*.md, examples/*.jsx/.py/.ts) exist, so the navigation leads nowhere. This lands between 'references present but' unusable and the well-organized anchor, hence the midpoint rather than a 4 or 5.

Specificity

The description names concrete capabilities and technologies ('Build modern data apps, dashboards, and interactive reports using either React + Vite or Streamlit', 'Includes optional Gemini Data Analytics chat integration'), which would merit a 4 — but condition 2 uses second person ('You need to generate a frontend web application to interact with, query, and visualize data from GCP data sources'), and the rubric mandates a 1-point specificity penalty for second-person voice. Not a 2 because the domain and actions are far more concrete than 'Names the domain but actions are minimal'.

Completeness

Explicitly answers both questions: the 'what' ('Build modern data apps, dashboards, and interactive reports using either React + Vite or Streamlit. Includes optional Gemini Data Analytics chat integration') and the 'when' via three numbered 'Relevant when' conditions plus three explicit 'Do NOT use when' exclusions. This matches the anchor 'Clearly and explicitly answers both what AND when with concrete trigger phrases'; a 4 would require a less explicit 'when' clause.

Trigger Term Quality

Good natural keyword coverage: 'data dashboard', 'data application', 'visualization UI', 'chat with your data', 'Gemini Data Analytics chat API', 'GCP', 'BigQuery' — phrases users would naturally say. Not 5 because common variations like 'data visualization', 'report builder', 'BI dashboard', or framework mentions as triggers (e.g., 'Streamlit app') are absent; not 3 because coverage clearly exceeds 'some relevant keywords'.

Distinctiveness Conflict Risk

The GCP/BigQuery binding and explicit negative conditions ('backend-only services', 'simple CLI scripts', 'not data-centric') carve out a mostly distinct niche with minor overlap risk against generic frontend or visualization skills. Not 5 because 'data dashboard'/'visualization UI' is a crowded trigger space and condition 1's 'defaulting to BigQuery unless otherwise specified' lets it claim any data-dashboard request, keeping some conflict risk with closely related skills.