- Home
- Skills
- Shinpr
- Claude Code Workflows
- Frontend Ai Guide
frontend-ai-guide_skill
102
GitHub Stars
1
Bundled Files
2 months ago
Catalog Refreshed
4 months ago
First Indexed
Readme & install
Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.
Installation
Preview and clipboard use veilstrat where the catalogue uses aiagentskills.
npx veilstrat add skill shinpr/claude-code-workflows --skill frontend-ai-guide- SKILL.md9.5 KB
Overview
This skill provides frontend-specific decision criteria, common anti-patterns, debugging techniques, and a quality check workflow to guide technical decisions and QA. It codifies rules like the Rule of Three, fail-fast principles, and concrete steps for impact analysis to reduce regressions and technical debt. Use it to standardize reviews, design docs, and implementation checklists for frontend features.
How this skill works
The skill inspects design choices, duplicated code patterns, excessive fallbacks, and unsafe type usage against a set of red-flag patterns. It prescribes actions: when to commonalize, when to split components, how to apply fail-fast error handling, and which build/test commands to run during quality checks. It also guides debugging via error analysis, 5 Whys, minimal repros, and structured impact reports.
When to use it
- Planning or reviewing frontend design and architecture
- Deciding whether to extract shared components or hooks
- Performing pre-merge quality checks and CI troubleshooting
- Investigating recurring runtime errors or uncertain new tech
- Preparing an impact analysis before refactoring or deleting code
Best practices
- Apply the Rule of Three: delay commonalization until the third similar occurrence
- Prefer fail-fast handling; only add fallbacks explicitly defined in the design doc
- Split components larger than ~300 lines and avoid multi-responsibility components
- Start with failing tests (Red-Green-Refactor) and use minimal reproductions for bugs
- Log errors explicitly and require design review for the 3rd catch in a feature
Example use cases
- A feature branch introducing similar form inputs: evaluate duplication and extract after the 3rd instance
- A production bug with unclear stack traces: run the error analysis procedure and 5 Whys to find root cause
- Adding a new experimental library: mark certainty low, create a minimal verification, and define fallback plans
- QA pre-release: run check, build, test, and test:coverage:fresh; troubleshoot with cleanup:processes if ports or caches block
- Removing legacy utilities: run discovery, full understanding, and a structured impact report before deletion
FAQ
Only when the Design Doc explicitly allows it or after a design review; otherwise prefer fail-fast and explicit error logging.
How do I decide to commonalize repeated code?
Follow Rule of Three: keep the first occurrence inline, consider consolidation on the second, and commonalize on the third if patterns and business logic align.