agentleFS
andresanemicandresanemic/lore-plugin/skills/create-project/SKILL.md

create-project

Skill7 starsChanged 3 months agoApache-2.0View on GitHub

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.

11 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use json-canvas, webapp-testing and 1 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • wangzhuofengSkill

    json-canvas

    Create and edit JSON Canvas files (.canvas) with nodes, edges, groups, and connections. Use when working with .canvas files, creating visual canvases, mind maps, flowcharts, or when the user mentions Canvas files in Obsidian.

    Also in 3 projects that use this

  • JetBrainsSkill

    webapp-testing

    Toolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser logs.

    Also in 3 projects that use this

  • GoogleSkill

    grill-me

    A relentless interview to sharpen a plan or design.

    Also in 3 projects that use this

The file

Show its rules and text

We split this skill into the rules it gives an agent

13 rules. 0 are common, 2 are distinctive, and 11 are very specific to this project.

  • 0

    Common

    Most of the 9 edited versions we read keep these.

  • 2

    Distinctive

    This author's own choices. Worth a look.

  • 11

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Create a project within an existing area.

    line 13
  2. Very specific:

    Read the area's one instruction contract and its Lore: {{AREA_PATH}}/lore/identidad.md + principios.md (+ index.md and any thematic modules …

    line 71
  3. Very specific:

    Read the area FASES.md (project registry) and prior projects' Lore/docs if they offer reusable criteria — skip the prior-projects sweep …

    line 74
  4. Very specific:

    Check whether the area carries a starter scaffold: {{AREA_PATH}}/_starter/.

    line 76
  5. Very specific:

    When primera-vez returns ofrece: true, offer the agreement and start with the why — what this project is for, in the person's own words and …

    line 116
  6. Very specific:

    Otherwise: create the work folders derived from the source docs, each with a .gitkeep.

    line 146
  7. Very specific:

    Write the project's lore/identidad.md:

    line 169
  8. Very specific:

    Write lore/index.md pointing to the area modules:

    line 200
  9. Distinctive:

    After either path, verify there is exactly one instruction contract and that its name matches the Area.

    line 234
  10. Very specific:

    Verify local index.md links resolve to present files, and the ../../../lore/<module>.md links resolve to files in the area.

    line 255
  11. Very specific:

    Verify the stamped contract meets the starter floor: one always-on block, four things, ≤ 25 lines.

    line 257
  12. Very specific:

    Verify exactly one of CLAUDE.md or AGENTS.md exists.

    line 265
  13. Distinctive:

    No data, figures or deliverables are invented: they are derived from the source.

    line 283

“Common” is measured: kept by at least 6 in 10 of the 9 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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)

TokenWhere 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 namespaced). With what you read, propose and get the user's approval for:

  • The project's specific identity (what it is, its own north, its anti-scope) — leads identidad.md, then a pointer to the area standard.
  • The project's specific principles (its own constraints) — lead principios.md, then a pointer to the area laws.
  • The folder schema derived from the source's domains (thematic, per-deliverable, or hybrid) — or the area starter's layout if {area}/_starter/ exists.
  • The phase map derived from the source's timeline/deliverables, and the initial active phase.

Apply brainstorming-lore's recognizable continuity contract: carry each approved decision into the accumulated project design and recap it at contextual milestones.

Create no file before the design is approved.

Then, at this same threshold, run the agreement — available here, never in the way. The person asking to create a project directly gets it built with the agreement offered:

node <ruta-del-kit>/skills/use-lore/scripts/acuerdo.mjs aviso --raiz "{{AREA_PATH}}" --desde <kit-version-anterior>
node <ruta-del-kit>/skills/use-lore/scripts/acuerdo.mjs primera-vez --raiz "{{AREA_PATH}}" --sesiones <n>

Say the aviso message once, in plain language, only when the command returns one — it names Vespi, what it can do, and the invitation to set limits. Showing it approves nothing. The commands need nothing on disk to answer: rastro: false in the aviso output means there was nowhere yet to note the notice was shown, so it may show again — the message still arrives.

When primera-vez returns ofrece: true, offer the agreement and start with the why — what this project is for, in the person's own words and yours — before the dials (intensidad sobria/cercana, ritmo despacio/normal/rapido) and their limits of use by model family and level. It binds only if the person accepts, and this skill continues without it, on the defaults. An area that already carries an approved agreement answers motivo: "ya-hay-acuerdo" and is not offered again. use-lore owns the agreement itself.

After resolving the optional agreement, hand the approved design to vespi: recommend an execution mode with reason, cost and alternative, based on area Pistas, agreement/defaults and observed callable roles. Preserve the person's choice; if pending, do not execute. Design approval does not choose the method or authorize publication. Record design/method in source/state; write spec/plan when needed; a master plan is optional.

One decision per message: design choice → design approval → optional agreement → execution choice. Require independent Advisor review before execution of the approved spec/plan. A callable read-only review role does not require writing authority; an unavailable writer is not an unavailable reviewer. Missing review blocks that execution; self-review cannot close an operation. Keep rejected work and corrections visible. Resolve inherited links from each document: the root contract uses ../../lore/, its lore/ files use ../../../lore/. Check each link.

4. Create the structure

DEST="{{AREA_PATH}}/proyectos/{{PROJECT_SLUG}}"
mkdir -p "$DEST/lore"
  • If the area has a starter ({{AREA_PATH}}/_starter/): instantiate it into $DEST (copy its versioned files; do not copy node_modules/build output/lockfiles so the stack resolves to its latest version). Then rename the project templates and adapt folders per the brainstorm:
    STARTER="{{AREA_PATH}}/_starter"
    cp -r "$STARTER/." "$DEST/"                          # templates + code scaffold (web/, …)
    for CONTRACT in CLAUDE AGENTS; do
      [ -f "$DEST/$CONTRACT.template.md" ] && mv "$DEST/$CONTRACT.template.md" "$DEST/$CONTRACT.md"
    done
    [ -f "$DEST/golden-paths.template.md" ] && mv "$DEST/golden-paths.template.md" "$DEST/golden-paths.md"
    # $DEST/FASES.md comes from the starter as-is; tokens are resolved in step 6.
  • Otherwise: create the work folders derived from the source docs, each with a .gitkeep.

Resulting structure (folder names come from step 2/3):

{{AREA_PATH}}\proyectos\{{PROJECT_SLUG}}\
  {{CONTRACT_FILE}}    → the one project contract (pointers to lore/)
  FASES.md             → state + phase map derived from the source
  lore\
    index.md           → project Lore map: points to area modules (../../../lore/<module>.md)
    identidad.md       → project identity + pointer to area identidad
    principios.md      → project laws + pointer to area principios
    (if the area profile is enabled, this index carries its pointer)
  {{thematic / per-deliverable folders, empty with .gitkeep}}
  fuente\              → original source document(s) + extracted text

5. Write the inherited-but-DRY Lore

The snippets below are shape, not literal text: render every heading, sentence AND localizable filename in the user's language. Relative-path depth stays as-is, but path segments use the area's actual (localized) names.

Write the project's lore/identidad.md:

# Identidad — {{PROJECT_TITLE}}

## Este proyecto
{{PROJECT_SPECIFIC_IDENTITY}}   # what it is, its own north, its anti-scope

## Estándar heredado del área
This project inherits the area's premium standard and quality floor.
Source of truth for the shared standard: [`../../../lore/identidad.md`](../../../lore/identidad.md).

registro: is inherited, not re-decided. A project takes the area's line and writes none of its own; only add registro: here when the user says this project should read differently from the rest of the area, and then it is inferred from how they said it — never asked. Everything about how the calibrator behaves is in use-lore.

Write the project's lore/principios.md:

# Principios — {{PROJECT_TITLE}}

## Leyes propias de este proyecto
{{PROJECT_SPECIFIC_PRINCIPLES}}

## Leyes heredadas del área
The area's invariant laws apply in full. Source of truth:
[`../../../lore/principios.md`](../../../lore/principios.md).

Write lore/index.md pointing to the area modules:

# Índice del Lore — {{PROJECT_TITLE}}

## Fundamentos (project)
- Identidad — this project + inherited standard · [identidad.md](identidad.md)
- Principios — this project's laws + inherited laws · [principios.md](principios.md)

## Módulos heredados del área (por ruta relativa)
- Professional criterion · [../../../lore/perfil-profesional.md](../../../lore/perfil-profesional.md) _(only if it exists)_
- animation · [../../../lore/animation.md](../../../lore/animation.md)
- layout · [../../../lore/layout.md](../../../lore/layout.md)
- (…the area modules this project relies on…)

## Módulos propios del proyecto
_(none yet — created by save-to-lore when a project-specific scar appears)_

Only list the area modules the project actually relies on. Project-specific clues get their own local module later, added by save-to-lore.

6. Write / resolve {{CONTRACT_FILE}} and FASES.md

  • If the area starter provided them (step 4 renamed the contract template and left FASES.md): do NOT rewrite from scratch — resolve their {{TOKENS}} with the project's name/description and the phase map derived from the source docs.
  • Otherwise, write them with Write:
    • {{CONTRACT_FILE}}: slimmed to pointers — where lore/ lives, that thematic modules are inherited from the area by relative path, and the area's actual base rules; never invent a web-only rule for a non-web project.
    • FASES.md: outside lore/, with the phase map derived from the source's timeline and the initial active phase.

After either path, verify there is exactly one instruction contract and that its name matches the Area. Do not create a second contract merely because another host might be used later.

Stamp the always-on block (project variant) in that contract — the pointer section wrapped in <!-- lore:always-on --> / <!-- /lore:always-on -->, pointing at this project's own layer and its mother area's, at its own FASES.md in one line, plus the signal to invoke instead of writing by hand. The area starter template already carries it; if the contract was written from scratch, add it. Rules, ceiling and the idempotency table are in use-lore — this happens inside the threshold this skill already has, and never as a second pass afterwards. If a block is already there and differs, report it and wait: a human edit inside the block is a decision.

Resolve every {{TOKEN}} with what was discussed; leave none unresolved.

7. Verify and report

grep -rn '{{[A-Z_]\+}}' "$DEST" && echo "UNRESOLVED TOKENS" || echo "OK no tokens"
# every local index link resolves; area links point outside the project:
  • Verify local index.md links resolve to present files, and the ../../../lore/<module>.md links resolve to files in the area.
  • Verify the stamped contract meets the starter floor: one always-on block, four things, ≤ 25 lines; FASES.md outside lore/; modules inherited by relative path, not copied; no HARD-GATE in present tense; no plugin wrap. If the area is bots, stop and hand back to create-bot — that skill owns the bot variant, and the stamped bot declares what it loaded in one short line (Spanish canonical form: Contrato, Lore y FASES cargados) — only after the opening hook confirms by staying silent; if the hook speaks, repair first. Where no hook runs, open the three bodies yourself, then declare what you opened. The line goes in the user's language; what is fixed is the meaning and the three bodies.
  • Verify exactly one of CLAUDE.md or AGENTS.md exists. For cross-host use, offer Codex's project_doc_fallback_filenames setting or, only with explicit approval, a minimal adapter.
  • Register the project in the area's FASES.md (row with path + status + internal phase).
  • Report the created structure and the next step (start the active phase; optionally git init).

Invariants

  • The project ALWAYS lives in {area}/proyectos/{slug}/. lore/ at its root; FASES.md outside lore/ (criteria persists, state advances).
  • Thematic modules and, if it exists, perfil-profesional.md are referenced from the area, not duplicated (DRY). Only identidad.md, principios.md and index.md are project-local Lore files at creation.
  • Read the source docs before fixing folders and phases. Structure and phase map come from the source, not a mold.
  • Project-specific identity/principles are BORN from the brainstorm, never from invented defaults.
  • Everything generated — content and artifact filenames — is in the user's language (fixed selected contract name (CLAUDE.md or AGENTS.md) / lore/ / index.md and general technical English terms excluded); the area's established names win inside its tree, and a language clash with the area is flagged — never resolved silently.
  • No data, figures or deliverables are invented: they are derived from the source.
  • A paragraph is a paragraph (kit invariant in use-lore): generated lore/, contract and FASES.md are not hard-wrapped at column 80.
  • The project is NOT auto-committed. The user decides.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.