Use when adding, changing, testing, or debugging Cookiecutter templates, including cookiecutter.json variables, Jinja-rendered files, hooks, _copy_without_render, optional feature cleanup, and generated-project validation.
SkillScore91Maintained
Automatic
◆Coding pack
Last verified 8/15/2026
What it changes
Passed 19 of 21 test cases with the skill, and 17 of 21 without it.
Without skill82%
With skill91%
Checks it passed that the model alone missed
The response recommends maintaining the existing string 'y'/'n' pattern for the new feature flag.
The response states that Cookiecutter aborts generation and cleans up the target directory when a hook exits with a non-zero status.
The response advises verifying the syntax and formatting of the rendered output rather than judging template source tags in isolation.
and 1 more in the full report
4 fixed16 passed either way0 still failing2 broke
Pass-rate lift
+9 pp
Tokens
+36%
Agent turns
0%
Response time
-32%
Model gemini-3.6-flashMeasured 8/15/2026v120 of 22 cases passed with skill · 21 comparable
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 4 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 4
Prompt
In our existing template's cookiecutter.json, boolean toggles are configured as 'y' and 'n' string prompts. I am adding a new feature flag `use_redis`. Should I introduce it as JSON boolean `true`/`false` or string `'y'`/`'n'`?
What was checked, without and with the skill
Checked
Without skill
With skill
The response recommends maintaining the existing string 'y'/'n' pattern for the new feature flag.
Missed
Passed
case-03 · gemini-3.6-flash · 8/15/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md107 lines2 files
Cookiecutter Template Work
Use this skill before changing a repository that has cookiecutter.json,
hooks/, or a generated project directory such as
{{ cookiecutter.project_slug }}/.
First Pass
Read the repo instructions, README.md, cookiecutter.json, existing tests,
and any hooks before editing.
Identify the template root and the generated project root. Make changes in
the template files, not in one rendered sample.
Search for the relevant Cookiecutter variables and feature flags with rg
before adding new ones.
Check how the repo validates rendered projects. Prefer existing render tests
and smoke-check commands over inventing a separate validation path.
Template Boundaries
cookiecutter.json is the user-facing interface. Every new prompt, default,
derived value, private value, and choice should be deliberate and documented
where the repo documents options.
The generated project directory may itself contain Jinja in file names and
paths. Treat both file contents and paths as render surfaces.
Follow the repo's current variable style. If it already uses y/n strings,
keep using that style for new feature flags. If it uses Cookiecutter boolean
values, keep those as real JSON booleans.
Optional features must be valid in both enabled and disabled states. Remove or
gate app files, imports, URL routes, settings, dependencies, docs, tests,
workflows, and migrations together.
Do not add maintainer-specific names, local paths, secrets, or one-agent
assumptions to generated output.
Jinja Rules
Keep rendered files valid in their target language: Python, JSON, TOML, YAML,
shell, Markdown, HTML, JavaScript, or CSS.
Watch for dangling commas after conditional blocks in JSON, TOML, Python data
structures, YAML lists, package manifests, and GitHub Actions.
Use whitespace control ({%- ... -%}) only when it improves rendered syntax