Add you-might-not-need-an-effect skill

[IzumiSy]

Motivation

AppShell now has several project-local development skills, but nothing focused on React's useEffect guidance. In practice, AI coding assistants tend to use useEffect too casually for derived state, event logic, and initialization, so we wanted to package React's official guidance as a lightweight skill that can load during normal development and review.

This is especially useful in this repository because AppShell mixes framework code, hooks, and app-like examples, so it is easy to reach for useEffect for work that belongs in render logic, event handlers, loaders, or startup code instead.

useEffect is still useful in many cases, so this is intentionally not a mechanical checker or lint rule. The goal is to improve judgment at authoring/review time, not to enforce a blanket ban.

Design Decision

Instead of building a rigid repo-specific auditing workflow, this adds a small knowledge-oriented skill plus a single reference file of concrete anti-patterns. That keeps the skill easy to load during normal coding, while still grounding it in the React guidance from "You Might Not Need an Effect".

The skill also includes a small AppShell-specific note around initialization: because AppShell embeds React Router, some work may belong in route loaders, auth initialization, or app startup code rather than mount effects.

A few alternatives were considered and intentionally not adopted:

• vercel-labs/agent-skills's react-best-practices has some useful material, but it mixes in Next.js- and Server Component-oriented guidance. AppShell targets SPA usage, so pulling it in wholesale would add noise. It may still be worth curating separately later as a broader react-skills style addition.
• victor36max/use-effect-killer was a good reference point, but it is effectively just a SKILL.md. Since we wanted to tweak the content, include AppShell-specific guidance, and avoid a pseudo-dependency on an external text file, copying and owning the content locally was the simpler choice.
• A linter-style rule was rejected because the usefulness of useEffect is case-dependent. This change is meant to teach and steer, not to mechanically fail code that may be perfectly valid.

Summary

• add a project-local you-might-not-need-an-effect skill under .agents/skills
• document common effect anti-patterns, legitimate effect cases, and the displayed-vs-interacted decision rule
• add a companion anti-pattern reference with concrete examples for review and implementation guidance

[interacsean]

Do we need any guidance here that this behaves differently if initialContent changes from the parent component? Truly if we only want to initialize state, and not if we want a controlled component?

[interacsean]

Unclear to me what happens to "comment", how this cleanly replaces the idea of having a comment that clears when userId changes