A project-aware explanation command for Feature-Sliced Design (FSD), a method for organizing frontend code into layers, slices, and segments. It explains FSD topics using examples from the current project.

Use it to learn about layers, features, widgets, entities, public APIs, segments, cross-imports, hierarchy, shared code, and slice boundaries.

It makes unfamiliar architecture rules easier to understand and gives a team a shared explanation of how those rules apply to its own code.

explain — Command for Claude Code by jhlee0409/claude-plugins

Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

Clone the repo

git clone --depth 1 https://github.com/jhlee0409/claude-plugins

Made for: Claude Code.

Or install fsdarch, the plugin that ships this one along with the rest of its 4 skills, 6 commands.

Wrote this? Show the measurements

A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.

README.md

[![agentmods](https://agentmods.dev/badge/commands/jhlee0409/claude-plugins/explain/github.svg)](https://agentmods.dev/commands/jhlee0409/claude-plugins/explain)

Your own site

<a href="https://agentmods.dev/commands/jhlee0409/claude-plugins/explain"><img src="https://agentmods.dev/badge/commands/jhlee0409/claude-plugins/explain/github.svg" alt="Measured on agentmods" height="20"></a>

Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.

Your own site · 80×15

<a href="https://agentmods.dev/commands/jhlee0409/claude-plugins/explain"><img src="https://agentmods.dev/badge/commands/jhlee0409/claude-plugins/explain.svg" alt="Reviewed on agentmods" width="80" height="20"></a>

Per session 8 Only the description is in the session, so the agent can decide to use it. The body loads when it is invoked.

When invoked 2,274 The whole file, excluding the scripts and references it only reads on demand.

Security scan A 0 findings. A grade says what 26 rules found in the file — not that it is safe.

Origin original No closer match found in the catalogue.

Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

Model	Per session	Once invoked
Fable 5.1	$0.00008	$0.02274
Opus 5.5	$0.00003	$0.00910
Sonnet 5.5	$0.00002	$0.00455
Haiku 4.5	$0.00001	$0.00227

Measured 1mo ago against content hash 8e9e551a2c6a, method: parsed. Prices are Anthropic first-party input rates as of 2026-10-07, from the pricing page.

Security

Grade A, and why

explain scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 1mo ago.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

plugins/fsd-architect/commands/explain.md · 339 lines

How it starts

The opening of the file, as written. The whole thing — 339 lines — stays where its author put it; the contents beside it link to each section on GitHub.

/fsdarch:explain

FSD 개념을 프로젝트 맥락에서 설명합니다. 학습 곡선을 낮추고 팀 내 이해도를 통일합니다.

Syntax

/fsdarch:explain <topic>

Available Topics

Topic	Description
`layers`	7개 레이어와 각각의 역할
`feature-vs-widget`	Feature와 Widget의 차이
`entity-vs-feature`	Entity와 Feature의 차이
`public-api`	Public API 패턴과 이유
`segments`	ui, model, api, lib 세그먼트
`cross-imports`	Cross-import 금지 규칙
`hierarchy`	레이어 계층 규칙
`shared`	Shared 레이어 사용법
`slices`	슬라이스 분리 기준
`<custom>`	자유 질문 (FSD 관련)

Execution Flow

Step 1: Parse Topic

미리 정의된 토픽인지 확인
아니면 자유 질문으로 처리

Step 2: Load Project Context

.fsd-architect.json 로드 (있으면)
현재 프로젝트 구조 분석
실제 예시 준비

Step 3: Generate Explanation

개념 설명 (이론)
프로젝트 예시 (실제)
관련 규칙
추가 학습 자료

Step 4: Display Result

토픽별 맞춤형 출력.

Examples

Example 1: Feature vs Widget

/fsdarch:explain feature-vs-widget

═══════════════════════════════════════════════════════════════
                  FEATURE vs WIDGET
═══════════════════════════════════════════════════════════════

📚 핵심 개념

Feature (기능)
  → 사용자 시나리오 단위의 기능
  → "사용자가 ~할 수 있다"로 설명 가능
  → 비즈니스 로직 포함 가능
  → 다른 Feature와 독립적

Widget (위젯)
  → 여러 Feature를 조합한 UI 블록
  → 자체 비즈니스 로직 최소화
  → 페이지에서 재사용되는 "덩어리"

───────────────────────────────────────────────────────────────

🎯 결정 기준

"이것이 독립적인 사용자 행동인가?"
  → YES: Feature (예: "로그인", "장바구니 추가", "리뷰 작성")
  → NO: Widget (예: "헤더", "사이드바", "제품 카드 그리드")

"다른 기능과 조합되어야 하는가?"
  → YES: Widget (예: HeaderWidget = auth + cart + search 조합)
  → NO: Feature

───────────────────────────────────────────────────────────────

📁 당신의 프로젝트 예시

Features (현재 8개):
  ├── auth/          → 사용자가 "로그인할 수 있다"
  ├── cart/          → 사용자가 "장바구니를 관리할 수 있다"
  ├── checkout/      → 사용자가 "결제할 수 있다"
  ├── favorites/     → 사용자가 "찜 목록을 관리할 수 있다"
  └── ...

Widgets (현재 3개):
  ├── header/        → auth + cart + search 조합
  ├── product-card/  → product entity + favorites feature 조합
  └── sidebar/       → navigation + user-info 조합

───────────────────────────────────────────────────────────────

⚠️ 흔한 실수

1. Feature가 너무 큼
   ✗ features/user/ (너무 포괄적)
   ✓ features/user-profile/, features/user-settings/

2. Widget에 비즈니스 로직
   ✗ widgets/header/model/authLogic.ts
   ✓ features/auth/ 에서 로직, widget은 조합만

3. Feature 간 의존성
   ✗ features/auth → features/cart
   ✓ widgets/auth-cart 에서 조합

───────────────────────────────────────────────────────────────

📚 더 알아보기

• https://feature-sliced.design/docs/reference/layers#features
• https://feature-sliced.design/docs/reference/layers#widgets

═══════════════════════════════════════════════════════════════

Read the full file on GitHub · 339 lines

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

1mo ago First seen · 339 lines · 8 tokens per session scan A 8e9e551a2c6a

Subscribe to this mod's changes

explain is a command published in the GitHub repository jhlee0409/claude-plugins (4 stars, last pushed 9mo ago), licensed MIT. It adds 8 tokens to every session and 2,274 once invoked, about $0.0000 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.

Claude Code Frontend Learning and teaching api-codegen claude-plugin code-generator openapi react-query

speckit.gym.drop

Record a drop card from a mis-fire. A mis-fire is not a mistake to punish — it is a discovery to keep. Drop cards capture what was done, what was expected, and what happened, persisted to the configured redundant stores (default /drops/ plus the extension's append-only .drop-ledger.md).

arrrrny/zuraffa · 0 tokens

explain