devantler-tech/agent-plugins/allowed-stack-guardrail

Allowed-stack guardrail

A deployment that lets people build conversationally still has a hard boundary: only the building blocks the deployment actually operates are buildable. This skill is that boundary check. It runs before you agree to build anything, and its verdict is binding: there is no best-effort path around it. Declines are delivered in the register of the jargon-free-voice skill.

The Stack map contract

The allowed stack is deployment-owned configuration — it never ships inside this skill. The consuming deployment's canonical instructions file (AGENTS.md) defines it in a section titled exactly `## Stack map`, containing:

• A table whose rows each carry three required fields:
• Building block — the block's plain-language name;
• Good for — the needs it serves, written in the user's vocabulary (this is the matching

surface);

• Owning repo — owner/repo, where a suggested issue for that block is filed.
• A default intake repo (required, once per map) — the catch-all owner/repo that receives

the suggested issue for any need matching no row.

Read the section fresh each session; the deployment can change it at any time.

The check

1. Match conservatively. Compare the user's stated need (outcome / audience / workflow — as

elicited by the needs-stack-mapping skill) against each row's Good for purposes. Matching is semantic but conservative: only a confident match counts. Anything you cannot confidently place falls through to the unmatched path — never stretch a row to fit.

1. In-stack → proceed. A confidently matched need goes forward to be built with the matched

block(s), the deployment's way.

1. Out-of-stack or unmatched → decline and redirect. In plain language: say what you can't

build, in one friendly sentence, without technical vocabulary; then offer to put it on the deployment's wish list. With the user's consent, prepare a well-formed issue — the need as the user stated it, the outcome it serves, and why it fell outside the current building blocks. Routing follows the confidence of the match: a need that confidently concerns a mapped block yet is still out-of-stack (say, a capability that block doesn't have) is filed on that block's owning repo; every non-confident or unmatched need goes to the default intake repo — never to a merely "nearest" block, which would land out-of-stack work on an unrelated owner. The user consents to "adding it to the wish list", never to "filing an issue on a repo" — the redirect itself stays jargon-free.

Fail closed

When the ## Stack map section is absent, or malformed — no table, any row missing a required field, or no default intake repo (it is required once per map; its absence makes the whole map malformed even when every row parses) — treat every need as out-of-stack:

• Decline plainly: explain that your catalogue of what can be built here isn't available right

now, so you can't safely agree to build anything yet.

• If a default intake repo is parseable, still offer the wish-list redirect there; otherwise,

direct the user to whoever operates the deployment.

• Never infer, remember, or improvise an allowed stack, and never build "just this once" while

the map is unavailable.

Boundaries

• The guardrail gates building; it never gates conversation. Understanding the need, exploring

what the user wants, and mapping it are always allowed — only the commitment to build is gated.

• A split need (partly in-stack, partly out) proceeds only with its in-stack part; the out-of-stack

part gets the decline-and-redirect path explicitly, so nothing silently drops.

• The decline is a full answer, not an apology: what can't happen, why in one plain sentence

("that needs a kind of building block this setup doesn't have yet"), and what happens next (the wish list, and what the user can expect from it).