RedHat Frontend Builder

Build frontend apps with safe API integration and quality gates.

Security Scan

The skill's requested resources and runtime instructions are coherent with its stated purpose of scaffolding frontend projects; there are a few minor metadata and documentation mismatches to verify before use.

Purpose & Capability

The name/description (frontend scaffolding, safe API integration, quality gates) matches the instructions (scaffold project structure, API client layer, lint/tests/build). There are no unexpected credentials, binaries, or installs required for this purpose.

Instruction Scope

Instructions are scoped to creating project files, adding a client API layer, accessibility guardrails, tests, and build validation — all consistent. Minor gap: the SKILL.md states the API client's base URL should be provided 'via env' and that outputs include 'notes about env vars', but the skill does not declare any specific required env var names. Also the runtime instructions expect writing files in a 'target directory' (normal for a scaffolder) — confirm the agent has the intended working directory and permissions.

Install Mechanism

Instruction-only skill with no install spec or code to download; this is low risk and expected for a scaffolding/instruction skill.

Credentials

The skill requests no credentials or config paths (proportionate). It does reference using environment variables for base URL and notes about env configuration, but does not declare specific env vars — this convenience gap is a documentation mismatch rather than a secret-exfiltration risk. No secrets are requested or embedded by the skill itself.

Persistence & Privilege

always is false, the skill is user-invocable and may be invoked autonomously (platform default) but it does not request persistent system-wide changes or modify other skills/configs. Expected privilege level for a scaffolder.

Scan Findings in Context

[no-findings] expected: The regex-based scanner had no code files to analyze (instruction-only skill). This is expected; absence of findings does not imply safety — review SKILL.md as primary signal.

Assessment

This skill appears coherent for scaffolding frontend projects, but do these checks before installing or running it: 1) Verify the skill origin — registry metadata owner ID (kn741...) differs from the internal _meta.json ownerId (redhat-agent-001) and there's no homepage/source link; prefer skills with a clear publisher and repo. 2) Decide which environment variables (e.g., API_BASE_URL) you will provide; the SKILL.md references env usage but does not declare names. 3) When the agent scaffolds files, review the generated code (especially the API client and any server proxy guidance) to ensure no secrets are embedded and endpoints are as expected. 4) Because this is instruction-only, it will create files in whatever working directory the agent runs in — run it in a controlled sandbox or repo to avoid accidental overwrites. If you want higher assurance, ask the skill author for a repository or example output to inspect before trusting it in production.

SKILL: frontend-builder

Purpose

Build frontend applications (React / Next.js / Vite) with predictable structure, accessibility, and safe API integration.

When to Use

• A new UI app/page/component system is required.
• The task includes routing, state management, or API consumption.
• You need a repeatable scaffold with quality gates (lint/tests/build).

Inputs

• stack (required, enum: react-vite|nextjs|react-spa).
• ui_requirements (required, string|object): pages, components, UX constraints.
• api_contract (optional, object): endpoints/events and schemas.
• constraints (optional, string[]): theming, perf, accessibility, browser support.

Steps

1. Confirm scope:
   • routes/pages
   • global layout/navigation
   • state boundaries (server vs client)
2. Scaffold project in the target directory with minimal dependencies.
3. Implement component structure:
   • components/, pages//routes/, lib/, styles/
4. Implement API client layer with:
   • base URL via env
   • timeouts
   • error normalization
5. Add accessibility and UX guardrails:
   • semantic HTML
   • keyboard navigation
   • loading/error states
6. Add tests (where the repo conventions support them).
7. Validate build/lint/test.

Validation

• App builds cleanly.
• No secrets in client bundles.
• API calls handle errors and cancellations.
• Key user flows are covered by at least smoke tests.

Output

• Files created/changed
• Run commands (dev, build, test)
• Notes about env vars and configuration

Safety Rules

• Never embed API keys in frontend code; use server-side proxy if needed.
• Avoid untrusted HTML injection; sanitize where necessary.
• Prefer stable, well-maintained libraries.

Example

Input:

• stack: react-vite
• ui_requirements: “Dashboard page + settings form; calls /api/me.” Output: Vite project with src/pages/Dashboard.tsx, src/lib/api.ts, and build validation commands.