How to use the Secrets Management for CI/CD agent skill

What does the secrets-management skill make the agent do?

The skill's source describes secure secrets management for CI/CD pipelines using HashiCorp Vault, AWS Secrets Manager, and other tools. Its stated purpose is to implement this without hardcoding sensitive information. When the skill is active, the agent can draw on its guidance for storing API keys and database passwords, handling TLS certificates, rotating secrets and applying least-privilege access.

The file also covers Azure Key Vault and Google Secret Manager as native alternatives, and shows how GitHub Actions, GitLab CI and Kubernetes (via the External Secrets Operator) can read secrets at run time. It includes a best-practices list, a manual rotation outline, an AWS rotation Lambda example and a TruffleHog secret-scanning example.

• Draft setup steps and configuration for HashiCorp Vault or AWS Secrets Manager
• Show how a pipeline job can import secrets as environment variables
• Provide a checklist of practices such as masking secrets in logs and never committing them to Git
• Offer a pre-commit hook and CI job that scan for leaked secrets

How do you install the secrets-management skill?

Download the ZIP file for this skill from this page. The skill is distributed as a single file, SKILL.md. Unzip it so that the skill folder ends up in one of two places: your personal skills folder at ~/.claude/skills/, or a project-specific folder at .claude/skills/ inside your project. A personal install applies to all your work, while a project install applies only to that repository.

If you use the Claude apps instead, open Settings, go to Capabilities, then Skills, and upload the skill there.

• Personal install: ~/.claude/skills/
• Project install: .claude/skills/ inside your project
• Claude apps: Settings → Capabilities → Skills, then upload

How do you trigger the skill with a natural request?

You do not need a special command. Describe the task in plain language and mention the relevant concern, such as credentials, rotation, or securing your pipeline. The skill's description says it applies when handling sensitive credentials, rotating secrets, or securing CI/CD environments, so requests that match those topics are the ones it is meant to help with.

Name your tools and CI system where you can. Saying 'GitHub Actions' or 'Vault' helps the agent pick the matching section of the guide.

• "Help me move our database password out of the GitHub Actions workflow and into Vault."
• "Review how our GitLab CI job gets its API key and suggest improvements."
• "Write a secret-rotation outline for our production database credentials."
• "Add a pre-commit check that stops us committing API keys."

What examples does the skill include?

The source includes a Vault setup sequence using a dev server, a GitHub Actions workflow that imports secrets with the hashicorp/vault-action, a GitLab CI job that reads values with the vault CLI, and AWS Secrets Manager commands that create a secret and read it in a workflow. It also shows a Terraform data source for an AWS secret, GitHub and GitLab variable usage, and a Kubernetes SecretStore and ExternalSecret pair.

Treat these as starting templates. Several examples use placeholder values, a dev-mode Vault server and a root token, which the source itself makes clear are for testing.

What does the skill need before you use it?

The skill itself only supplies guidance. To act on it you need the tools it refers to: a HashiCorp Vault or an AWS, Azure or GCP secret manager account where applicable, and credentials such as AWS credentials or a Vault token that you provide yourself. The TruffleHog pre-commit example requires Docker. The pipeline examples assume GitHub Actions or GitLab CI, depending on what you use.

The skill does not run scripts on its own, but it does involve network use: the examples call external services such as your Vault server or AWS.

• Secret manager account (Vault, AWS, Azure or GCP) where applicable
• Your own AWS credentials or Vault token
• Docker, for the TruffleHog pre-commit example
• GitHub Actions or GitLab CI

What safety points should you check first?

Do not use the examples in production as written. The source's dev server, root token and plaintext password example are for testing only. Review every value, replace placeholders, and confirm that secrets are not echoed into logs. The skill is a general guide and does not verify your specific setup, so it is not an audited security solution.

The examples also pass secrets through shell variables and, in one AWS case, into GITHUB_ENV, so check how your job handles them. Use the masking and protected-variable options your CI platform provides.

• Replace the dev server and root token before any real use
• Never commit secrets; the pre-commit example is a starting point
• Use different secrets for each environment
• Review generated code before running it against live systems

What tips help you get the most from it?

Start with the best-practices list and check your current pipeline against it. Ask the agent to point out where you hardcode credentials, then work through one secret at a time. Pair this skill with the related skills the source names when you need deeper pipeline design help.

For rotation, follow the manual outline (generate, update the store, update applications, verify, revoke the old secret) and test it in a non-production environment first.

• Work through the 10 best practices in order of risk for your pipeline
• Related skills named in the source: github-actions-templates, gitlab-ci-patterns, deployment-pipeline-design