rule-frontend-utils

Enforce frontend utility extraction and naming conventions in Simpler Grants.

1|1|Updated Mar 31, 2026
One-click install
npx skills add https://github.com/btabaska/simpler-grants-documentation-automation --skill rule-frontend-utils
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: rule-frontend-utils
Source: https://github.com/btabaska/simpler-grants-documentation-automation/tree/main/.claude/skills/rule-frontend-utils
Command: npx skills add https://github.com/btabaska/simpler-grants-documentation-automation --skill rule-frontend-utils

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Frontend development often suffers from inconsistent utility placement, naming, and testing practices. This Skill codifies conventions for when to extract utilities into a shared frontend/src/utils/ directory versus inline usage, promoting consistency and maintainability across the Simpler Grants frontend.

Core Features & Use Cases

  • Extraction vs Inline Rules: Clear criteria to decide when a helper belongs in frontend/src/utils/ and when a component-local helper is sufficient.
  • Naming & Structure Guidance: Naming conventions like dateUtil.ts, generalUtils.ts, and avoiding single-function files to reduce fragmentation; guidance on domain subfolders like applyForm/, attachment/, etc.
  • Runtime Safety & Testing: Guidelines for edge-runtime safety, middleware considerations, and colocated tests with a preference for pure functions and test coverage.

Quick Start

Review the current frontend utils usage in the repository and decide where to extract utilities and how to name them.

Frequently Asked Questions about rule-frontend-utils

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
When should I extract a frontend utility function versus keeping it inline in a component?

Extract a frontend utility function into a shared utils directory when it is reused across multiple components; keep helper logic inline when it remains component-local to avoid unnecessary fragmentation.

What naming conventions should I follow for frontend utility files in TypeScript?

Frontend utility file naming conventions recommend grouping related functions into files like dateUtil.ts or generalUtils.ts, avoiding single-function files to reduce fragmentation and maintain consistency across the codebase.

How do I ensure edge-runtime safety for frontend utilities?

Ensure edge-runtime safety for frontend utilities by writing pure functions, addressing middleware considerations, and colocating tests to verify behavior under edge-runtime constraints.

Does this utility convention apply to my existing TypeScript frontend project?

These utility conventions apply specifically to the Simpler Grants frontend codebase, targeting files under frontend/src/utils and frontend/src/**/*.ts that require edge-runtime safety and testing.

What's the best way to organize frontend utils to prevent file fragmentation?

Organize frontend utils by grouping related functions into domain subfolders like applyForm/ or attachment/, avoiding single-function files and using shared files like generalUtils.ts to prevent fragmentation.

Why do my frontend utility tests fail in edge-runtime environments?

Frontend utility tests fail in edge-runtime environments when functions lack purity or ignore middleware constraints; colocating tests and enforcing edge-runtime safety guidelines resolves these runtime errors.