@mthanh/vespercli 1.7.1 → 2.0.0

package/assets/instructions/tailwind-v4-vite/tailwind-v4-vite.instructions.md

@@ -1,236 +0,0 @@
----
-description: 'Tailwind CSS v4+ installation and configuration for Vite projects using the official @tailwindcss/vite plugin'
-applyTo: 'vite.config.ts, vite.config.js, **/*.css, **/*.tsx, **/*.ts, **/*.jsx, **/*.js'
----
-
-# Tailwind CSS v4+ Installation with Vite
-
-Instructions for installing and configuring Tailwind CSS version 4 and above using the official Vite plugin. Tailwind CSS v4 introduces a simplified setup that eliminates the need for PostCSS configuration and tailwind.config.js in most cases.
-
-## Key Changes in Tailwind CSS v4
-
-- **No PostCSS configuration required** when using the Vite plugin
-- **No tailwind.config.js required** - configuration is done via CSS
-- **New @tailwindcss/vite plugin** replaces the PostCSS-based approach
-- **CSS-first configuration** using `@theme` directive
-- **Automatic content detection** - no need to specify content paths
-
-## Installation Steps
-
-### Step 1: Install Dependencies
-
-Install `tailwindcss` and the `@tailwindcss/vite` plugin:
-
-```bash
-npm install tailwindcss @tailwindcss/vite
-```
-
-### Step 2: Configure Vite Plugin
-
-Add the `@tailwindcss/vite` plugin to your Vite configuration file:
-
-```typescript
-// vite.config.ts
-import { defineConfig } from 'vite';
-import tailwindcss from '@tailwindcss/vite';
-
-export default defineConfig({
-	plugins: [tailwindcss()],
-});
-```
-
-For React projects with Vite:
-
-```typescript
-// vite.config.ts
-import { defineConfig } from 'vite';
-import react from '@vitejs/plugin-react';
-import tailwindcss from '@tailwindcss/vite';
-
-export default defineConfig({
-	plugins: [react(), tailwindcss()],
-});
-```
-
-### Step 3: Import Tailwind CSS
-
-Add the Tailwind CSS import to your main CSS file (e.g., `src/index.css` or `src/App.css`):
-
-```css
-@import 'tailwindcss';
-```
-
-### Step 4: Verify CSS Import in Entry Point
-
-Ensure your main CSS file is imported in your application entry point:
-
-```typescript
-// src/main.tsx or src/main.ts
-import './index.css';
-```
-
-### Step 5: Start Development Server
-
-Run the development server to verify installation:
-
-```bash
-npm run dev
-```
-
-## What NOT to Do in Tailwind v4
-
-### Do NOT Create tailwind.config.js
-
-Tailwind v4 uses CSS-first configuration. Do not create a `tailwind.config.js` file unless you have specific legacy requirements.
-
-```javascript
-// ❌ NOT NEEDED in Tailwind v4
-module.exports = {
-	content: ['./src/**/*.{js,ts,jsx,tsx}'],
-	theme: {
-		extend: {},
-	},
-	plugins: [],
-};
-```
-
-### Do NOT Create postcss.config.js for Tailwind
-
-When using the `@tailwindcss/vite` plugin, PostCSS configuration for Tailwind is not required.
-
-```javascript
-// ❌ NOT NEEDED when using @tailwindcss/vite
-module.exports = {
-	plugins: {
-		tailwindcss: {},
-		autoprefixer: {},
-	},
-};
-```
-
-### Do NOT Use Old Directives
-
-The old `@tailwind` directives are replaced by a single import:
-
-```css
-/* ❌ OLD - Do not use in Tailwind v4 */
-@tailwind base;
-@tailwind components;
-@tailwind utilities;
-
-/* ✅ NEW - Use this in Tailwind v4 */
-@import 'tailwindcss';
-```
-
-## CSS-First Configuration (Tailwind v4)
-
-### Custom Theme Configuration
-
-Use the `@theme` directive in your CSS to customize your design tokens:
-
-```css
-@import 'tailwindcss';
-
-@theme {
-	--color-primary: #3b82f6;
-	--color-secondary: #64748b;
-	--font-sans: 'Inter', system-ui, sans-serif;
-	--radius-lg: 0.75rem;
-}
-```
-
-### Adding Custom Utilities
-
-Define custom utilities directly in CSS:
-
-```css
-@import 'tailwindcss';
-
-@utility content-auto {
-	content-visibility: auto;
-}
-
-@utility scrollbar-hidden {
-	scrollbar-width: none;
-	&::-webkit-scrollbar {
-		display: none;
-	}
-}
-```
-
-### Adding Custom Variants
-
-Define custom variants in CSS:
-
-```css
-@import 'tailwindcss';
-
-@variant hocus (&:hover, &:focus);
-@variant group-hocus (:merge(.group):hover &, :merge(.group):focus &);
-```
-
-## Verification Checklist
-
-After installation, verify:
-
-- [ ] `tailwindcss` and `@tailwindcss/vite` are in `package.json` dependencies
-- [ ] `vite.config.ts` includes the `tailwindcss()` plugin
-- [ ] Main CSS file contains `@import "tailwindcss";`
-- [ ] CSS file is imported in the application entry point
-- [ ] Development server runs without errors
-- [ ] Tailwind utility classes (e.g., `text-blue-500`, `p-4`) render correctly
-
-## Example Usage
-
-Test the installation with a simple component:
-
-```tsx
-export function TestComponent() {
-	return (
-		<div className='min-h-screen bg-gray-100 flex items-center justify-center'>
-			<h1 className='text-3xl font-bold text-blue-600 underline'>Hello, Tailwind CSS v4!</h1>
-		</div>
-	);
-}
-```
-
-## Troubleshooting
-
-### Styles Not Applying
-
-1. Verify CSS import statement is `@import "tailwindcss";` (not old directives)
-2. Ensure CSS file is imported in your entry point
-3. Check Vite config includes the `tailwindcss()` plugin
-4. Clear Vite cache: `rm -rf node_modules/.vite && npm run dev`
-
-### Plugin Not Found Error
-
-If you see "Cannot find module '@tailwindcss/vite'":
-
-```bash
-npm install @tailwindcss/vite
-```
-
-### TypeScript Errors
-
-If TypeScript cannot find types for the Vite plugin, ensure you have the correct import:
-
-```typescript
-import tailwindcss from '@tailwindcss/vite';
-```
-
-## Migration from Tailwind v3
-
-If migrating from Tailwind v3:
-
-1. Remove `tailwind.config.js` (move customizations to CSS `@theme`)
-2. Remove `postcss.config.js` (if only used for Tailwind)
-3. Uninstall old packages: `npm uninstall postcss autoprefixer`
-4. Install new packages: `npm install tailwindcss @tailwindcss/vite`
-5. Replace `@tailwind` directives with `@import "tailwindcss";`
-6. Update Vite config to use `@tailwindcss/vite` plugin
-
-## Reference
-
-- Official Documentation: https://tailwindcss.com/docs/installation/using-vite
-- Tailwind CSS v4 Upgrade Guide: https://tailwindcss.com/docs/upgrade-guide

package/assets/instructions/task-implementation/task-implementation.instructions.md

@@ -1,223 +0,0 @@
----
-applyTo: '**/.vesper/.tracking/changes/*.md'
-description: 'Instructions for implementing task plans with progressive tracking and change record - Brought to you by microsoft/edge-ai'
----
-
-# Task Plan Implementation Instructions
-
-You will implement your specific task plan located in `.vesper/.tracking/plans/**` and `.vesper/.tracking/details/**`. Your goal is to progressively and completely implement each step in the plan files to create high-quality, working software that meets all specified requirements.
-
-Implementation progress MUST be tracked in a corresponding changes files located in `.vesper/.tracking/changes/**`.
-
-## Pre-Implementation Validation
-
-**CRITICAL - MUST COMPLETE BEFORE ANY IMPLEMENTATION:**
-
-1. **Verify Planning Completeness:**
-   - Search `.vesper/.tracking/research/` for most recent research file
-   - Search `.vesper/.tracking/plans/` for corresponding plan file
-   - Search `.vesper/.tracking/details/` for corresponding details file
-   - Search `.vesper/.tracking/prompts/` for implementation prompt file
-
-2. **If ANY file is missing:**
-   - STOP immediately
-   - Report: "❌ Planning incomplete. Missing: [list missing files]"
-   - Suggest: "Please complete planning first using Thanh Junior Agent"
-   - DO NOT proceed with implementation
-
-3. **If all files exist:**
-   - Proceed to Core Implementation Process
-
-
-## Core Implementation Process
-
-### 1. Plan Analysis and Preparation
-
-**MUST complete before starting implementation:**
-
-- **MANDATORY**: Read and fully understand the complete plan file including scope, objectives, all phases, and every checklist item
-- **MANDATORY**: Read and fully understand the corresponding changes file completely - if any parts are missing from context, read the entire file back in using `read_file`
-- **MANDATORY**: Identify all referenced files mentioned in the plan and examine them for context
-- **MANDATORY**: Understand current project structure and conventions
-
-### 2. Systematic Implementation Process
-
-**Implement each task in the plan systematically:**
-
-1. **Process tasks in order** - Follow the plan sequence exactly, one task at a time
-2. **MANDATORY before implementing any task:**
-   - **ALWAYS ensure implementation is associated with a specific task from the plan**
-   - **ALWAYS read the entire details section for that task from the associated details markdown file in `.vesper/.tracking/details/**`\*\*
-   - **FULLY understand all implementation details before proceeding**
-   - Gather any additional required context as needed
-
-3. **Implement the task completely with working code:**
-   - Follow existing code patterns and conventions from the workspace
-   - Create working functionality that meets all task requirements specified in the details
-   - Include proper error handling, documentation, and follow best practices
-
-4. **Mark task complete and update changes tracking:**
-   - Update plan file: change `[ ]` to `[x]` for completed task
-   - **MANDATORY after completing EVERY task**: Update the changes file by appending to the appropriate Added, Modified, or Removed sections with relative file paths and one-sentence summary of what was implemented
-   - **MANDATORY**: If any changes diverge from the task plan and details, specifically call out within the relevant section that the change was made outside of the plan and include the specific reason
-   - If ALL tasks in a phase are complete `[x]`, mark the phase header as complete `[x]`
-
-### 3. Implementation Quality Standards
-
-**Every implementation MUST:**
-
-- Follow existing workspace patterns and conventions (check `copilot/` folder for standards)
-- Implement complete, working functionality that meets all task requirements
-- Include appropriate error handling and validation
-- Use consistent naming conventions and code structure from the workspace
-- Add necessary documentation and comments for complex logic
-- Ensure compatibility with existing systems and dependencies
-
-### 4. Continuous Progress and Validation
-
-**After implementing each task:**
-
-1. Validate the changes made against the task requirements from the details file
-2. Fix any problems before moving to the next task
-3. **MANDATORY**: Update the plan file to mark completed tasks `[x]`
-4. **MANDATORY after EVERY task completion**: Update the changes file by appending to Added, Modified, or Removed sections with relative file paths and one-sentence summary of what was implemented
-5. Continue to the next unchecked task
-
-**Continue until:**
-
-- All tasks in the plan are marked complete `[x]`
-- All specified files have been created or updated with working code
-- All success criteria from the plan have been verified
-
-### 5. Reference Gathering Guidelines
-
-**When gathering external references:**
-
-- Focus on practical implementation examples over theoretical documentation
-- Validate that external sources contain actual usable patterns
-- Adapt external patterns to match workspace conventions and standards
-
-**When implementing from references:**
-
-- Follow workspace patterns and conventions first, external patterns second
-- Implement complete, working functionality rather than just examples
-- Ensure all dependencies and configurations are properly integrated
-- Ensure implementations work within the existing project structure
-
-### 6. Completion and Documentation
-
-**Implementation is complete when:**
-
-- All plan tasks are marked complete `[x]`
-- All specified files exist with working code
-- All success criteria from the plan are verified
-- No implementation errors remain
-
-**Final step - update changes file with release summary:**
-
-- Add Release Summary section only after ALL phases are marked complete `[x]`
-- Document complete file inventory and overall implementation summary for release documentation
-
-### 7. Problem Resolution
-
-**When encountering implementation issues:**
-
-- Document the specific problem clearly
-- Try alternative approaches or search terms
-- Use workspace patterns as fallback when external references fail
-- Continue with available information rather than stopping completely
-- Note any unresolved issues in the plan file for future reference
-
-## Implementation Workflow
-
-```
-1. Read and fully understand plan file and all checklists completely
-2. Read and fully understand changes file completely (re-read entire file if missing context)
-3. For each unchecked task:
-   a. Read entire details section for that task from details markdown file
-   b. Fully understand all implementation requirements
-   c. Implement task with working code following workspace patterns
-   d. Validate implementation meets task requirements
-   e. Mark task complete [x] in plan file
-   f. Update changes file with Added, Modified, or Removed entries
-   g. Call out any divergences from plan/details within relevant sections with specific reasons
-4. Repeat until all tasks complete
-5. Only after ALL phases are complete [x]: Add final Release Summary to changes file
-```
-
-## Success Criteria
-
-Implementation is complete when:
-
-- ✅ All plan tasks are marked complete `[x]`
-- ✅ All specified files contain working code
-- ✅ Code follows workspace patterns and conventions
-- ✅ All functionality works as expected within the project
-- ✅ Changes file is updated after every task completion with Added, Modified, or Removed entries
-- ✅ Changes file documents all phases with detailed release-ready documentation and final release summary
-
-## Template Changes File
-
-Use the following as a template for the changes file that tracks implementation progress for releases.
-Replace `{{ }}` with appropriate values. Create this file in `./.vesper/.tracking/changes/` with filename: `YYYYMMDD-task-description-changes.md`
-
-**IMPORTANT**: Update this file after EVERY task completion by appending to Added, Modified, or Removed sections.
-**MANDATORY**: Always include the following at the top of the changes file: `<!-- markdownlint-disable-file -->`
-
-<!-- <changes-template> -->
-
-```markdown
-<!-- markdownlint-disable-file -->
-
-# Release Changes: {{task name}}
-
-**Related Plan**: {{plan-file-name}}
-**Implementation Date**: {{YYYY-MM-DD}}
-
-## Summary
-
-{{Brief description of the overall changes made for this release}}
-
-## Changes
-
-### Added
-
-- {{relative-file-path}} - {{one sentence summary of what was implemented}}
-
-### Modified
-
-- {{relative-file-path}} - {{one sentence summary of what was changed}}
-
-### Removed
-
-- {{relative-file-path}} - {{one sentence summary of what was removed}}
-
-## Release Summary
-
-**Total Files Affected**: {{number}}
-
-### Files Created ({{count}})
-
-- {{file-path}} - {{purpose}}
-
-### Files Modified ({{count}})
-
-- {{file-path}} - {{changes-made}}
-
-### Files Removed ({{count}})
-
-- {{file-path}} - {{reason}}
-
-### Dependencies & Infrastructure
-
-- **New Dependencies**: {{list-of-new-dependencies}}
-- **Updated Dependencies**: {{list-of-updated-dependencies}}
-- **Infrastructure Changes**: {{infrastructure-updates}}
-- **Configuration Updates**: {{configuration-changes}}
-
-### Deployment Notes
-
-{{Any specific deployment considerations or steps}}
-```
-
-<!-- </changes-template> -->

package/assets/prompts/create-specification/create-specification.prompt.md

@@ -1,151 +0,0 @@
----
-agent: 'SE: Tech Writer'
-description: 'Create a new specification file for the solution, optimized for Generative AI consumption.'
-tools:
-  [
-    'changes',
-    'search/codebase',
-    'edit/editFiles',
-    'extensions',
-    'fetch',
-    'githubRepo',
-    'openSimpleBrowser',
-    'problems',
-    'runTasks',
-    'search',
-    'search/searchResults',
-    'runCommands/terminalLastCommand',
-    'runCommands/terminalSelection',
-    'testFailure',
-    'usages',
-    'vscodeAPI',
-  ]
----
-
-# Create Specification
-
-Your goal is to create a new specification file for `${input:SpecPurpose}`.
-
-The specification file must define the requirements, constraints, and interfaces for the solution components in a manner that is clear, unambiguous, and structured for effective use by Generative AIs. Follow established documentation standards and ensure the content is machine-readable and self-contained.
-
-## Best Practices for AI-Ready Specifications
-
-- Use precise, explicit, and unambiguous language.
-- Clearly distinguish between requirements, constraints, and recommendations.
-- Use structured formatting (headings, lists, tables) for easy parsing.
-- Avoid idioms, metaphors, or context-dependent references.
-- Define all acronyms and domain-specific terms.
-- Include examples and edge cases where applicable.
-- Ensure the document is self-contained and does not rely on external context.
-
-The specification should be saved in the `.vesper/.tracking/specs/` directory and named according to the following convention: `YYYYMMDD-task-description-specification.md`.
-
-The specification file must be formatted in well formed Markdown.
-
-Specification files must follow the template below, ensuring that all sections are filled out appropriately. The front matter for the markdown should be structured correctly as per the example following:
-
-````md
----
-title: [Concise Title Describing the Specification's Focus]
-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]
-tags: [Optional: List of relevant tags or categories, e.g., `infrastructure`, `process`, `design`, `app` etc]
----
-
-# Introduction
-
-[A short concise introduction to the specification and the goal it is intended to achieve.]
-
-## 1. Purpose & Scope
-
-[Provide a clear, concise description of the specification's purpose and the scope of its application. State the intended audience and any assumptions.]
-
-## 2. Definitions
-
-[List and define all acronyms, abbreviations, and domain-specific terms used in this specification.]
-
-## 3. Requirements, Constraints & Guidelines
-
-[Explicitly list all requirements, constraints, rules, and guidelines. 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
-
-## 4. Interfaces & Data Contracts
-
-[Describe the interfaces, APIs, data contracts, or integration points. Use tables or code blocks for schemas and examples.]
-
-## 5. Acceptance Criteria
-
-[Define clear, testable acceptance criteria for each requirement using Given-When-Then format where appropriate.]
-
-- **AC-001**: Given [context], When [action], Then [expected outcome]
-- **AC-002**: The system shall [specific behavior] when [condition]
-- **AC-003**: [Additional acceptance criteria as needed]
-
-## 6. Test Automation Strategy
-
-[Define the testing approach, frameworks, and automation requirements.]
-
-- **Test Levels**: Unit, Integration, End-to-End
-- **Frameworks**: MSTest, FluentAssertions, Moq (for .NET applications)
-- **Test Data Management**: [approach for test data creation and cleanup]
-- **CI/CD Integration**: [automated testing in GitHub Actions pipelines]
-- **Coverage Requirements**: [minimum code coverage thresholds]
-- **Performance Testing**: [approach for load and performance testing]
-
-## 7. Rationale & Context
-
-[Explain the reasoning behind the requirements, constraints, and guidelines. Provide context for design decisions.]
-
-## 8. Dependencies & External Integrations
-
-[Define the external systems, services, and architectural dependencies required for this specification. Focus on **what** is needed rather than **how** it's implemented. Avoid specific package or library versions unless they represent architectural constraints.]
-
-### External Systems
-
-- **EXT-001**: [External system name] - [Purpose and integration type]
-
-### Third-Party Services
-
-- **SVC-001**: [Service name] - [Required capabilities and SLA requirements]
-
-### Infrastructure Dependencies
-
-- **INF-001**: [Infrastructure component] - [Requirements and constraints]
-
-### Data Dependencies
-
-- **DAT-001**: [External data source] - [Format, frequency, and access requirements]
-
-### Technology Platform Dependencies
-
-- **PLT-001**: [Platform/runtime requirement] - [Version constraints and rationale]
-
-### Compliance Dependencies
-
-- **COM-001**: [Regulatory or compliance requirement] - [Impact on implementation]
-
-**Note**: This section should focus on architectural and business dependencies, not specific package implementations. For example, specify "OAuth 2.0 authentication library" rather than "Microsoft.AspNetCore.Authentication.JwtBearer v6.0.1".
-
-## 9. Examples & Edge Cases
-
-    ```code
-    // Code snippet or data example demonstrating the correct application of the guidelines, including edge cases
-    ```
-
-## 10. Validation Criteria
-
-[List the criteria or tests that must be satisfied for compliance with this specification.]
-
-## 11. Related Specifications / Further Reading
-
-[Link to related spec 1]
-[Link to relevant external documentation]
-````

package/assets/prompts/playwright-generate-test/playwright-generate-test.prompt.md

@@ -1,26 +0,0 @@
----
-agent: agent
-description: 'Generate a Playwright test for a given scenario'
-tools: ['search', 'read', 'edit', 'execute', 'vscode', 'todo', 'vesper-indexing/*']
----
-
-# Test Generation from Source
-
-Generate a Playwright test based on the provided scenario by analyzing source code.
-
-## Instructions
-
-1. If no scenario is provided, ask the user for one
-2. Use `vesper-indexing` to find the relevant component/page source files
-3. Read the source — identify routes, `data-testid` attributes, interactive elements, and expected behaviors
-4. Generate a TypeScript test using `@playwright/test` with proper locators from source
-5. Save the test file in the `tests/` directory
-6. Run with `npx playwright test <file> --reporter=list`
-7. If tests fail, read the error, fix, and re-run
-
-## Constraints
-
-- DO NOT explore the website with a browser — generate from source code
-- DO verify locators exist in the actual component source before using them
-- DO use `getByRole`, `getByTestId`, `getByText` — prefer accessible locators
-- DO run the test and iterate until it passes