什么是 Persona Docs？

Persona Docs 是一项战略技能，旨在通过定义产品的受众及其交互方式，为产品驱动型开发奠定坚实基础。通过与 Openclaw Skills 集成，该工具可确保每一项功能决策、设计选择和优先级排序都建立在对目标受众、其技术背景和特定痛点的深刻理解之上。它将模糊的假设转化为可落地的文档，并随代码库同步演进。

该技能专注于创建超越简单人口统计数据的以用户为中心的文档，深入探讨行为、目标和发现路径。无论您是发布新产品还是调整现有产品，Persona Docs 都能提供必要的框架来统一团队思想，并通过消除猜测来降低开发成本。

下载入口:https://github.com/openclaw/skills/tree/main/skills/wpank/persona-docs

安装与下载

1. ClawHub CLI

从源直接安装技能的最快方式。

2. 手动安装

将技能文件夹复制到以下位置之一

优先级：工作区 > 本地 > 内置

3. 提示词安装

将此提示词复制到 OpenClaw 即可自动安装。

Persona Docs 应用场景

• 项目初期启动，在编写代码前定义目标受众。
• 在转向新的用户群或市场时记录战略转变。
• 解决团队在产品方向和主要用户身份方面的分歧。
• 根据实际用户需求和记录的行为验证主要功能计划。
• 通过明确目标用户及其背景，简化新团队成员的入职流程。

1. 分析现有代码库、README、落地页和营销文案，以识别目标受众线索。
2. 向开发人员提出澄清性问题，以定义主要用户、其核心问题及技术水平。
3. 基于标准化的画像模板初始化最小化文档结构，以确保一致性。
4. 将信息整合为详细的用户概况、发现路径和入职流程。
5. 随着团队通过研究和反馈深入了解实际用户行为，对文档进行迭代。

Persona Docs 配置指南

使用以下命令安装此技能：

npx clawhub@latest install persona-docs

Persona Docs 数据架构与分类体系

该技能在项目仓库中组织文档，以确保其作为随产品演进的动态文档存在。

name: persona-docs
model: reasoning
version: 1.0.0
description: >
  Create persona documentation for a product or codebase. Use when asked to create persona docs,
  document target users, define user journeys, document onboarding flows, or when starting a new
  product and needing to define its audience. Persona docs should be the first documentation
  created for any product.
tags: [personas, user-research, product, documentation, onboarding, user-journey]

Persona Docs

Create user-centered documentation that defines who a product is for and how they interact with it. Persona docs establish the foundation for product-driven development — every feature decision, design choice, and prioritization call flows from understanding your users.

Installation

OpenClaw / Moltbot / Clawbot

npx clawhub@latest install persona-docs

When to Create

Persona docs should be the first thing fleshed out for any product. Even minimal documentation about who uses the product helps direct development and design decisions.

• Project inception — before writing code, define who you're building for
• Pivoting to a new audience — document the shift so the team aligns
• Team lacks clarity on target users — when people disagree on "who is this for?"
• Before major feature planning — validate that planned features serve actual users
• New team member onboarding — give them context on who they're building for

Process

1. Analyze the codebase — look for existing documentation, README, landing pages, or marketing copy that hints at the target audience
2. Ask clarifying questions if the target user isn't clear:
   • "Who is the primary user of this product?"
   • "What problem does this solve for them?"
   • "How would they discover this product?"
   • "What's the first thing they'd do after finding it?"
3. Start minimal — a few sentences per section is better than nothing
4. Read the template — see references/template.md for the full structure
5. Iterate — revisit and expand as you learn more about actual users

Core Components

1. Target User Profile

Who they are, their background, their context. Be specific enough to be useful.

Good: "Backend engineers at mid-size SaaS companies who debug production issues under time pressure, typically 3-8 years of experience, comfortable with command-line tools."

Too vague: "Developers."

Include:

• Role, job title, or archetype
• Technical level and relevant skills
• Industry or domain context
• When and where they'd use this product
• Team size and organizational context

2. User Needs and Pain Points

The problems this product solves. What frustrations or gaps exist in their current workflow?

Structure as:

• Primary pain point — the single biggest problem you solve
• Secondary pain points — additional problems you address
• Current workarounds — what they do today without your product
• Why existing solutions fail — what alternatives exist and why they're insufficient

3. Discovery Path

How they find the product. This informs marketing, positioning, and first-impression design.

• Search — what queries lead them here?
• Referral — word of mouth, colleague recommendation?
• Content — blog posts, tutorials, conference talks?
• Marketplace — app store, plugin directory, package registry?
• The hook — what makes them click "sign up" or "download"?

4. Onboarding Flow

The simplest possible path from "I found this" to "I'm getting value."

Define:

• First encounter — landing page, app store listing, GitHub README
• Registration/Login — minimum viable auth (email-only? OAuth? no account?)
• Time to value — how quickly can they experience the core benefit?
• First success moment — the specific action that makes them think "this is useful"
• Friction points — where do users drop off, and how do you minimize that?

Example flow:

User lands on homepage → clicks "Try it" → pastes their data → sees result in <30 seconds → decides to create account

5. User Journey Map

Key touchpoints and interactions across the user lifecycle.

New User (Day 1):

• Discovers product via [channel]
• Takes [first action]
• Achieves [first success]

Returning User (Week 1):

• Key repeated action they perform
• Features they explore
• Integrations or customizations they set up

Power User (Month 1+):

• Advanced features they rely on
• Workflows they've established
• How they'd describe the product to others

6. Feature Touchpoints

Map where users encounter key features in their journey:

Multi-Persona Products

If your product serves multiple distinct user types:

1. Identify the primary persona first — who must you serve to survive?
2. Document secondary personas separately — one file per persona
3. Note conflicts — where persona needs clash, document the tradeoff
4. Prioritize ruthlessly — you can't optimize for everyone simultaneously

Output Location

Place persona docs at:

• docs/PERSONA.md — single file for simple products
• docs/personas/ — directory for multiple personas

Keep it in the repo so it evolves with the product.

Quality Criteria

A good persona doc should:

• Be specific enough that two team members would build the same feature from it
• Include evidence — data, quotes, or observations, not just assumptions
• Be actionable — reading it should change how you build
• Be maintained — outdated personas are worse than none
• Be honest — don't describe aspirational users; describe actual users

NEVER Do

1. NEVER skip personas for a new product — building without knowing your user is guessing, and guessing is expensive
2. NEVER describe users as demographics alone — "25-34 male" tells you nothing about what they need; describe behaviors and goals
3. NEVER create personas in isolation — involve the team; one person's assumptions become the whole product's blind spots
4. NEVER treat personas as permanent — users change, markets shift; review personas quarterly
5. NEVER create more than 3 personas initially — if you try to serve everyone, you serve no one; start with your primary user
6. NEVER write aspirational personas — document who actually uses your product, not who you wish did