diff --git a/.cspell.json b/.cspell.json
deleted file mode 100644
index e20a4d3..0000000
--- a/.cspell.json
+++ /dev/null
@@ -1,87 +0,0 @@
-{
-  "version": "0.2",
-  "language": "en",
-  "words": [
-    "DEMA",
-    "demaconsulting",
-    "VHDL",
-    "vhdl",
-    "vhdltest",
-    "testbench",
-    "testbenches",
-    "Xilinx",
-    "Aldec",
-    "ghdl",
-    "modelsim",
-    "vivado",
-    "activehdl",
-    "Questa",
-    "QuestaSim",
-    "netanalyzers",
-    "csproj",
-    "yaml",
-    "trx",
-    "snupkg",
-    "nupkg",
-    "spdx",
-    "sbom",
-    "sonarcloud",
-    "coverlet",
-    "opencover",
-    "msys",
-    "mingw",
-    "dotnet",
-    "dorny",
-    "mstest",
-    "Pandoc",
-    "Weasyprint",
-    "ibiqlik",
-    "msystem",
-    "nickg",
-    "sonarscanner",
-    "mcode",
-    "Anson",
-    "pandoctool",
-    "weasyprinttool",
-    "tracematrix",
-    "buildnotes",
-    "buildmark",
-    "vsimsa",
-    "alib",
-    "worklib",
-    "acom",
-    "asim",
-    "endsim",
-    "vlib",
-    "vcom",
-    "vsim",
-    "PATHEXT",
-    "nolog",
-    "xvhdl",
-    "runall",
-    "xelab",
-    "ASIC",
-    "lifecycles",
-    "slnx",
-    "reqstream",
-    "screencasts",
-    "sarifmark",
-    "Sarif",
-    "SARIF"
-  ],
-  "ignorePaths": [
-    "node_modules",
-    ".git",
-    "bin",
-    "obj",
-    "*.nupkg",
-    "*.snupkg",
-    "*.dll",
-    "*.exe",
-    "*.trx",
-    "*.spdx.json",
-    "package-lock.json",
-    "yarn.lock",
-    "AGENT_REPORT_*.md"
-  ]
-}
diff --git a/.cspell.yaml b/.cspell.yaml
new file mode 100644
index 0000000..349274a
--- /dev/null
+++ b/.cspell.yaml
@@ -0,0 +1,114 @@
+---
+# Spell-Checking
+#
+# PURPOSE:
+# - Maintain professional documentation and code quality
+# - Catch spelling errors before publication
+# - Support consistent technical terminology usage
+# - Misspelled words should be fixed in the source
+# - NEVER add a misspelled word to the 'words' list
+# - PROPOSE only genuine technical terms/names as needed
+
+version: "0.2"
+language: en
+
+# Project-specific technical terms and tool names
+words:
+  - activehdl
+  - Aldec
+  - alib
+  - acom
+  - Anson
+  - ASIC
+  - asim
+  - buildmark
+  - BuildMark
+  - build_notes
+  - camelcase
+  - code_quality
+  - code_review_plan
+  - code_review_report
+  - CodeQL
+  - copilot
+  - coverlet
+  - cspell
+  - csproj
+  - dcterms
+  - Dema
+  - demaconsulting
+  - dotnet
+  - dorny
+  - endsim
+  - ghdl
+  - gitattributes
+  - ibiqlik
+  - lifecycles
+  - markdownlint
+  - mingw
+  - mcode
+  - modelsim
+  - mstest
+  - msys
+  - msystem
+  - netanalyzers
+  - nickg
+  - nlog
+  - nupkg
+  - opencover
+  - pandoc
+  - pandoctool
+  - PATHEXT
+  - Questa
+  - QuestaSim
+  - reqstream
+  - ReqStream
+  - requirements_doc
+  - requirements_report
+  - reviewmark
+  - ReviewMark
+  - runall
+  - Sarif
+  - SarifMark
+  - sarifmark
+  - sbom
+  - SBOM
+  - screencasts
+  - slnx
+  - snupkg
+  - sonarcloud
+  - sonarscanner
+  - spdx
+  - testbench
+  - testbenches
+  - trace_matrix
+  - tracematrix
+  - trx
+  - vcom
+  - VHDL
+  - vhdl
+  - vhdltest
+  - vlib
+  - vivado
+  - vsim
+  - vsimsa
+  - Weasyprint
+  - weasyprinttool
+  - worklib
+  - xelab
+  - Xilinx
+  - xvhdl
+  - yaml
+  - yamllint
+
+# Exclude common build artifacts, dependencies, and vendored third-party code
+ignorePaths:
+  - "**/.git/**"
+  - "**/node_modules/**"
+  - "**/.venv/**"
+  - "**/thirdparty/**"
+  - "**/third-party/**"
+  - "**/3rd-party/**"
+  - "**/AGENT_REPORT_*.md"
+  - "**/bin/**"
+  - "**/obj/**"
+  - package-lock.json
diff --git a/.gitattributes b/.gitattributes
new file mode 100644
index 0000000..2f09872
--- /dev/null
+++ b/.gitattributes
@@ -0,0 +1,7 @@
+# Set default behavior: normalize line endings to LF on checkout for all text files.
+# This ensures consistent SHA256 fingerprints for reviewmark across all platforms.
+* text=auto eol=lf
+
+# Windows batch files require CRLF line endings to function correctly.
+*.bat text eol=crlf
+*.cmd text eol=crlf
diff --git a/.github/agents/code-quality-agent.md b/.github/agents/code-quality.agent.md
similarity index 87%
rename from .github/agents/code-quality-agent.md
rename to .github/agents/code-quality.agent.md
index c838ba0..f307a22 100644
--- a/.github/agents/code-quality-agent.md
+++ b/.github/agents/code-quality.agent.md
@@ -1,6 +1,8 @@
 ---
-name: Code Quality Agent
-description: Ensures code quality through linting and static analysis - responsible for security, maintainability, and correctness
+name: code-quality
+description: Ensures code quality through comprehensive linting and static analysis.
+tools: [read, search, edit, execute, github, agent]
+user-invocable: true
 ---
 
 # Code Quality Agent - VHDLTest
@@ -9,7 +11,7 @@ Enforce quality standards through linting, static analysis, and security scannin
 
 ## When to Invoke This Agent
 
-Invoke the code-quality-agent for:
+Invoke the code-quality agent for:
 
 - Running and fixing linting issues (markdown, YAML, spell check, code formatting)
 - Ensuring static analysis passes with zero warnings
@@ -31,8 +33,8 @@ Ensure the project is:
 
 1. **Build**: Zero warnings (TreatWarningsAsErrors=true)
 2. **Linting**:
-   - markdownlint (`.markdownlint-cli2.jsonc`)
-   - cspell (`.cspell.json`)
+   - markdownlint (`.markdownlint-cli2.yaml`)
+   - cspell (`.cspell.yaml`)
    - yamllint (`.yamllint.yaml`)
    - dotnet format (`.editorconfig`)
 3. **Static Analysis**:
@@ -76,7 +78,7 @@ lint.bat     # Windows
 - **Software Developer Agent**: For fixing production code issues
 - **Test Developer Agent**: For fixing test code issues
 
-## Don't
+## Don't Do These Things
 
 - Disable quality checks to make builds pass
 - Ignore security warnings
diff --git a/.github/agents/code-review.agent.md b/.github/agents/code-review.agent.md
new file mode 100644
index 0000000..fb01a20
--- /dev/null
+++ b/.github/agents/code-review.agent.md
@@ -0,0 +1,46 @@
+---
+name: code-review
+description: Assists in performing formal file reviews.
+tools: [read, search, edit, execute, github, web, agent]
+user-invocable: true
+---
+
+# Code Review Agent
+
+Execute comprehensive code reviews with emphasis on structured compliance verification and file review status
+requirements.
+
+## Reporting
+
+Create a report using the filename pattern `AGENT_REPORT_code_review_[review-set].md`
+(e.g., `AGENT_REPORT_code_review_auth-module.md`) to document review criteria, identified issues, and recommendations
+for the specific review-set.
+
+## Review Steps
+
+1. Download the
+   <https://github.com/demaconsulting/ContinuousCompliance/raw/refs/heads/main/docs/review-template/review-template.md>
+   to get the checklist to fill in
+2. Use `dotnet reviewmark --elaborate [review-set]` to get the files to review
+3. Review the files all together
+4. Populate the checklist with the findings to make the report
+
+## Hand-off to Other Agents
+
+Only attempt to apply review fixes if requested.
+
+- If code quality, logic, or structural issues need fixing, call the @software-developer agent
+- If test coverage gaps or quality issues are identified, call the @test-developer agent
+- If documentation accuracy or completeness issues are found, call the @technical-writer agent
+- If quality gate verification is needed after fixes, call the @code-quality agent
+- If requirements traceability issues are discovered, call the @requirements agent
+
+## Don't Do These Things
+
+- **Never modify code during review** (document findings only, delegate fixes)
+- **Never skip applicable checklist items** (comprehensive review required)
+- **Never approve reviews with unresolved critical findings**
+- **Never bypass review status requirements** for compliance
+- **Never conduct reviews without proper documentation**
+- **Never ignore security or compliance findings**
+- **Never approve without verifying all quality gates**
diff --git a/.github/agents/repo-consistency-agent.md b/.github/agents/repo-consistency-agent.md
deleted file mode 100644
index 4cde732..0000000
--- a/.github/agents/repo-consistency-agent.md
+++ /dev/null
@@ -1,122 +0,0 @@
----
-name: Repo Consistency Agent
-description: Ensures downstream repositories remain consistent with the TemplateDotNetTool template patterns and best practices
----
-
-# Repo Consistency Agent - VHDLTest
-
-Maintain consistency between VHDLTest and the TemplateDotNetTool template at <https://github.com/demaconsulting/TemplateDotNetTool>.
-
-## When to Invoke This Agent
-
-Invoke the repo-consistency-agent for:
-
-- Periodic reviews of VHDLTest against the TemplateDotNetTool template
-- Checking if VHDLTest follows the latest template patterns
-- Identifying drift from template standards
-- Recommending updates to bring VHDLTest back in sync with TemplateDotNetTool
-
-**Note**: This agent reviews VHDLTest (<https://github.com/demaconsulting/VHDLTest>) for consistency with
-the TemplateDotNetTool template (<https://github.com/demaconsulting/TemplateDotNetTool>).
-
-## Responsibilities
-
-### Consistency Checks
-
-The agent reviews the following areas for consistency with the template:
-
-#### GitHub Configuration
-
-- **Issue Templates**: `.github/ISSUE_TEMPLATE/` files (bug_report.yml, feature_request.yml, config.yml)
-- **Pull Request Template**: `.github/pull_request_template.md`
-- **Workflow Patterns**: General structure of `.github/workflows/` (build.yaml, build_on_push.yaml, release.yaml)
-  - Note: Some projects may need workflow deviations for specific requirements
-
-#### Agent Configuration
-
-- **Agent Definitions**: `.github/agents/` directory structure
-- **Agent Documentation**: `AGENTS.md` file listing available agents
-
-#### Code Structure and Patterns
-
-- **Context Parsing**: `Context.cs` pattern for command-line argument handling
-- **Self-Validation**: `Validation.cs` pattern for built-in tests
-- **Program Entry**: `Program.cs` pattern with version/help/validation routing
-- **Standard Arguments**: Support for `-v`, `--version`, `-?`, `-h`, `--help`, `--silent`, `--validate`, `--results`, `--log`
-
-#### Documentation
-
-- **README Structure**: Follows template README.md pattern (badges, features, installation,
-  usage, structure, CI/CD, documentation, license)
-- **Standard Files**: Presence and structure of:
-  - `CONTRIBUTING.md`
-  - `CODE_OF_CONDUCT.md`
-  - `SECURITY.md`
-  - `LICENSE`
-
-#### Quality Configuration
-
-- **Linting Rules**: `.cspell.json`, `.markdownlint-cli2.jsonc`, `.yamllint.yaml`
-  - Note: Spelling exceptions will be repository-specific
-- **Editor Config**: `.editorconfig` settings (file-scoped namespaces, 4-space indent, UTF-8+BOM, LF endings)
-- **Code Style**: C# code style rules and analyzer configuration
-
-#### Project Configuration
-
-- **csproj Sections**: Key sections in .csproj files:
-  - NuGet Tool Package Configuration
-  - Symbol Package Configuration
-  - Code Quality Configuration (TreatWarningsAsErrors, GenerateDocumentationFile, etc.)
-  - SBOM Configuration
-  - Common package references (DemaConsulting.TestResults, Microsoft.SourceLink.GitHub, analyzers)
-
-#### Documentation Generation
-
-- **Document Structure**: `docs/` directory with:
-  - `guide/` (user guide)
-  - `requirements/` (auto-generated)
-  - `justifications/` (auto-generated)
-  - `tracematrix/` (auto-generated)
-  - `buildnotes/` (auto-generated)
-  - `quality/` (auto-generated)
-- **Definition Files**: `definition.yaml` files for document generation
-
-### Review Process
-
-1. **Identify Differences**: Compare VHDLTest repository structure with the TemplateDotNetTool template
-2. **Assess Impact**: Determine if differences are intentional variations or drift
-3. **Recommend Updates**: Suggest specific files or patterns that should be updated
-4. **Respect Customizations**: Recognize valid project-specific customizations
-
-### What NOT to Flag
-
-- Project-specific naming (tool names, package IDs, repository URLs)
-- Project-specific spell check exceptions in `.cspell.json`
-- Workflow variations for specific project needs
-- Additional requirements or features beyond the template
-- Project-specific dependencies
-
-## Defer To
-
-- **Software Developer Agent**: For implementing code changes recommended by consistency check
-- **Technical Writer Agent**: For updating documentation to match template
-- **Requirements Agent**: For updating requirements.yaml
-- **Test Developer Agent**: For updating test patterns
-- **Code Quality Agent**: For applying linting and code style changes
-
-## Usage Pattern
-
-This agent is typically invoked on VHDLTest to review consistency with TemplateDotNetTool:
-
-1. Access the VHDLTest repository
-2. Invoke repo-consistency-agent to review consistency with the TemplateDotNetTool template (<https://github.com/demaconsulting/TemplateDotNetTool>)
-3. Review agent recommendations
-4. Apply relevant changes using appropriate specialized agents
-5. Test changes to ensure they don't break existing functionality
-
-## Key Principles
-
-- **Template Evolution**: As TemplateDotNetTool evolves, this agent helps VHDLTest stay current
-- **Respect Customization**: Not all differences are problems - some are valid customizations
-- **Incremental Adoption**: VHDLTest can adopt template changes incrementally
-- **Documentation**: When recommending changes, explain why they align with best practices
diff --git a/.github/agents/repo-consistency.agent.md b/.github/agents/repo-consistency.agent.md
new file mode 100644
index 0000000..ffbda59
--- /dev/null
+++ b/.github/agents/repo-consistency.agent.md
@@ -0,0 +1,50 @@
+---
+name: repo-consistency
+description: Ensures downstream repositories remain consistent with the TemplateDotNetTool template patterns and best practices.
+tools: [read, search, edit, execute, github, agent]
+user-invocable: true
+---
+
+# Repo Consistency Agent - VHDLTest
+
+Maintain consistency between VHDLTest and the TemplateDotNetTool template at <https://github.com/demaconsulting/TemplateDotNetTool>.
+
+## When to Invoke This Agent
+
+Invoke the repo-consistency-agent for:
+
+- Periodic reviews of VHDLTest against the TemplateDotNetTool template
+- Checking if VHDLTest follows the latest template patterns
+- Identifying drift from template standards
+- Recommending updates to bring VHDLTest back in sync with TemplateDotNetTool
+
+**Note**: This agent reviews VHDLTest (<https://github.com/demaconsulting/VHDLTest>) for consistency with
+the TemplateDotNetTool template (<https://github.com/demaconsulting/TemplateDotNetTool>).
+
+## Reporting
+
+If detailed documentation of consistency analysis is needed, create a report using the filename pattern
+`AGENT_REPORT_consistency_[repo_name].md` (e.g., `AGENT_REPORT_consistency_MyTool.md`) to document
+consistency gaps, template evolution updates, and recommended changes for the specific repository.
+
+## Consistency Steps
+
+1. Fetch the 20 most recently merged PRs (`is:pr is:merged sort:updated-desc`) from <https://github.com/demaconsulting/TemplateDotNetTool>
+2. Determine the intent of the template pull requests (what changes were performed to which files)
+3. Apply missing changes to this repository's files (if appropriate and with translation)
+
+## Don't Do These Things
+
+- **Never recommend changes without understanding project context** (some differences are intentional)
+- **Never flag valid project-specific customizations** as consistency problems
+- **Never apply template changes blindly** without assessing downstream project impact
+- **Never ignore template evolution benefits** when they clearly improve downstream projects
+- **Never recommend breaking changes** without migration guidance and impact assessment
+- **Never skip validation** of preserved functionality after template alignment
+- **Never assume all template patterns apply universally** (assess project-specific needs)
+
+## Key Principles
+
+- **Evolutionary Consistency**: Template improvements should enhance downstream projects systematically
+- **Intelligent Customization Respect**: Distinguished valid customizations from unintentional drift
+- **Incremental Template Adoption**: Support phased adoption of template improvements based on project capacity
diff --git a/.github/agents/requirements-agent.md b/.github/agents/requirements-agent.md
deleted file mode 100644
index ebe36d8..0000000
--- a/.github/agents/requirements-agent.md
+++ /dev/null
@@ -1,80 +0,0 @@
----
-name: Requirements Agent
-description: Develops requirements and ensures appropriate test coverage - knows which requirements need unit/integration/self-validation tests
----
-
-# Requirements Agent - VHDLTest
-
-Develop and maintain high-quality requirements with proper test coverage linkage.
-
-## When to Invoke This Agent
-
-Invoke the requirements-agent for:
-
-- Creating new requirements in `requirements.yaml`
-- Reviewing and improving existing requirements
-- Ensuring requirements have appropriate test coverage
-- Determining which type of test (unit, integration, or self-validation) is appropriate
-- Differentiating requirements from design details
-
-## Responsibilities
-
-### Writing Good Requirements
-
-- Focus on **what** the system must do, not **how** it does it
-- Requirements describe observable behavior or characteristics
-- Design details (implementation choices) are NOT requirements
-- Use clear, testable language with measurable acceptance criteria
-- Each requirement should be traceable to test evidence
-
-### Test Coverage Strategy
-
-- **All requirements MUST be linked to tests** - this is enforced in CI
-- **Not all tests need to be linked to requirements** - tests may exist for:
-  - Exploring corner cases
-  - Testing design decisions
-  - Failure-testing scenarios
-  - Implementation validation beyond requirement scope
-- **Self-validation tests**: Preferred for command-line behavior, features that ship with the product
-- **Unit tests**: For internal component behavior, isolated logic
-- **Integration tests**: For cross-component interactions, end-to-end scenarios
-
-### Requirements Format
-
-Follow the `requirements.yaml` structure:
-
-- Clear ID and description
-- Justification explaining why the requirement is needed
-- Linked to appropriate test(s)
-- Enforced via: `dotnet reqstream --requirements requirements.yaml --tests "artifacts/**/*.trx" --enforce`
-
-### Test Source Filters
-
-Test links in `requirements.yaml` can include a source filter prefix to restrict which test results count as
-evidence. This is critical for platform, simulator, and framework requirements - **never remove these filters**.
-
-- `ghdl@TestName` - proves the test passed using the GHDL simulator
-- `nvc@TestName` - proves the test passed using the NVC simulator
-- `windows@TestName` - proves the test passed on a Windows platform
-- `ubuntu@TestName` - proves the test passed on a Linux (Ubuntu) platform
-- `macos@TestName` - proves the test passed on a macOS platform
-- `dotnet8.x@TestName` - proves the self-validation test ran on a machine with .NET 8.x runtime
-- `dotnet9.x@TestName` - proves the self-validation test ran on a machine with .NET 9.x runtime
-- `dotnet10.x@TestName` - proves the self-validation test ran on a machine with .NET 10.x runtime
-
-Without the source filter, a test result from any platform/simulator/framework satisfies the requirement. Removing
-a filter invalidates the evidence for platform/simulator/framework requirements.
-
-## Defer To
-
-- **Software Developer Agent**: For implementing self-validation tests and production code
-- **Test Developer Agent**: For implementing unit and integration tests
-- **Technical Writer Agent**: For documentation of requirements and processes
-- **Code Quality Agent**: For verifying test quality and enforcement
-
-## Don't
-
-- Mix requirements with implementation details
-- Create requirements without test linkage
-- Expect all tests to be linked to requirements (some tests exist for other purposes)
-- Change code directly (delegate to developer agents)
diff --git a/.github/agents/requirements.agent.md b/.github/agents/requirements.agent.md
new file mode 100644
index 0000000..3e28f8e
--- /dev/null
+++ b/.github/agents/requirements.agent.md
@@ -0,0 +1,69 @@
+---
+name: requirements
+description: Develops requirements and ensures appropriate test coverage - knows which requirements need unit/integration/self-validation tests
+tools: [read, search, edit, execute, github, web, agent]
+user-invocable: true
+---
+
+# Requirements Agent - VHDLTest
+
+Develop and maintain high-quality requirements with proper test coverage linkage.
+
+## When to Invoke This Agent
+
+Invoke the requirements-agent for:
+
+- Creating new requirements in `requirements.yaml`
+- Reviewing and improving existing requirements
+- Ensuring requirements have appropriate test coverage
+- Determining which type of test (unit, integration, or self-validation) is appropriate
+- Differentiating requirements from design details
+
+## Responsibilities
+
+### Requirements Engineering
+
+- Focus on **observable behavior**, not implementation details
+- Write clear, testable requirements
+- Include justification explaining business/regulatory rationale
+- Prefer `IntegrationTest_*` tests over unit tests for evidence
+
+### VHDLTest-Specific Test Types
+
+1. **Self-Validation Tests** (via `--validate`): For CLI argument handling, output formatting
+2. **Integration Tests** (`IntegrationTest_*`): For VHDL simulation workflows, report generation
+3. **Unit Tests**: For parsing logic, data transformations
+
+### Test Source Filters (CRITICAL - Do Not Remove)
+
+```yaml
+tests:
+  - "ghdl@TestName"      # GHDL simulator evidence only
+  - "nvc@TestName"       # NVC simulator evidence only
+  - "windows@TestName"   # Windows platform evidence only
+  - "ubuntu@TestName"    # Linux (Ubuntu) platform evidence only
+  - "macos@TestName"     # macOS platform evidence only
+  - "TestName"           # Any platform acceptable
+```
+
+### Enforcement
+
+```bash
+dotnet reqstream \
+  --requirements requirements.yaml \
+  --tests "artifacts/**/*.trx" \
+  --enforce
+```
+
+## Defer To
+
+- **Software Developer Agent**: For implementing features that satisfy requirements
+- **Test Developer Agent**: For creating tests to validate requirements
+- **Technical Writer Agent**: For requirements documentation
+
+## Don't Do These Things
+
+- Create requirements without test linkage (CI will fail)
+- Remove source filters from platform/simulator-specific requirements
+- Mix implementation details with requirements
+- Skip justification text
diff --git a/.github/agents/software-developer.md b/.github/agents/software-developer.agent.md
similarity index 79%
rename from .github/agents/software-developer.md
rename to .github/agents/software-developer.agent.md
index 99276c7..115d5df 100644
--- a/.github/agents/software-developer.md
+++ b/.github/agents/software-developer.agent.md
@@ -1,6 +1,8 @@
 ---
-name: Software Developer
+name: software-developer
 description: Writes production code and self-validation tests - targets design-for-testability and literate programming style
+tools: [read, search, edit, execute, github, agent]
+user-invocable: true
 ---
 
 # Software Developer - VHDLTest
@@ -59,23 +61,15 @@ var results = ProcessFile(options.InputFile);
 - **Using Statements**: Top of file only
 - **String Formatting**: Use interpolated strings ($"") for clarity
 
-### Self-Validation Tests
-
-- Naming: `VHDLTest_FeatureBeingValidated`
-- These tests ship with the product and run via `--validate` flag
-- Must support TRX/JUnit output format
-- Link to requirements in `requirements.yaml`
-
 ## Defer To
 
-- **Requirements Agent**: For new requirement creation and test strategy
-- **Test Developer Agent**: For unit and integration tests
+- **Requirements Agent**: For requirements quality and test linkage strategy
 - **Technical Writer Agent**: For documentation updates
-- **Code Quality Agent**: For linting, formatting, and static analysis
+- **Test Developer Agent**: For unit and integration tests
 
-## Don't
+## Don't Do These Things
 
-- Write code without explanatory comments
-- Create large monolithic functions
-- Skip XML documentation
-- Ignore the literate programming style
+- Skip literate programming comments
+- Disable compiler warnings to make builds pass
+- Create untestable code with hidden dependencies
+- Skip XML documentation on any members
diff --git a/.github/agents/technical-writer.md b/.github/agents/technical-writer.agent.md
similarity index 76%
rename from .github/agents/technical-writer.md
rename to .github/agents/technical-writer.agent.md
index 5897994..1e1f917 100644
--- a/.github/agents/technical-writer.md
+++ b/.github/agents/technical-writer.agent.md
@@ -1,6 +1,8 @@
 ---
-name: Technical Writer
+name: technical-writer
 description: Ensures documentation is accurate and complete - knowledgeable about regulatory documentation and special document types
+tools: [read, search, edit, execute, github, agent]
+user-invocable: true
 ---
 
 # Technical Writer - VHDLTest
@@ -34,14 +36,15 @@ Invoke the technical-writer for:
 - **All markdown files**: Use reference-style links `[text][ref]` with `[ref]: url` at document end
 - **Exceptions**:
   - **README.md**: Use absolute URLs in the links (shipped in NuGet package)
-  - **AI agent markdown files** (`.github/agents/*.md`): Use inline links `[text](url)` so URLs are visible in agent context
+  - **AI agent markdown files** (`.github/agents/*.agent.md`): Use inline links `[text](url)` so URLs are visible
+    in agent context
 - Max 120 characters per line
 - Lists require blank lines (MD032)
 
 #### Linting Requirements
 
-- **markdownlint**: Style and structure compliance
-- **cspell**: Spelling (add technical terms to `.cspell.json`)
+- **markdownlint**: Style and structure compliance (`.markdownlint-cli2.yaml`)
+- **cspell**: Spelling (add technical terms to `.cspell.yaml`)
 - **yamllint**: YAML file validation
 
 ### Regulatory Documentation
@@ -59,8 +62,9 @@ For documents requiring regulatory compliance:
 - **Test Developer Agent**: For test documentation
 - **Code Quality Agent**: For running linters and fixing lint issues
 
-## Don't
+## Don't Do These Things
 
-- Change code to match documentation (code is source of truth)
-- Document non-existent features
-- Skip linting before committing changes
+- Edit auto-generated documentation manually (will be overwritten)
+- Skip purpose and scope sections in regulatory documents
+- Ignore spelling errors
+- Commit documentation without linting verification
diff --git a/.github/agents/test-developer.md b/.github/agents/test-developer.agent.md
similarity index 94%
rename from .github/agents/test-developer.md
rename to .github/agents/test-developer.agent.md
index 8084e0c..5e9ae20 100644
--- a/.github/agents/test-developer.md
+++ b/.github/agents/test-developer.agent.md
@@ -1,6 +1,8 @@
 ---
-name: Test Developer
+name: test-developer
 description: Writes unit and integration tests following AAA pattern - clear documentation of what's tested and proved
+tools: [read, search, edit, execute, github, agent]
+user-invocable: true
 ---
 
 # Test Developer - VHDLTest
@@ -87,6 +89,16 @@ the evidence-based proof that the tool works on a specific platform, simulator,
 - Use MSTest V4 testing framework
 - Follow existing naming conventions in the test suite
 
+### CI/CD Integration
+
+```yaml
+- name: Upload Test Results
+  uses: actions/upload-artifact@v7
+  with:
+    name: test-results
+    path: TestResults/**/*.trx
+```
+
 ### MSTest V4 Best Practices
 
 Common anti-patterns to avoid (not exhaustive):
@@ -138,7 +150,7 @@ Common anti-patterns to avoid (not exhaustive):
 - **Technical Writer Agent**: For test documentation in markdown
 - **Code Quality Agent**: For test linting and static analysis
 
-## Don't
+## Don't Do These Things
 
 - Write tests that test multiple behaviors in one test
 - Skip test documentation
diff --git a/.markdownlint-cli2.jsonc b/.markdownlint-cli2.jsonc
deleted file mode 100644
index 94acac4..0000000
--- a/.markdownlint-cli2.jsonc
+++ /dev/null
@@ -1,16 +0,0 @@
-{
-  "config": {
-    "default": true,
-    "MD003": { "style": "atx" },
-    "MD007": { "indent": 2 },
-    "MD013": { "line_length": 120 },
-    "MD024": { "siblings_only": true },
-    "MD025": false,
-    "MD033": false,
-    "MD041": false
-  },
-  "ignores": [
-    "node_modules",
-    "**/AGENT_REPORT_*.md"
-  ]
-}
diff --git a/.markdownlint-cli2.yaml b/.markdownlint-cli2.yaml
new file mode 100644
index 0000000..04f1f80
--- /dev/null
+++ b/.markdownlint-cli2.yaml
@@ -0,0 +1,47 @@
+---
+# Markdown Linting Standards
+#
+# PURPOSE:
+# - Maintain professional technical documentation standards
+# - Ensure consistent formatting for readability and maintenance
+# - Support automated documentation generation and publishing
+#
+# DO NOT MODIFY: These rules represent coding standards
+# - If files fail linting, fix the files to meet these standards
+# - Do not relax rules to accommodate existing non-compliant files
+# - Consistency across repositories is critical for documentation quality
+
+config:
+  # Enable all default rules
+  default: true
+
+  # Require ATX-style headers (# Header) instead of Setext-style
+  MD003:
+    style: atx
+
+  # Set consistent indentation for nested lists
+  MD007:
+    indent: 2
+
+  # Allow longer lines for URLs and technical content
+  MD013:
+    line_length: 120
+
+  # Allow multiple top-level headers per document
+  MD025: false
+
+  # Allow inline HTML for enhanced documentation
+  MD033: false
+
+  # Allow documents without top-level header (for fragments)
+  MD041: false
+
+# Exclude common build artifacts, dependencies, and vendored third-party code
+ignores:
+  - "**/.git/**"
+  - "**/node_modules/**"
+  - "**/.venv/**"
+  - "**/thirdparty/**"
+  - "**/third-party/**"
+  - "**/3rd-party/**"
+  - "**/AGENT_REPORT_*.md"
diff --git a/.yamllint.yaml b/.yamllint.yaml
index a10ae8e..6c6c4fb 100644
--- a/.yamllint.yaml
+++ b/.yamllint.yaml
@@ -1,14 +1,31 @@
 ---
-# yamllint configuration for VHDLTest
-# This configuration defines the rules for YAML file linting
+# YAML Linting Standards
+#
+# PURPOSE:
+# - Maintain consistent code quality and readability standards
+# - Support CI/CD workflows with reliable YAML parsing
+# - Ensure professional documentation and configuration files
+#
+# DO NOT MODIFY: These rules represent coding standards
+# - If files fail linting, fix the files to meet these standards
+# - Do not relax rules to accommodate existing non-compliant files
+# - Consistency across repositories is critical for maintainability
 
 extends: default
 
+# Exclude common build artifacts, dependencies, and vendored third-party code
+ignore: |
+  .git/
+  node_modules/
+  .venv/
+  thirdparty/
+  third-party/
+  3rd-party/
+
 rules:
   # Allow 'on:' in GitHub Actions workflows (not a boolean value)
   truthy:
     allowed-values: ['true', 'false', 'on', 'off']
-    check-keys: true
 
   # Allow longer lines for URLs and complex expressions
   line-length:
diff --git a/AGENTS.md b/AGENTS.md
index 81f055a..a41460a 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -5,24 +5,26 @@ generating test reports.
 
 ## Available Specialized Agents
 
-- **Requirements Agent** - Develops requirements and ensures test coverage linkage
-- **Technical Writer** - Creates accurate documentation following regulatory best practices
-- **Software Developer** - Writes production code and self-validation tests in literate style
-- **Test Developer** - Creates unit and integration tests following AAA pattern
-- **Code Quality Agent** - Enforces linting, static analysis, and security standards
-- **Repo Consistency Agent** - Ensures VHDLTest remains consistent with TemplateDotNetTool template patterns
+- **requirements** - Develops requirements and ensures test coverage linkage
+- **technical-writer** - Creates accurate documentation following regulatory best practices
+- **software-developer** - Writes production code and self-validation tests in literate style
+- **test-developer** - Creates unit and integration tests following AAA pattern
+- **code-quality** - Enforces linting, static analysis, and security standards
+- **code-review** - Assists in performing formal file reviews
+- **repo-consistency** - Ensures VHDLTest remains consistent with TemplateDotNetTool template patterns
 
 ## Agent Selection Guide
 
-- Fix a bug → **Software Developer**
-- Add a new feature → **Requirements Agent** → **Software Developer** → **Test Developer**
-- Write a test → **Test Developer**
-- Fix linting or static analysis issues → **Code Quality Agent**
-- Update documentation → **Technical Writer**
-- Add or update requirements → **Requirements Agent**
-- Ensure test coverage linkage in `requirements.yaml` → **Requirements Agent**
-- Run security scanning or address CodeQL alerts → **Code Quality Agent**
-- Propagate template changes → **Repo Consistency Agent**
+- Fix a bug → **software-developer**
+- Add a new feature → **requirements** → **software-developer** → **test-developer**
+- Write a test → **test-developer**
+- Fix linting or static analysis issues → **code-quality**
+- Update documentation → **technical-writer**
+- Add or update requirements → **requirements**
+- Ensure test coverage linkage in `requirements.yaml` → **requirements**
+- Run security scanning or address CodeQL alerts → **code-quality**
+- Perform formal file reviews → **code-review**
+- Propagate template changes → **repo-consistency**
 
 ## Tech Stack
 
@@ -33,7 +35,17 @@ generating test reports.
 
 - **`requirements.yaml`** - All requirements with test linkage (enforced via `dotnet reqstream --enforce`)
 - **`.editorconfig`** - Code style (file-scoped namespaces, 4-space indent, UTF-8, LF endings)
-- **`.cspell.json`, `.markdownlint-cli2.jsonc`, `.yamllint.yaml`** - Linting configs
+- **`.cspell.yaml`, `.markdownlint-cli2.yaml`, `.yamllint.yaml`** - Linting configs
+
+### Spell Check Word List Policy
+
+**Never** add a word to the `.cspell.yaml` word list in order to silence a spell-checking failure.
+Doing so defeats the purpose of spell-checking and reduces the quality of the repository.
+
+- If cspell flags a word that is **misspelled**, fix the spelling in the source file.
+- If cspell flags a word that is a **genuine technical term** (tool name, project identifier, etc.) and is
+  spelled correctly, raise a **proposal** (e.g. comment in a pull request) explaining why the word
+  should be added. The proposal must be reviewed and approved before the word is added to the list.
 
 ## Requirements (VHDLTest-Specific)
 
@@ -113,7 +125,7 @@ build.bat     # Windows
 
 ## Markdown Link Style
 
-- **AI agent markdown files** (`.github/agents/*.md`): Use inline links `[text](url)` so URLs are visible in
+- **AI agent markdown files** (`.github/agents/*.agent.md`): Use inline links `[text](url)` so URLs are visible in
   agent context
 - **README.md**: Use absolute URLs (shipped in NuGet package)
 - **All other markdown files**: Use reference-style links `[text][ref]` with `[ref]: url` at document end
@@ -159,9 +171,10 @@ When agents need to write report files to communicate with each other or the use
 
 Delegate tasks to specialized agents for better results:
 
-- **requirements-agent** - Invoke for: creating/reviewing requirements, test coverage strategy
+- **requirements** - Invoke for: creating/reviewing requirements, test coverage strategy
 - **technical-writer** - Invoke for: documentation updates/reviews, markdown/spell/YAML linting
 - **software-developer** - Invoke for: production code implementation, refactoring for testability
 - **test-developer** - Invoke for: unit and integration tests, test coverage improvements
-- **code-quality-agent** - Invoke for: code quality reviews, linting, static analysis, security, zero-warning builds
-- **repo-consistency-agent** - Invoke for: checking consistency with TemplateDotNetTool template patterns
+- **code-quality** - Invoke for: code quality reviews, linting, static analysis, security, zero-warning builds
+- **code-review** - Invoke for: performing formal file reviews and compliance verification
+- **repo-consistency** - Invoke for: checking consistency with TemplateDotNetTool template patterns