---
name: document-feature
description: Reverse-engineers a specific feature from existing code and updates its Notion entry with full detail. Equivalent to /refine-feature but starting from code. Supports --all flag to process all features in `Documentado parcial` state. Use after /document-project.
metadata:
  category: Feature Definition
---

# Skill: Document Feature

Takes a feature from the existing project, reads the associated code, infers what it does and how it's built, and updates the entry in the Notion features database with the detail. Status changes from `Documentado parcial` to `Documentado`.

## When to Use

- After `/document-project`, to detail each screen
- When you want to document a specific feature: `/document-feature [name]`
- With `--all` to go through all features in `Documentado parcial` status at once

## Constraints

- **Read-only** on `src/`. Never modifies code.
- If the Notion page does not exist, stop and tell the user to run `/document-project` first.

## Steps

### 0. Check Prerequisites

Verify that the project's Notion page exists. If the user hasn't provided it in the conversation, ask before proceeding:

> "Do you have the link to the project's Notion page? If you haven't created it yet, use `/document-project` first."

### 1. Read the feature from Notion database (delegate to haiku)

```
Agent({
  model: "haiku",
  prompt: `
    Search the Features database on the page {notionPageUrl} for the record with Name = "{featureName}" (or Name containing "{featureName}").

    Return:
    - Exact Name
    - Module
    - Screen
    - Current Status
    - Existing Description
    - Existing Criteria (if any)

    If no matching record exists, indicate clearly.
  `
})
```

If the record does not exist, notify the user and suggest they add the feature to the database manually or run `/document-project` to regenerate the list.

### 2. Read the associated code (delegate to haiku)

With the feature information (name, screen, module), search for relevant files:

```
Agent({
  model: "haiku",
  prompt: `
    Search src/ for files related to the feature "{featureName}" of the screen "{screenName}".

    Search by:
    - File or folder name matching the screen or feature name
    - Routes in the router pointing to that screen
    - Components imported in that screen

    For each relevant file found, read its content and extract:
    1. What it renders (component structure, layout)
    2. Which @material-hu components it uses (name + import path)
    3. What data it consumes (types, interfaces, visible fields)
    4. Custom hooks or library hooks used (react-query, react-hook-form, etc.)
    5. Validation schemas (Zod, Yup, etc.)
    6. Services or API calls (URLs, methods)
    7. States handled (loading, error, empty, etc.)

    Return everything structured by file.
  `
})
```

### 3. Infer and build the detail (run directly — Sonnet)

With the code reading, build the feature detail:

**Components table:**

| Section | Component | Import path | Key prop | Value / Source |
|---|---|---|---|---|

- List only `@material-hu` or composed-components. Don't include HTML primitives.
- Import path: the exact import path found in the code.

**Data structure table:**

| Field | Type | Visible in UI | Source |
|---|---|---|---|

- Type: TypeScript type inferred from code (`string`, `number`, `boolean`, date, enum, etc.)
- Source: service or endpoint name if inferrable; `user input` for form fields.

**Inferred validation criteria:**

Propose 2–4 criteria in plain English based on what the code does:
- ✅ "When opening the screen, the table is visible with records loaded"
- ✅ "The form cannot be submitted if the name field is empty"
- ❌ "The component renders correctly" ← too technical

### 4. Short interview for what cannot be inferred

Present what was inferred and ask only what's missing:

> "I read the code for **[feature name]** and here's what I understand:
>
> [3–5 line summary of what the feature does]
>
> To complete the documentation I need to know:
> - **What is the main intent of this screen?** What problem does it solve for the user?
> - **Are there known edge cases** that don't show up in the code? (e.g., special error cases, implicit business logic)
> - **Is anything I inferred wrong?** [point out any specific code uncertainties]"

Ask the questions one at a time if the answers seem to need elaboration.

### 5. Update the entry in Notion (delegate to haiku)

```
Agent({
  model: "haiku",
  prompt: `
    In the Features database on the Notion page {notionPageUrl}, update the record "{featureName}":

    Properties:
    - Estado: "Documentado"
    - Description: "{updated description}"
    - Criteria: "{validation criteria, one per line}"

    Record internal page — replace the content with:

    ## Components
    {components table}

    ## Data structure
    {data structure table if applicable}

    ## Implementation notes
    {observations about the code: patterns used, relevant logic, visible technical debt}

    ## Intent and context
    {what the user explained that doesn't show up in the code}
  `
})
```

Confirm with the user:
> I updated the documentation for **[feature name]** in Notion. Status: `Documentado`. [link to entry]

### 6. Flag --all: go through all features in `Documentado parcial`

If the user ran `/document-feature --all`:

1. Read all features with status `Documentado parcial` from the database (delegate to haiku).
2. Present the list to the user and ask for confirmation:
   > "I found [N] features in `Documentado parcial`:
   > [numbered list]
   > Should I document them all in this order?"
3. Wait for explicit confirmation.
4. Run steps 2–5 for each feature in order, showing progress:
   > "[2/N] Documenting: [feature name]…"
5. When done, report a summary:
   > "Done. I documented [N] features. They're all now in `Documentado` status in Notion."

⛔ Don't start the loop without user confirmation.
