# Product build prompts

## Signal Studio

Build a responsive web application called Signal Studio for independent creators who manage paid memberships and community channels. The product should unify comments, community chat, polls, purchases, membership activity, and content performance into one evidence based workspace. Its purpose is to help a creator understand what fans are asking for, which themes are emerging, what content affects retention and conversion, and what small experiment to run next.

Primary user: a creator with 5,000 to 100,000 followers and a small team who currently copies data between platform analytics, spreadsheets, and chat tools. Secondary user: a community or growth manager who needs to present a clear recommendation to the creator.

Build these flows:
1. Connect data sources with granular permissions, plain language consent, import status, and the ability to revoke each source.
2. Show an insights dashboard with four evidence backed signals: repeated fan requests, rising themes, retention drivers, and conversion opportunities.
3. Let users open a signal cluster to inspect representative comments, source distribution, confidence, timeframe, and why the model grouped those items.
4. Generate an editable recommendation that names the opportunity, evidence, expected impact, risk, and suggested audience.
5. Turn the recommendation into an experiment. Let the user choose a goal, audience, offer, duration, guardrail, and success metric before launch.
6. Compare baseline and experiment performance. Support save, reject, edit, launch, pause, and record a learning.
7. Add an AI correction flow so the user can merge clusters, remove irrelevant examples, change the interpretation, and improve future suggestions.

Design direction: editorial and analytical. Use warm white, charcoal, muted coral, and a single teal status color. Avoid gradients, glass effects, decorative blobs, huge empty hero sections, and card grids without hierarchy. Use a narrow utility sans for labels and a readable serif for insight headlines. Make the evidence more prominent than the recommendation.

AI requirements: every recommendation must link to its evidence. Show confidence as plain language with the sample size and date range. Never claim certainty. Let the creator override the model. Store corrections as structured feedback. Include empty, loading, partial data, disconnected source, conflicting signal, and low confidence states.

Accessibility: keyboard navigation, visible focus, semantic landmarks, charts with text alternatives, 4.5:1 text contrast, 44 pixel touch targets, reduced motion, and no color only status communication.

Suggested data entities: Creator, Workspace, DataSource, AudienceSegment, ContentItem, CommunityMessage, SignalCluster, EvidenceItem, Recommendation, Experiment, Metric, ExperimentResult, ModelCorrection, and ConsentRecord.

Success measures: time from question to testable experiment, percentage of recommendations opened with evidence, experiment completion rate, corrections submitted, repeated weekly use, and creator reported decision confidence. Do not optimize for the number of AI outputs.

Implementation: build the first version with a responsive React or Next.js front end, typed data models, accessible component primitives, seeded realistic sample data, and a mocked AI service with transparent output schemas. Add unit coverage for scoring and permissions, interaction coverage for the experiment flow, and analytics events for each major decision.

## AccessFit

Build a mobile first responsive application called AccessFit for adults adapting to a prosthetic device. The product helps a user record daily comfort, fit, skin observations, activity, and mobility, recognize patterns over time, and prepare a concise report for a clinician. It is a self tracking and communication tool. It must never diagnose, prescribe, or imply that it replaces professional care.

Primary user: an adult in the first year of adapting to a lower limb prosthesis who wants a fast, low effort way to remember changes between appointments. Secondary user: a prosthetist or physical therapist reviewing a patient generated summary with the patient's explicit permission.

Build these flows:
1. Onboard with device profile, adaptation stage, accessibility preferences, notification choices, privacy explanation, and emergency guidance.
2. Run a daily check in that takes under 60 seconds. Capture comfort, socket fit, activity, skin change, mobility confidence, optional note, and optional voice input.
3. Provide an accessible body and device map. Let users select a region, choose a sensation, rate severity, and add context.
4. Show trends across days and weeks. Connect discomfort with activity, wear time, fit, and user notes without stating causation.
5. Generate a plain language AI summary that cites the user's own entries, explains uncertainty, and separates observations from possible questions for a clinician.
6. Build a clinician report preview with selected date range, relevant trends, notes, questions, and export or time limited share controls.
7. Add a privacy center where the user can inspect, correct, export, or delete data and revoke any share link.
8. Show urgent support guidance when the user records severe symptoms or rapidly worsening skin concerns. Use calm language and direct the user to appropriate professional or emergency support.

Design direction: calm, precise, and dignified. Use bone white, deep navy, soft blue, warm amber, and restrained red only for urgent guidance. Avoid clinical stock photography, glowing AI effects, gamified streak pressure, infantilizing illustrations, and decorative dashboards. Prefer large type, clear steps, generous touch targets, and strong information hierarchy.

AI and safety requirements: summaries must be grounded only in user entered data. Show exactly which entries support each observation. Do not infer a diagnosis. Distinguish observation, uncertainty, and suggested question. Allow the user to edit or remove every statement before sharing. Log consent and sharing activity. Include a visible statement that AccessFit is not medical advice.

Accessibility: full keyboard and screen reader support, logical focus order, large text mode, high contrast mode, voice input, reduced motion, non visual body map alternative, 44 pixel minimum targets, no forced time limits, and simple language.

Suggested data entities: User, DeviceProfile, AccessibilityPreference, DailyCheckIn, BodyRegion, SymptomObservation, ActivityEntry, WearSession, Trend, SummaryStatement, EvidenceReference, ClinicianReport, ShareGrant, ConsentRecord, and SafetyEscalation.

Success measures: check in completion time, weekly completion consistency, percentage of summaries edited before sharing, clinician report completion, share revocation success, accessibility task completion, and user reported preparedness for appointments. Never use longer app time as a goal.

Implementation: build the first version as a responsive progressive web application with offline draft support, local encryption for sensitive drafts, typed schemas, seeded synthetic data, accessible charts with table alternatives, and a mocked grounded summary service. Add automated accessibility checks, interaction coverage for urgent support and sharing, and clear separation between product guidance and medical care.