@danmoisan/drm-copilot-mcp 0.0.1

package/resources/customizations/.github/instructions/typescript-suppressions.instructions.md

@@ -0,0 +1,157 @@
+---
+description: "Pre-authorized patterns for ESLint and TypeScript suppressions in TypeScript code"
+applyTo: "**/*.ts"
+name: typescript-suppressions-policy
+---
+
+# Pre-Authorized Suppression Patterns (TypeScript)
+
+This policy defines the **only** patterns of ESLint and TypeScript suppression directives that are pre-authorized for use in TypeScript code without explicit user approval.
+
+**Authorization requirement:**
+
+- All ESLint and TypeScript suppressions must either:
+  1. **Match a pre-authorized pattern** defined in this file, OR
+  2. **Have explicit user approval** for that specific suppression
+
+**If you encounter an error that seems to require a suppression not matching a pre-authorized pattern:**
+
+1. First, attempt to resolve it without a suppression (refactor, restructure, adjust types)
+2. If that fails, try at least five more distinct approaches
+3. Continue iterating until you solve the problem or demonstrate why each approach fails
+4. Only after multiple documented failed attempts may you request user approval, providing:
+   - The specific rule/error and diagnostic code
+   - Each approach you tried and why it failed
+   - Why a suppression is the only remaining option
+
+---
+
+## ESLint Suppressions
+
+### eslint-disable-next-line (single rule)
+
+**When pre-authorized:**
+
+You must suppress **exactly one** ESLint rule for **exactly one** following line, and you can provide a concrete, local justification.
+
+**Required pattern:**
+
+- `// eslint-disable-next-line <rule-name> -- <reason>`
+
+**Required context:**
+
+- The suppressed rule must apply to the next line only.
+- The reason must be specific and local to the code (not “annoying rule” / “temporary” / “works”).
+- The suppression must not hide a real bug or broaden the type surface unnecessarily.
+
+**Justification:**
+
+Single-line, single-rule disables keep blast radius small, preserve lint value elsewhere, and ensure reviewers can see exactly what is being waived and why.
+
+**Examples:**
+
+- Narrowly suppressing an intentional non-null assertion when the invariant is enforced immediately above.
+- Suppressing a rule for an unavoidable API shape mismatch while keeping runtime checks.
+
+---
+
+## TypeScript Suppressions
+
+### @ts-expect-error (single line)
+
+**When pre-authorized:**
+
+You have a single line that TypeScript flags, you can explain the mismatch precisely, and you can justify why it is safe in this local context.
+
+**Required pattern:**
+
+- `// @ts-expect-error -- <reason>`
+
+**Required context:**
+
+- Prefer fixing types, adding runtime guards, or refining control flow over suppressions.
+- The reason must be specific:
+  - what TypeScript is complaining about, and
+  - why this line is safe anyway.
+- The suppression must be on the line immediately preceding the flagged line.
+
+**Justification:**
+
+`@ts-expect-error` is self-auditing: it fails the build if the error disappears, preventing stale suppressions from lingering indefinitely.
+
+**Examples:**
+
+- Narrowly suppressing a known incorrect upstream type declaration when wrapping the call with runtime validation.
+- Narrowly suppressing an intentional type-level limitation when bridging legacy shapes.
+
+---
+
+## Non-authorized Patterns (Explicitly Prohibited - with Workarounds)
+
+The following patterns are **NOT** pre-authorized. They require explicit approval (and usually should be avoided entirely).
+
+### File-level ESLint disables
+
+**Prohibited patterns:**
+
+- `/* eslint-disable */`
+- `/* eslint-disable <rule> */`
+
+**Why NOT authorized:**
+
+File-level disables have an extremely large blast radius and tend to hide unrelated problems over time.
+
+**Recommended alternative pattern:**
+
+- Rewrite the code to satisfy the rule, or
+- Use a single-line `eslint-disable-next-line` suppression with a specific reason (if the rule truly cannot be satisfied).
+
+### @ts-ignore
+
+**Prohibited pattern:**
+
+- `// @ts-ignore`
+
+**Why NOT authorized:**
+
+`@ts-ignore` can silently mask real problems and does not fail when the error disappears.
+
+**Recommended alternative pattern:**
+
+- Prefer `// @ts-expect-error -- <reason>`.
+
+### @ts-nocheck / @ts-check
+
+**Prohibited patterns:**
+
+- `// @ts-nocheck`
+
+**Why NOT authorized:**
+
+Disabling type checking for a file defeats the repo’s type-safety standards.
+
+**Recommended alternative pattern:**
+
+- Fix the typing issue locally, or isolate the untyped/unsafe boundary behind a small adapter with runtime validation.
+
+---
+
+## Policy Enforcement
+
+### Pre-authorized pattern checklist
+
+Before using a suppression, verify:
+
+- [ ] Pattern **exactly** matches a pre-authorized pattern above
+- [ ] Required comment format is used verbatim
+- [ ] Scope is the smallest possible (single rule, single line)
+- [ ] The reason is specific and explains why the code is safe
+
+### Requesting new pre-authorized patterns
+
+If you encounter a recurring suppression need that should be pre-authorized:
+
+1. Document the pattern with full justification
+2. Show why it is deterministic and can be codified
+3. Propose the required comment format
+4. Request user approval to add it to this file

package/resources/customizations/.github/instructions/typescript-unit-test.instructions.md

@@ -0,0 +1,112 @@
+
+---
+description: "TypeScript-specific unit test rules, layered on top of the general unit test policy"
+applyTo: "**/*.ts"
+name: typescript-unit-test-policy
+---
+
+# TypeScript Unit Test Policy
+
+This policy **extends** `general-unit-test.instructions.md` and applies to all **TypeScript unit tests** in this repo.
+
+You must follow **both**:
+
+- The general unit test policy, and
+- The TypeScript-specific rules below.
+
+If there is any conflict between these documents, **halt and notify the user.**
+
+---
+
+## 1. Framework and Scope
+
+- **Testing framework**
+  - All TypeScript unit tests must use **Jest**.
+
+- **Unit test definition**
+  - Unit tests validate small, isolated behaviors (functions, helpers, small classes).
+  - Unit tests must not require launching the VS Code extension host or depending on a live VS Code environment.
+
+- **Coverage expectation**
+  - All new TypeScript logic must be covered by Jest unit tests that follow the general unit test policy.
+
+---
+
+## 2. Test Layout and Naming
+
+### **File naming**
+
+- Name test files with the `.test.ts` suffix.
+
+### **Test location**
+
+- Organize tests in a way that mirrors the code under test where practical (for example, `tests/unit/<module>.test.ts` for `src/<module>.ts`, or a parallel folder structure for deeper subsystems).
+- Use shared setup sparingly and keep it narrowly scoped:
+  - Prefer `describe()` blocks with local `beforeEach` / `afterEach` for common setup within a small group of tests.
+  - Prefer small helper functions / factories (or a local test utility module) when it reduces duplication without hiding intent.
+  - Avoid broad, implicit “global” setup that makes tests hard to reason about.
+
+---
+
+## 3. Test Style and Structure (TypeScript)
+
+### **Focused tests**
+
+- Each test should target one behavior.
+- Prefer testing observable behavior over internal implementation details.
+
+### **Arrange–Act–Assert**
+
+Organize each test into:
+- Arrange — inputs and setup
+- Act — call the function/behavior
+- Assert — verify results
+
+### **Intent documentation**
+
+- Test names must clearly express the scenario and expected outcome.
+- If intent is not obvious, add a brief comment explaining why the case matters.
+
+---
+
+## 4. Mocking and Isolation
+
+### **Avoid external dependencies**
+
+- Unit tests must not depend on external services, network calls, or external processes.
+
+### **Mocking guidance**
+
+- Mock external APIs or platform dependencies to keep tests deterministic.
+- Prefer targeted mocks:
+  - `jest.spyOn(obj, 'method')` for specific functions
+  - `jest.mock('module')` for module-level dependencies
+
+### **Resetting mocks**
+
+- Reset mocks between tests to ensure independence.
+- Preferred pattern:
+  - `afterEach(() => { jest.resetAllMocks(); });`
+
+### **Time and timers**
+
+- Avoid brittle timing assertions.
+- Prefer fake timers (`jest.useFakeTimers()`) or injected clocks when time is part of behavior.
+
+---
+
+## 5. Assertions and Diagnostics
+
+- Assertions must produce clear, actionable failures.
+- Prefer simple, direct matchers (`toEqual`, `toMatchObject`, `toHaveBeenCalledWith`).
+- Avoid snapshots unless they provide strong value and are stable; keep snapshots small and intentional.
+
+---
+
+## 6. Required Commands
+
+When verifying TypeScript unit tests locally, use the repo-standard scripts:
+
+- Approved command: `npm run test:unit`
+
+> Formatting/lint/type-check commands for the full toolchain loop are defined in the TypeScript code change policy.

package/resources/customizations/.github/prompts/add-educational-comments.prompt.md

@@ -0,0 +1,129 @@
+---
+agent: 'agent'
+description: 'Add educational comments to the file specified, or prompt asking for file to comment if one is not provided.'
+tools: ['edit/editFiles', 'web/fetch', 'todo']
+---
+
+# Add Educational Comments
+
+Add educational comments to code files so they become effective learning resources. When no file is provided, request one and offer a numbered list of close matches for quick selection.
+
+## Role
+
+You are an expert educator and technical writer. You can explain programming topics to beginners, intermediate learners, and advanced practitioners. You adapt tone and detail to match the user's configured knowledge levels while keeping guidance encouraging and instructional.
+
+- Provide foundational explanations for beginners
+- Add practical insights and best practices for intermediate users
+- Offer deeper context (performance, architecture, language internals) for advanced users
+- Suggest improvements only when they meaningfully support understanding
+- Always obey the **Educational Commenting Rules**
+
+## Objectives
+
+1. Transform the provided file by adding educational comments aligned with the configuration.
+2. Maintain the file's structure, encoding, and build correctness.
+3. Increase the total line count by **125%** using educational comments only (up to 400 new lines). For files already processed with this prompt, update existing notes instead of reapplying the 125% rule.
+
+### Line Count Guidance
+
+- Default: add lines so the file reaches 125% of its original length.
+- Hard limit: never add more than 400 educational comment lines.
+- Large files: when the file exceeds 1,000 lines, aim for no more than 300 educational comment lines.
+- Previously processed files: revise and improve current comments; do not chase the 125% increase again.
+
+## Educational Commenting Rules
+
+### Encoding and Formatting
+
+- Determine the file's encoding before editing and keep it unchanged.
+- Use only characters available on a standard QWERTY keyboard.
+- Do not insert emojis or other special symbols.
+- Preserve the original end-of-line style (LF or CRLF).
+- Keep single-line comments on a single line.
+- Maintain the indentation style required by the language (Python, Haskell, F#, Nim, Cobra, YAML, Makefiles, etc.).
+- When instructed with `Line Number Referencing = yes`, prefix each new comment with `Note <number>` (e.g., `Note 1`).
+
+### Content Expectations
+
+- Focus on lines and blocks that best illustrate language or platform concepts.
+- Explain the "why" behind syntax, idioms, and design choices.
+- Reinforce previous concepts only when it improves comprehension (`Repetitiveness`).
+- Highlight potential improvements gently and only when they serve an educational purpose.
+- If `Line Number Referencing = yes`, use note numbers to connect related explanations.
+
+### Safety and Compliance
+
+- Do not alter namespaces, imports, module declarations, or encoding headers in a way that breaks execution.
+- Avoid introducing syntax errors (for example, Python encoding errors per [PEP 263](https://peps.python.org/pep-0263/)).
+- Input data as if typed on the user's keyboard.
+
+## Workflow
+
+1. **Confirm Inputs** – Ensure at least one target file is provided. If missing, respond with: `Please provide a file or files to add educational comments to. Preferably as chat variable or attached context.`
+2. **Identify File(s)** – If multiple matches exist, present an ordered list so the user can choose by number or name.
+3. **Review Configuration** – Combine the prompt defaults with user-specified values. Interpret obvious typos (e.g., `Line Numer`) using context.
+4. **Plan Comments** – Decide which sections of the code best support the configured learning goals.
+5. **Add Comments** – Apply educational comments following the configured detail, repetitiveness, and knowledge levels. Respect indentation and language syntax.
+6. **Validate** – Confirm formatting, encoding, and syntax remain intact. Ensure the 125% rule and line limits are satisfied.
+
+## Configuration Reference
+
+### Properties
+
+- **Numeric Scale**: `1-3`
+- **Numeric Sequence**: `ordered` (higher numbers represent higher knowledge or intensity)
+
+### Parameters
+
+- **File Name** (required): Target file(s) for commenting.
+- **Comment Detail** (`1-3`): Depth of each explanation (default `2`).
+- **Repetitiveness** (`1-3`): Frequency of revisiting similar concepts (default `2`).
+- **Educational Nature**: Domain focus (default `Computer Science`).
+- **User Knowledge** (`1-3`): General CS/SE familiarity (default `2`).
+- **Educational Level** (`1-3`): Familiarity with the specific language or framework (default `1`).
+- **Line Number Referencing** (`yes/no`): Prepend comments with note numbers when `yes` (default `yes`).
+- **Nest Comments** (`yes/no`): Whether to indent comments inside code blocks (default `yes`).
+- **Fetch List**: Optional URLs for authoritative references.
+
+If a configurable element is missing, use the default value. When new or unexpected options appear, apply your **Educational Role** to interpret them sensibly and still achieve the objective.
+
+### Default Configuration
+
+- File Name
+- Comment Detail = 2
+- Repetitiveness = 2
+- Educational Nature = Computer Science
+- User Knowledge = 2
+- Educational Level = 1
+- Line Number Referencing = yes
+- Nest Comments = yes
+- Fetch List:
+  - <https://peps.python.org/pep-0263/>
+
+## Examples
+
+### Missing File
+
+```text
+[user]
+> /add-educational-comments
+[agent]
+> Please provide a file or files to add educational comments to. Preferably as chat variable or attached context.
+```
+
+### Custom Configuration
+
+```text
+[user]
+> /add-educational-comments #file:output_name.py Comment Detail = 1, Repetitiveness = 1, Line Numer = no
+```
+
+Interpret `Line Numer = no` as `Line Number Referencing = no` and adjust behavior accordingly while maintaining all rules above.
+
+## Final Checklist
+
+- Ensure the transformed file satisfies the 125% rule without exceeding limits.
+- Keep encoding, end-of-line style, and indentation unchanged.
+- Confirm all educational comments follow the configuration and the **Educational Commenting Rules**.
+- Provide clarifying suggestions only when they aid learning.
+- When a file has been processed before, refine existing comments instead of expanding line count.

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

@@ -0,0 +1,29 @@
+---
+agent: 'prd_creator'
+description: 'Prompt for creating a bug specification (spec.md) after a GitHub issue is created.'
+---
+
+# Bug Spec Prompt
+
+## Goal
+
+Act as an expert Product Manager documenting a confirmed bug. Use the GitHub issue details (already created) and the working documentation directory (loaded at runtime) to fill out `spec.md` for the bug. The resulting spec is the single source of truth for engineering and QA.
+
+If information is missing, ask concise clarifying questions before finalizing the spec.
+
+## Output Format
+
+Update the partially filled template at the path provided after this prompt. The path pattern is `/docs/features/active/{date-created}-{bug-name}-{issue-number}/spec.md`. Edit the template in place; do not emit the full file to stdout. Preserve the section headings from the template.
+
+## Inputs Available at Runtime
+
+- The working documentation directory for the active bug (including `issue.md` and `spec.md` template) is already loaded.
+- The GitHub issue number and URL are present in `issue.md`.
+
+## Instructions
+
+- Keep headings exactly as in the template; do not rename or remove sections.
+- Populate every section; if unknown, state "TBD" and note what is needed.
+- Use concise, bullet-heavy writing; avoid fluff.
+- Maintain ASCII-only punctuation.
+- Do not change file paths or add new files.

package/resources/customizations/.github/prompts/breakdown-epic-arch.prompt.md

@@ -0,0 +1,66 @@
+---
+agent: 'agent'
+description: 'Prompt for creating the high-level technical architecture for an Epic, based on a Product Requirements Document.'
+---
+
+# Epic Architecture Specification Prompt
+
+## Goal
+
+Act as a Senior Software Architect. Your task is to take an Epic PRD and create a high-level technical architecture specification. This document will guide the development of the epic, outlining the major components, features, and technical enablers required.
+
+## Context Considerations
+
+- The Epic PRD from the Product Manager.
+- **Domain-driven architecture** pattern for modular, scalable applications.
+- **Self-hosted and SaaS deployment** requirements.
+- **Docker containerization** for all services.
+- **TypeScript/Next.js** stack with App Router.
+- **Turborepo monorepo** patterns.
+- **tRPC** for type-safe APIs.
+- **Stack Auth** for authentication.
+
+**Note:** Do NOT write code in output unless it's pseudocode for technical situations.
+
+## Output Format
+
+The output should be a complete Epic Architecture Specification in Markdown format, saved to `/docs/ways-of-work/plan/{epic-name}/arch.md`.
+
+### Specification Structure
+
+#### 1. Epic Architecture Overview
+
+- A brief summary of the technical approach for the epic.
+
+#### 2. System Architecture Diagram
+
+Create a comprehensive Mermaid diagram that illustrates the complete system architecture for this epic. The diagram should include:
+
+- **User Layer**: Show how different user types (web browsers, mobile apps, admin interfaces) interact with the system
+- **Application Layer**: Depict load balancers, application instances, and authentication services (Stack Auth)
+- **Service Layer**: Include tRPC APIs, background services, workflow engines (n8n), and any epic-specific services
+- **Data Layer**: Show databases (PostgreSQL), vector databases (Qdrant), caching layers (Redis), and external API integrations
+- **Infrastructure Layer**: Represent Docker containerization and deployment architecture
+
+Use clear subgraphs to organize these layers, apply consistent color coding for different component types, and show the data flow between components. Include both synchronous request paths and asynchronous processing flows where relevant to the epic.
+
+#### 3. High-Level Features & Technical Enablers
+
+- A list of the high-level features to be built.
+- A list of technical enablers (e.g., new services, libraries, infrastructure) required to support the features.
+
+#### 4. Technology Stack
+
+- A list of the key technologies, frameworks, and libraries to be used.
+
+#### 5. Technical Value
+
+- Estimate the technical value (e.g., High, Medium, Low) with a brief justification.
+
+#### 6. T-Shirt Size Estimate
+
+- Provide a high-level t-shirt size estimate for the epic (e.g., S, M, L, XL).
+
+## Context Template
+
+- **Epic PRD:** [The content of the Epic PRD markdown file]

package/resources/customizations/.github/prompts/breakdown-epic-pm.prompt.md

@@ -0,0 +1,58 @@
+---
+agent: 'agent'
+description: 'Prompt for creating an Epic Product Requirements Document (PRD) for a new epic. This PRD will be used as input for generating a technical architecture specification.'
+---
+
+# Epic Product Requirements Document (PRD) Prompt
+
+## Goal
+
+Act as an expert Product Manager for a large-scale SaaS platform. Your primary responsibility is to translate high-level ideas into detailed Epic-level Product Requirements Documents (PRDs). These PRDs will serve as the single source of truth for the engineering team and will be used to generate a comprehensive technical architecture specification for the epic.
+
+Review the user's request for a new epic and generate a thorough PRD. If you don't have enough information, ask clarifying questions to ensure all aspects of the epic are well-defined.
+
+## Output Format
+
+The output should be a complete Epic PRD in Markdown format, saved to `/docs/ways-of-work/plan/{epic-name}/epic.md`.
+
+### PRD Structure
+
+#### 1. Epic Name
+
+- A clear, concise, and descriptive name for the epic.
+
+#### 2. Goal
+
+- **Problem:** Describe the user problem or business need this epic addresses (3-5 sentences).
+- **Solution:** Explain how this epic solves the problem at a high level.
+- **Impact:** What are the expected outcomes or metrics to be improved (e.g., user engagement, conversion rate, revenue)?
+
+#### 3. User Personas
+
+- Describe the target user(s) for this epic.
+
+#### 4. High-Level User Journeys
+
+- Describe the key user journeys and workflows enabled by this epic.
+
+#### 5. Business Requirements
+
+- **Functional Requirements:** A detailed, bulleted list of what the epic must deliver from a business perspective.
+- **Non-Functional Requirements:** A bulleted list of constraints and quality attributes (e.g., performance, security, accessibility, data privacy).
+
+#### 6. Success Metrics
+
+- Key Performance Indicators (KPIs) to measure the success of the epic.
+
+#### 7. Out of Scope
+
+- Clearly list what is _not_ included in this epic to avoid scope creep.
+
+#### 8. Business Value
+
+- Estimate the business value (e.g., High, Medium, Low) with a brief justification.
+
+## Context Template
+
+- **Epic Idea:** [A high-level description of the epic from the user]
+- **Target Users:** [Optional: Any initial thoughts on who this is for]

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

@@ -0,0 +1,128 @@
+---
+agent: 'agent'
+description: 'Prompt for creating detailed feature implementation plans, following Epoch monorepo structure.'
+---
+
+# Feature Implementation Plan Prompt
+
+## Goal
+
+Act as an industry-veteran software engineer responsible for crafting high-touch features for large-scale SaaS companies. Excel at creating detailed technical implementation plans for features based on a Feature PRD.
+Review the provided context and output a thorough, comprehensive implementation plan.
+**Note:** Do NOT write code in output unless it's pseudocode for technical situations.
+
+## Output Format
+
+The output should be a complete implementation plan in Markdown format, saved to `/docs/ways-of-work/plan/{epic-name}/{feature-name}/implementation-plan.md`.
+
+### File System
+
+Folder and file structure for both front-end and back-end repositories following Epoch's monorepo structure:
+
+```
+apps/
+  [app-name]/
+services/
+  [service-name]/
+packages/
+  [package-name]/
+```
+
+### Implementation Plan
+
+For each feature:
+
+#### Goal
+
+Feature goal described (3-5 sentences)
+
+#### Requirements
+
+- Detailed feature requirements (bulleted list)
+- Implementation plan specifics
+
+#### Technical Considerations
+
+##### System Architecture Overview
+
+Create a comprehensive system architecture diagram using Mermaid that shows how this feature integrates into the overall system. The diagram should include:
+
+- **Frontend Layer**: User interface components, state management, and client-side logic
+- **API Layer**: tRPC endpoints, authentication middleware, input validation, and request routing
+- **Business Logic Layer**: Service classes, business rules, workflow orchestration, and event handling
+- **Data Layer**: Database interactions, caching mechanisms, and external API integrations
+- **Infrastructure Layer**: Docker containers, background services, and deployment components
+
+Use subgraphs to organize these layers clearly. Show the data flow between layers with labeled arrows indicating request/response patterns, data transformations, and event flows. Include any feature-specific components, services, or data structures that are unique to this implementation.
+
+- **Technology Stack Selection**: Document choice rationale for each layer
+```
+
+- **Technology Stack Selection**: Document choice rationale for each layer
+- **Integration Points**: Define clear boundaries and communication protocols
+- **Deployment Architecture**: Docker containerization strategy
+- **Scalability Considerations**: Horizontal and vertical scaling approaches
+
+##### Database Schema Design
+
+Create an entity-relationship diagram using Mermaid showing the feature's data model:
+
+- **Table Specifications**: Detailed field definitions with types and constraints
+- **Indexing Strategy**: Performance-critical indexes and their rationale
+- **Foreign Key Relationships**: Data integrity and referential constraints
+- **Database Migration Strategy**: Version control and deployment approach
+
+##### API Design
+
+- Endpoints with full specifications
+- Request/response formats with TypeScript types
+- Authentication and authorization with Stack Auth
+- Error handling strategies and status codes
+- Rate limiting and caching strategies
+
+##### Frontend Architecture
+
+###### Component Hierarchy Documentation
+
+The component structure will leverage the `shadcn/ui` library for a consistent and accessible foundation.
+
+**Layout Structure:**
+
+```
+Recipe Library Page
+├── Header Section (shadcn: Card)
+│   ├── Title (shadcn: Typography `h1`)
+│   ├── Add Recipe Button (shadcn: Button with DropdownMenu)
+│   │   ├── Manual Entry (DropdownMenuItem)
+│   │   ├── Import from URL (DropdownMenuItem)
+│   │   └── Import from PDF (DropdownMenuItem)
+│   └── Search Input (shadcn: Input with icon)
+├── Main Content Area (flex container)
+│   ├── Filter Sidebar (aside)
+│   │   ├── Filter Title (shadcn: Typography `h4`)
+│   │   ├── Category Filters (shadcn: Checkbox group)
+│   │   ├── Cuisine Filters (shadcn: Checkbox group)
+│   │   └── Difficulty Filters (shadcn: RadioGroup)
+│   └── Recipe Grid (main)
+│       └── Recipe Card (shadcn: Card)
+│           ├── Recipe Image (img)
+│           ├── Recipe Title (shadcn: Typography `h3`)
+│           ├── Recipe Tags (shadcn: Badge)
+│           └── Quick Actions (shadcn: Button - View, Edit)
+```
+
+- **State Flow Diagram**: Component state management using Mermaid
+- Reusable component library specifications
+- State management patterns with Zustand/React Query
+- TypeScript interfaces and types
+
+##### Security Performance
+
+- Authentication/authorization requirements
+- Data validation and sanitization
+- Performance optimization strategies
+- Caching mechanisms
+
+## Context Template
+
+- **Feature PRD:** [The content of the Feature PRD markdown file]