# Build Product Wiki

> Design and populate a product knowledge base that preserves context, decisions, and institutional knowledge. Use this skill when a team loses time to repeated questions, onboarding gaps, or forgotten decisions.

- Skill: `alexe-ev/build-product-wiki` (Agent Skill, multi-file: 5 files)
- Install (CLI): `npx skillmds@latest add alexe-ev/build-product-wiki`
- Raw SKILL.md: https://api.skillmd.com/api/skills/alexe-ev/build-product-wiki/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Research & Search
- Author: alexe-ev (https://skillmd.com/u/alexe-ev)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/alexe-ev/build-product-wiki

---


# Build Product Wiki

## Purpose
Help teams design a product knowledge base that is actually used — organized around how teams work, not how information is created, and maintained through team habits rather than individual effort.

## Skill type
Conceptual skill

## Use this skill when
- New team members take too long to ramp up due to missing documentation
- Decisions get relitigated because the rationale was never recorded
- The same questions keep getting answered in Slack rather than documented
- Tooling has changed but process documentation hasn't caught up

## Do not use this skill when
- The goal is tooling selection alone (tooling is a means — structure comes first)
- The goal is sprint or delivery documentation (use plan-delivery-collaboration)

## Required inputs
- Team type and size
- Primary use cases for documentation (onboarding, decisions, process, templates)

## Optional inputs
- Current documentation state and tools
- Onboarding pain points
- Most common repeated questions
- Documentation owners or maintainers

## Upstream context
Works best when:
- Operating cadence and key processes are defined
- Team norms are established

## Downstream handoff
Output can feed:
- align-cross-team-communication (wiki is a shared context artifact)
- design-planning-process (planning templates go in the wiki)

## Instructions
1. Define the purpose of the wiki: what decisions or work does it support?
2. Design the top-level structure around how teams navigate, not how information is created.
3. Define the core content types: process guides, decision logs, templates, onboarding tracks, reference material.
4. Define content ownership and update responsibilities per section.
5. Design a "freshness" system: how do team members know if content is current?
6. Define what goes in the wiki vs. in tickets, Slack, or other tools.
7. Plan for maintenance: what happens at each planning cycle to review and update?

## Output
Provide:
- Wiki purpose and primary use cases
- Top-level structure (navigation design)
- Content types and their locations
- Content ownership map
- Freshness system (review dates, owner tags)
- Tool boundary definition (wiki vs. tickets vs. Slack vs. docs)
- Maintenance plan

## Risks / caveats
- A wiki that isn't navigable will be ignored — structure for findability, not completeness
- Content without clear owners goes stale — assign every section
- Don't document everything — document what is repeatedly needed and not in people's heads