@danmoisan/drm-copilot-mcp 0.0.1

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

@@ -0,0 +1,61 @@
+---
+agent: 'prd_creator'
+description: 'Prompt for creating Product Requirements Documents (PRDs) for new features, based on an Epic.'
+---
+
+# Feature PRD Prompt
+
+## Goal
+
+Act as an expert Product Manager for a large-scale SaaS platform. Your primary responsibility is to take a high-level feature or enabler from an Epic and create a detailed Product Requirements Document (PRD). This PRD will serve as the single source of truth for the engineering team and will be used to generate a comprehensive technical specification.
+
+Review the user's request for a new feature and the parent Epic, and generate a thorough PRD. If you don't have enough information, ask clarifying questions to ensure all aspects of the feature are well-defined.
+
+## Output Format
+
+The output should be a complete PRD in Markdown format, saved to `/docs/ways-of-work/plan/{epic-name}/{feature-name}/prd.md`.
+
+### PRD Structure
+
+#### 1. Feature Name
+
+- A clear, concise, and descriptive name for the feature.
+
+#### 2. Epic
+
+- Link to the parent Epic PRD and Architecture documents.
+
+#### 3. Goal
+
+- **Problem:** Describe the user problem or business need this feature addresses (3-5 sentences).
+- **Solution:** Explain how this feature solves the problem.
+- **Impact:** What are the expected outcomes or metrics to be improved (e.g., user engagement, conversion rate, etc.)?
+
+#### 4. User Personas
+
+- Describe the target user(s) for this feature.
+
+#### 5. User Stories
+
+- Write user stories in the format: "As a `<user persona>`, I want to `<perform an action>` so that I can `<achieve a benefit>`."
+- Cover the primary paths and edge cases.
+
+#### 6. Requirements
+
+- **Functional Requirements:** A detailed, bulleted list of what the system must do. Be specific and unambiguous.
+- **Non-Functional Requirements:** A bulleted list of constraints and quality attributes (e.g., performance, security, accessibility, data privacy).
+
+#### 7. Acceptance Criteria
+
+- For each user story or major requirement, provide a set of acceptance criteria.
+- Use a clear format, such as a checklist or Given/When/Then. This will be used to validate that the feature is complete and correct.
+
+#### 8. Out of Scope
+
+- Clearly list what is _not_ included in this feature to avoid scope creep.
+
+## Context Template
+
+- **Epic:** [Link to the parent Epic documents]
+- **Feature Idea:** [A high-level description of the feature request from the user]
+- **Target Users:** [Optional: Any initial thoughts on who this is for]

package/resources/customizations/.github/prompts/code-exemplars-blueprint-generator.prompt.md

@@ -0,0 +1,126 @@
+---
+description: 'Technology-agnostic prompt generator that creates customizable AI prompts for scanning codebases and identifying high-quality code exemplars. Supports multiple programming languages (.NET, Java, JavaScript, TypeScript, React, Angular, Python) with configurable analysis depth, categorization methods, and documentation formats to establish coding standards and maintain consistency across development teams.'
+agent: 'agent'
+---
+
+# Code Exemplars Blueprint Generator
+
+## Configuration Variables
+${PROJECT_TYPE="Auto-detect|.NET|Java|JavaScript|TypeScript|React|Angular|Python|Other"} <!-- Primary technology -->
+${SCAN_DEPTH="Basic|Standard|Comprehensive"} <!-- How deeply to analyze the codebase -->
+${INCLUDE_CODE_SNIPPETS=true|false} <!-- Include actual code snippets in addition to file references -->
+${CATEGORIZATION="Pattern Type|Architecture Layer|File Type"} <!-- How to organize exemplars -->
+${MAX_EXAMPLES_PER_CATEGORY=3} <!-- Maximum number of examples per category -->
+${INCLUDE_COMMENTS=true|false} <!-- Include explanatory comments for each exemplar -->
+
+## Generated Prompt
+
+"Scan this codebase and generate an exemplars.md file that identifies high-quality, representative code examples. The exemplars should demonstrate our coding standards and patterns to help maintain consistency. Use the following approach:
+
+### 1. Codebase Analysis Phase
+- ${PROJECT_TYPE == "Auto-detect" ? "Automatically detect primary programming languages and frameworks by scanning file extensions and configuration files" : `Focus on ${PROJECT_TYPE} code files`}
+- Identify files with high-quality implementation, good documentation, and clear structure
+- Look for commonly used patterns, architecture components, and well-structured implementations
+- Prioritize files that demonstrate best practices for our technology stack
+- Only reference actual files that exist in the codebase - no hypothetical examples
+
+### 2. Exemplar Identification Criteria
+- Well-structured, readable code with clear naming conventions
+- Comprehensive comments and documentation
+- Proper error handling and validation
+- Adherence to design patterns and architectural principles
+- Separation of concerns and single responsibility principle
+- Efficient implementation without code smells
+- Representative of our standard approaches
+
+### 3. Core Pattern Categories
+
+${PROJECT_TYPE == ".NET" || PROJECT_TYPE == "Auto-detect" ? `#### .NET Exemplars (if detected)
+- **Domain Models**: Find entities that properly implement encapsulation and domain logic
+- **Repository Implementations**: Examples of our data access approach
+- **Service Layer Components**: Well-structured business logic implementations
+- **Controller Patterns**: Clean API controllers with proper validation and responses
+- **Dependency Injection Usage**: Good examples of DI configuration and usage
+- **Middleware Components**: Custom middleware implementations
+- **Unit Test Patterns**: Well-structured tests with proper arrangement and assertions` : ""}
+
+${(PROJECT_TYPE == "JavaScript" || PROJECT_TYPE == "TypeScript" || PROJECT_TYPE == "React" || PROJECT_TYPE == "Angular" || PROJECT_TYPE == "Auto-detect") ? `#### Frontend Exemplars (if detected)
+- **Component Structure**: Clean, well-structured components
+- **State Management**: Good examples of state handling
+- **API Integration**: Well-implemented service calls and data handling
+- **Form Handling**: Validation and submission patterns
+- **Routing Implementation**: Navigation and route configuration
+- **UI Components**: Reusable, well-structured UI elements
+- **Unit Test Examples**: Component and service tests` : ""}
+
+${PROJECT_TYPE == "Java" || PROJECT_TYPE == "Auto-detect" ? `#### Java Exemplars (if detected)
+- **Entity Classes**: Well-designed JPA entities or domain models
+- **Service Implementations**: Clean service layer components
+- **Repository Patterns**: Data access implementations
+- **Controller/Resource Classes**: API endpoint implementations
+- **Configuration Classes**: Application configuration
+- **Unit Tests**: Well-structured JUnit tests` : ""}
+
+${PROJECT_TYPE == "Python" || PROJECT_TYPE == "Auto-detect" ? `#### Python Exemplars (if detected)
+- **Class Definitions**: Well-structured classes with proper documentation
+- **API Routes/Views**: Clean API implementations
+- **Data Models**: ORM model definitions
+- **Service Functions**: Business logic implementations
+- **Utility Modules**: Helper and utility functions
+- **Test Cases**: Well-structured unit tests` : ""}
+
+### 4. Architecture Layer Exemplars
+
+- **Presentation Layer**:
+  - User interface components
+  - Controllers/API endpoints
+  - View models/DTOs
+  
+- **Business Logic Layer**:
+  - Service implementations
+  - Business logic components
+  - Workflow orchestration
+  
+- **Data Access Layer**:
+  - Repository implementations
+  - Data models
+  - Query patterns
+  
+- **Cross-Cutting Concerns**:
+  - Logging implementations
+  - Error handling
+  - Authentication/authorization
+  - Validation
+
+### 5. Exemplar Documentation Format
+
+For each identified exemplar, document:
+- File path (relative to repository root)
+- Brief description of what makes it exemplary
+- Pattern or component type it represents
+${INCLUDE_COMMENTS ? "- Key implementation details and coding principles demonstrated" : ""}
+${INCLUDE_CODE_SNIPPETS ? "- Small, representative code snippet (if applicable)" : ""}
+
+${SCAN_DEPTH == "Comprehensive" ? `### 6. Additional Documentation
+
+- **Consistency Patterns**: Note consistent patterns observed across the codebase
+- **Architecture Observations**: Document architectural patterns evident in the code
+- **Implementation Conventions**: Identify naming and structural conventions
+- **Anti-patterns to Avoid**: Note any areas where the codebase deviates from best practices` : ""}
+
+### ${SCAN_DEPTH == "Comprehensive" ? "7" : "6"}. Output Format
+
+Create exemplars.md with:
+1. Introduction explaining the purpose of the document
+2. Table of contents with links to categories
+3. Organized sections based on ${CATEGORIZATION}
+4. Up to ${MAX_EXAMPLES_PER_CATEGORY} exemplars per category
+5. Conclusion with recommendations for maintaining code quality
+
+The document should be actionable for developers needing guidance on implementing new features consistent with existing patterns.
+
+Important: Only include actual files from the codebase. Verify all file paths exist. Do not include placeholder or hypothetical examples.
+"
+
+## Expected Output
+Upon running this prompt, GitHub Copilot will scan your codebase and generate an exemplars.md file containing real references to high-quality code examples in your repository, organized according to your selected parameters.

package/resources/customizations/.github/prompts/drafts/create-github-issues-feature-from-implementation-plan.prompt.md

@@ -0,0 +1,28 @@
+---
+agent: 'agent'
+description: 'Create GitHub Issues from implementation plan phases using feature_request.yml or chore_request.yml templates.'
+tools: ['search/codebase', 'search', 'github', 'create_issue', 'search_issues', 'update_issue']
+---
+# Create GitHub Issue from Implementation Plan
+
+Create GitHub Issues for the implementation plan at `${file}`.
+
+## Process
+
+1. Analyze plan file to identify phases
+2. Check existing issues using `search_issues`
+3. Create new issue per phase using `create_issue` or update existing with `update_issue`
+4. Use `feature_request.yml` or `chore_request.yml` templates (fallback to default)
+
+## Requirements
+
+- One issue per implementation phase
+- Clear, structured titles and descriptions
+- Include only changes required by the plan
+- Verify against existing issues before creation
+
+## Issue Content
+
+- Title: Phase name from implementation plan
+- Description: Phase details, requirements, and context
+- Labels: Appropriate for issue type (feature/chore)

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

@@ -0,0 +1,158 @@
+---
+agent: 'prd_creator'
+description: 'Create a new implementation plan file for 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']
+---
+# Create Implementation Plan
+
+## Primary Directive
+
+Your goal is to create a new implementation plan file for `${input:PlanPurpose}`. 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/drafts/create-technical-spike.prompt.md

@@ -0,0 +1,231 @@
+---
+agent: 'agent'
+description: 'Create time-boxed technical spike documents for researching and resolving critical development decisions before implementation.'
+tools: ['execute/getTerminalOutput', 'execute/runInTerminal', 'read/terminalLastCommand', 'read/terminalSelection', 'execute/createAndRunTask', 'execute/getTaskOutput', 'execute/runTask', 'edit', 'search', 'vscode/extensions', 'search/usages', 'vscode/vscodeAPI', 'read/problems', 'search/changes', 'execute/testFailure', 'vscode/openSimpleBrowser', 'web/fetch', 'web/githubRepo', 'todo',  'search']
+---
+
+# Create Technical Spike Document
+
+Create time-boxed technical spike documents for researching critical questions that must be answered before development can proceed. Each spike focuses on a specific technical decision with clear deliverables and timelines.
+
+## Document Structure
+
+Create individual files in `${input:FolderPath|docs/spikes}` directory. Name each file using the pattern: `[category]-[short-description]-spike.md` (e.g., `api-copilot-integration-spike.md`, `performance-realtime-audio-spike.md`).
+
+```md
+---
+title: "${input:SpikeTitle}"
+category: "${input:Category|Technical}"
+status: "🔴 Not Started"
+priority: "${input:Priority|High}"
+timebox: "${input:Timebox|1 week}"
+created: [YYYY-MM-DD]
+updated: [YYYY-MM-DD]
+owner: "${input:Owner}"
+tags: ["technical-spike", "${input:Category|technical}", "research"]
+---
+
+# ${input:SpikeTitle}
+
+## Summary
+
+**Spike Objective:** [Clear, specific question or decision that needs resolution]
+
+**Why This Matters:** [Impact on development/architecture decisions]
+
+**Timebox:** [How much time allocated to this spike]
+
+**Decision Deadline:** [When this must be resolved to avoid blocking development]
+
+## Research Question(s)
+
+**Primary Question:** [Main technical question that needs answering]
+
+**Secondary Questions:**
+
+- [Related question 1]
+- [Related question 2]
+- [Related question 3]
+
+## Investigation Plan
+
+### Research Tasks
+
+- [ ] [Specific research task 1]
+- [ ] [Specific research task 2]
+- [ ] [Specific research task 3]
+- [ ] [Create proof of concept/prototype]
+- [ ] [Document findings and recommendations]
+
+### Success Criteria
+
+**This spike is complete when:**
+
+- [ ] [Specific criteria 1]
+- [ ] [Specific criteria 2]
+- [ ] [Clear recommendation documented]
+- [ ] [Proof of concept completed (if applicable)]
+
+## Technical Context
+
+**Related Components:** [List system components affected by this decision]
+
+**Dependencies:** [What other spikes or decisions depend on resolving this]
+
+**Constraints:** [Known limitations or requirements that affect the solution]
+
+## Research Findings
+
+### Investigation Results
+
+[Document research findings, test results, and evidence gathered]
+
+### Prototype/Testing Notes
+
+[Results from any prototypes, spikes, or technical experiments]
+
+### External Resources
+
+- [Link to relevant documentation]
+- [Link to API references]
+- [Link to community discussions]
+- [Link to examples/tutorials]
+
+## Decision
+
+### Recommendation
+
+[Clear recommendation based on research findings]
+
+### Rationale
+
+[Why this approach was chosen over alternatives]
+
+### Implementation Notes
+
+[Key considerations for implementation]
+
+### Follow-up Actions
+
+- [ ] [Action item 1]
+- [ ] [Action item 2]
+- [ ] [Update architecture documents]
+- [ ] [Create implementation tasks]
+
+## Status History
+
+| Date   | Status         | Notes                      |
+| ------ | -------------- | -------------------------- |
+| [Date] | 🔴 Not Started | Spike created and scoped   |
+| [Date] | 🟡 In Progress | Research commenced         |
+| [Date] | 🟢 Complete    | [Resolution summary]       |
+
+---
+
+_Last updated: [Date] by [Name]_
+```
+
+## Categories for Technical Spikes
+
+### API Integration
+
+- Third-party API capabilities and limitations
+- Integration patterns and authentication
+- Rate limits and performance characteristics
+
+### Architecture & Design
+
+- System architecture decisions
+- Design pattern applicability
+- Component interaction models
+
+### Performance & Scalability
+
+- Performance requirements and constraints
+- Scalability bottlenecks and solutions
+- Resource utilization patterns
+
+### Platform & Infrastructure
+
+- Platform capabilities and limitations
+- Infrastructure requirements
+- Deployment and hosting considerations
+
+### Security & Compliance
+
+- Security requirements and implementations
+- Compliance constraints
+- Authentication and authorization approaches
+
+### User Experience
+
+- User interaction patterns
+- Accessibility requirements
+- Interface design decisions
+
+## File Naming Conventions
+
+Use descriptive, kebab-case names that indicate the category and specific unknown:
+
+**API/Integration Examples:**
+
+- `api-copilot-chat-integration-spike.md`
+- `api-azure-speech-realtime-spike.md`
+- `api-vscode-extension-capabilities-spike.md`
+
+**Performance Examples:**
+
+- `performance-audio-processing-latency-spike.md`
+- `performance-extension-host-limitations-spike.md`
+- `performance-webrtc-reliability-spike.md`
+
+**Architecture Examples:**
+
+- `architecture-voice-pipeline-design-spike.md`
+- `architecture-state-management-spike.md`
+- `architecture-error-handling-strategy-spike.md`
+
+## Best Practices for AI Agents
+
+1. **One Question Per Spike:** Each document focuses on a single technical decision or research question
+
+2. **Time-Boxed Research:** Define specific time limits and deliverables for each spike
+
+3. **Evidence-Based Decisions:** Require concrete evidence (tests, prototypes, documentation) before marking as complete
+
+4. **Clear Recommendations:** Document specific recommendations and rationale for implementation
+
+5. **Dependency Tracking:** Identify how spikes relate to each other and impact project decisions
+
+6. **Outcome-Focused:** Every spike must result in an actionable decision or recommendation
+
+## Research Strategy
+
+### Phase 1: Information Gathering
+
+1. **Search existing documentation** using search/fetch tools
+2. **Analyze codebase** for existing patterns and constraints
+3. **Research external resources** (APIs, libraries, examples)
+
+### Phase 2: Validation & Testing
+
+1. **Create focused prototypes** to test specific hypotheses
+2. **Run targeted experiments** to validate assumptions
+3. **Document test results** with supporting evidence
+
+### Phase 3: Decision & Documentation
+
+1. **Synthesize findings** into clear recommendations
+2. **Document implementation guidance** for development team
+3. **Create follow-up tasks** for implementation
+
+## Tools Usage
+
+- **search/searchResults:** Research existing solutions and documentation
+- **fetch/githubRepo:** Analyze external APIs, libraries, and examples
+- **codebase:** Understand existing system constraints and patterns
+- **runTasks:** Execute prototypes and validation tests
+- **editFiles:** Update research progress and findings
+- **vscodeAPI:** Test VS Code extension capabilities and limitations
+
+Focus on time-boxed research that resolves critical technical decisions and unblocks development progress.

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

@@ -0,0 +1,19 @@
+---
+description: 'Prompt for creating Potential Feature Document ("PFD") for new features.'
+---
+
+# Potential Feature Prompt
+
+## Goal
+
+Act as an expert Product Manager for a large-scale SaaS platform. Your primary responsibility is to take a high-level idea and create a detailed potential feature document ("PFD"). This preliminary document will serve as the single source of truth which will later be used to develop detailed user stories, technical specifications, and implementation plans.
+
+Review the user's request for a new feature and the parent Epic, and generate a thorough PFD. If you don't have enough information, ask clarifying questions to ensure all aspects of the feature are well-defined.
+
+## Output Format
+
+The output should be a complete PFD in Markdown format, saved to ${file}. There is a template already created.
+
+### PFD Structure
+
+You can find a complete template at `docs/features/potential/template.md`