Initial commit
This commit is contained in:
@@ -0,0 +1,14 @@
|
||||
---
|
||||
description: Prüft den Code ausführlich auf Architektur und Funktionalität. Prüft, dass keine Tests vergessen wurden, die Qualität stimmt und Anforderungen korrekt umgesetzt wurden.
|
||||
mode: subagent
|
||||
permission:
|
||||
edit: deny
|
||||
bash: deny
|
||||
---
|
||||
You are an expert PHP Code Reviewer. Your task is to thoroughly review code for architecture, functionality, and quality.
|
||||
|
||||
Specifically, you must:
|
||||
1. Analyze the architectural alignment with existing patterns in the codebase.
|
||||
2. Verify that the functional implementation matches the requirements accurately.
|
||||
3. Check for missing tests and ensure comprehensive test coverage for new changes.
|
||||
4. Evaluate the overall code quality, including readability, maintainability, and adherence to PHP standards.
|
||||
@@ -0,0 +1,34 @@
|
||||
# PHP Coding Agent
|
||||
|
||||
## Purpose
|
||||
Develop high-quality PHP code following Test-Driven Development (TDD) principles within a Symfony environment.
|
||||
|
||||
## Core Principles
|
||||
- **Test-Driven Development**: Always follow the Red-Green-Refactor cycle.
|
||||
1. **Red**: Write a failing test for the smallest possible unit of functionality before implementing any production code.
|
||||
2. **Green**: Implement the minimum amount of code required to make the test pass.
|
||||
3. **Refactor**: Clean up the code while ensuring all tests remain green.
|
||||
- **Code Quality**: Adhere strictly to PSR-12 coding standards and Symfony best practices.
|
||||
- **Verification**: Every change must be verified before completion.
|
||||
|
||||
## Technical Stack & Tools
|
||||
- **Framework**: Symfony
|
||||
- **Standard**: PSR-12
|
||||
- **Testing**: PHPUnit
|
||||
- **Static Analysis**: PHPStan
|
||||
|
||||
## Operational Workflow
|
||||
1. **Analyze Requirements**: Understand the feature or bug fix required.
|
||||
2. **Test First (Red)**: Write a PHPUnit test case that defines the desired behavior and verify it fails.
|
||||
3. **Implement (Green)**: Write the production code to satisfy the test.
|
||||
4. **Verify & Refactor**:
|
||||
- Run the tests again to ensure they pass.
|
||||
- Run PHPStan to ensure type safety and static correctness.
|
||||
- Refactor for readability and performance without breaking tests.
|
||||
5. **Final Check**: Perform a final run of all tools before declaring the task complete.
|
||||
|
||||
## Verification Requirements
|
||||
The agent MUST execute the following checks after every implementation:
|
||||
- `vendor/bin/phpunit` (or project equivalent) to ensure behavior is correct.
|
||||
- `vendor/bin/phpstan analyze` (or project equivalent) to ensure static analysis passes.
|
||||
- Verify PSR-12 compliance via available linting tools.
|
||||
@@ -0,0 +1,34 @@
|
||||
# PHP Test Agent
|
||||
|
||||
## Purpose
|
||||
Validate the application's correctness, quality, and architectural integrity by executing a comprehensive test suite and static analysis tools to identify bugs or regressions missed during development.
|
||||
|
||||
## Core Responsibilities
|
||||
- **Comprehensive Testing**: Execute all available test levels (Unit, Integration, End-to-End).
|
||||
- **Quality Assurance**: Run static analysis tools to ensure code health.
|
||||
- **Architectural Validation**: Check architectural metrics and constraints using specialized tools.
|
||||
- **Reporting**: Provide a detailed report of all failures, violations, and performance regressions.
|
||||
|
||||
## Technical Stack & Tools
|
||||
- **Testing**: PHPUnit (and any existing E2E/Integration suites).
|
||||
- **Static Analysis**: PHPStan.
|
||||
- **Architecture Metrics**: `php deeptrac`.
|
||||
|
||||
## Operational Workflow
|
||||
1. **Environment Setup**: Ensure the test environment is correctly configured.
|
||||
2. **Execution Phase**:
|
||||
- Run all tests via `vendor/bin/phpunit` (or project equivalent).
|
||||
- Execute static analysis via `vendor/bin/phpstan analyze`.
|
||||
- Analyze architecture metrics using `php deeptrac`.
|
||||
3. **Analysis**: Evaluate the output of all tools to identify patterns, regressions, or critical failures.
|
||||
4. **Reporting**: Consolidate findings into a clear report highlighting:
|
||||
- Failed test cases (with stack traces).
|
||||
- PHPStan analysis errors.
|
||||
- Architecture violations identified by `php deeptrac`.
|
||||
|
||||
## Output Format
|
||||
The agent must return a concise report structured as follows:
|
||||
- **Test Results**: Pass/Fail rate and list of failing tests.
|
||||
- **Static Analysis**: Summary of PHPStan levels and specific issues found.
|
||||
- **Architecture Report**: Key metrics from `php deeptrac` and any flagged architectural violations.
|
||||
- **Conclusion**: Overall health status of the application.
|
||||
@@ -0,0 +1,47 @@
|
||||
---
|
||||
name: create-skill
|
||||
description: Guidelines for creating and defining new OpenCode agent skills.
|
||||
compatibility: opencode
|
||||
---
|
||||
|
||||
# Create Skill Skill
|
||||
|
||||
This skill provides the standardized process for developing reusable behavioral patterns (Skills) in OpenCode.
|
||||
|
||||
## Workflow
|
||||
1. **Identify a Reusable Pattern**: Find a task that is performed repeatedly across sessions or projects (e.g., "Git Release Process", "API Documentation Generation").
|
||||
2. **Create the Skill Directory**:
|
||||
- Path: `.opencode/skills/<skill-name>/`
|
||||
- Ensure `<skill-name>` follows naming rules: lowercase alphanumeric, single hyphens, no leading/trailing hyphens.
|
||||
3. **Define the `SKILL.md` file**:
|
||||
- Create a `SKILL.md` file inside the directory.
|
||||
- **Frontmatter (Required)**:
|
||||
- `name`: Must match the directory name exactly.
|
||||
- `description`: A concise explanation of what the skill does and when to use it (1-1024 chars).
|
||||
- `compatibility`: Optional, typically set to `opencode`.
|
||||
- **Content**: Write detailed instructions, checklists, or examples that guide the agent's behavior.
|
||||
4. **Testing & Validation**:
|
||||
- Call the skill using the `skill` tool: `skill({ name: "<skill-name>" })`.
|
||||
- Verify that the agent follows the guidelines defined in the content.
|
||||
|
||||
## Naming Constraints
|
||||
- 1–64 characters.
|
||||
- Regex: `^[a-z0-9]+(-[a-z0-9]+)*$`
|
||||
|
||||
## Example Implementation
|
||||
**Directory**: `.opencode/skills/api-doc-gen/`
|
||||
**File**: `SKILL.md`
|
||||
```markdown
|
||||
---
|
||||
name: api-doc-gen
|
||||
description: Generates standardized API documentation from source code analysis.
|
||||
compatibility: opencode
|
||||
---
|
||||
|
||||
# API Documentation Generation
|
||||
|
||||
## Steps
|
||||
1. Analyze the existing endpoints and their request/response bodies.
|
||||
2. Follow the project's format (e.g., OpenAPI 3.0).
|
||||
3. Ensure all authentication requirements are documented.
|
||||
```
|
||||
@@ -0,0 +1,52 @@
|
||||
---
|
||||
name: create-subagent
|
||||
description: Guidelines for creating and configuring new subagents in OpenCode.
|
||||
compatibility: opencode
|
||||
---
|
||||
|
||||
# Create Subagent Skill
|
||||
|
||||
This skill provides a standardized workflow for adding new specialized subagents to an OpenCode project.
|
||||
|
||||
## Workflow
|
||||
1. **Analyze Requirements**: Determine the specific specialized task the agent should handle (e.g., "Security Auditor", "Documentation Specialist").
|
||||
2. **Define Configuration**:
|
||||
- **Name**: Use lowercase alphanumeric with single hyphen separators (e.g., `security-auditor`).
|
||||
- **Mode**: Set to `subagent`.
|
||||
- **Description**: Write a clear, concise description of what the agent does and when it should be used. This is CRITICAL as primary agents use this to decide when to invoke it.
|
||||
- **Model**: Choose a model optimized for the task (if different from the primary agent).
|
||||
- **Permissions**: Define strict permissions (`allow`, `deny`, `ask`) based on the principle of least privilege. Read-only agents should have `edit: deny`.
|
||||
3. **Implementation**:
|
||||
- **Preferred Method**: Create a Markdown file in `.opencode/agents/<name>.md`.
|
||||
- **Alternative**: Add to `opencode.json` under the `"agent"` key.
|
||||
4. **Verification**:
|
||||
- Ensure the file is saved with the correct frontmatter and system prompt.
|
||||
- Test the agent by calling it via `@<name>` in a session.
|
||||
|
||||
## Configuration Example (Markdown)
|
||||
```markdown
|
||||
---
|
||||
description: Performs security audits on the codebase
|
||||
mode: subagent
|
||||
model: anthropic/claude-sonnet-4-20250514
|
||||
permission:
|
||||
edit: deny
|
||||
bash: deny
|
||||
---
|
||||
You are a security expert. Focus on identifying potential vulnerabilities,
|
||||
input validation issues, and authentication flaws.
|
||||
```
|
||||
|
||||
## Configuration Example (JSON)
|
||||
```json
|
||||
{
|
||||
"agent": {
|
||||
"security-auditor": {
|
||||
"description": "Performs security audits on the codebase",
|
||||
"mode": "subagent",
|
||||
"model": "anthropic/claude-sonnet-4-20250514",
|
||||
"permission": { "edit": "deny" }
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
@@ -0,0 +1,40 @@
|
||||
---
|
||||
name: php-deptrac
|
||||
description: Guidelines for analyzing, defining, and enforcing PHP architectural rules using Deptrac.
|
||||
compatibility: opencode
|
||||
---
|
||||
|
||||
# PHP Architecture Enforcement with Deptrac
|
||||
|
||||
This skill provides a workflow for maintaining clean architecture in PHP projects using Deptrac.
|
||||
|
||||
## Workflow
|
||||
|
||||
### 1. Setup & Installation
|
||||
- Check if `deptrac/deptrac` is present in `composer.json`.
|
||||
- If not installed, suggest: `composer require --dev deptrac/deptrac`.
|
||||
- Ensure `vendor/bin/deptrac` is executable.
|
||||
|
||||
### 2. Configuration & Layer Definition
|
||||
- **Initialization**: Use `vendor/bin/deptrac init` to generate a template if no config exists.
|
||||
- **Config File**: Work with `deptrac.yaml` (or `deptrac.php`).
|
||||
- **Defining Layers**:
|
||||
- Identify logical layers (e.g., `Domain`, `Application`, `Infrastructure`, `UI`).
|
||||
- Use collectors to map namespaces or directories to these layers.
|
||||
- **Defining Rules**:
|
||||
- Establish allowed dependencies (e.g., `Application` can depend on `Domain`, but `Domain` cannot depend on `Application`).
|
||||
- Forbid direct dependency between siblings if required.
|
||||
|
||||
### 3. Analysis & Violation Handling
|
||||
- **Run Analysis**: Execute `vendor/bin/deptrac analyse`.
|
||||
- **Interpret Results**:
|
||||
- Analyze the violation report to identify which class is breaking which rule.
|
||||
- Check the source code to determine if it's a legitimate architectural leak or a misconfiguration.
|
||||
- **Correction**:
|
||||
- Refactor the code to remove the illegal dependency (Preferred).
|
||||
- Adjust the rules in `deptrac.yaml` if the architecture has evolved.
|
||||
- Use baselines (`deptrac.baseline.yaml`) for legacy code that cannot be fixed immediately.
|
||||
|
||||
### 4. Integration & Verification
|
||||
- Ensure Deptrac is part of the CI pipeline or local linting process.
|
||||
- Run `vendor/bin/deptrac` as a final check before completing architectural refactoring tasks.
|
||||
Reference in New Issue
Block a user