Repository navigation
dotnet azure lessons
Refine the dotnet-azure-lessons plugin using this workstation's Codex history and the existing cross-workstation findings. Keep the eleven skills and read-only reviewer, remove repeated or overbroad instructions, and add narrowly scoped checks for demonstrated gaps.
| Type | Issue |
|---|---|
| Parent | Issue #107 |
| Sub-issue | Issue #108 |
| Sub-issue | Issue #109 |
| Sub-issue | Issue #110 |
| Sub-issue | Issue #111 |
| Pull request | PR #112 |
The original plugin already codifies recurring corrections from .NET, Azure, PowerShell, and agent-session work. This review found two opportunities to improve its effect: a few rules prescribe a single action beyond the evidence or task authorization, and practical lessons about profile migrations and credential diagnosis are not yet represented clearly.
The current-workstation history supports a stage-validate-switch-verify-recover pattern for changes to user environment profiles, including preserving data the change does not own. It also demonstrates why successful CI must be distinguished from migration steps that were not run. A PR review session re-read a changed head, compared existing discussion, and refreshed findings before posting; this supports a check for head drift, without implying that the earlier findings were wrong. Source-session identifiers and private paths remain local.
- Preserve the eleven skill entry points and the reviewer. Remove duplicated anecdotes, repeated completion prompts, and procedures already owned by neighboring skills. Keep a concise check and rationale with each non-obvious rule.
- Make scope, authorization, environment, and exceptions explicit. A rule should guide a decision without independently authorizing external writes, installs, credential resets, settings changes, or unrelated UI actions. Apply command-prefix guidance only where the current session's policy uses it.
- Add checks for reviewing the current PR head and existing comments before posting an earlier review; diagnosing CLI authentication separately from Git credential helpers; staging and validating environment/profile updates before switching, preserving unowned data, and defining recovery after partial failure; and distinguishing PowerShell source-file encoding from generated-file encoding.
- Narrow rigid acceptance checks to the work at hand: distinguish debugging reproduction from post-fix acceptance, treat unavailable platform and screenshot evidence as a reported gap, separate safe package builds from credentialed publication, and reserve installs or UI manipulation for an appropriate authorized environment.
- Keep technical specifics where they prevent a demonstrated failure. Use one owner for shared invariants, check the owning implementation or authoritative source when a rule's technical meaning changes, and cross-reference by rule title.
- Update the reviewer to include staged and unstaged changes, report actionable defects separately from missing evidence, and remain read-only.
- Audit the eleven skills and reviewer. Trim repeated rationale and completion text; revise authorization, evidence, and environment boundaries.
- Add the focused history-backed guidance to PR workflow, environment/profile updates, CLI authentication, and PowerShell encoding. Deduplicate shared validation and verification guidance.
- Update the reviewer selection and reporting criteria; keep all skill names, manifests, and applicable triggers consistent.
- Update English and Japanese plan and repository records to match the final skill behavior.
- Validate marketplace manifests, frontmatter, skill names, and local links; inspect the final diff and English/Japanese consistency.
- Search the plugin for private identifiers and secrets. Do not publish raw session excerpts.
- Run read-only scenarios for changed PR heads, authentication failures, denied operations, staged files, partial environment updates, and unavailable platform verification. Evaluate decisions and side effects rather than exact wording.
- Report static validation, scenario evaluation, and actual skill selection in client sessions separately. Do not claim client invocation or platform execution without observing it.