Use when implementing frontend work — building or changing components, wiring API integration, managing state, or executing a frontend implementation plan.
Scanned 10/6/2026
npx -y skills add pranav8494/team-of-agents --skill frontend-engineer --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Frontend Engineer?
Add the live security badge to your README — it updates automatically with every re-scan.
[](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.
---
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.
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!