Back to Details

feature-discovery

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Feature Discovery

功能发现

Purpose

用途

Perform a read-only discovery pass over one or more projects. Explain what the requested topic does, how it works, where it is used, and why it may have been needed.
Use this skill for prompts shaped like:
markdown
Projects Affected: [Project Code], [Project Code]

What:
[FEATURE / ISSUE / BEHAVIOR / MODULE / WORKFLOW]
对一个或多个项目执行只读式的发现扫描。解释请求的主题是什么、如何运作、使用场景以及可能的需求背景。
当用户的提示符合以下格式时使用此技能：
markdown
Projects Affected: [Project Code], [Project Code]

What:
[FEATURE / ISSUE / BEHAVIOR / MODULE / WORKFLOW]

Rules

规则

  • Stay read-only. Do not edit files.
  • Prefer CLI tools over MCP.
  • Use 
    rg
    first for text search.
  • Use 
    git
    , 
    git grep
    , 
    find
    , package metadata, local docs, and tests as needed.
  • When the active agent runtime supports sub-agents and the user has allowed them, use explorer agents for independent read-only discovery work.
  • Use multiple explorer agents in parallel when projects, modules, or evidence streams can be investigated independently.
  • Keep the main session responsible for synthesis, evidence quality, uncertainty calls, and final reporting.
  • Do not run 
    git fetch
    , 
    git pull
    , installs, migrations, or destructive commands.
  • Scan the codebase before using git history.
  • Review git commits only when code scanning does not explain the topic clearly.
  • If git history is needed, review only the last 2 months.
  • Back concrete claims with file paths, symbols, commands, tests, docs, or commits.
  • Separate confirmed facts from inference.
  • Do not invent memory or rationale.
  • 保持只读状态，不要编辑文件。
  • 优先使用CLI工具而非MCP。
  • 首先使用
    rg
    进行文本搜索。
  • 根据需要使用
    git
    、
    git grep
    、
    find
    、包元数据、本地文档和测试。
  • 当活跃的Agent运行时支持子Agent且用户已允许的情况下，使用探索Agent进行独立的只读发现工作。
  • 当项目、模块或证据流可独立调查时，并行使用多个探索Agent。
  • 主会话负责结果整合、证据质量把控、不确定性判断和最终报告输出。
  • 不要运行
    git fetch
    、
    git pull
    、安装、迁移或破坏性命令。
  • 在查看git历史之前先扫描代码库。
  • 仅当代码扫描无法清晰解释主题时，才查看git提交记录。
  • 如果需要查看git历史，仅查看最近2个月的内容。
  • 所有具体结论都需附上文件路径、符号、命令、测试、文档或提交记录作为依据。
  • 将已确认的事实与推断内容区分开。
  • 不要编造记忆或理由。

Workflow

工作流程

  1. Parse the request:
    • Identify project codes from 
      Projects Affected
      .
    • Identify the topic from 
      What
      .
    • Note explicit constraints, dates, branches, modules, or terms.
  2. Locate project roots:
    • Find relevant git roots and package/app boundaries.
    • Map project codes to folders by repo names, package metadata, READMEs, config, or naming conventions.
    • If a project code cannot be mapped, state that early and continue best-effort.
  3. Discover the topic:
    • Search exact terms from 
      What
      .
    • Search likely aliases, route names, component names, API paths, config keys, env vars, table names, filenames, and test names.
    • Trace definitions to callers.
    • Trace user-facing flows from entry points to lower-level services.
    • Include tests, docs, configs, migrations, routes, background jobs, and feature flags when relevant.
    • If using explorer agents, split work by project, module, or evidence type and require each explorer to return file paths, symbols, commands, and uncertainty.
  4. Use git history only if needed:
    • Limit to the last 2 months.
    • Look for commits touching discovered files or mentioning the topic.
    • Use commit history to explain why or when behavior changed, not as the primary source of truth.
  5. Validate findings:
    • Cross-check code against tests, docs, configs, and usage sites.
    • Mark dead code, unclear ownership, missing tests, contradictory evidence, and unverified assumptions.
    • Avoid broad claims when evidence is partial.
  1. 解析请求：
    • 从
      Projects Affected
      中识别项目代码。
    • 从
      What
      中识别主题。
    • 记录明确的约束条件、日期、分支、模块或术语。
  2. 定位项目根目录：
    • 找到相关的git根目录和包/应用边界。
    • 通过仓库名称、包元数据、README、配置或命名约定将项目代码映射到文件夹。
    • 如果无法映射项目代码，尽早说明并继续尽最大努力完成任务。
  3. 探索主题：
    • 搜索
      What
      中的精确术语。
    • 搜索可能的别名、路由名称、组件名称、API路径、配置键、环境变量、表名、文件名和测试名称。
    • 追踪定义到调用方的链路。
    • 追踪从入口点到底层服务的用户交互流程。
    • 相关时纳入测试、文档、配置、迁移、路由、后台任务和功能标志。
    • 如果使用探索Agent，按项目、模块或证据类型拆分工作，并要求每个探索Agent返回文件路径、符号、命令和不确定性说明。
  4. 仅在必要时使用git历史：
    • 限制为最近2个月的内容。
    • 查找涉及已发现文件或提及主题的提交记录。
    • 使用提交历史解释行为变更的原因或时间，而非作为主要事实来源。
  5. 验证发现结果：
    • 对照测试、文档、配置和使用场景交叉检查代码。
    • 标记死代码、不明确的所有权、缺失的测试、矛盾的证据和未验证的假设。
    • 当证据不完整时，避免做出宽泛的结论。

Search Defaults

默认搜索命令

Adapt commands to the repo. Keep command output summarized in the final report.
bash
rg -n "exact topic|likely alias|route|config_key" .
find . -maxdepth 4 \( -name package.json -o -name README.md -o -name .git \)
git grep -n "term"
git log --since="2 months ago" --oneline --all -- <relevant-path>
根据仓库适配命令。在最终报告中总结命令输出。
bash
rg -n "exact topic|likely alias|route|config_key" .
find . -maxdepth 4 \( -name package.json -o -name README.md -o -name .git \)
git grep -n "term"
git log --since="2 months ago" --oneline --all -- <relevant-path>

Output Format

输出格式

Use this structure exactly.
markdown
undefined
严格遵循以下结构。
markdown
undefined

Feature Discovery: [Topic]

Feature Discovery: [Topic]

1. Summary

1. Summary

  • [Short answer: what this is and where it lives.]
  • [Main finding or current behavior.]
  • [Important caveat, if any.]
  • [简短说明：该主题是什么以及所在位置。]
  • [主要发现或当前行为。]
  • [重要注意事项（如有）。]

2. What It Does

2. What It Does

  • [Describe the behavior in product/domain terms.]
  • [Mention inputs, outputs, side effects, or user-visible result.]
  • [Mention relevant project(s).]
  • [用产品/领域术语描述行为。]
  • [提及输入、输出、副作用或用户可见结果。]
  • [提及相关项目。]

3. How It Works

3. How It Works

  • [Step-by-step flow.]
  • [Key files, functions, classes, routes, configs, jobs, services, or data models.]
  • [Important conditions, flags, dependencies, or error paths.]
  • [分步流程。]
  • [关键文件、函数、类、路由、配置、任务、服务或数据模型。]
  • [重要条件、标志、依赖项或错误路径。]

4. Where It Is Used

4. Where It Is Used

  • [Usage site 1 with file reference.]
  • [Usage site 2 with file reference.]
  • [Tests/docs/configs that confirm usage.]
  • [使用场景1，附文件引用。]
  • [使用场景2，附文件引用。]
  • [确认使用情况的测试/文档/配置。]

5. Why It Was Needed / Memory

5. Why It Was Needed / Memory

  • [Use conversation memory, local docs, comments, issues, or recent commits if available.]
  • [If not found: "No reliable rationale found in available memory, docs, comments, or recent git history."]
  • [如有可用，使用对话记忆、本地文档、注释、问题或近期提交记录。]
  • [如果未找到：“在可用记忆、文档、注释或近期git历史中未找到可靠依据。”]

6. Risks, Gaps, And Recommended Next Checks

6. Risks, Gaps, And Recommended Next Checks

  • [Risk, ambiguity, dead code, missing test, or unclear owner.]
  • [Recommended next check.]
  • [State what could not be verified.]
undefined
  • [风险、歧义、死代码、缺失测试或不明确的所有者。]
  • [建议的下一步检查。]
  • [说明无法验证的内容。]
undefined

Evidence Style

证据格式

Prefer concise evidence bullets:
markdown
- `apps/admin/src/routes/users.ts`: defines the route.
- `packages/auth/src/session.ts`: validates the session before the route runs.
- `apps/admin/src/routes/users.test.ts`: covers the disabled-user case.
- Commit `abc1234` from 2026-04-12: introduced the feature flag.
优先使用简洁的证据项目符号：
markdown
- `apps/admin/src/routes/users.ts`: defines the route.
- `packages/auth/src/session.ts`: validates the session before the route runs.
- `apps/admin/src/routes/users.test.ts`: covers the disabled-user case.
- Commit `abc1234` from 2026-04-12: introduced the feature flag.

Quality Bar

质量标准

The final answer should let another engineer understand:
  • what the thing is
  • what it does
  • how it works
  • where it is used
  • what evidence supports the explanation
  • what remains uncertain
最终答案应让其他工程师能够理解：
  • 该主题是什么
  • 它的作用是什么
  • 它如何运作
  • 使用场景在哪里
  • 哪些证据支持该解释
  • 哪些内容仍不确定