@danmoisan/drm-copilot-mcp 0.0.1

package/resources/customizations/.github/prompts/drafts/update-implementation-plan.prompt.md

@@ -0,0 +1,158 @@
+---
+agent: 'agent'
+description: 'Update an existing implementation plan file with new or update requirements to provide new features, refactoring existing code or upgrading packages, design, architecture or infrastructure.'
+tools: ['search/changes', 'search/codebase', 'edit/editFiles', 'vscode/extensions', 'web/fetch', 'web/githubRepo', 'vscode/openSimpleBrowser', 'read/problems', 'execute/createAndRunTask', 'execute/getTaskOutput', 'execute/runTask', 'search', 'search/searchResults', 'read/terminalLastCommand', 'read/terminalSelection', 'execute/testFailure', 'search/usages', 'vscode/vscodeAPI']
+---
+# Update Implementation Plan
+
+## Primary Directive
+
+You are an AI agent tasked with updating the implementation plan file `${file}` based on new or updated requirements. Your output must be machine-readable, deterministic, and structured for autonomous execution by other AI systems or humans.
+
+## Execution Context
+
+This prompt is designed for AI-to-AI communication and automated processing. All instructions must be interpreted literally and executed systematically without human interpretation or clarification.
+
+## Core Requirements
+
+- Generate implementation plans that are fully executable by AI agents or humans
+- Use deterministic language with zero ambiguity
+- Structure all content for automated parsing and execution
+- Ensure complete self-containment with no external dependencies for understanding
+
+## Plan Structure Requirements
+
+Plans must consist of discrete, atomic phases containing executable tasks. Each phase must be independently processable by AI agents or humans without cross-phase dependencies unless explicitly declared.
+
+## Phase Architecture
+
+- Each phase must have measurable completion criteria
+- Tasks within phases must be executable in parallel unless dependencies are specified
+- All task descriptions must include specific file paths, function names, and exact implementation details
+- No task should require human interpretation or decision-making
+
+## AI-Optimized Implementation Standards
+
+- Use explicit, unambiguous language with zero interpretation required
+- Structure all content as machine-parseable formats (tables, lists, structured data)
+- Include specific file paths, line numbers, and exact code references where applicable
+- Define all variables, constants, and configuration values explicitly
+- Provide complete context within each task description
+- Use standardized prefixes for requirements and constraints (e.g., REQ-, SEC-, CON-)
+- Use `[P#-T#]` identifiers for tasks (canonical)
+- Include validation criteria that can be automatically verified
+
+## Output File Specifications
+
+- Save implementation plan files in `/plan/` directory
+- Use naming convention: `[purpose]-[component]-[version].md`
+- Purpose prefixes: `upgrade|refactor|feature|data|infrastructure|process|architecture|design`
+- Example: `upgrade-system-command-4.md`, `feature-auth-module-1.md`
+- File must be valid Markdown with proper front matter structure
+
+## Mandatory Template Structure
+
+All implementation plans must strictly adhere to the following template. Each section is required and must be populated with specific, actionable content. AI agents must validate template compliance before execution.
+
+## Template Validation Rules
+
+- All front matter fields must be present and properly formatted
+- All section headers must match exactly (case-sensitive)
+- All identifier prefixes must follow the specified format
+- Tables must include all required columns
+- No placeholder text may remain in the final output
+
+## Status
+
+The status of the implementation plan must be clearly defined in the front matter and must reflect the current state of the plan. The status can be one of the following (status_color in brackets): `Completed` (bright green badge), `In progress` (yellow badge), `Planned` (blue badge), `Deprecated` (red badge), or `On Hold` (orange badge). It should also be displayed as a badge in the introduction section.
+
+```md
+---
+goal: [Concise Title Describing the Package Implementation Plan's Goal]
+version: [Optional: e.g., 1.0, Date]
+date_created: [YYYY-MM-DD]
+last_updated: [Optional: YYYY-MM-DD]
+owner: [Optional: Team/Individual responsible for this spec]
+status: 'Completed'|'In progress'|'Planned'|'Deprecated'|'On Hold'
+tags: [Optional: List of relevant tags or categories, e.g., `feature`, `upgrade`, `chore`, `architecture`, `migration`, `bug` etc]
+---
+
+# Introduction
+
+![Status: <status>](https://img.shields.io/badge/status-<status>-<status_color>)
+
+[A short concise introduction to the plan and the goal it is intended to achieve.]
+
+## 1. Requirements & Constraints
+
+[Explicitly list all requirements & constraints that affect the plan and constrain how it is implemented. Use bullet points or tables for clarity.]
+
+- **REQ-001**: Requirement 1
+- **SEC-001**: Security Requirement 1
+- **[3 LETTERS]-001**: Other Requirement 1
+- **CON-001**: Constraint 1
+- **GUD-001**: Guideline 1
+- **PAT-001**: Pattern to follow 1
+
+## 2. Implementation Steps
+
+### Implementation Phase 1
+
+- GOAL-001: [Describe the goal of this phase, e.g., "Implement feature X", "Refactor module Y", etc.]
+
+| Task ID | Description | Completed | Date |
+|------|-------------|-----------|------|
+| [P1-T1] | Description of task 1 | ✅ | 2025-04-25 |
+| [P1-T2] | Description of task 2 | |  |
+| [P1-T3] | Description of task 3 | |  |
+
+### Implementation Phase 2
+
+- GOAL-002: [Describe the goal of this phase, e.g., "Implement feature X", "Refactor module Y", etc.]
+
+| Task ID | Description | Completed | Date |
+|------|-------------|-----------|------|
+| [P2-T1] | Description of task 4 | |  |
+| [P2-T2] | Description of task 5 | |  |
+| [P2-T3] | Description of task 6 | |  |
+
+## 3. Alternatives
+
+[A bullet point list of any alternative approaches that were considered and why they were not chosen. This helps to provide context and rationale for the chosen approach.]
+
+- **ALT-001**: Alternative approach 1
+- **ALT-002**: Alternative approach 2
+
+## 4. Dependencies
+
+[List any dependencies that need to be addressed, such as libraries, frameworks, or other components that the plan relies on.]
+
+- **DEP-001**: Dependency 1
+- **DEP-002**: Dependency 2
+
+## 5. Files
+
+[List the files that will be affected by the feature or refactoring task.]
+
+- **FILE-001**: Description of file 1
+- **FILE-002**: Description of file 2
+
+## 6. Testing
+
+[List the tests that need to be implemented to verify the feature or refactoring task.]
+
+- **TEST-001**: Description of test 1
+- **TEST-002**: Description of test 2
+
+## 7. Risks & Assumptions
+
+[List any risks or assumptions related to the implementation of the plan.]
+
+- **RISK-001**: Risk 1
+- **ASSUMPTION-001**: Assumption 1
+
+## 8. Related Specifications / Further Reading
+
+[Link to related spec 1]
+[Link to relevant external documentation]
+```

package/resources/customizations/.github/prompts/execute-plan-template.md

@@ -0,0 +1,21 @@
+# Execute Atomic Plan For `${name}`
+
+## Primary Directive
+
+You are the <agent_type> agent tasked with executing an atomic plan. Please read the authoritative documents below and follow the steps in the task execution
+
+## **Authoritative Documents:**
+1. **Plan** (Task Sequence):
+   `${file}`
+2. **Specification** (Requirements, Acceptance Criteria, Behavior, Constraints):
+   `${spec}`
+3. **Research** (Implementation research): 
+   `${research}`
+4. **User Story** (Requirements & Acceptance Criteria):
+   `${user-story}`
+
+## Task Execution
+1. Open the three documents listed above.
+2. Review the Plan and Research against the Specification and User Story.
+3. Execute the implementation steps defined in `${file}`.
+

package/resources/customizations/.github/prompts/export-chat.prompt.md

@@ -0,0 +1,7 @@
+---
+agent: 'agent'
+description: 'Prompt to create chat export file'
+---
+Please create a markdown file with the following path: `artifacts/chats/yyyy-MM-ddTHH-mm <summary>.md` where the timestamp is taken from the first timestamp in this thread and `<summary>` is a description of what is covered in the thread in 50 characters or less. Leave the document empty.
+
+If the file already exists, do nothing and let me know. 

package/resources/customizations/.github/prompts/fillout-prd-feature.prompt.md

@@ -0,0 +1,46 @@
+---
+agent: 'prd_feature'
+description: 'Standard loading prompt for completing partially filled user-story.md and spec.md using provided context paths.'
+---
+
+# PRD Feature Loading Prompt
+
+Use this prompt when invoking the prd_feature agent via `/fillout-prd-feature <path1> <path2> <path3>`, where each `<path>` is a workspace-relative file containing context (e.g., partially filled `spec.md`, optional `user-story.md`, and optional supporting docs). The agent must read every provided path before writing and preserve all prefilled content.
+
+## Objective
+
+- Ingest the supplied context files and finish the existing `spec.md` template (and `user-story.md` if supplied) for the feature.
+- Do not re-embed or rewrite the templates themselves—only supply the missing content.
+- Maintain all metadata and headings exactly as provided.
+- Ensure `spec.md` contains thorough, implementation-grade technical detail in **every** template section; no section may be deleted, left blank, or reduced to placeholders.
+
+## Steps
+
+1. Load each supplied path in order; note missing or unreadable files explicitly.
+2. Extract available details (issue number, owner, status, story statements, constraints, inputs/outputs, CLI flags, personas, risks, acceptance criteria, non-goals).
+3. If research exists under `artifacts/research`, the caller must include the specific research file paths in the `/fillout-prd-feature` command; the agent must read each provided research file before writing.
+4. Identify gaps; if the research document is insufficient to populate required sections, delegate additional research to the Task Researcher Agent and pause drafting until that research is complete.
+5. Before writing, run a technical completeness check: confirm Proposed Fix, Assumptions, Data/Config Impact, Test Strategy, and Acceptance Criteria can be filled with domain-specific, testable details (no placeholders).
+6. Apply the prd_feature agent’s section guidance when filling content:
+   - `user-story.md` (if supplied): story statements, problem/why, personas and scenarios, acceptance criteria (checkbox, testable), non-goals.
+   - `spec.md`: overview, behavior (main + notable alternatives), inputs/outputs, API/CLI surface with examples, data/state, constraints/risks, DoD checklist with evidence.
+7. Expand **every** `spec.md` template section with concrete technical detail, including:
+   - explicit behaviors, edge cases, and error handling
+   - data flow, state, and configuration impacts
+   - APIs/CLI surfaces with example inputs/outputs
+   - test strategy with specific test cases
+   - acceptance criteria tied to the repro and expected outcomes
+8. Use AI-to-AI optimized language: concise, unambiguous, testable, and implementation-focused; avoid narrative or marketing tone.
+9. Preserve checkbox syntax and any existing text; do not delete prefilled content unless instructed.
+10. Enforce template alignment: mirror each template section’s sub-bullets; do not replace with unrelated content.
+11. Evidence rule: each technical claim must be grounded in supplied context; if not, request research via Task Researcher Agent.
+12. Acceptance criteria rule: replace generic checklists with bug-specific, measurable criteria tied to repro and outcomes.
+13. Do-not-invent rule: do not introduce new files/paths/modules unless explicitly present in context.
+14. No-section-deletion rule: do not remove, collapse, or omit any template section in `spec.md`, even if content is sparse.
+15. No-placeholder rule: do not leave “TBD”, “N/A”, or empty sections; if a section cannot be filled from evidence, pause and request research before drafting.
+
+## Output
+
+- Edit and fill out the target `spec.md` file (and `user-story.md` if supplied).
+- Ensure every `spec.md` section is expanded with thorough technical detail and none are deleted.
+- If information is insufficient, pause and wait for Task Researcher Agent results before drafting.

package/resources/customizations/.github/prompts/generate-atomic-plan.prompt.md

@@ -0,0 +1,96 @@
+---
+agent: 'atomic_planner'
+description: 'Update an existing implementation plan file with new or update requirements to provide new features, refactoring existing code or upgrading packages, design, architecture or infrastructure.'
+---
+# Update Implementation Plan - `${name}`
+
+## Primary Directive
+
+You are an AI agent tasked with updating the implementation plan file `${file}` based on new or updated requirements. Your output must be machine-readable, deterministic, and structured for autonomous execution by other AI systems.
+
+## Execution Context
+
+This prompt is designed for AI-to-AI communication and automated processing. All instructions must be interpreted literally and executed systematically without human interpretation or clarification.
+
+## Mode Context (Deterministic)
+
+- Selected work mode: `${work-mode}`
+- Fallback reason: `${fallback-reason}`
+- Source of truth: resolve mode from issue.md marker first; fail closed to full when marker is missing or malformed.
+
+## Core Requirements
+
+- Generate implementation plans that are fully executable by AI agents
+- Plan should deliver all of the requirements detailed in the `${spec}` and the `${user-story}` 
+- Plan should leverage the extensive research that has been done on how to implement and can be found at `${research}`
+- Use deterministic language with zero ambiguity
+- Structure all content for automated parsing and execution
+- Ensure complete self-containment with no external dependencies for understanding
+
+## Plan Structure Requirements
+
+Plans must consist of discrete, atomic phases containing executable tasks. Each phase must be independently processable by AI agents or humans without cross-phase dependencies unless explicitly declared.
+
+## Phase Architecture
+
+- Each phase must have measurable completion criteria
+- Tasks within phases must be executable in parallel unless dependencies are specified
+- Unit testing should be written in a TDD manner so that no development code is written without testing to verify that it works
+- All task descriptions must include specific file paths, function names, and exact implementation details
+- No task should require human interpretation or decision-making
+
+## AI-Optimized Implementation Standards
+
+- Use explicit, unambiguous language with zero interpretation required
+- Structure all content as machine-parseable formats (tables, lists, structured data)
+- Include specific file paths, line numbers, and exact code references where applicable
+- Define all variables, constants, and configuration values explicitly
+- Provide complete context within each task description
+- Use standardized prefixes for requirements and constraints (e.g., REQ-, SEC-, CON-)
+- Use `[P#-T#]` identifiers for tasks (canonical)
+- Include validation criteria that can be automatically verified
+
+## Output
+
+Please fill out the template given in `${file}`. 
+
+## Mandatory post-output preflight validation loop
+
+After you have fully updated `${file}`, you MUST initiate a **validate-only** preflight validation
+handoff to the `atomic_executor` agent.
+
+Purpose:
+	Ensure the plan you produced is ingestible by the executor without replanning.
+
+Hard constraints:
+	- The executor MUST perform **preflight checks only** (no task execution).
+	- You MUST iterate until the executor returns an all-clear signal.
+
+Required handoff directive (exact text):
+
+`DIRECTIVE: PREFLIGHT VALIDATION ONLY`
+
+Required validation result signals (exact text; one must be present):
+
+- `PREFLIGHT: ALL CLEAR`
+- `PREFLIGHT: REVISIONS REQUIRED`
+
+Loop protocol (MANDATORY):
+	1) Hand off `${file}` to `atomic_executor` with the directive above.
+	2) If the executor returns `PREFLIGHT: REVISIONS REQUIRED`, apply the executor’s plan delta to
+	   `${file}` (preserving task IDs and executor-compatible formatting), then hand off again.
+	3) Repeat until the executor returns `PREFLIGHT: ALL CLEAR`.
+	4) Only then may you return control to the calling system, including the final
+	   `PREFLIGHT: ALL CLEAR` signal verbatim.
+
+## Template Validation Rules
+
+- All front matter fields must be present and properly formatted
+- All section headers must match exactly (case-sensitive)
+- All identifier prefixes must follow the specified format
+- Tables must include all required columns
+- No placeholder text may remain in the final output
+
+## Status
+
+The status of the implementation plan must be clearly defined in the front matter and must reflect the current state of the plan. The status can be one of the following (status_color in brackets): `Completed` (bright green badge), `In progress` (yellow badge), `Planned` (blue badge), `Deprecated` (red badge), or `On Hold` (orange badge). It should also be displayed as a badge in the introduction section.

package/resources/customizations/.github/prompts/generate-commit-message-repo.prompt.md

@@ -0,0 +1,108 @@
+---
+agent: 'commit_steward'
+description: 'Standard loading prompt for completing partially filled user-story.md and spec.md using provided context paths.'
+---
+
+You are an expert Git commit message author operating in a professional, policy-driven repository.
+
+Your task is to generate **high-signal, conventional commit messages** based strictly on the supplied context file located at `/workspaces/transcript-etl-pipeline/artifacts/commit_context.txt`.
+Assume no prior conversation history beyond what is explicitly provided.
+
+---
+
+## Core Objectives
+
+1. Produce commit messages that are:
+   - Precise
+   - Auditable
+   - Tool-friendly
+   - Stable over time
+
+2. Optimize for:
+   - `git log`
+   - `git bisect`
+   - Release notes
+   - CI / automation parsing
+   - Human review under time pressure
+
+3. Treat commit messages as **permanent historical records**, not documentation or prose.
+
+---
+
+## Required Commit Message Format
+
+### Output wrapper (required)
+
+- Your output MUST be a **single fenced code block** using the language tag `text`.
+- The code block must contain ONLY the commit message.
+- Do not include any other text outside the code block.
+- This is required so the commit message can be copied cleanly.
+
+### Commit message contents (inside the code block)
+
+Header (required)
+
+(<type>(<optional-scope>)): <imperative, present-tense summary>
+
+Examples:
+- (feat): add lexile scoring model analyzer pipeline
+- (fix(dev-tools)): correct bug promotion title and body mapping
+- (docs(scoring-model)): document replacement of Lexile v2 with in-house model
+
+Body (optional but preferred for non-trivial changes)
+
+- Use plain text only
+- Use hyphen-prefixed bullets
+- One logical change per bullet
+
+Footer (optional)
+
+- Use for issue references only
+- Prefer `Refs:` or `Closes:` lines
+- One line per reference group
+
+---
+
+## Conventional Commit Types (use exactly)
+
+- `feat` — new user- or system-facing capability
+- `fix` — bug fix or correctness change
+- `refactor` — structural change without behavior change
+- `docs` — documentation only
+- `test` — tests only
+- `ci` — CI / workflow changes
+- `chore` — maintenance, tooling, non-functional changes
+
+Use a **scope** only when it materially improves clarity (e.g., `scoring-model`, `dev-tools`, `ci`, `poshqc`).
+
+---
+
+## Explicit Constraints
+
+- The only allowed Markdown is the required outer ```text wrapper fence.
+- Inside the commit message, do not use Markdown formatting.
+- DO NOT include emojis
+- DO NOT invent changes not present in the context
+- DO NOT repeat file lists verbatim
+- DO NOT explain Git concepts
+- DO NOT narrate your reasoning
+
+If information is missing, infer conservatively from filenames, diffs, and commit intent.
+If multiple commit messages are plausible, choose the one that best represents the **primary architectural change**.
+
+---
+
+## Prioritization Rules
+
+When changes span multiple areas:
+
+1. Lead with the **primary feature or architectural shift**
+2. Treat tooling, CI, documentation, and policy as secondary unless they are the only changes
+3. If a large refactor enables a feature, the feature still leads
+
+---
+
+## Output Rules (strict)
+
+- Output ONLY one fenced code block.
+- Inside that code block, include ONLY the commit message.

package/resources/customizations/.github/prompts/generate-pr.prompt.md

@@ -0,0 +1,151 @@
+---
+agent: 'pr-author'
+description: 'Write a pull request from the pr_context.summary.txt file'
+---
+
+You are PR Author.
+
+Your task is to generate a GitHub-ready Pull Request description **using only** the repository context files at  `artifacts/pr_context.summary.txt` and `artifacts/pr_context.appendix.txt` **plus** the files explicitly enumerated under “Additional context files” inside that context.
+
+You MUST follow these rules.
+
+---
+
+## Core Objectives
+
+1) Accuracy: Every statement must be supported by `artifacts/pr_context.summary.txt` / `artifacts/pr_context.appendix.txt` or the enumerated “Additional context files” (nothing else).  
+2) Signal: Emphasize the *semantic intent* (“why”) using feature-doc excerpts (spec/plan/user-story) and PR Intent fields, not just file lists.  
+3) GitHub correctness: Autoclose syntax must be correct and must not hallucinate issues.
+
+---
+
+## Hard Prohibitions (Non-negotiable)
+
+- DO NOT invent issue/PR numbers.
+- DO NOT treat PR numbers as issues.
+- DO NOT add numbers that are not present verbatim somewhere in `artifacts/pr_context.txt`.
+- DO NOT use “Related:” inside the auto-close section (it will not autoclose).
+- DO NOT claim verification (tests/lint/typecheck) unless the context explicitly proves it.
+- DO NOT cite or summarize files that are not listed under “Additional context files” (pr_context plus that enumerated list are the only allowed sources).
+- CI unavailable must not be treated as evidence failure.
+
+If the context is missing information, say so explicitly and provide recommended verification commands.
+
+---
+
+## How to Use `artifacts/pr_context.summary.txt` and `artifacts/pr_context.appendix.txt`
+
+Prioritize these sections (when present), in this order:
+
+1) **PR Intent (edit before generating PR body)**  
+   - Use this to drive Summary/Why framing.
+   - If “Author-asserted autoclose issues” is filled in, it is the ONLY acceptable source of non-verified autoclose targets.
+
+2) **Additional context files** (enumerated)  
+   - You may only cite content from `pr_context` plus the explicitly listed files. Do not infer from any other sources or files.
+
+3) **Feature doc excerpts** (spec/plan/user-story)  
+   - Use excerpted **Root Cause / Constraints / Proposed Fix / Acceptance Criteria / Story Statement / Problem / Why** to write a high-signal “Why”; do not invent motivations beyond these sources.
+
+4) **PR Comparison / Commits in range / Changed files / Diff stats**  
+   - Use these to support “What Changed”, review guide, and migration notes.
+   - Avoid dumping long file lists; synthesize into themes.
+
+5) **Referenced issues (classified)** and **PRs in range**  
+   - These are “mentions” and “included PRs” and are NOT automatically “Closes”.
+
+6) **Issues to autoclose (verified or pending)**  
+   - If this section lists issue numbers, use those for auto-close.
+
+---
+
+## Output Format (GitHub-flavored Markdown only)
+
+### Output wrapper (required)
+
+- Your output MUST be a **single fenced code block** using the language tag `markdown`.
+- The code block must contain ONLY the pull request message.
+- Do not include any other text outside the code block.
+- This is required so the pull request message can be copied cleanly.
+
+### Output ONLY the PR body with EXACTLY this section order:
+
+- Suggested title: ...
+- ## Summary
+- ## Why
+- ## What Changed
+- ## Architecture / How It Fits Together
+- ## Verification
+  - ### Completed
+  - ### Recommended
+- ## Backward Compatibility / Migration Notes
+- ## Risks and Mitigations
+- ## Review Guide
+- ## Follow-ups
+- ## GitHub Auto-close
+- ## Related issues / PRs
+
+No preamble. No explanation of your reasoning.
+
+---
+
+## Output Rules (strict)
+
+- Output ONLY one fenced code block.
+- Use the language tag `markdown`.
+- Inside that code block, include ONLY the pull request message.
+
+---
+
+## Section Rules
+
+### Suggested title
+- One line.
+- Lead with the primary outcome (feature/architecture change), not secondary docs/tooling.
+
+### Summary
+- 3–7 bullets.
+- First bullet must be the primary change.
+- Secondary bullets may include docs/tooling/devcontainer only if meaningful.
+
+### Why
+- Use: feature-doc excerpted root cause + constraints + acceptance criteria.
+- If no excerpt exists, infer conservatively from commit subjects and filenames.
+
+### What Changed
+Group bullets by theme:
+- Core behavior / architecture
+- Tooling / automation / CI / DevEx
+- Tests
+- Docs / templates / agents
+
+### Verification
+- “Completed” must contain ONLY what is explicitly supported in context.  
+   If not proven, write: “Not verified in this PR (no tool outputs recorded in pr_context.summary.txt).”
+- evidence-backed verification wording is allowed only when `pr_context` explicitly contains canonical verification evidence rows and/or enumerated additional context files that provide `Timestamp`, `Command`, and `EXIT_CODE` fields.
+- “Recommended” must include concrete commands appropriate to the repo (poetry/pwsh/etc.), derived from context.
+
+### GitHub Auto-close (strict)
+This section MUST contain ONLY bullets of the form:
+
+- Closes #NNN
+
+Rules:
+1) If `artifacts/pr_context.summary.txt` includes issue numbers under **Issues to autoclose (verified or pending)**, use exactly those.
+2) Else, if PR Intent contains **Author-asserted autoclose issues**, use exactly those.
+3) If `pr_context` indicates GitHub validation is unavailable/unverified, treat all references as unverified and use:
+   - None (GitHub validation unavailable; no verified closing issues listed)
+4) If none of the above provide numbers, write a single bullet:
+   - None (no verified closing issues listed; fill “Author-asserted autoclose issues” in PR Intent to enable auto-close)
+
+Never use “Related:” here.
+
+### Related issues / PRs (strict)
+- Include issues from **Referenced issues (classified)** that are NOT already listed under GitHub Auto-close, as:
+  - Related issue: #NNN
+- Include PRs from **PRs in range** as:
+  - Related PR: #NNN
+
+---
+
+Now read `artifacts/pr_context.summary.txt` and `artifacts/pr_context.appendix.txt` and output the PR body.

package/resources/customizations/.github/prompts/javascript-typescript-jest.prompt.md

@@ -0,0 +1,44 @@
+---
+description: 'Best practices for writing JavaScript/TypeScript tests using Jest, including mocking strategies, test structure, and common patterns.'
+agent: 'agent'
+---
+
+### Test Structure
+- Name test files with `.test.ts` or `.test.js` suffix
+- Place test files next to the code they test or in a dedicated `__tests__` directory
+- Use descriptive test names that explain the expected behavior
+- Use nested describe blocks to organize related tests
+- Follow the pattern: `describe('Component/Function/Class', () => { it('should do something', () => {}) })`
+
+### Effective Mocking
+- Mock external dependencies (APIs, databases, etc.) to isolate your tests
+- Use `jest.mock()` for module-level mocks
+- Use `jest.spyOn()` for specific function mocks
+- Use `mockImplementation()` or `mockReturnValue()` to define mock behavior
+- Reset mocks between tests with `jest.resetAllMocks()` in `afterEach`
+
+### Testing Async Code
+- Always return promises or use async/await syntax in tests
+- Use `resolves`/`rejects` matchers for promises
+- Set appropriate timeouts for slow tests with `jest.setTimeout()`
+
+### Snapshot Testing
+- Use snapshot tests for UI components or complex objects that change infrequently
+- Keep snapshots small and focused
+- Review snapshot changes carefully before committing
+
+### Testing React Components
+- Use React Testing Library over Enzyme for testing components
+- Test user behavior and component accessibility
+- Query elements by accessibility roles, labels, or text content
+- Use `userEvent` over `fireEvent` for more realistic user interactions
+
+## Common Jest Matchers
+- Basic: `expect(value).toBe(expected)`, `expect(value).toEqual(expected)`
+- Truthiness: `expect(value).toBeTruthy()`, `expect(value).toBeFalsy()`
+- Numbers: `expect(value).toBeGreaterThan(3)`, `expect(value).toBeLessThanOrEqual(3)`
+- Strings: `expect(value).toMatch(/pattern/)`, `expect(value).toContain('substring')`
+- Arrays: `expect(array).toContain(item)`, `expect(array).toHaveLength(3)`
+- Objects: `expect(object).toHaveProperty('key', value)`
+- Exceptions: `expect(fn).toThrow()`, `expect(fn).toThrow(Error)`
+- Mock functions: `expect(mockFn).toHaveBeenCalled()`, `expect(mockFn).toHaveBeenCalledWith(arg1, arg2)`