Skill prompt optimization

.github/agents/compiler-perf-investigator.md

@@ -24,14 +24,14 @@ These are **general investigation instructions** for this agent, a template for
 
 ## Absolute Requirements
 
-- **Always use** a fresh, local F# compiler and FSharp.Core where possible. Log full paths and proof the correct compiler is used.
+- **When a fresh, local F# compiler and FSharp.Core can be prepared, use them.** Log full paths and proof the correct compiler is used; otherwise record why they could not be used.
 - **Matrix over** Debug/Release and ParallelCompilation on/off.
 - **For each build and analysis step:**
   - Record all commands, timings, and results.
   - Log all intermediate results (e.g., hot call stacks, wallclock timings, error messages) to `HOT_PATHS.md` as they are found.
 - **For every hypothesis or question:** 
   - State it in `HYPOTHESIS.md` and update with status (untested/confirmed/denied) and pointers to relevant runs/artifacts.
-- **Primary artifact must be** clear, actionable, human-written text in `INSIGHTS.md`—this should summarize what the agent has learned, not just what it ran.
+- **Primary artifact must be** clear, actionable prose for humans in `INSIGHTS.md`—this should summarize what the agent has learned, not just what it ran.
 
 ---
 
@@ -64,7 +64,7 @@ Record:
 - **HYPOTHESIS.md:** Maintain numbered/dated hypotheses about causes, behaviors, or fixes.  
   - Mark each as untested/confirmed/denied (and why/where).
   - Reference experimental runs or insights which test them.
-  - Never re-run a denied or already confirmed hypothesis: record, cross-reference, and always consult HYPOTHESIS.md on starting or resuming work.
+  - Do not re-run a denied or already confirmed hypothesis unless the hypothesis or scenario materially changes. Record and cross-reference it, and consult HYPOTHESIS.md when starting or resuming work.
 
 ### 5. Insights as Product
 
@@ -84,7 +84,7 @@ Record:
 
 ### 7. Best Practices
 
-- **If agent is interrupted:** On restart, consult `TODO.md`, `HYPOTHESIS.md`, and `INSIGHTS.md` to resume exactly where left off—never duplicate work and always cross-check hypotheses.
+- **If agent is interrupted:** On restart, consult `TODO.md`, `HYPOTHESIS.md`, and `INSIGHTS.md` to resume where work stopped. Do not duplicate work; cross-check hypotheses first.
 - **If insight contradicts previous belief:** Update both `INSIGHTS.md` and point back to affected hypotheses.
 - **If a hypothesis is tested and denied,** record why and what observation/finding proves it false (with links/log references).
 - **If unable to explain a result with current hypotheses,** propose a new one and add it as untested.
@@ -122,7 +122,7 @@ Record:
 3. Update hypothesis status in HYPOTHESIS.md
 4. Formulate/publish a new insight if progress is made
 5. Set new TODO in TODO.md, and finish session
-6. On any restart, agent must consult all MD files to avoid redundancy and repeat work only if hypothesis or scenario materially changes.
+6. On any restart, consult all investigation MD files to avoid redundancy; repeat work only if the hypothesis or scenario materially changes.
 
 ---
 
@@ -141,6 +141,6 @@ At the end of an investigation, the primary deliverables are:
 
 **This is an insight and hypothesis-driven agent for F# build perf analysis.  
 Its mission is to extract and publish meaningful, durable understanding—not just build logs or raw data.  
-The workflow is always resumable, transparent, and maximally reusable for community and future agents.**
+The workflow remains resumable and transparent, with commands, evidence, and reusable tools preserved for the community and future agents.**
 
 ---

.github/agents/expert-reviewer.md

@@ -431,7 +431,7 @@ New features must be gated behind language version checks. Breaking changes requ
 
 ## Review Workflow
 
-Execute review in five waves, each building on the previous.
+Execute review in six waves, each building on the previous.
 
 ### Wave 0: Orientation & Dimension Dispatch
 

.github/agents/extraction-pipeline.md

@@ -35,7 +35,7 @@ This pipeline processes **thousands** of GitHub items (typically 3,000–10,000+
 
 **Context management:** Store all intermediate results in **SQLite** (queryable) and **JSON backup files** (recoverable). Sub-agents write results to files; the orchestrator imports into SQLite and dispatches the next phase. Never pass large datasets through agent context — use the filesystem.
 
-**Model selection:** Use the best available reasoning model (e.g., `claude-opus-4.6`) for classification and synthesis sub-agents. Fast/cheap models produce shallow rules. Collection sub-agents can use standard models. Use background mode so agents run in parallel.
+**Model selection:** Use GPT-5.6 Sol for classification and synthesis sub-agents. Fast/cheap models produce shallow rules. Collection sub-agents can use standard models. Use background mode so agents run in parallel.
 
 **Reliability:** After each batch of sub-agents completes, validate output files: >500 bytes, parseable JSON, contains entries for all assigned items. Re-dispatch incomplete outputs up to 3 times. Keep batch assignments to ≤5 batches per agent — agents given too much work produce placeholders or give up.
 
@@ -182,7 +182,7 @@ Store feature areas in SQLite: `CREATE TABLE feature_areas (area_name TEXT, fold
 > **Output:** SQLite `comment_analysis` table, `taxonomy.json`
 > **Context per sub-agent:** taxonomy + CI summary + 15 PR packets (all comments on each PR)
 
-For each collected comment, classify using a sub-agent (Opus). **Do not use a hardcoded category list** — derive categories from the data:
+For each collected comment, classify using a GPT-5.6 Sol sub-agent. **Do not use a hardcoded category list** — derive categories from the data:
 
 1. **Bootstrap pass**: Take a stratified sample of ~300 comments: proportional by year, at least 5 per major feature area from §2.1, and at least 20 each of review_comments, pr_descriptions, and issue_comments. Ask a sub-agent to read them and propose a category taxonomy. The agent should identify recurring themes, name them, and define each in one sentence. Expect 15–40 categories to emerge. After deriving the taxonomy, cross-check it against the feature area table — if any area representing >10% of the codebase has zero categories, re-sample with enforced coverage.
 
@@ -223,7 +223,7 @@ This ensures a PR with 50 comments gets weight=1, same as a PR with 1 comment. T
 
 ### 2.3 Clustering
 
-> **Sub-agents:** 1 (Opus, synthesis)
+> **Sub-agents:** 1 (GPT-5.6 Sol, synthesis)
 > **Input:** `pr_rule_votes` table, `taxonomy.json`, `feature_areas` table, `ci_summary.txt`
 > **NOT available:** raw `user_comments`, JSON backups — synthesis works only with classified, deduplicated data
 > **Output:** `dimensions.json`, `principles.json`, `folder_hotspots.json`, SQLite `dimension_evidence` table
@@ -509,4 +509,3 @@ Final check on the complete artifact set:
 - Every CHECK item is phrased as a generalizable principle, not a transcription of one PR's feedback
 - Dimension frequency was counted by PRs, not by comments — a PR with 50 comments counts the same as one with 1 comment
 
-

.github/agents/fsharp-generic.md

@@ -40,14 +40,14 @@ async { let! x = op(); return x }
 ```
 
 ## Rules
-DO Option for absence. DON'T null.
-DO Result for expected errors. DON'T exceptions in F# APIs.
-DO immutable default. DON'T mutable default.
-DO pattern match. DON'T if-else chains.
-DO modules + functions. DON'T methods on records.
-DO [<RequireQualifiedAccess>]. DON'T [<AutoOpen>] (except CE builders).
-DO explicit .fsi for public API. DON'T implicit surface.
-DO PascalCase: types, modules, fields. DO camelCase: functions, values, params.
+Use Option for absence instead of null.
+Use Result for expected errors instead of exceptions in F# APIs.
+Prefer immutable values; use mutable values only when required.
+Prefer pattern matching over if-else chains.
+Prefer modules and functions over methods on records.
+Use [<RequireQualifiedAccess>]; avoid [<AutoOpen>] except for CE builders.
+Define public APIs explicitly in .fsi files rather than using an implicit surface.
+Use PascalCase for types, modules, and fields. Use camelCase for functions, values, and parameters.
 
 ## Domain modeling
 

.github/instructions/NoBloat.instructions.md

@@ -13,7 +13,7 @@ Reviewers read code, not prose. Add bytes only when they pay for themselves.
 
 ## Comments
 
-Good names **always** beat comments. Before writing a comment, ask: *can I rename a value, extract a function, or use an active pattern so the comment becomes unnecessary?* If yes, do that instead.
+Prefer good names to comments. Before writing a comment, ask: *can I rename a value, extract a function, or use an active pattern so the comment becomes unnecessary?* If yes, do that instead.
 
 - **Do not** restate what the code says (variable name, type name, attribute name, function signature).
 - **Do not** narrate the algorithm step-by-step. The diff is the algorithm.

.github/skills/code-compaction/templates/logic-rounds.md

@@ -23,9 +23,9 @@ NOT a search for existing helpers — that comes next.
 *name*; it misses functions that match by *shape* but not by name —
 which is the exact reuse the bloated patch should have used. Dispatch a
 real subagent with the agent's full toolset (code intelligence,
-semantic search, LSP, symbol search). **Spend the tokens** — a thorough
-reuse hunt up front saves Round 1 reviewers from proposing new code
-that duplicates existing infrastructure.
+semantic search, LSP, symbol search). A thorough reuse hunt up front
+saves Round 1 reviewers from proposing new code that duplicates existing
+infrastructure.
 
 ### Subagent dispatch prompt
 
@@ -56,8 +56,8 @@ YOUR JOB:
    empty. Round 1 reviewers need to know what's actually new vs
    reinvented.
 
-Spend the tokens. Recurse into multiple search strategies if the first
-one returns weak matches.
+If the first search strategy returns weak matches, recurse into multiple
+search strategies.
 
 OUTPUT:
 - list of reuse candidates with file:line and relevance note

.github/skills/hypothesis-driven-debugging/SKILL.md

@@ -23,7 +23,7 @@ Use this skill when:
 1. **Always start with a minimal reproduction**
 2. **Form multiple competing hypotheses**
 3. **Design verification for each hypothesis**
-4. **Document findings rigorously**
+4. **Record each hypothesis's verification method, result, and implications**
 5. **Re-run builds and tests after every change**
 
 ## Process