seal init

seal init bootstraps a fresh seal.json in the current working directory. It proposes discovery patterns based on agent layouts it detects, hashes the matched bundles, prints a summary, and on confirmation writes the lockfile atomically.

init is the only way to create seal.json. Once it exists, use pin to update entries.

Synopsis

seal init [--warn] [--verbose]

Flags

Flag	Effect
`--warn`	Set `policy: "warn"` in the new lockfile instead of the default `"block"`.
`-v`, `--verbose`	Show per‑file detail in the summary.

There is no -y / --force flag. Confirmation is required and cannot be bypassed.

Behaviour

If seal.json already exists in the current working directory, init exits 2 with seal: init: <path> already exists; init will not overwrite.
Otherwise, it runs the heuristics registry. For each entry whose probe directory exists, the pattern is added to a proposed discovery array.
Those patterns are expanded using the discovery glob matcher to find candidate sealed roots.
Each candidate is hashed so the summary can show accurate file counts.
The summary is printed to stderr (stdout stays reserved for machine output). With --verbose, each candidate expands into a per‑file listing.
If at least one pattern or bundle is proposed, you see Apply these changes? [y/N].
If the heuristics found nothing, the summary shows no patterns or bundles, then you see the explicit fallback prompt:
```
No agent bundles or known agent layouts detected in this project. Create empty seal.json with policy: block? [y/N]
```
On y, the file lock is acquired, seal.json is written atomically, and the success line is printed:
```
Wrote seal.json (<n> bundles, <m> discovery patterns)
```
On any other answer (or bare Enter, or EOF), the operation is abandoned: seal: init aborted, exit 2.

Heuristics registry

init is the only command that uses agent‑specific heuristics. pin and verify are driven exclusively by the lockfile’s discovery array, so CI behaviour is deterministic across implementations.

The current registry, in declaration order:

Name	Pattern
Agent Skills	`.agents/skills/*`
Amazon Q agents	`.amazonq/agents/*`
Amazon Q rules	`.amazonq/rules`
Amp agents	`.amp/agents/*`
Amp skills	`.amp/skills/*`
Claude Code agents	`.claude/agents/*`
Claude Code commands	`.claude/commands/*`
Claude Code hooks	`.claude/hooks`
Claude Code plugins	`.claude/plugins/*`
Claude Code skills	`.claude/skills/*`
Codex skills	`.codex/skills/*`
Cursor rules	`.cursor/rules`
Cursor skills	`.cursor/skills/*`
Gemini CLI skills	`.gemini/skills/*`
GitHub Copilot instructions	`.github/instructions`
GitHub Copilot prompts	`.github/prompts`
GitHub Copilot skills	`.github/skills/*`
Kiro agents	`.kiro/agents/*`
Kiro skills	`.kiro/skills/*`
Kiro specs	`.kiro/specs/*`
Kiro steering	`.kiro/steering`
OpenClaw skills	`.openclaw/skills/*`
OpenCode agents	`.opencode/agents/*`
OpenCode commands	`.opencode/commands/*`
OpenCode modes	`.opencode/modes/*`
OpenCode plugins	`.opencode/plugins/*`
OpenCode skills	`.opencode/skills/*`
OpenCode tools	`.opencode/tools/*`
Windsurf rules	`.windsurf/rules`
Windsurf skills	`.windsurf/skills/*`

For wildcard-leaf patterns such as .claude/skills/*, the probe is the parent directory (.claude/skills). For whole-directory patterns such as .cursor/rules, the probe is the directory itself. So a fresh Go project does not get every agent-tool layout dumped into it, and the suggestion list reads top‑down in the order above.

If a pattern’s probe directory exists but contains no bundles, the proposed pattern produces zero candidates and the user simply sees no bundles in the summary. The empty pattern is still written to discovery so future bundles in that directory are picked up by seal pin.

TTY requirement

init requires confirmation, so both stdin and stderr must be a TTY. If neither is interactive (typical for CI), init refuses to run and exits 2:

seal: init: requires a TTY for confirmation; cannot bootstrap seal.json in a non-interactive environment

This is intentional: the spec requires any operation mutating seal.json to summarise the changes and prompt for explicit user confirmation, with no bypass mechanism.

Exit codes

Code	Meaning
`0`	`seal.json` was written successfully.
`2`	`seal.json` already exists, confirmation declined, no TTY, read/write error, or any other fatal condition.

See exit codes for the full table across all subcommands.

Examples

Bootstrap a project that uses Claude Code skills:

$ seal init
Discovery patterns to add:
  + .claude/skills/*

Bundles to add (2):
  + ./.claude/skills/code-review        (12 files)
  + ./.claude/skills/deploy-guard       (4 files)

Apply these changes? [y/N] y
Wrote seal.json (2 bundles, 1 discovery patterns)

Bootstrap an empty lockfile in a project with no detected layouts:

$ seal init
Discovery patterns to add:
  (none)

Bundles to add (0):

No agent bundles or known agent layouts detected in this project. Create empty seal.json with policy: block? [y/N] y
Wrote seal.json (0 bundles, 0 discovery patterns)

Use warn policy instead of block:

seal init --warn