agentleFS
EpicGamesEpicGames/lore/.claude/skills/write-lep/SKILL.md

write-lep

Skill9.1k starsChanged 9 days agoMITView on GitHub

How to draft a Lore Enhancement Proposal in docs/proposals/ — naming, drafting against the template, applying the rules in the README, and finishing the file.

Adopted by

Steady: 0 new projects took it in the last 4 weeks, none the 4 weeks before.thin data

Week of Sep 13: 0 new projectsWeek of Sep 20: 0 new projectsWeek of Sep 27: 0 new projectsWeek of Oct 4: 0 new projectsWeek of Oct 11: 0 new projectsWeek of Oct 18: 0 new projectsWeek of Oct 25: 0 new projectsWeek of Nov 1: 0 new projects
Sep 2026Oct 2026Nov 2026
New projects taking a version of this file each week, over the 8 weeks our latest run read: only 0 in all, so this is a hint, not a trend.

Who's talking about EpicGames/lore

The biggest 5 of 39 mentions linking to the repository that our crawl found. Each line is their own headline.

See all 39

Talked about on GitHub, Bluesky and Hacker News (39 times).

On GitHub · 26

21 more on GitHub

On Bluesky · 12

7 more on Bluesky

On Hacker News · 1

The file

We split this skill into the rules it gives an agent

6 rules. About 0 are common, 1 is distinctive, and 5 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈1

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 5

    Very specific

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

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

    Read docs/proposals/README.md ("How to write an LEP").

    line 13
  2. Very specific:

    Read docs/proposals/lep-template.md to confirm the section structure and frontmatter shape.

    line 15
  3. Distinctive:

    If the user did not pass a title as an argument, ask for a short descriptive one.

    line 19
  4. Very specific:

    Start from the template's structure — same sections in the same order.

    line 29
  5. Very specific:

    When research and user input genuinely don't support a claim, mark {TODO: <what's missing>} in place rather than inventing detail.

    line 31
  6. Very specific:

    Do not editorialize about the proposal's quality.

    line 33

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “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

Write LEP

Mechanical authoring of a new LEP. The rules — per-section and cross-cutting — live in docs/proposals/README.md. The template at docs/proposals/lep-template.md is just the section skeleton. This guide is the procedure for applying both.

Before you start

Read docs/proposals/README.md ("How to write an LEP"). It is the canonical source for what each section requires and for the cross-cutting rules (active voice, public citations, no fabrication).

Read docs/proposals/lep-template.md to confirm the section structure and frontmatter shape.

Find out what the user has by way of prior research: notes, related reviews, design conversations, related tickets, pasted content, file paths, glob patterns, public links. Any form is fine. If they have nothing, proceed without.

If the user did not pass a title as an argument, ask for a short descriptive one.

Naming the file

Filenames follow YYYY-MM-DD-<slug>.md, where <slug> is the kebab-case form of the title (lowercase, hyphens, no punctuation, max ~6 words). Today's date comes from date +%Y-%m-%d. If a file with the chosen name already exists in docs/proposals/, append -2, -3, etc. until you reach a free name.

Drafting

Before drafting, check the scope against the README's One decision per proposal. When the work has parts that can be accepted on their own, write a proposal for each. A part that changes an accepted LEP is an amendment to it, as the README's Lifecycle describes. Tell the user the split before you draft.

Start from the template's structure — same sections in the same order. For each section, apply the rules in docs/proposals/README.md and replace the template's placeholder text with your content.

When research and user input genuinely don't support a claim, mark {TODO: <what's missing>} in place rather than inventing detail.

Do not editorialize about the proposal's quality. Apply the rules; gaps become {TODO}s, not opinions.

Finishing

Set the frontmatter: lep is the filename without .md, status is Draft, created and updated are today's date. Write the file to docs/proposals/<filename>.

Tell the user to run /review-lep docs/proposals/<filename> before sharing the LEP. Staging, committing, and opening it for review are the author's calls — this guide stops at writing the file.

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.