run-preview
รัน preview build เพื่อทดสอบก่อน deploy จริง
SKILL.mdrun-preview/SKILL.md
GitHubGoal
Run a preview build to test before an actual deploy, covering build, start server, test, verify, and share preview
Scope
Use for all kinds of preview, both a local preview server and a deployment preview (Vercel, Cloudflare, Netlify), before an actual deploy
Execute
Pre-Run: Always run
/deep-reviewfirst —run-*must be reviewed/assessed before the main work, never skip; if findings are blockers, fix or report before running (preview)
1. Build Preview
Goal: Build Preview
Create a preview build for testing
- Run
/run-buildto create the preview build - Set the build mode to preview, not production
- Check the build output for errors
- For Vite: use
bun run buildthenbun run preview - For Next.js: use
bun run buildthenbun run start - For Nuxt: use
bun run buildthenbun run preview - For Vercel: use
bunx vercel previewfor a deployment preview - For Cloudflare: use
bunx wrangler pages devfor a local preview
2. Start Preview Server
Goal: Start Preview Server
Run the preview server per the framework
- Run the preview server command per the framework in use
- Check that the server is running by watching the console output
- Record the preview URL (local or deployment URL)
- For a deployment preview, wait until the URL is ready
3. Test Preview
Goal: Test Preview
Test the preview in the browser
- Open the preview URL in the browser
- Run
/watch-browser fixto continuously check the page - Test the key features that changed recently
- Check the console errors and warnings
- Run
/run-testfor detailed testing
4. Verify Preview
Goal: Verify Preview
Verify the correctness of the preview
- Check that every page loads correctly
- Check that assets and static files all load
- Test the critical user flows
- Check the responsive design across multiple screen sizes
- Check that the API endpoints work correctly (if any)
- Check that the environment variables are correct for the preview
5. Report Issues
Goal: Report Issues
Report the issues found in a table
- Run
/reportto format a table - Create a table with columns: Category, Issue, Severity, Location, Action Required
- Categories: Build, Pages, Assets, API, Console Errors, Responsive
- Order the issues by severity (critical, high, medium, low)
6. Share Preview
Goal: Share Preview
Share the preview with the team and collect feedback
- Share the preview URL with the team
- Collect feedback and record the issues found
- If there are issues, run
/resolve-errorsthen rebuild the preview - If everything passes, run
/run-deployfor the actual deploy
Rules
- Use the preview build mode, not production
- Set separate environment variables for preview from production
- Use a preview or staging database if needed
- Test the most recently changed features first
- Always test the critical user flows
- Test the responsive design across multiple screen sizes
- Use
/watch-browser fixfor continuous checking - Use
/run-testfor detailed testing - Use
/reportto report issues - Stop the preview server when not in use
- Periodically delete old preview builds
- Use preview URLs temporarily; never use them as production
- If there are issues, fix them before the actual deploy
- For a deployment preview, wait until the URL is ready before testing
Common Mistakes
- Using a production build instead of a preview build
- Not setting environment variables for preview
- Testing only the changed pages and not the critical flows
- Not checking the console errors
- Forgetting to stop the preview server when not in use
- Using a preview URL as production
Anti-Patterns
- Deploying for real without going through a preview first
- Using a production database for preview
- Skipping responsive design testing
- Not reporting the issues found in the preview
- Skipping API testing in the preview
- Use /run-dev if needed
- Use /run-review if needed
Expected Outcome
- The preview build succeeds with no errors
- The preview server works
- Features work correctly in the preview
- The console has no errors or warnings
- The responsive design works on every screen size
- Issues are identified, reported in a table, and fixed before deploy
- Team feedback is collected
- Ready for
/run-deployfor the actual deploy