Request
Would Clerk be open to a maintained Agent Skill/reference that directly installs and invokes HOL Guard before state-changing Clerk work performed through a supported local coding-agent harness?
The most useful placement seems close to clerk-cli, because that skill can mutate users, organizations, applications, environment keys, and deployment configuration. A dedicated clerk-hol-guard skill or a maintained runtime-safety path routed from clerk-cli would both work; happy to follow the maintainers' preferred structure.
Proposed behavior
For mutation-bearing Clerk workflows, the maintained skill would use the real HOL Guard runtime rather than generic security prose:
pipx install hol-guard
hol-guard detect --json
hol-guard bootstrap
hol-guard install <detected-harness>
hol-guard run <detected-harness> --dry-run
hol-guard run <detected-harness>
hol-guard doctor <detected-harness> --json
hol-guard status
The exact harness identifier should come from hol-guard detect --json, not a hand-maintained alias list. If the dry run, launch, doctor, or status cannot prove protection, the skill should stop the state-changing Clerk operation rather than silently fall back to an unprotected agent session.
Boundaries
HOL Guard would be only the local agent-runtime boundary. Clerk permissions, authentication, Dashboard/API controls, repository review, tests, and any provider-side safeguards remain authoritative. This would not claim server-side interception or replace Clerk-native controls.
If this placement makes sense, I can contribute the smallest repository-conformant PR and follow the existing validation/review process.
Request
Would Clerk be open to a maintained Agent Skill/reference that directly installs and invokes HOL Guard before state-changing Clerk work performed through a supported local coding-agent harness?
The most useful placement seems close to
clerk-cli, because that skill can mutate users, organizations, applications, environment keys, and deployment configuration. A dedicatedclerk-hol-guardskill or a maintained runtime-safety path routed fromclerk-cliwould both work; happy to follow the maintainers' preferred structure.Proposed behavior
For mutation-bearing Clerk workflows, the maintained skill would use the real HOL Guard runtime rather than generic security prose:
The exact harness identifier should come from
hol-guard detect --json, not a hand-maintained alias list. If the dry run, launch, doctor, or status cannot prove protection, the skill should stop the state-changing Clerk operation rather than silently fall back to an unprotected agent session.Boundaries
HOL Guard would be only the local agent-runtime boundary. Clerk permissions, authentication, Dashboard/API controls, repository review, tests, and any provider-side safeguards remain authoritative. This would not claim server-side interception or replace Clerk-native controls.
If this placement makes sense, I can contribute the smallest repository-conformant PR and follow the existing validation/review process.