This guide is for external collaborators who get their own Discord channel and want to create an app with the Fable Labs AI system.

It assumes you do not code yourself, but you are comfortable using AI tools, giving feedback, thinking through product details, and testing things carefully.

How to use this guide

This online guide is further reading for people who have already received their own app channel. Start the actual work in your Discord channel; use this page when you want the full workflow, boundaries, and examples.

Deeper guide

1. What this system is

The Fable Labs AI system is a working app-building environment inside Discord.

You will get a dedicated channel named after you, for example #grete. That channel becomes the place where you and the AI collaborators work on your app.

You can use the system to:

• develop an app idea
• define the app clearly
• choose an app name and repo name
• plan screens and features
• create screenshot/mockup directions
• build an iOS app from the Fable skeleton workflow
• test the app in the simulator
• prepare TestFlight builds
• prepare App Store text and screenshots
• iterate from feedback

This is not a polished consumer product. It is an ongoing internal development system. Treat it like working with a skilled AI development team that is still under active construction.

2. Your channel

Your channel is your workspace.

Use it for:

• all app idea discussion
• product decisions
• screen planning
• app name discussion
• design feedback
• implementation requests
• testing notes
• TestFlight preparation

Try to keep decisions in the channel instead of scattered across DMs. That gives Odin context and makes it easier to continue work later.

3. What you should do first

Start with a short message like this:

I want to create an app for [target user].
The problem is [problem].
The first version should help them [main outcome].
I want the style to feel [simple / playful / premium / calm / serious / etc.].
Please help me turn this into a clear app concept and MVP plan.

If you do not have a finished idea, say that. Odin can help you explore.

A good first goal is not “build the app”. A good first goal is:

Define the smallest clear version of the app that can be tested.

4. The normal workflow

Step 1 — Idea

Explain the app idea in plain language.

Useful things to include:

• who the app is for
• what problem it solves
• what the user should be able to do in the first version
• what kind of feeling the app should have
• examples of apps or designs you like
• what you definitely do not want

Ask Odin:

Help me sharpen this app idea into a clear first version.
Ask questions if something is unclear.

Step 2 — Specs

Before anything is built, ask for a short product spec.

Ask Odin:

Create a simple MVP spec for this app:
- target user
- core problem
- main screens
- first version features
- what we should not build yet
- open questions

This prevents the app from becoming too big too early.

Step 3 — Name and repo name

Before the project is created, decide the app name and repo name together with Odin.

The app name can be changed later, so do not get stuck forever. But the first name should be good enough to build around.

Ask Odin:

Suggest app names and repo names for this concept.
Keep them simple, memorable, and suitable for an iOS app.

The repo should be created using the Fable skeleton workflow. You do not need to manage the technical details yourself.

Step 4 — Screen plan

Before visual design, create a screen plan.

Ask Odin:

Create a screen-by-screen plan for the first version.
For each screen, include purpose, content, buttons, empty states, and what happens when the user taps the main actions.

A good screen plan makes implementation much smoother.

Step 5 — Screenshots and mockups

Odin coordinates the design work. You normally talk to Odin in your app channel; Odin brings in Ram when design screenshots are needed.

Ram is our designer. He can create screenshot-style mockups that make the app idea feel real before we start coding.

Use Ram for first-pass visual direction: the look, mood, layout, and key screens. The screenshots are a basis for discussion and implementation, not final truth. Before coding, Odin/Ram should review them for consistency, usability, and any details that must be corrected.

You can ask Odin:

Odin, ask Ram to create screenshot concepts for this app based on the current screen plan.
Use realistic iPhone UI, clean App Store-ready design, and show the key screens.
Afterwards, review the screenshots for consistency, correctness, and what must be fixed before implementation.

Or, if you prefer using your own ChatGPT for the screenshot concepts:

Create iPhone app screenshot mockups for this app.
Style: [describe style].
Screens: [list screens].
Make them realistic enough to guide SwiftUI implementation.

The goal is not perfect marketing screenshots yet. The goal is to make the app direction visible enough that we can build it.

Step 6 — Create the app project

When the idea, name, repo name, and first screen plan are clear, Odin can help create the app project using the Fable skeleton workflow.

You should not need to understand the technical details.

Ask Odin:

The app name and first version are now clear. Please create the app project from the Fable skeleton workflow and explain what decisions you need before starting.

Step 7 — Build the first version

Build in small steps.

Good requests:

Implement the first version from the MVP spec. Start with the main flow only.

Build the home screen and one complete user flow first. Do not add extra features yet.

Run the app in the simulator and tell me what works, what is missing, and what I should review.

Avoid asking for everything at once. Small steps produce better apps.

Step 8 — Simulator screenshots

Once the app runs, ask for simulator screenshots.

Run the app in the simulator and capture screenshots of the main screens.
Compare them against the design direction and list what should be improved.

This is where you give visual feedback:

• too cluttered
• too plain
• wrong colors
• buttons unclear
• text feels generic
• flow is confusing
• looks good, continue

Step 9 — TestFlight

TestFlight is Apple’s beta testing system for iOS apps.

When the app is good enough to test on a real iPhone, it can be uploaded to TestFlight. Then you can install it through Apple’s TestFlight app and try it like a real app.

Important: the App Store Connect app record currently requires manual help from a Fable Labs admin.

When ready, ask:

I think this is ready for TestFlight. Please check what is missing before upload, and tell me what a Fable Labs admin needs to do manually.

Odin can help prepare the app, metadata, build, screenshots, and release checklist. A Fable Labs admin has to handle the manual App Store Connect app creation step when needed.

Step 10 — App Store preparation

Before release, prepare:

• app name
• subtitle
• description
• keywords
• screenshots
• privacy details
• support/contact info
• final build
• known limitations

Ask Odin:

Prepare an App Store readiness checklist for this app.
List what is done, what is missing, and what a Fable Labs admin must handle manually.

When the app is release-ready, a Fable Labs admin manually sends it to Apple for review. Then we wait for Apple. Review can pass, fail, or ask for changes.

5. What can be automated

Odin and the system can help with most of the work:

• app idea shaping
• MVP planning
• app naming suggestions
• repo/project creation from the skeleton workflow
• screen plans
• UI implementation
• simulator testing
• screenshot capture
• bug fixing
• TestFlight preparation
• App Store metadata drafts
• release checklists
• explaining technical decisions in plain language

6. What is manual right now

A Fable Labs admin currently has to help with some steps:

• creating the app in App Store Connect when needed
• final TestFlight/App Store account-level decisions
• manually submitting the app to Apple review when release-ready
• handling Apple review responses when they require account-owner action
• helping if the Fable Labs AI system breaks or behaves strangely

If you reach one of these points, ask clearly in your channel first. Odin can prepare the checklist, then a Fable Labs admin can step in.

If something is broken or confusing, ask a Fable Labs admin in the shared help/general channel.

7. Boundaries

You can ask for help with your app.

You cannot ask to change:

• OpenClaw settings
• AI agent definitions
• system prompts
• skills
• shared memory/bootstrap files
• Fable Labs website
• other people’s app channels or repos
• infrastructure/security/domain settings

If your app needs something outside your channel’s scope, Odin may tell you that a Fable Labs admin has to approve or handle it.

8. How to write good requests

Good requests are specific.

Instead of:

Make it better.

Say:

The home screen feels too generic. Make it more premium and focused. Keep the same features, but improve spacing, typography, and the main call-to-action.

Instead of:

Build the app.

Say:

Build the first version with these three screens: onboarding, home, and detail. Keep settings and accounts out of scope for now.

Instead of:

I don’t like it.

Say:

I don’t like the colors or the amount of text. Make it calmer, with fewer labels and more visual hierarchy.

9. Useful commands and habits

/btw

Use /btw when you want to add side information without derailing the current work.

Example:

/btw I like the style of Duolingo’s progress screens, but less childish.

Ask for a plan first

Before a big change:

Before building, give me a short plan and tell me what decisions are still open.

Ask for tradeoffs

Give me 2–3 options and recommend one.

Ask for scope control

What should we leave out of version 1?

Ask for a review

Review the current app like a critical product designer. What is weak, confusing, or unnecessary?

Ask for next steps

What is the next concrete step to get this closer to TestFlight?

10. What not to worry about

You do not need to know:

• Swift
• Xcode
• Git
• app signing
• build numbers
• repository setup
• simulator commands

Odin can handle or explain those when needed.

Your job is to be clear about the product:

• who it is for
• what it should do
• what feels right or wrong
• what should be included now
• what should wait until later

11. When things go wrong

Sometimes the system will misunderstand, fail, get stuck, or produce something that is not good enough. That is normal.

Best response:

1. Say what is wrong.
2. Give a concrete correction.
3. Ask Odin to inspect before changing too much.
4. If it seems like the system itself is broken, ask a Fable Labs admin in the shared help/general channel.

Example:

This is not what I meant. The app should be simpler and more focused on one daily habit. Please restate the concept and ask me 3 questions before changing the implementation.

12. The best mindset

Think of the system as a fast AI app workshop.

You do not need to code. But you do need to make product decisions.

The better you explain the user, the problem, the feeling, and the first version, the better the app will become.