skills/implement-cleanup-mocks/SKILL.md
Use when user says "cleanup mocks", "handover to backend", "remove mock data", "prepare for backend", or wants to clean up mock data and generate API contract docs before backend handover.
npx skillsauth add ash4180/vorbit implement-cleanup-mocksInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Clean up mock data created during prototyping/implementation and generate API contract documentation for backend handover.
When frontend development is ready for backend handover:
Locate
_shared/: This skill ships as a plugin, so_shared/files live in the plugin cache, not your project. Before reading any_shared/...path below, runls -d ~/.claude/plugins/cache/local/vorbit/*/skills/_shared 2>/dev/null | head -1and use the output as the absolute base for every_shared/...reference.
Read and follow _shared/mcp-tool-routing.md. Discover connected platforms, ask user which to use, and verify connection.
Check for mock registry file:
.claude/mock-registry.json
Registry format: see _shared/mock-registry.md for the version 1.1 schema.
IF registry exists:
IF registry doesn't exist:
**/mocks/*.json - mock data files**/mocks/*.ts - mock data exports// TODO: Replace with real APIMOCK_ prefixed constantsuseState(MOCK_ or useState([{ with hardcoded dataconst [data, setData] = useState(mockData)For each mock file being cleaned up:
users.json → GET /api/usersuser-detail.json → GET /api/users/:id### [Endpoint Name]
**Endpoint:** `GET /api/users/:id`
**Description:** [Infer from feature name and data]
**Response Shape:**
```json
{
"id": "string",
"name": "string",
"email": "string",
"createdAt": "ISO date string"
}
Example Response:
[Actual mock data - first item if array]
Used by: [List components that import this mock]
## Step 4: Collect Open Questions for Backend
Before assembling the contract, ask the user via `AskUserQuestion` whether there are open questions or decisions the backend team needs to make. Examples:
- "Should this endpoint paginate? If yes, cursor or offset?"
- "Authorization: per-user only, or also per-org?"
- "Soft-delete or hard-delete for the DELETE endpoint?"
If the user has nothing, drop the "Questions for Backend" section from the contract template. Don't auto-populate it with guesses — vague questions are worse than no questions. This step closes the gap where no upstream skill writes that section; without asking here, it stays empty.
## Step 5: Present API Contract for Review
**Show the complete API contract document**, populated with the endpoints generated in Step 3 — use the template in `./output-schema.md`.
**Ask:** "Does this API contract look correct? Ready to save to PRD?"
**Wait for confirmation before proceeding.**
## Step 6: Save API Contract to PRD
### If Notion PRD:
1. Use `notion-fetch` to get current PRD content
2. Use `notion-update-page` to append API Contract section:
- Command: `insert_content_after`
- Find appropriate location (after User Stories or at end)
- Insert the API contract markdown
### If no platform detected:
1. Create local file: `docs/api-contracts/[feature-name].md`
2. Report file location
## Step 7: Clean Up Mock Files and State
**For each mock in cleanup scope:**
### 6.1 Mock Files
1. **Delete mock JSON/TS files** in `mocks/` folders
2. **Update imports** - replace mock imports with placeholder:
```tsx
// BEFORE:
import mockData from './mocks/data.json';
// TODO: Replace with real API
// AFTER:
// TODO: Connect to real API - see PRD for contract
// API endpoint: GET /api/users
const data = null; // Backend will implement
Replace hardcoded useState with empty/loading state:
// BEFORE:
const [users, setUsers] = useState([
{ id: 1, name: 'John' },
{ id: 2, name: 'Jane' }
]);
// AFTER:
// TODO: Connect to real API - GET /api/users
const [users, setUsers] = useState<User[]>([]);
const [loading, setLoading] = useState(true);
Clean Zustand/Redux stores - replace mock initial state:
// BEFORE:
const useStore = create((set) => ({
users: MOCK_USERS,
// ...
}));
// AFTER:
// TODO: Connect to real API - GET /api/users
const useStore = create((set) => ({
users: [],
loading: true,
// ...
}));
Clean Context providers - replace mock values:
// BEFORE:
<UserContext.Provider value={mockUserData}>
// AFTER:
// TODO: Connect to real API - GET /api/users/:id
<UserContext.Provider value={null}>
.claude/mock-registry.jsonPresent summary:
## Mock Cleanup Complete
### API Contract
- Saved to: [Notion PRD URL / local file path]
- Endpoints documented: [count]
### Files Removed
- src/pages/Feature/mocks/data.json
- src/pages/Feature/mocks/users.json
### Files Updated
- src/pages/Feature/index.tsx (mock import → API placeholder)
- src/pages/Feature/components/List.tsx (mock import → API placeholder)
### Next Steps for Backend
1. Review API contract in PRD
2. Implement endpoints matching documented shapes
3. Frontend will connect via [API client pattern]
See _shared/mock-registry.md for the .claude/mock-registry.json location, the version 1.1 format, registration rules, and what each entry captures.
See ./output-schema.md for the full API Contract Template handed to backend.
development
Sync design tokens and components from a codebase to a Pencil canvas (`.pen` files), or set up a Pencil canvas from a style guide when no codebase exists. Use when the user says "sync pencil", "setup pencil", "configure pencil", "pencil sync", "sync tokens to pencil", "build pencil component library", or names Pencil/`.pen` files explicitly. Also triggers when mockups generated by Pencil don't match project conventions.
development
--- name: figma version: 1.6.0 description: Use when user says "figma", "figma it", "sync figma", "figma mockup", "create figma file", "design to figma", "figma from PRD", "figma from journey", "build in figma", or "figma design system" — anything that creates, syncs, or updates Figma design systems, components, variables, mockups, or front-end-ready screens. Always enumerates the linked Figma library FIRST (library-driven discovery, not per-need search), produces a block→DS mapping table for us
development
Use when the user wants to build Webflow pages, templates, or components, with or without Figma designs as reference.
testing
Use when the user wants to verify an implementation, validate acceptance criteria, or run a Vorbit-style post-change check using shared project rules.