📝[Docs]: Correct Markdown casing and improve clarity in documentation files

Author: MariusStorhaug

.github/instructions/md.instructions.md

@@ -5,7 +5,7 @@ description: Markdown style guidelines for consistency across documentation.
 
 # Markdown Style Guidelines
 
-This document defines the markdown style guidelines for all markdown files in this repository. These rules follow common markdown linter best practices and ensure consistency across documentation.
+This document defines the Markdown style guidelines for all Markdown files in this repository. These rules follow common markdown linter best practices and ensure consistency across documentation.
 
 ## Headings
 
@@ -110,7 +110,7 @@ No blank lines before/after code blocks.
 - Always provide link text in square brackets: `[text](url)`
 - Do not use bare URLs (wrap them: `<https://example.com>`)
 - For internal repository links, use relative paths starting with `./` or `../`
-- Use `.md` extension for links to markdown files
+- Use `.md` extension for links to Markdown files
 
 **Good:**
 

.github/instructions/pwsh.instructions.md

@@ -629,7 +629,7 @@ Get-ChildItem -Path 'C:\Temp' -Filter '*.txt' -Recurse $true -ErrorAction 'Stop'
 
 - Use PowerShell comparison operators (`-eq`, `-ne`, `-gt`, `-lt`, `-ge`, `-le`)
 - Don't use C-style operators (`==`, `!=`, `>`, `<`)
-- Use `-like` for wildcard matching, `-match` for regex
+- Use `-like` for wildcard matching, `-match` for regular expression
 - Use `-contains` for collection membership, not `-eq`
 - Add `-i` prefix for case-insensitive (default) or `-c` for case-sensitive
 - Caution with $null comparisons. Comparison order is important depending if the variable is a single item or a collection.

.github/prompts/constitution.prompt.md

@@ -64,12 +64,12 @@ Follow this execution flow:
 
 3. Draft / Merge updated constitution content:
     - In Iteration Mode, integrate new principles/sections with minimal disruption:
-       * Retain stable identifiers (e.g., keep existing principle numbering unless renumbering is explicitly required or gaps introduced by removals).
-       * When replacing, either (a) fully substitute content if user confirmed or (b) append revised content and mark old with `DEPRECATED:` prefix plus TODO for removal in a future major version.
-   - Replace every placeholder with concrete text (no bracketed tokens left except intentionally retained template slots that the project has chosen not to define yet—explicitly justify any left).
-   - Preserve heading hierarchy and comments can be removed once replaced unless they still add clarifying guidance.
-   - Ensure each Principle section: succinct name line, paragraph (or bullet list) capturing non‑negotiable rules, explicit rationale if not obvious.
-   - Ensure Governance section lists amendment procedure, versioning policy, and compliance review expectations.
+      * Retain stable identifiers (e.g., keep existing principle numbering unless renumbering is explicitly required or gaps introduced by removals).
+      * When replacing, either (a) fully substitute content if user confirmed or (b) append revised content and mark old with `DEPRECATED:` prefix plus TODO for removal in a future major version.
+    - Replace every placeholder with concrete text (no bracketed tokens left except intentionally retained template slots that the project has chosen not to define yet—explicitly justify any left).
+    - Preserve heading hierarchy and comments can be removed once replaced unless they still add clarifying guidance.
+    - Ensure each Principle section: succinct name line, paragraph (or bullet list) capturing non‑negotiable rules, explicit rationale if not obvious.
+    - Ensure Governance section lists amendment procedure, versioning policy, and compliance review expectations.
 
 4. Consistency propagation checklist (convert prior checklist into active validations):
    - Read [`.specify/templates/plan-template.md`](../../.specify/templates/plan-template.md) and ensure any "Constitution Check" or rules align with updated principles.

.github/prompts/specify.prompt.md

@@ -30,7 +30,8 @@ Given that feature description, do this:
    If detected, extract the upstream repository information (owner/repo).
 
    **If fork contribution is detected but information is incomplete**, prompt the user:
-   ```
+
+   ```text
    Fork contribution detected. Please provide the following information:
    - Upstream organization/owner name (e.g., "microsoft", "PSModule")
    - Upstream repository name (e.g., "vscode", "PSModule")
@@ -51,12 +52,15 @@ Given that feature description, do this:
    - Examples: "user-authentication", "merge-workflows", "api-rate-limiting", "fix-memory-leak"
 
 3. Run the script [`.specify/scripts/powershell/create-new-feature.ps1 -Json -FeatureDescription "$ARGUMENTS" -BranchName "<your-generated-name>"`](../../.specify/scripts/powershell/create-new-feature.ps1) from repo root and parse its JSON output for BRANCH_NAME, SPEC_FILE, and IS_EXISTING_BRANCH. All file paths must be absolute.
-  **IMPORTANT** You must only ever run this script once. The JSON is provided in the terminal as output - always refer to it to get the actual content you're looking for.
-  **NOTE**
-  - The script will prepend an auto-incremented feature number (e.g., `003-`) to your branch name.
-  - If you're currently on `main` branch, a new feature branch will be created.
-  - If you're already on a feature branch (starts with 3 digits like `001-`, `002-`, etc.), you'll stay on that branch to iterate on the existing feature.
-  - This allows you to refine specifications without creating multiple branches for the same feature.
+
+**IMPORTANT** You must only ever run this script once. The JSON is provided in the terminal as output - always refer to it to get the actual content you're looking for.
+
+**NOTE**
+
+- The script will prepend an auto-incremented feature number (e.g., `003-`) to your branch name.
+- If you're currently on `main` branch, a new feature branch will be created.
+- If you're already on a feature branch (starts with 3 digits like `001-`, `002-`, etc.), you'll stay on that branch to iterate on the existing feature.
+- This allows you to refine specifications without creating multiple branches for the same feature.
 
 4. **Store fork information (if detected in step 1)**:
    - If the user indicated this is a fork contribution, create a `.fork-info.json` file in the feature directory (same location as SPEC_FILE)