Harden Your .claude Directory: Permissions, a Skill, and a Hook That Fires
Take a small repo with real hazards planted in it (a secret .env, a destructive deploy script) and lock down its .claude directory so Claude Code is safe to run loose: deny rules for the dangerous operations, a reusable skill, and a PreToolUse hook that actually blocks writes to the secret file. Prove the hook fires and submit your .claude setup for instant, rubric-based feedback.
1.3 hrs
Est. time
3
Outcomes
6
Rubric criteria
65%
Pass score
What you'll learn
Skills you'll have real reps in after shipping this.
The scenario
You are dropping Claude Code into a real repo and you want it to move fast without being able to do damage. The repo has the usual landmines: a .env full of live-looking secrets, a deploy.sh that force-pushes to prod, a script that wipes local data. Out of the box, a confidently wrong agent can touch all of them.
This task is that setup, hardened for real. You configure the project's .claude directory so the hazards are denied, a common workflow is one reusable skill instead of a paragraph of instructions, and a PreToolUse hook physically blocks any attempt to write the secret file. You do not just describe the config: a local self-check runs your actual hook and only writes your proof-of-work evidence when it genuinely blocks the .env write.
Your role
You are the engineer who owns how Claude Code is configured for a repo. Your deliverable is a hardened .claude directory (permissions, a skill, a working hook) plus machine-generated evidence that the hook fires, packaged as a single submission.
Start the task to unlock the full brief
You'll get the step-by-step requirements, setup commands, the 6-criterion grading rubric, tips, and the ability to submit your solution for instant AI grading.
Free to start · submit when you're ready
Lock down Claude Code in a real repo, hands-on
Permissions, skills, and hooks are how you turn Claude Code from a generic agent into a safe, repo-specific collaborator, and this task makes you wire all three for real. You start from a small app with hazards planted in it (a secret .env, a destructive deploy script) and harden its .claude directory until a local self-check runs your actual PreToolUse hook and confirms it blocks the secret write while leaving ordinary edits alone. You come away with a hardening pattern (deny rules as declared policy, a hook as executable enforcement, a skill as a reusable workflow) and machine-generated proof that your guard rails actually fire, not just a description of them.