# Fr Init > > - **Type:** Skill - **Install:** `agentstack add skill-derio-net-super-fr-fr-init` - **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior - **Seller:** [derio-net](https://agentstack.voostack.com/s/derio-net) - **Installs:** 0 - **Category:** [Developer Tools](https://agentstack.voostack.com/c/developer-tools) - **Latest version:** 0.1.0 - **License:** MIT - **Upstream author:** [derio-net](https://github.com/derio-net) - **Source:** https://github.com/derio-net/super-fr/tree/main/plugins/super-fr/skills/fr-init ## Install ```sh agentstack add skill-derio-net-super-fr-fr-init ``` Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent. ## About # fr-init Captures "how you work in this repo" as committed devcontainer profiles plus host-only secrets placeholders. Interactive BY DESIGN — the interview is operator-owned context, so this skill is exempt from autonomy contracts: under a fr-goal run, a missing devcontainer is a blocker; pause, run this interview, resume isolated. **Announce at start:** "I'm using fr-init to set up this repo's profiles." ## 1. Scan first Before asking anything, learn what the repo already says: - Languages and toolchains: manifests (pyproject/package.json/go.mod/...), lockfiles, `.tool-versions`, CI workflows (what does CI install?). - Existing `.devcontainer/` (profiles already present? then this is an edit, not a green-field init). Check `.devcontainer/fr-profiles.yaml` for an existing top-level `backend:`/`host:` key too. - Which forge: `git remote get-url origin`'s hostname (`github.com` / `gitlab.com` self-identify; anything else, including a literal `gitea.com`, is self-hosted and needs the operator to confirm the backend explicitly — no hostname alone distinguishes GitLab Self-Managed / Gitea / GitHub Enterprise). - Credential surface: `.env*` patterns in .gitignore, CI secret names, cloud/k8s configs — candidates for the profile's expected secrets. - Working patterns: Makefile/justfile/scripts (what do humans run here?). The interview confirms and fills gaps; it never asks what the scan answers. ## 2. Interview (AskUserQuestion, batched ≤4 per round) Cover, with scan-informed recommended options: 1. **Backend** — github (default), gitlab, or gitea? Skip asking if the scan already resolved it unambiguously (github.com/gitlab.com remote, or an explicit `backend:` key already in fr-profiles.yaml). Confirm the hostname too (`--host`) if self-hosted — drives which CLI (`gh`/`glab`/`tea`) gets installed and which CI template `fr acceptance init` picks. 2. **Profiles wanted** — one `dev` default, or split (e.g. `readonly` for review/exploration vs `admin` with deploy credentials)? Profiles differ by CREDENTIALS first, tools second — same binaries, different env-files is the normal shape. 3. **Tools** — confirm the scan's toolchain list; surface what CI installs that local work also needs (kubectl, terraform, docker-in-docker...). 4. **Credentials per profile** — which env KEYS each profile expects (names only, never values). **Do NOT ask for a host-forge token by default:** push, PR/MR creation, and every `fr`-driven `gh`/`glab`/`tea` call run on the authenticated HOST (fr-isolation's credential boundary) — the container needs none for the standard pipeline. Offer it only for an explicit in-container-writes profile (e.g. `admin`). 5. **Working patterns** — test/build/run commands worth recording in the profile's purpose/notes so future runs know the repo's verbs. ## 3. Scaffold per profile ```bash fr init scaffold --repo . --profile dev --purpose "day-to-day development" \ --tool uv --tool node --default fr init scaffold --repo . --profile admin --purpose "deploys, gh writes" \ --secret GH_TOKEN --secret KUBECONFIG_B64 ``` For a non-GitHub repo, pass `--backend`/`--host` on EVERY profile call for that repo (repo-level, but scaffold reads it fresh per call): `fr init scaffold ... --backend gitlab --host gitlab.mycorp.com`. Each call writes: - `.devcontainer//devcontainer.json` — committed by scaffold; base image + the backend's CLI (github-cli feature for GitHub; a versioned, checksummed `glab`/`tea` binary install for GitLab/Gitea — no official devcontainer feature exists for either) + mapped tool features + vk installed in postCreate + `--env-file` pointing at the host secrets path. - `.devcontainer/fr-profiles.yaml` — committed by scaffold; default profile, purpose, expected secret keys, notes for tools without a feature mapping, and the repo-level `backend`/`host` keys (github is the implicit default and not written explicitly). - `~/.config/fr/secrets//.env` — host-only; commented placeholders per secret key. Existing operator values are never overwritten; re-runs only append missing placeholders. Unknown tools land in the profile's notes — wire them into `postCreateCommand` by editing the devcontainer.json, and say so. ## 4. Hand back - Tell the operator which placeholders to fill (`~/.config/fr/secrets//.env`) before the first `fr isolation up` — an empty env-file is normal for a default profile (the standard pipeline needs only the host's own CLI auth to be green: `gh auth status` for GitHub, `glab auth status` for GitLab, `tea login` for Gitea). - `fr init scaffold` already **committed** the `.devcontainer/` files (scoped commit on the current branch — `main` during bootstrap), so the profile is in the committed tree that `fr isolation up` checks out. No separate commit step — and the agent couldn't do one anyway (base-repo `git commit` is gate-denied). Pass `--no-commit` only if you want to stage/commit them yourself (e.g. to open a PR in a repo that blocks direct pushes to `main`). - If a run was paused on this init, resume it: `fr isolation up` now works. ## Multi-profile principles - The DEFAULT profile is the one autonomous runs use; keep it least- privileged enough to be safe unattended (admin credentials belong in a non-default profile the operator selects explicitly). - Adding a profile later is one more `fr init scaffold` call — the layout is per-profile subfolders from day one, no migration. ## Source & license This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code. - **Author:** [derio-net](https://github.com/derio-net) - **Source:** [derio-net/super-fr](https://github.com/derio-net/super-fr) - **License:** MIT Install and usage instructions live in the source repository linked above. ## Pricing - **Free** — Free ## Security capabilities Automated source analysis of v0.1.0 — what this tool can access: - **Network access:** no - **Filesystem access:** no - **Shell / process execution:** no - **Environment & secrets:** yes - **Dynamic code execution:** no *"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.* ## Versions - **0.1.0** — security scan: passed — Imported from the upstream source. ## Links - Listing page: https://agentstack.voostack.com/l/skill-derio-net-super-fr-fr-init - Seller: https://agentstack.voostack.com/s/derio-net - Browse the marketplace: https://agentstack.voostack.com/browse --- Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.