---
description: Workflow rules for building sandbox projects with non-technical users. Covers planning in Notion, visual checkpoints, incremental commits, and session continuity. Always apply when working in a humand-create-app project.
alwaysApply: true
---

# Sandbox Workflow Rules

These rules define how to collaborate with the user throughout a sandbox project — from planning to delivery.

---

## 1. Plan before building

Before writing any code, generate the full project plan and publish it to Notion using the sandbox project template.

The mandatory order is:

```
   /bootstrap-react-project                   ← scaffold the project
    → /plan-project                              ← Notion page + flows (conceptual only, no preflight)
    → per screen: /refine-feature                ← preflight runs HERE (scaffold must exist)
    → per feature: /build-feature
```

Steps:
1. Ask the user to describe what they want to build (screens, flows, goals)
2. Run `/bootstrap-react-project` to scaffold the project before planning
3. Propose a structured plan: list every screen, the order to build them, and what each one shows
4. Create the Notion page using the `/plan-project` skill and fill it with the proposed plan — no preflight needed here, this is conceptual planning only
5. Share the Notion link and ask the user to review it:
   > Before we start, I created a project plan here: [link]. Review it and let me know if anything is missing or if you'd like to change something. When you're ready, just say so and we'll get started.
6. Do not write any code until the user explicitly confirms the plan

---

## 2. Refine each screen before building

Before building any screen, run `/refine-feature` for that screen. This decomposes it into features and adds the detail work (components, data structure, validation criteria) that `/plan-project` left out.

⛔ Do NOT invoke `/build-feature` without a completed `/refine-feature` for that screen.

- `/refine-feature` is run once per screen, before the first `/build-feature` for that screen
- The output is a list of features in implementation order — each becomes one `/build-feature` invocation
- If the user wants to skip refinement for a trivial screen, confirm explicitly before proceeding

---

## 3. Build features exclusively through /build-feature

Never implement a feature by writing code directly. Always invoke the `/build-feature` skill — it enforces pre-flight, verification, visual checkpoint, commit, and Notion update.

If you are tempted to "just code it quickly", stop. Use the skill.

- One feature = one invocation of `/build-feature`
- After each feature, the skill will pause and ask the user to validate before continuing

---

## 4. Visual checkpoint after every feature

After completing each feature:

1. Tell the user exactly what changed and where to see it:
   > I added [feature name] to the [screen name] screen. You can find it in the left menu under "[Label]". Can you check it and let me know if it looks like what we planned?

2. Wait for confirmation before moving to the next feature
3. If something looks wrong, fix it before continuing — never accumulate visual debt

---

## 5. Commit after every confirmed feature

Once the user confirms a feature looks correct:

1. Run type check and lint silently:
   ```bash
   npx tsc --noEmit && bun run lint
   ```
2. If both pass, commit with a message the user can understand:
   ```bash
   git add .
   git commit -m "<User-facing description of what is now visible>"
   ```

Commit message rules:
- **In Spanish**
- **Describe what the user can now see**, not what changed in the code
- Use active past tense: "Pantalla de X lista", "Formulario de Y agregado", "Navegación actualizada con Z"

**Examples:**
- ✅ `Pantalla de lista de pedidos lista para revisar`
- ✅ `Formulario de creación de cliente agregado`
- ✅ `Dashboard con métricas de ventas del mes`
- ❌ `feat: add OrderList component`
- ❌ `refactor: update DashboardLayout sections`

---

## 6. Update the Notion plan after each commit

After committing, update the project's Notion page:
- Mark the completed screen as done
- Update the **Estado** field if all screens are complete
- Add any decisions or changes that came up during implementation to **Decisiones de diseño**

This keeps the Notion page as a live record of where the project stands.

---

## 7. Session continuity

When the user returns to an existing project after a break, always start fresh:

1. Read the current project state **before** clearing context:
   - Check `git log --oneline -10` to see recent commits
   - Check the Notion project page if available
2. Greet the user with a summary of the current state:
   > Your project has 3 completed screens: Order List, Create Order, and Dashboard. The last one we finished was "Dashboard with metrics". Should we continue with the order detail screen, or would you like to adjust something already built?
3. Ask the user to run `/clear` to continue with a clean context:
   > Before we continue, type `/clear` to start fresh. The summary above will help you pick up where we left off.

Never assume the user remembers where they left off. Never reconstruct session state on top of an existing long conversation — always reset first.