feat: Add intelligent auto-router and enhanced integrations
- Add intelligent-router.sh hook for automatic agent routing - Add AUTO-TRIGGER-SUMMARY.md documentation - Add FINAL-INTEGRATION-SUMMARY.md documentation - Complete Prometheus integration (6 commands + 4 tools) - Complete Dexto integration (12 commands + 5 tools) - Enhanced Ralph with access to all agents - Fix /clawd command (removed disable-model-invocation) - Update hooks.json to v5 with intelligent routing - 291 total skills now available - All 21 commands with automatic routing 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
admin
319
dexto/commands/README.md
Normal file
319
dexto/commands/README.md
Normal file
@@ -0,0 +1,319 @@
|
||||
# Dexto Commands (File Prompts)
|
||||
|
||||
This directory contains File Prompts — reusable prompt templates that work like Claude Code's custom slash commands.
|
||||
|
||||
## Prompt Types in Dexto
|
||||
|
||||
Dexto supports four types of prompts, each with different capabilities:
|
||||
|
||||
### 1. 📁 File Prompts (Commands)
|
||||
Location:
|
||||
- Local: `commands/`
|
||||
- Global: `~/.dexto/commands`
|
||||
Format: Markdown files with frontmatter
|
||||
Arguments: Positional placeholders (`$1`, `$2`, `$ARGUMENTS`)
|
||||
Best for: Simple, file-based prompts you can version control
|
||||
|
||||
### 2. 🔌 MCP Prompts
|
||||
Source: Connected MCP servers
|
||||
Format: Defined by MCP protocol
|
||||
Arguments: Named arguments (e.g., `report_type: "metrics"`)
|
||||
Best for: Complex prompts from external services (GitHub, databases, etc.)
|
||||
|
||||
### 3. ⚡ Starter Prompts
|
||||
Source: Built into Dexto
|
||||
Format: Hardcoded in code
|
||||
Arguments: Varies by prompt
|
||||
Best for: Common operations provided out-of-the-box
|
||||
|
||||
### 4. ✨ Custom Prompts
|
||||
Source: Created at runtime via API/UI
|
||||
Format: Stored in database
|
||||
Arguments: Positional placeholders like File Prompts
|
||||
Best for: User-created prompts that need persistence
|
||||
|
||||
---
|
||||
|
||||
**Custom Commands (Create, Use, Manage)**
|
||||
|
||||
Custom commands are prompts you create at runtime. They live in the local database (not on disk) and are available to the active agent across sessions. They support the same placeholder behavior as file prompts:
|
||||
|
||||
- `$1..$9` and `$ARGUMENTS` positional placeholders
|
||||
- `$$` escapes a literal dollar
|
||||
- `{{name}}` named placeholders (when you declare `arguments`)
|
||||
- If no placeholders are used in the template: arguments/context are appended at the end
|
||||
|
||||
Create via Web UI
|
||||
- Open the “Create Custom Prompt” modal in the web UI
|
||||
- Provide `name`, optional `title`/`description`, and the prompt `content`
|
||||
- Use `$1..$9`/`$ARGUMENTS`/`{{name}}` placeholders in `content`
|
||||
- Optionally attach a resource file; it will be stored and included when the prompt runs
|
||||
|
||||
Create via API
|
||||
- POST `POST /api/prompts/custom` with JSON:
|
||||
```
|
||||
{
|
||||
"name": "research-summary",
|
||||
"title": "Research Summary",
|
||||
"description": "Summarize research papers with key findings",
|
||||
"content": "Summarize in style $1 with length $2.\n\nContent:\n$ARGUMENTS",
|
||||
"arguments": [
|
||||
{ "name": "style", "required": true },
|
||||
{ "name": "length", "required": true }
|
||||
],
|
||||
"resource": {
|
||||
"base64": "data:application/pdf;base64,...",
|
||||
"mimeType": "application/pdf",
|
||||
"filename": "paper.pdf"
|
||||
}
|
||||
}
|
||||
```
|
||||
- Declaring `arguments` is optional but recommended; it enables inline argument hints in the slash UI and required-arg validation.
|
||||
- The `resource` field is optional; attached data is stored in the blob store and sent alongside the prompt when executed.
|
||||
|
||||
Delete via API
|
||||
- `DELETE /api/prompts/custom/:name`
|
||||
|
||||
Preview resolution (without sending to LLM)
|
||||
- `GET /api/prompts/:name/resolve?context=...&args={...}`
|
||||
- `context` becomes `_context` for positional flows
|
||||
- `args` is a JSON string for structured argument values
|
||||
|
||||
Argument Handling Summary
|
||||
- Positional tokens typed after `/name` appear in `args._positional` and are expanded into `$1..$9` and `$ARGUMENTS`.
|
||||
- Named args can be declared in `arguments` and referenced as `{{name}}`.
|
||||
- If the template contains any placeholders ($1..$9, $ARGUMENTS, or {{name}}), arguments are considered deconstructed and are NOT appended.
|
||||
- If the template contains no placeholders, providers append at the end:
|
||||
- `Context: <_context>` if provided, otherwise
|
||||
- `Arguments: key: value, ...`
|
||||
|
||||
---
|
||||
|
||||
## Creating File Prompts
|
||||
|
||||
### Basic Structure
|
||||
|
||||
Create a `.md` file in this directory with frontmatter:
|
||||
|
||||
```markdown
|
||||
---
|
||||
description: Short description of what this prompt does
|
||||
argument-hint: [required-arg] [optional-arg?]
|
||||
---
|
||||
|
||||
# Prompt Title
|
||||
|
||||
Your prompt content here using $1, $2, or $ARGUMENTS placeholders.
|
||||
```
|
||||
|
||||
### Frontmatter Fields
|
||||
|
||||
| Field | Required | Description | Example |
|
||||
|-------|----------|-------------|---------|
|
||||
| `description` | ✅ Yes | Brief description shown in UI | `"Summarize text with style and length"` |
|
||||
| `argument-hint` | ⚠️ Recommended | Argument names for UI hints | `"[style] [length]"` |
|
||||
| `name` | ❌ Optional | Override filename as command name | `"quick-summary"` |
|
||||
| `category` | ❌ Optional | Group prompts by category | `"text-processing"` |
|
||||
| `id` | ❌ Optional | Unique identifier | `"summarize-v2"` |
|
||||
|
||||
### Argument Placeholders
|
||||
|
||||
File prompts support Claude Code's positional argument system:
|
||||
|
||||
| Placeholder | Expands To | Use Case |
|
||||
|-------------|------------|----------|
|
||||
| `$1`, `$2`, ..., `$9` | Individual arguments by position | Structured parameters |
|
||||
| `$ARGUMENTS` | Remaining arguments after `$1..$9` | Free-form text content |
|
||||
| `$$` | Literal dollar sign | When you need `$` in output |
|
||||
|
||||
### Examples
|
||||
|
||||
#### Example 1: Structured Arguments Only
|
||||
|
||||
```markdown
|
||||
---
|
||||
description: Translate text between languages
|
||||
argument-hint: [from-lang] [to-lang] [text]
|
||||
---
|
||||
|
||||
Translate from $1 to $2:
|
||||
|
||||
$3
|
||||
```
|
||||
|
||||
Usage: `/translate english spanish "Hello world"`
|
||||
Expands to:
|
||||
```
|
||||
Translate from english to spanish:
|
||||
|
||||
Hello world
|
||||
```
|
||||
|
||||
#### Example 2: Mixed Structured + Free-form
|
||||
|
||||
```markdown
|
||||
---
|
||||
description: Analyze code with focus area
|
||||
argument-hint: [file] [focus]
|
||||
---
|
||||
|
||||
Analyze the code in **$1** focusing on: $2
|
||||
|
||||
Full input for context:
|
||||
$ARGUMENTS
|
||||
```
|
||||
|
||||
Usage: `/analyze utils.ts performance "function slow() { ... }"`
|
||||
Expands to:
|
||||
```
|
||||
Analyze the code in **utils.ts** focusing on: performance
|
||||
|
||||
Full input for context:
|
||||
utils.ts performance function slow() { ... }
|
||||
```
|
||||
|
||||
#### Example 3: Free-form Only
|
||||
|
||||
```markdown
|
||||
---
|
||||
description: Improve any text
|
||||
argument-hint: [text-to-improve]
|
||||
---
|
||||
|
||||
Please improve the following text:
|
||||
|
||||
$ARGUMENTS
|
||||
```
|
||||
|
||||
Usage: `/improve "This sentence not good"`
|
||||
Expands to:
|
||||
```
|
||||
Please improve the following text:
|
||||
|
||||
This sentence not good
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Usage in the UI
|
||||
|
||||
### Invoking File Prompts
|
||||
|
||||
1. Type `/` in chat — opens slash command autocomplete
|
||||
2. Select your prompt — shows inline argument hints
|
||||
3. Provide arguments — positional order matters!
|
||||
|
||||
### Argument Display
|
||||
|
||||
The UI shows:
|
||||
- `<argname>` — Required argument
|
||||
- `<argname?>` — Optional argument
|
||||
- Hover tooltip — Argument description (if provided)
|
||||
|
||||
Example UI display for summarize:
|
||||
```
|
||||
/summarize <style> <length>
|
||||
^required ^required
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## How Different Prompt Types Handle Arguments
|
||||
|
||||
### File Prompts vs MCP Prompts
|
||||
|
||||
File Prompts (like `summarize`):
|
||||
```
|
||||
User types: /summarize technical 100 "Machine learning..."
|
||||
↓
|
||||
Expands: $1="technical", $2="100", $ARGUMENTS="technical 100 Machine learning..."
|
||||
↓
|
||||
Result: Prompt text with placeholders replaced
|
||||
```
|
||||
|
||||
MCP Prompts (like `generate-report`):
|
||||
```
|
||||
User types: /generate-report metrics
|
||||
↓
|
||||
Maps: _positional=["metrics"] → report_type="metrics"
|
||||
↓
|
||||
Result: MCP server receives {report_type: "metrics"}
|
||||
```
|
||||
|
||||
Key difference:
|
||||
- File prompts: Simple string replacement in markdown
|
||||
- MCP prompts: Structured data passed to external servers
|
||||
|
||||
---
|
||||
|
||||
## Best Practices
|
||||
|
||||
### ✅ DO:
|
||||
|
||||
- Use descriptive names — `analyze-performance` not `analyze`
|
||||
- Add clear descriptions — help users understand what it does
|
||||
- Include usage examples — in the prompt content or description
|
||||
- Use `argument-hint` — enables inline UI hints
|
||||
- Keep it focused — one clear purpose per prompt
|
||||
- Use `$1`, `$2` for structure — when you need specific parameters
|
||||
- Use `$ARGUMENTS` for flexibility — when content is variable
|
||||
|
||||
### ❌ DON'T:
|
||||
|
||||
- Don't use spaces in filenames — use kebab-case: `my-prompt.md`
|
||||
- Don't create overly complex prompts — split into multiple files
|
||||
- Don't forget argument-hint — users need to know what to provide
|
||||
- Don't rely on order if flexible — document expected argument positions
|
||||
|
||||
---
|
||||
|
||||
## Testing Your Prompts
|
||||
|
||||
1. Create the `.md` file in this directory
|
||||
2. Restart the agent (or wait for hot reload)
|
||||
3. Type `/your-prompt-name` in chat
|
||||
4. Test with different arguments — verify placeholders expand correctly
|
||||
|
||||
---
|
||||
|
||||
## Advanced: Argument-Hint Parsing
|
||||
|
||||
The `argument-hint` field is parsed to create structured argument definitions:
|
||||
|
||||
```markdown
|
||||
argument-hint: [style] [length?] [extra-param]
|
||||
```
|
||||
|
||||
Becomes:
|
||||
```json
|
||||
[
|
||||
{ "name": "style", "required": true },
|
||||
{ "name": "length", "required": false },
|
||||
{ "name": "extra-param", "required": true }
|
||||
]
|
||||
```
|
||||
|
||||
Rules:
|
||||
- `[name]` = required argument
|
||||
- `[name?]` = optional argument (with `?`)
|
||||
- Order matters — matches positional `$1`, `$2` positions
|
||||
|
||||
---
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Prompt doesn't appear in slash command list
|
||||
|
||||
- Check filename ends with `.md`
|
||||
- Verify frontmatter is valid YAML
|
||||
- Ensure description field is present
|
||||
- Put your file in `commands/` (local) or `~/.dexto/commands` (global)
|
||||
- Restart the agent
|
||||
|
||||
---
|
||||
|
||||
## Further Reading
|
||||
|
||||
- Prompt Manager Architecture: `packages/core/src/prompts/prompt-manager.ts`
|
||||
- File Prompt Provider: `packages/core/src/prompts/providers/file-prompt-provider.ts`
|
||||
- Placeholder Expansion: `packages/core/src/prompts/utils.ts` (expandPlaceholders function)
|
||||
103
dexto/commands/code-review.md
Normal file
103
dexto/commands/code-review.md
Normal file
@@ -0,0 +1,103 @@
|
||||
---
|
||||
description: "Review code for bugs, improvements, and best practices with actionable feedback"
|
||||
id: code-review
|
||||
name: code-review
|
||||
category: coding
|
||||
---
|
||||
|
||||
<!-- TODO: (355) Move all prompts off absolute path and into relative agent specific paths, referenced using @dexto.agent_dir colocated near their folders. This allows us to keep agent specific prompts -->
|
||||
<!-- https://github.com/truffle-ai/dexto/pull/355#discussion_r2413003414 -->
|
||||
# Code Review Assistant
|
||||
|
||||
I'm here to help you review code for bugs, improvements, and best practices. I'll analyze your code and provide actionable feedback with specific suggestions for improvement.
|
||||
|
||||
## How I Work
|
||||
|
||||
When you share code with me, I'll:
|
||||
|
||||
1. **Analyze the code structure** and identify potential issues
|
||||
2. **Check for common bugs** and edge cases
|
||||
3. **Suggest performance improvements** and optimizations
|
||||
4. **Review code style** and adherence to best practices
|
||||
5. **Provide specific, actionable feedback** with examples
|
||||
6. **Consider the context** and purpose of your code
|
||||
|
||||
## Natural Language Examples
|
||||
|
||||
```bash
|
||||
# Use natural language - I'll understand what you want!
|
||||
/code-review function calculateTotal(items) { return items.reduce((sum, item) => sum + item.price, 0); }
|
||||
/code-review this React component for accessibility issues
|
||||
/code-review my Python function for error handling
|
||||
/code-review this SQL query for performance
|
||||
/code-review my API endpoint for security vulnerabilities
|
||||
```
|
||||
|
||||
## What I'll Review
|
||||
|
||||
I analyze code for:
|
||||
|
||||
- **Bugs & Logic Errors**: Incorrect calculations, edge cases, null handling
|
||||
- **Performance Issues**: Inefficient algorithms, memory leaks, unnecessary operations
|
||||
- **Security Vulnerabilities**: SQL injection, XSS, input validation
|
||||
- **Code Quality**: Readability, maintainability, naming conventions
|
||||
- **Best Practices**: Design patterns, error handling, testing considerations
|
||||
- **Accessibility**: For web applications and user interfaces
|
||||
|
||||
## Code Review Process
|
||||
|
||||
1. **Initial Scan**: Quick overview of structure and purpose
|
||||
2. **Detailed Analysis**: Line-by-line review for specific issues
|
||||
3. **Pattern Recognition**: Identify common anti-patterns and improvements
|
||||
4. **Alternative Solutions**: Suggest better approaches when applicable
|
||||
5. **Prioritization**: Rank issues by severity and impact
|
||||
|
||||
## Response Format
|
||||
|
||||
I'll structure my review as:
|
||||
|
||||
1. **Summary** - High-level assessment and key findings
|
||||
2. **Critical Issues** - Bugs, security problems, major performance issues
|
||||
3. **Improvements** - Code quality, readability, and maintainability
|
||||
4. **Suggestions** - Alternative approaches and best practices
|
||||
5. **Questions** - Clarifications needed to provide better feedback
|
||||
6. **Overall Rating** - Code quality score with justification
|
||||
|
||||
## Tips for Better Reviews
|
||||
|
||||
- **Provide context**: What is this code supposed to do?
|
||||
- **Include requirements**: Any specific constraints or performance needs?
|
||||
- **Mention the language/framework**: So I can give language-specific advice
|
||||
- **Share related code**: Dependencies, interfaces, or surrounding context
|
||||
- **Ask specific questions**: "Focus on security" or "Check for memory leaks"
|
||||
|
||||
## Language-Specific Expertise
|
||||
|
||||
I can review code in:
|
||||
- **JavaScript/TypeScript**: Frontend, Node.js, React, Vue, Angular
|
||||
- **Python**: Web apps, data science, automation, APIs
|
||||
- **Java/C#**: Enterprise applications, Android, .NET
|
||||
- **Go/Rust**: Systems programming, performance-critical code
|
||||
- **SQL**: Database queries, performance, security
|
||||
- **HTML/CSS**: Accessibility, responsive design, best practices
|
||||
|
||||
## Security Focus Areas
|
||||
|
||||
When reviewing for security, I check:
|
||||
- **Input Validation**: Sanitization, type checking, bounds checking
|
||||
- **Authentication**: Session management, password handling
|
||||
- **Authorization**: Access control, permission checks
|
||||
- **Data Protection**: Encryption, secure storage, transmission
|
||||
- **Common Vulnerabilities**: OWASP Top 10, injection attacks
|
||||
|
||||
## Performance Focus Areas
|
||||
|
||||
When reviewing for performance, I examine:
|
||||
- **Algorithm Complexity**: Time and space complexity analysis
|
||||
- **Resource Usage**: Memory allocation, CPU utilization
|
||||
- **I/O Operations**: Database queries, file operations, network calls
|
||||
- **Caching**: Opportunities for memoization and result caching
|
||||
- **Optimization**: Unnecessary operations, redundant calculations
|
||||
|
||||
Now, share your code and I'll provide a comprehensive review! You can paste it directly or describe what you'd like me to focus on.
|
||||
|
||||
104
dexto/commands/debug.md
Normal file
104
dexto/commands/debug.md
Normal file
@@ -0,0 +1,104 @@
|
||||
---
|
||||
description: "Debug code issues with systematic problem-solving and troubleshooting steps"
|
||||
id: debug
|
||||
name: debug
|
||||
category: tools
|
||||
---
|
||||
|
||||
# Debug Assistant
|
||||
|
||||
I'm here to help you debug code issues systematically. I'll analyze problems, identify root causes, and guide you through the debugging process step by step.
|
||||
|
||||
## How I Work
|
||||
|
||||
When you share a bug or issue with me, I'll:
|
||||
|
||||
1. **Understand the problem** - What's happening vs. what should happen
|
||||
2. **Analyze the symptoms** - Error messages, unexpected behavior, performance issues
|
||||
3. **Investigate potential causes** - Logic errors, data issues, environment problems
|
||||
4. **Suggest debugging strategies** - Logging, testing, isolation techniques
|
||||
5. **Provide step-by-step solutions** - Specific fixes and verification steps
|
||||
6. **Help prevent future issues** - Best practices and defensive programming
|
||||
|
||||
## Natural Language Examples
|
||||
|
||||
```bash
|
||||
# Use natural language - I'll understand what you want!
|
||||
/debug my function returns undefined when it should return a number
|
||||
/debug this React component won't render
|
||||
/debug my API endpoint gives 500 errors
|
||||
/debug why my loop runs forever
|
||||
/debug my database query is slow
|
||||
```
|
||||
|
||||
## Common Debugging Scenarios
|
||||
|
||||
I can help with:
|
||||
|
||||
- **Runtime Errors**: Crashes, exceptions, error messages
|
||||
- **Logic Bugs**: Incorrect calculations, wrong outputs, unexpected behavior
|
||||
- **Performance Issues**: Slow execution, memory leaks, infinite loops
|
||||
- **Data Problems**: Incorrect values, null/undefined errors, type mismatches
|
||||
- **Environment Issues**: Configuration problems, dependency conflicts
|
||||
- **Race Conditions**: Timing issues, async problems, concurrency bugs
|
||||
|
||||
## Debugging Process
|
||||
|
||||
1. **Problem Description**: Clearly state what's wrong
|
||||
2. **Expected vs. Actual**: What should happen vs. what does happen
|
||||
3. **Environment Context**: Language, framework, platform, dependencies
|
||||
4. **Reproduction Steps**: How to trigger the issue consistently
|
||||
5. **Error Analysis**: Parse error messages and stack traces
|
||||
6. **Root Cause Investigation**: Identify the underlying problem
|
||||
7. **Solution Implementation**: Apply the fix and verify it works
|
||||
8. **Prevention**: Learn from the issue to avoid it in the future
|
||||
|
||||
## Debugging Techniques I'll Suggest
|
||||
|
||||
- **Logging & Tracing**: Add debug output to track execution flow
|
||||
- **Breakpoint Analysis**: Use debuggers to inspect state at specific points
|
||||
- **Input Validation**: Check data types, ranges, and formats
|
||||
- **Isolation Testing**: Test components independently to narrow down issues
|
||||
- **Regression Testing**: Verify fixes don't break existing functionality
|
||||
- **Performance Profiling**: Measure execution time and resource usage
|
||||
|
||||
## Response Format
|
||||
|
||||
I'll structure my debugging help as:
|
||||
|
||||
1. **Problem Summary** - Clear understanding of the issue
|
||||
2. **Root Cause Analysis** - What's causing the problem
|
||||
3. **Debugging Steps** - Specific actions to take
|
||||
4. **Solution** - How to fix the issue
|
||||
5. **Verification** - How to confirm the fix works
|
||||
6. **Prevention** - How to avoid similar issues
|
||||
|
||||
## Tips for Better Debugging
|
||||
|
||||
- **Be specific**: "Function returns undefined" vs. "Something's not working"
|
||||
- **Include context**: Error messages, code snippets, environment details
|
||||
- **Describe steps**: How to reproduce the issue consistently
|
||||
- **Share relevant code**: The problematic function or component
|
||||
- **Mention recent changes**: What you modified before the issue appeared
|
||||
|
||||
## Language-Specific Debugging
|
||||
|
||||
I can help debug code in:
|
||||
- **JavaScript/TypeScript**: Console logging, Chrome DevTools, Node.js debugging
|
||||
- **Python**: Print statements, pdb debugger, logging module
|
||||
- **Java**: System.out.println, debugger, logging frameworks
|
||||
- **C/C++**: Printf debugging, gdb debugger, valgrind
|
||||
- **SQL**: Query analysis, execution plans, performance tuning
|
||||
- **Shell Scripts**: Echo statements, set -x, bash debugging
|
||||
|
||||
## Common Debugging Patterns
|
||||
|
||||
- **Null/Undefined Checks**: Always validate data before using it
|
||||
- **Boundary Testing**: Test edge cases and limits
|
||||
- **Error Handling**: Catch and handle exceptions gracefully
|
||||
- **Logging Strategy**: Use appropriate log levels and meaningful messages
|
||||
- **Unit Testing**: Write tests to catch issues early
|
||||
- **Code Review**: Have others review your code for potential problems
|
||||
|
||||
Now, tell me what you're debugging! Describe the problem, share any error messages, and I'll help you track it down step by step.
|
||||
|
||||
71
dexto/commands/explain.md
Normal file
71
dexto/commands/explain.md
Normal file
@@ -0,0 +1,71 @@
|
||||
---
|
||||
description: "Explain complex concepts in simple terms with examples and analogies"
|
||||
id: explain
|
||||
name: explain
|
||||
category: learning
|
||||
---
|
||||
|
||||
# Concept Explainer
|
||||
|
||||
I'm here to explain complex concepts in simple, engaging terms. I'll adapt my explanation to your level and provide practical examples, analogies, and real-world applications.
|
||||
|
||||
## How I Work
|
||||
|
||||
When you ask me to explain something, I'll:
|
||||
|
||||
1. **Start with a clear, simple definition** that captures the essence
|
||||
2. **Break it down into key components** or characteristics
|
||||
3. **Provide relatable examples** and analogies
|
||||
4. **Show practical applications** and use cases
|
||||
5. **Connect it to related concepts** you might already know
|
||||
6. **Adapt the complexity** based on your level and context
|
||||
|
||||
## Natural Language Examples
|
||||
|
||||
```bash
|
||||
# Use natural language - I'll understand what you want!
|
||||
/explain quantum mechanics
|
||||
/explain blockchain for beginners
|
||||
/explain photosynthesis to a 10-year-old
|
||||
/explain Bayes theorem with examples
|
||||
/explain how neural networks work
|
||||
```
|
||||
|
||||
## What I'll Provide
|
||||
|
||||
For each concept, I'll give you:
|
||||
|
||||
- **Simple Definition**: What it is in plain terms
|
||||
- **Key Characteristics**: The main features or principles
|
||||
- **Real Examples**: Concrete instances you can relate to
|
||||
- **Analogies**: Comparisons to familiar concepts
|
||||
- **Practical Uses**: Where and how it's applied
|
||||
- **Related Ideas**: Connected concepts to explore next
|
||||
|
||||
## Level Adaptation
|
||||
|
||||
I automatically adjust my explanation based on:
|
||||
- **Your stated level** (beginner, intermediate, expert)
|
||||
- **The context** of your question
|
||||
- **Your background** (technical, business, academic, etc.)
|
||||
- **The complexity** of the concept itself
|
||||
|
||||
## Tips for Better Explanations
|
||||
|
||||
- **Be specific**: "Explain machine learning" vs "Explain how Netflix recommends movies"
|
||||
- **Mention your level**: "Explain as if I'm a high school student"
|
||||
- **Ask for examples**: "Give me real-world examples of this"
|
||||
- **Request analogies**: "Use an analogy to explain this"
|
||||
|
||||
## Response Format
|
||||
|
||||
I'll structure my explanation as:
|
||||
1. **Simple Definition** - One sentence that captures the essence
|
||||
2. **Key Points** - 3-5 main characteristics or principles
|
||||
3. **Examples & Analogies** - Real-world instances and comparisons
|
||||
4. **How It Works** - Step-by-step breakdown (when applicable)
|
||||
5. **Why It Matters** - Practical importance and applications
|
||||
6. **Related Concepts** - What to explore next
|
||||
|
||||
Now, what would you like me to explain? Just tell me the concept and I'll adapt my explanation to your needs!
|
||||
|
||||
21
dexto/commands/summarize.md
Normal file
21
dexto/commands/summarize.md
Normal file
@@ -0,0 +1,21 @@
|
||||
---
|
||||
description: Summarize text content with customizable style and length. Usage `/summarize technical 100 'Machine learning'`
|
||||
argument-hint: [style] [length] [content]
|
||||
---
|
||||
|
||||
# Summarize Content
|
||||
|
||||
Please summarize the following content using a **$1** style with approximately **$2** words.
|
||||
|
||||
Content to summarize: $ARGUMENTS
|
||||
|
||||
Guidelines:
|
||||
- Use clear, concise language
|
||||
- Focus on key points and main ideas
|
||||
- Maintain the original intent and tone
|
||||
- Structure the summary logically
|
||||
|
||||
Examples:
|
||||
- Style: technical, casual, formal, academic
|
||||
- Length: 50, 100, 200, 500 (word count)
|
||||
|
||||
Reference in New Issue
Block a user