# Send Persona Docs to your agent Hand the extracted package to your coding agent with a concrete install brief instead of figuring it out manually. ## Fast path - Download the package from Yavira. - Extract it into a folder your agent can access. - Paste one of the prompts below and point your agent at the extracted folder. ## Suggested prompts ### New install ```text I downloaded a skill package from Yavira. Read SKILL.md from the extracted folder and install it by following the included instructions. Then review README.md for any prerequisites, environment setup, or post-install checks. Tell me what you changed and call out any manual steps you could not complete. ``` ### Upgrade existing ```text I downloaded an updated skill package from Yavira. Read SKILL.md from the extracted folder, compare it with my current installation, and upgrade it while preserving any custom configuration unless the package docs explicitly say otherwise. Then review README.md for any prerequisites, environment setup, or post-install checks. Summarize what changed and any follow-up checks I should run. ``` ## Machine-readable fields ```json { "schemaVersion": "1.0", "item": { "slug": "persona-docs", "name": "Persona Docs", "source": "tencent", "type": "skill", "category": "效率提升", "sourceUrl": "https://clawhub.ai/wpank/persona-docs", "canonicalUrl": "https://clawhub.ai/wpank/persona-docs", "targetPlatform": "OpenClaw" }, "install": { "downloadUrl": "/downloads/persona-docs", "sourceDownloadUrl": "https://wry-manatee-359.convex.site/api/v1/download?slug=persona-docs", "sourcePlatform": "tencent", "targetPlatform": "OpenClaw", "packageFormat": "ZIP package", "primaryDoc": "SKILL.md", "includedAssets": [ "README.md", "SKILL.md", "references/template.md" ], "downloadMode": "redirect", "sourceHealth": { "source": "tencent", "slug": "persona-docs", "status": "healthy", "reason": "direct_download_ok", "recommendedAction": "download", "checkedAt": "2026-04-30T20:26:26.101Z", "expiresAt": "2026-05-07T20:26:26.101Z", "httpStatus": 200, "finalUrl": "https://wry-manatee-359.convex.site/api/v1/download?slug=persona-docs", "contentType": "application/zip", "probeMethod": "head", "details": { "probeUrl": "https://wry-manatee-359.convex.site/api/v1/download?slug=persona-docs", "contentDisposition": "attachment; filename=\"persona-docs-0.1.0.zip\"", "redirectLocation": null, "bodySnippet": null, "slug": "persona-docs" }, "scope": "item", "summary": "Item download looks usable.", "detail": "Yavira can redirect you to the upstream package for this item.", "primaryActionLabel": "Download for OpenClaw", "primaryActionHref": "/downloads/persona-docs" }, "validation": { "installChecklist": [ "Use the Yavira download entry.", "Review SKILL.md after the package is downloaded.", "Confirm the extracted package contains the expected setup assets." ], "postInstallChecks": [ "Confirm the extracted package includes the expected docs or setup files.", "Validate the skill or prompts are available in your target agent workspace.", "Capture any manual follow-up steps the agent could not complete." ] } }, "links": { "detailUrl": "https://openagent3.xyz/skills/persona-docs", "downloadUrl": "https://openagent3.xyz/downloads/persona-docs", "agentUrl": "https://openagent3.xyz/skills/persona-docs/agent", "manifestUrl": "https://openagent3.xyz/skills/persona-docs/agent.json", "briefUrl": "https://openagent3.xyz/skills/persona-docs/agent.md" } } ``` ## Documentation ### 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. ### 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 Analyze the codebase — look for existing documentation, README, landing pages, or marketing copy that hints at the target audience 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?" Start minimal — a few sentences per section is better than nothing Read the template — see references/template.md for the full structure Iterate — revisit and expand as you learn more about actual users ### 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: FeatureWhen EncounteredUser Need at That Moment[Feature 1][Journey stage][What they're trying to do][Feature 2][Journey stage][What they're trying to do] ### Multi-Persona Products If your product serves multiple distinct user types: Identify the primary persona first — who must you serve to survive? Document secondary personas separately — one file per persona Note conflicts — where persona needs clash, document the tradeoff 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 NEVER skip personas for a new product — building without knowing your user is guessing, and guessing is expensive NEVER describe users as demographics alone — "25-34 male" tells you nothing about what they need; describe behaviors and goals NEVER create personas in isolation — involve the team; one person's assumptions become the whole product's blind spots NEVER treat personas as permanent — users change, markets shift; review personas quarterly NEVER create more than 3 personas initially — if you try to serve everyone, you serve no one; start with your primary user NEVER write aspirational personas — document who actually uses your product, not who you wish did ## Trust - Source: tencent - Verification: Indexed source record - Publisher: wpank - Version: 0.1.0 ## Source health - Status: healthy - Item download looks usable. - Yavira can redirect you to the upstream package for this item. - Health scope: item - Reason: direct_download_ok - Checked at: 2026-04-30T20:26:26.101Z - Expires at: 2026-05-07T20:26:26.101Z - Recommended action: Download for OpenClaw ## Links - [Detail page](https://openagent3.xyz/skills/persona-docs) - [Send to Agent page](https://openagent3.xyz/skills/persona-docs/agent) - [JSON manifest](https://openagent3.xyz/skills/persona-docs/agent.json) - [Markdown brief](https://openagent3.xyz/skills/persona-docs/agent.md) - [Download page](https://openagent3.xyz/downloads/persona-docs)