/create-area

name: create-area
description: Use when starting a brand-new WORK AREA that groups several projects of the same kind (web, research, blog, video, apps…) — before it has any Lore, contract or project registry of its own. Trigger on "create a work area for X", "I want to start working on a domain with Lore", or a shared mold, starter or scaffold for future projects ("un molde común", "mother folder whose method every future project inherits"). Operating scattered criteria in place, without a new container, is transmute-lore, not this skill.

create-area — Start a new work 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.

You are writing the same rule into a third repository. Not copying it — rewriting it, slightly differently each time, because you half-remember how you phrased it last time. In six months those three versions will disagree and none of them will be marked as the wrong one.

That is the problem an area solves. This skill creates the **mother folder** of a domain (web, research, blog, video, apps…) with its own **body of criteria** (area Lore) that its projects inherit. It is the "mold of molds": `create-project` creates projects INSIDE an area; `create-area` creates the area.

> **Startup golden rule:** the Lore's content is BORN from a brainstorm, not from a template > filled in blind. The template gives the *shape*; the brainstorm gives the *content*.

> **Language rule:** write EVERYTHING the skill generates — content AND artifact filenames — in the > **user's language** (the language they speak during the brainstorm), NOT the language this skill > is written in. The names used throughout this skill (`identidad.md`, `principios.md`, `FASES.md`, > `proyectos/`) are the Spanish canonical forms: localize them (e.g. English → `identity.md`, > `principles.md`, `PHASES.md`, `projects/`). Fixed in every language: the selected contract name > (`CLAUDE.md` or `AGENTS.md`), `lore/`, > `index.md`, `golden-paths.md`, `_starter/`, the `<!-- lore:always-on -->` marker pair (literal, never localized — localizing it breaks idempotent stamping silently). English terms of general technical use (workflow, > stack, commit, scaffold, starter…) stay in English regardless.

Area model (federated + hybrid)

• The area is a **light** folder: one instruction contract + `FASES.md` + `lore/` + `proyectos/` + `_starter/`.
• The area carries its own **project scaffold** in `_starter/` — the templates (`{{CONTRACT_FILE}}.template.md`,

`FASES.md`, and `golden-paths.template.md` when the domain warrants it) **tuned to this area's domain**, plus any base code scaffold (e.g. a Next.js app for a web area). `create-project` stamps new projects from `{area}/_starter/`, so each area's projects are born in that area's shape.

• **New** projects are born inside `proyectos/` (via `create-project`), inheriting the area Lore.
• **Existing** projects are **ADOPTED by registration** in `FASES.md` (with their path), without

moving them or touching their git.

• **This skill does NOT adopt projects**: it only creates the area clean. Adopting an existing

project is a later manual step (add its row to `FASES.md`).

• The area Lore distills the domain's **cross-cutting method and standard**, NOT one concrete

project's theory. A project consumes and feeds that standard; its own theory lives in the project's `lore/`.

Procedure (step by step)

1. Identity brainstorm (threshold)

**Create no file or folder before the design is approved.** Invoke Lore Plugin's own `brainstorming-lore` skill (`lore:brainstorming-lore` where skills are namespaced). Ask **one thing at a time** and derive the tokens:

| Token | Where it comes from | |---|---| | `{{AREA_SLUG}}` | area name in kebab-case (e.g. `desarrollo-web`) | | `{{AREA_TITLE}}` | readable name (e.g. "Desarrollo Web") | | `{{PATH}}` | mother path; default `{{ROOT}}/{{AREA_SLUG}}`, where `{{ROOT}}` is the user's own root of areas — ask for it, never assume one | | `{{CONTRACT_FILE}}` | the user's primary host: Claude Code → `CLAUDE.md`; Codex → `AGENTS.md` | | `{{PURPOSE}}` | what does the area produce and for whom? → `identidad.md` | | `{{NORTH}}` | quality standard: what is every deliverable judged against? → `identidad.md` | | `{{ANTI_SCOPE}}` | what the area is NOT / what practice it rejects → `identidad.md` | | `{{REGISTRO}}` | how technical the kit speaks here: `tecnico` / `equilibrado` (default) / `llano` → `identidad.md`. **Inferred from how the user wrote during the brainstorm, never asked, and applied silently.** Mention it only if the user asks about tone or a correction is needed. It calibrates how much ground surrounds a rule and **never the rules themselves** — a threshold stays a threshold. It is a declared preference, not criteria: no confidence marker, never promoted | | `{{PRINCIPLES}}` | invariant laws of the method (may inherit from a prior corpus) → `principios.md` | | `{{MODULES}}` | initial thematic modules (may be 0; created when the first friction appears) |

> **If `create-bot` sent you here, the area is `bots` and its domain is *the user's bots* — never the > domain of any one of them.** There is **one** `bots` area, and every bot is a project inside it. A > second area named after the bot being requested is the failure `create-bot` documents as *«why it > must not be an area»*, arriving through this skill instead of being caught by that one. Do not > brainstorm an identity out of the bot's purpose: that purpose belongs to the bot, and it gets > written when control returns.

**If the user already has material about this domain — source documents, or a pile of free notes they have been writing in any app — read it before proposing anything.** If they ask to mine or save that inbox rather than us