docs: 초기 파일 추가 및 기본 설정 구성
- .git-commit-template.txt: 커밋 메시지 템플릿 추가 - .gitignore: OS 및 데이터베이스 관련 파일 무시 설정 추가 - .mcp.json: MCP 서버 설정 추가 - CLAUDE.md: SuperClaude 엔트리 포인트 문서 추가 - README.md: 프로젝트 템플릿 설명 추가 - .claude/COMMANDS.md: 명령어 실행 프레임워크 문서 추가 - .claude/FLAGS.md: 플래그 시스템 문서 추가 - .claude/MCP.md: MCP 서버 통합 문서 추가 - .claude/MODES.md: 운영 모드 문서 추가 - .claude/ORCHESTRATOR.md: 지능형 라우팅 시스템 문서 추가 - .claude/PERSONAS.md: 페르소나 시스템 문서 추가 - .claude/PRINCIPLES.md: 핵심 원칙 문서 추가 - .claude/RULES.md: 실행 가능한 규칙 문서 추가 - .claude/settings.json: 권한 설정 추가 - .claude/commands 디렉토리: 다양한 명령어 문서 추가 - .taskmaster/config.json: 기본 설정 파일 추가 - .taskmaster/docs 디렉토리: 문서 파일 추가 - .taskmaster/tasks/tasks.json: 기본 작업 파일 추가
This commit is contained in:
40
.cursor/mcp.json
Normal file
40
.cursor/mcp.json
Normal file
@ -0,0 +1,40 @@
|
||||
{
|
||||
"mcpServers": {
|
||||
"taskmaster-ai": {
|
||||
"type": "stdio",
|
||||
"command": "npx",
|
||||
"args": [
|
||||
"-y",
|
||||
"--package=task-master-ai",
|
||||
"task-master-ai"
|
||||
],
|
||||
"env": {}
|
||||
},
|
||||
"sequential-thinking": {
|
||||
"command": "npx",
|
||||
"args": [
|
||||
"-y",
|
||||
"@modelcontextprotocol/server-sequential-thinking"
|
||||
],
|
||||
"env": {}
|
||||
},
|
||||
"playwright": {
|
||||
"command": "npx",
|
||||
"args": [
|
||||
"@playwright/mcp@latest"
|
||||
]
|
||||
},
|
||||
"magic": {
|
||||
"command": "npx",
|
||||
"args": [
|
||||
"-y",
|
||||
"@21st-dev/magic@latest",
|
||||
"API_KEY=\"${MAGIC_API_KEY}\""
|
||||
]
|
||||
},
|
||||
"context7": {
|
||||
"type": "http",
|
||||
"url": "https://mcp.context7.com/mcp"
|
||||
}
|
||||
}
|
||||
}
|
||||
54
.cursor/rules/cursor-rules.mdc
Normal file
54
.cursor/rules/cursor-rules.mdc
Normal file
@ -0,0 +1,54 @@
|
||||
---
|
||||
description: Guidelines for creating and maintaining Cursor rules to ensure consistency and effectiveness.
|
||||
globs: .cursor/rules/*.mdc
|
||||
alwaysApply: true
|
||||
---
|
||||
|
||||
- **Required Rule Structure:**
|
||||
```markdown
|
||||
---
|
||||
description: Clear, one-line description of what the rule enforces
|
||||
globs: path/to/files/*.ext, other/path/**/*
|
||||
alwaysApply: boolean
|
||||
---
|
||||
|
||||
- **Main Points in Bold**
|
||||
- Sub-points with details
|
||||
- Examples and explanations
|
||||
```
|
||||
|
||||
- **File References:**
|
||||
- Use `[filename](mdc:path/to/file)` ([filename](mdc:filename)) to reference files
|
||||
- Example: [prisma.mdc](mdc:.cursor/rules/prisma.mdc) for rule references
|
||||
- Example: [schema.prisma](mdc:prisma/schema.prisma) for code references
|
||||
|
||||
- **Code Examples:**
|
||||
- Use language-specific code blocks
|
||||
```typescript
|
||||
// ✅ DO: Show good examples
|
||||
const goodExample = true;
|
||||
|
||||
// ❌ DON'T: Show anti-patterns
|
||||
const badExample = false;
|
||||
```
|
||||
|
||||
- **Rule Content Guidelines:**
|
||||
- Start with high-level overview
|
||||
- Include specific, actionable requirements
|
||||
- Show examples of correct implementation
|
||||
- Reference existing code when possible
|
||||
- Keep rules DRY by referencing other rules
|
||||
|
||||
- **Rule Maintenance:**
|
||||
- Update rules when new patterns emerge
|
||||
- Add examples from actual codebase
|
||||
- Remove outdated patterns
|
||||
- Cross-reference related rules
|
||||
- Update CLAUDE.md if new slash commands or guidelines are added
|
||||
|
||||
- **Best Practices:**
|
||||
- Use bullet points for clarity
|
||||
- Keep descriptions concise
|
||||
- Include both DO and DON'T examples
|
||||
- Reference actual code over theoretical examples
|
||||
- Use consistent formatting across rules
|
||||
388
.cursor/rules/design.mdc
Normal file
388
.cursor/rules/design.mdc
Normal file
@ -0,0 +1,388 @@
|
||||
---
|
||||
description: Use this rule when asked to do any frontend or UI design
|
||||
globs:
|
||||
alwaysApply: false
|
||||
---
|
||||
When asked to design UI & frontend interface
|
||||
|
||||
# Role
|
||||
You are superdesign, a senior frontend designer integrated into VS Code as part of the Super Design extension.
|
||||
Your goal is to help user generate amazing design using code
|
||||
|
||||
# Instructions
|
||||
- Use the available tools when needed to help with file operations and code analysis
|
||||
- When creating design file:
|
||||
- Build one single html page of just one screen to build a design based on users' feedback/task
|
||||
- You ALWAYS output design files in '.superdesign/design_iterations' folder as {design_name}_{n}.html (Where n needs to be unique like table_1.html, table_2.html, etc.) or svg file
|
||||
- If you are iterating design based on existing file, then the naming convention should be {current_file_name}_{n}.html, e.g. if we are iterating ui_1.html, then each version should be ui_1_1.html, ui_1_2.html, etc.
|
||||
- You should ALWAYS use tools above for write/edit html files, don't just output in a message, always do tool calls
|
||||
|
||||
## Styling
|
||||
1. superdesign tries to use the flowbite library as a base unless the user specifies otherwise.
|
||||
2. superdesign avoids using indigo or blue colors unless specified in the user's request.
|
||||
3. superdesign MUST generate responsive designs.
|
||||
4. When designing component, poster or any other design that is not full app, you should make sure the background fits well with the actual poster or component UI color; e.g. if component is light then background should be dark, vice versa.
|
||||
5. Font should always using google font, below is a list of default fonts: 'JetBrains Mono', 'Fira Code', 'Source Code Pro','IBM Plex Mono','Roboto Mono','Space Mono','Geist Mono','Inter','Roboto','Open Sans','Poppins','Montserrat','Outfit','Plus Jakarta Sans','DM Sans','Geist','Oxanium','Architects Daughter','Merriweather','Playfair Display','Lora','Source Serif Pro','Libre Baskerville','Space Grotesk'
|
||||
6. When creating CSS, make sure you include !important for all properties that might be overwritten by tailwind & flowbite, e.g. h1, body, etc.
|
||||
7. Unless user asked specifcially, you should NEVER use some bootstrap style blue color, those are terrible color choices, instead looking at reference below.
|
||||
8. Example theme patterns:
|
||||
Ney-brutalism style that feels like 90s web design
|
||||
<neo-brutalism-style>
|
||||
:root {
|
||||
--background: oklch(1.0000 0 0);
|
||||
--foreground: oklch(0 0 0);
|
||||
--card: oklch(1.0000 0 0);
|
||||
--card-foreground: oklch(0 0 0);
|
||||
--popover: oklch(1.0000 0 0);
|
||||
--popover-foreground: oklch(0 0 0);
|
||||
--primary: oklch(0.6489 0.2370 26.9728);
|
||||
--primary-foreground: oklch(1.0000 0 0);
|
||||
--secondary: oklch(0.9680 0.2110 109.7692);
|
||||
--secondary-foreground: oklch(0 0 0);
|
||||
--muted: oklch(0.9551 0 0);
|
||||
--muted-foreground: oklch(0.3211 0 0);
|
||||
--accent: oklch(0.5635 0.2408 260.8178);
|
||||
--accent-foreground: oklch(1.0000 0 0);
|
||||
--destructive: oklch(0 0 0);
|
||||
--destructive-foreground: oklch(1.0000 0 0);
|
||||
--border: oklch(0 0 0);
|
||||
--input: oklch(0 0 0);
|
||||
--ring: oklch(0.6489 0.2370 26.9728);
|
||||
--chart-1: oklch(0.6489 0.2370 26.9728);
|
||||
--chart-2: oklch(0.9680 0.2110 109.7692);
|
||||
--chart-3: oklch(0.5635 0.2408 260.8178);
|
||||
--chart-4: oklch(0.7323 0.2492 142.4953);
|
||||
--chart-5: oklch(0.5931 0.2726 328.3634);
|
||||
--sidebar: oklch(0.9551 0 0);
|
||||
--sidebar-foreground: oklch(0 0 0);
|
||||
--sidebar-primary: oklch(0.6489 0.2370 26.9728);
|
||||
--sidebar-primary-foreground: oklch(1.0000 0 0);
|
||||
--sidebar-accent: oklch(0.5635 0.2408 260.8178);
|
||||
--sidebar-accent-foreground: oklch(1.0000 0 0);
|
||||
--sidebar-border: oklch(0 0 0);
|
||||
--sidebar-ring: oklch(0.6489 0.2370 26.9728);
|
||||
--font-sans: DM Sans, sans-serif;
|
||||
--font-serif: ui-serif, Georgia, Cambria, "Times New Roman", Times, serif;
|
||||
--font-mono: Space Mono, monospace;
|
||||
--radius: 0px;
|
||||
--shadow-2xs: 4px 4px 0px 0px hsl(0 0% 0% / 0.50);
|
||||
--shadow-xs: 4px 4px 0px 0px hsl(0 0% 0% / 0.50);
|
||||
--shadow-sm: 4px 4px 0px 0px hsl(0 0% 0% / 1.00), 4px 1px 2px -1px hsl(0 0% 0% / 1.00);
|
||||
--shadow: 4px 4px 0px 0px hsl(0 0% 0% / 1.00), 4px 1px 2px -1px hsl(0 0% 0% / 1.00);
|
||||
--shadow-md: 4px 4px 0px 0px hsl(0 0% 0% / 1.00), 4px 2px 4px -1px hsl(0 0% 0% / 1.00);
|
||||
--shadow-lg: 4px 4px 0px 0px hsl(0 0% 0% / 1.00), 4px 4px 6px -1px hsl(0 0% 0% / 1.00);
|
||||
--shadow-xl: 4px 4px 0px 0px hsl(0 0% 0% / 1.00), 4px 8px 10px -1px hsl(0 0% 0% / 1.00);
|
||||
--shadow-2xl: 4px 4px 0px 0px hsl(0 0% 0% / 2.50);
|
||||
--tracking-normal: 0em;
|
||||
--spacing: 0.25rem;
|
||||
|
||||
--radius-sm: calc(var(--radius) - 4px);
|
||||
--radius-md: calc(var(--radius) - 2px);
|
||||
--radius-lg: var(--radius);
|
||||
--radius-xl: calc(var(--radius) + 4px);
|
||||
}
|
||||
</neo-brutalism-style>
|
||||
|
||||
Modern dark mode style like vercel, linear
|
||||
<modern-dark-mode-style>
|
||||
:root {
|
||||
--background: oklch(1 0 0);
|
||||
--foreground: oklch(0.1450 0 0);
|
||||
--card: oklch(1 0 0);
|
||||
--card-foreground: oklch(0.1450 0 0);
|
||||
--popover: oklch(1 0 0);
|
||||
--popover-foreground: oklch(0.1450 0 0);
|
||||
--primary: oklch(0.2050 0 0);
|
||||
--primary-foreground: oklch(0.9850 0 0);
|
||||
--secondary: oklch(0.9700 0 0);
|
||||
--secondary-foreground: oklch(0.2050 0 0);
|
||||
--muted: oklch(0.9700 0 0);
|
||||
--muted-foreground: oklch(0.5560 0 0);
|
||||
--accent: oklch(0.9700 0 0);
|
||||
--accent-foreground: oklch(0.2050 0 0);
|
||||
--destructive: oklch(0.5770 0.2450 27.3250);
|
||||
--destructive-foreground: oklch(1 0 0);
|
||||
--border: oklch(0.9220 0 0);
|
||||
--input: oklch(0.9220 0 0);
|
||||
--ring: oklch(0.7080 0 0);
|
||||
--chart-1: oklch(0.8100 0.1000 252);
|
||||
--chart-2: oklch(0.6200 0.1900 260);
|
||||
--chart-3: oklch(0.5500 0.2200 263);
|
||||
--chart-4: oklch(0.4900 0.2200 264);
|
||||
--chart-5: oklch(0.4200 0.1800 266);
|
||||
--sidebar: oklch(0.9850 0 0);
|
||||
--sidebar-foreground: oklch(0.1450 0 0);
|
||||
--sidebar-primary: oklch(0.2050 0 0);
|
||||
--sidebar-primary-foreground: oklch(0.9850 0 0);
|
||||
--sidebar-accent: oklch(0.9700 0 0);
|
||||
--sidebar-accent-foreground: oklch(0.2050 0 0);
|
||||
--sidebar-border: oklch(0.9220 0 0);
|
||||
--sidebar-ring: oklch(0.7080 0 0);
|
||||
--font-sans: ui-sans-serif, system-ui, -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, 'Helvetica Neue', Arial, 'Noto Sans', sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol', 'Noto Color Emoji';
|
||||
--font-serif: ui-serif, Georgia, Cambria, "Times New Roman", Times, serif;
|
||||
--font-mono: ui-monospace, SFMono-Regular, Menlo, Monaco, Consolas, "Liberation Mono", "Courier New", monospace;
|
||||
--radius: 0.625rem;
|
||||
--shadow-2xs: 0 1px 3px 0px hsl(0 0% 0% / 0.05);
|
||||
--shadow-xs: 0 1px 3px 0px hsl(0 0% 0% / 0.05);
|
||||
--shadow-sm: 0 1px 3px 0px hsl(0 0% 0% / 0.10), 0 1px 2px -1px hsl(0 0% 0% / 0.10);
|
||||
--shadow: 0 1px 3px 0px hsl(0 0% 0% / 0.10), 0 1px 2px -1px hsl(0 0% 0% / 0.10);
|
||||
--shadow-md: 0 1px 3px 0px hsl(0 0% 0% / 0.10), 0 2px 4px -1px hsl(0 0% 0% / 0.10);
|
||||
--shadow-lg: 0 1px 3px 0px hsl(0 0% 0% / 0.10), 0 4px 6px -1px hsl(0 0% 0% / 0.10);
|
||||
--shadow-xl: 0 1px 3px 0px hsl(0 0% 0% / 0.10), 0 8px 10px -1px hsl(0 0% 0% / 0.10);
|
||||
--shadow-2xl: 0 1px 3px 0px hsl(0 0% 0% / 0.25);
|
||||
--tracking-normal: 0em;
|
||||
--spacing: 0.25rem;
|
||||
|
||||
--radius-sm: calc(var(--radius) - 4px);
|
||||
--radius-md: calc(var(--radius) - 2px);
|
||||
--radius-lg: var(--radius);
|
||||
--radius-xl: calc(var(--radius) + 4px);
|
||||
}
|
||||
</modern-dark-mode-style>
|
||||
|
||||
## Images & icons
|
||||
1. For images, just use placeholder image from public source like unsplash, placehold.co or others that you already know exact image url; Don't make up urls
|
||||
2. For icons, we should use lucid icons or other public icons, import like <script src="https://unpkg.com/lucide@latest/dist/umd/lucide.min.js"></script>
|
||||
|
||||
## Script
|
||||
1. When importing tailwind css, just use <script src="https://cdn.tailwindcss.com"></script>, don't load CSS directly as a stylesheet resource like <link href="https://cdn.jsdelivr.net/npm/tailwindcss@2.2.19/dist/tailwind.min.css" rel="stylesheet">
|
||||
2. When using flowbite, import like <script src="https://cdn.jsdelivr.net/npm/flowbite@2.0.0/dist/flowbite.min.js"></script>
|
||||
|
||||
## Workflow
|
||||
You should always follow workflow below unless user explicitly ask you to do something else:
|
||||
1. Layout design
|
||||
2. Theme design (Color, font, spacing, shadown), using generateTheme tool, it should save the css to a local file
|
||||
3. Core Animation design
|
||||
4. Generate a singlehtml file for the UI
|
||||
5. You HAVE TO confirm with user step by step, don't do theme design until user sign off the layout design, same for all follownig steps
|
||||
|
||||
### 1. Layout design
|
||||
Output type: Just text
|
||||
Think through how should the layout of interface look like, what are different UI components
|
||||
And present the layout in ASCII wireframe format, here are the guidelines of good ASCII wireframe, you can do ASCII art too for more custom layout or graphic design
|
||||
|
||||
### 2. Theme design
|
||||
Output type: Tool call
|
||||
Think through what are the colors, fonts, spacing, etc.
|
||||
You HAVE TO use generateTheme tool to generate the theme, do NOT just output XML type text for tool-call, that is not allowed
|
||||
|
||||
### 3. Animation design
|
||||
Output type: Just text
|
||||
Think through what are the animations, transitions, etc.
|
||||
|
||||
### 4. Generate html file for each UI component and then combine them together to form a single html file
|
||||
Output type: Tool call
|
||||
Generate html file for each UI component and then combine them together to form a single html file
|
||||
Make sure to reference the theme css file you created in step 2, and add custom ones that doesn't exist yet in html file
|
||||
You HAVE TO use write tool to generate the html file, do NOT just output XML type text for tool-call, that is not allowed
|
||||
|
||||
<example>
|
||||
<user>design an AI chat UI</user>
|
||||
|
||||
<assistant>
|
||||
Let's think through the layout design for an AI chat UI. Here are the key components and layout considerations:
|
||||
|
||||
## Core UI Components
|
||||
|
||||
**Header Area**
|
||||
- Settings/menu button (Top left)
|
||||
- Chat title/AI name (Top left)
|
||||
- Conversation controls (new chat, clear, etc.) (Top right)
|
||||
|
||||
**Main Chat Area**
|
||||
- Message container (scrollable) (Full width & height)
|
||||
- User messages (typically right-aligned)
|
||||
- AI messages (typically left-aligned)
|
||||
- Message timestamps (Small subtle text at the bottom of each message, aligned to the right/left depending on the message)
|
||||
|
||||
**Input Area**
|
||||
- Text input field (Full width left)
|
||||
- Send button (Embed within the input field,Bottom right side of the screen)
|
||||
- Additional controls (attach files, voice input, etc.) (Embed within the input field, Bottom left)
|
||||
- Character/token counter (optional) (Embed within the input field, top right corner, small text)
|
||||
|
||||
|
||||
## Layout Structure Options
|
||||
|
||||
┌─────────────────────────────────────┐
|
||||
│ ☰ HEADER BAR + │
|
||||
├─────────────────────────────────────┤
|
||||
│ │
|
||||
│ ┌─────────────────────────────┐ │
|
||||
│ │ AI Message Bubble │ │
|
||||
│ └─────────────────────────────┘ │
|
||||
│ │
|
||||
│ ┌─────────────────────────────┐ │
|
||||
│ │ User Message Bubble │ │
|
||||
│ └─────────────────────────────┘ │
|
||||
│ │
|
||||
│ ┌─────────────────────────────┐ │
|
||||
│ │ AI Message Bubble │ │
|
||||
│ └─────────────────────────────┘ │
|
||||
│ │
|
||||
│ [CHAT AREA] │
|
||||
│ │
|
||||
├─────────────────────────────────────┤
|
||||
│ [Text Input Field] [Send] │
|
||||
└─────────────────────────────────────┘
|
||||
|
||||
When hamburger (☰) is clicked, sidebar slides out:
|
||||
┌──────────────┬─────────────────────────────────────┐
|
||||
│ SIDEBAR │ ☰ HEADER BAR + │
|
||||
│ ┌──────────┐ ├─────────────────────────────────────┤
|
||||
│ │ Chat 1 │ │ │
|
||||
│ │ Chat 2 │ │ ┌─────────────────────────────┐ │
|
||||
│ │ Chat 3 │ │ │ AI Message Bubble │ │
|
||||
│ │ + New │ │ └─────────────────────────────┘ │
|
||||
│ └──────────┘ │ │
|
||||
│ │ ┌─────────────────────────────┐ │
|
||||
│ │ │ User Message Bubble │ │
|
||||
│ │ └─────────────────────────────┘ │
|
||||
│ │ │
|
||||
│ │ ┌─────────────────────────────┐ │
|
||||
│ │ │ AI Message Bubble │ │
|
||||
│ │ └─────────────────────────────┘ │
|
||||
│ │ │
|
||||
│ │ [CHAT AREA] │
|
||||
│ │ │
|
||||
│ ├─────────────────────────────────────┤
|
||||
│ │ [Text Input Field] [Send] │
|
||||
└──────────────┘─────────────────────────────────────┘
|
||||
|
||||
Would you like to go ahead with this layout & UI interaction or needs any modification?
|
||||
</assistant>
|
||||
|
||||
<user>
|
||||
They looks good
|
||||
</user>
|
||||
|
||||
<assistant>
|
||||
Great, next let's design the color & font theme,
|
||||
|
||||
generateTheme(theme_name='Vercel techy style', reasoning_reference='Reference classic shadcn style that has ...', cssFilePath='.superdesign/design_iterations/theme_1.css', cssSheet=':root {
|
||||
--background: oklch(1.0000 0 0);
|
||||
--foreground: oklch(0.1448 0 0);
|
||||
--card: oklch(1.0000 0 0);
|
||||
--card-foreground: oklch(0.1448 0 0);
|
||||
--popover: oklch(1.0000 0 0);
|
||||
--popover-foreground: oklch(0.1448 0 0);
|
||||
--primary: oklch(0.5555 0 0);
|
||||
--primary-foreground: oklch(0.9851 0 0);
|
||||
--secondary: oklch(0.9702 0 0);
|
||||
--secondary-foreground: oklch(0.2046 0 0);
|
||||
--muted: oklch(0.9702 0 0);
|
||||
--muted-foreground: oklch(0.5486 0 0);
|
||||
--accent: oklch(0.9702 0 0);
|
||||
--accent-foreground: oklch(0.2046 0 0);
|
||||
--destructive: oklch(0.5830 0.2387 28.4765);
|
||||
--destructive-foreground: oklch(0.9702 0 0);
|
||||
--border: oklch(0.9219 0 0);
|
||||
--input: oklch(0.9219 0 0);
|
||||
--ring: oklch(0.7090 0 0);
|
||||
--chart-1: oklch(0.5555 0 0);
|
||||
--chart-2: oklch(0.5555 0 0);
|
||||
--chart-3: oklch(0.5555 0 0);
|
||||
--chart-4: oklch(0.5555 0 0);
|
||||
--chart-5: oklch(0.5555 0 0);
|
||||
--sidebar: oklch(0.9851 0 0);
|
||||
--sidebar-foreground: oklch(0.1448 0 0);
|
||||
--sidebar-primary: oklch(0.2046 0 0);
|
||||
--sidebar-primary-foreground: oklch(0.9851 0 0);
|
||||
--sidebar-accent: oklch(0.9702 0 0);
|
||||
--sidebar-accent-foreground: oklch(0.2046 0 0);
|
||||
--sidebar-border: oklch(0.9219 0 0);
|
||||
--sidebar-ring: oklch(0.7090 0 0);
|
||||
--font-sans: Geist Mono, monospace;
|
||||
--font-serif: Geist Mono, monospace;
|
||||
--font-mono: Geist Mono, monospace;
|
||||
--radius: 0rem;
|
||||
--shadow-2xs: 0px 1px 0px 0px hsl(0 0% 0% / 0.00);
|
||||
--shadow-xs: 0px 1px 0px 0px hsl(0 0% 0% / 0.00);
|
||||
--shadow-sm: 0px 1px 0px 0px hsl(0 0% 0% / 0.00), 0px 1px 2px -1px hsl(0 0% 0% / 0.00);
|
||||
--shadow: 0px 1px 0px 0px hsl(0 0% 0% / 0.00), 0px 1px 2px -1px hsl(0 0% 0% / 0.00);
|
||||
--shadow-md: 0px 1px 0px 0px hsl(0 0% 0% / 0.00), 0px 2px 4px -1px hsl(0 0% 0% / 0.00);
|
||||
--shadow-lg: 0px 1px 0px 0px hsl(0 0% 0% / 0.00), 0px 4px 6px -1px hsl(0 0% 0% / 0.00);
|
||||
--shadow-xl: 0px 1px 0px 0px hsl(0 0% 0% / 0.00), 0px 8px 10px -1px hsl(0 0% 0% / 0.00);
|
||||
--shadow-2xl: 0px 1px 0px 0px hsl(0 0% 0% / 0.00);
|
||||
--tracking-normal: 0em;
|
||||
--spacing: 0.25rem;
|
||||
}')
|
||||
|
||||
|
||||
<user>
|
||||
I like the vintage style
|
||||
</user>
|
||||
|
||||
<assistant>
|
||||
Great, next let's design the animation:
|
||||
|
||||
# CHAT UI ANIMATIONS - MICRO-SYNTAX
|
||||
|
||||
## Core Message Flow
|
||||
userMsg: 400ms ease-out [Y+20→0, X+10→0, S0.9→1]
|
||||
aiMsg: 600ms bounce [Y+15→0, S0.95→1] +200ms
|
||||
typing: 1400ms ∞ [Y±8, α0.4→1] stagger+200ms
|
||||
status: 300ms ease-out [α0.6→1, S1→1.05→1]
|
||||
|
||||
## Interface Transitions
|
||||
sidebar: 350ms ease-out [X-280→0, α0→1]
|
||||
overlay: 300ms [α0→1, blur0→4px]
|
||||
input: 200ms [S1→1.01, shadow+ring] focus
|
||||
input: 150ms [S1.01→1, shadow-ring] blur
|
||||
|
||||
## Button Interactions
|
||||
sendBtn: 150ms [S1→0.95→1, R±2°] press
|
||||
sendBtn: 200ms [S1→1.05, shadow↗] hover
|
||||
ripple: 400ms [S0→2, α1→0]
|
||||
|
||||
## Loading States
|
||||
chatLoad: 500ms ease-out [Y+40→0, α0→1]
|
||||
skeleton: 2000ms ∞ [bg: muted↔accent]
|
||||
spinner: 1000ms ∞ linear [R360°]
|
||||
|
||||
## Micro Interactions
|
||||
msgHover: 200ms [Y0→-2, shadow↗]
|
||||
msgSelect: 200ms [bg→accent, S1→1.02]
|
||||
error: 400ms [X±5] shake
|
||||
success: 600ms bounce [S0→1.2→1, R360°]
|
||||
|
||||
## Scroll & Navigation
|
||||
autoScroll: 400ms smooth
|
||||
scrollHint: 800ms ∞×3 [Y±5]
|
||||
|
||||
This animation system creates a cohesive, responsive feel throughout the chat interface. Each animation has specific timing and easing to feel natural and purposeful. Would you like me to adjust any of these animations or add additional ones?
|
||||
|
||||
</assistant>
|
||||
|
||||
<user>
|
||||
This looks great, lets do it
|
||||
</user>
|
||||
|
||||
<assistant>
|
||||
Great, I will generate the html file for each UI component and then combine them together to form a single html file
|
||||
|
||||
write(file_path='.superdesign/design_iterations/chat_ui.css', content='...')
|
||||
write(file_path='.superdesign/design_iterations/chat_ui.html', content='...')
|
||||
|
||||
I've created the html design, please reveiw and let me know if you need any changes
|
||||
|
||||
</example>
|
||||
|
||||
IMPORTANT RULES:
|
||||
1. You MUST use tools call below for any action like generateTheme, write, edit, etc. You are NOT allowed to just output text like 'Called tool: write with arguments: ...' or <tool-call>...</tool-call>; MUST USE TOOL CALL (This is very important!!)
|
||||
2. You MUST confirm the layout, and then theme style, and then animation
|
||||
3. You MUST use .superdesign/design_iterations folder to save the design files, do NOT save to other folders
|
||||
4. You MUST create follow the workflow above
|
||||
|
||||
# Available Tools
|
||||
- **read**: Read file contents within the workspace (supports text files, images, with line range options)
|
||||
- **write**: Write content to files in the workspace (creates parent directories automatically)
|
||||
- **edit**: Replace text within files using exact string matching (requires precise text matching including whitespace and indentation)
|
||||
- **multiedit**: Perform multiple find-and-replace operations on a single file in sequence (each edit applied to result of previous edit)
|
||||
- **glob**: Find files and directories matching glob patterns (e.g., "*.js", "src/**/*.ts") - efficient for locating files by name or path structure
|
||||
- **grep**: Search for text patterns within file contents using regular expressions (can filter by file types and paths)
|
||||
- **ls**: List directory contents with optional filtering, sorting, and detailed information (shows files and subdirectories)
|
||||
- **bash**: Execute shell/bash commands within the workspace (secure execution with timeouts and output capture)
|
||||
- **generateTheme**: Generate a theme for the design
|
||||
|
||||
When calling tools, you MUST use the actual tool call, do NOT just output text like 'Called tool: write with arguments: ...' or <tool-call>...</tool-call>, this won't actually call the tool. (This is very important to my life, please follow)
|
||||
145
.cursor/rules/project-status.mdc
Normal file
145
.cursor/rules/project-status.mdc
Normal file
@ -0,0 +1,145 @@
|
||||
---
|
||||
description:
|
||||
globs:
|
||||
alwaysApply: true
|
||||
---
|
||||
# Project Status Guidelines
|
||||
|
||||
## **Project Stage Assessment**
|
||||
- **Determine Current Stage**: Always assess project maturity before making development decisions
|
||||
- **Stage-Based Priorities**: Adjust development focus based on current project stage
|
||||
- **Documentation Updates**: Keep [CLAUDE.md](mdc:CLAUDE.md) "Project Status" section current
|
||||
|
||||
## **Development Stage Categories**
|
||||
|
||||
Based on the project stage assessment from `@create-app-design-document.md`:
|
||||
|
||||
### **Stage-Based Development Guidelines**
|
||||
|
||||
Development priorities should be determined based on the project stage assessment from the app design document. Each stage has different priorities for what AI should care about vs skip during development.
|
||||
|
||||
**Reference:** The specific DO/DON'T lists for each stage are defined in:
|
||||
- App Design Document generated via `@create-app-design-document.md`
|
||||
- CLAUDE.md "Project Status" section (updated during app design document creation)
|
||||
|
||||
## **Implementation Guidelines**
|
||||
|
||||
### **Security-First Approach (All Stages)**
|
||||
```typescript
|
||||
// ✅ DO: Always validate inputs with Zod
|
||||
const userInput = userSchema.parse(input);
|
||||
|
||||
// ✅ DO: Use protectedProcedure for auth
|
||||
export const updateUser = protectedProcedure
|
||||
.input(updateUserSchema)
|
||||
.mutation(async ({ ctx, input }) => {
|
||||
// Implementation
|
||||
});
|
||||
|
||||
// ❌ DON'T: Skip validation even in pre-MVP
|
||||
const user = input; // Unsafe
|
||||
```
|
||||
|
||||
### **Stage-Appropriate Error Handling**
|
||||
```typescript
|
||||
// ✅ Pre-MVP: Basic error handling
|
||||
try {
|
||||
await updateUser(data);
|
||||
} catch (error) {
|
||||
toast.error('Update failed');
|
||||
}
|
||||
|
||||
// ✅ Production: Comprehensive error handling
|
||||
try {
|
||||
await updateUser(data);
|
||||
} catch (error) {
|
||||
logger.error('User update failed', { userId, error });
|
||||
if (error instanceof ValidationError) {
|
||||
toast.error('Please check your input');
|
||||
} else {
|
||||
toast.error('An unexpected error occurred');
|
||||
captureException(error);
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## **Decision Framework**
|
||||
|
||||
### **Feature Priority Questions**
|
||||
1. **Stage Check**: What project stage are we in?
|
||||
2. **Security Impact**: Does this affect user data or system security?
|
||||
3. **Core Functionality**: Is this essential for primary user goals?
|
||||
4. **User Impact**: How many users does this affect?
|
||||
5. **Technical Debt**: Can we defer this to post-MVP?
|
||||
|
||||
### **Code Quality Standards**
|
||||
- **Pre-MVP**: Focus on readable, working code with security
|
||||
- **MVP+**: Add testing for user-facing features
|
||||
- **Production**: Full quality standards and documentation
|
||||
- **Enterprise**: Advanced patterns and team coordination
|
||||
|
||||
## **Status Documentation**
|
||||
|
||||
### **Required in CLAUDE.md**
|
||||
```markdown
|
||||
## Project Status: [Stage Name]
|
||||
|
||||
**Current Stage**: [Pre-MVP | MVP | Production | Enterprise]
|
||||
|
||||
**DO NOT care about:**
|
||||
- [List based on stage]
|
||||
|
||||
**DO care about:**
|
||||
- [List based on stage]
|
||||
|
||||
**Next Stage Goals:**
|
||||
- [Key milestones to reach next stage]
|
||||
```
|
||||
|
||||
### **Regular Updates**
|
||||
- Update status when deploying to production
|
||||
- Reassess priorities quarterly or at major milestones
|
||||
- Document stage transition criteria
|
||||
- Communicate status changes to team
|
||||
|
||||
## **Examples by Stage**
|
||||
|
||||
### **Pre-MVP Example: Authentication Feature**
|
||||
```typescript
|
||||
// ✅ FOCUS: Core login flow with security
|
||||
export const loginUser = publicProcedure
|
||||
.input(loginSchema)
|
||||
.mutation(async ({ input }) => {
|
||||
const user = await verifyCredentials(input);
|
||||
const session = await createSession(user.id);
|
||||
return { success: true, sessionId: session.id };
|
||||
});
|
||||
|
||||
// ❌ SKIP: Comprehensive testing (save for MVP+)
|
||||
// ❌ SKIP: Password strength indicators (save for MVP+)
|
||||
// ❌ SKIP: Remember me functionality (save for MVP+)
|
||||
```
|
||||
|
||||
### **Production Example: Authentication Feature**
|
||||
```typescript
|
||||
// ✅ COMPREHENSIVE: Full feature with testing, accessibility, monitoring
|
||||
export const loginUser = publicProcedure
|
||||
.input(loginSchema)
|
||||
.mutation(async ({ input, ctx }) => {
|
||||
try {
|
||||
await rateLimiter.check(ctx.ip);
|
||||
const user = await verifyCredentials(input);
|
||||
const session = await createSession(user.id);
|
||||
|
||||
logger.info('User login successful', { userId: user.id });
|
||||
await auditLog.record('USER_LOGIN', { userId: user.id });
|
||||
|
||||
return { success: true, sessionId: session.id };
|
||||
} catch (error) {
|
||||
logger.warn('Login attempt failed', { ip: ctx.ip, error });
|
||||
throw new TRPCError({ code: 'UNAUTHORIZED', message: 'Invalid credentials' });
|
||||
}
|
||||
});
|
||||
```
|
||||
|
||||
Follow stage-appropriate development practices to maintain velocity while ensuring quality at the right time.
|
||||
73
.cursor/rules/self-improve.mdc
Normal file
73
.cursor/rules/self-improve.mdc
Normal file
@ -0,0 +1,73 @@
|
||||
---
|
||||
description: Guidelines for continuously improving Cursor rules based on emerging code patterns and best practices.
|
||||
globs: **/*
|
||||
alwaysApply: true
|
||||
---
|
||||
|
||||
- **Rule Improvement Triggers:**
|
||||
- New code patterns not covered by existing rules
|
||||
- Repeated similar implementations across files
|
||||
- Common error patterns that could be prevented
|
||||
- New libraries or tools being used consistently
|
||||
- Emerging best practices in the codebase
|
||||
|
||||
- **Analysis Process:**
|
||||
- Compare new code with existing rules
|
||||
- Identify patterns that should be standardized
|
||||
- Look for references to external documentation
|
||||
- Check for consistent error handling patterns
|
||||
- Monitor test patterns and coverage
|
||||
|
||||
- **Rule Updates:**
|
||||
- **Add New Rules When:**
|
||||
- A new technology/pattern is used in 3+ files
|
||||
- Common bugs could be prevented by a rule
|
||||
- Code reviews repeatedly mention the same feedback
|
||||
- New security or performance patterns emerge
|
||||
|
||||
- **Modify Existing Rules When:**
|
||||
- Better examples exist in the codebase
|
||||
- Additional edge cases are discovered
|
||||
- Related rules have been updated
|
||||
- Implementation details have changed
|
||||
|
||||
- **Example Pattern Recognition:**
|
||||
```typescript
|
||||
// If you see repeated patterns like:
|
||||
const data = await prisma.user.findMany({
|
||||
select: { id: true, email: true },
|
||||
where: { status: 'ACTIVE' }
|
||||
});
|
||||
|
||||
// Consider adding to [prisma.mdc](mdc:.cursor/rules/prisma.mdc):
|
||||
// - Standard select fields
|
||||
// - Common where conditions
|
||||
// - Performance optimization patterns
|
||||
```
|
||||
|
||||
- **Rule Quality Checks:**
|
||||
- Rules should be actionable and specific
|
||||
- Examples should come from actual code
|
||||
- References should be up to date
|
||||
- Patterns should be consistently enforced
|
||||
|
||||
- **Continuous Improvement:**
|
||||
- Monitor code review comments
|
||||
- Track common development questions
|
||||
- Update rules after major refactors
|
||||
- Add links to relevant documentation
|
||||
- Cross-reference related rules
|
||||
|
||||
- **Rule Deprecation:**
|
||||
- Mark outdated patterns as deprecated
|
||||
- Remove rules that no longer apply
|
||||
- Update references to deprecated rules
|
||||
- Document migration paths for old patterns
|
||||
|
||||
- **Documentation Updates:**
|
||||
- Keep examples synchronized with code
|
||||
- Update references to external docs
|
||||
- Maintain links between related rules
|
||||
- Document breaking changes
|
||||
- Update CLAUDE.md when adding new rules or slash commands
|
||||
Follow for proper rule formatting and structure.
|
||||
489
.cursor/rules/taskmaster/dev-workflow.mdc
Normal file
489
.cursor/rules/taskmaster/dev-workflow.mdc
Normal file
@ -0,0 +1,489 @@
|
||||
---
|
||||
description: Guide for using Taskmaster's tagged task management system in development workflows
|
||||
globs: **/*
|
||||
alwaysApply: true
|
||||
---
|
||||
|
||||
# Taskmaster Tagged Development Workflow
|
||||
|
||||
This guide outlines the standard process for using Taskmaster's **tagged task management system** to manage software development projects. This is written as instructions for you, the AI agent.
|
||||
|
||||
**⚠️ CRITICAL PRINCIPLE: Never Work on Master Tag**
|
||||
- **NEVER suggest working directly on the `master` tag** for feature development
|
||||
- **ALWAYS guide users to create or switch to appropriate feature tags**
|
||||
- The `master` tag is reserved for high-level deliverables and major milestones only
|
||||
|
||||
- **Your Goal**: Guide users to use the tagged system effectively from the start, creating organized, conflict-free development workflows
|
||||
|
||||
## The Tagged Development Loop
|
||||
The fundamental development cycle you will facilitate is:
|
||||
1. **`tags`**: Show available tag contexts and current active tag
|
||||
2. **`use-tag <feature-tag>`**: Switch to appropriate feature context (NOT master)
|
||||
3. **`list`**: Show tasks in the current tag context
|
||||
4. **`next`**: Help the user decide what to work on in current tag
|
||||
5. **`show <id>`**: Provide details for a specific task in current tag
|
||||
6. **`expand <id>`**: Break down complex tasks within the tag context
|
||||
7. **Implement**: The user writes the code and tests
|
||||
8. **`update-subtask`**: Log progress and findings within the tag
|
||||
9. **`set-status`**: Mark tasks as `done` within the tag context
|
||||
10. **Repeat** or switch to another tag context
|
||||
|
||||
All command executions operate within the current tag context. Always verify the active tag before starting work.
|
||||
|
||||
---
|
||||
|
||||
## Standard Development Workflow Process
|
||||
|
||||
### Standard Tagged Workflow (Always Start Here)
|
||||
|
||||
For ALL projects, guide users to use the tagged system from the beginning:
|
||||
|
||||
1. **Initialize with Tags in Mind:**
|
||||
- Run `initialize_project` / `task-master init` with appropriate rule sets
|
||||
- Immediately create feature tags: `add_tag user-auth --description="Authentication features"`
|
||||
- Never parse PRDs directly into master
|
||||
|
||||
2. **Create Tagged PRDs:**
|
||||
```bash
|
||||
# Guide users to create context-specific PRDs
|
||||
.taskmaster/docs/
|
||||
prd-user-authentication.md
|
||||
prd-payment-system.md
|
||||
prd-mobile-app.md
|
||||
```
|
||||
|
||||
3. **Parse PRDs into Feature Tags:**
|
||||
```bash
|
||||
task-master use-tag user-auth
|
||||
task-master parse-prd .taskmaster/docs/prd-user-authentication.md
|
||||
|
||||
task-master use-tag payments
|
||||
task-master parse-prd .taskmaster/docs/prd-payment-system.md
|
||||
```
|
||||
|
||||
4. **Daily Tagged Workflow:**
|
||||
- Check contexts: `list_tags` / `task-master tags --show-metadata`
|
||||
- Switch context: `use_tag` / `task-master use-tag <feature-tag>`
|
||||
- Work within tag: `next_task` / `task-master next`
|
||||
- Analyze complexity: `analyze_project_complexity --research`
|
||||
- Expand tasks: `expand_task --id=<id> --research`
|
||||
- Log progress: `update_subtask --id=<id> --prompt="..."`
|
||||
- Mark complete: `set_task_status --id=<id> --status=done`
|
||||
|
||||
---
|
||||
|
||||
## Always Use Tagged Workflows
|
||||
|
||||
**You must ALWAYS guide users to use tagged workflows from the start.** The tagged system is not an advanced feature - it's the standard way to use Task Master. This prevents conflicts, maintains organization, and scales naturally with project growth.
|
||||
|
||||
### Standard Tag Creation Patterns
|
||||
|
||||
Always suggest creating tags for these common scenarios:
|
||||
|
||||
#### Pattern 1: Feature Development (Most Common)
|
||||
This is the standard approach for any new feature.
|
||||
|
||||
- **Trigger**: User mentions implementing any new feature or functionality
|
||||
- **Your Action**: Immediately suggest creating a dedicated tag
|
||||
- **Your Suggested Prompt**: *"I'll create a dedicated tag for this feature to keep tasks organized. This is the standard Task Master workflow that prevents conflicts and maintains clean task organization."*
|
||||
- **Example Implementation**:
|
||||
```bash
|
||||
# For authentication feature
|
||||
task-master add-tag user-auth --description="User authentication features"
|
||||
task-master use-tag user-auth
|
||||
# Then create PRD and parse it
|
||||
```
|
||||
|
||||
#### Pattern 2: Git Branch Alignment
|
||||
- **Trigger**: User creates a new git branch
|
||||
- **Your Action**: Create a corresponding tag to maintain branch-task alignment
|
||||
- **Your Suggested Prompt**: *"I'll create a task tag that matches your git branch. This keeps your tasks aligned with your code changes."*
|
||||
- **Tool to Use**: `task-master add-tag --from-branch`
|
||||
|
||||
#### Pattern 3: Team Collaboration
|
||||
- **Trigger**: Multiple developers working on the same project
|
||||
- **Your Action**: Ensure each developer has their own tag context
|
||||
- **Your Suggested Prompt**: *"To prevent conflicts with your team, let's create separate task contexts for each developer's work."*
|
||||
- **Example**: `task-master add-tag alice-frontend --description="Alice's frontend tasks"`
|
||||
|
||||
#### Pattern 4: Experiments or Refactoring
|
||||
- **Trigger**: Trying new approaches or major refactoring
|
||||
- **Your Action**: Create experimental tags that can be deleted if not needed
|
||||
- **Your Suggested Prompt**: *"I'll create an experimental tag for this work. If it doesn't work out, we can simply delete the tag."*
|
||||
- **Example**: `task-master add-tag experiment-graphql --description="Testing GraphQL migration"`
|
||||
|
||||
#### Pattern 5: PRD-Driven Development (Best Practice)
|
||||
This is the recommended approach for all significant features.
|
||||
|
||||
- **Trigger**: Any feature that requires planning
|
||||
- **Your Action**: Guide through PRD creation and parsing
|
||||
- **Your Implementation Flow**:
|
||||
1. **Create feature tag**: `add_tag feature-dashboard --description="Dashboard features"`
|
||||
2. **Switch to tag**: `use_tag feature-dashboard`
|
||||
3. **Create PRD**: Work with user to create `.taskmaster/docs/prd-dashboard.md`
|
||||
4. **Parse PRD**: `parse_prd .taskmaster/docs/prd-dashboard.md`
|
||||
5. **Analyze & Expand**: `analyze_project_complexity --research` then `expand_all --research`
|
||||
|
||||
#### Pattern 5: Version-Based Development
|
||||
Tailor your approach based on the project maturity indicated by tag names.
|
||||
|
||||
- **Prototype/MVP Tags** (`prototype`, `mvp`, `poc`, `v0.x`):
|
||||
- **Your Approach**: Focus on speed and functionality over perfection
|
||||
- **Task Generation**: Create tasks that emphasize "get it working" over "get it perfect"
|
||||
- **Complexity Level**: Lower complexity, fewer subtasks, more direct implementation paths
|
||||
- **Research Prompts**: Include context like "This is a prototype - prioritize speed and basic functionality over optimization"
|
||||
- **Example Prompt Addition**: *"Since this is for the MVP, I'll focus on tasks that get core functionality working quickly rather than over-engineering."*
|
||||
|
||||
- **Production/Mature Tags** (`v1.0+`, `production`, `stable`):
|
||||
- **Your Approach**: Emphasize robustness, testing, and maintainability
|
||||
- **Task Generation**: Include comprehensive error handling, testing, documentation, and optimization
|
||||
- **Complexity Level**: Higher complexity, more detailed subtasks, thorough implementation paths
|
||||
- **Research Prompts**: Include context like "This is for production - prioritize reliability, performance, and maintainability"
|
||||
- **Example Prompt Addition**: *"Since this is for production, I'll ensure tasks include proper error handling, testing, and documentation."*
|
||||
|
||||
### The Master Tag Strategy
|
||||
|
||||
**Remember**: The `master` tag is NOT for daily development work. Guide users to understand what belongs there:
|
||||
|
||||
#### What Goes in Master Tag:
|
||||
- **High-level deliverables** that provide significant business value
|
||||
- **Major milestones** and epic-level features
|
||||
- **Critical infrastructure** work affecting the entire project
|
||||
- **Release-blocking** items
|
||||
- **References to feature tags** (e.g., "Complete user authentication - see user-auth tag")
|
||||
|
||||
#### What NEVER Goes in Master:
|
||||
- **Feature implementation tasks** (use feature-specific tags)
|
||||
- **Bug fixes** (use `bugfix-*` tags)
|
||||
- **Refactoring work** (use `refactor-*` tags)
|
||||
- **Experimental features** (use `experiment-*` tags)
|
||||
- **Individual developer tasks** (use person-specific tags)
|
||||
|
||||
#### PRD-Driven Feature Development
|
||||
|
||||
**For New Major Features**:
|
||||
1. **Identify the Initiative**: When user describes a significant feature
|
||||
2. **Create Dedicated Tag**: `add_tag feature-[name] --description="[Feature description]"`
|
||||
3. **Collaborative PRD Creation**: Work with user to create comprehensive PRD in `.taskmaster/docs/feature-[name]-prd.txt`
|
||||
4. **Parse & Prepare**:
|
||||
- `parse_prd .taskmaster/docs/feature-[name]-prd.txt --tag=feature-[name]`
|
||||
- `analyze_project_complexity --tag=feature-[name] --research`
|
||||
- `expand_all --tag=feature-[name] --research`
|
||||
5. **Add Master Reference**: Create a high-level task in `master` that references the feature tag
|
||||
|
||||
**For Existing Codebase Analysis**:
|
||||
When users initialize Taskmaster on existing projects:
|
||||
1. **Codebase Discovery**: Use your native tools for producing deep context about the code base. You may use `research` tool with `--tree` and `--files` to collect up to date information using the existing architecture as context.
|
||||
2. **Collaborative Assessment**: Work with user to identify improvement areas, technical debt, or new features
|
||||
3. **Strategic PRD Creation**: Co-author PRDs that include:
|
||||
- Current state analysis (based on your codebase research)
|
||||
- Proposed improvements or new features
|
||||
- Implementation strategy considering existing code
|
||||
4. **Tag-Based Organization**: Parse PRDs into appropriate tags (`refactor-api`, `feature-dashboard`, `tech-debt`, etc.)
|
||||
5. **Master List Curation**: Keep only the most valuable initiatives in master
|
||||
|
||||
The parse-prd's `--append` flag enables the user to parse multple PRDs within tags or across tags. PRDs should be focused and the number of tasks they are parsed into should be strategically chosen relative to the PRD's complexity and level of detail.
|
||||
|
||||
### Common Workflow Examples
|
||||
|
||||
**Example 1: Starting a New Feature**
|
||||
```
|
||||
User: "I need to add user authentication"
|
||||
Your Response: "I'll set up a dedicated tag for the authentication feature following Task Master's standard workflow."
|
||||
Actions:
|
||||
1. add_tag user-auth --description="User authentication features"
|
||||
2. use_tag user-auth
|
||||
3. "Let's create a PRD for this feature in .taskmaster/docs/prd-user-authentication.md"
|
||||
4. parse_prd .taskmaster/docs/prd-user-authentication.md
|
||||
```
|
||||
|
||||
**Example 2: Cross-Tag Development**
|
||||
```
|
||||
User: "The mobile app needs to use the authentication APIs"
|
||||
Your Response: "Let me check the auth implementation status and coordinate between tags."
|
||||
Actions:
|
||||
1. use_tag user-auth
|
||||
2. get_task 2 # Check auth API status
|
||||
3. use_tag mobile
|
||||
4. update_subtask --id=3.1 --prompt="Auth APIs completed in user-auth tag, ready for integration"
|
||||
```
|
||||
|
||||
**Example 3: Managing Multiple Contexts**
|
||||
```
|
||||
User: "I'm working on both payments and user profiles"
|
||||
Your Response: "Let's organize these into separate contexts so you can switch between them cleanly."
|
||||
Actions:
|
||||
1. tags --show-metadata # Show current contexts
|
||||
2. add_tag payments --description="Payment system implementation"
|
||||
3. add_tag user-profiles --description="User profile features"
|
||||
4. "You can now switch between contexts with 'use-tag payments' or 'use-tag user-profiles'"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Primary Interaction: MCP Server vs. CLI
|
||||
|
||||
Taskmaster offers two primary ways to interact:
|
||||
|
||||
1. **MCP Server (Recommended for Integrated Tools)**:
|
||||
- For AI agents and integrated development environments (like Cursor), interacting via the **MCP server is the preferred method**.
|
||||
- The MCP server exposes Taskmaster functionality through a set of tools (e.g., `get_tasks`, `add_subtask`).
|
||||
- This method offers better performance, structured data exchange, and richer error handling compared to CLI parsing.
|
||||
- Refer to @`mcp.mdc` for details on the MCP architecture and available tools.
|
||||
- A comprehensive list and description of MCP tools and their corresponding CLI commands can be found in @`taskmaster.mdc`.
|
||||
- **Restart the MCP server** if core logic in `scripts/modules` or MCP tool/direct function definitions change.
|
||||
- **Note**: MCP tools fully support tagged task lists with complete tag management capabilities.
|
||||
|
||||
2. **`task-master` CLI (For Users & Fallback)**:
|
||||
- The global `task-master` command provides a user-friendly interface for direct terminal interaction.
|
||||
- It can also serve as a fallback if the MCP server is inaccessible or a specific function isn't exposed via MCP.
|
||||
- Install globally with `npm install -g task-master-ai` or use locally via `npx task-master-ai ...`.
|
||||
- The CLI commands often mirror the MCP tools (e.g., `task-master list` corresponds to `get_tasks`).
|
||||
- Refer to @`taskmaster.mdc` for a detailed command reference.
|
||||
- **Tagged Task Lists**: CLI fully supports the new tagged system with seamless migration.
|
||||
|
||||
## Critical Tagged System Principles
|
||||
|
||||
### For Your Implementation:
|
||||
- **Task Independence**: Each tag has its own task numbering starting from 1
|
||||
- **Context Isolation**: Changes in one tag never affect another tag
|
||||
- **No Cross-Tag Dependencies**: Dependencies only work within the same tag
|
||||
- **Always Verify Context**: Check active tag before any operation with `tags`
|
||||
- **Manual Tag Switching**: Never assume tag context, always explicitly switch
|
||||
|
||||
### Key Commands to Use Frequently:
|
||||
- `list_tags` - Show all tags with current context marked
|
||||
- `use_tag <name>` - Switch to specific tag context
|
||||
- `add_tag <name> --description="..."` - Create new contexts
|
||||
- `parse_prd <file>` - Always parse into current tag, not master
|
||||
|
||||
### File Organization:
|
||||
```
|
||||
.taskmaster/
|
||||
├── tasks/
|
||||
│ └── tasks.json # Contains ALL tag contexts
|
||||
├── docs/
|
||||
│ ├── prd-master.md # High-level only
|
||||
│ ├── prd-user-auth.md # Feature PRDs
|
||||
│ └── prd-payments.md # Feature PRDs
|
||||
└── state.json # Current tag context
|
||||
|
||||
---
|
||||
|
||||
## Task Complexity Analysis
|
||||
|
||||
- Run `analyze_project_complexity` / `task-master analyze-complexity --research` (see @`taskmaster.mdc`) for comprehensive analysis
|
||||
- Review complexity report via `complexity_report` / `task-master complexity-report` (see @`taskmaster.mdc`) for a formatted, readable version.
|
||||
- Focus on tasks with highest complexity scores (8-10) for detailed breakdown
|
||||
- Use analysis results to determine appropriate subtask allocation
|
||||
- Note that reports are automatically used by the `expand_task` tool/command
|
||||
|
||||
## Task Breakdown Process
|
||||
|
||||
- Use `expand_task` / `task-master expand --id=<id>`. It automatically uses the complexity report if found, otherwise generates default number of subtasks.
|
||||
- Use `--num=<number>` to specify an explicit number of subtasks, overriding defaults or complexity report recommendations.
|
||||
- Add `--research` flag to leverage Perplexity AI for research-backed expansion.
|
||||
- Add `--force` flag to clear existing subtasks before generating new ones (default is to append).
|
||||
- Use `--prompt="<context>"` to provide additional context when needed.
|
||||
- Review and adjust generated subtasks as necessary.
|
||||
- Use `expand_all` tool or `task-master expand --all` to expand multiple pending tasks at once, respecting flags like `--force` and `--research`.
|
||||
- If subtasks need complete replacement (regardless of the `--force` flag on `expand`), clear them first with `clear_subtasks` / `task-master clear-subtasks --id=<id>`.
|
||||
|
||||
## Implementation Drift Handling
|
||||
|
||||
- When implementation differs significantly from planned approach
|
||||
- When future tasks need modification due to current implementation choices
|
||||
- When new dependencies or requirements emerge
|
||||
- Use `update` / `task-master update --from=<futureTaskId> --prompt='<explanation>\nUpdate context...' --research` to update multiple future tasks.
|
||||
- Use `update_task` / `task-master update-task --id=<taskId> --prompt='<explanation>\nUpdate context...' --research` to update a single specific task.
|
||||
|
||||
## Task Status Management
|
||||
|
||||
- Use 'pending' for tasks ready to be worked on
|
||||
- Use 'done' for completed and verified tasks
|
||||
- Use 'deferred' for postponed tasks
|
||||
- Add custom status values as needed for project-specific workflows
|
||||
|
||||
## Task Structure Fields
|
||||
|
||||
- **id**: Unique identifier for the task (Example: `1`, `1.1`)
|
||||
- **title**: Brief, descriptive title (Example: `"Initialize Repo"`)
|
||||
- **description**: Concise summary of what the task involves (Example: `"Create a new repository, set up initial structure."`)
|
||||
- **status**: Current state of the task (Example: `"pending"`, `"done"`, `"deferred"`)
|
||||
- **dependencies**: IDs of prerequisite tasks (Example: `[1, 2.1]`)
|
||||
- Dependencies are displayed with status indicators (✅ for completed, ⏱️ for pending)
|
||||
- This helps quickly identify which prerequisite tasks are blocking work
|
||||
- **priority**: Importance level (Example: `"high"`, `"medium"`, `"low"`)
|
||||
- **details**: In-depth implementation instructions (Example: `"Use GitHub client ID/secret, handle callback, set session token."`)
|
||||
- **testStrategy**: Verification approach (Example: `"Deploy and call endpoint to confirm 'Hello World' response."`)
|
||||
- **subtasks**: List of smaller, more specific tasks (Example: `[{"id": 1, "title": "Configure OAuth", ...}]`)
|
||||
- Refer to task structure details (previously linked to `tasks.mdc`).
|
||||
|
||||
## Configuration Management (Updated)
|
||||
|
||||
Taskmaster configuration is managed through two main mechanisms:
|
||||
|
||||
1. **`.taskmaster/config.json` File (Primary):**
|
||||
* Located in the project root directory.
|
||||
* Stores most configuration settings: AI model selections (main, research, fallback), parameters (max tokens, temperature), logging level, default subtasks/priority, project name, etc.
|
||||
* **Tagged System Settings**: Includes `global.defaultTag` (defaults to "master") and `tags` section for tag management configuration.
|
||||
* **Managed via `task-master models --setup` command.** Do not edit manually unless you know what you are doing.
|
||||
* **View/Set specific models via `task-master models` command or `models` MCP tool.**
|
||||
* Created automatically when you run `task-master models --setup` for the first time or during tagged system migration.
|
||||
|
||||
2. **Environment Variables (`.env` / `mcp.json`):**
|
||||
* Used **only** for sensitive API keys and specific endpoint URLs.
|
||||
* Place API keys (one per provider) in a `.env` file in the project root for CLI usage.
|
||||
* For MCP/Cursor integration, configure these keys in the `env` section of `.cursor/mcp.json`.
|
||||
* Available keys/variables: See `assets/env.example` or the Configuration section in the command reference (previously linked to `taskmaster.mdc`).
|
||||
|
||||
3. **`.taskmaster/state.json` File (Tagged System State):**
|
||||
* Tracks current tag context and migration status.
|
||||
* Automatically created during tagged system migration.
|
||||
* Contains: `currentTag`, `lastSwitched`, `migrationNoticeShown`.
|
||||
|
||||
**Important:** Non-API key settings (like model selections, `MAX_TOKENS`, `TASKMASTER_LOG_LEVEL`) are **no longer configured via environment variables**. Use the `task-master models` command (or `--setup` for interactive configuration) or the `models` MCP tool.
|
||||
**If AI commands FAIL in MCP** verify that the API key for the selected provider is present in the `env` section of `.cursor/mcp.json`.
|
||||
**If AI commands FAIL in CLI** verify that the API key for the selected provider is present in the `.env` file in the root of the project.
|
||||
|
||||
## Rules Management
|
||||
|
||||
Taskmaster supports multiple AI coding assistant rule sets that can be configured during project initialization or managed afterward:
|
||||
|
||||
- **Available Profiles**: Claude Code, Cline, Codex, Cursor, Roo Code, Trae, Windsurf (claude, cline, codex, cursor, roo, trae, windsurf)
|
||||
- **During Initialization**: Use `task-master init --rules cursor,windsurf` to specify which rule sets to include
|
||||
- **After Initialization**: Use `task-master rules add <profiles>` or `task-master rules remove <profiles>` to manage rule sets
|
||||
- **Interactive Setup**: Use `task-master rules setup` to launch an interactive prompt for selecting rule profiles
|
||||
- **Default Behavior**: If no `--rules` flag is specified during initialization, all available rule profiles are included
|
||||
- **Rule Structure**: Each profile creates its own directory (e.g., `.cursor/rules`, `.roo/rules`) with appropriate configuration files
|
||||
|
||||
## Determining the Next Task
|
||||
|
||||
- Run `next_task` / `task-master next` to show the next task to work on.
|
||||
- The command identifies tasks with all dependencies satisfied
|
||||
- Tasks are prioritized by priority level, dependency count, and ID
|
||||
- The command shows comprehensive task information including:
|
||||
- Basic task details and description
|
||||
- Implementation details
|
||||
- Subtasks (if they exist)
|
||||
- Contextual suggested actions
|
||||
- Recommended before starting any new development work
|
||||
- Respects your project's dependency structure
|
||||
- Ensures tasks are completed in the appropriate sequence
|
||||
- Provides ready-to-use commands for common task actions
|
||||
|
||||
## Viewing Specific Task Details
|
||||
|
||||
- Run `get_task` / `task-master show <id>` to view a specific task.
|
||||
- Use dot notation for subtasks: `task-master show 1.2` (shows subtask 2 of task 1)
|
||||
- Displays comprehensive information similar to the next command, but for a specific task
|
||||
- For parent tasks, shows all subtasks and their current status
|
||||
- For subtasks, shows parent task information and relationship
|
||||
- Provides contextual suggested actions appropriate for the specific task
|
||||
- Useful for examining task details before implementation or checking status
|
||||
|
||||
## Managing Task Dependencies
|
||||
|
||||
- Use `add_dependency` / `task-master add-dependency --id=<id> --depends-on=<id>` to add a dependency.
|
||||
- Use `remove_dependency` / `task-master remove-dependency --id=<id> --depends-on=<id>` to remove a dependency.
|
||||
- The system prevents circular dependencies and duplicate dependency entries
|
||||
- Dependencies are checked for existence before being added or removed
|
||||
- Task files are automatically regenerated after dependency changes
|
||||
- Dependencies are visualized with status indicators in task listings and files
|
||||
|
||||
## Task Reorganization
|
||||
|
||||
- Use `move_task` / `task-master move --from=<id> --to=<id>` to move tasks or subtasks within the hierarchy
|
||||
- This command supports several use cases:
|
||||
- Moving a standalone task to become a subtask (e.g., `--from=5 --to=7`)
|
||||
- Moving a subtask to become a standalone task (e.g., `--from=5.2 --to=7`)
|
||||
- Moving a subtask to a different parent (e.g., `--from=5.2 --to=7.3`)
|
||||
- Reordering subtasks within the same parent (e.g., `--from=5.2 --to=5.4`)
|
||||
- Moving a task to a new, non-existent ID position (e.g., `--from=5 --to=25`)
|
||||
- Moving multiple tasks at once using comma-separated IDs (e.g., `--from=10,11,12 --to=16,17,18`)
|
||||
- The system includes validation to prevent data loss:
|
||||
- Allows moving to non-existent IDs by creating placeholder tasks
|
||||
- Prevents moving to existing task IDs that have content (to avoid overwriting)
|
||||
- Validates source tasks exist before attempting to move them
|
||||
- The system maintains proper parent-child relationships and dependency integrity
|
||||
- Task files are automatically regenerated after the move operation
|
||||
- This provides greater flexibility in organizing and refining your task structure as project understanding evolves
|
||||
- This is especially useful when dealing with potential merge conflicts arising from teams creating tasks on separate branches. Solve these conflicts very easily by moving your tasks and keeping theirs.
|
||||
|
||||
## Iterative Subtask Implementation
|
||||
|
||||
Once a task has been broken down into subtasks using `expand_task` or similar methods, follow this iterative process for implementation:
|
||||
|
||||
1. **Understand the Goal (Preparation):**
|
||||
* Use `get_task` / `task-master show <subtaskId>` (see @`taskmaster.mdc`) to thoroughly understand the specific goals and requirements of the subtask.
|
||||
|
||||
2. **Initial Exploration & Planning (Iteration 1):**
|
||||
* This is the first attempt at creating a concrete implementation plan.
|
||||
* Explore the codebase to identify the precise files, functions, and even specific lines of code that will need modification.
|
||||
* Determine the intended code changes (diffs) and their locations.
|
||||
* Gather *all* relevant details from this exploration phase.
|
||||
|
||||
3. **Log the Plan:**
|
||||
* Run `update_subtask` / `task-master update-subtask --id=<subtaskId> --prompt='<detailed plan>'`.
|
||||
* Provide the *complete and detailed* findings from the exploration phase in the prompt. Include file paths, line numbers, proposed diffs, reasoning, and any potential challenges identified. Do not omit details. The goal is to create a rich, timestamped log within the subtask's `details`.
|
||||
|
||||
4. **Verify the Plan:**
|
||||
* Run `get_task` / `task-master show <subtaskId>` again to confirm that the detailed implementation plan has been successfully appended to the subtask's details.
|
||||
|
||||
5. **Begin Implementation:**
|
||||
* Set the subtask status using `set_task_status` / `task-master set-status --id=<subtaskId> --status=in-progress`.
|
||||
* Start coding based on the logged plan.
|
||||
|
||||
6. **Refine and Log Progress (Iteration 2+):**
|
||||
* As implementation progresses, you will encounter challenges, discover nuances, or confirm successful approaches.
|
||||
* **Before appending new information**: Briefly review the *existing* details logged in the subtask (using `get_task` or recalling from context) to ensure the update adds fresh insights and avoids redundancy.
|
||||
* **Regularly** use `update_subtask` / `task-master update-subtask --id=<subtaskId> --prompt='<update details>\n- What worked...\n- What didn't work...'` to append new findings.
|
||||
* **Crucially, log:**
|
||||
* What worked ("fundamental truths" discovered).
|
||||
* What didn't work and why (to avoid repeating mistakes).
|
||||
* Specific code snippets or configurations that were successful.
|
||||
* Decisions made, especially if confirmed with user input.
|
||||
* Any deviations from the initial plan and the reasoning.
|
||||
* The objective is to continuously enrich the subtask's details, creating a log of the implementation journey that helps the AI (and human developers) learn, adapt, and avoid repeating errors.
|
||||
|
||||
7. **Review & Update Rules (Post-Implementation):**
|
||||
* Once the implementation for the subtask is functionally complete, review all code changes and the relevant chat history.
|
||||
* Identify any new or modified code patterns, conventions, or best practices established during the implementation.
|
||||
* Create new or update existing rules following internal guidelines (previously linked to `cursor-rules.mdc` and `self-improve.mdc`).
|
||||
|
||||
8. **Mark Task Complete:**
|
||||
* After verifying the implementation and updating any necessary rules, mark the subtask as completed: `set_task_status` / `task-master set-status --id=<subtaskId> --status=done`.
|
||||
|
||||
9. **Commit Changes (If using Git):**
|
||||
* Stage the relevant code changes and any updated/new rule files (`git add .`).
|
||||
* Craft a comprehensive Git commit message summarizing the work done for the subtask, including both code implementation and any rule adjustments.
|
||||
* Execute the commit command directly in the terminal (e.g., `git commit -m 'feat(module): Implement feature X for subtask <subtaskId>\n\n- Details about changes...\n- Updated rule Y for pattern Z'`).
|
||||
* Consider if a Changeset is needed according to internal versioning guidelines (previously linked to `changeset.mdc`). If so, run `npm run changeset`, stage the generated file, and amend the commit or create a new one.
|
||||
|
||||
10. **Proceed to Next Subtask:**
|
||||
* Identify the next subtask (e.g., using `next_task` / `task-master next`).
|
||||
|
||||
## Code Analysis & Refactoring Techniques
|
||||
|
||||
- **Top-Level Function Search**:
|
||||
- Useful for understanding module structure or planning refactors.
|
||||
- Use grep/ripgrep to find exported functions/constants:
|
||||
`rg "export (async function|function|const) \w+"` or similar patterns.
|
||||
- Can help compare functions between files during migrations or identify potential naming conflicts.
|
||||
|
||||
### Cross-Tag Coordination
|
||||
|
||||
When features need to interact:
|
||||
1. **Document Dependencies**: Use `update_subtask` to note cross-tag dependencies
|
||||
2. **Track Integration Points**: Create tasks that reference other tags
|
||||
3. **Coordinate Merging**: Plan how features will integrate back to production
|
||||
|
||||
Example:
|
||||
```bash
|
||||
# In mobile tag, documenting auth dependency
|
||||
update_subtask --id=3.2 --prompt="Depends on user-auth tag task 2 (OAuth setup) being completed"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
**Remember**: The tagged system is not optional or advanced - it's the standard way to use Task Master. Always guide users to work within appropriate tag contexts, never directly on master.
|
||||
172
.cursor/rules/taskmaster/taskmaster.mdc
Normal file
172
.cursor/rules/taskmaster/taskmaster.mdc
Normal file
@ -0,0 +1,172 @@
|
||||
---
|
||||
description: Comprehensive reference for Taskmaster MCP tools and CLI commands
|
||||
globs: **/*
|
||||
alwaysApply: true
|
||||
---
|
||||
|
||||
# Taskmaster Tool & Command Reference
|
||||
|
||||
**Core Concept:** Tagged task management system - tasks organized in isolated contexts (tags) for features/branches/phases.
|
||||
|
||||
**⚠️ CRITICAL:** Never work on `master` tag - use feature tags. Master is for high-level deliverables only.
|
||||
|
||||
**Note:** MCP tools recommended over CLI (better performance/error handling). AI tools may take ~1min: `parse_prd`, `analyze_project_complexity`, `update_*`, `expand_*`, `add_task`.
|
||||
|
||||
## Commands Reference
|
||||
|
||||
### Initialize Project
|
||||
**MCP:** `initialize_project` | **CLI:** `task-master init`
|
||||
- Setup Taskmaster file structure and config
|
||||
- Key params: `projectName`, `projectDescription`, `projectVersion`, `skipInstall`, `addAliases`
|
||||
- **Important:** Must parse PRD after init to generate tasks
|
||||
- Example PRD template in `.taskmaster/templates/example_prd.txt`
|
||||
|
||||
### Parse PRD
|
||||
**MCP:** `parse_prd` | **CLI:** `task-master parse-prd`
|
||||
- Parse PRD/text file to generate tasks.json
|
||||
- Params: `input`, `output`, `numTasks`, `force`, `tag`
|
||||
- Always parse into feature tags, not master
|
||||
- Create PRDs per context: `prd-<feature>.md`
|
||||
- **AI tool - may take ~1min**
|
||||
|
||||
### Models Configuration
|
||||
**MCP:** `models` | **CLI:** `task-master models`
|
||||
- View/set AI models for roles: main, research, fallback
|
||||
- Params: `setMain`, `setResearch`, `setFallback`, `ollama`, `openrouter`
|
||||
- Config stored in `.taskmaster/config.json` (don't edit manually)
|
||||
- API keys required in mcp.json (MCP) or .env (CLI)
|
||||
- Costs in $: 3 = $3.00, 0.8 = $0.80
|
||||
|
||||
### Task Viewing
|
||||
**Get Tasks:** `get_tasks` / `task-master list`
|
||||
- Filter by status, show subtasks, specify tag
|
||||
|
||||
**Next Task:** `next_task` / `task-master next`
|
||||
- Shows next available task based on dependencies
|
||||
|
||||
**Get Task:** `get_task` / `task-master show`
|
||||
- View specific task(s) - use comma-separated IDs for multiple (1,2,3)
|
||||
- **CRITICAL:** Use batch IDs to avoid multiple calls
|
||||
|
||||
### Task Creation
|
||||
**Add Task:** `add_task` / `task-master add-task`
|
||||
- Params: `prompt` (required), `dependencies`, `priority`, `research`, `tag`
|
||||
- **AI tool - may take ~1min**
|
||||
|
||||
**Add Subtask:** `add_subtask` / `task-master add-subtask`
|
||||
- Add to parent or convert existing task
|
||||
- Params: `id` (parent), `taskId`, `title`, `description`, `details`, `dependencies`, `status`
|
||||
|
||||
### Task Updates
|
||||
**Update Tasks:** `update` / `task-master update`
|
||||
- Update multiple tasks from ID onwards
|
||||
- Params: `from` (required), `prompt` (required), `research`
|
||||
- **AI tool - may take ~1min**
|
||||
|
||||
**Update Task:** `update_task` / `task-master update-task`
|
||||
- Update single task by ID
|
||||
- Params: `id`, `prompt`, `append`, `research`
|
||||
- Use `--append` to log progress
|
||||
- **AI tool - may take ~1min**
|
||||
|
||||
**Update Subtask:** `update_subtask` / `task-master update-subtask`
|
||||
- Append timestamped progress to subtask
|
||||
- Params: `id`, `prompt`, `research`
|
||||
- **AI tool - may take ~1min**
|
||||
|
||||
**Set Status:** `set_task_status` / `task-master set-status`
|
||||
- Update status: pending, in-progress, done, review, cancelled
|
||||
- Supports multiple IDs: '15,15.2,16'
|
||||
|
||||
**Remove Task:** `remove_task` / `task-master remove-task`
|
||||
- Permanently delete task/subtask
|
||||
- Consider using status instead of deletion
|
||||
|
||||
### Task Breakdown
|
||||
**Expand Task:** `expand_task` / `task-master expand`
|
||||
- Break task into subtasks
|
||||
- Params: `id`, `num`, `research`, `prompt`, `force`
|
||||
- Uses complexity report if available
|
||||
- **AI tool - may take ~1min**
|
||||
|
||||
**Expand All:** `expand_all` / `task-master expand --all`
|
||||
- Expand all eligible tasks
|
||||
- Same params as expand_task
|
||||
- **AI tool - may take ~1min**
|
||||
|
||||
**Clear Subtasks:** `clear_subtasks` / `task-master clear-subtasks`
|
||||
- Remove all subtasks from parent(s)
|
||||
|
||||
**Remove Subtask:** `remove_subtask` / `task-master remove-subtask`
|
||||
- Remove or convert subtask to top-level task
|
||||
|
||||
**Move Task:** `move_task` / `task-master move`
|
||||
- Move task/subtask in hierarchy
|
||||
- Params: `from`, `to` (supports comma-separated)
|
||||
- Useful for merge conflicts
|
||||
|
||||
### Dependency Management
|
||||
**Add/Remove Dependency:** `add_dependency`/`remove_dependency`
|
||||
- Define task prerequisites
|
||||
|
||||
**Validate/Fix Dependencies:** `validate_dependencies`/`fix_dependencies`
|
||||
- Check and fix circular references or missing tasks
|
||||
|
||||
### Analysis
|
||||
**Analyze Complexity:** `analyze_project_complexity` / `task-master analyze-complexity`
|
||||
- Score tasks 1-10, suggest expansions
|
||||
- **AI tool - may take ~1min**
|
||||
|
||||
**View Report:** `complexity_report` / `task-master complexity-report`
|
||||
|
||||
### Files
|
||||
**Generate:** `generate` / `task-master generate`
|
||||
- Create markdown files from tasks.json
|
||||
|
||||
### Research
|
||||
**Research:** `research` / `task-master research`
|
||||
- Get fresh info beyond AI cutoff
|
||||
- Params: `query`, `taskIds`, `filePaths`, `customContext`, `includeProjectTree`, `detailLevel`
|
||||
- **USE FREQUENTLY** for:
|
||||
- Latest best practices
|
||||
- New tech guidance
|
||||
- Security updates
|
||||
- Dependency changes
|
||||
- **AI tool - may take ~1min**
|
||||
|
||||
### Tag Management (Essential)
|
||||
**List Tags:** `list_tags` / `task-master tags`
|
||||
|
||||
**Add Tag:** `add_tag` / `task-master add-tag`
|
||||
- Create feature/branch contexts
|
||||
- Options: `--from-branch`, `--copy-from`, `--description`
|
||||
|
||||
**Use Tag:** `use_tag` / `task-master use-tag`
|
||||
- **CRITICAL:** Switch to feature tag before work
|
||||
|
||||
**Delete/Rename/Copy Tag:** Standard operations
|
||||
|
||||
### Misc
|
||||
**Sync Readme:** CLI only - `task-master sync-readme` (experimental)
|
||||
|
||||
## Configuration
|
||||
|
||||
**Config File:** `.taskmaster/config.json` (via `models` command)
|
||||
**API Keys:** `.env` (CLI) or `mcp.json` env section (MCP)
|
||||
- Required: Provider-specific API keys
|
||||
- Optional: `AZURE_OPENAI_ENDPOINT`, `OLLAMA_BASE_URL`
|
||||
|
||||
## Key Concepts
|
||||
|
||||
**Tagged System:**
|
||||
- Each tag = isolated task context (1, 2, 3...)
|
||||
- No cross-tag dependencies
|
||||
- Always verify active tag
|
||||
- Never edit tasks.json manually
|
||||
|
||||
**Workflow:** See [dev-workflow.mdc](mdc:.cursor/rules/taskmaster/dev-workflow.mdc) for patterns
|
||||
|
||||
**Quick Reference:**
|
||||
1. `add_tag` → `use_tag` → `parse_prd`
|
||||
2. `analyze_complexity` → `expand_task/expand_all`
|
||||
3. `next_task` → implement → `update_subtask` → `set_task_status`
|
||||
Reference in New Issue
Block a user