Simple Management of Product Documents

---

name: simple-product-doc-manager description: | Simple Management of Product Documents - A structured workflow for managing product documentation in Feishu (Lark). Use this skill when: - Creating a new project knowledge base in Feishu - Setting up standardized document structure for product development - Managing product requirements documents with version control - Following the project's documentation workflow (requirements → implementation → archival) - Setting up Feishu API integration for automated document management This skill provides a complete document management system including: requirements thinking docs, project/code documentation, configuration records, and versioned product requirement documents.

---

Simple Product Doc Manager | 产品文档管理器

> A structured workflow for managing product documentation in Feishu with clear lifecycle management and version control.

📋 Document Structure

When setting up a new project, create this structure in Feishu:

项目知识库/Project Knowledge Base
├── 📄 需求思考/Requirements Thinking
│   └── (Ongoing) Product insights, user pain points, competitive analysis
├── 📄 项目地址和代码逻辑记录/Project & Code Logic
│   └── (Ongoing) Architecture, key functions, database schemas
├── 📄 配置信息记录/Configuration Records
│   └── (Ongoing) API keys, env variables, deployment configs
└── 📁 产品需求文档/Product Requirements/
    ├── YYYY-M-D-requirement-name-v1.md  (Draft → Finalized)
    ├── YYYY-M-D-requirement-name-v2.md  (New version for iterations)
    └── ...

🔄 Document Lifecycle

Requirements Document States

| State | Description | Actions Allowed | |-------|-------------|-----------------| | 撰写中/Drafting | Requirements being written or in development | Edit, update, refine | | 已定型/Finalized | Code implemented and approved by user | Read-only, archived |

State Transition Rules

1. New Requirement → Create document with "Drafting" status 2. Development → Continuously update document 3. Code Complete → User reviews and approves 4. Approved → Status changes to "Finalized", document locked 5. New Iteration → Create new version document (v2, v3, etc.)

📝 Naming Convention

Requirements Documents

Format: {YYYY}-{M}-{D}-{requirement-name}-v{version}

Examples:

2026-3-26-mvp-full-requirements-v1

2026-3-28-user-login-feature-v1

2026-4-5-user-login-feature-v2 (iteration)

Rules:

Use actual date when document is created

Use lowercase for requirement names

Use hyphens as separators

Increment version for same requirement iterations

🚀 Workflow

1. Project Setup

Create the knowledge base with initial structure:

{
  "action": "create_knowledge_base",
  "name": "Project Name Knowledge Base"
}

2. Create Core Documents

Create the three ongoing documents:

Requirements Thinking

Project & Code Logic Records

Configuration Records

3. Requirements Workflow

New Idea → Create Requirements Doc (Drafting)
                ↓
        Write & Refine Requirements
                ↓
        Develop Code (sync to Code Logic doc)
                ↓
        User Review & Approval
                ↓
    ┌───────────────────────┐
    ↓                       ↓
Approved → Finalize    Changes Needed → Update Doc
    ↓                       ↓
Locked (Read-only)    Continue Development
    ↓
New Iteration → Create v2

📚 Reference Materials

references/workflow-examples.md - Concrete examples

references/feishu-api-setup.md - Complete Feishu API configuration guide

🔧 Best Practices

1. Always use write/append for Markdown - These actions auto-render formatting 2. Never use update_block for Markdown - It stores plain text only 3. Keep Requirements Thinking updated - Capture insights as they come 4. Document code logic immediately - Don't wait until after implementation 5. Version clearly - When in doubt, create a new version rather than overwrite