Token导航 LogoToken导航

Agent Skill · 待分类

requirements-extractor(需求提取器)

用于辅助安全审计、权限检查、凭据风险、认证流程和常见漏洞排查。它适合让 Agent 梳理敏感配置、检查依赖风险、分析鉴权逻辑或生成安全复核清单。使用时不能把工具输出直接当最终结论,涉及密钥、令牌、用户数据或生产系统时,应先确认最小权限、脱敏方式和操作边界。

requirements-extractor 是待分类类 Agent Skill,可用宿主为 Codex、Claude、Cursor、Gemini CLI,通过GitHub 仓库获取,权限为接触敏感数据;许可证为 MIT,第三方扫描有提醒项,按安装量在待分类类的 11,209 个 Skill 里排第 7,063。

总安装 392周安装 16GitHub Stars 21下载 125核验 2026-05-01

安装说明

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

安装方式

通过对话安装

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

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

命令行安装

复制命令到本机终端执行。不同来源提供的安装方式可能略有差异;本站展示可直接复制的安装命令,安装前请核对来源页面。

skills.shnpx skills
npx skills add https://github.com/matteocervelli/llms --skill requirements-extractor

这个 Skill 是做什么的

这个 Skill 的分类还没最终确定,用法以来源仓库的说明为准。

用于辅助安全审计、权限检查、凭据风险与认证流程排查。适合梳理敏感配置、分析鉴权逻辑或生成安全复核清单。不能将工具输出直接作为最终结论,涉及密钥或生产系统时应先确认最小权限。使用时应脱敏用户数据并明确操作边界。requirements-extractor 属于待分类类 Skill,可作为该场景下的辅助能力补充。

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

上手步骤

4 步
  1. 1

    确认自己的宿主工具

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

  2. 2

    拿到安装命令

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

  3. 3

    安装后重启宿主

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

  4. 4

    按最小权限试用

    它需要接触敏感数据,先在测试目录或测试账号里跑,确认没问题再放到正式项目。

常见问题

6 条

requirements-extractor 怎么安装?

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

requirements-extractor 支持哪些 AI 工具?

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

requirements-extractor 需要什么权限?

权限级别是接触敏感数据。该 Skill 可能接触密钥、Token、环境变量或敏感配置,应进入高风险复核队列,默认不自动发布。

requirements-extractor 是免费的吗?

来源标注的许可证是 MIT。本站不代收任何费用,也不托管安装包;能否商用、要不要署名,以许可证原文为准。

requirements-extractor 用的人多吗?

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

requirements-extractor 安全吗?

第三方扫描有提醒项,说明存在需要人工确认的行为。安装前请打开源码看清它读了什么、联网到哪里。

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

值得选的地方

  • 同时适配 4 种工具,换客户端不用重新找替代品。
  • 3 个目录同时收录,说明这个 Skill 流传比较广。
  • 许可证明确为 MIT,商用和分发边界好判断。

先想清楚的地方

  • 需要接触敏感数据,装到常用环境前要先评估影响面。
  • 第三方扫描存在提醒项或未通过项,需要人工逐条确认。
  • 第三方目录整理,版本更新和行为细节以来源仓库为准。

适不适合你

更适合

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

不太适合

  • 环境里有大量密钥、凭证,不方便给第三方 Skill 读取的人。
  • 需要厂商级技术支持和 SLA 的生产系统。

待分类类 Skill 对比

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

infsh CLI · Codex、Claude

4,374,576382权限未标注未明确未收录
ai-video-generation

AI 视频生成 · Codex、Claude

4,313,376382调用外部服务未明确有提醒
lark-openapi-explorer

云雀 OpenAPI 浏览器 · Codex、Claude

2,064,1209,011需要联网未明确有提醒
lark-workflow-standup-report

Lark 工作流程站立报告 · Codex、Claude

2,041,6328,978需要联网未明确通过
use-my-browser

使用我的浏览器 · Codex、Claude

1,848,49140操作浏览器未明确未通过
requirements-extractor

需求提取器 · 本页

39221接触敏感数据MIT有提醒

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

SKILL.md 原文

Purpose

The requirements-extractor skill provides structured methods for parsing GitHub issues to extract and organize requirements information. It ensures that all requirements are properly identified, categorized, and documented in a format suitable for downstream design and implementation phases.

When to Use

This skill auto-activates when you:

  • Analyze GitHub issues for requirements
  • Parse feature requests or bug reports
  • Extract acceptance criteria from issue descriptions
  • Identify user stories (As a... I want... So that...)
  • Distinguish functional from non-functional requirements
  • Clarify ambiguous or missing requirements

Provided Capabilities

1. Requirement Identification

  • Functional Requirements: What the system must do
  • Non-Functional Requirements: Quality attributes (performance, security, usability, scalability)
  • Business Requirements: Business goals and objectives
  • User Requirements: User-facing capabilities
  • System Requirements: Technical system capabilities

2. Acceptance Criteria Extraction

  • Parse acceptance criteria from issue body
  • Identify testable conditions
  • Convert narratives to checkable criteria
  • Flag missing or ambiguous criteria

3. User Story Parsing

  • Identify user story format: "As a [role], I want [feature], so that [benefit]"
  • Extract role, feature, and benefit components
  • Parse epic stories vs. individual stories
  • Link related stories

4. Requirement Categorization

  • Must Have (P0): Critical for MVP
  • Should Have (P1): Important but not critical
  • Could Have (P2): Desirable but optional
  • Won't Have (P3): Out of scope for this release

5. Requirement Validation

  • Check for completeness using requirements-checklist.md
  • Identify ambiguous language
  • Flag conflicting requirements
  • Ensure testability

Usage Guide

Step 1: Fetch Issue Content

gh issue view <issue-number> --json title,body,labels,comments --repo matteocervelli/llms

Step 2: Parse Issue Structure

Look for these patterns in issue body:

Functional Requirements Indicators:

  • "The system must..."
  • "The feature should..."
  • "Users can..."
  • "When X happens, then Y..."

Non-Functional Requirements Indicators:

  • "Response time..."
  • "Must handle N concurrent users..."
  • "Should be accessible to..."
  • "Must comply with..."
  • "Performance target..."

Acceptance Criteria Indicators:

  • "Acceptance Criteria:"
  • "Definition of Done:"
  • Checklist items: - []
  • "Given... When... Then..." (BDD format)

User Stories Indicators:

  • "As a..."
  • "User persona..."
  • "Use case..."

Step 3: Extract Functional Requirements

Parse statements that describe what the system does:

### Functional Requirements
1. **[FR-001]** User Authentication: System must authenticate users via email/password
2. **[FR-002]** Data Export: Users can export data to CSV, JSON, or PDF formats
3. **[FR-003]** Real-time Updates: System must push updates to clients within 5 seconds

Naming Convention: FR-XXX for functional requirements

Step 4: Extract Non-Functional Requirements

Parse quality attributes:

### Non-Functional Requirements

#### Performance
- **[NFR-P-001]** API response time must be < 200ms for 95th percentile
- **[NFR-P-002]** System must handle 1000 concurrent users

#### Security
- **[NFR-S-001]** All data transmission must use TLS 1.3+
- **[NFR-S-002]** Passwords must be hashed with bcrypt (cost factor ≥12)

#### Usability
- **[NFR-U-001]** UI must be WCAG 2.1 Level AA compliant
- **[NFR-U-002]** All actions must be reversible within 30 seconds

#### Scalability
- **[NFR-SC-001]** Architecture must support horizontal scaling
- **[NFR-SC-002]** Database must handle 10M+ records without degradation

Naming Convention: NFR-[Category]-XXX

Step 5: Extract Acceptance Criteria

Convert issue acceptance criteria to structured format:

### Acceptance Criteria

- [ ] **AC-001**: User can log in with valid credentials
  - Given valid email and password
  - When user submits login form
  - Then user is redirected to dashboard
  - And session token is created

- [ ] **AC-002**: Invalid login shows error message
  - Given invalid credentials
  - When user submits login form
  - Then error message displays: "Invalid email or password"
  - And user remains on login page
  - And login attempt is logged

- [ ] **AC-003**: Forgot password link is visible
  - Given user is on login page
  - When user views page
  - Then "Forgot Password?" link is visible
  - And link navigates to password reset flow

Naming Convention: AC-XXX for acceptance criteria

Step 6: Parse User Stories

Extract user stories in standard format:

### User Stories

**Story 1**: User Login
- **As a** registered user
- **I want to** log in with my email and password
- **So that** I can access my personalized dashboard
- **Priority**: Must Have (P0)
- **Acceptance Criteria**: AC-001, AC-002, AC-003

**Story 2**: Guest Browsing
- **As a** guest visitor
- **I want to** browse public content without logging in
- **So that** I can evaluate the platform before registering
- **Priority**: Should Have (P1)
- **Acceptance Criteria**: AC-004, AC-005

Step 7: Categorize by Priority

Use MoSCoW method:

### Requirement Priorities

#### Must Have (P0) - Critical for MVP
- FR-001: User Authentication
- FR-003: Real-time Updates
- NFR-S-001: TLS encryption

#### Should Have (P1) - Important
- FR-002: Data Export
- NFR-U-001: WCAG compliance

#### Could Have (P2) - Desirable
- FR-005: Dark mode support
- NFR-P-003: CDN integration

#### Won't Have (P3) - Out of scope
- FR-010: AI-powered recommendations (future release)

Step 8: Validate Using Checklist

Use requirements-checklist.md to validate each requirement:

# Check against requirements checklist
# Manually verify each criterion from requirements-checklist.md

Validation Criteria:

  • ✅ Clear and unambiguous
  • ✅ Testable
  • ✅ Complete
  • ✅ Consistent (no conflicts)
  • ✅ Traceable to business goals
  • ✅ Feasible with available resources

Step 9: Flag Issues

Identify and document:

### Requirement Issues

**Ambiguous Requirements**:
- FR-007: "System should be fast" → Needs quantification (What is "fast"?)
- FR-012: "Easy to use" → Needs specific usability criteria

**Missing Requirements**:
- No error handling requirements specified for API failures
- Logging and monitoring requirements not defined
- Backup and recovery procedures not mentioned

**Conflicting Requirements**:
- FR-015 requires real-time sync, but NFR-P-005 sets 5-minute update interval

Best Practices

1. Be Thorough

  • Read entire issue including comments
  • Check linked issues and PRs
  • Review labels and milestones
  • Look for implicit requirements

2. Use Standard Formats

  • Consistent naming conventions
  • Structured templates
  • Clear categorization
  • Numbered identifiers

3. Validate Completeness

  • Every requirement has ID
  • Every requirement is testable
  • Every requirement has priority
  • Every requirement traces to business goal

4. Handle Ambiguity

  • Flag vague language
  • Request clarification
  • Document assumptions
  • Provide examples

5. Consider Non-Obvious Requirements

  • Error handling
  • Logging and monitoring
  • Performance under load
  • Data migration needs
  • Backward compatibility
  • Accessibility
  • Internationalization
  • Privacy and compliance

Resources

requirements-checklist.md

Comprehensive checklist for validating requirements including:

  • Completeness criteria
  • Clarity criteria
  • Consistency checks
  • Testability validation
  • Feasibility assessment

extraction-patterns.md

Common patterns for identifying requirements in natural language:

  • Keywords and phrases
  • Sentence structures
  • Issue templates
  • Standard formats (BDD, user stories)

Example Usage

Input (GitHub Issue)

Title: Add user authentication feature

Description:
As a user, I want to log in with my email and password so that I can access my personal data.

The system should support:
- Email/password login
- "Remember me" option
- Forgot password flow
- Account lockout after 5 failed attempts

Acceptance Criteria:
- [ ] User can log in with valid credentials
- [ ] Invalid login shows error message
- [ ] Password reset email sent within 1 minute
- [ ] Locked accounts show appropriate message

Output (Extracted Requirements)

## Requirements

### Functional Requirements
1. **[FR-001]** Email/Password Authentication: System must authenticate users via email and password
2. **[FR-002]** Remember Me: System must provide "remember me" checkbox to maintain session
3. **[FR-003]** Password Reset: System must send password reset email when user requests
4. **[FR-004]** Account Lockout: System must lock account after 5 consecutive failed login attempts

### Non-Functional Requirements

#### Security
- **[NFR-S-001]** Password storage must use bcrypt hashing
- **[NFR-S-002]** Session tokens must expire after 24 hours (unless "remember me")
- **[NFR-S-003]** Login attempts must be rate-limited (max 10/hour per IP)

#### Performance
- **[NFR-P-001]** Password reset email must be sent within 1 minute
- **[NFR-P-002]** Login response time must be < 500ms

#### Usability
- **[NFR-U-001]** Error messages must not reveal whether email exists
- **[NFR-U-002]** Locked account message must provide unlock instructions

### Acceptance Criteria
- [ ] **AC-001**: User can log in with valid email/password
- [ ] **AC-002**: Invalid login shows generic error message
- [ ] **AC-003**: Password reset email sent within 1 minute of request
- [ ] **AC-004**: Account locked after 5 failed attempts with clear message
- [ ] **AC-005**: "Remember me" extends session to 30 days

### User Stories
**Story 1**: User Login
- **As a** registered user
- **I want to** log in with email and password
- **So that** I can access my personal data
- **Priority**: Must Have (P0)

Integration

This skill is used by:

  • analysis-specialist agent during Phase 1: Requirements Analysis
  • Activates automatically when agent analyzes GitHub issues
  • Provides structured output for analysis document generation

Version: 2.0.0 Auto-Activation: Yes (when extracting requirements) Phase: 1 (Requirements Analysis) Created: 2025-10-29

平台分布

Antigravity

26.39%
按下载量换算33

OpenCode

25.37%
按下载量换算32

Claude Code

16.36%
按下载量换算20

Codex

13.44%
按下载量换算17

Gemini CLI

7.33%
按下载量换算9

github-copilot

3.69%
按下载量换算5

安全审计

Gen Agent Trust Hub

通过

Socket

通过

Snyk

可疑

权限和风险

接触敏感数据

该 Skill 可能接触密钥、Token、环境变量或敏感配置,应进入高风险复核队列,默认不自动发布。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。来源安全扫描存在提醒或未通过项,安装前请自行复核。

继续浏览同类 Skills