Skip to main content
// docs / organize

Organize your library in 10 minutes.

Three questions, in this order: who may see it (repo), what is it about (folder), what else is true about it (tag).

Repo, folder, tag

  • Repo · The sharing boundary. Visibility (private or public), members and their roles, and the license are set per repo. Put prompts that are shared with the same people in the same repo.
  • Folder · The area inside a repo. A path like reviews/backend: up to 3 levels, 64 characters per level. A folder has no permissions of its own; it only groups.
  • Tag · The axis that cuts across folders. A label like security or weekly that can sit on prompts in different folders of the same repo. Tags belong to one repo; moving a prompt to another repo matches them by name.

Start with the repo: if two prompts must never be seen by the same people, they do not belong in the same repo. Folders and tags are free to change later, a repo boundary is not, so decide that first. See Sharing & discovery and Collaboration for what a repo setting does.

Name a prompt: verb + object, no commas, one name per account

Good titles read like a command you would give: Review pull request, Summarize meeting notes, Draft release notes. Three rules:

  1. Verb first, then the object. The title is what you type in ple get and what an agent passes to get_prompt; a verb tells both what it does.
  2. No commas. ple save reads a comma in a tag as a separator (-t "a,b" becomes the tags a and b), and a comma is easy to lose in scripts that pass a title along. Use a dash or another word.
  3. Unique across your whole account, not only inside the repo. When two repos have a prompt with the same title, a lookup by name has to ask which one; the CLI then needs --project to tell them apart. Fewer such asks, fewer wrong prompts.

Write the description line agents search

Search looks in the title and the description, so the description is where the words you did not put in the title can be found. One line, four parts:

description pattern
When <the situation> · Input <what you give it> · Output <what you get back> · keywords <words you would search for, in the languages you use>
example
When a pull request needs a second pair of eyes · Input the diff, the ticket text · Output a ranked list of risks with file and line · keywords code review, PR, risk, diff, kod incelemesi

The When part is the one a person (or an agent deciding which prompt to use) reads first; put the situation there, not a summary of the text.

Three example structures

Pick the one closest to you and change the names.

1 · Solo developer: one private repo, folders by job
my-prompts            (private)
├─ coding/            Review pull request · Explain stack trace
├─ writing/           Draft release notes · Rewrite for clarity
└─ research/          Summarize paper · Compare options
tags: weekly, security, draft
2 · Small team: one shared repo for the team, one private repo for experiments
team-prompts          (private, members: editors)
├─ support/replies/   Answer refund request · Answer shipping question
├─ support/triage/    Classify incoming ticket
└─ engineering/       Review pull request · Write migration plan
my-experiments        (private, only you)
└─ drafts/            anything not ready to share
tags: approved, needs-review
3 · Public library next to private work: the repo is the line
public-patterns       (public, license set)
├─ review/            Review pull request
└─ writing/           Rewrite for clarity
work-prompts          (private)
└─ client-a/ · client-b/   one folder per client, nothing here is public
tags: v2, stable

A prompt is on a public page only when its repo and the prompt itself are public. Moving a prompt between a public and a private repo changes who can see it, so you are asked to confirm.

Move a prompt, rename a folder (web app)

  1. Open the repo (as its owner), hover a prompt row and click the Move icon. Pick a repo you can edit and, if you like, a folder (type a new one, or choose one that exists).
  2. The prompt keeps its versions, deploy labels, stars, usage count and its short /p/… link. Tags are matched by name in the target repo and created if they do not exist.
  3. A move is refused when the target repo already has a prompt with the same title (rename one first), or when the owner of the target repo has reached the plan's prompt limit.
  4. Once a repo has folders, a tree appears on the left of the prompt list. Select a folder and use Rename: the folder and everything under it get the new path, the prompts themselves do not change.

The page of a public prompt lives under its repo's address, so that address changes when the prompt moves to another repo; the short /p/… link does not.

Move and folders in the terminal and in the MCP tools are not part of the released packages yet. Today they work in the web app.

A ten-minute check

  • Every repo answers "who may see this?" in one sentence.
  • No folder is deeper than two levels in daily use; three is the limit.
  • No two prompts in your account share a title.
  • Every prompt you reuse has a description line with a When part.
  • You can find a prompt by a word that is only in its description: ple search "risk".

Next: Workspace & navigation for the sidebar and ⌘K, and the CLI reference.