agentleFS
VyrnexisVyrnexis/nim-agent-template/skills/atlas-package-cloner/SKILL.md

atlas-package-cloner

Skill4 starsChanged 3 months agoMITView on GitHub

Use Atlas to initialize Nim projects, install or update Atlas-managed dependencies, configure dependency directories, inspect Atlas-generated nim.cfg paths, handle Atlas overrides, features, plugins, lockfiles, and local Nim environments. Use when setting up or repairing Nim dependency workflows that use Atlas instead of Nimble's global package path.

1 other project uses a version of this.

Adopted by

Most recently taken up by

The file

Show its rules and text

We split this skill into the rules it gives an agent

36 rules. About 0 are common, 5 are distinctive, and 31 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈5

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 31

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  • could be automatic: a setting could enforce it
  1. Very specific:

    Treat either root atlas.config or <deps>/atlas.config as Atlas config.

    line 12
  2. Very specific:

    Use atlas init from the project root to initialize Atlas state.

    line 14
  3. Very specific:

    Use atlas init --deps=DIR or atlas --deps=DIR init when the project intentionally uses a dependency directory other than deps/.

    line 15
  4. Very specific:

    After initialization, inspect <deps>/atlas.config.

    line 17
  5. Very specific:

    Do not assume atlas init creates nim.cfg.

    line 19
  6. Very specific:

    Use atlas use <url|pkgname> to add a dependency.

    line 24
  7. Very specific:

    Use atlas install when the Nimble file already contains requirements and Atlas should materialize the dependency graph.

    line 25
  8. Very specific:

    Use atlas update [filter] to refresh dependency refs.

    line 27
  9. Very specific:

    Use atlas link <path> only for local project linking tasks.

    line 29
  10. Very specific:

    Use atlas pin [atlas.lock] to pin current dependency checkouts.

    line 31
  11. Very specific:

    Use atlas rep [atlas.lock] to replay a lockfile.

    line 32
  12. Very specific:

    Use atlas --noexec rep [atlas.lock] when replay should avoid build actions that may run arbitrary code.

    line 33
  13. Very specific:

    Use atlas env <nimversion> for project-local Nim environments, for example atlas env 1.6.12 or atlas env devel.

    line 35
  14. Very specific:

    Use --packagesRepo only when the workflow needs the full nim-lang/packages git repository behavior.

    line 53
  15. Very specific:

    Use --forceGitToHttps when dependency URLs need git:// rewritten to https://.

    line 54
  16. Very specific:

    If a package name or URL resolves incorrectly, fix nameOverrides, urlOverrides, or pkgOverrides in <deps>/atlas.config instead of editing …

    line 55
  17. Very specific:

    Do not hand-edit generated --path entries as the first fix.

    line 71
  18. Very specific:

    Use nameOverrides for package-name-to-URL mapping.

    line 80
  19. Very specific:

    Use urlOverrides for URL rewrite rules.

    line 81
  20. Very specific:

    Use pkgOverrides when multiple URLs conflict for the same package shortname.

    line 82
  21. Very specific:

    Keep overrides in Atlas config so future install, use, update, and rep commands remain repeatable.

    line 83
  22. Very specific:

    Use --allFeatures only when every declared feature should be enabled.

    line 91
  23. Very specific:

    Use --keepFeatures or -k when the command should reuse feature defines from the current nim.cfg.

    line 92
  24. Distinctive:

    Treat plugin execution as potentially arbitrary code execution because plugins can call external tools.

    line 99
  25. Very specific:

    Use --noexec when the task only needs dependency graph setup or lockfile replay and build actions should not run.

    line 101
  26. Distinctive:

    After a successful env setup, activate it explicitly:

    line 106
  27. Distinctive:

    Do not assume the virtual Nim environment is active in later shell sessions.

    line 109
  28. Very specific:

    Look for *.nimble, nim.cfg, atlas.lock, deps/, and any custom dependency directory.

    line 114
  29. Very specific:

    Check root atlas.config first, then <deps>/atlas.config.

    line 116
  30. Very specific:

    Use init, use, install, update, link, pin, rep, or env according to the task.

    line 119
  31. Very specific:

    Run commands from the project root unless --project=path is intentional.

    line 120
  32. Distinctive:

    Check policy before changing dependencies.

    line 121
  33. Distinctive:

    Read resolver, overrides, plugins, feature needs, lockfile state, and existing Nimble requirements.

    line 122
  34. Very specific:

    Run the smallest Atlas operation.

    line 123
  35. Very specific:

    Use filters for targeted updates and --noexec when arbitrary build actions should not run.

    line 124
  36. Very specific:

    If the dependency set must remain stable, run atlas pin after successful setup and keep the lockfile with the project when that is the …

    line 129

≈ “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

Atlas Package Cloner

Rules

Project State

  • Treat either root atlas.config or <deps>/atlas.config as Atlas config. Atlas prefers root atlas.config when present, but atlas init creates deps/atlas.config by default.
  • Use atlas init from the project root to initialize Atlas state.
  • Use atlas init --deps=DIR or atlas --deps=DIR init when the project intentionally uses a dependency directory other than deps/.
  • After initialization, inspect <deps>/atlas.config; the default config records deps, nameOverrides, urlOverrides, pkgOverrides, plugins, resolver, and graph.
  • Do not assume atlas init creates nim.cfg. Atlas has code paths that patch nim.cfg when dependency operations need compiler paths.

Commands

  • Use atlas use <url|pkgname> to add a dependency.
  • Use atlas install when the Nimble file already contains requirements and Atlas should materialize the dependency graph.
  • Use atlas update [filter] to refresh dependency refs. Prefer a filter when only one dependency needs an update.
  • Use atlas link <path> only for local project linking tasks; be prepared to inspect generated link files and the linked project's dependency graph state.
  • Use atlas pin [atlas.lock] to pin current dependency checkouts.
  • Use atlas rep [atlas.lock] to replay a lockfile. atlas replay and atlas reproduce are aliases.
  • Use atlas --noexec rep [atlas.lock] when replay should avoid build actions that may run arbitrary code.
  • Use atlas env <nimversion> for project-local Nim environments, for example atlas env 1.6.12 or atlas env devel.

Package Names, URLs, And Indexes

  • Package names are resolved through Atlas' package lookup table, populated from packages.json, plus configured nameOverrides.
  • URL inputs are parsed as URLs and can be rewritten with urlOverrides.
  • Forge aliases are valid package references:
AliasExpands to
gh:user/repo or github:user/repohttps://github.com/user/repo
gl:user/repo or gitlab:user/repohttps://gitlab.com/user/repo
srht:user/repo or sourcehut:user/repohttps://git.sr.ht/~user/repo
cb:user/repo, cberg:user/repo, or codeberg:user/repohttps://codeberg.org/user/repo
  • Atlas downloads packages.json into the package cache by default, using packages.nim-lang.org with GitHub fallback.
  • Use --packagesRepo only when the workflow needs the full nim-lang/packages git repository behavior.
  • Use --forceGitToHttps when dependency URLs need git:// rewritten to https://.
  • If a package name or URL resolves incorrectly, fix nameOverrides, urlOverrides, or pkgOverrides in <deps>/atlas.config instead of editing generated paths by hand.

Generated nim.cfg Paths

  • Atlas' nim.cfg patcher uses this section shape:
############# begin Atlas config section ##########
--noNimblePath
--path:"deps/pkg"
############# end Atlas config section   ##########
  • Inspect the Atlas section in nim.cfg when imports fail.
  • Preserve user-written content outside the Atlas begin/end section.
  • Do not hand-edit generated --path entries as the first fix. Correct the dependency graph, package metadata, or config overrides instead.

Resolution And Overrides

  • Atlas supports MinVer, SemVer, and MaxVer resolver algorithms.
  • The generated default config uses SemVer.
  • Set resolver policy in <deps>/atlas.config or with --resolver=minver|semver|maxver when the task requires a specific policy.
  • Use nameOverrides for package-name-to-URL mapping.
  • Use urlOverrides for URL rewrite rules.
  • Use pkgOverrides when multiple URLs conflict for the same package shortname.
  • Keep overrides in Atlas config so future install, use, update, and rep commands remain repeatable.

Features

  • Atlas supports Nimble feature statements.
  • Pass feature flags explicitly with --feature=<feature>. Pass multiple --feature options when multiple features are required, or use --features=<list> for a comma- or space-separated list.
  • Use --allFeatures only when every declared feature should be enabled.
  • Use --keepFeatures or -k when the command should reuse feature defines from the current nim.cfg.
  • Feature request flags populate runtime context; they are not saved as fields in atlas.config.
  • In Nimble requirements, feature syntax has the shape require "somelib[testing]".

Plugins And Build Actions

  • Atlas plugins are *.nims files read from the project-relative directory configured by the plugins field.
  • Treat plugin execution as potentially arbitrary code execution because plugins can call external tools.
  • Inspect the configured plugin directory before enabling plugins or replaying dependencies with execution enabled.
  • Use --noexec when the task only needs dependency graph setup or lockfile replay and build actions should not run.

Virtual Nim Environments

  • atlas env <version> creates a project-local Nim environment under the dependency directory.
  • After a successful env setup, activate it explicitly:
    • Unix: source deps/nim-<version>/activate.sh
    • Windows: deps\nim-<version>\activate.bat
  • Do not assume the virtual Nim environment is active in later shell sessions.

Workflow

  1. Inspect the project root. Look for *.nimble, nim.cfg, atlas.lock, deps/, and any custom dependency directory.
  2. Locate Atlas config. Check root atlas.config first, then <deps>/atlas.config; if --deps or --confdir is in use, inspect that configured location.
  3. Choose the Atlas command. Use init, use, install, update, link, pin, rep, or env according to the task. Run commands from the project root unless --project=path is intentional.
  4. Check policy before changing dependencies. Read resolver, overrides, plugins, feature needs, lockfile state, and existing Nimble requirements.
  5. Run the smallest Atlas operation. Use filters for targeted updates and --noexec when arbitrary build actions should not run.
  6. Verify generated state. Inspect <deps>/atlas.config, project.nimble, nim.cfg, and atlas.lock as applicable. Compile or test the smallest Nim target that imports the affected package.
  7. Preserve reproducibility. If the dependency set must remain stable, run atlas pin after successful setup and keep the lockfile with the project when that is the repository policy.

Task Examples

  • For a new project that adds a dependency, read references/start_project.md.
  • For custom dependency directories and overrides, read references/custom_deps_and_overrides.md.
  • For feature flags, lockfiles, and replay, read references/features_and_replay.md.

Common Mistakes

MistakeWhy it is wrong
Looking only for root atlas.configVerified atlas init writes deps/atlas.config by default even though root config is preferred when present.
Assuming atlas init creates nim.cfgVerified init creates Atlas config only; dependency operations are what drive path patching.
Editing generated nim.cfg paths firstAtlas can regenerate that section; fix config, package metadata, or dependency resolution instead.
Enabling plugins without inspectionPlugins are NimScript files and may execute external commands.

References

  • references/start_project.md — Atlas adoption: project setup, dependency addition, and compile flow.
  • references/custom_deps_and_overrides.md — Custom dependency directories and URL overrides.
  • references/features_and_replay.md — Optional features and lockfile replay commands.

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.