The full scope
of Clearsky

Everything the product is, everything it does, and everything that has been designed so far — the app, the marketing site, the visual system and the assets behind them.

1. The problem

Most people do not have a productivity problem. They have a presence problem. Messages arrive faster than they can be considered, so replies get shorter and later; plans get made in passing and never land in a calendar; the people who matter most get the leftovers of attention that strangers and automated senders took first.

Existing tools make this worse in three specific ways. Inboxes treat every sender as equal. Task managers require you to re-type what you already said in a conversation. Calendars record only what was formally scheduled, so an informal promise — "I'll let you know by tonight" — exists nowhere at all.

Clearsky closes that gap. It reads what arrives, decides what deserves you, drafts the reply, extracts the commitment hidden inside it, puts that commitment on a date, and defends the time it needs.

2. Who it is for

3. Principles

1. Nothing sends itself. Clearsky drafts, suggests and reminds. Every outbound word is tapped by the user.
2. One nudge a day. A single morning summary, plus a reminder only when a promise is actually due. Notification budget is a hard product constraint, not a setting.
3. Every item must explain its presence. Triage cards state both the relationship/context signal that made an item relevant now and the system behavior if the user takes no action.
4. Every action maps to one explicit state. Clearsky uses a fixed set of user-understandable outcomes—Responded, Planned, Snoozed, Waiting on them, and Let go—and reflects those same outcomes across triage, promises, calendar, notifications, and completion states.
5. Ownership determines pressure. Items that require the user’s action are distinct from items awaiting another person. Clearsky does not frame waiting on someone else as incomplete personal work.
6. Recovery is a valid outcome. When a commitment no longer fits, the product presents “needs a new plan” and offers honest exits: keep it, choose a new time, or let it go.
7. Recommendations guide; they do not override. Clearsky recommends the most appropriate next action based on item context, while preserving quieter alternatives and user control.
8. Protecting time is a feature, not an afterthought. A promise without a defended block is just a nicer to-do.
9. Calm is the aesthetic and the behaviour. Sky imagery, generous whitespace, no badges, no streaks, no guilt mechanics.

4. The core model — five loops

The entire product is one short cycle repeated daily. Each loop has a screen, an object it produces, and a definition of done.

5. Object model

Six entities carry the whole product. Everything on every screen is a view of one of these.

6. Screen inventory

Nineteen screens, all built and interactive in 02 App Prototype. Grouped by the flow they belong to.

7. End-to-end flows

8. Notifications

Three notifications exist in V1. There is no fourth, and adding one is a product decision, not a feature request.

• Morning summary — 08:00, one line naming the size of the stack and the most urgent promise.
• Promise due — only on the day, only once, only for promises with a date.
• Weekly recap — Sunday evening, the one moment the product asks for reflection.

9. Privacy and data

Privacy is a positioning pillar, not a compliance page. Three commitments carry it, each stated on the Privacy screen and the marketing page in identical words.

• On your device. Sorting and drafting run locally wherever the model allows.
• Kept 30 days. Message text used for sorting is discarded after a month.
• Never sold. No ad model, no data brokers, no training on user words.
• Never sends. The strongest promise, repeated on both surfaces: Clearsky never sends a message on your behalf.

10. Pricing

One product, everything included. No tiers, no feature gates. 14 days free, then:

The same three numbers appear on the marketing pricing page and in the app paywall. Any change must be made in both places at once.

11. Marketing site

Six pages plus a 404, all built. The site tells one story across a single day-cycle: each page owns a sky state, and the daydreamer character appears on every one, interacting with the page itself rather than sitting inside a framed illustration.

12. Design system

13. Asset library

One character — the Clearsky daydreamer — locked to a saved reference so every image is the same person. Everything is generated in the glossy toy-vinyl style and cut to transparency. The character library serves the marketing site only; the app ships no character art, but it does keep the six painted sky plates as its splash backgrounds.

• 21 character embeds — transparent, page-ready. Five app-loop poses, eight page-specific poses, eight original scenes.
• 6 cloud cutouts — C1 to C6, the parallax layer set used on every marketing page and every splash screen.
• 8 background plates — two marketing hero skies for M01 and M02, plus the six app splash plates (dawn, golden morning, high clear air, mint relief, golden hour, dusk cloud sea), each painted beneath its own CSS pattern at 62% opacity.
• Reference-only originals — the first-generation illustrations with baked-in backgrounds, kept for direction, not for use.

14. Deliberately out of scope for V1

15. Open questions

1. Does triage run once each morning, or continuously through the day with a morning peak? The current design assumes once.
   Decision (Duck default, 23 Sep 2026): Once each morning, plus an optional evening sweep.
2. What happens to a queued item that is never revisited — does it expire, resurface, or accumulate?
   Decision (Duck default, 23 Sep 2026): It comes back once after 7 days, then moves to an archive. It never accumulates indefinitely.
3. Can a promise exist without a date, and if so where does it live so it is not forgotten?
   Decision (Duck default, 23 Sep 2026): Allowed. Clearsky asks "by when?" within 24 hours and defaults to "this week" if the user doesn't answer.
4. Does protected time write a real calendar event that others can see as busy, or a private hold?
   Decision (Duck default, 23 Sep 2026): A calendar hold that shows as busy to others; the details stay private.
5. What is the empty state for a user with no inner circle and no connected accounts — a demo day, or a prompt to connect?
   Decision (Duck default, 23 Sep 2026): A demo day with sample data, and one tap to connect.

16. What to validate next

The model is structurally good enough to test. The next risk is not information architecture—it is whether Clearsky’s recommendations feel trustworthy and whether users can predict state transitions without explanation from the team.