Learn what each step gives you, when it helps and what you take on. Follow your agent to a working app, choose reusable pieces when they fit, or build directly with your preferred stack.
No app idea needed. Browse any lesson before setting up.
What does Composer add? Environment checks, reusable setup handoffs, portable app briefs and working composition examples in one place. Use the parts that help. Your own app can stay independent of Composer, with an agent building directly on Workers, Astro and optional EmDash.
Follow along at your own pace · reviewed 14 October 2026
A short brief and project instructions give future tasks the same starting point: who the app serves, what matters and how to check the result. You spend less time explaining the project again.
Useful when
Use an agent for a direct app, a reusable mini-app or an existing project. Composer is optional; useful project guidance carries across all three.
The trade-off
Instructions and skills need to match the current project. Too much stale guidance can obscure the actual task; a file or installed skill does not prove the agent used it.
You decide what you want to make. Your coding agent works in your project folder: it inspects files, handles routine setup, builds and checks the result. You handle account sign-in and decisions about permissions or spending.
You can read this guide on any device. Automated starter setup is currently verified with Codex on an Apple Silicon Mac with Node 22 and Git. Ask your agent to check support first on another setup.
Try this
Open your coding agent and select a project folder. An empty folder is fine.
Ask it to inspect the folder before changing anything. If it contains work already, ask it to preserve that work.
Read its response: it should identify the actual folder, available tools and the next useful step.
Ask your agent
Inspect this selected project folder without changing it. Explain what is already here, what tools you can actually use and the smallest next step for App Composer Get Ready. Preserve existing work. Do not install, create repositories, change accounts or deploy during this inspection. Keep credentials and private files out of the response.
What a useful result looks like
The agent can explain what it inspected and distinguish a missing tool from a missing login. “Everything looks good” without those checks is a reason to ask for the evidence.
Give future tasks a useful starting point
AGENTS.md holds project-specific working instructions: purpose, real build commands, what to preserve and how to verify a change. A skill holds a reusable workflow, often in a folder containing SKILL.md. A tool or MCP connection gives the agent an actual capability. They solve different problems; instructions alone do not connect accounts or enforce permissions.
Describe the outcome. Name the audience, main task, desired feel and what is out of scope. Tell the agent about an existing app or preferred stack.
Inspect before adding. Preserve existing instructions and skills. Keep project rules short and use the commands and release path that actually exist.
Add only relevant workflows. Design and copy help for public pages; official EmDash guidance for CMS work; diagramming when a relationship needs explaining. Check trusted sources, versions and installation scope.
Verify use. Ask which instructions the selected agent loaded. For each required skill, distinguish present, discoverable and exercised on a relevant task. Keep account access and live deployment checks separate.
Prepare the guidance for your project
Replace the bracketed phrases with your idea. You can also describe it in your own words.
I want to build [what people should be able to do] for [the audience], with [the feel and constraints I care about]. Inspect this selected project and preserve its existing work. Prepare concise project instructions from the actual source: purpose, supported commands, boundaries and how to check the intended result. Reconcile existing AGENTS.md and product/design guidance rather than replacing it blindly. Recommend the smallest relevant skill/tool set, check trusted sources and compatibility, and verify what this agent can discover and use. Identify missing capabilities honestly. Handle routine local preparation within existing authority; ask for unavoidable sign-in, spending or consequential permissions. Keep credentials out of files and chat.
Get Ready does not yet install and exercise every relevant skill in every intended app project. This is work for the selected agent to inspect and prove. Official OpenAI documentation explains project instructions and skills; other agents can use different conventions.
New to agents, GitHub or Cloudflare?
Coding agent
The assistant doing technical work in your selected folder.
GitHub repository
The home for your app’s source and change history.
Cloudflare Worker
The deployed application that serves your site.
HTTPS
An encrypted connection to a web address. We also check that it serves the intended app.
The current supported setup path uses Codex on an Apple Silicon Mac with Node 22 and Git available. Other agents and systems need separate verification. Use the maintained first-setup instructions if you need help opening the agent.
What did you observe?
Optional personal notes. Tick only what you saw; move on or revisit any lesson.
A small deployed starter finds account, source and publishing problems before they become tangled with a larger app. Get Ready can also inspect an existing setup and reuse what already works.
Useful when
Start here if you do not yet know that your agent can publish to the intended account. If that environment is already verified, recheck what changed instead of reinstalling everything.
The trade-off
A Hello page proves a narrow path. A different app, database, private login or domain still needs its own checks. Your starter’s private source repository does not make its web page private.
Now hand over preparation. Get Ready uses one shared engine to check tools, GitHub source, Cloudflare access and a deployed starter. For a starter with a private source repository, begin with a temporary workers.dev address in an existing authorised Cloudflare account; you can consider a domain later.
Copy the setup request there, paste it into the agent for your folder and send it.
If the agent identifies a login, finish only that step on the provider’s official screen. Tell the agent when you are ready so it can recheck.
Open the HTTPS address it gives you. Ask it to match the live app to the intended repository and deployed source.
Copy a setup, inspection or resume request here
The agent checks what you already have, then prepares the supported starter. You handle sign-in and approve changes that need your say.
Read or copy the agent handoff
Prepare my environment before asking for an app idea. Use App Composer’s current Get Ready implementation at https://github.com/loftwah/app-composer. Read its trusted AGENTS.md and supported setup instructions in README.md; use the one lib/get-ready engine, not a new checklist or planner. Work in this authorised Codex folder. If a Get Ready MCP is already connected for this exact host-selected workspace and target, its check/inspect tools can perform read-only verification; they cannot execute setup. Otherwise use the same engine through the doctor command. Before changing an actual output project, use the same core’s inspectProject API or --inspect-project mode (or its host-selected get_ready_project tool). Inspect that project’s declarations, existing guidance and canonical skills without replacing them. Check user/plugin copies before installing duplicates. A file or matching entrypoint does not prove installed version, agent visibility, exercised capability or readiness; recheck the output project’s actual environment separately. Keep credentials out of chat and specifications, preserve existing files and save resumable evidence privately. Report what you actually checked, the next step and any precise human action. Give me a redacted progress JSON export using the doctor’s --report flag; never share its private receipt. Check the available tools, GitHub access and my selected Cloudflare account. If I select an existing custom domain, use the same core’s read-only diagnoseDomain API or --inspect-domain mode for the exact intended zone/account. Return its separate portable domain report, inspect nameserver/DNSSEC findings and preserve current website/email records. A resolver observation is not permission to change nameservers or proof of HTTPS. On the supported Apple Silicon Mac with Node 22 and Git, use the explicit install-workspace-tools step if GitHub CLI or pnpm is missing. Reuse verified prepared tools across the new checkout with tools-workspace; inspect partial folders before retry. Other repairs use official instructions. Continue independent checks when one step is blocked. Use supported operations to acquire the maintained Hello starter, prepare my private source and tools, then deploy to an unused workers.dev address in my existing authorised account. Confirm the intended owner and destination; never use the launch operator’s account or domain for me. Recheck the exact source over HTTPS. First accounts, new domains and unsupported runtimes still need separate setup: explain the gap honestly. Ask MP for unavoidable sign-in, purchases, expanded permissions or consequential approvals. Do not stop at a plan.
See actual check results
Ask the agent for its redacted Get Ready JSON export, then open it below. This reuses Get Ready’s report viewer and freshness checks. It reads the file locally. The private receipt is a different file and should stay private.
Your environment.
Waiting for your agent’s report
Let your agent check the environment. Its report will identify the next action and who needs to take it.
Open the report your agent gives you. Each result comes from the same checks used to prepare and deploy the app.
Read on this device; never uploaded. Use the report your agent exports, not its private readiness.json file.
No report loaded.
Agent and tools
Not checked here
Git, GitHub CLI, pnpm and the active coding-agent workspace.
GitHub workspace
Not checked here
The actual repository, source and required access.
Cloudflare connection
Not checked here
The selected account and deployment tools.
Live HTTPS app
Not checked here
The intended app, exact source and selected address.
This is a dated agent report, not a live check. Recheck after changing your environment. This report grants no access or permission to build or deploy.
For sign-in or account access, use the maintained account instructions. For a missing tool, let the agent inspect and repair the supported setup. A provider outage needs a bounded retry; a changed target needs a fresh check. Preserve partial work instead of restarting blindly.
First-account creation, broader agent/OS coverage and new-domain bootstrap remain incomplete. Check current release evidence before choosing an unsupported path. A domain purchase or a new billing commitment needs your approval.
Why start without a domain?
A workers.dev address lets you test the supported private starter before moving DNS or buying a name. It still needs your intended Cloudflare account and verified deployment access. Cloudflare explains workers.dev addresses.
What did you observe?
Optional personal notes. Tick only what you saw; move on or revisit any lesson.
A concrete brief makes the result reviewable: a visitor should be able to do a particular thing, with content and behaviour you can recognise. A portable specification makes those decisions easier to carry between tasks.
Useful when
Use Init when its supported settings fit. For an original standalone app, give the agent a plain-language brief and let it choose the smallest suitable implementation.
The trade-off
A template gives you a working starting shape but limits what its existing settings express. A custom build gives more control and leaves more implementation and maintenance to your project.
After your starter is verified, make one small change. For this first pass, configure a Hello page. Keeping the change small makes it easy to see whether the full journey works.
Try this sample: title My first corner, introduction A small place to start making things., theme Midnight. Or write your own.
For your verified private workers.dev starter, choose A temporary Cloudflare address. It describes your existing verified destination.
Select Save and preview. Inspect the words and theme, then use Download spec and Copy to Codex.
Check the draft before sending it
The portable specification should contain the title, introduction, theme and destination intent you selected. Your draft stays on this device. Saving and previewing it does not change a live app.
What is a specification?
A specification is a structured description of the app you want. It gives your agent a concrete starting point you can review and carry to another project. It contains configuration, never passwords or secret keys.
Decision Explorer helps compare meaningful choices without executing them. You can change your mind there without creating an app.
I want to start with photos instead
Init also exposes Guestbook and Showcase configuration. Explore those previews freely. The automated owned-starter update in this tutorial is the three-field Hello path; another customer app needs its own implementation and release verification. Lesson 5 shows the existing composed photo pair without asking you to deploy it first.
What did you observe?
Optional personal notes. Tick only what you saw; move on or revisit any lesson.
People use the deployed page, so check the intended address and main action after release. Keeping the source and deployed identity together makes later diagnosis and rollback clearer.
Useful when
Do this after a code release, configuration change, domain move or migration. A content-only publish also deserves a check that the intended public content appeared.
The trade-off
Check the changed journey and important dependencies. A health endpoint or green build is useful evidence, but neither proves every action works. Larger changes need broader verification.
Give your downloaded Hello specification and copied handoff to the agent in your verified starter folder. It should review the requested changes, follow the starter’s release rules and check the result online.
Try this
Ask the agent to confirm that the specification targets your already verified app and source.
Let it apply the supported title, introduction and theme changes, run the required checks, then commit and push the intended source.
After the authorised deployment, open your app’s exact HTTPS address and refresh. Compare the greeting and theme with your specification.
Ask the agent for the actual source revision, deployed identity and behaviour it checked. Keep that evidence with your project.
Ask for the result
Check the outcome of this Hello update. Compare the supplied specification with my intended repository and current live HTTPS hostname. Report the actual source revision, deployed identity, title, introduction and theme you verified. Separate local build results from live behaviour. If the update has not been deployed, name the exact remaining step and required authority; do not report it as complete.
If you still see the old greeting
Confirm the address first. Ask the agent to compare the live source with the new commit and investigate the release or cache. A working old page does not establish that the update succeeded. Keep the previous working release while the agent diagnoses the difference.
Understand the evidence
Build passed
The changed source can build locally.
Deployed
The provider accepted a release.
Live verified
The intended hostname serves the expected source and behaviour.
You tried it
You saw the result and used the page on your own device.
A mini-app is a focused application with its own source and a declared interface. Reusing a reviewed photo collector or curated display can save you rebuilding that feature; composition connects them when they need to share data or actions.
Useful when
Choose this when an existing feature fits, has a compatible interface and benefits from separate ownership or reuse. One coherent app with tightly coupled behaviour may be simpler to build directly.
The trade-off
Separate apps add contracts, version compatibility, deployment configuration and dependency failures to manage. Independent code does not guarantee independent data or uptime. You can use each app on its own.
You can build one app directly
Yes: ask your agent to build your own app on Workers with Astro and, if you need editable content, EmDash. You can choose your layout, data model and behaviour without adopting Composer’s mini-app contracts. You can also use the independent Get Ready capability without composing apps. Astro documents direct Cloudflare deployment; EmDash documents its own site setup.
Choose by the job you need to do
Approach
Benefit and responsibility
Build one app directly
Good for a distinctive workflow or tightly connected features. Your agent can design one coherent project without composition contracts.
Your project owns the feature implementation, permissions, updates and recovery. You can still reuse ordinary libraries.
Use a mini-app on its own
Good when a reviewed existing app already solves the problem. Guestbook and Showcase each have their own deployment and source.
Check licence, configuration fit, current behaviour and maintenance. Custom changes may require more work than the settings expose.
Compose mini-apps
Good when useful independent features need to exchange approved data or actions, as the photo collector and showcase do.
Check both apps and the connection: interface versions, access, source visibility, compatible updates and failure handling. Shared infrastructure can still fail together.
A sensible starting point: choose one app unless reuse or an independently maintained feature solves a concrete need. Splitting a small app into more parts is not automatically easier, cheaper or more reliable.
A direct-build request for your agent
Replace the bracketed phrases. This starts a project discussion and implementation through that project’s own rules; it is not a supported automated customer-provisioning operation in Composer.
Build a standalone app for [audience] that lets people [main task]. I want [content, design and constraints]. Inspect and preserve the selected project first. Recommend the simplest suitable structure: Astro for pages, Workers for required server behaviour, and EmDash only if editorial content needs it. Explain the benefits and trade-offs before adding independently deployed parts. Prepare concise project guidance and relevant skills, then implement a small complete journey. Use the intended authorised account and destination, existing release gates and live verification. Before valuable data is accepted, explain the backup, restore, access and cost requirements. Ask for human-only decisions or permissions; do not create a new paid commitment.
See where composition earns its place
Composition connects independently maintained apps through data and actions. Here / there owns contributed photos and their approval. Top shelf curates approved photos into a showcase and links each one back to its original.
On a composition you are authorised to manage, the fuller test is: submit a test photo, check that it is private, approve it, feature it, follow its source link, then hide it at the source. On the next public request, both controlled views should stop showing it. Ask the agent to verify the media URL too.
The public demo requires an invited owner credential for those writes. Browse it without an account; do not claim the moderation test from browsing alone. Downloaded copies cannot be recalled.
Why this is more than two links
The showcase asks the guestbook for currently eligible items through a versioned contract. Source repositories and storage remain independent. Composer pins the code versions it runs together, while current source visibility governs public content. See the architecture.
What did you observe?
Optional personal notes. Tick only what you saw; move on or revisit any lesson.
EmDash gives editors a place to manage structured content, media and publication. Astro supplies the page layer. A model helps decide which information people enter and how the app uses it.
Useful when
Add a CMS when people need to edit content without changing code, or need editorial workflows. A small static page can stay in Astro; custom app behaviour can live in a Worker.
The trade-off
A CMS adds a database, permissions, migrations, media handling and recovery work. Model previews express intent; required rules and access still need checking in the implemented app.
When an app needs structured content, plan the fields people will use. A collection groups entries of one kind; fields describe each entry. EmDash provides those content concepts, while Astro supplies the public pages.
Use a sample pattern, or design a small collection such as project notes: a title, a summary and a link.
Try the form with sample values. Check the required fields, help text and any conditions you chose.
Inspect the portable model and native EmDash seed export. Ask your agent to review them against the installed EmDash version before implementation.
Check the boundary
The builder lets you author and exercise a model locally. Its preview and seed export do not establish that a customer app has been built or deployed. The agent must implement the app, test its server-side rules and check the actual live form.
Coming from WordPress?
Collections, fields, media and draft/published states should feel familiar. The page layer and plugin implementation differ. A familiar concept does not guarantee that a particular WordPress plugin can be replaced without review. Read the official EmDash concept map.
When would a diagram help?
Use a diagram when it makes a relationship clearer: who can publish a photo, where content lives, or which app supplies a card. Ask for editable source, a readable phone version and a text explanation. Installing a diagram tool is useful only when you can use the result.
What did you observe?
Optional personal notes. Tick only what you saw; move on or revisit any lesson.
Clear words, readable layouts and predictable controls help people complete the task without learning your implementation. Watching someone use the app reveals confusion a code check can miss.
Useful when
Check the main journey early, then again when navigation, forms, content or layout change. Add a focused design or writing skill when it helps solve an observed problem.
The trade-off
Start with the task people need to complete. Extra animation, generic polish or a large tool pack can add cost without improving that task. Judge the rendered result and actual use.
A good-looking preview is a start. People need to understand the next action, read the content and recover when something goes wrong. Check those things on the page they actually use.
Try this on your app
Open it on your phone, or at a narrow browser width. Read the heading and use the main action. Look for sideways scrolling, tiny text or controls covered by other content.
Use a keyboard: Tab to the controls, notice the focus indicator, and activate buttons and links. Try any form with incomplete input.
Read the page’s words aloud. Replace vague promises with the action and useful result. Verify factual claims before publishing them.
Ask another person to complete the main task without coaching. Note where they hesitate, then give the agent that specific problem.
Ask for a focused quality pass
Review my current app’s main user journey. Check readable phone and desktop layouts, keyboard operation, visible focus, contrast, reduced motion and useful error recovery. Inspect the rendered page and exercise its actual controls. Fix the smallest material problems while preserving its identity and existing work. Run relevant checks and follow the project’s own release rules. Report what you verified and any device or human check still needed.
How do I spot generic AI writing?
Watch for promises that could describe any app, unnecessary slogans and claims with no source. Say what the user can do, use a concrete example and remove filler. A score from an AI detector cannot prove writing quality. Neither can having a design skill installed.
What can the agent verify automatically?
It can inspect layout, run code checks, exercise supported controls and compare intended content with live output. Those help find defects. Your physical device, your taste and someone else’s understanding still need direct observation.
What did you observe?
Optional personal notes. Tick only what you saw; move on or revisit any lesson.
Source ownership, a clear update path and a tested recovery procedure help you keep using the app when code, data or account access goes wrong. The right level depends on what people rely on it for.
Useful when
Decide before accepting valuable content or making the app important to someone else. Revisit before risky migrations and when the consequences of downtime or lost data change.
The trade-off
Backups, retention, monitoring and redundant deployments require attention and can cost money. Choose protection for a named failure and test it; adding more services alone does not establish resilience.
You should leave with an app you can find and a clear record of how it was released. Keep the source and configuration under your control. Ask the agent to leave recovery instructions that describe what has actually been tested.
Before you finish
Find your GitHub repository and app address. Ask which account owns each and which permissions are needed for future updates.
Keep the downloaded brief, relevant source revision and release evidence with the project. Store credentials through the project’s documented secret handling.
Ask what would happen if a release fails, a permission is revoked or you need to restore data. Separate a tested recovery path from a proposed one.
Choose your next small change, or stop here with your working starter. You can return to any lesson later.
Code history and data are different
Returning to an earlier code version must preserve current customisations and privacy. It should not make hidden photos public again. Data backup and restoration need their own evidence. General customer-source updates, cleanup and complete recovery remain open work; ask for the supported path for your particular app.
A backup gives you an earlier recoverable copy after deletion or corruption. Redundancy supplies another working path through a particular failure. Replicas or a mirror can repeat a mistaken deletion, and two deployments sharing the same account, database or provider can fail together. Mini-apps do not automatically provide either protection.
Decide how much recent data you could lose and how long the app could be unavailable. A personal static page and an app collecting irreplaceable contributions need different recovery plans. These targets guide the work; a restore rehearsal tells you whether you can meet them.
Source and configuration: retain committed code, dependency pins, owner customisations, destination settings and the matching release identity. Know how you would access these if the primary account became unavailable.
Database: check the actual recovery window, export needs and migration procedure for the selected environment. D1 Time Travel can restore a database within its plan-specific window; it overwrites that database and does not restore uploaded media. Check the current D1 recovery limits.
Media: preserve uploaded files as well as database references. Check representative file contents and a manifest against the backup. A copy that mirrors deletions without retaining a recoverable version is insufficient for deletion recovery.
Access and keys: keep account recovery and required encryption keys in an appropriate protected store, separately from public source and exported app specifications. Without required keys, a data copy may be unusable.
Before you rely on it: restore a permitted test dataset and files into an isolated environment, verify the main journey, and record what was recovered and how long it took. Choose retention and backup access that respect privacy; a restore must reconcile later deletions and revocations before anything is served publicly. EmDash’s recovery guide distinguishes database, media and key recovery. Worker rollback restores code, not bound storage.
What is a proportionate first setup?
For a small public site: keep source history, a repeatable release, checks of the main page and action, and a named update/recovery owner. When you collect valuable data, add protected recoverable database/media copies and a tested restore path. Consider a copy outside the production failure boundary when losing that account would also lose the backup.
Add a redundant deployment or failover only when the cost of downtime warrants it. Ask what exact failure it covers, how data stays consistent, how traffic switches and how you test the switch. More infrastructure adds cost and coordination. An alert can warn about usage; it is not a spending cap. Review actual provider costs before changing resources.
Ask for an app-specific recovery assessment
Inspect this app’s source, configuration, database, uploaded media, access and encryption-key dependencies. Explain what would be lost after a bad deploy, deletion, lost account or provider outage. Propose a proportionate backup/retention and recovery approach against my acceptable data loss and downtime; identify those targets if not decided. Separate configured protections from a successfully tested restore. Explain any redundancy benefit, shared failure points, maintenance and costs. Preserve current privacy and deletion decisions. Keep this assessment read-only; do not restore production, copy sensitive data, provision resources or add spend. Identify one bounded authorised restore rehearsal and the exact permissions it would require.
Ask for a useful handover
Summarise this app’s actual state for its owner. Give the intended repository and live URL, verified source and deployed identity, configuration to preserve, supported update and recovery steps, and exact unresolved checks. Distinguish code rollback from data restoration and keep current privacy decisions intact. Keep credentials, private records and raw provider responses out of the summary. Recommend one small next improvement, or explain why the current working app is a good stopping point.
