Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Schema
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| project-onboarding | |
| debug-systematic-approach | Structured approach to debugging complex issues with root cause analysis |
| lovable-ai-editor-base | A prompt that defines the core identity and capabilities of 'Lovable', an AI assistant designed for real-time web application development and modification. It establishes the AI's role as a conversational partner that can edit code, use a live preview, access project assets like images and console logs, and assist with debugging. |
| performance-optimization | Comprehensive performance analysis and optimization strategies for applications |
| perplexity-search-assistant | This prompt defines the behavior of Perplexity, a helpful search assistant. Its goal is to provide accurate, detailed, and comprehensive answers to queries based on provided search results. It emphasizes proper formatting, citation, and an unbiased, journalistic tone, while also outlining specific instructions for different query types like academic research, recent news, coding, and more. |
| replit-expert-software-developer-editor | This prompt defines the role and operating principles for an expert autonomous programmer built by Replit. It outlines the iteration process, workflow guidelines, debugging procedures, user interaction policies, and best practices for developing software within the Replit environment. The core focus is on efficiently fulfilling user requests with minimal interaction, prioritizing Replit's built-in tools, and maintaining clear communication with non-technical users. |
| sql-expert | Defines the LLM as a highly knowledgeable SQL expert, capable of understanding complex database concepts, generating optimized SQL queries, and discussing advanced topics like schema design, performance optimization, and security in the context of LLM-SQL integration. The persona emphasizes precision, contextual awareness, and the ability to act as a guide for other SQL professionals. |
| clean-code-clarity-readability | Generate code that is self-explanatory, using clear and meaningful names, and logical organization, minimizing the need for extensive comments. |
| clean-code-small-functions | Generate functions that are concise, ideally no more than 20 lines, and perform a single, clearly defined task. This improves readability, testability, and reusability. |
| clean-code-single-abstraction-level | Generate functions where all statements operate at the same conceptual level, separating high-level logic from detailed implementations. Utilize 'Extract Method' refactoring where appropriate. |
| clean-code-tests | Generate code alongside its unit tests. The tests should be fast, independent, repeatable, self-validating, and written contemporaneously with the production code. |
| clean-code-no-duplication-dry | Generate code that avoids duplication, following the 'Don't Repeat Yourself' (DRY) principle. Suggest abstractions or refactoring techniques like 'Extract Method' to eliminate redundant code. |
| clean-code-continuous-improvement | Analyze a given code snippet or module and suggest refactorings to leave it cleaner than found, adhering to the 'Boy Scout Rule'. Focus on small, continuous improvements. |
| solid-single-responsibility-principle | Design a class or module where each entity has a single, clearly defined responsibility, encapsulating that functionality completely. This leads to smaller, cleaner, more maintainable, and testable classes. |
| solid-open-closed-principle | Design software entities to be open for extension but closed for modification. New functionality should be added through extension of existing code, not by altering it. |
| solid-liskov-substitution-principle | When designing class hierarchies, ensure that objects of subclasses can be substituted for objects of their base classes without altering the correctness of the program. Focus on behavioral contracts. |
| solid-interface-segregation-principle | Design multiple smaller, client-specific interfaces rather than a single large, 'fat' interface. This reduces dependencies and improves modularity. |
| solid-dependency-inversion-principle | Design modules to depend on abstractions, not on concretions. Both high-level and low-level modules should depend on abstractions. This promotes loose coupling, flexibility, and maintainability. |
| design-principle-dry | Generate code that adheres to the 'Don't Repeat Yourself' (DRY) principle, reducing information repetition by using abstractions or data normalization. |
| design-principle-kiss | Generate code that adheres to the 'Keep It Simple, Stupid' (KISS) principle, ensuring designs and systems are as simple as possible to understand and maintain. |
| design-principle-yagni | Generate code that adheres to the 'You Aren't Gonna Need It' (YAGNI) principle, adding functionality only when it is deemed necessary, preventing over-engineering and unnecessary complexity. |
| procedural-clear-naming-conventions | Generate procedural code using clear and descriptive naming conventions for variables, functions, and files. Use snake_case for variables/functions and uppercase for constants. |
| procedural-limited-scope-no-globals | Generate procedural code that minimizes the use of global variables, preferring local scope to reduce unexpected side effects and debugging difficulties. |
| procedural-controlled-branching-loops | Generate procedural code with limited nesting of if/else statements and loops (ideally 2-3 levels) to prevent excessive complexity. Avoid intentional infinite loops. |
| oop-abstraction | Design object-oriented code emphasizing abstraction: separating 'what' from 'how' by focusing on high-level ideas and hiding unnecessary details from the client through clear contracts. |
| oop-encapsulation | Generate object-oriented code that bundles data and methods within a single unit (the object) and restricts direct access to internal components, isolating parts of an application. |
| oop-meaningful-names-camelcase | Generate object-oriented code using consistent, descriptive names for classes, methods, and variables, typically in CamelCase. Class names should start with an uppercase letter. |
| oop-fewer-arguments | Design object-oriented methods with a minimal number of arguments, leveraging object properties within the class instead. Avoid methods with too many arguments as they are hard to read. |
| oop-avoid-statics-wisely | Generate object-oriented code that minimizes the use of static methods, as they can hinder testability and object-oriented design principles. Provide alternatives where appropriate. |
| oop-reduce-conditional-statements | Generate object-oriented code that minimizes excessive `if/else` ladders, favoring behavioral polymorphism (Strategy or Factory patterns) to reduce complexity and improve reusability. |
| declarative-prioritize-readability | Generate declarative code that is highly readable and expressive, focusing on describing the desired outcome rather than the explicit steps. |
| declarative-focus-data-relations | Generate declarative code that emphasizes the declaration of relationships between different pieces of data. |
| functional-pure-functions-immutability | Generate functional code that uses pure functions (same input, same output, no side effects) and immutable data structures. This promotes predictability, easier testing, and parallelizability. |
| functional-higher-order-functions | Generate functional code that effectively uses higher-order functions (functions that take other functions as arguments or return them) like `map`, `filter`, and `reduce` for data transformations. |
| software-architecture-separation-of-concerns | Design software architecture by separating concerns based on the type of work performed (e.g., business logic from UI/infrastructure logic), ensuring testability and loose coupling. |
| software-architecture-architectural-patterns | Propose and explain the choice of a suitable architectural pattern (e.g., Layered, Event-Driven, Microservices) for a given software project scenario, outlining its benefits and considerations. |
| software-design-patterns | Identify a common software design problem in a given context and propose a relevant Gang of Four (GoF) design pattern (Creational, Structural, or Behavioral) as a solution, explaining its benefits. |
| testing-unit-test-generation | Generate unit tests for a given code snippet, ensuring they are fast, independent, repeatable, self-validating, and comprehensive. |
| testing-proactive-test-strategy | Based on a software design or feature description, propose a proactive, continuous, and integrated testing strategy, including relevant test types (unit, integration, functional, etc.) and automation considerations. |
| code-review-feedback-generation | Generate constructive feedback for a given code snippet or pull request, focusing on functionality, design, complexity, testability, naming, and documentation, in a collaborative tone. |
| code-review-anti-pattern-identification | Analyze a code snippet and identify common anti-patterns or violations of modern programming guidelines (e.g., Clean Code, SOLID, DRY, KISS, YAGNI), providing explanations and suggesting improvements. |
| version-control-meaningful-commits | Generate a clear, concise, and descriptive Git commit message for a given set of code changes or a feature implementation, ensuring it provides context and relates to a single task or ticket. |
| version-control-branching-strategy | Propose a suitable Git branching strategy (e.g., Feature Branches, Git Flow, GitHub Flow) for a team based on their project size, release cadence, and collaboration needs. Explain the chosen strategy's workflow. |
| documentation-inline-comments | Generate inline comments that explain 'why' a piece of code is written in a certain way, rather than simply reiterating 'what' the code does, especially for complex or non-obvious logic. |
| documentation-api-documentation | Generate comprehensive API documentation (e.g., Javadoc, PyDoc) for a given method or class, describing its purpose, arguments, return values, exceptions, and usage contract for future developers. |
| documentation-readme-generation | Generate a comprehensive `README.md` file for a given project description, including sections for purpose, setup, usage, and reference to detailed guides. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_prompt_stats | Get statistics about available prompts |
| get_tool_stats | Get statistics about available tools |
| list_skills | List all available development skills with descriptions and IDs |
| load_skills | Load and combine multiple skills into an agent's knowledge base |
| search_profiles | Search for profiles |
| search_prompts | Search for prompts by keyword or tag |