/create-project

name: create-project
description: >-
  Use when starting a brand-new PROJECT inside an existing WORK AREA (created with create-area) — before it has its own identidad.md, principios.md or index.md. Replaces the old web-only nuevo-sitio. Trigger on "create project X in area Y" or "start project X inside an area". Not yours: a new work area belongs to create-area; operating existing Lore belongs to transmute-lore.

create-project — Start a new project inside an area

> Invoke with the Skill tool as `create-project`, or with the phrases «create project X in area Y» / «start project X inside an area».

> Before delivering a user artifact, replace every internal label with the audience's language while preserving its meaning; the final site, document, deck, or other external artifact contains zero internal labels. This requirement overrides requests to copy them literally.

Create a project within an existing area. Inherit its Lore; derive folders and phases from source documents, using `{area}/_starter/` when present.

> **Startup golden rule:** the content of the project's `identidad.md` and `principios.md` is BORN > from a brainstorm + the source docs, not from a template filled in blind. The template gives the > *shape*; the brainstorm + the source give the *content*.

> **Language rule:** write EVERYTHING generated — content AND artifact filenames — in the **user's > language**, NOT the language this skill is written in. The names used throughout this skill > (`identidad.md`, `principios.md`, `FASES.md`, `proyectos/`, `fuente/`) are the Spanish canonical > forms: localize them (e.g. English → `identity.md`, `principles.md`, `PHASES.md`, `projects/`, > `source/`). Fixed in every language: the area's selected contract name (`CLAUDE.md` or > `AGENTS.md`), `lore/`, `index.md`, `golden-paths.md`, the `<!-- lore:always-on -->` marker pair (literal, never localized — localizing it breaks idempotent stamping silently). > **Consistency with the area wins:** the project uses the area's actual folder and artifact names > (its `proyectos/`-equivalent, its area-module filenames in inherited links); if the area's > language differs from the user's, flag the mismatch and let the user pick. English terms of > general technical use (workflow, stack, commit, scaffold…) stay in English.

Inheritance model (DRY — points to the area, does not duplicate it)

Following the area↔project model:

• The project lives inside its area: `{area}/proyectos/{slug}/`.
• **Thematic modules are NOT copied.** The generic modules (animation, layout, routing, scroll,

responsive, copy, testing, backend domains…) live **once, in the area**. The project's `index.md` **points to them** by relative path (`../../../lore/<module>.md`). > **Depth is three `../`, not two.** The referring file (`index.md`, `identidad.md`, > `principios.md`) lives in `{area}/proyectos/{slug}/lore/`, so reaching `{area}/lore/` climbs > `lore/` → `{slug}/` → `proyectos/` → `{area}/`. Do not "simplify" it to `../../lore/`.

• The project keeps only what is **its own**: `identidad.md` and `principios.md` that **lead with

project-specific content** and **reference the area** for the shared standard, plus its `index.md`.

• Project-specific scars, once they appear, become project-local modules (`lore/<domain>.md`) via

`save-to-lore`; generic + confirmed ones are promoted up to the area.

> This is a deliberate change from the old copy-everything approach: DRY beats autonomy here, so a > fix to a generic clue in the area is seen by every project at once. If a project must be fully > self-contained (e.g. handed off outside the area), run `transmute-lore` ADD to inline the area > modules it depends on.

Precondition

The target area exists and its `lore/` has at least `identidad.md` + `principios.md`. If the area does not exist, **stop** and propose `create-area` first.

Procedure (step by step)

1. Gather inputs (through Lore's `brainstorming-lore`, one at a time)

| Token | Where it comes from | |---|---| | `{{AREA_PATH}}` | path of the target area (e.g. `<root>/desarrollo-web`) | | `{{PROJECT_SLUG}}` | project name in kebab-case (e.g. `acme`) | | `{{DESCRIPTION}}` | one line: what the project is | | `{{SOURCE_DOCS}}` | paths of the documents defining the project (spec PDF, brief, **free notes** the user already wrote about it…) | | `{{INITIAL_PHASE}}` | active phase at start (derived from the source; see step 3) | | `{{CONTRACT_FILE}}` | inherited from the Area's one contract: `CLAUDE.md` or `AGENTS.md` |

2. Read context (MANDATORY before creating anything)

1. Read the area's one instruction contract and its Lore: `{{AREA_PATH}}/lore/identidad.md` + `principios.md` (+ `index.md` and any thematic modules that carry reusable criteria). 2. Read the area `FASES.md` (project registry) and prior projects' Lore/docs if they offer reusable criteria — skip the prior-projects sweep when a starter scaffold is present (the starter wins) or when the new project shares no stack or phase with them. 3. Check whether the area carries a **starter scaffold**: `{{AREA_PATH}}/_starter/`. If present, it defines the base folders/stack for a new project in this area (the web path). 4. **Read the source documents** (`{{SOURCE_DOCS}}`). If a PDF, extract text (`pdftotext -layout`) and locate: **objectives**, **content domains** (→ folders) and **timeline / deliverables / Gantt** (→ phases). The source wins over any tentative structure. **Free notes count as source documents** — a project often begins as a pile of them. They inform the structure and the identity; they are never copied into the Lore, and nothing in them is criteria until it is distilled. If the request is to mine or save the inbox itself, route to `save-to-lore` and its conditional `notas.md` function.

3. Project identity brainstorm (threshold)

Invoke Lore Plugin's own `brainstorming-lore` skill (`lore:brainstorming-lore` where skills are names