Agent安装
- 作者仓库星标 2
- 作者更新于 实时读取
- 作者仓库 setup-structure-index
- 领域
- 工程开发
- 兼容 Agent
-
- Claude Code
- Cursor
- Cline
- Codex
- Windsurf
- Gemini CLI
- +20
- 信任分
- 88 / 100 · 社区维护
- 作者 / 版本 / 许可
- @wegfetrhrtewqerwfgtrhtmjhfgdsas · 未声明 license
- Token 消耗评级
- 低消耗
- 接入复杂程度
- 需简单配置
- 是否需要外部 API Key
- 需要 · Vendor-specific
- 兼容的系统
- 未声明(默认跨平台)
- 底层运行要求
- 无特殊要求
- 文件与系统权限
-
- 只读
- 允许写入 / 修改
- 网络行为
- 允许外网请求
- 安装命令数
- 26 条
档案由构建时根据 SKILL.md 与安装命令自动衍生,可能与作者实际意图存在差异。
需要注意: 未限定 allowed-tools,默认拥有全部工具权限。
---
name: setup-structure-index
description: This skill should be used when the user asks to "set up structure index", "add codebase structur…
category: 工程开发
runtime: 无特殊运行时
---
# setup-structure-index 输出预览
## PART A: 任务判断
- 适用问题:代码实现、重构、调试或代码审查。
- 输入要求:目标材料、限制条件、期望输出和验收方式。
- 证据边界:围绕“Why Two Tiers? / What It Creates / Tier 1: Compact File Map (in CLAUDE.md)”读取原文规则,不把推断写成作者承诺。
## PART B: 执行结果
- **01** 任务判断:确认你的需求是否属于代码实现、重构、调试或代码审查,并标出输入、限制和预期结果。
- **02** 执行计划:优先按“Why Two Tiers? / What It Creates / Tier 1: Compact File Map (in CLAUDE.md)”拆成步骤,说明每一步会读取什么、修改什么、产出什么。
- **03** 交付结果:给出可复制的命令、文件改动、检查清单或内容草稿,并说明如何继续迭代。
- **04** 风险边界:结合 读取文件、写入/修改文件、会按任务需要访问外部网络、需要准备 Vendor-specific API Key 给出执行前确认项。
## Running Rules
- 读取文件、写入/修改文件;会按任务需要访问外部网络;需要准备 Vendor-specific API Key。
- 先小样例验证,再放大到真实任务。
- 交付时同时给结果、检查口径和下一步迭代建议。 原文出现了 `/api` 这类斜杠命令;如果你的 Agent 支持命令触发,优先用命令开场,再补充目标和边界。
告诉 Agent 目标文件或材料、期望结果、不可改范围、是否允许联网或执行命令。本 Skill 的权限画像是:读取文件、写入/修改文件。
先用一个小任务确认它会围绕“Why Two Tiers? / What It Creates / Tier 1: Compact File Map (in CLAUDE.md)”工作;涉及文件或命令时,先看 diff、日志、预览或测试结果。
检查最终产物是否包含明确结果、必要证据和下一步动作;如果输出泛泛而谈,就补充输入、边界和验收标准后重跑。
---
name: setup-structure-index
description: This skill should be used when the user asks to "set up structure index", "add codebase structur…
category: 工程开发
source: wegfetrhrtewqerwfgtrhtmjhfgdsas/setup-structure-index
---
# setup-structure-index
## 什么时候使用
- 把工程方向的常用动作沉淀成 Agent 可调用的技能 适合处理工程开发场景下的代码实现、调试、重构、测试或代码审查,核心价值是把输入、判断、执行、验证和交付边界固定下来,避免 Agent 泛泛回答。 把任务拆成可执行、可检查、可继续迭代…
- 面向代码实现、重构、调试或代码审查,优先处理能明确输入、步骤和验收标准的工作。
## 需要提供什么
- 目标材料、目录范围、期望结果和不可改动内容。
- 是否允许联网、执行命令、读写文件或调用外部服务。
## 执行规则
- 围绕「Why Two Tiers? / What It Creates / Tier 1: Compact File Map (in CLAUDE.md)」组织步骤,不把推断写成作者事实。
- 读取文件、写入/修改文件;会按任务需要访问外部网络;需要准备 Vendor-specific API Key。
- 先跑小样例,确认结果可检查后再扩大任务范围。
## 输出要求
- 给出最终产物、关键证据、验证方式和下一步动作。
- 信息不足时标记 unknown,不编造命令、平台或依赖。 作者原文负责流程事实;仓库文件负责来源和命令;流狐只补充适用场景、限制和质量判断。
skill "setup-structure-index" {
输入层 -> 用户目标 + 目标文件 + 禁止范围 + 验收标准
上下文层 -> Why Two Tiers? / What It Creates / Tier 1: Compact File Map (in CLAUDE.md)
规则层 -> SKILL.md 触发条件 / 执行顺序 / 输出格式
运行层 -> 无特殊运行时 | 读取文件、写入/修改文件 | 会按任务需要访问外部网络
安全层 -> 需要准备 Vendor-specific API Key + 小任务验证 + diff / 日志复核
输出层 -> 可复制结果 + 检查清单 + 下一步迭代
} Codebase Structure Index — Setup Guide
A two-tier system for maintaining a living structural index of your codebase. A compact file map in CLAUDE.md provides instant zero-cost orientation every session, while detailed per-directory YAML files are read on demand when deeper exploration is needed.
Why Two Tiers?
Most of the exploration savings come from knowing where things are, not their exact method signatures. A compact file map (~100-200 lines) embedded in CLAUDE.md captures ~70% of the navigation value at zero extra token cost (CLAUDE.md is already loaded into the system prompt). Detailed YAML files with full signatures are only needed when working in an unfamiliar area of the codebase.
Token economics of the old single-tier approach:
- Reading a full structure YAML (~1000-2000 lines per module) every session
- Most sessions only touch 1-2 directories, wasting tokens on irrelevant detail
- Method signatures are low value — you still need to read source before editing
Token economics of the two-tier approach:
- Tier 1 (file map in CLAUDE.md): 0 extra tokens (already in system prompt)
- Tier 2 (detailed YAML): read only when needed, split by directory for targeted reads
- Net result: most sessions read 0 extra lines; deep exploration reads ~100-300 lines
What It Creates
Tier 1: Compact File Map (in CLAUDE.md)
A concise listing of every source file with a one-line description, embedded directly in CLAUDE.md. This answers "where is X?" — the most common exploration question. Since CLAUDE.md is automatically loaded into the system prompt, this costs zero additional tokens.
Tier 2: Detailed Structure Files (in .claude/structure/)
Per-directory YAML files with full export signatures, method params/returns, and intra-project imports. These answer "what does X export?" and are only read when working in that area. Split by directory so you never read more than you need.
TaskCompleted Hook
A hook that evaluates whether a completed task added, removed, or renamed files/classes. Only triggers updates for structural changes, not every code edit.
Setup Steps
1. Create the structure directory
mkdir .claude/structure
2. Add the file map and instruction to CLAUDE.md
Add these sections to your project's CLAUDE.md (create one if it doesn't exist). The file map goes in the project structure area; the instruction goes near the top.
Instruction section (add near the top):
## Codebase Structure Index
The file map below provides instant orientation. For detailed export signatures and dependencies, read the relevant `.claude/structure/*.yaml` file for the directory you're working in.
After adding, removing, or renaming source files or public classes/functions, update both the file map below and the relevant structure YAML file.
File map section (add after the instruction, or integrate into an existing project structure section):
### File Map
<!-- One line per source file: relative path - brief description -->
src/controllers/auth.ts - Authentication endpoints (register, login, OAuth, refresh)
src/controllers/users.ts - User profile, avatar, subscription endpoints
src/services/auth.service.ts - Auth business logic (password verification, token generation)
src/services/subscription.service.ts - Tier logic, group limits, downgrade handling
src/middleware/authenticate.ts - JWT bearer token verification
src/middleware/errorHandler.ts - Global error handler (ApplicationError, Zod, Multer)
src/database/types.ts - Kysely table interfaces and type utilities
src/utils/jwt.ts - JWT generation and verification
...
Also add .claude/structure/ to any project tree listing:
└── .claude/structure/ # Detailed structure index (per-directory YAML)
Guidelines for the file map:
- One line per source file:
relative/path.ext - Brief description - Keep descriptions to ~10 words. For API handlers, include HTTP methods/routes.
- Group by directory with blank lines between groups
- Skip test files, config files, and generated files
- Target ~100-200 lines total. If the project is larger, group minor utility files.
3. Add the TaskCompleted hook
Add this to .claude/settings.json (create if it doesn't exist). If the file already has content, merge the hooks key into the existing object:
{
"hooks": {
"TaskCompleted": [
{
"hooks": [
{
"type": "prompt",
"prompt": "A task is being completed: $ARGUMENTS. Check if the task involved adding, removing, or renaming source files, public classes, or public functions. If so, respond {\"ok\": false, \"reason\": \"Update the CLAUDE.md file map and .claude/structure/ YAML to reflect added, removed, or renamed files/classes/functions.\"}. If the task only modified existing function bodies, fixed bugs without structural changes, or was non-code work, respond {\"ok\": true}."
}
]
}
]
}
}
This hook is more selective than a blanket "did code change?" check. It only blocks for structural changes (new/removed/renamed files, classes, functions), not for every bug fix or implementation change. This avoids wasting tokens updating the index when a one-line fix doesn't change the structure.
4. Generate the initial file map for CLAUDE.md
Use a Haiku agent (Task tool with model: "haiku") to scan the source tree and produce the compact file map.
Agent prompt template:
Generate a compact file map for the [MODULE_NAME] module to embed in CLAUDE.md.
What to do:
- List every source file in
[MODULE_PATH]/- For each file, write one line:
relative/path.ext - Brief description (~10 words)- For API handlers, include HTTP method + route in the description
- Group by directory with blank lines between groups
- Skip test files, config files, and generated files
- Return the result as plain text (not YAML) ready to paste into CLAUDE.md
Target: ~100-200 lines total. Be concise.
After the agent returns the file map, add it to CLAUDE.md under the instruction section.
5. Generate the initial detailed structure files
For each major directory (not module — directory), generate a focused YAML file. Use a Haiku agent per directory. Split along natural boundaries: controllers/, services/, ui/fragments/, etc.
Agent prompt template:
Generate a detailed structure YAML file for the
[DIRECTORY]directory of the [MODULE_NAME] module.What to do:
- For each source file in
[MODULE_PATH]/[DIRECTORY]/, identify:
- Public classes/functions/types and their signatures (params + return types)
- Key intra-project imports (skip external packages)
- Write the result as YAML to
.claude/structure/[module]-[directory].yamlGuidelines:
- Only include PUBLIC interfaces, skip private/internal
- Keep signatures concise — param names and types, return type
- Include a one-line description for each file and each export
- For API handlers, include HTTP method + route
- Don't include function bodies or implementation details
- For obvious signatures (like Android lifecycle methods), omit params
- Skip imports that are obvious from context
Naming convention: [module]-[directory].yaml, e.g.:
backend-controllers.yamlbackend-services.yamlapp-fragments.yamlapp-network.yaml
For small directories (< 5 files), combine related ones into a single file.
Tier 1: File Map Format
Plain text, one line per file. Designed for minimal token footprint while answering "where is X?"
# Controllers
src/controllers/auth.ts - POST register, login, google, refresh, logout, password reset
src/controllers/users.ts - GET/PATCH/DELETE user profile, avatar upload/download
src/controllers/groups.ts - Group CRUD, members, invites, activity feed, exports
# Services
src/services/authorization.ts - Role checks: requireGroupMember, requireGroupAdmin, etc.
src/services/subscription.service.ts - Tier logic, group limits, downgrade handling
src/services/fcm.service.ts - Firebase push notifications and topic messaging
# Middleware
src/middleware/authenticate.ts - JWT bearer token verification
src/middleware/errorHandler.ts - ApplicationError class + global error handler
src/middleware/rateLimiter.ts - Rate limiters for API, auth, password reset
Tier 2: Detailed YAML Format
Self-documenting, per-directory. Only read when working in that area.
# backend-controllers structure detail
module: my-backend
directory: controllers/
description: Express route handlers
files:
auth.ts:
description: Authentication endpoints
exports:
- name: register
kind: function
params: [{name: req, type: AuthRequest}, {name: res, type: Response}]
returns: Promise<void>
description: POST /api/auth/register - Create user with email/password
- name: login
kind: function
description: POST /api/auth/login - Authenticate with email/password
- name: googleAuth
kind: function
description: POST /api/auth/google - Sign in/register with Google OAuth
imports:
- from: services/auth.service
items: [verifyPassword, createUser]
- from: utils/jwt
items: [generateAccessToken, generateRefreshToken]
Format Conventions
kind:function,class,interface,type,object,exportparams: Array of{name, type}. Omit for obvious signatures (lifecycle methods, simple getters).returns: Return type. Omit for void or when obvious.description: One line. Include HTTP method + route for API handlers.imports: Only intra-project dependencies. Skip external packages.
What to Include
- All public functions, classes, interfaces, types, constants
- Method signatures (params + return types) for non-obvious interfaces
- Intra-project imports
- One-line descriptions
What to Exclude
- Private/internal functions and properties
- Function bodies or implementation details
- External package imports
- Obvious lifecycle method signatures (onCreate, onViewCreated, etc.)
- Parameter types when obvious from name (e.g.,
context: Context) - Test files, config files
How It Works
The system has two tiers and one enforcement point:
Tier 1 — File map in CLAUDE.md (always loaded, zero cost): Answers "where is X?" without any file reads. Loaded automatically in the system prompt every session.
Tier 2 — Per-directory YAML (loaded on demand): Answers "what does X export?" when you need to understand a specific area. Read only the relevant directory file, not the entire codebase.
TaskCompleted hook (structural changes only): Blocks task completion when files/classes/functions are added, removed, or renamed. Does NOT block for bug fixes or implementation changes within existing functions.
Workflow
New session
→ Claude reads CLAUDE.md (automatic, includes file map)
→ Instant orientation: knows where everything is
→ Needs to work in controllers/ → reads .claude/structure/backend-controllers.yaml
→ Works on tasks, modifies code
→ Adds a new controller function
→ Tries to mark task complete
→ Hook fires: "were files/classes/functions added/removed/renamed?"
→ Yes: blocked until file map + structure YAML updated
→ Updates both, task completes
→ Next task: fix bug in existing service function
→ Tries to mark task complete
→ Hook fires: only a body change, no structural change
→ Passes through, no update needed
Maintenance
- File map is the primary index. Keep it accurate — it's what gets read every session.
- Structure YAMLs are secondary detail. Update when structural changes happen, but don't obsess over keeping method signatures perfectly current.
- Git-tracked. Commit both the file map (in CLAUDE.md) and structure files alongside code changes.
- Periodic validation. If you suspect drift, re-run the Haiku generation and diff.
- Split threshold. A single YAML file works well up to ~300 lines. Beyond that, split further by subdirectory.
Estimated Costs
- Tier 1 reading (per session): 0 extra tokens (embedded in CLAUDE.md, already loaded)
- Tier 2 reading (per deep exploration): ~100-300 lines per directory file
- Initial generation (Haiku agents): ~50K tokens per module, ~$0.01-0.03
- Hook evaluation: ~1K tokens per task completion, fraction of a cent
- Structure updates: only on structural changes, not every code edit
Design Principles
- Zero-cost orientation. The file map in CLAUDE.md means every session starts with full codebase awareness at no extra token cost.
- Read on demand, not up front. Detailed YAML files are only read when working in that area. Most sessions read 0-1 detail files.
- Structural changes only. The hook and update obligation only apply when the codebase structure changes (new/removed/renamed items), not for every line of code.
- The repo is the source of truth. Structure files are an index, not an authority. If there's a conflict, the code wins.
- Split by directory, not by module. Keeps individual reads small and targeted. Never read 1000+ lines to find one function.
- Minimal infrastructure. Files, a CLAUDE.md section, and one hook. No databases, no servers, no build steps.
先判断是否适合
作者设计意图
作者的方法与取舍
边界和复核