V0.8.0/dotnet benchmark

.gitignore

@@ -1,3 +1,20 @@
+# Build results
+[Dd]ebug/
+[Dd]ebugPublic/
+[Rr]elease/
+[Rr]eleases/
+x64/
+x86/
+[Ww][Ii][Nn]32/
+[Aa][Rr][Mm]/
+[Aa][Rr][Mm]64/
+bld/
+[Bb]in/
+[Oo]bj/
+[Oo]ut/
+[Ll]og/
+[Ll]ogs/
+
 # OS
 .DS_Store
 Thumbs.db

AGENTS.md

@@ -2,6 +2,10 @@
 
 Repository-level rules for AI agents working in this codebase.
 
+## Local Shell Execution
+
+Agents may use any appropriate local shell. When using PowerShell syntax or executing a `.ps1` script locally, use PowerShell 7+ through `pwsh`; never invoke `powershell` or `powershell.exe`. This does not prescribe GitHub Actions shell choices.
+
 ## Eval Isolation
 
 Eval workspaces and test repositories must **never** be created inside this repository. This includes:

CHANGELOG.md

@@ -4,7 +4,62 @@ All notable changes to this project will be documented in this file.
 
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/), and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
-## [Unreleased]
+## [0.8.0] - 2026-07-18
+
+This is a minor release introducing the `dotnet-benchmark` skill for performance testing of .NET types with evidence-driven discovery and measurement discipline. The release emphasizes candidate selection through profiling evidence, semantic correctness validation before performance interpretation, and proportionate-stopping decision logic. Additionally, the release standardizes local PowerShell execution to `pwsh` 7+ and strengthens validation discipline across repo-managed skills.
+
+### Added
+
+- `dotnet-benchmark` skill with evidence-driven workflow for identifying high-value benchmark targets, designed to avoid low-signal performance testing and over-measurement; includes step-by-step discovery phases from intent resolution through experiment planning,
+- Discovery-focused FORMS.md parameter collection for `dotnet-benchmark` reducing implementation-tier choice friction by deferring tier selection to workflow inspection,
+- New template assets `operation-benchmark.cs` and `comparison-benchmark.cs` providing refined structural guidance for single-operation and comparative-implementation benchmarks,
+- `candidate-selection.md` reference documenting evidence ladders, call-site inspection, profiling integration, and candidate-ranking heuristics to drive the discovery phase,
+- `experiment-design.md` reference detailing performance questions, workload selection, semantic preflight and correctness oracle validation, measurement fitness assessment, and early-stop conditions,
+- Mandatory semantic preflight validation gate in `dotnet-benchmark` SKILL.md requiring deterministic correctness oracle derivation before accepting full-run results, preventing false-positive baseline misinterpretation,
+- Proportionate-stopping decision logic in `dotnet-benchmark` recognizing when measurement is complete and cost does not justify deeper investigation; includes case studies and selectivity-drift repair guidance,
+- Yolo mode support in `dotnet-benchmark` for autonomous candidate selection and progress-update-only planning when user intent is explicit,
+- Report-aware runner preflight in `dotnet-benchmark` recognizing when SkipBenchmarksWithReports plus matching reports/tuning/ artifacts intentionally filter a benchmark type, preserving benchmark code unchanged,
+- Comprehensive eval coverage for `dotnet-benchmark` with 12 test cases covering discovery workflow, candidate selection, evidence gathering, cost-signal analysis, implementation-comparison patterns, semantic preflight validation, selectivity-drift repair, proportionate stopping, yolo mode, and report-aware preflight; includes fixture code supporting five representative benchmark scenarios,
+- Enhanced `check-benchmark-requirements.ps1` and new `validate-skill.ps1` tooling supporting discovery workflow validation and template-asset consistency checking.
+
+### Changed
+
+- Standardized local PowerShell execution to `pwsh` 7+ while preserving Bash and workflow-specific shell choices; updated all local command examples and contributor guidance accordingly.
+
+## [0.7.5] - 2026-07-15
+
+This is a patch release focused on extending `trunk-first-repo` with a push-remote workflow mode that safely handles first-time remote pushes by pushing `main` before feature branches, ensuring the remote defaults to the correct branch while maintaining the PR-first workflow philosophy.
+
+### Added
+
+- Push Remote Workflow mode in `trunk-first-repo` for safely pushing to a newly-established remote without manually switching branches or checking out `main`, allowing `push remote <url>` invocation from the feature branch to send `main` by ref (`main:main`) before the feature branch,
+- Enhanced eval coverage for `trunk-first-repo` documenting push-remote workflow and Step 0 mode selection behavior,
+- Updated README description for `trunk-first-repo` to document safe first-push capability and `push remote <url>` mode alongside the Initialize Workflow.
+
+### Changed
+
+- Extended `trunk-first-repo` SKILL.md with Step 0 mode selector to distinguish between Initialize Workflow (repository creation) and Push Remote Workflow (remote establishment),
+- Refined README guidance to emphasize that `push remote <url>` can be invoked later from the feature branch for safer first-push without switching branches,
+- Added explicit push-remote documentation to trunk-first-repo "Why?" section explaining safer first-push behavior and benefits of sending `main` by ref.
+
+## [0.7.4] - 2026-07-03
+
+This is a patch release focused on strengthening `git-keep-a-changelog` with mandatory Step 4a base-commit inspection for concrete releases, ensuring that foundational version bumps, release-prep changes, and dependency baseline updates are never omitted from release narratives. The skill now requires explicit inspection of the base commit before manifest diffs and commit bodies, with output verification and structured reporting.
+
+### Added
+
+- Step 4a mandatory checkpoint in `git-keep-a-changelog` that inspects and explicitly reports the base commit for concrete releases (e.g., `## [X.Y.Z]`), showing changed files, identifying dependency/version manifests, and confirming release-prep file modifications before proceeding to Step 4b manifest diffs,
+- Explicit base-commit-inclusion enforcement using `<base>^..HEAD` (with caret) throughout Step 4 for concrete releases, ensuring the base commit itself is included in the changelog narrative,
+- Verification and confirmation gates in Step 4a requiring agents to show full base commit output, identify manifests, and explicitly state whether manifests or release-prep files were touched before proceeding to 4b,
+- Detailed comparison matrix in Step 3b distinguishing between `base^..HEAD` (for concrete releases, inclusive of base) and `base..HEAD` (for [Unreleased], exclusive of base),
+- Eval coverage validating base-commit inclusion, manifest detection, and Step 4a output verification for concrete release scenarios.
+
+### Changed
+
+- Restructured `git-keep-a-changelog` Step 4 into explicit sub-steps (4a through 4f) with clear sequencing: base-commit inspection first (4a), manifest detection (4b), manifest diff inspection (4c), commit-body reading (4d), net-diff inspection (4e), and pending-change integration (4f),
+- Enhanced `git-keep-a-changelog` SKILL.md with critical range-extension guidance for concrete releases, emphasizing that `<base>^..HEAD` (with caret) must be used consistently to include the base commit itself,
+- Strengthened "Bad Output Characteristics" section with **CRITICAL** emphasis on the consequences of omitting the base commit: silently-wrong output that breaks release narratives and loses foundational version bumps,
+- Updated README with enhanced description of `git-keep-a-changelog` base-commit enforcement and Step 4a mandatory checkpoint.
 
 ## [0.7.3] - 2026-07-01
 
@@ -418,7 +473,9 @@ This is a minor release that introduces two complementary git workflow skills, e
 
 - Improved scaffold fidelity with hidden `.bot` asset preservation, explicit UTF-8 and BOM handling, and checks aimed at preventing mojibake or incomplete generated output.
 
-[Unreleased]: https://github.com/codebeltnet/agentic/compare/v0.7.3...HEAD
+[0.8.0]: https://github.com/codebeltnet/agentic/compare/v0.7.5...v0.8.0
+[0.7.5]: https://github.com/codebeltnet/agentic/compare/v0.7.4...v0.7.5
+[0.7.4]: https://github.com/codebeltnet/agentic/compare/v0.7.3...v0.7.4
 [0.7.3]: https://github.com/codebeltnet/agentic/compare/v0.7.2...v0.7.3
 [0.7.2]: https://github.com/codebeltnet/agentic/compare/v0.7.1...v0.7.2
 [0.7.1]: https://github.com/codebeltnet/agentic/compare/v0.7.0...v0.7.1

CONTRIBUTING.md

@@ -68,21 +68,21 @@ The `description` is the most important field — it's how the AI decides to loa
 
 Evals let you verify the skill works and measure improvement over a baseline. Every repo-managed skill in this repository must include `evals/evals.json`:
 
-```json
-{
-  "skill_name": "your-skill-name",
-  "evals": [
-    {
-      "id": 0,
-      "prompt": "The user message to test against",
-      "expected_output": "What a correct response looks like — used for manual or automated grading",
-      "files": ["evals/files/example.md"]
-    }
-  ]
-}
-```
-
-`files` is optional. When present, list one or more fixture files relative to `skills/<name>/`. A common pattern is to store those fixtures under `evals/files/` so benchmark runners can copy or attach the same source inputs for both `with_skill` and `without_skill` runs.
+```json
+{
+  "skill_name": "your-skill-name",
+  "evals": [
+    {
+      "id": 0,
+      "prompt": "The user message to test against",
+      "expected_output": "What a correct response looks like — used for manual or automated grading",
+      "files": ["evals/files/example.md"]
+    }
+  ]
+}
+```
+
+`files` is optional. When present, list one or more fixture files relative to `skills/<name>/`. A common pattern is to store those fixtures under `evals/files/` so benchmark runners can copy or attach the same source inputs for both `with_skill` and `without_skill` runs.
 
 Aim for 3–5 evals that cover distinct scenarios: happy path, edge cases, and cases where the skill should *not* do something.
 
@@ -116,27 +116,27 @@ When a skill needs defaults for versions, paths, repository names, or support wi
 
 Use the repo validation harness before submitting scaffold or template changes:
 
-```powershell
-powershell -NoProfile -ExecutionPolicy Bypass -File .\scripts\validate-skill-templates.ps1
+```console
+pwsh -NoProfile -File ./scripts/validate-skill-templates.ps1
 ```
 
-Run the validator locally first for the fastest feedback loop. GitHub Actions also runs the same script on pull requests, but CI is the backstop, not the primary authoring loop.
+Run the validator locally first for the fastest feedback loop. GitHub Actions also runs the same script on pull requests, but CI is the backstop, not the primary authoring loop.
 
 To compare a change against the initial imported version, run the same harness against a git ref:
 
-```powershell
-powershell -NoProfile -ExecutionPolicy Bypass -File .\scripts\validate-skill-templates.ps1 -Ref HEAD
+```console
+pwsh -NoProfile -File ./scripts/validate-skill-templates.ps1 -Ref HEAD
 ```
 
 ## Checklist before submitting
 
 - [ ] `SKILL.md` has valid front matter with `name` and `description`
 - [ ] Skill is stack-agnostic (or clearly scoped to a specific tech in the name/description)
 - [ ] Examples are generic — no personal emails, usernames, or project-specific identifiers
-- [ ] At least one eval in `evals/evals.json`
-- [ ] The skill's `evals/evals.json` exists and its `skill_name` matches the folder/frontmatter name
-- [ ] Any optional `files` entries in `evals/evals.json` point to real fixture files under the same skill folder
-- [ ] Skill changes were benchmarked from a temp workspace with both `with_skill` and `without_skill` runs
+- [ ] At least one eval in `evals/evals.json`
+- [ ] The skill's `evals/evals.json` exists and its `skill_name` matches the folder/frontmatter name
+- [ ] Any optional `files` entries in `evals/evals.json` point to real fixture files under the same skill folder
+- [ ] Skill changes were benchmarked from a temp workspace with both `with_skill` and `without_skill` runs
 - [ ] `benchmark.json` and `eval-viewer/generate_review.py` from the installed Anthropic `skill-creator` copy were used so a human could compare `Outputs` and `Benchmark`
 - [ ] `scripts/validate-skill-templates.ps1` passes for the current working tree when changing scaffold or template behavior
 - [ ] If CI is enabled for the branch, the GitHub Actions validation job passes too