| name | fabrico-modernize |
| description | Create a migration plan and rebuild on the selected target. |
Invocation portability: $fabrico-* below means the discovered entry workflow. Use the unqualified name for repository or filesystem installs and $fabrico-collections:fabrico-* for plugin installs.
Input
Use the user’s current request as the workflow input. Expected context: <url of running app | path to SPEC.md> [target: web|ios|react-native].
Delegate the build phase to the fabrico-engineering-manager custom agent once the spec and migration plan
exist. Spawn it through Codex subagent delegation and adopt the autonomy contract from
$fabrico-autopilot for the rebuild. If that profile is unavailable, as in a skills-only plugin installation,
perform the build phase in the current thread with the referenced skills and the same autonomy and quality gates.
Goal
Take an existing web application and rebuild it on a modern target — modern web, native iOS, or cross-platform
React Native — preserving behavior and reaching feature parity, with as little manual babysitting as possible.
Required skills
fabrico-reverse-engineering-spec — to derive the SPEC if given a URL.fabrico-planning-migration — to choose/confirm the target, build the parity matrix, and plan data/auth/UX.fabrico-technical-context-discovering, fabrico-architecture-designing — for the target architecture.
Workflow
- Get the SPEC. If
the user’s request is a URL → run the $fabrico-reverse-spec flow first to produce SPEC.md.
If it's a path to an existing SPEC.md → use it. If neither is resolvable → ask the user (direct user question).
- Determine the target. Read it from
the user’s request (web | ios | react-native). If absent, use
direct user question to pick one (with the trade-offs from fabrico-planning-migration). Write the chosen target
into the SPEC's Target section.
- Plan the migration. Follow
fabrico-planning-migration to produce MIGRATION-PLAN.md: stack mapping,
feature-parity matrix (port-as-is / adapt / drop), data migration, auth, UX adaptation (esp. web → mobile),
risks, and phasing.
- Review checkpoint (single gate). Present a concise summary of
SPEC.md + MIGRATION-PLAN.md and the open
questions, and ask the user to confirm or edit the target, parity decisions, and any dropped features. (If the
user said to run fully autonomously, skip this gate, log decisions to ASSUMPTIONS.md, and continue.)
- Rebuild autonomously. Delegate to
fabrico-engineering-manager using the $fabrico-autopilot autonomy
contract: scaffold the target stack → implement each story in parity-matrix order with tests → run quality
gates → git commit per feature → code review. Honor the data-migration and integration plan (stub external
services behind interfaces until the user provides keys).
- Output
BUILD-SUMMARY.md plus a parity report: each legacy feature → built / adapted / pending, what
the user must still provide (keys, data export access, Apple developer account for iOS), and how to run/build.
Constraints
- Preserve behavior; modernize presentation. Don't drop a legacy feature without it being marked in the parity
matrix and confirmed.
- Never commit secrets; never deploy, charge, send real messages, or migrate production data without explicit
approval. Use
.env.example and a mock/stub for any integration whose credentials aren't provided.
- For
ios (SwiftUI), building/running on-device needs Xcode + an Apple developer account — note this in the
summary; produce the buildable project and tests regardless.
