coily adopt: one-shot bootstrap so new repos pick up coily conventions #66

Open
opened 2026-05-23 20:54:05 +00:00 by coilysiren · 0 comments
Owner

Originally filed by @coilysiren on 2026-04-26T23:17:15Z - https://github.com/coilysiren/coily/issues/18

🤖 Filed by Claude Code on Kai's behalf.

Problem

Coily already ships the pieces that make a repo "coily-aware":

  • coily lockdown writes per-repo .claude/settings.json denies that force ops through coily.
  • coily lockdown skill regenerates the coily-passthroughs SKILL so Claude has the offline manifest.
  • coily gh ... / coily aws ... / coily kubectl ... are the audited entry points.

But applying them is manual and per-repo, and Kai keeps forgetting to run them when standing up (or returning to) a repo. The result is that sessions land in a repo and reach for bare gh / aws / kubectl, bypass the audit log, and (on Desktop, where the deny list is read but not enforced) silently succeed. Exactly the failure mode lockdown was meant to prevent.

Proposal

A single coily init (name TBD: coily bootstrap, coily setup, coily adopt are all candidates) that, run once from a repo root, applies the full coilysiren-convention bundle:

  • coily lockdown (settings.json denies + PreToolUse hook).
  • coily lockdown skill (regen passthroughs SKILL).
  • Optionally: stamp the standard .pre-commit-config.yaml trufflehog entry if missing.
  • Optionally: append a coily section to AGENTS.md if one isn't there ("this repo is coily-locked, use coily gh not gh").
  • Idempotent: re-running on an already-initialized repo is a no-op and reports drift.

Open questions

  • Name: init collides with git init semantics (creates something new). adopt or enroll reads more accurately, it's pulling an existing repo into the coily regime, not creating one. Lean toward adopt.
  • Scope: should this also bootstrap repo-local Makefile targets (make checkin per the daily-checkin discussion), or is that out of scope and a separate per-repo thing?
  • Discovery: is there value in a coily adopt --check mode that just reports what would change, for use in a daily sweep across all coilysiren/* repos? Pairs naturally with repo-recall surfacing "this repo isn't coily-adopted" as a signal.

Why this matters

The lockdown story only works if lockdown is actually applied. A one-command bootstrap removes the "I forgot" failure mode and makes it cheap to keep every repo in the workspace consistent. Also unblocks treating coily-adoption as a checkable invariant (CI lint, repo-recall signal) rather than a per-repo memory task.

🤖 Filed by Claude Code on Kai's behalf.

_Originally filed by @coilysiren on 2026-04-26T23:17:15Z - [https://github.com/coilysiren/coily/issues/18](https://github.com/coilysiren/coily/issues/18)_ > 🤖 Filed by Claude Code on Kai's behalf. ## Problem Coily already ships the pieces that make a repo "coily-aware": - `coily lockdown` writes per-repo `.claude/settings.json` denies that force ops through coily. - `coily lockdown skill` regenerates the `coily-passthroughs` SKILL so Claude has the offline manifest. - `coily gh ...` / `coily aws ...` / `coily kubectl ...` are the audited entry points. But applying them is manual and per-repo, and Kai keeps forgetting to run them when standing up (or returning to) a repo. The result is that sessions land in a repo and reach for bare `gh` / `aws` / `kubectl`, bypass the audit log, and (on Desktop, where the deny list is read but not enforced) silently succeed. Exactly the failure mode lockdown was meant to prevent. ## Proposal A single `coily init` (name TBD: `coily bootstrap`, `coily setup`, `coily adopt` are all candidates) that, run once from a repo root, applies the full coilysiren-convention bundle: - `coily lockdown` (settings.json denies + PreToolUse hook). - `coily lockdown skill` (regen passthroughs SKILL). - Optionally: stamp the standard `.pre-commit-config.yaml` trufflehog entry if missing. - Optionally: append a coily section to AGENTS.md if one isn't there ("this repo is coily-locked, use `coily gh` not `gh`"). - Idempotent: re-running on an already-initialized repo is a no-op and reports drift. ## Open questions - **Name**: `init` collides with `git init` semantics (creates something new). `adopt` or `enroll` reads more accurately, it's pulling an existing repo into the coily regime, not creating one. Lean toward `adopt`. - **Scope**: should this also bootstrap repo-local `Makefile` targets (`make checkin` per the daily-checkin discussion), or is that out of scope and a separate per-repo thing? - **Discovery**: is there value in a `coily adopt --check` mode that just reports what would change, for use in a daily sweep across all `coilysiren/*` repos? Pairs naturally with repo-recall surfacing "this repo isn't coily-adopted" as a signal. ## Why this matters The lockdown story only works if lockdown is actually applied. A one-command bootstrap removes the "I forgot" failure mode and makes it cheap to keep every repo in the workspace consistent. Also unblocks treating coily-adoption as a checkable invariant (CI lint, repo-recall signal) rather than a per-repo memory task. > 🤖 Filed by Claude Code on Kai's behalf.
coilysiren added
P4
and removed
P3
labels 2026-05-31 06:59:46 +00:00
Sign in to join this conversation.
No labels
P0
P1
P2
P3
P4
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
coilyco-bridge/coily#66
No description provided.