recipebooq

Finds the component for a UI need described in plain words, ranked, and says when this catalog ships nothing on purpose because the phone's own control is the right choice. Omit `need` to list every component with its purpose and whether it renders the real system control.

{
  "type": "object",
  "properties": {
    "need": {
      "type": "string",
      "description": "e.g. \"a progress bar for an upload\""
    },
    "category": {
      "type": "string",
      "enum": [
        "controls",
        "chrome",
        "surfaces"
      ]
    }
  }
}

Everything needed to write a correct call site for one component: props with types, defaults and allowed values, what draws on iOS and on Android, the providers it needs at the app root, its dependencies, and the runtime rules that stop it rendering blank.

{
  "type": "object",
  "properties": {
    "slug": {
      "type": "string",
      "description": "e.g. \"button\""
    },
    "platform": {
      "type": "string",
      "enum": [
        "ios",
        "android"
      ],
      "description": "only the rules that hold there"
    }
  },
  "required": [
    "slug"
  ]
}

Scans TSX that uses these components for the mistakes that render nothing with no error: animated opacity on glass, the flex: 1 collapse, a clipped lens, a conditionally mounted surface. A read-only text scan, not a guarantee; verify_app checks a whole emitted project.

{
  "type": "object",
  "properties": {
    "code": {
      "type": "string",
      "description": "the TSX to check"
    }
  },
  "required": [
    "code"
  ]
}

How an app is set up so these components work and follow its theme, one topic at a time: the app-root providers in the order that works, the theme hooks and token scales, or the rules that hold across the whole catalog. An app built by emit_app already has all three wired.

{
  "type": "object",
  "properties": {
    "topic": {
      "type": "string",
      "enum": [
        "providers",
        "theme",
        "rules"
      ]
    },
    "platform": {
      "type": "string",
      "enum": [
        "ios",
        "android"
      ],
      "description": "rules only"
    }
  },
  "required": [
    "topic"
  ]
}

Needs a subscription. Turns an App Designer design into a working Expo app: navigation, providers, tab bar, screens and the components they use. Returns a recipe for the current project: every file with its target path, one install line and ordered steps with a check each. Pass `step` for one step in full, which does not count against the daily allowance.

{
  "type": "object",
  "properties": {
    "appId": {
      "type": "string",
      "description": "the share code from the App Designer's \"Send app to agent\", e.g. \"34ca4babb2\""
    },
    "override": {
      "type": "boolean",
      "description": "emit even with screens flagged not ready; ask the customer first"
    },
    "step": {
      "type": "string",
      "description": "a step id from the recipe, or \"review\" for the screen list"
    },
    "page": {
      "type": "number",
      "description": "for step write or review; each page names the next"
    }
  },
  "required": [
    "appId"
  ]
}

Needs a subscription. Adds one screen designed in the App Designer to a project. With the project's .opointo/files.json it returns the screen file, the route that mounts it and the one line to register it, and never rewrites existing files. Without it, a self-contained screen file for any Expo app.

{
  "type": "object",
  "properties": {
    "appId": {
      "type": "string",
      "description": "the share code from \"Send app to agent\""
    },
    "screen": {
      "type": "string",
      "description": "the new screen's name in that design"
    },
    "manifest": {
      "type": "object",
      "description": "the parsed .opointo/files.json"
    },
    "tab": {
      "type": "string",
      "description": "nest it in this tab's stack; omit to place it where the design does"
    },
    "componentName": {
      "type": "string",
      "description": "only to add a second copy of a screen; omit for the export's name"
    }
  },
  "required": [
    "appId"
  ]
}

Needs a subscription, except for the free foundation components. Adds one component to an existing project: the files it and its dependencies need in install order with exact target paths, the single expo install line, the providers it needs and its runtime rules. A backend recipe's id, such as "supabase", adds that integration: its files and the per-app wiring an export writes.

{
  "type": "object",
  "properties": {
    "slug": {
      "type": "string",
      "description": "e.g. \"button\", or a recipe id such as \"supabase\""
    }
  },
  "required": [
    "slug"
  ]
}

Needs a subscription. Reads the project's .opointo/files.json and returns only the opointo-supplied files that changed since export, so it works months later with no share code. Never touches the customer's own screens, and flags the rare change that needs a code edit rather than a copy.

{
  "type": "object",
  "properties": {
    "manifest": {
      "type": "object",
      "description": "the parsed .opointo/files.json (the object or its files array)"
    },
    "current": {
      "type": "array",
      "description": "only when a split-unverified blocker asks: each named file's hash, from its command",
      "items": {
        "type": "object",
        "properties": {
          "path": {
            "type": "string"
          },
          "sha": {
            "type": "string"
          },
          "missing": {
            "type": "boolean"
          }
        },
        "required": [
          "path"
        ]
      }
    },
    "acceptSplit": {
      "type": "array",
      "items": {
        "type": "string"
      },
      "description": "only once the customer agreed: the paths split-customer-edited blockers name"
    },
    "page": {
      "type": "number",
      "description": "only when the answer's page.next asks for it"
    }
  },
  "required": [
    "manifest"
  ]
}

Needs a subscription. Checks an emitted app before it is built: missing files, altered copy-verbatim files, absent packages, the config merge expo-router needs, and whether the installed Xcode can build the project. Takes the files written with byte sizes, package.json dependencies, project config and toolchain versions.

{
  "type": "object",
  "properties": {
    "appId": {
      "type": "string",
      "description": "the share code given to emit_app; `appId` in .opointo/files.json"
    },
    "files": {
      "type": "array",
      "description": "each file written, the hidden .opointo/files.json included: { path, bytes }, path from the project root",
      "items": {
        "type": "object",
        "properties": {
          "path": {
            "type": "string"
          },
          "bytes": {
            "type": "number",
            "description": "size in bytes on disk as `wc -c` reports, not the character count"
          },
          "sha": {
            "type": "string",
            "description": "optional; when sent, the byte check is skipped"
          }
        },
        "required": [
          "path"
        ]
      }
    },
    "dependencies": {
      "type": "array",
      "items": {
        "type": "string"
      },
      "description": "package.json dependencies' keys"
    },
    "config": {
      "type": "object",
      "properties": {
        "main": {
          "type": "string",
          "description": "package.json \"main\""
        },
        "scheme": {
          "type": "string",
          "description": "app.json"
        },
        "plugins": {
          "type": "array",
          "items": {
            "type": "string"
          },
          "description": "app.json"
        },
        "userInterfaceStyle": {
          "type": "string",
          "description": "app.json"
        },
        "moduleSuffixes": {
          "type": "array",
          "items": {
            "type": "string"
          },
          "description": "tsconfig compilerOptions"
        },
        "nativeModulesDir": {
          "type": "string",
          "description": "package.json expo.autolinking; omit if unset"
        },
        "icon": {
          "type": "string",
          "description": "app.json"
        },
        "monochromeImage": {
          "type": "string",
          "description": "app.json android.adaptiveIcon"
        },
        "supportsTablet": {
          "type": "boolean",
          "description": "app.json ios"
        }
      }
    },
    "toolchain": {
      "type": "object",
      "properties": {
        "xcode": {
          "type": "string",
          "description": "`xcodebuild -version`, e.g. \"26.2\"; omit without Xcode"
        },
        "expoSdk": {
          "type": "string",
          "description": "the INSTALLED expo version, e.g. \"56.0.15\" (`npm ls expo`)"
        },
        "expoBuildProperties": {
          "type": "string",
          "description": "the INSTALLED expo-build-properties version; omit if absent"
        },
        "enableSceneSupport": {
          "type": "boolean",
          "description": "app.json expo-build-properties ios.enableSceneSupport"
        }
      }
    }
  },
  "required": [
    "files"
  ]
}

Your agent can design an app with you: send an app in opointo's design format (the AppSpec emit_app builds from) and get back a link that opens it in the App Designer as a new, unsaved design. The person sees every screen and the navigation, changes what they like, and hands it back for emit_app. Each problem comes back with its path and a fix. dryRun checks without making a link; format: true returns the format and every block.

{
  "type": "object",
  "properties": {
    "app": {
      "type": "object",
      "description": "The design: { name, tabs: [{ screenId, label }], screens: [{ id, name, composition: { screen: { content: { children: [node] }, chrome: { header?, headerItems?, floating: [] }, overlays: [] } } }], onboardingScreenIds: [], pushed: [{ screenId, fromScreenId, presentation }], theme? }. A node is { id, slug, props }: slug is \"wireframe:<block>\" such as \"wireframe:list-row\" (a list whose rows open one screen is one row block with repeats: \"true\" and its sample rows in rows: [{ title, ... }]) or a component from find_component, and a content node opens a screen with navigate: { to, presentation } beside its props. A top bar is header: { id, slug: \"header\", props: {} }, titled by the screen's name; a sheet has none. entryScreenId is only for a splash screen before the tabs. Tab icons, titles and composition metadata are set by the builder."
    },
    "dryRun": {
      "type": "boolean",
      "description": "check the design and report, without making a link"
    },
    "format": {
      "type": "boolean"
    }
  }
}

Your agent can design a single screen with you: send one screen in opointo's design format (the Composition add_screen builds from) and get back a link that opens it in the App Designer as a new, unsaved design the person can change. Each problem comes back with its path and a fix. dryRun checks without making a link; format: true returns the format. For a whole app with navigation, propose_app is the matching tool.

{
  "type": "object",
  "properties": {
    "composition": {
      "type": "object",
      "description": "One screen: { name, screen: { content: { children: [node] }, chrome: { header?, headerItems?, floating: [] }, overlays: [] } }. A node is { id, slug, props }: slug is \"wireframe:<block>\" or a component from find_component."
    },
    "dryRun": {
      "type": "boolean",
      "description": "check the screen and report, without making a link"
    },
    "format": {
      "type": "boolean"
    }
  }
}