diff --git a/SKILL.md b/SKILL.md
index b2e3912..62d3bd6 100644
--- a/SKILL.md
+++ b/SKILL.md
@@ -229,7 +229,8 @@ Inspect the reference build for anything unsupported. Surface them and confirm
 with the user before proceeding.
 
 **NOT yet supported — warn the user if the project has these:**
-- Custom commands / generated code
+- Build-time custom commands / generated code. Configure-time generated
+  files are handled by you, not the tool: see the reference guide.
 - Per-test-binary identity alignment, and include search **order** (presence
   only) — both have planned follow-ups
 - Packaging / install rules
@@ -271,7 +272,7 @@ generated `.bazelrc` so a declared version that MVS overrides fails the build
 instead of being a warning nobody reads.
 
 The reference guide covers what is specific to translating its build system
-(for CMake: the build type).
+(for CMake: the build type and configure-time generated files).
 
 ### Main migration loop {#main-migration-loop}
 
diff --git a/docs/REFERENCE-cmake.md b/docs/REFERENCE-cmake.md
index db36825..37c6c98 100644
--- a/docs/REFERENCE-cmake.md
+++ b/docs/REFERENCE-cmake.md
@@ -14,8 +14,9 @@ as the reference build.
 
 When [confirming scope](../SKILL.md#confirm-scope), inspect `CMakeLists.txt`
 for these and surface them before proceeding:
-- Generated code: `configure_file`, `add_custom_command`, protoc or other
-  codegen steps.
+- Build-time generated code: `add_custom_command`, protoc or other codegen
+  steps. `configure_file` is handled by you, not the tool: see
+  [Configure-time generated files](#configure-time-generated-files).
 - `find_package` of non-system libraries. There is no automatic
   `find_package` → bzlmod resolution; each one must be mapped by hand.
 
@@ -63,6 +64,15 @@ also turns assertions off where the reference keeps them (`ndebug` in
 `diff.json`); `build --copt=-UNDEBUG` undoes the toolchain's `-DNDEBUG`, not
 one in a rule's `copts`.
 
+### Configure-time generated files
+
+For `configure_file` and probe headers, prefer a Starlark `configure_file` rule
+over the `.in` template, so the configuration stays derived. Checking in a
+probe's result is acceptable for one platform if the file says so and you
+verify it, file by file, against the configure output it came from. Never
+point Bazel at CMake's build directory: that will not rebuild from the
+repository, which is worse than migrating less.
+
 ## CMake-specific comparison notes
 
 - **Target names** in `target_map` and `exclude_targets` keys are CMake target