fr-initlisted

Initialize a repo for isolated runs: scan it, interview the operator about working patterns, tools, and credentials, then scaffold one or more devcontainer profiles via `fr init scaffold`. Use when a repo has no devcontainer profile, when fr-isolation or fr-brainstorming hard-stops asking for one, when the operator says "init this repo", "set up the devcontainer", or wants separate read-only/admin environments.
derio-net/super-fr · ★ 0 · AI & Automation · score 70

Install: claude install-skill derio-net/super-fr

# 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). - 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. **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. 2. **Tools** — confirm the scan's toolchain list; surface what CI installs that local work also needs (kubectl, te