web-nuxt has a dedicated skills entry for prompt-driven customization. The goal is simple: let a builder describe the product change in natural language, then let Codex map that request onto the right files and shared layers.
Recommended skill stack
$onboard: use first when you need the repo map or want to confirm which layer owns a feature.$customize-web-nuxt: use when editingapps/web-nuxtdirectly: landing hero, pricing, docs, auth, guest-demo, dashboard entry flow, or app-level proxy routes.$create-app: use when you want a separate frontend copied fromapps/web-nuxtinstead of modifying the template in place.$customize-brand: use after copying the app, or when the change is mostly manifest-driven branding and SEO.$add-page: use when the new product surface needs its own route.$add-dashboard: use when the user dashboard needs a new feature tab or activation area.
In-place editing vs copied app
Use $customize-web-nuxt when apps/web-nuxt itself is the working frontend.
Use $create-app first if you want tenant isolation, a new package name, or a product frontend with its own release cadence. After that, use the other skills against the copied app.
Main edit surfaces
apps/web-nuxt/zship.app.json: brand identity, SEO, footer, analytics, dashboard feature flags.apps/web-nuxt/app/components/LandingPage.vue: hero, CTA flow, marketing sections, testimonials, closing CTA.apps/web-nuxt/app/pages/pricing.vue: pricing layout, comparison table, sales CTA.apps/web-nuxt/content/docs/*: user-facing docs content in English and Simplified Chinese.apps/web-nuxt/server/api/*: public-page server proxies.
Practical workflow
- Start from the repo root.
- Invoke the skill explicitly in your prompt.
- Describe the product change, not just the file name.
- Let Codex inspect the current implementation before patching.
- Ask for verification on the affected route after the change lands.