From 8576a9b2c6eb8b80e95f050c6b5fb685f5166146 Mon Sep 17 00:00:00 2001 From: perf-bundle Date: Thu, 3 Sep 2026 15:30:10 +0200 Subject: [PATCH] Optimize skill prompts Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 2f8363a4-a171-432f-92c4-04c181879d48 --- .github/agents/compiler-perf-investigator.md | 12 ++++++------ .github/agents/expert-reviewer.md | 2 +- .github/agents/extraction-pipeline.md | 7 +++---- .github/agents/fsharp-generic.md | 16 ++++++++-------- .github/instructions/NoBloat.instructions.md | 2 +- .../code-compaction/templates/logic-rounds.md | 10 +++++----- .../skills/hypothesis-driven-debugging/SKILL.md | 2 +- 7 files changed, 25 insertions(+), 26 deletions(-) diff --git a/.github/agents/compiler-perf-investigator.md b/.github/agents/compiler-perf-investigator.md index 5ad3c9477d0..2b3e3a026ad 100644 --- a/.github/agents/compiler-perf-investigator.md +++ b/.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.** --- diff --git a/.github/agents/expert-reviewer.md b/.github/agents/expert-reviewer.md index 4e7b8cfa6e1..eb02d8f26fc 100644 --- a/.github/agents/expert-reviewer.md +++ b/.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 diff --git a/.github/agents/extraction-pipeline.md b/.github/agents/extraction-pipeline.md index 0daf23aad79..d48ebda1480 100644 --- a/.github/agents/extraction-pipeline.md +++ b/.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 - diff --git a/.github/agents/fsharp-generic.md b/.github/agents/fsharp-generic.md index d56bf16e5b7..224e1f7e196 100644 --- a/.github/agents/fsharp-generic.md +++ b/.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 []. DON'T [] (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 []; avoid [] 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 diff --git a/.github/instructions/NoBloat.instructions.md b/.github/instructions/NoBloat.instructions.md index c80ca85f01b..280a7e8a0ae 100644 --- a/.github/instructions/NoBloat.instructions.md +++ b/.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. diff --git a/.github/skills/code-compaction/templates/logic-rounds.md b/.github/skills/code-compaction/templates/logic-rounds.md index b69f6975ad2..34bff7e1925 100644 --- a/.github/skills/code-compaction/templates/logic-rounds.md +++ b/.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 diff --git a/.github/skills/hypothesis-driven-debugging/SKILL.md b/.github/skills/hypothesis-driven-debugging/SKILL.md index 82af0d4afc8..6f4ece850ec 100644 --- a/.github/skills/hypothesis-driven-debugging/SKILL.md +++ b/.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