workspace-architect 1.4.1 → 1.5.1

package/assets/prompts/java-refactoring-extract-method.prompt.md

@@ -1,105 +0,0 @@
----
-title: 'Refactoring Java Methods with Extract Method'
-mode: 'agent'
-description: 'Refactoring using Extract Methods in Java Language'
----
-
-# Refactoring Java Methods with Extract Method
-
-## Role
-
-You are an expert in refactoring Java methods.
-
-Below are **2 examples** (with titles code before and code after refactoring) that represents **Extract Method**.
-
-## Code Before Refactoring 1:
-```java
-public FactLineBuilder setC_BPartner_ID_IfValid(final int bpartnerId) {
-	assertNotBuild();
-	if (bpartnerId > 0) {
-		setC_BPartner_ID(bpartnerId);
-	}
-	return this;
-}
-```
-
-## Code After Refactoring 1:
-```java
-public FactLineBuilder bpartnerIdIfNotNull(final BPartnerId bpartnerId) {
-	if (bpartnerId != null) {
-		return bpartnerId(bpartnerId);
-	} else {
-		return this;
-	}
-}
-public FactLineBuilder setC_BPartner_ID_IfValid(final int bpartnerRepoId) {
-	return bpartnerIdIfNotNull(BPartnerId.ofRepoIdOrNull(bpartnerRepoId));
-}
-```
-
-## Code Before Refactoring 2:
-```java
-public DefaultExpander add(RelationshipType type, Direction direction) {
-     Direction existingDirection = directions.get(type.name());
-     final RelationshipType[] newTypes;
-     if (existingDirection != null) {
-          if (existingDirection == direction) {
-               return this;
-          }
-          newTypes = types;
-     } else {
-          newTypes = new RelationshipType[types.length + 1];
-          System.arraycopy(types, 0, newTypes, 0, types.length);
-          newTypes[types.length] = type;
-     }
-     Map<String, Direction> newDirections = new HashMap<String, Direction>(directions);
-     newDirections.put(type.name(), direction);
-     return new DefaultExpander(newTypes, newDirections);
-}
-```
-
-## Code After Refactoring 2:
-```java
-public DefaultExpander add(RelationshipType type, Direction direction) {
-     Direction existingDirection = directions.get(type.name());
-     final RelationshipType[] newTypes;
-     if (existingDirection != null) {
-          if (existingDirection == direction) {
-               return this;
-          }
-          newTypes = types;
-     } else {
-          newTypes = new RelationshipType[types.length + 1];
-          System.arraycopy(types, 0, newTypes, 0, types.length);
-          newTypes[types.length] = type;
-     }
-     Map<String, Direction> newDirections = new HashMap<String, Direction>(directions);
-     newDirections.put(type.name(), direction);
-     return (DefaultExpander) newExpander(newTypes, newDirections);
-}
-protected RelationshipExpander newExpander(RelationshipType[] types,
-          Map<String, Direction> directions) {
-     return new DefaultExpander(types, directions);
-}
-```
-
-## Task
-
-Apply **Extract Method** to improve readability, testability, maintainability, reusability, modularity, cohesion, low coupling, and consistency.
-
-Always return a complete and compilable method (Java 17).
-
-Perform intermediate steps internally:
-- First, analyze each method and identify those exceeding thresholds:
-  * LOC (Lines of Code) > 15
-  * NOM (Number of Statements) > 10
-  * CC (Cyclomatic Complexity) > 10
-- For each qualifying method, identify code blocks that can be extracted into separate methods.
-- Extract at least one new method with a descriptive name.
-- Output only the refactored code inside a single ```java``` block.
-- Do not remove any functionality from the original method.
-- Include a one-line comment above each new method describing its purpose.
-
-## Code to be Refactored:
-
-Now, assess all methods with high complexity and refactor them using **Extract Method**

package/assets/prompts/java-refactoring-remove-parameter.prompt.md

@@ -1,85 +0,0 @@
----
-title: 'Refactoring Java Methods with Remove Parameter'
-mode: 'agent'
-description: 'Refactoring using Remove Parameter in Java Language'
----
-
-# Refactoring Java Methods with Remove Parameter
-
-## Role
-
-You are an expert in refactoring Java methods.
-
-Below are **2 examples** (with titles code before and code after refactoring) that represents **Remove Parameter**.
-
-## Code Before Refactoring 1:
-```java
-public Backend selectBackendForGroupCommit(long tableId, ConnectContext context, boolean isCloud)
-        throws LoadException, DdlException {
-    if (!Env.getCurrentEnv().isMaster()) {
-        try {
-            long backendId = new MasterOpExecutor(context)
-                    .getGroupCommitLoadBeId(tableId, context.getCloudCluster(), isCloud);
-            return Env.getCurrentSystemInfo().getBackend(backendId);
-        } catch (Exception e) {
-            throw new LoadException(e.getMessage());
-        }
-    } else {
-        return Env.getCurrentSystemInfo()
-                .getBackend(selectBackendForGroupCommitInternal(tableId, context.getCloudCluster(), isCloud));
-    }
-}
-```
-
-## Code After Refactoring 1:
-```java
-public Backend selectBackendForGroupCommit(long tableId, ConnectContext context)
-        throws LoadException, DdlException {
-    if (!Env.getCurrentEnv().isMaster()) {
-        try {
-            long backendId = new MasterOpExecutor(context)
-                    .getGroupCommitLoadBeId(tableId, context.getCloudCluster());
-            return Env.getCurrentSystemInfo().getBackend(backendId);
-        } catch (Exception e) {
-            throw new LoadException(e.getMessage());
-        }
-    } else {
-        return Env.getCurrentSystemInfo()
-                .getBackend(selectBackendForGroupCommitInternal(tableId, context.getCloudCluster()));
-    }
-}
-```
-
-## Code Before Refactoring 2:
-```java
-NodeImpl( long id, long firstRel, long firstProp )
-{
-     this( id, false );
-}
-```
-
-## Code After Refactoring 2:
-```java
-NodeImpl( long id)
-{
-     this( id, false );
-}
-```
-
-## Task
-
-Apply **Remove Parameter** to improve readability, testability, maintainability, reusability, modularity, cohesion, low coupling, and consistency.
-
-Always return a complete and compilable method (Java 17).
-
-Perform intermediate steps internally:
-- First, analyze each method and identify parameters that are unused or redundant (i.e., values that can be obtained from class fields, constants, or other method calls).
-- For each qualifying method, remove the unnecessary parameters from its definition and from all its internal calls.
-- Ensure that the method continues to function correctly after parameter removal.
-- Output only the refactored code inside a single ```java``` block.
-- Do not remove any functionality from the original method.
-- Include a one-line comment above each modified method indicating which parameter was removed and why.
-
-## Code to be Refactored:
-
-Now, assess all methods with unused parameters and refactor them using **Remove Parameter**

package/assets/prompts/java-springboot.prompt.md

@@ -1,66 +0,0 @@
----
-mode: 'agent'
-tools: ['changes', 'search/codebase', 'edit/editFiles', 'problems', 'search']
-description: 'Get best practices for developing applications with Spring Boot.'
----
-
-# Spring Boot Best Practices
-
-Your goal is to help me write high-quality Spring Boot applications by following established best practices.
-
-## Project Setup & Structure
-
-- **Build Tool:** Use Maven (`pom.xml`) or Gradle (`build.gradle`) for dependency management.
-- **Starters:** Use Spring Boot starters (e.g., `spring-boot-starter-web`, `spring-boot-starter-data-jpa`) to simplify dependency management.
-- **Package Structure:** Organize code by feature/domain (e.g., `com.example.app.order`, `com.example.app.user`) rather than by layer (e.g., `com.example.app.controller`, `com.example.app.service`).
-
-## Dependency Injection & Components
-
-- **Constructor Injection:** Always use constructor-based injection for required dependencies. This makes components easier to test and dependencies explicit.
-- **Immutability:** Declare dependency fields as `private final`.
-- **Component Stereotypes:** Use `@Component`, `@Service`, `@Repository`, and `@Controller`/`@RestController` annotations appropriately to define beans.
-
-## Configuration
-
-- **Externalized Configuration:** Use `application.yml` (or `application.properties`) for configuration. YAML is often preferred for its readability and hierarchical structure.
-- **Type-Safe Properties:** Use `@ConfigurationProperties` to bind configuration to strongly-typed Java objects.
-- **Profiles:** Use Spring Profiles (`application-dev.yml`, `application-prod.yml`) to manage environment-specific configurations.
-- **Secrets Management:** Do not hardcode secrets. Use environment variables, or a dedicated secret management tool like HashiCorp Vault or AWS Secrets Manager.
-
-## Web Layer (Controllers)
-
-- **RESTful APIs:** Design clear and consistent RESTful endpoints.
-- **DTOs (Data Transfer Objects):** Use DTOs to expose and consume data in the API layer. Do not expose JPA entities directly to the client.
-- **Validation:** Use Java Bean Validation (JSR 380) with annotations (`@Valid`, `@NotNull`, `@Size`) on DTOs to validate request payloads.
-- **Error Handling:** Implement a global exception handler using `@ControllerAdvice` and `@ExceptionHandler` to provide consistent error responses.
-
-## Service Layer
-
-- **Business Logic:** Encapsulate all business logic within `@Service` classes.
-- **Statelessness:** Services should be stateless.
-- **Transaction Management:** Use `@Transactional` on service methods to manage database transactions declaratively. Apply it at the most granular level necessary.
-
-## Data Layer (Repositories)
-
-- **Spring Data JPA:** Use Spring Data JPA repositories by extending `JpaRepository` or `CrudRepository` for standard database operations.
-- **Custom Queries:** For complex queries, use `@Query` or the JPA Criteria API.
-- **Projections:** Use DTO projections to fetch only the necessary data from the database.
-
-## Logging
-
-- **SLF4J:** Use the SLF4J API for logging.
-- **Logger Declaration:** `private static final Logger logger = LoggerFactory.getLogger(MyClass.class);`
-- **Parameterized Logging:** Use parameterized messages (`logger.info("Processing user {}...", userId);`) instead of string concatenation to improve performance.
-
-## Testing
-
-- **Unit Tests:** Write unit tests for services and components using JUnit 5 and a mocking framework like Mockito.
-- **Integration Tests:** Use `@SpringBootTest` for integration tests that load the Spring application context.
-- **Test Slices:** Use test slice annotations like `@WebMvcTest` (for controllers) or `@DataJpaTest` (for repositories) to test specific parts of the application in isolation.
-- **Testcontainers:** Consider using Testcontainers for reliable integration tests with real databases, message brokers, etc.
-
-## Security
-
-- **Spring Security:** Use Spring Security for authentication and authorization.
-- **Password Encoding:** Always encode passwords using a strong hashing algorithm like BCrypt.
-- **Input Sanitization:** Prevent SQL injection by using Spring Data JPA or parameterized queries. Prevent Cross-Site Scripting (XSS) by properly encoding output.

package/assets/prompts/javascript-typescript-jest.prompt.md

@@ -1,44 +0,0 @@
----
-description: 'Best practices for writing JavaScript/TypeScript tests using Jest, including mocking strategies, test structure, and common patterns.'
-mode: 'agent'
----
-
-### Test Structure
-- Name test files with `.test.ts` or `.test.js` suffix
-- Place test files next to the code they test or in a dedicated `__tests__` directory
-- Use descriptive test names that explain the expected behavior
-- Use nested describe blocks to organize related tests
-- Follow the pattern: `describe('Component/Function/Class', () => { it('should do something', () => {}) })`
-
-### Effective Mocking
-- Mock external dependencies (APIs, databases, etc.) to isolate your tests
-- Use `jest.mock()` for module-level mocks
-- Use `jest.spyOn()` for specific function mocks
-- Use `mockImplementation()` or `mockReturnValue()` to define mock behavior
-- Reset mocks between tests with `jest.resetAllMocks()` in `afterEach`
-
-### Testing Async Code
-- Always return promises or use async/await syntax in tests
-- Use `resolves`/`rejects` matchers for promises
-- Set appropriate timeouts for slow tests with `jest.setTimeout()`
-
-### Snapshot Testing
-- Use snapshot tests for UI components or complex objects that change infrequently
-- Keep snapshots small and focused
-- Review snapshot changes carefully before committing
-
-### Testing React Components
-- Use React Testing Library over Enzyme for testing components
-- Test user behavior and component accessibility
-- Query elements by accessibility roles, labels, or text content
-- Use `userEvent` over `fireEvent` for more realistic user interactions
-
-## Common Jest Matchers
-- Basic: `expect(value).toBe(expected)`, `expect(value).toEqual(expected)`
-- Truthiness: `expect(value).toBeTruthy()`, `expect(value).toBeFalsy()`
-- Numbers: `expect(value).toBeGreaterThan(3)`, `expect(value).toBeLessThanOrEqual(3)`
-- Strings: `expect(value).toMatch(/pattern/)`, `expect(value).toContain('substring')`
-- Arrays: `expect(array).toContain(item)`, `expect(array).toHaveLength(3)`
-- Objects: `expect(object).toHaveProperty('key', value)`
-- Exceptions: `expect(fn).toThrow()`, `expect(fn).toThrow(Error)`
-- Mock functions: `expect(mockFn).toHaveBeenCalled()`, `expect(mockFn).toHaveBeenCalledWith(arg1, arg2)`