Content
78%Weight 40%Scale 1-5Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
A well-structured, highly actionable reference for Pester v5 testing: correct sequencing, executable examples, genuine version-specific gotchas, and an appropriately offloaded CI reference file. The main deductions are minor: placeholder test bodies, one example referencing an undefined function, and slightly repetitive citation phrasing.
Suggestions
Make code examples fully executable: give the Step 3 and Step 7 It blocks real assertion bodies, and dot-source or define Get-FormattedDate in the Step 6 mock example so it runs as written.
Add an explicit run-and-iterate checkpoint after Step 2 (e.g. 'run Invoke-Pester, read the failure output, fix, re-run') to close the feedback loop in the authoring workflow.
Trim the repeated 'Per [pqs][pqs]' / 'Per [pm][pm]' sentence openers and consolidate the version-sensitivity notes into the Limitations section to tighten token usage.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is dense with version-specific gotchas Claude cannot reliably recall ("Pester 3.4.0 built-in", "-SkipPublisherCheck", "$PesterBoundParameters (available since Pester 5.2.0)", scope rules) rather than explanations of known concepts. It is not 5 because repeated "Per [pqs][pqs]" citation phrasing and the placeholder It bodies in Steps 3 and 7 add tokens that could be trimmed. | 4 / 5 |
Actionability | Nearly all guidance is copy-paste ready: the install commands, a complete first test file, the Should matcher list, mock definitions with ParameterFilter, and the [PesterConfiguration]@{...} hashtable. It falls short of 5 because Step 3 and Step 7 It bodies are '# ...' placeholders and the Step 6 mock example calls Get-FormattedDate, which is never defined or dot-sourced. | 4 / 5 |
Workflow Clarity | A clear 10-step sequence (install -> first test -> structure -> assertions -> hooks -> mocks -> tags -> configuration -> coverage -> CI XML) with a verify checkpoint ("Import-Module Pester -PassThru") and an Anti-patterns table for error avoidance. Not 5: there is no explicit run -> fail -> fix feedback-loop guidance after test authoring, so checkpoints are present but not fully elaborated. | 4 / 5 |
Progressive Disclosure | The heavy material (full cross-platform CI YAML, Azure DevOps task, Run property table) is correctly split into references/ci-and-config.md, which exists in the bundle, is one level deep, and is clearly signaled in Steps 8 and 10 plus the References section. The body retains only the core in-spine examples, matching the 5 anchor. | 5 / 5 |
Total | 17 / 20 Passed |