@@ -4,7 +4,7 @@
 
 Write notebooks to be read top-to-bottom, interleaving implementation, explanation, examples, outputs, and failure demonstrations. These conventions target published libraries; match surrounding notebooks in internal projects.
 
-Check the file, not the repo: `# AUTOGENERATED! DO NOT EDIT!` names the source notebook; `# %% ../nbs/04_usage.ipynb #a45f753a` identifies the source cell. Edit that notebook, never generated modules, `__all__`, `_modidx.py`, or module docstrings; `nbdev-export` regenerates them. Unmarked modules are hand-written. Use notebooks where narrative/examples teach the API, plain `.py` for dense mechanism iterated under pytest. Tests follow source form: lesson cells for notebooks, `tests/*.py` for plain modules.
+Check the file, not the repo: `# AUTOGENERATED! DO NOT EDIT!` names the source notebook; `# %% ../nbs/04_usage.ipynb #a45f753a` identifies the source cell. Edit that notebook, never generated modules, `__all__`, `_modidx.py`, or module docstrings; `nbdev-export` regenerates them. Unmarked modules are hand-written. Use notebooks where narrative/examples teach the API, plain `.py` for dense mechanism iterated under pytest (which should be very rare; never add pytests to a project that doesn't have any, unless explicitly requested). Tests follow source form: lesson cells for notebooks, `tests/*.py` for plain modules.
 
 For project-level questions, read `nbs/index.ipynb`, the source of README.md; regenerate with `nbdev-readme` after changes.
 
@@ -36,7 +36,7 @@
 
 Write page content, not standalone test cells (except rare hidden checks): realistic values, minimal setup, reused objects, and direct assertions that support the lesson. End lesson cells with an informative displayed value when there is something useful to show. Compact `_repr_markdown_` or structured summaries can make later examples readable; plots, tables, images, and HTML also provide evidence. Explain what matters in large outputs and keep stored results focused.
 
-Use `fastcore.test` assertions and `expect_fail` in ordinary code cells, with one focused error example per contract. Keep check plumbing, mocks, dense comprehensions, and long setup out of reader-facing examples: extract a small helper or hide the check.
+Use `fastcore.test` assertions and `expect_fail` in ordinary code cells, with one focused error example per contract. Keep check plumbing, mocks, dense comprehensions, and long setup out of reader-facing examples: extract a small helper or hide the check. Use `nbdev-test --file-re` for running >1 named notebook, since they'll run in parallel.
 
 Review these as rewrite signals, not absolute rules: