---
name: document-project
description: Reverse-engineers an existing React project to create a Notion page with project overview and a features database. Equivalent to /plan-project but starting from code instead of a blank slate. Use when the user has an existing project and wants to document it.
metadata:
  category: Project Creation
---

# Skill: Document Project

Scans the code of an existing project, detects screens and features, validates them with the user, and creates the Notion page + features database equivalent to what `/plan-project` generates. Features start in `Documentado parcial` state — completed with `/document-feature`.

## When to Use

- When the user has an existing project and wants to document it in Notion
- As a first step before running `/document-feature` to detail each feature
- When someone joins an ongoing project and needs a quick overview

## Constraints

- **Read-only** on `src/`. Never modifies code.
- If `src/` does not exist, stop and tell the user to run the skill from the project root.

## Steps

### 1. Scan the project (delegate to haiku)

Launch a sub-agent to explore the code structure:

```
Agent({
  model: "haiku",
  prompt: `
    Read the project structure in src/.
    Identify:
    1. Defined routes (react-router, route files, pages/ or screens/ folders)
    2. Top-level components (pages, screens, views)
    3. Data services or hooks (files in services/, hooks/, api/)
    4. Main types (files in types/)
    5. Inferrable stack (package.json, vite.config, etc.)

    Return:
    - List of detected screens (name + route if applicable + source file)
    - List of identified services/hooks
    - Inferred stack (key libraries: router, forms, query, UI)
    - Any notable patterns (multi-tenant, roles, feature flags)
  `
})
```

### 2. Short interview to fill gaps

With the scan list in hand, ask the user what the code cannot reveal:

> "I scanned the project and detected these screens:
> [numbered list of screens with one-line description]
>
> Before documenting it, I need to understand three things:
> 1. **What is the product's goal?** What problem does it solve and for whom?
> 2. **Who are the main users?** (admin, employee, manager, customer…)
> 3. **Is there anything relevant in the stack that doesn't show up in the code?** (integration with an external service, business logic that comes from the backend, etc.)"

Ask one question at a time if the answers seem to need elaboration. Don't proceed until you have answers for all three.

### 3. Propose screens/features list for confirmation

Combine the scan with interview answers and present the full list:

> "Based on the code and what you told me, these are the screens/features I see:
>
> **[Module A]**
> 1. **[Screen 1]** — [one-line description]
> 2. **[Screen 2]** — [one-line description]
>
> **[Module B]**
> 3. **[Screen 3]** — [one-line description]
>
> Are they all there? Is anything missing, extra, or should I rename something?"

⛔ Do not create anything in Notion until the user confirms the list.

### 4. Create the Notion page and features database

Ask the user for the Notion link where to create the page, or use the location set by the team.

Create the page following the structure from `TEMPLATE.md` of `plan-project`:

- **Title:** `[Project Name] — Plan`
- **Goal:** what the user described in the interview
- **Status:** `En progreso` (the project already exists)
- **Technical Context:** inferred stack from the scan + what the user added

Then create the **Features database** embedded in the Features section with these properties:

| Property | Type | Options |
|---|---|---|
| Name | Title | — |
| Module | Select | *(added as documenting)* |
| Screen | Select | *(added as documenting)* |
| Estado | Select | `Documentado parcial`, `Documentado`, `En progreso`, `✅ Listo` |
| Description | Text | — |
| Order | Number | — |
| Criteria | Text | — |
| Commit | Text | — |

Create one record per confirmed screen with status `Documentado parcial`. Delegate to haiku:

```
Agent({
  model: "haiku",
  prompt: `
    On the Notion page {notionPageUrl}, create a record in the Features database for each screen from this list:

    {list of confirmed screens}

    For each record:
    - Name: "{screen name}"
    - Module: "{corresponding module}"
    - Screen: "{screen name}"
    - Estado: "Documentado parcial"
    - Description: "{one-line description}"
    - Order: {number}
  `
})
```

Share the link with the user:
> I created the project page here: [link]. It has the overview and the [N] detected screens, all in `Documentado parcial` status. The next step is `/document-feature` to detail each one.

### 5. Size checkpoint

Count the detected features and decide the next step:

**If there are ≤ 3 features:**
> "That's [N] screens total. Do you want me to document each one now, in one go? I can run `/document-feature` for each one without you asking again."

Wait for explicit confirmation. If the user says yes, run `/document-feature` for each feature in order. If no, tell them the command.

**If there are > 3 features:**
> "That's [N] screens. You can document them one at a time with `/document-feature [name]`, or all the ones in `Documentado parcial` status at once with `/document-feature --all`. I recommend starting with the most critical ones."

⛔ Never auto-execute `/document-feature` without explicit user confirmation.
