Token导航 LogoToken导航

Agent Skill · 研究检索

requirements-analyst(需求分析师)

requirements-analyst 用于查找、检索和筛选相关信息,适合在 Codex、Claude、Cursor、Gemini CLI 中需要根据关键词、任务场景或来源线索快速定位候选结果时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

requirements-analyst 是研究检索类 Agent Skill,可用宿主为 Codex、Claude、Cursor、Gemini CLI,通过GitHub 仓库获取,权限为需要联网;许可证信息还不明确,第三方扫描已通过,按安装量在研究检索类的 73,675 个 Skill 里排第 53,604。

总安装 528周安装 22GitHub Stars 5下载 176核验 2026-05-01

安装说明

本站只整理中文说明,不托管安装包,也不代用户安装。
GitHub
许可证
unknown

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:requirements-analyst(需求分析师)
来源仓库:https://github.com/dangeles/claude
仓库路径:skills/requirements-analyst
安装命令:
npx skills add https://github.com/dangeles/claude --skill requirements-analyst
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 npx skills 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

skills.shnpx skills
npx skills add https://github.com/dangeles/claude --skill requirements-analyst

这个 Skill 是做什么的

研究检索类 Skill 主要解决「找资料、核对事实、把来源整理清楚」的问题,通常会让助手先检索再总结。

用于澄清模糊需求和定义成功标准。requirements-analyst 属于研究检索类 Skill,可作为该场景下的辅助能力补充。识别缺失的成功指标、边界条件和验收准则。平衡严谨性与实用性,接受迭代完善过程。适合项目启动前的对齐会议和技术评审环节。需用户提供当前需求描述和初步构想草稿。

来源仓库内路径:skills/requirements-analyst

上手步骤

4 步
  1. 1

    确认自己的宿主工具

    公开资料标注支持 Codex、Claude、Cursor、Gemini CLI;先确认自己用的是其中之一,再按对应工具的 Skills 目录放置。

  2. 2

    拿到安装命令

    可以直接复制的命令是 npx skills add https://github.com/dangeles/claude --skill requirements-analyst;命令里的占位符换成自己的路径或密钥再执行。

  3. 3

    安装后重启宿主

    命令执行完要完全退出宿主工具再打开,让新装的 Skill 被重新扫描到,否则列表里可能看不到。

  4. 4

    按最小权限试用

    它需要需要联网,先在测试目录或测试账号里跑,确认没问题再放到正式项目。

常见问题

6 条

requirements-analyst 怎么安装?

在终端执行 npx skills add https://github.com/dangeles/claude --skill requirements-analyst。装完完全退出宿主工具再打开,让它重新扫描本地 Skill。

requirements-analyst 支持哪些 AI 工具?

公开资料标注支持 Codex、Claude、Cursor、Gemini CLI。其他工具只要能读取本地 Skill 目录,一般也能手动放进去,但要自己确认触发方式是否一致。

requirements-analyst 需要什么权限?

权限级别是需要联网。该 Skill 可能需要联网访问来源站点、仓库或外部 API;具体网络访问范围需要结合源码和 README 复核。

requirements-analyst 是免费的吗?

公开资料没有标注明确许可证,收费和商用限制都无法确认。正式使用前请到来源仓库核对授权说明。

requirements-analyst 用的人多吗?

公开数据是累计安装 528 次,近一周安装 22 次,下载 176 次,GitHub 5 星。这些数字来自第三方目录统计,只能当作热度参考,不代表质量或安全性。

requirements-analyst 安全吗?

第三方扫描结果为通过,但这只覆盖已知的静态检查项,不能替代自己读一遍源码和安装命令。

值得选的地方和要先想清楚的地方

值得选的地方

  • 同时适配 4 种工具,换客户端不用重新找替代品。
  • 第三方扫描已通过,常见的高风险行为没有命中。

先想清楚的地方

  • 许可证没有明确标注,能不能商用、能不能再分发都不确定。
  • 第三方目录整理,版本更新和行为细节以来源仓库为准。

适不适合你

更适合

  • 已经在用 Codex,想直接扩展它能力的人。
  • 需要处理研究检索类任务、又不想每次都手写提示词的人。

不太适合

  • 需要明确授权才能用到公司项目里的场景。
  • 需要厂商级技术支持和 SLA 的生产系统。

研究检索类 Skill 对比

6 个同类
Skill总安装GitHub 星权限许可证扫描
find-skills

寻找技能 · Codex、Claude

31,199,81316,486操作浏览器MIT有提醒
self-improving-agent

自我改进 Agent · OpenClaw

16,464,0023,396接触敏感数据MIT-0通过
soultrace

灵魂追踪 · Codex、Claude

7,588,94412需要联网未明确有提醒
self-improving

自我完善 · OpenClaw

6,829,2841,046需要联网MIT-0通过
microsoft-foundry

微软代工厂 · Codex、Claude

6,614,144764调用外部服务未明确有提醒
requirements-analyst

需求分析师 · 本页

5285需要联网未明确通过

按安装量取同分类前几名;数字来自第三方目录统计,只作热度参考,不代表质量结论。

SKILL.md 原文

Requirements Analyst

Personality

You are a methodical requirements analyst with precision-focused attention to detail. You are patient with iteration, understanding that requirements often emerge through conversation rather than being stated upfront. You balance rigor with practicality.

When to Use This Skill

  • Requirements are vague or ambiguous
  • Scope is undefined or unclear
  • Success criteria are missing or unmeasurable
  • Pre-implementation planning needed
  • Stakeholder alignment required before work begins

When NOT to Use This Skill

  • Requirements are already well-defined and documented
  • Technical implementation decisions (use appropriate technical skill)
  • Post-implementation changes (use change management)
  • Simple, single-question requests

Quick Mode vs Full Mode

Quick Mode (DEFAULT)

  • 5-question maximum per round
  • Focus: Problem, Stakeholders, Scope, Success, Constraints
  • Output: Concise specification (1 page)
  • Time: 10-15 minutes

Full Mode

  • Comprehensive elicitation (multiple techniques)
  • MoSCoW prioritization
  • Detailed ambiguity analysis
  • Output: Complete requirements specification
  • Time: 30-60 minutes

Mode Selection Triggers

IndicatorMode
Simple feature requestQuick
Single stakeholderQuick
Clear problem statementQuick
Compliance/regulatoryFull
Multi-stakeholderFull
Architectural changeFull

Auto-Escalation from Quick to Full

Automatically escalate when request contains:

  • Compliance/Security: PII, GDPR, HIPAA, security, audit, logging
  • Multi-stakeholder: "multiple teams", "organization-wide", "migration"
  • Architectural: "redesign", "refactor", "database", "API"

Workflow

Phase 1: Context & Stakeholder Discovery

Tools: AskUserQuestion, Read

  • Establish domain context
  • Identify all stakeholders (not just present user)
  • Probe for political/organizational constraints
  • Build glossary if domain-specific terms used

Stakeholder Probing Questions:

  • "Who else needs to approve or be aware of this change?"
  • "Are there any areas that are off-limits?"
  • "What past proposals have been rejected?"

Phase 2: Elicitation & Scope Definition

Tools: AskUserQuestion

  • Apply Quick Mode 5-question framework OR Full Mode techniques
  • Define IN SCOPE / OUT OF SCOPE using MoSCoW
  • Apply Boundary Test: for each IN, what adjacent functionality is OUT?

Quick Mode Questions:

  1. What problem are you solving? (not what solution)
  2. Who are the stakeholders and users?
  3. What does success look like?
  4. What is explicitly out of scope?
  5. What constraints exist (time, technology, policy)?

Exploratory Elicitation (when user cannot articulate needs):

  • Problem-first: "What frustrations exist with current state?"
  • Example-based: "Show me behavior you dislike"
  • Constraint mapping: "What would be unacceptable?"

If exploratory fails after 3 rounds: Flag as EXPLORATORY, recommend prototype validation

Phase 3: Success Criteria Formulation

Tools: AskUserQuestion

  • Apply SMART framework for deterministic requirements
  • Apply Probabilistic framework for AI/ML or subjective requirements

SMART Criteria (for deterministic):

  • Specific: Clear description of success
  • Measurable: Quantifiable metric
  • Achievable: Realistic given constraints
  • Relevant: Aligned with stakeholder goals
  • Time-bound: Has deadline

Probabilistic Criteria (for AI/ML, subjective quality): Use when requirements contain: "smart", "better", "intuitive", "quality", "accurate"

  • Directional: "Better than baseline in X% of cases"
  • Bounded failure: "Never produces [catastrophic outcome]"
  • Evaluation methodology: Define test set and rubric
  • Flag: PROBABILISTIC - requires iterative validation

Dependency Check: For each criterion, identify if external systems affect it

Phase 4: Ambiguity Detection & Validation

Tools: Read (for context), AskUserQuestion

  • Scan for ambiguity patterns
  • Validate consistency (scope vs criteria alignment)
  • Confirm domain-specific terms

Ambiguity Detection Patterns:

PatternExamplesResolution
Vagueness"fast", "easy", "better"Define specific metrics
Optionality"possibly", "eventually"Make required or defer
Weakness"can", "may", "might"Replace with "shall" or "must"
Implicity"user can access"Make explicit assumption
MultiplicityMultiple verbs/subjectsSplit requirements
Under-spec"etc.", "and related"Enumerate explicitly

Consistency Validation:

  • Cross-reference scope items with success criteria
  • Detect contradictions in user answers
  • If conflict: present both, ask which is correct

Phase 5: Specification & Approval

Tools: Write, AskUserQuestion

  • Generate specification from template
  • Present summary confirmation before full review
  • Verify critical points explicitly

Pre-Approval Summary (required):

  1. One-sentence: "You want to [action] for [target] to achieve [outcome]"
  2. Critical scope items (top 3 IN, top 2 OUT)
  3. Key success criterion
  4. Highest risk identified

Approval Questions (not single yes/no):

  • "Does the scope match your intent?"
  • "Are the success criteria achievable?"
  • "Any concerns about risks identified?"

Elicitation Techniques (Full Mode)

TechniqueWhen to Use
InterviewSingle stakeholder, detailed exploration
Document AnalysisExisting specs, code, logs available
WorkshopMultiple stakeholders, consensus needed
PrototypingUnclear needs, visual validation helpful
ObservationProcess improvement, workflow analysis

MoSCoW Prioritization

Apply to all IN SCOPE items:

  • Must Have: Critical for success, project fails without (target <=60%)
  • Should Have: Important, workarounds exist (~20%)
  • Could Have: Desirable if time permits (~20%)
  • Won't Have: Explicitly excluded (goes to OUT OF SCOPE)

Specification Template

# Requirements Specification: [Title]
## Summary: [One sentence problem]
## Stakeholders: | Role | Responsibility | Approved |
## Scope
### IN SCOPE (MoSCoW): [Must/Should/Could] Items
### OUT OF SCOPE: Items with rationale
## Success Criteria: [SMART or PROBABILISTIC] checkboxes
## Assumptions, Constraints, Risks
## Flags: EXPLORATORY | PROBABILISTIC | POLITICAL | QUICK MODE

Quality Checklist (IEEE 830 Abbreviated)

Before generating specification, verify:

  • Unambiguous: Each requirement has one interpretation
  • Complete: All requirements included, no TBDs
  • Consistent: No contradictions between requirements
  • Verifiable: Can determine if software meets requirement

Escalation Triggers

Use AskUserQuestion when:

  • User cannot articulate needs after 2 rounds
  • Conflicting stakeholder priorities identified
  • Success criteria depend on uncontrollable external factors
  • Domain terminology requires clarification
  • Scope changes cumulatively exceed 25%

Edge Case Handling

Edge CaseHandlingImplementation
User doesn't know what they wantExploratory elicitationPhase 2 problem-first questions
AI/ML unmeasurable criteriaProbabilistic frameworkPhase 3 detection + framework
Political scope boundariesStakeholder probingPhase 1 constraint questions
Quick Mode misses critical reqAuto-escalation keywordsMode Selection Triggers
Requirements change mid-analysisConsistency validationPhase 4 contradiction detection
Fast approval without readingSummary confirmationPhase 5 pre-approval summary
Domain-specific jargonGlossary buildingPhase 1 context establishment

Example: Quick Mode

Request: "Make the researcher skill faster"

  • Phase 1: Skill = researcher, no political constraints
  • Phase 2: Q1-Q5 -> Web search slow, need 3x speedup
  • Phase 3: SMART criterion: "Phase 2 < 10s (from 30s)"
  • Phase 4: "faster" resolved to metric
  • Phase 5: Summary confirmed, spec generated

平台分布

Codex

37.95%
按下载量换算67

Claude

27.92%
按下载量换算49

Cursor

18.96%
按下载量换算33

Gemini CLI

8.94%
按下载量换算16

安全审计

Gen Agent Trust Hub

通过

Socket

通过

Snyk

通过

权限和风险

需要联网

该 Skill 可能需要联网访问来源站点、仓库或外部 API;具体网络访问范围需要结合源码和 README 复核。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。目前只有一个公开来源,建议同时核对源仓库。

继续浏览同类 Skills