diff --git a/docs/skills/pytesting/SKILL.md b/docs/skills/pytesting/SKILL.md
index 3ab56ba..edffd6d 100644
--- a/docs/skills/pytesting/SKILL.md
+++ b/docs/skills/pytesting/SKILL.md
@@ -16,9 +16,9 @@ x-personal-mcp:
     - resource://skills/pytesting/document
 ---
 
-# Pytest Scaffolding
+# Pytesting
 
-This skill is a collection of best-practice references and source-documentation links for building and maintaining pytest suites.
+This skill is a collection of preferences and links to source documentation for building and maintaining pytest suites.
 
 Use it to quickly find the right guidance for:
 1. Baseline pytest structure and marker strategy.
@@ -67,7 +67,16 @@ Always consult [naming-and-organization.md](./references/naming-and-organization
 3. The request mentions conventions, readability, hierarchy, or discoverability.
 4. The task introduces parametrization where case naming affects failure readability.
 
-## Baseline Best Practices
+## Guiding Principles
+
+These principles are abstract, but are the highest priority to follow.
+
+- Much of testing is very well-trodden. In general, tests should follow whatever conventions there are.
+- Tests will be run very frequently, so it's important that they run quickly and deterministically.
+- When tests fail, it should be easy to determine what failed and fix it.
+- Always be on guard against tests that are tautological. Every test should provide specific value by capturing something about the intent of the program.
+
+## Pytest Best Practices
 
 These are stable defaults regardless of stack:
 
@@ -86,9 +95,7 @@ These are stable defaults regardless of stack:
 
 ## Universal Test Double Policy (Repo-Local Placement)
 
-Treat this policy as universal guidance for test authoring, while it is documented in this repository-local skill file for now.
-
-Apply this policy whenever a test change introduces a fake collaborator or patched behavior:
+To avoid over-using monkeypatching, mocks, fakes, etc, apply this policy whenever a test change introduces one of them:
 
 1. Attempt a real-input, real-object test design first.
 2. If that approach is impractical, explain why and request user confirmation before adding monkeypatching, mocks, or fakes.