agentleFS
Sign inStart free
jocarrdjocarrd/crux-agents/skills/carry-env/SKILL.md

carry-env

Skill4 starsChanged 19 days agoMITView on GitHub

Carry a project's environment files to another machine. It gathers them into a folder with the map of where each one goes and the script that puts them back, without opening them and without any value passing through the agent's context. Use when switching computers, setting up a laptop from scratch, or about to reinstall and needing to recover afterwards whatever isn't in git.

The file

We split this skill into the rules it gives an agent

1 rule. About 0 are common, 1 is distinctive, and 0 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.

  • 0

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Delete the folder. It is the only thing in the whole flow that carries plaintext secrets outside their place, and its value expires as soon …

    line 85

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

carry-env

Everything needed to work is in git except one thing: the environment files. They are ignored on purpose, so a clone gives you the complete code and a project that won't start.

This gathers them into a folder you can carry and, above all, leaves written where each one goes back to. Twelve files with flat names and no hint of their path are worthless three months from now, which is exactly when they get used.

When NOT to use this

To share secrets with another person. This is a plaintext copy for yourself between two machines of yours. A secret that has to be shared goes through a password manager, and one that has passed through a channel you don't control is rotated, not reused.

As a production backup. The server's files live on the server. Taking them out of there is a different, more delicate decision, and a cp doesn't resolve it.

Gather them

<this-skill-directory>/scripts/collect.sh --project ~/Projects/<project>

It leaves in ~/entornos-<project> the files, RESTAURAR.md with the table of destinations and restaurar.sh, which is the way back. Folder at 0700 and files at 0600.

The anchor is always the project root. If you point it at a repo inside (or at the docs repo) it climbs up to the root and tells you, because the map stores paths relative to it and that is what the other machine will know how to find. The name comes from the project declared in crux.json, not from the directory: it is the one crux bootstrap uses to create the folder at the destination.

It doesn't open any file. It copies with cp and reports names and paths. If an agent runs this, no value enters its context or gets written into the session transcript, and a secret that has been written into a transcript is no longer a secret.

What it leaves out, and why it matters

SkippedReason
*-ws-*Copies generated by crux workspace from the main repo. They are derived: restoring them over the good ones leaves you an environment that looks fine and points at other ports.
.next/, dist/, build/, out/The same file, copied by the build tool. Restoring the artifact doesn't fix the source.
*.example, *.sample, *.templateTemplates without values. They are already in the repo.

And what it doesn't even look for: anything personal and regenerable (SSH keys, CLI sessions, registry tokens, OAuth). That is generated on each machine. Copying it is worse than regenerating it, because a token that travels is a token whose path you no longer know. That list goes in the project's machine onboarding.

Put them back

On the new machine, with the repos already cloned (crux bootstrap):

cd ~/entornos-<project>
./restaurar.sh            # says what it would do
./restaurar.sh --apply    # copies them (--hazlo still works)

It looks for the project in the projects folder crux uses on that machine; if it isn't there, it looks one level deeper in case the folder was gathered by pointing at a repo, and if that fails too, you pass it as an argument. It never overwrites: if the destination already exists it skips it and says so, because losing a value that was only there is worse than copying too little.

It distinguishes three endings (placed, exists, no repo) and the third is the one to look at: it means that repo isn't there, so either it still needs cloning or it no longer belongs to the project.

When finished

Delete the folder. It is the only thing in the whole flow that carries plaintext secrets outside their place, and its value expires as soon as you have restored.

Related

  • crux bootstrap: brings the repos; this brings what the repos don't carry
  • operations/machine-onboarding.md of the project: the personal stuff, which does get regenerated

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.

Check your setup, free