# Ship frontend code that's consistent, secure, and production-ready by default

AI-generated frontend code drifts into duplication, inconsistent styling, and security mistakes without explicit standards. This skill supplies a portable baseline of 16 universal principles plus framework-specific guidance, so professional output is the default and requires no extra prompting.

## Install

```bash
npx skillstore add ieze-king/frontend-guardrails
```

## Metadata

- - Slug: ieze-king-frontend-guardrails
- - Version: 1.0.0
- - Author: ieze-king
- - GitHub username: ieze-king
- - License: MIT
- - Repository: https://github.com/ieze-king/frontend-guardrails/tree/main/skills/frontend-guardrails
- - Ref: main
- - Supported tools: Claude, Codex, Claude Code
- - Risk level: safe
- - Quality score: 77
- - Quality tier: bronze
- - Public page: https://skillstore.pages.dev/skills/ieze-king-frontend-guardrails
- - Manifest: https://skillstore.pages.dev/api/skills/ieze-king-frontend-guardrails/manifest

## Capabilities

- Enforces 16 universal frontend principles covering reusability, design tokens, responsiveness, state management, security, and accessibility.
- Provides framework-specific implementation guidance for React/Next.js, Vue/Nuxt, Angular, and Svelte/SvelteKit.
- Applies a self-audit checklist before declaring any task complete, covering duplication, security, polish, and scope discipline.
- Warns against common security mistakes like putting secrets in \`localStorage\`, shipping unsanitized HTML, and trusting client-side route guards.
- Recommends composing with mature linters, formatters, and design tools rather than re-implementing them inline.
- Scales rigor to project size: applies fundamentals everywhere, but does not impose enterprise tooling on small or beginner projects.

## Use Cases

- Scaffolding a new React/Next.js project: Use when starting a new frontend project to get consistent structure, design tokens, security defaults, and a self-audit checklist applied from the first commit.
- Reviewing AI-generated UI code: Use as a review pass over generated components to catch duplication, hardcoded values, unsanitized HTML, secrets in client code, and missing accessibility.
- Teaching AI assistants your team's standards: Use as a standing skill so every AI session follows the same accessibility, security, state-management, and naming conventions without re-prompting.

## Prompt Templates

### Apply standards to a new component

```
I am adding a new [component name] to my [React/Vue/Angular/Svelte] project. Read the matching reference file and apply the universal principles: reuse existing components where possible, use design tokens (no hardcoded values), keep state at the right level, handle loading and empty states, label inputs, ensure keyboard operability, and avoid `dangerouslySetInnerHTML`/`v-html`/`{@html}` with untrusted content. After implementing, run the self-audit checklist and report which standards shaped the result.
```

### Audit a generated file for guardrail violations

```
Review the file at [path] against the frontend guardrails. Flag any of: duplicated markup or logic, hardcoded colors/fonts/spacing, missing loading or empty states, secrets or API keys in client code, unsanitized HTML, missing alt text, missing labels, missing keyboard handlers, and unused or speculative code. For each issue, cite the line and explain the fix in one sentence.
```

### Add auth or token handling safely

```
I need to add [login flow / session handling / token refresh] to my [framework] app. Read references/security.md and the framework-specific security section first. Use httpOnly + Secure + SameSite cookies for tokens, never `localStorage`. Keep all secret-bearing logic server-side. Re-check authorization on the backend on every request. Show the resulting code with comments explaining each security decision.
```

### Compose with the existing ecosystem

```
Before writing custom code, identify what tooling the project already has. Check `package.json` and config files for ESLint, Prettier, a11y plugins, and design-token systems. Recommend the smallest set of additions (e.g., `eslint-plugin-jsx-a11y`, Lighthouse, Context7 MCP) instead of re-implementing their rules. Do not introduce CI, TypeScript, or test suites into a project that does not already use them.
```

## Limitations

- Out of scope by design: backend, CI/CD, databases, deployment, error monitoring, and visual-regression testing are not covered.
- Not a replacement for mature tooling: it routes to ESLint, Lighthouse, Context7, and a11y linters rather than duplicating their rules.
- Provides principles and patterns, not a runnable library: it has no executable code to install.
- Yields to existing project conventions and explicit user instructions; it is a baseline, not a mandate.

## Best Practices

- Detect the existing stack first by reading \`package.json\` and config files; never impose a stack the project does not use.
- Reuse or extend existing components, hooks, and tokens before building something new; duplication is the most common source of repeated bugs.
- Apply the self-audit checklist before declaring any task done, and remove debug artifacts, stubs, mock data, and dead code.

## Anti Patterns

- Do not put secrets, API keys, or tokens in any client-exposed env var \(anything prefixed \`NEXT\_PUBLIC\_\`, \`VITE\_\`, \`PUBLIC\_\`, or in \`environment.ts\`/\`runtimeConfig.public\`\).
- Do not use \`dangerouslySetInnerHTML\` \(React\), \`v-html\` \(Vue\), \`\{@html\}\` \(Svelte\), \`bypassSecurityTrustHtml\` \(Angular\), or \`innerHTML\` on untrusted content.
- Do not rely on client-side route guards, hidden buttons, or disabled fields for security; the backend must re-check authorization on every request.

## Security Audit

- - Safe to publish: true
- - Audited at: 2026-06-08T23:30:48.554\+00:00
- - Summary: This skill is pure markdown documentation containing frontend engineering policy and best-practice guidance. The static analyzer flagged 192 potential issues, but on evaluation all are false positives: backticks in markdown inline code \(e.g., \`useState\`, \`localStorage\`\) were matched as 'Ruby/shell backtick execution', and security guidance that explicitly warns AGAINST using \`localStorage\` for tokens was flagged as 'Browser storage access'. The skill contains no executable code, no network calls, no file system access, and no obfuscation. It is safe to publish.

## Stats

- - Views: 2
- - Downloads: 17
- - Favorites: 1
- - Popularity score: 0