Token导航 LogoToken导航

Agent Skill · 研究检索

phy-prd-writer(物理 PRD 作家)

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

phy-prd-writer 是研究检索类 Agent Skill,可用宿主为 Local Agent,通过unknown获取,权限为只读;许可证信息还不明确,暂无第三方扫描结果,按安装量在研究检索类的 73,675 个 Skill 里排第 58,150。

总安装 420周安装 17下载 132核验 2026-05-01
研究检索只读unknown未标认证来源可访问许可证需确认审计未展示Local Agent

安装说明

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

安装方式

通过对话安装

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

请帮我安装这个 Agent Skill:phy-prd-writer(物理 PRD 作家)
来源仓库:https://skills.volces.com
仓库路径:phy-prd-writer
安装命令:
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。当前暂无明确安装命令,请以来源页面说明为准。

这个 Skill 是做什么的

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

phy-prd-writer 用于查找、检索和筛选相关信息,适合在 Local Agent 中需要根据关键词、任务场景或来源线索快速定位候选结果时使用。适用于物理产品需求文档撰写、技术规格整理或跨领域知识检索等场景。安装方式未知,建议通过来源仓库进一步确认获取路径和配置方法。

使用前应核实维护状态及是否涉及敏感数据访问或外部资源调用。适用宿主包括 Local Agent,接入前应确认版本、权限和运行环境要求。

来源仓库内路径:phy-prd-writer

上手步骤

4 步
  1. 1

    确认自己的宿主工具

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

  2. 2

    拿到安装命令

    没有现成安装命令,按unknown的说明从来源页面获取,仓库路径是 phy-prd-writer。

  3. 3

    安装后重启宿主

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

  4. 4

    按最小权限试用

    它标注为只读,先用只读任务试一次,确认行为符合预期再扩大使用范围。

常见问题

6 条

phy-prd-writer 怎么安装?

公开资料没有给出可以直接复制的命令,需要按来源页面说明手动安装,仓库内路径为 phy-prd-writer。

phy-prd-writer 支持哪些 AI 工具?

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

phy-prd-writer 需要什么权限?

权限级别是只读。该 Skill 主要提供规则、说明或参考内容,本身偏只读;真正读写文件、联网或执行命令仍取决于宿主 Agent 的任务。

phy-prd-writer 是免费的吗?

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

phy-prd-writer 用的人多吗?

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

phy-prd-writer 安全吗?

没有查到第三方扫描结果,安全性无法从公开资料判断,安装前请自行审查源码、依赖和命令行为。

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

值得选的地方

  • 专注 Local Agent 一种宿主,触发方式和使用习惯不用来回切换。
  • 标注为只读权限,试用阶段不容易误改本地文件。

先想清楚的地方

  • 许可证没有明确标注,能不能商用、能不能再分发都不确定。
  • 没有第三方扫描结果,安全性只能靠自己读源码判断。
  • 第三方目录整理,版本更新和行为细节以来源仓库为准。

适不适合你

更适合

  • 已经在用 Local Agent,想直接扩展它能力的人。
  • 需要处理研究检索类任务、又不想每次都手写提示词的人。
  • 只想先试试效果、不希望它改动本地文件的人。

不太适合

  • 需要明确授权才能用到公司项目里的场景。
  • 要求有安全扫描结论才肯安装的团队。
  • 需要厂商级技术支持和 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调用外部服务未明确有提醒
phy-prd-writer

物理 PRD 作家 · 本页

420—只读未明确未收录

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

SKILL.md 原文

PRD Writer - Multi-Turn Requirements Gathering

Overview

Guide users through creating a professional PRD by asking focused questions one at a time. The goal is to produce a complete, actionable PRD that serves as the single source of truth for the team.

The Process

Phase 1: Problem Discovery (2-3 questions)

Start by understanding the core problem:

  1. Problem Statement: "What specific problem are you trying to solve? Describe the user pain point."
  2. Why Now: "Why is this important to solve now? What happens if we don't solve it?"
  3. Existing Solutions: "How are users currently solving this problem (workarounds, competitors)?"

Phase 2: User & Market (2-3 questions)

  1. Target Users: Ask who the primary users are. Offer common persona types:

- End consumers (B2C) - Business users (B2B) - Internal team members - Developers/Technical users - Other (specify)

  1. User Context: "In what context will users encounter this? (e.g., mobile on-the-go, desktop at work, specific workflow)"
  2. Market Size/Impact: "How many users will this affect? Is this a core feature or nice-to-have?"

Phase 3: Success Metrics (1-2 questions)

  1. Definition of Success: Ask what success looks like. Offer metric types:

- User engagement (DAU, retention, time spent) - Business metrics (revenue, conversion, cost reduction) - Technical metrics (performance, reliability, error rates) - User satisfaction (NPS, CSAT, support tickets)

  1. Specific Targets: "What specific numbers would indicate success? (e.g., 'reduce load time to <2s', 'increase conversion by 15%')"

Phase 4: Scope Definition (2-3 questions)

  1. Core Features: "What are the MUST-have features for v1? List the absolute minimum for launch."
  2. Out of Scope: "What should we explicitly NOT build in this phase? (This prevents scope creep)"
  3. Future Considerations: "What features might come in v2/v3? (Park these for later)"

Phase 5: Constraints & Dependencies (1-2 questions)

  1. Technical Constraints: Ask about limitations:

- Existing tech stack requirements - Integration dependencies - Performance requirements - Security/compliance needs - Budget/resource constraints

  1. Timeline: "What's the target launch date or deadline? Any external dependencies?"

Phase 6: Prioritization (1 question)

  1. MoSCoW Ranking: Present the collected features and ask user to categorize:

- Must: Essential for launch - Should: Important but can defer if needed - Could: Nice-to-have - Won't: Explicitly excluded

Questioning Guidelines

  • One question at a time - Never overwhelm with multiple questions
  • Use AskUserQuestion tool with multiple choice options when categories are clear
  • Offer "Other" option for open-ended responses
  • Summarize understanding after each phase before moving on
  • Allow backtracking - If user wants to revise earlier answers, accommodate
  • Skip if already answered - If user provided info upfront, don't re-ask

Example Question Flow

Q1: "What problem are you solving?"
→ User describes pain point

Q2: "Why is solving this urgent now?"
→ User explains timing

[Summary]: "So we're solving [X] because [Y]. Correct?"
→ User confirms or corrects

Q3: "Who are the primary users?"
→ [Multiple choice with AskUserQuestion]

... continue through phases ...

Output: PRD Document

After gathering all information, generate a complete PRD with this structure:

# PRD: [Product/Feature Name]

## Metadata
| Field | Value |
|-------|-------|
| Author | [User name] |
| Status | Draft |
| Created | [Date] |
| Last Updated | [Date] |

## 1. Problem Statement
[Clear description of the problem and why it matters]

### Why Now?
[Urgency and timing rationale]

## 2. Goals & Success Metrics
### Objectives
- [SMART goal 1]
- [SMART goal 2]

### Success Metrics (KPIs)
| Metric | Current | Target | Timeline |
|--------|---------|--------|----------|
| [Metric 1] | [Baseline] | [Goal] | [When] |

## 3. User & Market
### Target Users
[Primary persona description]

### User Stories
- As a [user type], I want [action] so that [benefit]

### Competitive Landscape
[How users solve this today]

## 4. Scope
### In Scope (v1)
- [Must-have feature 1]
- [Must-have feature 2]

### Out of Scope
- [Explicitly excluded 1]
- [Explicitly excluded 2]

### Future Considerations (v2+)
- [Deferred feature 1]

## 5. Feature Requirements
### Feature: [Name]
**Priority**: Must/Should/Could
**Description**: [What it does]
**Acceptance Criteria**:
- [ ] [Criterion 1]
- [ ] [Criterion 2]

## 6. Technical Constraints
- [Constraint 1]
- [Constraint 2]

### Dependencies
- [External dependency 1]

## 7. Timeline & Milestones
| Milestone | Target Date |
|-----------|-------------|
| Design Complete | [Date] |
| Development Start | [Date] |
| Beta/Testing | [Date] |
| Launch | [Date] |

## 8. Open Questions
- [Unresolved question 1]
- [Unresolved question 2]

## 9. Appendix
[Any additional context, wireframes references, research links]

After PRD Generation

Step 1: Save & Share

  1. Save PRD: Ask where to save (docs/prd/, docs/specs/, or custom path)
  2. Commit to git: Create a commit with the PRD document
  3. Share for review: Suggest sending to stakeholders for feedback

Step 2: Design (if UI/UX involved)

Ask: "Does this feature need UI design?"

  • Yes → Suggest using /brainstorming skill to explore design approaches
  • Yes + need mockups → Suggest /frontend-design for wireframes/prototypes
  • No → Skip to implementation planning

Step 3: Technical Architecture

Ask: "Is this feature complex enough to need a technical architecture design?"

  • Complex feature → Use architect subagent for system design

- Output: component breakdown, data flow, tech selection, interface design

  • Simple feature → Skip to task breakdown

Step 4: Break into Tasks

Ask: "Do you want to break the PRD into development tasks?"

  • Yes → Use planner subagent to create implementation plan

- Break down based on architecture design - Generate TaskCreate items with: - Clear acceptance criteria from PRD - Dependencies marked (blockedBy) - Priority from MoSCoW ranking

Step 5: Implementation

Once tasks are created:

  1. planner → Detailed implementation plan per task
  2. Write code
  3. code-reviewer → Auto-review before commit
  4. test-creator → Generate tests
  5. security-reviewer → If sensitive code

Step 6: Validation

Before shipping:

  1. e2e-runner → Automated testing
  2. Compare against PRD success metrics
  3. Update PRD status to "Shipped"

Workflow Cheatsheet

Phase 0: Requirements
/prd-writer          → Multi-turn Q&A to gather requirements, generate PRD

Phase 1: Planning
architect agent      → Technical architecture design (how to build it)
planner agent        → Break into implementation tasks (what to build)

Phase 2: Implementation
[write code]

Phase 3: Quality Assurance (parallel)
code-reviewer + security-reviewer  → simultaneous review
test-creator                       → add tests

Phase 4: Validation
e2e-runner           → end-to-end validation
doc-updater          → update documentation

PRD status → Shipped

Handoff Prompts

After PRD is complete, offer these next actions:

PRD generated! What would you like to do next?

1. UI/UX Design Exploration (/brainstorming) - if there's an interface
2. Technical Architecture Design (architect) - decide how to build it
3. Break into Development Tasks (planner) - decide what to build
4. Save for now, continue later

Use AskUserQuestion to let user choose.

Key Principles

  • Problem before solution - Never jump to features before understanding the problem
  • Quantify success - Vague goals lead to vague outcomes
  • Explicit exclusions - What you DON'T build is as important as what you do
  • Living document - Remind user to update as requirements evolve
  • YAGNI - Ruthlessly cut features that aren't essential for v1

Lenny's Podcast Wisdom Integration

When writing PRDs, automatically surface relevant wisdom from top product leaders. Use these to enrich the PRD process:

Phase 1: Problem Discovery

April Dunford: "Really great positioning feels so clear, so simple - of course that's what it is."
  • Ask: What are competitive alternatives (including status quo)?
  • Remember: 40% of B2B deals are lost to "no decision" - you're competing with spreadsheets!
Shreyas Doshi: "Most execution problems are actually strategy problems."
  • If user describes execution problems, dig deeper into strategy clarity

Phase 2: Why Now?

Brian Chesky: "If you build a great product and no one knows about it, did you even build a product?"
  • Ask: How will you tell the story of this product?
  • Think about every release as a chapter of a story

Phase 3: Scope Definition

Brian Chesky: "Five teams should do one thing rather than one team do five things."
  • Ruthlessly cut scope
  • Ask: "What would you cut to concentrate on fewer things?"
Brian Chesky: "The best way to slow a project down is add more people to it."
  • Small team, focused scope = faster delivery

Phase 4: Success Metrics

Marty Cagan: "Optimization is easier than innovation; but only innovation wins."
  • Don't just optimize metrics - ask what new value is created
  • Everything in the backlog is a bet - make better bets

Phase 5: Risk Assessment

Shreyas Doshi: Pre-mortem framework After PRD is drafted, suggest running a pre-mortem:
  • Tigers: Real threats that could kill the project
  • Paper Tigers: Seeming threats that aren't real
  • Elephants: Things nobody is talking about

Ask: "What 3 tigers (real threats) could derail this project?"

Phase 6: Prioritization

Shreyas Doshi: LNO Framework
  • L (Leverage): Which features give 10-100x return? Focus here.
  • N (Neutral): Standard features, 1x return
  • O (Overhead): Features with less return than effort

Reference: Wisdom Source

All wisdom sourced from Lenny's Podcast. If you have local transcripts, search them for additional context.

Quick Mode

If user says "quick PRD" or "lean PRD", use abbreviated flow:

  1. Problem (1 question)
  2. Users (1 question)
  3. Success metric (1 question)
  4. Must-have features (1 question)
  5. Generate One-Pager PRD format

平台分布

Local Agent

80.62%
按下载量换算106

安全审计

暂无安全审计结果可展示。

权限和风险

只读

该 Skill 主要提供规则、说明或参考内容,本身偏只读;真正读写文件、联网或执行命令仍取决于宿主 Agent 的任务。

安装前确认

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

继续浏览同类 Skills