From 2d22165cb86dfe39e7db1530b5ddeb0384e04bcb Mon Sep 17 00:00:00 2001 From: David Abram Date: Wed, 28 Oct 2026 20:17:22 +0100 Subject: [PATCH 1/2] skills: enforce Controlled English in plans and context --- .../references/plan-authoring.md | 13 +++++++++++++ .../sce-next-task/references/context-sync.md | 12 ++++++++++++ .../references/plan-authoring.md | 13 +++++++++++++ .../sce-next-task/references/context-sync.md | 12 ++++++++++++ .../references/plan-authoring.md | 13 +++++++++++++ .../sce-next-task/references/context-sync.md | 12 ++++++++++++ .../references/plan-authoring.md | 13 +++++++++++++ .../sce-next-task/references/context-sync.md | 12 ++++++++++++ config/pkl/base/controlled-english.pkl | 17 +++++++++++++++++ config/pkl/base/workflow-change-to-plan.pkl | 6 ++++++ config/pkl/base/workflow-context-sync.pkl | 5 +++++ 11 files changed, 128 insertions(+) create mode 100644 config/pkl/base/controlled-english.pkl diff --git a/.agents/skills/sce-change-to-plan/references/plan-authoring.md b/.agents/skills/sce-change-to-plan/references/plan-authoring.md index 5b614219b..50883a4ab 100644 --- a/.agents/skills/sce-change-to-plan/references/plan-authoring.md +++ b/.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: diff --git a/.agents/skills/sce-next-task/references/context-sync.md b/.agents/skills/sce-next-task/references/context-sync.md index 807b83ffa..86cd8a166 100644 --- a/.agents/skills/sce-next-task/references/context-sync.md +++ b/.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: diff --git a/.claude/skills/sce-change-to-plan/references/plan-authoring.md b/.claude/skills/sce-change-to-plan/references/plan-authoring.md index 5b614219b..50883a4ab 100644 --- a/.claude/skills/sce-change-to-plan/references/plan-authoring.md +++ b/.claude/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: diff --git a/.claude/skills/sce-next-task/references/context-sync.md b/.claude/skills/sce-next-task/references/context-sync.md index 807b83ffa..86cd8a166 100644 --- a/.claude/skills/sce-next-task/references/context-sync.md +++ b/.claude/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: diff --git a/.opencode/skills/sce-change-to-plan/references/plan-authoring.md b/.opencode/skills/sce-change-to-plan/references/plan-authoring.md index 5b614219b..50883a4ab 100644 --- a/.opencode/skills/sce-change-to-plan/references/plan-authoring.md +++ b/.opencode/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: diff --git a/.opencode/skills/sce-next-task/references/context-sync.md b/.opencode/skills/sce-next-task/references/context-sync.md index 807b83ffa..86cd8a166 100644 --- a/.opencode/skills/sce-next-task/references/context-sync.md +++ b/.opencode/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: diff --git a/.pi/skills/sce-change-to-plan/references/plan-authoring.md b/.pi/skills/sce-change-to-plan/references/plan-authoring.md index 5b614219b..50883a4ab 100644 --- a/.pi/skills/sce-change-to-plan/references/plan-authoring.md +++ b/.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: diff --git a/.pi/skills/sce-next-task/references/context-sync.md b/.pi/skills/sce-next-task/references/context-sync.md index 807b83ffa..86cd8a166 100644 --- a/.pi/skills/sce-next-task/references/context-sync.md +++ b/.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: diff --git a/config/pkl/base/controlled-english.pkl b/config/pkl/base/controlled-english.pkl new file mode 100644 index 000000000..6834a79a0 --- /dev/null +++ b/config/pkl/base/controlled-english.pkl @@ -0,0 +1,17 @@ +title = "Controlled English for Plans and Context" + +rules = """ +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. +""" + +section = """ +## \(title) + +\(rules) +""" diff --git a/config/pkl/base/workflow-change-to-plan.pkl b/config/pkl/base/workflow-change-to-plan.pkl index 80483fa22..291ebe3b5 100644 --- a/config/pkl/base/workflow-change-to-plan.pkl +++ b/config/pkl/base/workflow-change-to-plan.pkl @@ -1,4 +1,5 @@ import "workflow-content.pkl" as model +import "controlled-english.pkl" as controlledEnglish changeToPlanSkillBody = (argumentsReference: String, invocationExample: String) -> """ # SCE Change to Plan @@ -278,6 +279,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 **\(controlledEnglish.title)** 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`. @@ -445,6 +449,8 @@ 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. +\(controlledEnglish.section) + ## Plan authoring boundaries Do not: diff --git a/config/pkl/base/workflow-context-sync.pkl b/config/pkl/base/workflow-context-sync.pkl index 415636c20..4a497767f 100644 --- a/config/pkl/base/workflow-context-sync.pkl +++ b/config/pkl/base/workflow-context-sync.pkl @@ -1,4 +1,5 @@ import "workflow-content.pkl" as workflow +import "controlled-english.pkl" as controlledEnglish local taskExecution = workflow.semanticReference.apply("`sce-task-execution`", "the **Task execution phase**") local taskExecutionName = workflow.semanticReference.apply("sce-task-execution", "Task execution phase") @@ -1336,6 +1337,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 **\(controlledEnglish.title)** + rules below. - Do not change application code, tests, or plan state. Create a new context file only when: @@ -1433,6 +1436,8 @@ 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. +\(controlledEnglish.section) + ## Task context synchronization boundaries Do not: From f874dafb21c82be1fe6b673f0d82ed0b6f6d4b56 Mon Sep 17 00:00:00 2001 From: David Abram Date: Wed, 28 Oct 2026 20:17:23 +0100 Subject: [PATCH 2/2] skills: strengthen test design during task execution --- .../references/task-execution.md | 15 +++++++++ .../references/task-execution.md | 15 +++++++++ .../references/task-execution.md | 15 +++++++++ .../references/task-execution.md | 15 +++++++++ config/pkl/base/workflow-next-task.pkl | 32 ++++++++++++++++++- 5 files changed, 91 insertions(+), 1 deletion(-) diff --git a/.agents/skills/sce-next-task/references/task-execution.md b/.agents/skills/sce-next-task/references/task-execution.md index ae68ed4c3..f5f4215c0 100644 --- a/.agents/skills/sce-next-task/references/task-execution.md +++ b/.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. diff --git a/.claude/skills/sce-next-task/references/task-execution.md b/.claude/skills/sce-next-task/references/task-execution.md index ae68ed4c3..f5f4215c0 100644 --- a/.claude/skills/sce-next-task/references/task-execution.md +++ b/.claude/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. diff --git a/.opencode/skills/sce-next-task/references/task-execution.md b/.opencode/skills/sce-next-task/references/task-execution.md index ae68ed4c3..f5f4215c0 100644 --- a/.opencode/skills/sce-next-task/references/task-execution.md +++ b/.opencode/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. diff --git a/.pi/skills/sce-next-task/references/task-execution.md b/.pi/skills/sce-next-task/references/task-execution.md index ae68ed4c3..f5f4215c0 100644 --- a/.pi/skills/sce-next-task/references/task-execution.md +++ b/.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. diff --git a/config/pkl/base/workflow-next-task.pkl b/config/pkl/base/workflow-next-task.pkl index 8f6725314..2bbc29f10 100644 --- a/config/pkl/base/workflow-next-task.pkl +++ b/config/pkl/base/workflow-next-task.pkl @@ -936,7 +936,22 @@ local renderExecutionSkillBody = (mode: model.WorkflowRenderMode) -> """ 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. @@ -1725,6 +1740,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.