439-deployment-config

Deployment rules and a shell check for finding the Google Cloud command-line tool and validating the deployment environment and credentials.

In plain words
What is it for?
Use them before deploying to Google Cloud. They cover tool discovery, credential selection, environment confirmation, and basic command validation. The input does not provide enough detail to describe the full deployment process.
Why use it?
They help prevent deployments from using missing tools, the wrong environment, or invalid credentials.

Cursor rule

Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

agentmods
npx agentmods add rules/hamzaamjad/cursor-rules/439-deployment-config
Clone the repo
git clone --depth 1 https://github.com/hamzaamjad/cursor-rules
Per session 0 Nothing until a file matches its globs; then the whole rule loads.
When invoked 665 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

ModelPer sessionOnce invoked
Fable 5 $0.00000 $0.00665
Opus 5 $0.00000 $0.00332
Sonnet 5 $0.00000 $0.00133
Haiku 4.5 $0.00000 $0.00067

Measured 2d ago against content hash dc3c112239ea, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

439-deployment-config scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

rules/400-patterns/439-deployment-config.mdc · 67 lines

What it actually says

deployment-config.mdc

  • Purpose: To ensure reliable deployment processes by establishing standard protocols for tool discovery, credential management, and environment validation. Empirical Impact: Projects following these protocols show 60% fewer deployment failures and 40% faster resolution times.

  • Requirements:

    • Tool Discovery Protocol:
      • Search standard tool locations systematically: ~/bin, ~/google-cloud-sdk/bin, /usr/local/bin, /opt/homebrew/bin
      • Use find command for comprehensive search: find /Users/$USER -name "tool_name" -type f 2>/dev/null
      • Verify tool functionality with --version or --help before proceeding
      • Document discovered tool paths for future reference
    • Credential Management:
      • Prioritize user-provided credential files over hardcoded values
      • Support multiple environments (sandbox, staging, production) in single config file
      • Use environment-specific sections: {"production": {...}, "sandbox": {...}}
      • Validate credentials before deployment operations
    • Environment Validation:
      • Explicitly confirm target environment before state-changing operations
      • Display environment context in deployment outputs
      • Use environment-specific naming conventions (e.g., service-name-prod vs service-name-sandbox)
      • Implement health checks with environment identification
  • Validation:

    • Check: Are tools discovered systematically before use?
    • Check: Are environment-specific credentials loaded correctly?
    • Check: Is target environment explicitly confirmed?
    • Check: Do deployments include environment validation?
  • Examples:

    • Tool Discovery:
      # Systematic tool search
      GCLOUD_PATH=$(find /Users/$USER -name "gcloud" -type f 2>/dev/null | head -1)
      if [ -z "$GCLOUD_PATH" ]; then
          echo "❌ gcloud not found, please install Google Cloud SDK"
          exit 1
      fi
      echo "✅ Found gcloud at: $GCLOUD_PATH"
      
    • Environment Validation:
      # Environment confirmation
      echo "🎯 Target Environment: $ENVIRONMENT"
      echo "🔑 Using credentials for: $ENVIRONMENT"
      read -p "Proceed with deployment to $ENVIRONMENT? (y/N): " confirm
      
  • Integration Notes:

    • Works with stepwise-autonomy for deployment verification
    • Enhances risk-checkpoint by validating deployment targets
    • Supports multi-environment configuration patterns
  • Changes: Initial implementation v1.0.0 based on Ascend integration deployment challenges.

  • Source References:

    • Ascend Integration Task Retrospective (2025-01-02)
    • Google Cloud Deployment Best Practices
    • Multi-Environment Configuration Patterns
Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

  1. 2d ago First seen · 67 lines · 0 tokens per session scan A dc3c112239ea

Subscribe to this mod's changes

439-deployment-config is a cursor rule published in the GitHub repository hamzaamjad/cursor-rules (2 stars, last pushed 1y ago), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 665 tokens. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.