arthai-marketplace

/extensions enable

Enable a compliance extension pack for this project.

Synopsis

/extensions enable <domain>/<name>

The pack_id argument must be in <domain>/<name> format (e.g., compliance/hipaa, security/baseline).

When to use it

Opting a project into a compliance or quality pack (e.g. compliance/hipaa, security/baseline) so its rules apply to toolkit workflows
Re-enabling a pack you previously disabled — both entries (the original disable and the new re-enable) are kept in the audit trail with timestamps, so you can see when it was disabled and when it was re-enabled
Not for: seeing what’s available — that’s /extensions list; or skipping one rule in an enabled pack — that’s /extensions waive

Quickstart

/extensions enable compliance/hipaa

What you’ll see: Enabled compliance/hipaa v1.0.0 (restrictiveness 5, source original). Evidence will be generated on next /pr run. — plus a conflict count if the pack’s rules overlap with already-enabled packs.

Examples

/extensions enable compliance/hipaa      # opt in to a pack (format: <domain>/<name>)
/extensions enable security/baseline     # enable a second pack — conflicts auto-resolve

What it does

Validates the pack exists on disk (both its opt-in and rules files) and has well-formed frontmatter.
Checks current state — already-active packs exit cleanly (idempotent); a previously disabled pack is detected as a re-enable and the prior audit trail is preserved.
Scans for rule conflicts with already-enabled packs. Overlapping rules auto-resolve in favor of the higher restrictiveness (alphabetical pack ID on a tie) — each resolution is logged, with no interactive prompt.
Records the enablement in .claude/extensions/.enabled.json with the pack ID, version, timestamp, your git email, and a source field (always "manual" for this command). Re-enables also add a re_enabled_at timestamp.
Confirms — evidence for the pack is generated on your next /pr run.

Output & artifacts

.claude/extensions/.enabled.json — the project’s enabled-pack and waiver registry. Example entry:
```
{
  "pack_id": "compliance/hipaa",
  "version": "1.0.0",
  "enabled_at": "2026-07-05T12:00:00Z",
  "enabled_by_email": "user@example.com",
  "source": "manual"
}
```
A re-enable adds "re_enabled_at": "<iso8601>" to the new entry while leaving the prior disabled entry untouched.
.claude/extensions/<pack-kebab>/conflict-log.md — one line per auto-resolved rule conflict
Evidence report generated on the next /pr run

Troubleshooting

Problem	Fix
`Pack {pack_id} not found`	Check the ID format is `<domain>/<name>` and run /extensions list to see available packs
`Pack {pack_id} has malformed frontmatter`	The pack’s opt-in file is missing required keys (version/restrictiveness) — fix or re-install the pack
`jq required for /extensions enable`	Install `jq` — this command manipulates JSON state
`Could not acquire lock`	Another `/extensions` command is running; if not, remove `.claude/extensions/.lock`
`Pack ... is already enabled`	Nothing to do — the command is idempotent

/extensions list — see all packs and their status
/extensions status — enabled packs with evidence freshness
/extensions disable — opt back out
/extensions waive — waive a single rule instead of the whole pack
/pr — generates the evidence report for enabled packs