Skip to content

v1.2.0

Choose a tag to compare

@phuryn phuryn released this 03 Nov 17:05
· 23 commits to main since this release

Screens start from what people come to do, and the work you can see comes first.

Changed: design, now mandatory for any screen work, a builder's included.

  • The jobs map before any screen: each job in the user's words, the screen it happens on, that screen's one question and its primary action. A screen with no job is cut.
  • The product's data rules stay out of the copy and show up only as outcomes in plain words. When the product replaces a tool you know, that tool's structure is the default.
  • Example data fills every screen, so a click-through never meets an empty tab.
  • A stage with screens reaches you only after a newcomer walkthrough: someone new to the domain says what each screen is for and what to press next, unaided. Then the rendered-screen pass.
  • The method adds four rules: a dismissable dialog has a close button, a grid stretches a lone button, a shell's second bar takes its stretching row, and an API key is not a password field.

Changed: app-lifecycle and propose

  • The work is ordered by what you will see against what it costs. The landing, pricing on display and placeholder legal pages are built with the first screens, so your first click-through shows the whole product, and they are made true before any further feature phase; hard logic waits until the product is worth it. Sample prices never reach a page a stranger can open.
  • A plan may move the design stage, never drop it, and a brief for a stage with screens names the design method by its path, so a builder that reads no skills finds it.
  • A product whose content arrives from an integration ships example data. The click-through list says what isn't built yet, and which stage brings it.
  • Monitoring is proposed once going live is done, with the status page linked from the footer, for example, in a change of its own; a development deploy has nothing to watch. Staygreen finds /health and the app's sign-in and database on its own, so the app is built to be found there.
  • A proposal lists its jobs map, and the prototype draws those screens.

Also: codex-agents and delegation carry the design method into builds with screens; release-gate stamps every Railway upload with its commit; flight-deck items carry everything they need, and an idle session with answers waiting schedules its own check.

44 skills in six packs.

Install: README § Install. Lost at any point? Type /product:start-here (Codex: $product:start-here) and say what you have.