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
- planetis-m/skillsword for word, first seen Jul 16, 2026
Other versions1 project uses a version of this.
Word for word · 1
- planetis-m/skills★ 59100% same
Edited · 0
None found.
Wrote their own version · 0
None found.
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository18 other files it gives its agents.
- buildSkill
- docs-genSkill
- format-codeSkill
- nim-api-designSkill
- nim-c-bindingsSkill
- nim-code-organizationSkill
- nim-c-wrappersSkill
- nim-debuggingSkill
- nim-defect-analysisSkill
- nim-doc-commentsSkill
- nim-error-handlingSkill
- nim-fuzzingSkill
- nim-mcp-toolsSkill
- nimonypluginsSkill
- nim-ownership-hooksSkill
- nim-style-guideSkill
- nim-testingSkill
- run-testsSkill
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
- Very specific: line 12
Treat either root atlas.config or <deps>/atlas.config as Atlas config.
- Very specific: line 14
Use atlas init from the project root to initialize Atlas state.
- Very specific: line 15
Use atlas init --deps=DIR or atlas --deps=DIR init when the project intentionally uses a dependency directory other than deps/.
- Very specific: line 17
After initialization, inspect <deps>/atlas.config.
- Very specific: line 19
Do not assume atlas init creates nim.cfg.
- Very specific: line 24
Use atlas use <url|pkgname> to add a dependency.
- Very specific: line 25
Use atlas install when the Nimble file already contains requirements and Atlas should materialize the dependency graph.
- Very specific: line 27
Use atlas update [filter] to refresh dependency refs.
- Very specific: line 29
Use atlas link <path> only for local project linking tasks.
- Very specific: line 31
Use atlas pin [atlas.lock] to pin current dependency checkouts.
- Very specific: line 32
Use atlas rep [atlas.lock] to replay a lockfile.
- Very specific: line 33
Use atlas --noexec rep [atlas.lock] when replay should avoid build actions that may run arbitrary code.
- Very specific: line 35
Use atlas env <nimversion> for project-local Nim environments, for example atlas env 1.6.12 or atlas env devel.
- Very specific: line 53
Use --packagesRepo only when the workflow needs the full nim-lang/packages git repository behavior.
- Very specific: line 54
Use --forceGitToHttps when dependency URLs need git:// rewritten to https://.
- Very specific: line 55
If a package name or URL resolves incorrectly, fix nameOverrides, urlOverrides, or pkgOverrides in <deps>/atlas.config instead of editing …
- Very specific: line 71
Do not hand-edit generated --path entries as the first fix.
- Very specific: line 80
Use nameOverrides for package-name-to-URL mapping.
- Very specific: line 81
Use urlOverrides for URL rewrite rules.
- Very specific: line 82
Use pkgOverrides when multiple URLs conflict for the same package shortname.
- Very specific: line 83
Keep overrides in Atlas config so future install, use, update, and rep commands remain repeatable.
- Very specific: line 91
Use --allFeatures only when every declared feature should be enabled.
- Very specific: line 92
Use --keepFeatures or -k when the command should reuse feature defines from the current nim.cfg.
- Distinctive: line 99
Treat plugin execution as potentially arbitrary code execution because plugins can call external tools.
- Very specific: line 101
Use --noexec when the task only needs dependency graph setup or lockfile replay and build actions should not run.
- Distinctive: line 106
After a successful env setup, activate it explicitly:
- Distinctive: line 109
Do not assume the virtual Nim environment is active in later shell sessions.
- Very specific: line 114
Look for *.nimble, nim.cfg, atlas.lock, deps/, and any custom dependency directory.
- Very specific: line 116
Check root atlas.config first, then <deps>/atlas.config.
- Very specific: line 119
Use init, use, install, update, link, pin, rep, or env according to the task.
- Very specific: line 120
Run commands from the project root unless --project=path is intentional.
- Distinctive: line 121
Check policy before changing dependencies.
- Distinctive: line 122
Read resolver, overrides, plugins, feature needs, lockfile state, and existing Nimble requirements.
- Very specific: line 123
Run the smallest Atlas operation.
- Very specific: line 124
Use filters for targeted updates and --noexec when arbitrary build actions should not run.
- Very specific: line 129
If the dependency set must remain stable, run atlas pin after successful setup and keep the lockfile with the project when that is the …
≈ “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.
Files
Atlas Package Cloner
Rules
Project State
- Treat either root
atlas.configor<deps>/atlas.configas Atlas config. Atlas prefers rootatlas.configwhen present, butatlas initcreatesdeps/atlas.configby default. - Use
atlas initfrom the project root to initialize Atlas state. - Use
atlas init --deps=DIRoratlas --deps=DIR initwhen the project intentionally uses a dependency directory other thandeps/. - After initialization, inspect
<deps>/atlas.config; the default config recordsdeps,nameOverrides,urlOverrides,pkgOverrides,plugins,resolver, andgraph. - Do not assume
atlas initcreatesnim.cfg. Atlas has code paths that patchnim.cfgwhen dependency operations need compiler paths.
Commands
- Use
atlas use <url|pkgname>to add a dependency. - Use
atlas installwhen 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 replayandatlas reproduceare 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 exampleatlas env 1.6.12oratlas env devel.
Package Names, URLs, And Indexes
- Package names are resolved through Atlas' package lookup table, populated from
packages.json, plus configurednameOverrides. - URL inputs are parsed as URLs and can be rewritten with
urlOverrides. - Forge aliases are valid package references:
| Alias | Expands to |
gh:user/repo or github:user/repo | https://github.com/user/repo |
gl:user/repo or gitlab:user/repo | https://gitlab.com/user/repo |
srht:user/repo or sourcehut:user/repo | https://git.sr.ht/~user/repo |
cb:user/repo, cberg:user/repo, or codeberg:user/repo | https://codeberg.org/user/repo |
- Atlas downloads
packages.jsoninto the package cache by default, usingpackages.nim-lang.orgwith GitHub fallback. - Use
--packagesRepoonly when the workflow needs the fullnim-lang/packagesgit repository behavior. - Use
--forceGitToHttpswhen dependency URLs needgit://rewritten tohttps://. - If a package name or URL resolves incorrectly, fix
nameOverrides,urlOverrides, orpkgOverridesin<deps>/atlas.configinstead of editing generated paths by hand.
Generated nim.cfg Paths
- Atlas'
nim.cfgpatcher uses this section shape:
############# begin Atlas config section ##########
--noNimblePath
--path:"deps/pkg"
############# end Atlas config section ##########- Inspect the Atlas section in
nim.cfgwhen imports fail. - Preserve user-written content outside the Atlas begin/end section.
- Do not hand-edit generated
--pathentries as the first fix. Correct the dependency graph, package metadata, or config overrides instead.
Resolution And Overrides
- Atlas supports
MinVer,SemVer, andMaxVerresolver algorithms. - The generated default config uses
SemVer. - Set resolver policy in
<deps>/atlas.configor with--resolver=minver|semver|maxverwhen the task requires a specific policy. - Use
nameOverridesfor package-name-to-URL mapping. - Use
urlOverridesfor URL rewrite rules. - Use
pkgOverrideswhen multiple URLs conflict for the same package shortname. - Keep overrides in Atlas config so future
install,use,update, andrepcommands remain repeatable.
Features
- Atlas supports Nimble
featurestatements. - Pass feature flags explicitly with
--feature=<feature>. Pass multiple--featureoptions when multiple features are required, or use--features=<list>for a comma- or space-separated list. - Use
--allFeaturesonly when every declared feature should be enabled. - Use
--keepFeaturesor-kwhen the command should reuse feature defines from the currentnim.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
*.nimsfiles read from the project-relative directory configured by thepluginsfield. - 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
--noexecwhen 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
- Unix:
- Do not assume the virtual Nim environment is active in later shell sessions.
Workflow
- Inspect the project root.
Look for
*.nimble,nim.cfg,atlas.lock,deps/, and any custom dependency directory. - Locate Atlas config.
Check root
atlas.configfirst, then<deps>/atlas.config; if--depsor--confdiris in use, inspect that configured location. - Choose the Atlas command.
Use
init,use,install,update,link,pin,rep, orenvaccording to the task. Run commands from the project root unless--project=pathis intentional. - Check policy before changing dependencies. Read resolver, overrides, plugins, feature needs, lockfile state, and existing Nimble requirements.
- Run the smallest Atlas operation.
Use filters for targeted updates and
--noexecwhen arbitrary build actions should not run. - Verify generated state.
Inspect
<deps>/atlas.config,project.nimble,nim.cfg, andatlas.lockas applicable. Compile or test the smallest Nim target that imports the affected package. - Preserve reproducibility.
If the dependency set must remain stable, run
atlas pinafter 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
| Mistake | Why it is wrong |
Looking only for root atlas.config | Verified atlas init writes deps/atlas.config by default even though root config is preferred when present. |
Assuming atlas init creates nim.cfg | Verified init creates Atlas config only; dependency operations are what drive path patching. |
Editing generated nim.cfg paths first | Atlas can regenerate that section; fix config, package metadata, or dependency resolution instead. |
| Enabling plugins without inspection | Plugins 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.
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
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.

