mit einem Klick
outside-in-mode
// Use this when designing an internal tool or operational app where the safest path is to prove the workflow and UI before locking in backend structure.
// Use this when designing an internal tool or operational app where the safest path is to prove the workflow and UI before locking in backend structure.
Use Beads (`bd`) as the durable task-management system for work that needs priorities, dependencies, status tracking, and cross-session continuity.
Turn a one-line objective into a step-by-step construction plan where every step has a self-contained context brief. Designed for work that spans multiple sessions or agents.
Treat diagnosis as a first-class phase before fixing a bug, unstable behavior, or weird operational issue.
Use contracts, templates, and durable markdown artifacts consistently when a workflow needs handoffs, plans, context bundles, decisions, or verification evidence.
Create a practical understanding of a repository or a large area before detailed work begins.
This is the meta-skill -- it teaches how to build skills that AI agents can
| name | outside-in-mode |
| description | Use this when designing an internal tool or operational app where the safest path is to prove the workflow and UI before locking in backend structure. |
| pack | skills-outside-in |
Use this when designing an internal tool or operational app where the safest path is to prove the workflow and UI before locking in backend structure.
Work in this order:
Do not jump straight to database tables, service layers, or event pipelines unless the user explicitly wants backend-first design.
Create or update these artifacts as needed:
wireframe-planmock-data-planapi-contract-setUse the toolkit contracts as the durable output layer:
contracts/wireframe-plan/CONTRACT.mdcontracts/mock-data-plan/CONTRACT.mdcontracts/api-contract-set/CONTRACT.mdUse templates/outside-in/ only as supporting design references when the
contract template needs more detailed domain-specific structure.
First determine:
Primary skill:
workflow-discoveryTurn jobs into:
Primary skill:
screen-flow-designCreate:
Then validate that the UI flow can operate against those mocks.
Primary skills:
mock-data-designmock-api-contractsOnce the mocked slice makes sense, derive:
Primary skill:
backend-derivationOnly after the validated slice exists, define:
Primary skill:
infra-derivation| Don't | Do Instead |
|---|---|
| Start from database tables | Start from user jobs and screens |
| Model the entire backend first | Prove one workflow slice first |
| Use unrealistic mock data | Use realistic records and edge cases |
| Design internal services before UI actions are clear | Let screen actions drive contract design |
| Over-spec infrastructure on day one | Derive infra after workflows and contracts stabilize |