home / skills / uzhussain / copycat / copycat

copycat skill

/SKILL.md

This skill inventories a Next.js app's public and authenticated views, confirms view names with you, and plans a shadcn-based clean platform scaffold.

npx playbooks add skill uzhussain/copycat --skill copycat

Review the files below or copy the command above to add this skill to your agents.

Files (2)
SKILL.md
4.2 KB
---
name: copycat
description: Inventory a Next.js app's marketing and dashboard views by authenticated vs unauthenticated roles, confirm view names with the user, and plan a shadcn-based clean platform scaffold in a separate App Router folder using user-confirmed naming and route segments. Use when auditing role-based views, planning shadcn UI recreation, or splitting auth vs public routes.
---

# Next.js Auth View Discovery + Clean Platform Scaffold

## Quick start
1) Identify router type and entry points.
2) Inventory routes, auth boundaries, and roles.
3) Run a route naming audit (librarian pass).
4) Confirm the view list and new names with the user.
5) Derive the platform name and route segment from existing copy.
6) Scaffold `app/<platform-segment>` public/app layouts.
7) Add the landing header dropdown link.
8) Smoke-test public and auth routes.

## Scope
Does:
- Inventory public vs authenticated routes and role gates.
- Confirm view naming and scope before scaffold.
- Create a clean App Router subtree for the new platform.
- Keep legacy routes intact and isolated.

Does not:
- Migrate every legacy screen.
- Change auth logic or delete old code.

## Required inputs
Derive before scaffolding (do not ask the user):
- `platformName`
- `platformRouteSegment`
- `platformFolderName` (default: `platformRouteSegment`)
- `landingDropdownLabel` (default: `platformName`)
- `landingDropdownItemLabel` (default: `platformName`)

## Rule categories by priority
| Priority | Category | Rules |
| --- | --- | --- |
| 1 | Discovery & confirmation | `rules/discovery-auth-views`, `rules/route-naming-audit`, `rules/confirm-view-names`, `rules/platform-naming-derive` |
| 2 | Platform scaffold & boilerplate | `rules/routing-platform-scaffold`, `rules/boilerplate-first` |
| 3 | Coexistence & entry | `rules/coexistence-legacy`, `rules/landing-header-dropdown` |
| 4 | Naming & testing | `rules/naming-clean`, `rules/test-auth-flows` |

## Output: view inventory template
```
UserRole: <role name>
Public views (unauthenticated):
- <View Title> -> <route> (source: <file>)

Authenticated views:
- <View Title> -> <route> (source: <file>)

Role-specific views:
- <View Title> -> <route> (role gate: <where>)

Status:
- Recreate in new platform: YES / NO
- Rename required: YES / NO
- New name (if renamed): <confirmed title>
 - Active in UI navigation: YES / NO
 - Evidence of activity: <nav link | redirect | deep link | comment>
```

## Rules (must follow)
- Boilerplate-first: only scaffold confirmed views.
- Confirmation-first: do not scaffold before view list + naming is confirmed.
- Clean naming: no `New*`, `*V2`, `Temp*`, legacy prefixes.
- Legacy isolation: do not import legacy CSS into new platform layouts.
- Shadcn-first: use shadcn components via CLI or MCP.
- Shadcn install: use MCP to add all components upfront, then reuse.
- Shadcn blocks: prefer `sidebar-16`/`sidebar-01`, `dashboard-01`, `login-04`, `signup-02`.
- Global CSS baseline: use shadcn create preset (nova/zinc/orange).
- No legacy UI kits: do not use Ant/Chakra/etc in new routes.
- Auth parity: align new auth routes with historical provider and users.
- No legacy CSS: enforce new baseline styles only.
- Keep new routes under `app/<platform-segment>`.

## Platform structure
```
app/
  <platform-segment>/
    layout.tsx
    (public)/
      layout.tsx
      page.tsx
      <public-views>/
    (app)/
      layout.tsx
      <auth-views>/
```

## Verification
- Public routes load unauthenticated.
- Authenticated routes redirect when unauthenticated.
- Role-gated routes block unauthorized roles.
- Landing dropdown navigates to `/<platform-segment>`.
- No console errors on load.

## Version policy
Use the latest stable versions of `next`, `react`, `tailwindcss`, and `shadcn/ui`.

## Additional resources
- Scans, mapping tips, and gotchas: `reference.md`
- Example inventories and scaffolds: `examples.md`
- Rule index:
  - Priority 1: `rules/discovery-auth-views`, `rules/route-naming-audit`, `rules/confirm-view-names`, `rules/platform-naming-derive`
  - Priority 2: `rules/routing-platform-scaffold`, `rules/boilerplate-first`
  - Priority 3: `rules/coexistence-legacy`, `rules/landing-header-dropdown`
  - Priority 4: `rules/naming-clean`, `rules/test-auth-flows`

Overview

This skill inventories a Next.js app’s marketing and dashboard views by authenticated vs unauthenticated roles, confirms view names with the user, and plans a shadcn-based clean platform scaffold in a separate App Router folder. It maps public/auth boundaries, proposes clean route names, and scaffolds only the confirmed boilerplate under app/<platform-segment> while keeping legacy routes intact.

How this skill works

The skill scans the Next.js routing tree to identify public pages, authenticated app pages, and role-gated routes, then produces a human-readable view inventory template. After a librarian-style route naming audit, it asks the user to confirm which views to recreate and their final names, then outputs a scaffold plan for a shadcn-first platform subtree under the App Router (app/<platform-segment>) without touching legacy code or auth logic.

When to use it

  • Auditing role-based views to separate public vs authenticated UX.
  • Planning a clean shadcn UI recreation while keeping legacy routes unchanged.
  • Preparing to split auth and public routes into an App Router subtree.
  • Performing a route-name / navigation consistency audit before refactor.
  • Scaffolding only confirmed views to avoid premature migration work.

Best practices

  • Run a discovery pass and route-naming audit before scaffolding anything.
  • Confirm every recreated view name with stakeholders (confirmation-first).
  • Keep legacy routes isolated and do not import legacy CSS into new layouts.
  • Install shadcn components up-front (MCP/CLI) and prefer prescribed blocks.
  • Use clear, clean names—avoid New*, *V2, Temp*, or legacy prefixes.

Example use cases

  • Map an app that mixes marketing pages and a role-gated dashboard to decide what to re-create.
  • Create a clean app/<platform-segment> scaffold using shadcn blocks (sidebar, dashboard, auth).
  • Run smoke tests to verify public routes load unauthenticated and auth routes redirect.
  • Derive a platform route segment from existing product copy and confirm naming with the product owner.
  • Add a landing header dropdown entry that points to the new platform root without removing old links.

FAQ

Will this change authentication logic or delete old code?

No. The skill only inventories and scaffolds a new subtree; it does not modify auth logic or remove legacy files.

Do I have to recreate every legacy screen?

No. Boilerplate-first: only views confirmed by the user are scaffolded in the new platform.