lore pull

Download and install a Lore package to the current project.

Usage


lore pull <namespace>/<name>:<version> [flags]

Description

Downloads the .lore archive from the registry, decompresses it, and writes platform-specific artifacts to the project directory. The target platform is auto-detected from the AI runtime present in the project.

Flags

Flag	Description
`--target <runtime>`	Override auto-detected runtime target (e.g., `claude-code`, `cursor`, `raw`)
`--output <dir>`	Output directory (default: `.`)
`--registry`	Registry URL

Examples


# Pull latest version
lore pull m1cloud/azure-architect:1.0.0
 
# Pull with explicit target
lore pull m1cloud/azure-architect:1.0.0 --target cursor
 
# Pull to a specific directory
lore pull m1cloud/azure-architect:1.0.0 --output ./ai-config

Runtime Targets

The CLI auto-detects the runtime from files in your project:

File present	Detected target
`CLAUDE.md`	`claude-code`
`.cursorrules`	`cursor`
`.github/`	`copilot`
`AGENTS.md`	`openai-agents`
(none)	`raw`

.github/ is a weak signal — most GitHub-hosted repos have one for CI workflows or issue templates, whether or not they use Copilot customization. If a project has both .claude//.cursor/rules/ and .github/, lore pull installs for all detected targets. Use --target claude (or any other explicit target) to skip Copilot output in a repo where .github/ exists for unrelated reasons.

GitHub Copilot targets

Lore `kind`	Install path
`Skill`	`.github/skills/{name}/SKILL.md`
`Rule`	`.github/instructions/{name}.instructions.md`
`Spec`	`.github/instructions/{name}.instructions.md`
`Template`	`.github/instructions/{name}.instructions.md`
`Agent`	`.github/agents/{name}.agent.md`
`Scaffold`	`.github/skills/{name}/SKILL.md` (instruction only — see below)
`MCPServer`	`.vscode/mcp.json`, under the `servers` key (see Authoring an MCPServer Package)

Spec and Template collapse into the same .instructions.md format as Rule — Copilot has no native concept distinguishing them, the same reason cursor collapses all four into one .mdc format. Rule/Spec/Template/Agent get a name+description YAML frontmatter block; Skill does not (its content is already agentskills.io-compatible). Copilot instructions apply repo-wide — there’s no per-path applyTo scoping in this version.

spec.include packages

Packages whose manifest.yaml declares spec.include never get their included files extracted straight to disk. Instead, lore pull writes an instruction file alongside the package’s normal rendered output:

kind: Scaffold → .claude/scaffolds/{name}.md (.github/skills/{name}/SKILL.md on the copilot target)
any other kind → .claude/includes/{name}.md (.github/includes/{name}.md on copilot, .lore/{name}/includes.md on raw)

That file lists every path declared in include: plus a lore extract command — it’s meant to be read by the AI, which runs that command to download and unpack the real files using your CLI’s own authenticated session (so private packages work too), then decides how to place them in your project (you can review the result as untracked files in git before committing, just like a normal scaffolding tool).


$ lore pull m1cloud/react-forms:1.0.0
.claude/skills/react-forms/SKILL.md
✓ Include instruction → .claude/includes/react-forms.md

This is additive: a Skill/Rule/Agent/etc. package with spec.include still gets its normal rendered file (SKILL.md, RULE.md, …) exactly as before — the instruction file is written in addition, not instead of it.

The instruction file points at lore extract, not a bare download URL — a private package’s /raw endpoint requires authentication, and an AI correctly won’t (and shouldn’t) fetch an authenticated URL or read your credentials off disk on its own. lore extract handles that using the same session lore login/LORE_AUTH_TOKEN already set up. See lore extract.