@rexeus/agentic 0.3.1

package/skills/quality-patterns/SKILL.md

@@ -0,0 +1,73 @@
+---
+name: quality-patterns
+description: Identifies code quality anti-patterns and provides best practices. Applied when analyzing code smells, architecture decisions, complexity, or technical debt.
+user-invokable: false
+---
+
+# Quality Patterns & Anti-Patterns
+
+Code quality isn't subjective. These patterns are proven signals — each backed
+by decades of engineering wisdom. When this skill is active, evaluate code
+against these patterns. Flag violations with evidence and specific remediation.
+
+## Anti-Patterns to Flag
+
+### Complexity
+
+- **God objects**: Classes with many unrelated public methods or excessive dependencies
+  (typically 8+ public methods across multiple concerns, or 10+ dependencies).
+  Fix: Extract focused collaborators.
+- **Feature envy**: A function that accesses another object's data more than its own.
+  Fix: Move the behavior to where the data lives.
+- **Primitive obsession**: Using strings or numbers where a domain type would add clarity.
+  Fix: Introduce a value object (`EmailAddress`, `Money`, `UserId`).
+- **Deep nesting**: More than 3 levels of indentation.
+  Fix: Extract to functions, use early returns, invert conditions.
+
+### Coupling
+
+- **Temporal coupling**: Functions that must be called in a specific order.
+  Fix: Make the dependency explicit through function composition or a builder pattern.
+- **Stamp coupling**: Passing a large object when only one field is needed.
+  Fix: Pass only what's needed. Narrow the interface.
+- **Leaky abstractions**: Implementation details surfacing through a public API.
+  Fix: Introduce an interface boundary.
+
+### Duplication
+
+- **Shotgun surgery**: A single change requires edits in many places.
+  Fix: Centralize the varying behavior behind an abstraction.
+- **Copy-paste code**: Identical or near-identical blocks in multiple locations.
+  Fix: Extract a shared function. If the duplication is structural, extract a pattern.
+- **Long parameter lists**: Functions taking 4+ parameters that travel together.
+  Fix: Introduce a parameter object or config type.
+- **Data clumps**: Groups of values that always appear together across multiple functions.
+  Fix: Extract a cohesive type that represents the concept.
+
+### Error Handling
+
+- **Silent failures**: Catching errors without logging or rethrowing.
+  Fix: At minimum, log. Better: rethrow or return a Result type.
+- **Overly broad catches**: `catch (e: any)` or `catch (Exception e)`.
+  Fix: Catch the narrowest type possible.
+- **Error codes as control flow**: Using return values instead of exceptions (or vice versa) inconsistently.
+  Fix: Pick one pattern and use it consistently within a boundary.
+
+## Positive Patterns to Encourage
+
+- **Single Responsibility**: Each module has one reason to change.
+- **Dependency Inversion**: Depend on abstractions, not concretions.
+- **Fail Fast**: Validate inputs at the boundary, trust internals.
+- **Composition over Inheritance**: Combine behaviors through composition.
+- **Immutability by Default**: Mutable state is opt-in, not opt-out.
+- **Explicit over Implicit**: Make side effects, dependencies, and state transitions visible.
+
+## Severity Classification
+
+When reporting issues, classify by impact:
+
+- **Critical**: Will cause bugs, data loss, or security vulnerabilities. Must fix.
+- **Warning**: Increases maintenance cost or risk. Should fix.
+- **Suggestion**: Improves clarity or follows best practices. Consider fixing.
+
+Only flag issues you are confident about. False positives erode trust.

package/skills/security/SKILL.md

@@ -0,0 +1,77 @@
+---
+name: security
+description: Identifies security vulnerabilities and provides secure coding patterns. Applied when reviewing code for injection, authentication, authorization, and data exposure risks.
+user-invokable: false
+---
+
+# Security Patterns
+
+Security isn't a feature. It's a property of well-crafted code. Every
+vulnerability caught in review is an incident prevented in production.
+When this skill is active, evaluate code against these patterns and flag
+vulnerabilities
+with specific, actionable remediation steps.
+
+## Injection
+
+- **SQL Injection**: User input concatenated into SQL queries.
+  Fix: Use parameterized queries or prepared statements. Never interpolate.
+- **Command Injection**: User input passed to shell commands or process spawning.
+  Fix: Use library APIs instead of shell commands. If unavoidable, use allowlists
+  and argument arrays instead of string interpolation.
+- **XSS (Cross-Site Scripting)**: User input rendered as HTML without escaping.
+  Fix: Use framework-provided escaping. Never set innerHTML with user data.
+- **Template Injection**: User input evaluated in template engines.
+  Fix: Use sandboxed templates. Never pass user input to dynamic code evaluation.
+
+## Authentication & Authorization
+
+- **Hardcoded credentials**: API keys, passwords, or tokens in source code.
+  Fix: Use environment variables or a secrets manager. Never commit secrets.
+- **Weak token generation**: Predictable session tokens or API keys.
+  Fix: Use cryptographically secure random generators (crypto.randomUUID).
+- **Missing authorization checks**: Endpoints that verify authentication but not permissions.
+  Fix: Check authorization at every endpoint. Don't rely on client-side checks.
+- **Insecure password handling**: Plaintext storage or weak hashing (MD5, SHA1).
+  Fix: Use bcrypt, scrypt, or argon2 with appropriate cost factors.
+
+## Data Exposure
+
+- **Sensitive data in logs**: Passwords, tokens, or PII written to log output.
+  Fix: Sanitize log entries. Use structured logging with field-level filtering.
+- **Verbose error messages**: Stack traces or internal paths exposed to users.
+  Fix: Return generic error messages to clients. Log details server-side only.
+- **Missing encryption**: Sensitive data stored or transmitted in plaintext.
+  Fix: Use TLS for transit. Encrypt at rest with AES-256 or equivalent.
+
+## Server-Side Risks
+
+- **SSRF (Server-Side Request Forgery)**: User-controlled URLs passed to server-side HTTP requests.
+  Fix: Validate and allowlist target URLs. Block internal/private IP ranges.
+- **Insecure deserialization**: Untrusted data deserialized without validation.
+  Fix: Validate structure before deserialization. Use schema validation (Zod, JSON Schema).
+
+## Input Validation
+
+- **Missing boundary validation**: No checks on input size, range, or format.
+  Fix: Validate at the system boundary. Reject before processing.
+- **Type coercion vulnerabilities**: Loose comparisons that bypass checks.
+  Fix: Use strict equality. Validate types explicitly.
+- **Path traversal**: User input used to construct file paths.
+  Fix: Use path.resolve and validate the result stays within allowed directories.
+
+## Dependency Security
+
+- **Known vulnerable dependencies**: Packages with published CVEs.
+  Fix: Run npm audit or equivalent. Update or replace vulnerable packages.
+- **Typosquatting risk**: Dependencies with names similar to popular packages.
+  Fix: Verify package names, publishers, and download counts before installing.
+
+## Adapting to the Project
+
+Before flagging security issues:
+
+1. Check if the project has security-specific CLAUDE.md rules
+2. Understand the trust boundary — internal tools have different risk profiles
+3. Don't flag issues in test code unless they affect production security
+4. Consider the deployment context (serverless, container, bare metal)

package/skills/setup/SKILL.md

@@ -0,0 +1,105 @@
+---
+name: setup
+description: Getting started with Agentic — workflow, commands, and how the agent team works together.
+---
+
+# Getting Started with Agentic
+
+Agentic is a multi-agent development toolkit. Seven specialists, one
+orchestrator (the Lead), zero configuration.
+
+In OpenCode, `lead` is installed as a visible primary agent. The specialists
+are installed as hidden subagents. Talk to the Lead; the Lead deploys the team.
+
+## Your First Session
+
+The Lead agent is your main thread. Start with the Lead when you want to build,
+fix, or improve something — it deploys the right specialists for the job.
+
+For structured workflows, use the commands:
+
+```
+OpenCode:    /agentic-plan      Claude Code: /agentic:plan
+OpenCode:    /agentic-develop   Claude Code: /agentic:develop
+OpenCode:    /agentic-review    Claude Code: /agentic:review
+OpenCode:    /agentic-simplify  Claude Code: /agentic:simplify
+OpenCode:    /agentic-polish    Claude Code: /agentic:polish
+OpenCode:    /agentic-verify    Claude Code: /agentic:verify
+OpenCode:    /agentic-commit    Claude Code: /agentic:commit
+OpenCode:    /agentic-pr        Claude Code: /agentic:pr
+```
+
+## The Typical Flow
+
+```
+Plan → Develop → Review → Simplify → Verify → Commit → PR
+                                ↑
+                              Polish (iterative loop)
+```
+
+1. `/agentic-plan` (OpenCode) or `/agentic:plan` (Claude Code) — describe what you want. The Lead asks questions, challenges
+   scope, and produces a plan. You approve before anything is built.
+2. `/agentic-develop` (OpenCode) or `/agentic:develop` (Claude Code) — the Lead scouts the codebase, designs the approach,
+   briefs the developer, and runs review + tests.
+3. `/agentic-review` (OpenCode) or `/agentic:review` (Claude Code) — independent parallel reviewers check correctness,
+   security, and conventions.
+4. `/agentic-simplify` (OpenCode) or `/agentic:simplify` (Claude Code) — the Refiner removes unnecessary complexity while
+   preserving behavior.
+
+   **Polish.** `/agentic-polish` (OpenCode) or `/agentic:polish` (Claude Code) is the consistency loop. It aligns the code
+   with established patterns, smooths out inconsistencies, and is designed for iterative runs until the codebase converges.
+
+5. Review the changes yourself. Stage what looks good with `git add`.
+6. `/agentic-commit` (OpenCode) or `/agentic:commit` (Claude Code) — creates the commit message from staged changes.
+7. `/agentic-pr` (OpenCode) or `/agentic:pr` (Claude Code) — creates or updates a Pull Request.
+
+Skip steps you don't need. Every command works independently.
+
+## Important: You Control Staging
+
+No agent will ever run `git add`, `git stash`, or modify your staged files.
+Staging is your responsibility. The agents write code — you decide what ships.
+
+## The Agents
+
+You don't deploy agents directly. The Lead does that based on your task:
+
+- **Scout** — fast reconnaissance, maps the codebase
+- **Analyst** — traces logic, follows data flows, explains mechanics
+- **Architect** — designs solutions, evaluates trade-offs
+- **Developer** — the only agent that writes source code
+- **Reviewer** — reviews for correctness and security (read-only)
+- **Tester** — writes and runs tests (test code only)
+- **Refiner** — simplifies working code without changing behavior
+
+## Customizing Models
+
+Agents use your default model unless overridden. In OpenCode, configure
+per-agent models in `opencode.json`:
+
+```json
+{
+  "agent": {
+    "lead": { "model": "openai/gpt-5.4" },
+    "scout": { "model": "anthropic/claude-haiku-4-5" },
+    "developer": { "model": "openai/gpt-5.4" }
+  }
+}
+```
+
+Model IDs use the `provider/model` format. A practical setup: fast model for
+the scout (reconnaissance), capable model for the lead and developer
+(orchestration and implementation), default for the rest.
+
+In Claude Code, model overrides are configured in `settings.json` via the
+`agentSettings` key.
+
+## Guardrails
+
+The plugin enforces quality automatically:
+
+- **Secrets blocked** before writing (hardcoded passwords, API tokens)
+- **Commit messages validated** against Conventional Commits format
+- **Debug statements flagged** after writing (console.log, debugger)
+- **Unowned TODOs flagged** — use `TODO(name)` or `TODO(#123)`
+- **Agent role enforcement** via Stop hooks (Claude Code integration)

package/skills/testing/SKILL.md

@@ -0,0 +1,113 @@
+---
+name: testing
+description: Provides testing philosophy, patterns, and strategies. Applied when writing tests, assessing coverage, or designing test architectures.
+user-invokable: false
+---
+
+# Testing Patterns
+
+Examples use **TypeScript/JavaScript** conventions (Vitest, Jest, Mocha).
+For other languages, adapt patterns to the project's test framework.
+
+Tests aren't bureaucracy. They're a commitment to excellence — proof that
+the code does what it claims. When this skill is active, apply these
+principles to every test you write or assess.
+
+## Philosophy
+
+- **Test behavior, not implementation.** Tests verify what the code does,
+  not how it does it. A refactoring that preserves behavior should never
+  break a test.
+- **One assertion per concept.** Each test verifies one specific behavior.
+  If a test name needs "and", split it.
+- **Tests are documentation.** A well-named test suite is a specification.
+  `it('returns 401 when token is expired')` is both test and documentation.
+- **Fast tests run often.** The faster the feedback loop, the more value
+  tests provide. Prefer unit tests over integration tests over E2E tests.
+
+## Test Structure
+
+Follow the **Arrange-Act-Assert** pattern:
+
+```
+// Arrange: set up the preconditions
+const user = createTestUser({ role: 'admin' })
+const request = buildRequest({ userId: user.id })
+
+// Act: execute the behavior under test
+const result = await handleRequest(request)
+
+// Assert: verify the outcome
+expect(result.status).toBe(200)
+```
+
+Each section should be clearly separated. If Arrange is more than 5 lines,
+extract a factory or fixture.
+
+## Naming Conventions
+
+Test names should read as specifications:
+
+- `describe('TokenService')` — the unit under test
+- `describe('validate()')` — the method or behavior
+- `it('returns invalid when token is expired')` — the specific case
+
+Pattern: `it('<expected outcome> when <condition>')`
+
+## What to Test
+
+### Layer 1: Unit Tests (always)
+
+- Individual functions and methods in isolation
+- Pure logic, calculations, transformations
+- Error handling paths
+- Boundary conditions
+
+### Layer 2: Integration Tests (at boundaries)
+
+- Component interactions
+- Database queries (with test database)
+- API endpoint request/response cycles
+- Middleware chains
+
+### Layer 3: Edge Cases (where bugs hide)
+
+- Empty, null, undefined inputs
+- Boundary values: 0, -1, MAX_INT, empty string, single character
+- Concurrent operations and race conditions
+- Large inputs, deeply nested structures
+- Invalid types and malformed data
+- Unicode, special characters, emoji
+
+## Test Doubles
+
+Use the right double for the job:
+
+- **Stub**: Returns predetermined data. Use when you need controlled input.
+- **Mock**: Verifies interactions. Use sparingly — only when the interaction IS the behavior.
+- **Fake**: Working implementation with shortcuts. Use for external services.
+- **Spy**: Records calls without changing behavior. Use to observe side effects.
+
+**Rule:** Prefer stubs over mocks. Mocking implementation details creates brittle tests.
+
+## Anti-Patterns to Avoid
+
+- **Test interdependence**: Tests that must run in a specific order.
+  Fix: Each test sets up and tears down its own state.
+- **Testing implementation**: Asserting on internal method calls or private state.
+  Fix: Test the public interface and observable outcomes only.
+- **Flaky tests**: Tests that sometimes pass and sometimes fail.
+  Fix: Eliminate time-dependence, randomness, and shared state.
+- **Giant test files**: Hundreds of tests in a single file.
+  Fix: Group by behavior. One describe block per method or feature.
+- **Commented-out tests**: Tests disabled instead of fixed or removed.
+  Fix: Fix or delete. Commented tests rot and mislead.
+
+## Adapting to the Project
+
+Before writing tests:
+
+1. Identify the test framework in use (Jest, Vitest, Mocha, pytest, etc.)
+2. Find existing test utilities, factories, and fixtures
+3. Match the naming convention and file structure
+4. Check for CI/CD test configuration and coverage thresholds