# Actors Extractor — Documentation Preparation Prompt

Use this file as **complete instructions** for one work session (or more if the document is very large). When the user sends a message stating they are activating the **actors extraction prompt**, or attaches/refers to this file, execute the steps **in order** without skipping any step.

---

## Goal

From a single **master analysis file** at the documentation root, produce a consistent folder layout under `docs/actors/`, such that each actor has its own **`project_analysis.md`** containing only the analysis text that belongs to that actor.

---

## Inputs and paths (conventions)

| Item | Default path | Notes |
|------|----------------|--------|
| Master analysis file | `docs/project_analysis.md` | Must live **directly under `docs`** (not inside `actors`). If the project uses another name for the master file (e.g. `output.md`), the user states it in the message—then use the path they specify. |
| Output actors folder | `docs/actors/` | Create it if it does not exist. |
| Actor-splitting rules | Relevant `.cursor/rules/*.mdc` files | Read and follow them; at minimum any rule that **does not treat Guest/anonymous browsing as a separate actor**, if present. |

---

## Rules to respect before extracting actor names

1. **Do not create an actor named Guest / visitor / anonymous** as a standalone folder unless the user’s message or the document **explicitly** requires that role as a separate system actor.
2. **Unauthenticated** or **browse-without-login** flows are merged under the **primary role** described in the document (e.g. end customer, buyer).
3. **Folder names:** use **the same role naming as in the document** (Arabic if the analysis is Arabic), with filesystem-safe names (avoid illegal characters; replace spaces with `_` if needed without losing meaning).
4. **Do not assume a canned actor list** from a previous project; derive actors **only from the current master file**.

---

## Execution steps

### Step 1 — Read rules and the master file

- Open any Cursor rule relevant to actor splitting (e.g. `actors-and-docs-folders.mdc` or the project equivalent).
- Confirm the path to the master analysis file (`docs/project_analysis.md` or as specified by the user).
- If the file is missing or empty: stop and tell the user what must be provided.

### Step 2 — Extract the actor list

- Scan the document for:
  - Explicit sections (e.g. supported platforms, dashboards, “project functions” per party, headings like “X platform”, “features of … dashboard”).
  - Repeated party names in major headings.
- Produce a **deduplicated** list of product-level actors (illustrative examples only: client, courier, service provider, admin—**use whatever the document actually says**).
- Report the **extracted actor list** to the user in a short message (one line per actor) for review.

### Step 3 — Create the `docs/actors/<actor>/` layout

- Create the folder: `docs/actors/`
- For each actor in the list: create `docs/actors/<actor_name>/` (no duplicates).

### Step 4 — Extract analysis text per actor into `project_analysis.md`

For each actor:

1. **Define boundaries** in the master file:
   - Find the first line that clearly opens that actor’s section.
   - Find the last line before the next actor’s section begins, or before a global section that is not exclusive to this actor.
2. **One actor may have more than one non-contiguous segment** (e.g. a long narrative section and later a separate “functional properties” table). In that case:
   - Place **all segments** in the same `docs/actors/<actor>/project_analysis.md`.
   - Add clear subheadings inside the file, e.g. “Part 1 — …”, “Part 2 — …”, and cite **approximate source line ranges** when possible.
3. **Standard file header** (top of each per-actor `project_analysis.md`):
   - Title: `# Project analysis — Actor: <name>`
   - A short block stating: **source** (path to master file), **extraction scope** (approximate line numbers in the source), **notes** if content overlaps or is shared with another actor.
4. **Do not accidentally copy** another actor’s sections (e.g. content that still belongs to the client up to “courier platform” must not be appended to the courier file—verify context).

### Step 5 — Quick validation

- Ensure each actor folder contains a non-empty **`project_analysis.md`**.
- Ensure the end of a file does not contain another actor’s section heading (e.g. a “courier platform” heading inside the client file).
- If practical, search for misplaced keywords (wrong actor at file tail).

### Step 6 — What to report to the user at the end

- Path to `docs/actors/`.
- List of folders created.
- If any boundaries in the source were ambiguous, state that in one or two sentences (keep it brief).

---

## Optional — Regeneration script

If the master file name is stable and section boundaries are known by line number, a small script under `scripts/` can regenerate outputs after updates. This is **not required**; the primary workflow is following the steps above precisely.

---

## One-line activation (copy-paste)

```text
Execute docs/agent/actors_extractor.md in full: the master file is docs/project_analysis.md (or specify another name). Create docs/actors/ and a project_analysis.md per actor, respecting the project’s actor-splitting rules.
```

---

## Short version (for a brief session)

1. Read actor rules in `.cursor/rules/`.
2. Extract actors from `docs/project_analysis.md`.
3. Create `docs/actors/<actor>/project_analysis.md` for each actor.
4. Fill each file with the correct segments from the master file, plus source path and scope in the header.

---

*Template note: wording is portable across projects—adjust file names only if the project uses different conventions.*