Menu
The review-first prompt is selected by default. You can switch to a direct command or download a local copy.
Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
npx skills add https://github.com/different-ai/the-factory --skill cupid-app-architectureThe command stays on one line. Scroll horizontally to inspect it before copying.
Prefer a local copy? Download the files currently available to SkillsMP.
Drive the OpenWork dev renderer with Chrome MCP and verify workspace UI flows. Triggers when user mentions: - "use Chrome MCP with OpenWork" - "hook up to pnpm dev renderer" - "add an OpenWork workspace through the UI"
Create a PR with structured evidence: build verification, UI screenshots uploaded to an ephemeral host, API test results, and a verification comment. No screenshots committed to the repo. Triggers when user mentions: - "create a pr" - "make a pr" - "open a pr" - "push and pr"
Boot up the Den dev stack and the OpenWork desktop app locally, then test common flows like sign-in, dashboard, and telemetry. Triggers when user mentions: - "test den" - "test the app locally" - "boot up den" - "den dev flow" - "test sign in"
Showing SKILL.md
Based on SOC occupation classification
| name | cupid-app-architecture |
| description | CUPID app architecture guidance for apps/app/src/app/** |
Use this skill when changing ownership, file placement, or structure inside apps/app/src/app/**.
This is an incremental migration guide, not a rewrite mandate.
Goals:
app.tsx, pages/*, and generic utils/*apps/app/src/app/**app.tsx, pages/dashboard.tsx, pages/session.tsx, pages/settings.tsxDo not use this skill to justify broad rewrites. Move one coherent slice at a time.
Use these domains for apps/app/src/app/** work:
Owns app-wide composition only:
Examples today:
apps/app/src/app/app.tsxapps/app/src/app/entry.tsxcontext/*.tsxShell should orchestrate domains, not absorb their feature logic.
Owns workspace lifecycle and workspace-scoped controls:
Examples today:
context/workspace.tscomponents/create-workspace-modal.tsxcomponents/create-remote-workspace-modal.tsxcomponents/rename-workspace-modal.tsxlib/workspace-blueprints.tsOwns active task/session experience:
Examples today:
pages/session.tsxcomponents/session/*context/session.tslib/opencode-session.tslib/session-title.tsOwns connections to external capabilities and providers:
Examples today:
components/provider-auth-modal.tsxcomponents/mcp-auth-modal.tsxcomponents/add-mcp-modal.tsxmcp.tsutils/providers.tsPractical rule:
connectionsconnectionsOwns scheduled or repeatable work setup:
Examples today:
context/automations.tspages/scheduled.tsxOwns hosted OpenWork and Den-specific flows:
Examples today:
lib/den.tslib/den-template-cache.tscomponents/den-settings-panel.tsxlib/openwork-deployment.tsOwns app-wide preferences and local app controls:
Examples today:
pages/settings.tsxtheme.tslib/font-zoom.tsKernel is the smallest shared layer.
Only put code here when all of the following are true:
Good fits:
Bad fits:
utilsUse these defaults when deciding where code belongs:
workspace.connections, even if launched from dashboard or settings.connections.session.cloud.app-settings.If a feature has one clear user-facing owner, keep its state, view pieces, and helpers there.
Prefer this direction:
shell -> domain public API -> local domain internals
Rules:
kernel primitives.index.ts, api.ts, or a clearly named module.Within one domain, colocate:
Do not split code across components/, context/, lib/, and utils/ just because those buckets already exist.
When touching existing generic folders, prefer creating a domain subfolder and moving only the code you are already changing.
Keep code in shell only if it is truly app-global:
If logic answers a domain question like “how do workspaces connect?” or “how does provider auth start?”, it probably does not belong in shell.
Create a new domain only when the work has:
Do not create a new domain for one helper or one modal.
If the work is still clearly part of workspace/session/connections/automations/cloud/app-settings, use a subfolder there instead.
When touching existing app architecture:
Good incremental moves:
pages/settings.tsx into connections/providers/*app.tsx into workspace/*components/session/*Bad moves:
utils/ because the correct domain feels inconvenientapp.tsxpages/* because it is already therehooks.ts, helpers.ts, or utils.ts files without a domain ownerFor app-architecture work:
app.tsx?If the answer to several of these is “no”, stop and simplify the move.