skills: Extract Controlled English and test-design guidance

.agents/skills/sce-change-to-plan/references/plan-authoring.md

@@ -32,6 +32,9 @@ Read its `Acceptance criteria rules`, `Task rules` and `No validation task` rule
 and `Updating an existing plan` rules before authoring or revising. Apply those
 rules rather than restating them here.
 
+Apply the **Controlled English for Plans and Context** rules
+below to new or revised plan prose, both when authoring and revising.
+
 The workflow renders this phase's result as the summary defined in
 `references/output.md`.
 
@@ -199,6 +202,16 @@ Write user-facing questions and open questions directly and specifically.
 - Do not invent concerns, add praise or reassurance, or repeat the same concern in several forms.
 - When the user overrules a concern, record the decision and continue. Do not reintroduce it as a constraint, non-goal, or task.
 
+## Controlled English for Plans and Context
+
+Apply these rules to new or modified prose in SCE plans and durable context. Preserve Markdown structure, code, commands, identifiers, technical terminology, factual meaning, and existing task evidence. Do not rewrite unrelated content solely for style.
+
+1. Sentence structure: Use a maximum of 20 words per procedural sentence and 25 words per descriptive sentence, counted according to STE rules. Give one instruction per sentence, using imperative form and placing prerequisites first. Limit ordinary multi-word nouns to three words. Keep one topic and at most six sentences per descriptive paragraph. Do not use contractions or semicolons. Use active voice, except when the actor is unknown in descriptive text.
+
+2. Vocabulary: Prefer STE-approved words and established domain terminology. Use terms consistently and preserve their technical meanings.
+
+3. Verbs: Use simple present, simple past, simple future, and imperative forms. Avoid perfect and progressive constructions. Use "can" for possibility, ability, or permission, "must" for obligation, and "will" for future events. Replace "may", "should", "shall", and "would" with appropriate constructions. Use "could" only for past ability or permission.
+
 ## Plan authoring boundaries
 
 Do not:

.agents/skills/sce-next-task/references/context-sync.md

@@ -214,6 +214,8 @@ When editing context:
 - Update cross-references when files are added, moved, renamed, or superseded.
 - Keep one authoritative statement for each durable fact.
 - Avoid copying the execution result verbatim into context files.
+- Write new or modified prose under the **Controlled English for Plans and Context**
+  rules below.
 - Do not change application code, tests, or plan state.
 
 Create a new context file only when:
@@ -311,6 +313,16 @@ Record only the Markdown report. Do not add explanatory prose before or after it
 Do not determine whether the plan is complete. The `/next-task` workflow owns
 that decision after context synchronization.
 
+## Controlled English for Plans and Context
+
+Apply these rules to new or modified prose in SCE plans and durable context. Preserve Markdown structure, code, commands, identifiers, technical terminology, factual meaning, and existing task evidence. Do not rewrite unrelated content solely for style.
+
+1. Sentence structure: Use a maximum of 20 words per procedural sentence and 25 words per descriptive sentence, counted according to STE rules. Give one instruction per sentence, using imperative form and placing prerequisites first. Limit ordinary multi-word nouns to three words. Keep one topic and at most six sentences per descriptive paragraph. Do not use contractions or semicolons. Use active voice, except when the actor is unknown in descriptive text.
+
+2. Vocabulary: Prefer STE-approved words and established domain terminology. Use terms consistently and preserve their technical meanings.
+
+3. Verbs: Use simple present, simple past, simple future, and imperative forms. Avoid perfect and progressive constructions. Use "can" for possibility, ability, or permission, "must" for obligation, and "will" for future events. Replace "may", "should", "shall", and "would" with appropriate constructions. Use "could" only for past ability or permission.
+
 ## Task context synchronization boundaries
 
 Do not:

.agents/skills/sce-next-task/references/task-execution.md

@@ -113,6 +113,21 @@ checks.
 
 Use judgment for ordinary, reversible local implementation choices.
 
+When writing or modifying tests:
+
+1. Before implementing, identify likely subtle bugs, mistakes, and
+   alternative interpretations. Design tests that distinguish them,
+   preferring asymmetric examples and boundary cases on both sides.
+
+2. After implementing, independently derive expected results for high-risk
+   cases from the requirements, without using production code or helpers.
+   Compare these expectations with actual results, using fresh context when
+   available.
+
+3. When feasible, use property-based tests or structured random inputs to
+   explore meaningful states and code paths. Avoid random tests that only
+   check for crashes or repeatedly exercise the same error path.
+
 Stop when implementation requires:
 
 - Material scope expansion.

.pi/skills/sce-change-to-plan/references/plan-authoring.md

@@ -32,6 +32,9 @@ Read its `Acceptance criteria rules`, `Task rules` and `No validation task` rule
 and `Updating an existing plan` rules before authoring or revising. Apply those
 rules rather than restating them here.
 
+Apply the **Controlled English for Plans and Context** rules
+below to new or revised plan prose, both when authoring and revising.
+
 The workflow renders this phase's result as the summary defined in
 `references/output.md`.
 
@@ -199,6 +202,16 @@ Write user-facing questions and open questions directly and specifically.
 - Do not invent concerns, add praise or reassurance, or repeat the same concern in several forms.
 - When the user overrules a concern, record the decision and continue. Do not reintroduce it as a constraint, non-goal, or task.
 
+## Controlled English for Plans and Context
+
+Apply these rules to new or modified prose in SCE plans and durable context. Preserve Markdown structure, code, commands, identifiers, technical terminology, factual meaning, and existing task evidence. Do not rewrite unrelated content solely for style.
+
+1. Sentence structure: Use a maximum of 20 words per procedural sentence and 25 words per descriptive sentence, counted according to STE rules. Give one instruction per sentence, using imperative form and placing prerequisites first. Limit ordinary multi-word nouns to three words. Keep one topic and at most six sentences per descriptive paragraph. Do not use contractions or semicolons. Use active voice, except when the actor is unknown in descriptive text.
+
+2. Vocabulary: Prefer STE-approved words and established domain terminology. Use terms consistently and preserve their technical meanings.
+
+3. Verbs: Use simple present, simple past, simple future, and imperative forms. Avoid perfect and progressive constructions. Use "can" for possibility, ability, or permission, "must" for obligation, and "will" for future events. Replace "may", "should", "shall", and "would" with appropriate constructions. Use "could" only for past ability or permission.
+
 ## Plan authoring boundaries
 
 Do not:

.pi/skills/sce-next-task/references/context-sync.md

@@ -214,6 +214,8 @@ When editing context:
 - Update cross-references when files are added, moved, renamed, or superseded.
 - Keep one authoritative statement for each durable fact.
 - Avoid copying the execution result verbatim into context files.
+- Write new or modified prose under the **Controlled English for Plans and Context**
+  rules below.
 - Do not change application code, tests, or plan state.
 
 Create a new context file only when:
@@ -311,6 +313,16 @@ Record only the Markdown report. Do not add explanatory prose before or after it
 Do not determine whether the plan is complete. The `/next-task` workflow owns
 that decision after context synchronization.
 
+## Controlled English for Plans and Context
+
+Apply these rules to new or modified prose in SCE plans and durable context. Preserve Markdown structure, code, commands, identifiers, technical terminology, factual meaning, and existing task evidence. Do not rewrite unrelated content solely for style.
+
+1. Sentence structure: Use a maximum of 20 words per procedural sentence and 25 words per descriptive sentence, counted according to STE rules. Give one instruction per sentence, using imperative form and placing prerequisites first. Limit ordinary multi-word nouns to three words. Keep one topic and at most six sentences per descriptive paragraph. Do not use contractions or semicolons. Use active voice, except when the actor is unknown in descriptive text.
+
+2. Vocabulary: Prefer STE-approved words and established domain terminology. Use terms consistently and preserve their technical meanings.
+
+3. Verbs: Use simple present, simple past, simple future, and imperative forms. Avoid perfect and progressive constructions. Use "can" for possibility, ability, or permission, "must" for obligation, and "will" for future events. Replace "may", "should", "shall", and "would" with appropriate constructions. Use "could" only for past ability or permission.
+
 ## Task context synchronization boundaries
 
 Do not:

.pi/skills/sce-next-task/references/task-execution.md

@@ -113,6 +113,21 @@ checks.
 
 Use judgment for ordinary, reversible local implementation choices.
 
+When writing or modifying tests:
+
+1. Before implementing, identify likely subtle bugs, mistakes, and
+   alternative interpretations. Design tests that distinguish them,
+   preferring asymmetric examples and boundary cases on both sides.
+
+2. After implementing, independently derive expected results for high-risk
+   cases from the requirements, without using production code or helpers.
+   Compare these expectations with actual results, using fresh context when
+   available.
+
+3. When feasible, use property-based tests or structured random inputs to
+   explore meaningful states and code paths. Avoid random tests that only
+   check for crashes or repeatedly exercise the same error path.
+
 Stop when implementation requires:
 
 - Material scope expansion.