Install
$ agentstack add skill-jinsyin-skills-to-requirements ✓ scanned · ✓ verified, works with Claude Code, Cursor, and more.
Security review
✓ PassedNo issues found. Passed automated security review. · v0.1.0 How review works →
- ✓ Prompt-injection patterns
- ✓ Secret / credential exfiltration
- ✓ Dangerous shell & filesystem operations
- ✓ Untrusted network calls
- ✓ Known-malicious package signatures
What it can access
- ✓ Network access No
- ✓ Filesystem access No
- ✓ Shell / process execution No
- ✓ Environment & secrets No
- ✓ Dynamic code execution No
From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.
Verified badge
Passed review? Show it. Paste this badge into your README, it links to the public security report.
Reliability & compatibility
Declared compatibility
Compatibility is declared by the source manifest. End-to-end runtime verification is coming, see below.
We're building live execution health for every listing: tool-call success rate, median latency, uptime, and last-checked timestamps, measured, not self-reported. It isn't live yet, so we don't show numbers we can't stand behind.
How agent discovery & health will work →About
to-requirements
将口述需求与上下文方案整理为可追溯的原始需求文档。Reply in Chinese unless the user requests another language.
基本原则
- 把用户原话、当前对话、用户点名的本地材料和已有
REQUIREMENTS.md视为事实来源。 - 区分「要实现什么」与「可参考的实现方案」。不要把参考架构、竞品做法或开源项目能力自动升级为需求。
- 允许重组和精炼措辞,但不得新增功能、技术选型、交付物、竞品或链接。
- 对缺失、含糊、互相冲突的信息必须提问。允许用户明确回答「无」「不适用」或「暂不确定」,不得替用户作答。
- 未经用户要求,不主动做竞品调研或技术选型;本 skill 负责整理与确认,不负责扩写方案。
开始前读取 [references/requirements-structure.md](references/requirements-structure.md),以其中的章节、必填信息和渲染规则为准。
工作流
1. 确定输入与目标
- 把触发本 skill 的用户消息及其明确引用的上下文作为原始输入。
- 定位项目根目录:优先使用 Git 根目录;不在 Git 仓库时使用当前工作目录。
- 默认目标是
/REQUIREMENTS.md。用户指定其他路径时服从用户。 - 若目标文件已存在,先完整读取并判断用户是补充、重整还是替换。用户意图不明确时,先确认;不得直接覆盖。
2. 提取并分栏
先在工作记录中提取以下四类信息,不要立刻写文件:
| 类型 | 内容 | |---|---| | 已确认需求 | 用户明确要求的目标、能力、交付物、边界 | | 上下文方案 | 技术设想、产品方案、集成方式、参考实现 | | 外部参考 | 竞品、文档、开源项目及其链接与参考目的 | | 待确认项 | 缺失字段、歧义、冲突、无法判断的归类 |
保留重要限定词,如「仅」「至少」「不支持」「按需」「必须」「后续」。不得用更强或更弱的词替换。
3. 映射到固定骨架
按 reference 中的字段清单把信息映射到四个章节。映射时遵守:
- 一个事实只放在最合适的一处,避免四处重复。
- 「产品交付矩阵」写交付形态及使用/接入方式,不把内部模块清单冒充交付物。
- 「产品功能调研」只记录待调研对象、链接和调研目标,不假装已经完成调研。
- 「技术实现参考」必须标明仅作参考,不代表复制、模仿或已选型。
- 对现有文档进行更新时,保留未被用户推翻的原始信息;发现新旧冲突时列入待确认项。
4. 做缺口审计并访谈
逐项检查 reference 中标为「必须确认」的内容。只问输入和现有文件无法回答的问题。
- 每轮最多问 4 个问题,相关问题放在同一轮。
- 每个问题先说明已知信息或缺口,再提出一个可直接回答的问题。
- 有合理候选时给出候选,但始终允许用户自行表述。
- 用户答「暂不确定」时,继续确认文档应写成「待定」还是明确排除;不要自行选择。
- 若交互工具不可用,就在回复中列出问题并停止等待用户回答。绝不在用户看不到问题时自答。
四个章节均已覆盖,或用户已明确确认「无 / 不适用 / 待定」后,才能进入写入阶段。
5. 写入 REQUIREMENTS.md
按 reference 的模板渲染全文:
- 标题使用
# - 产品原始需求。 - 保留「原始需求可能随演进变化,以最终实现为准」的说明。
- 始终保留四个一级编号章节和规定的二级结构。
- 对经确认不适用的章节,写一句明确结论,不删除章节。
- 对经确认暂不确定的内容,使用
待定:...并写清需要在什么决策前补齐;不得留下空标题、TODO或占位符。 - 链接使用可读名称和标准 Markdown 链接;不要补造 URL。
若目标文件已存在,只在用户确认的范围内修改。完成后重新读取文件,检查实际落盘内容。
6. 校验与交付
保存后逐项校验:
- 四个编号章节齐全,标题层级与模板一致。
- 不存在空章节、
TODO、模板占位符或未向用户展示的推断。 - 产品要求、交付形态、竞品调研和技术参考没有混栏。
- 用户明确的限制、排除项和「仅作参考」语义没有丢失。
- 同一需求没有重复或相互矛盾的表述。
- 文件路径正确,已有文件未被越权覆盖。
最后报告保存路径,并简要列出用户明确确认的「无 / 不适用 / 待定」项。不要在文件之外继续扩写新需求。
Source & license
This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.
- Author: JinsYin
- Source: JinsYin/skills
- License: MIT
Install and usage instructions live in the source repository linked above.
Reviews
No reviews yet, be the first.
Write a review
Versions
- v0.1.0 Imported from the upstream source.