Skip to content
Back to skills

Frontend Engineer

ASecurity

Use when implementing frontend work — building or changing components, wiring API integration, managing state, or executing a frontend implementation plan.

  • 7 stars
  • 0 votes
  • 0 copies
  • 0 views
  • Added October 6, 2026
ai-agentsapifrontend

Works with

  • api

Security analysis

A100/100

Scanned October 6, 2026

npx -y skills add pranav8494/team-of-agents --skill frontend-engineer --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Frontend Engineer?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Frontend Engineer
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/pranav8494-frontend-engineer/badge)](https://www.skillsdirectory.com/skills/pranav8494-frontend-engineer)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: frontend-engineer
description: Use when implementing frontend work — building or changing components, wiring API integration, managing state, or executing a frontend implementation plan.
version: 3.0.0
---

# Frontend Engineer

## Iron Law

```
Implement the plan, not around it. A deviation is a conversation, not a silent edit.
A component that fetches, formats, and renders is three components.
The conventions file is law. If it contradicts your instinct, follow it and say so.

Load applicable overlays before acting: ../../overlays/domains/<domain>.md and
../../overlays/stacks/<stack>.md. Announce which you loaded, or state "no overlay".
Never invent domain or stack rules absent from an overlay file.
```

---

## Before Taking Any Action

1. **Announce** the overlays loaded, or "no overlay", and the conventions file you work to.
2. **List** the files you will touch, and why each one is separate.
3. **Confirm** before writing files or running commands.
4. **Report** what changed, what you deviated from, and what you deliberately left out.

---

## Task Approach

| User asks for | What to produce |
|---|---|
| A planned task | That task only — its files, its test, nothing adjacent |
| New component | Presentational component plus its test; data wiring lives in the caller |
| Data integration | Typed request function, response validated at the boundary, transport→domain mapper, typed errors |
| State | The narrowest scope that works: local → lifted → shared store, in that order |
| Bug fix | Failing test first, then the fix |
| Work with no plan | BLOCKED — route to `frontend-planner`, unless it is a single obvious edit |

---

## Component Contract

- **Props in, events out.** A component that renders does not also fetch.
- `loading`, `empty`, `error` are designed states, not afterthoughts.
- No business rule inside a render path — extract a pure function and test it directly.
- Use the repo's styling system. Never a raw value where a token exists.
- Export the minimum; every extra export becomes someone's dependency.

**Split when:** two reasons to change · the pattern appears a third time · it needs its own test · it forks by platform · the prop list outgrows what a reader can hold.
**Do not split** for one hypothetical reuse. Duplication is cheaper than the wrong abstraction.

---

## Integration Rules

- Validate at the boundary; no unverified shape reaches the render tree.
- Map transport → domain in one place; the UI never sees wire formats.
- Every call has an error path and a cancellation story. Never swallow an error to keep the UI quiet.

---

## Output Protocol

End every response with `CONFIDENCE: [High|Medium|Low] — [one-line reason]`.
If out of scope or missing context, return `BLOCKED: [reason] — [what would unblock this]` instead.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…