mobile-app-structure
Feature-folder layout, states/ convention, and data-flow rules for the Agenta mobile app (web/mobile). Use when creating or moving files under web/mobile, deciding where a component lives, adding a new feature or screen, or wiring data into mobile components.
git clone --depth 1 https://github.com/Agenta-AI/agenta /tmp/mobile-app-structure && cp -r /tmp/mobile-app-structure/.agents/skills/mobile-app-structure ~/.claude/skills/mobile-app-structureSKILL.md
# Mobile app structure
The source of truth for how code is organized in `web/mobile`. Load it before
creating any file there.
## Layout
```text
web/mobile/
src/
pages/ # Pages Router route shells ONLY — no logic, no layout JSX
features/
<feature>/ # e.g. sessions/, chat/, auth/, project-drawer/
<Component>.tsx # one component per file, named export = file name
states/ # designed states for this feature
<X>Skeleton.tsx # mirrors the final layout geometry (no shift on swap)
<X>Empty.tsx # designed empty state with a call to action
<X>Error.tsx # error + retry affordance; preserves user input
components/ui/ # shadcn registry components (see mobile-shadcn-conventions)
lib/ # cn util, motion presets, api glue, context resolution
styles/ # globals.css, theme.generated.css (generated)
scripts/ # generate-shadcn-tokens.ts (token bridge)
```
## Rules
- **Pages are thin shells.** A page file resolves route params and renders one
feature screen component. Anything else belongs in `features/`.
- **One component per file.** No secondary exported components; small private
helpers inside a file are fine if they never leave it.
- **Every data-bearing component has designed states.** Before writing the
happy path, create the `states/` siblings (skeleton, empty, error). A screen
is not done if any of its states is a browser default or an unstyled string.
- **Data flow:** components get data via hooks from `@agenta/*` packages
(`@agenta/entities`, `@agenta/shared`, later `@agenta/chat`) or thin fetchers
in `lib/`. NEVER import `@/oss/*`, `@agenta/oss`, `@agenta/ee` — the mobile
app has zero app-layer imports (lint enforces this).
- **No provider fleet.** `_app.tsx` stays minimal; add a provider only when a
concrete feature needs it, scoped as narrowly as possible.
## Adding a new feature (checklist)
1. Create `src/features/<feature>/` with the screen component.
2. Create `states/` siblings for every data-bearing component.
3. Add the route shell in `src/pages/` that renders the screen.
4. Use `useMotionPresets()` for any transitions (see mobile-motion-patterns).
5. `pnpm --filter @agenta/mobile lint && pnpm --filter @agenta/mobile types:check`.Helps add announcement cards to the sidebar banner system. Use when adding changelog entries, feature announcements, updates, or promotional banners to the Agenta sidebar. Handles both simple changelog entries and complex custom banners.
Playbook for adding a new coding-agent harness to Agenta (Codex, Hermes, Gemini, OpenCode, ...). Use when starting, planning, or reviewing a new-harness project. Covers the readiness audit of prior art, the spike-first milestone plan, the full integration-surface checklist, the per-harness variance axes to probe, and the process/communication contract with Mahmoud. Living document: every harness project appends its lessons to resources/LESSONS.md.
>-
Where to put frontend code (package vs app layer) and how to use the @agenta/* packages. Use when authoring or moving code in web/packages, choosing between @agenta/ui, @agenta/entities, @agenta/entity-ui, @agenta/shared, @agenta/playground, using molecules, loadable/runnable bridges, the EntityPicker, or writing package unit tests.
Use this skill to create and publish changelog announcements for new features, improvements, or bug fixes. This skill handles the complete workflow - creating detailed changelog documentation pages, adding sidebar announcement cards, and ensuring everything follows project standards. Use when the user mentions adding changelog entries, documenting new features, creating release notes, or announcing product updates.
Hard-won GitButler mechanics for multi-lane work in this repo — committing to a specific lane in a stack, spreading a pile of edits back across an existing stack, ordering a stack and setting PR bases, and recovering from a scrambled workspace. Use when working with stacked branches, when `but rub`/`but absorb`/`but commit --only` mis-routes a change, when a stack collapses or a commit lands on the wrong lane, or when a hunk gets dropped. Not needed for ordinary single-lane work.
Drive a researched and planned feature to a landed, tested change. Use after plan-feature has produced a docs/design/<project>/ workspace and the user says "implement it", "build the plan", "run the plan", or "let's ship this". Orchestrates refresh-plan, implement, review, a debug-local-deployment loop, and a test loop across the daytona / local-pi / claude x SDK / UI matrix, then documentation and a GitButler stacked branch. The orchestrator stays in the loop and spins narrow subagents for each phase.
Motion design rules for the Agenta mobile app (web/mobile) — the shared presets in src/lib/motion, when to animate, and reduced-motion requirements. Use when adding any animation or transition under web/mobile, animating navigation, sheets, skeletons, or list/chat surfaces.