Proposal
Add a maintained hol-guard security plugin to StackOne's official Agent Plugins marketplace for developers who use local coding agents to perform state-changing StackOne operations.
The plugin/skill should directly install and invoke HOL Guard on a supported local coding-agent harness before mutation-bearing StackOne work, rather than relying on prompt-only safety guidance:
pipx install hol-guard
hol-guard detect --json
hol-guard install <detected-harness>
hol-guard run <detected-harness>
hol-guard doctor <detected-harness> --json
Guard deny/review/error/unavailable states should prevent the protected local agent from proceeding with the same state-changing action through an unprotected fallback session.
Why it fits this repository
This repository is StackOne's official plugin/skills distribution, with native Claude Code marketplace installs and npx skills add stackonehq/agent-plugins support across Agent Skills-compatible clients. It already has a security category through stackone-defender, so a focused HOL Guard runtime-safety plugin would be a maintained install surface rather than a passive catalog entry.
Useful scope includes agent-driven connector/account configuration, CLI deployment or connector changes, and other state-changing StackOne workflows. The skill can remain separate from stackone-defender: Defender scans tool results for prompt-injection/jailbreak content, while HOL Guard provides the local supported-harness policy/approval boundary before protected actions execute.
Boundaries
- HOL Guard protects the supported local coding-agent harness; it does not run inside StackOne's hosted control plane.
- StackOne authentication, account permissions, API scopes, provider controls, confirmations, and server-side validation remain authoritative.
- This should not claim dedicated HOL Guard classification for every StackOne API or CLI operation.
- Existing StackOne skills remain the workflow source of truth after the protected local agent session is established.
If this placement is useful, I can follow the repository's existing plugins/security/<name> structure and keep the implementation to the smallest repository-native plugin/skill artifact.
Disclosure: I maintain HOL Guard / Hashgraph Online. AI assistance was used to prepare this proposal; the StackOne distribution and HOL Guard execution-boundary claims were checked against the current repository README.
Proposal
Add a maintained
hol-guardsecurity plugin to StackOne's official Agent Plugins marketplace for developers who use local coding agents to perform state-changing StackOne operations.The plugin/skill should directly install and invoke HOL Guard on a supported local coding-agent harness before mutation-bearing StackOne work, rather than relying on prompt-only safety guidance:
Guard deny/review/error/unavailable states should prevent the protected local agent from proceeding with the same state-changing action through an unprotected fallback session.
Why it fits this repository
This repository is StackOne's official plugin/skills distribution, with native Claude Code marketplace installs and
npx skills add stackonehq/agent-pluginssupport across Agent Skills-compatible clients. It already has asecuritycategory throughstackone-defender, so a focused HOL Guard runtime-safety plugin would be a maintained install surface rather than a passive catalog entry.Useful scope includes agent-driven connector/account configuration, CLI deployment or connector changes, and other state-changing StackOne workflows. The skill can remain separate from
stackone-defender: Defender scans tool results for prompt-injection/jailbreak content, while HOL Guard provides the local supported-harness policy/approval boundary before protected actions execute.Boundaries
If this placement is useful, I can follow the repository's existing
plugins/security/<name>structure and keep the implementation to the smallest repository-native plugin/skill artifact.Disclosure: I maintain HOL Guard / Hashgraph Online. AI assistance was used to prepare this proposal; the StackOne distribution and HOL Guard execution-boundary claims were checked against the current repository README.