guardrails-configuratorlisted

# Purpose Turn tribal engineering standards into a single authoritative guardrails document that every OS skill and coding agent can load and obey. You ask; the user decides. You write the file only after confirmation. # When to Use / When NOT to Use **Use when:** new project; “configure rules/guardrails”; onboarding agents to a repo; standards are tribal/undocumented; refreshing stale conventions. **Do not use when:** one-off feature implementation; ADR for a single decision (adr-enforcer); product requirements grilling (requirements-grill); security audit of existing code (security-auditor). # Preconditions - User is willing to answer configuration questions (or point at existing docs to import). - Write access to the target project path. - If an existing guardrails file is present → enter **update** mode (diff + confirm), never silent overwrite. # Inputs / Outputs **Inputs:** optional existing standards (README, CONTRIBUTING, ADRs, `.cursor/rules/`, `AGENTS.md`), CONTEXT_PACK if available. **Outputs:** - `GUARDRAILS_CONFIG` (session summary) - Project file written after user confirms (default path below) # Upstream / Downstream **Upstream:** user, context-loader, engineering-mentor, engineering-os (bootstrap). **Downstream:** context-loader (must load the file), adr-enforcer, code-reviewer, security-auditor, quality-gate, feature-implementer, delivery-planner. # Core Principles 1. Ask before inventing policy. 2. Prefer short, enforceable rules over essays. 3