agentleFS
Sign inStart free
felirangelpfelirangelp/harness-driven-dev/.claude/skills/fix-secret/SKILL.md

fix-secret

Skill15 starsChanged 6 months agoMITView on GitHub

Resolve a commit blocked by gitleaks — move the secret to .env, ask the user to populate it, and WAIT for confirmation before retrying the commit

  • Reads credentials

The file

We split this skill into the rules it gives an agent

9 rules. About 0 are common, 3 are distinctive, and 6 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈3

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 6

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  • could be automatic: a setting could enforce it
  1. Distinctive:

    Use this skill whenever a git commit is blocked by the gitleaks pre-commit hook because a secret was hardcoded in source code.

    line 11
  2. Distinctive:

    Identify the secret: Read the gitleaks output — file, line, and RuleID.

    line 16
  3. Very specific:

    Remove it from the code: Delete the hardcoded value.

    line 19
  4. Very specific:

    Document the variable: Make sure .env.example lists the variable name with a placeholder value — never the real one.

    line 24
  5. Very specific:

    NEVER read, write, or create .env yourself — the user owns secrets.

    line 29
  6. Very specific:

    WAIT for explicit confirmation: Do NOT retry the commit and do NOT continue with any other step until the user confirms .env is ready (e.g.

    line 31
  7. Distinctive:

    Retry the commit: only after the user confirms.

    line 36
  8. Very specific:

    NEVER commit a secret, even with --no-verify.

    line 43
  9. Very specific:

    NEVER touch .env — reading, writing, or creating it.

    line 45

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Fix Secret

Use this skill whenever a git commit is blocked by the gitleaks pre-commit hook because a secret was hardcoded in source code.

Steps

  1. Identify the secret: Read the gitleaks output — file, line, and RuleID. Confirm what kind of secret it is (API key, token, password).
  2. Remove it from the code: Delete the hardcoded value. Refactor the code to read the value from an environment variable (e.g. process.env.LINEAR_API_KEY). Keep the real connection code so there is something meaningful to commit.
  3. Document the variable: Make sure .env.example lists the variable name with a placeholder value — never the real one.
  4. STOP — hand off to the user. Tell the user the exact variable name to set and ask them to add the real value to the .env file. NEVER read, write, or create .env yourself — the user owns secrets.
  5. WAIT for explicit confirmation. Do NOT retry the commit and do NOT continue with any other step until the user confirms .env is ready (e.g. "listo", "ya está", "done"). This pause is MANDATORY — never assume .env is configured.
  6. Retry the commit only after the user confirms. gitleaks now passes because the code is clean.
  7. Continue the normal flow (push → PR → /close-issue).

Rules

  • NEVER commit a secret, even with --no-verify. The CI gitleaks job would catch it anyway and the secret would land in git history.
  • NEVER touch .env — reading, writing, or creating it. The user manages all secret values.
  • Step 5 is non-negotiable: WAIT for the user's confirmation before retrying the commit. Do not assume the flow will succeed.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free