diff --git a/.github/instructions/languages/cdk.instructions.md b/.github/instructions/languages/cdk.instructions.md
index b441a02..3590eb8 100644
--- a/.github/instructions/languages/cdk.instructions.md
+++ b/.github/instructions/languages/cdk.instructions.md
@@ -88,11 +88,27 @@ export class CptsApiAppStack extends Stack {
 - Prefer VPC endpoints for private connectivity
 - Minimize resource creation in test environments
 
+## Unit Testing
+
+- Write unit tests for CDK stacks and constructs using synthesis-based assertions.
+- Prefer in-process tests that instantiate CDK `App` and `Stack` objects directly and assert on synthesized templates.
+- Keep assertions light-touch and stable, such as resource counts and a small number of important properties.
+- Avoid mocking AWS resources or writing tests that attempt to exercise live AWS behaviour.
+- CDK constructs suitable for reuse should be placed in `eps-cdk-utils` repo.
+- Smaller CDK constructs may be included here and should have associated tests.
+- Do not test AWS implementation details owned by the CDK library. Test the resources and properties your code is responsible for declaring.
+
+### Recommended Test Styles
+
+- Smoke tests for `bin/` files: execute the entrypoint and assert that synthesis completes without throwing.
+- In-process synth tests for stacks and constructs: instantiate the stack directly and assert resource counts or key CloudFormation properties with `Template.fromStack(...)`.
+
 
 ## Validation and Verification
 
 - Build: `make cdk-synth`
 - Lint: `npm run lint --workspace packages/cdk`
+- Test: `npm test --workspace packages/cdk`
 
 ## Maintenance
 
diff --git a/.github/instructions/languages/typescript.instructions.md b/.github/instructions/languages/typescript.instructions.md
index 4c15f42..beddb89 100644
--- a/.github/instructions/languages/typescript.instructions.md
+++ b/.github/instructions/languages/typescript.instructions.md
@@ -23,6 +23,7 @@ This document provides instructions for generating, reviewing, and maintaining T
 - Use destructuring for objects and arrays to improve readability.
 - Avoid magic numbers and hardcoded values; use named constants.
 - Keep functions pure and side-effect free when possible.
+- Do not use the `void` operator to silence unused-value warnings; prefer code that makes usage explicit.
 
 ## Code Standards
 
@@ -92,6 +93,7 @@ This document provides instructions for generating, reviewing, and maintaining T
 ### Type Safety
 
 - Prefer interfaces and types. You MUST NOT use `any`.
+- Prefer `Array<T>` over `T[]` for array type annotations.
 - Use type guards and assertions when necessary.
 - Example: