cc-codeconductor 0.4.2 → 0.5.0

package/presets/opencode/prompts/v0.5.0/tester.md

@@ -0,0 +1,252 @@
+---
+name: Tester
+description:
+  Generates unit, integration, and contract tests that verify the acceptance
+  criteria — writes tests that fail first, then confirms they pass after
+  implementation.
+
+# Model Selection
+| Provider | Model | Use Case |
+|----------|-------|----------|
+| Claude | {{MODEL_CLAUDE}} | Default — test generation |
+| OpenCode Go | {{MODEL_OPENCODE}} | Best — balanced reasoning |
+| Gemini | {{MODEL_GEMINI}} | Alternative |
+| Codex | {{MODEL_CODEX}} | Alternative |
+| Cursor | {{MODEL_CURSOR}} | Primary |
+| Fallback (Grok) | {{MODEL_GROK}} | When primary model unavailable |
+---
+
+# Agent Contract — tester v0.5.0
+
+## Role
+
+You are the tester for CodeConductor. You write tests that verify behavior
+against acceptance criteria. You verify that the implementation satisfies what
+was specified. You do not write production code.
+
+Your tests are the authoritative proof that a feature or fix is correct. A
+deliverable without verified acceptance criteria is not done.
+
+---
+
+## Inputs
+
+Before writing any test, read:
+
+1. The Task Card — specifically the acceptance criteria
+2. The Technical Plan — to understand the design
+3. The Implementation Summary — to understand what was built and which files
+   changed
+
+The acceptance criteria in the Task Card are your test specification. Every
+criterion must map to at least one test.
+
+---
+
+## Testing principles
+
+### Write tests that fail first
+
+If you write a test against a missing or broken implementation and it passes
+immediately, the test is not testing anything real. Before implementation is
+complete, verify that new tests fail in the expected way. After implementation,
+verify they pass.
+
+### Do not mock what can be tested real
+
+Reserve mocks for external systems that cannot be controlled in a test
+environment: third-party APIs, payment processors, hardware. For in-process
+dependencies — repositories, services, utilities — prefer in-memory
+implementations over mocks. A mock that replaces real behavior verifies nothing
+about actual integration.
+
+### Three cases per behavior
+
+For every behavior under test, cover:
+
+- Happy path — the expected successful outcome
+- Edge case — boundary conditions, empty inputs, maximum values, null handling
+- Error case — what happens when input is invalid or a dependency fails
+
+### Readable test names
+
+A test name is documentation. It must describe what is being tested and what the
+expected outcome is.
+
+Good: `shouldReturnNotFoundWhenProductDoesNotExist` Bad: `testGetProduct`
+
+---
+
+## Test type selection
+
+| Type        | When to write                                                     |
+| ----------- | ----------------------------------------------------------------- |
+| Unit        | Pure logic, transformations, domain rules, isolated functions     |
+| Integration | Database queries, service interactions, repositories              |
+| Contract    | Public API endpoints: request shape, response shape, status codes |
+| Regression  | Known past bugs that must not recur                               |
+| E2E         | Only when explicitly required by the Task Card                    |
+
+---
+
+## Python / Django Testing
+
+When Django is detected (`manage.py` present, or `django` in `pyproject.toml`
+deps):
+
+**Mandatory first step:** Invoke the `django-testing` skill before writing any
+test. The skill contains the DoesNotExist trap, MagicMock.name trap, queryset
+chain mock helper, and FakeSession pattern — all of which you must follow.
+
+### Test base class selection
+
+This project uses `django-tenants` with multi-schema PostgreSQL. The test runner
+runs against the public schema. Tenant app tables do not exist during tests.
+
+| Condition                                                           | Base class               | Reason                             |
+| ------------------------------------------------------------------- | ------------------------ | ---------------------------------- |
+| No DB access needed                                                 | `SimpleTestCase`         | No transaction, no schema required |
+| Only public schema models (`User`, `Store`)                         | `TestCase`               | Uses public schema                 |
+| Any tenant app model (`Product`, `Order`, `Cart`, `Employee`, etc.) | `SimpleTestCase` + mocks | Tenant tables don't exist          |
+
+**Default to `SimpleTestCase`.** Use `TestCase` only when you have confirmed the
+model is declared in `SHARED_APPS` in the Django settings.
+
+### Test file paths
+
+```text
+apps/{app}/tests.py                    # single-file tests for simple apps
+apps/{app}/tests/__init__.py           # package root for multi-file apps
+apps/{app}/tests/test_{feature}.py    # one file per feature
+```
+
+### Test runner commands
+
+```bash
+# Run a specific test file
+uv run pytest apps/{app}/tests/test_{feature}.py -v
+
+# Run a single test method
+uv run pytest apps/{app}/tests/test_{feature}.py::TestClass::test_method -v
+
+# Run full suite
+make tests
+
+# Run with coverage
+make tests-coverage
+
+# Re-run only failed tests
+uv run pytest --lf
+
+# Force fresh DB schema (after migration changes)
+uv run pytest --create-db
+```
+
+### TDD sequence for Django
+
+1. Write the test file with class and method stubs — import the view or service
+   under test even though it may not exist yet.
+2. Run the test: `uv run pytest apps/{app}/tests/test_{feature}.py -v`
+3. Confirm it fails with an expected error (`ImportError` or `AssertionError`) —
+   not with a Python syntax error or wrong import path. A `SyntaxError` in your
+   test means the test is broken, not the implementation.
+4. Produce the Test Report listing failing tests and their expected errors.
+5. Hand the failing test file path to the `implementer`.
+6. After implementation, run again and confirm PASS.
+7. Run the full suite: `make tests`
+
+### Module docstring requirement
+
+Every test file must start with a docstring explaining the multi-tenant
+constraint:
+
+```python
+"""
+Tests for {app} {feature}.
+
+NOTE: {app} models are TENANT_APP — they live in per-store schemas.
+The test runner uses the public schema, so these tables don't exist.
+All tests use SimpleTestCase + mocks.
+"""
+```
+
+---
+
+## Process
+
+1. Read the acceptance criteria from the Task Card.
+2. Write test stubs (method signatures with empty bodies) for every criterion.
+3. Implement each test.
+4. Run the suite — confirm new tests fail in the expected way (before or against
+   an incomplete implementation).
+5. After implementation is complete, run the suite again.
+6. Confirm all tests pass.
+7. Produce the Test Report.
+
+---
+
+## Regression test requirement
+
+For bug fix tasks, write at least one regression test:
+
+- The test must reproduce the original bug condition
+- The test must fail before the fix is applied (or document that it was verified
+  to fail)
+- The test must pass after the fix
+
+---
+
+## Files you may edit
+
+Only test files. The file paths depend on the project's test conventions:
+
+- Java/Kotlin: files under `src/test/`
+- TypeScript/JavaScript: files matching `*.test.ts`, `*.spec.ts`, or under
+  `__tests__/`
+- Python: files matching `test_*.py` or `*_test.py`
+- Go: files matching `*_test.go`
+
+You do not modify production source files. If a production file must change to
+make it testable (e.g., an interface must be extracted), escalate to `architect`
+via the orchestrator — do not modify it yourself.
+
+---
+
+## Output format
+
+```markdown
+## Test Report
+
+**Task**: [objective from Task Card] **Runner**: [./gradlew test | npm test |
+pytest | go test ./... | ...]
+
+**Tests Written**:
+
+- [TestClassName#methodName or describe/it path] — [what it verifies]
+- ...
+
+**Coverage by Acceptance Criterion**:
+
+- Criterion 1: [test ID that covers it] — [pass | fail]
+- Criterion 2: [test ID that covers it] — [pass | fail]
+
+**Coverage by Case Type**:
+
+- Happy path: [covered | not covered — reason]
+- Edge cases: [covered | not covered — reason]
+- Error cases: [covered | not covered — reason]
+- Regression: [covered | not applicable]
+
+**Suite Result**: [X passed, Y failed] **Failing Tests**: [list or "none"]
+```
+
+---
+
+## Hard rules
+
+- Never edit production source files.
+- Never write tests that pass trivially (testing nothing real).
+- Never skip error case coverage without documenting why.
+- Never mock real behavior that could be tested with an in-memory alternative.
+- Never declare coverage complete when any acceptance criterion lacks a test.
+- Never run `git push` or `git commit`.

package/presets/opencode/skills/auth-token-inspector/SKILL.md

@@ -0,0 +1,31 @@
+---
+id: auth-token-inspector
+version: 1.0.0
+name: Auth Token Inspector
+description: >
+  Audits token storage mechanisms to prevent XSS-based JWT theft.
+user-invokable: true
+license: MIT
+metadata:
+  author: lgzarturo
+  category: security
+compatibility:
+  tools: [claude, codex, gemini, agy, opencode]
+  stacks:
+    languages: [typescript, javascript, python, kotlin, java, php]
+---
+# Auth Token Inspector
+
+## Core Principles
+
+1. **Secure Storage**: JWTs or session tokens must NOT be stored in `localStorage` or `sessionStorage` due to vulnerability to Cross-Site Scripting (XSS).
+2. **HttpOnly Cookies**: Deliver tokens via `HttpOnly`, `Secure`, and `SameSite=Strict` (or `Lax`) cookies to protect them from client-side JS access.
+3. **Short Expiration**: Ensure access tokens have short expiration times, and implement secure, rotation-enabled refresh tokens stored in cookies.
+
+## Storage Comparison
+
+| Storage Mode | Vulnerable to XSS | Vulnerable to CSRF | Recommended |
+| :--- | :--- | :--- | :--- |
+| **localStorage** | Yes (High Risk) | No | **NO** |
+| **sessionStorage** | Yes (High Risk) | No | **NO** |
+| **HttpOnly Cookie** | No (Secure) | Yes (Mitigated via SameSite/Tokens) | **YES** |

package/presets/opencode/skills/drizzle-schema-architect/SKILL.md

@@ -0,0 +1,51 @@
+---
+id: drizzle-schema-architect
+version: 1.0.0
+name: Drizzle Schema Architect
+description: >
+  Generates strictly typed Drizzle ORM schemas for PostgreSQL with indexes, 
+  foreign keys, and Zod schema deduction.
+user-invokable: true
+license: MIT
+metadata:
+  author: lgzarturo
+  category: database
+compatibility:
+  tools: [claude, codex, gemini, agy, opencode]
+  stacks:
+    languages: [typescript, javascript]
+    frameworks: [nextjs, drizzle]
+    databases: [postgresql]
+---
+# Drizzle Schema Architect
+
+## Core Principles
+
+1. **Strict Typing**: All table columns must be explicitly typed. Do not rely on loose implicit types.
+2. **PostgreSQL Focus**: Use pg-specific column types (e.g. `pgTable`, `uuid`, `timestamp`, `varchar`, `integer`).
+3. **Zod Validation Integration**: Always output Zod schemas inferred from Drizzle schemas using `drizzle-zod`'s `createInsertSchema` and `createSelectSchema`.
+
+## Schema Guidelines
+
+- **Primary Keys**: Prefer UUIDs generated by `gen_random_uuid()` or autoincrementing integers depending on the table volume.
+- **Indices**: Declare explicit indexes on foreign key columns and query filters.
+- **Dates**: Always store timestamps using `timestamp('created_at', { withTimezone: true, mode: 'date' }).defaultNow().notNull()`.
+
+### Example Schema Pattern
+
+```typescript
+import { pgTable, uuid, varchar, timestamp, index } from 'drizzle-orm/pg-core';
+import { createInsertSchema, createSelectSchema } from 'drizzle-zod';
+
+export const users = pgTable('users', {
+  id: uuid('id').defaultRandom().primaryKey(),
+  email: varchar('email', { length: 255 }).notNull().unique(),
+  name: varchar('name', { length: 255 }),
+  createdAt: timestamp('created_at', { withTimezone: true, mode: 'date' }).defaultNow().notNull(),
+}, (table) => [
+  index('email_idx').on(table.email)
+]);
+
+export const insertUserSchema = createInsertSchema(users);
+export const selectUserSchema = createSelectSchema(users);
+```

package/presets/opencode/skills/evaluation/SKILL.md

@@ -0,0 +1,6 @@
+---
+name: evaluation
+description: Scorecard, outcomes, model profiles. Use with /cc-scorecard.
+---
+
+See `presets/claude/skills/evaluation/SKILL.md` for full evaluation workflow.

package/presets/opencode/skills/fastapi-pydantic-strict/SKILL.md

@@ -0,0 +1,44 @@
+---
+id: fastapi-pydantic-strict
+version: 1.0.0
+name: FastAPI Pydantic Strict
+description: >
+  Enforces Pydantic v2 strict models, asynchronous dependency generators, and uv environment setup.
+user-invokable: true
+license: MIT
+metadata:
+  author: lgzarturo
+  category: validation
+compatibility:
+  tools: [claude, codex, gemini, agy, opencode]
+  stacks:
+    languages: [python]
+    frameworks: [fastapi, pydantic]
+---
+# FastAPI Pydantic Strict
+
+## Core Principles
+
+1. **Pydantic v2 Model Configuration**: Always configure models with `model_config = ConfigDict(strict=True)` to enforce type correctness.
+2. **Async Dependencies**: Rely on async FastAPI dependency generators (`async def get_db()`) to handle context managers correctly.
+3. **Environment Management**: Use `uv` for lightning-fast package installs and lockfile consistency.
+
+## Code Blueprint
+
+```python
+from fastapi import FastAPI, Depends
+from pydantic import BaseModel, ConfigDict, Field
+
+app = FastAPI()
+
+class StrictUser(BaseModel):
+    model_config = ConfigDict(strict=True)
+    
+    id: int
+    name: str = Field(..., min_length=2)
+    email: str
+
+@app.post("/users", response_model=StrictUser)
+async def create_user(user: StrictUser):
+    return user
+```

package/presets/opencode/skills/jpa-nplusone-detector/SKILL.md

@@ -0,0 +1,46 @@
+---
+id: jpa-nplusone-detector
+version: 1.0.0
+name: JPA N+1 Query Detector
+description: >
+  Audits Hibernate database interactions to prevent N+1 query problems in JVM apps.
+user-invokable: true
+license: MIT
+metadata:
+  author: lgzarturo
+  category: performance
+compatibility:
+  tools: [claude, codex, gemini, agy, opencode]
+  stacks:
+    languages: [kotlin, java]
+    frameworks: [spring-boot, spring-data-jpa, hibernate]
+---
+# JPA N+1 Query Detector
+
+## Core Principles
+
+1. **Hibernate Fetches**: Avoid lazy-loading relationships within loops or stream operations.
+2. **Batch Fetching & Joins**: Resolve N+1 issues by using `@EntityGraph` or `JOIN FETCH` inside custom JPQL queries.
+3. **Hibernate Statistics**: Enable Hibernate statistics in development to verify query counts.
+
+## Remediation Patterns
+
+### Ineffective Pattern (Triggers N+1 queries)
+```kotlin
+val users = userRepository.findAll()
+for (user in users) {
+    println(user.posts.size) // Post is loaded lazily for each user
+}
+```
+
+### Remediation A: Using JOIN FETCH
+```kotlin
+@Query("SELECT u FROM User u LEFT JOIN FETCH u.posts")
+fun findAllWithPosts(): List<User>
+```
+
+### Remediation B: Using @EntityGraph
+```kotlin
+@EntityGraph(attributePaths = ["posts"])
+override fun findAll(): List<User>
+```

package/presets/opencode/skills/livewire-alpine-bridge/SKILL.md

@@ -0,0 +1,36 @@
+---
+id: livewire-alpine-bridge
+version: 1.0.0
+name: Livewire Alpine Bridge
+description: >
+  Schedules reactive frontend states cleanly using entangle directives in PHP and JS.
+user-invokable: true
+license: MIT
+metadata:
+  author: lgzarturo
+  category: frontend
+compatibility:
+  tools: [claude, codex, gemini, agy, opencode]
+  stacks:
+    languages: [php, javascript]
+    frameworks: [laravel, livewire, alpinejs]
+---
+# Livewire Alpine Bridge
+
+## Core Principles
+
+1. **State Entanglement**: Synchronize states between Livewire properties and Alpine.js states using the `@entangle` directive.
+2. **Minimize Network Roundtrips**: Handle purely UI-related reactive interactions (modals, dropdowns, tab switches) strictly in Alpine.js without sending requests to the server.
+3. **Lazy Syncing**: Use `.live` modifier selectively. Rely on `.defer` or deferred synchronization for inputs to prevent heavy server load.
+
+## Implementation Pattern
+
+```html
+<div x-data="{ open: @entangle('showModal') }">
+    <button @click="open = true">Open Modal</button>
+    
+    <div x-show="open" @click.away="open = false">
+        Modal Content
+    </div>
+</div>
+```

package/presets/opencode/skills/openspec/SKILL.md

@@ -0,0 +1,50 @@
+---
+name: openspec
+description:
+  OpenSpec backlog format, state machine, and delivery workflow for CodeConductor.
+  Use when running /cc-openspec or editing BACKLOG.md.
+---
+
+# OpenSpec / BACKLOG Skill
+
+## BACKLOG.md contract
+
+`BACKLOG.md` at repo root is the operational queue. Required sections:
+
+- `## Global` — Product, Strategy, Policy, Review required, TDD required
+- `## Items` — active backlog entries
+- `## Archive` — completed entries (do not re-execute)
+
+Each item: `### BC-001 | Short title` with Priority (P0–P3), Status, Type, Depends on, Description, Scope, Out of scope, Acceptance (measurable checklist).
+
+## Status machine
+
+`TODO` → `READY` → `PLANNED` → `IN_PROGRESS` → `REVIEW` → `DONE` → Archive
+
+`BLOCKED` can return to `READY` when resolved. Reviewer rejection: `REVIEW` → `IN_PROGRESS`.
+
+## CLI commands
+
+```bash
+npx cc-codeconductor openspec validate
+npx cc-codeconductor openspec scan
+npx cc-codeconductor openspec plan BC-001
+npx cc-codeconductor openspec status
+npx cc-codeconductor openspec next
+```
+
+## OpenSpec folders
+
+Each item generates `openspec/changes/<slug>/` with `proposal.md`, `design.md`, `tasks.md`, `specs/`.
+
+## Agent phases
+
+| Phase | Agent |
+|-------|-------|
+| discover | repo-explorer |
+| design | architect |
+| test | tester |
+| implement | implementer |
+| review | reviewer |
+
+When Global `TDD required: yes`, test runs before implement.

package/presets/opencode/skills/seo-analytics-injector/SKILL.md

@@ -0,0 +1,44 @@
+---
+id: seo-analytics-injector
+version: 1.0.0
+name: SEO Analytics Injector
+description: >
+  Verifies and injects Google Tag Manager (GTM), GA4 event triggers, and optimized meta tags.
+user-invokable: true
+license: MIT
+metadata:
+  author: lgzarturo
+  category: marketing
+compatibility:
+  tools: [claude, codex, gemini, agy, opencode]
+  stacks:
+    languages: [typescript, javascript, html]
+    frameworks: [astro, nextjs]
+---
+# SEO Analytics Injector
+
+## Core Principles
+
+1. **Meta tags**: Layouts must contain standard SEO meta tags (`title`, `description`, `robots`, `og:title`, `og:description`, `og:image`, `twitter:card`).
+2. **Analytics Integration**: Verify GTM container script is placed inside `<head>` (as high as possible) and the noscript iframe is placed immediately after the opening `<body>` tag.
+3. **Lighthouse Compatibility**: Ensure images have `width` and `height`, and interactive components have accessible descriptions.
+
+## GTM / GA4 Snippet Verification
+
+GTM Script must match:
+```html
+<!-- Google Tag Manager -->
+<script>(function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':
+new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],
+j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src=
+'https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);
+})(window,document,'script','dataLayer','GTM-XXXXXX');</script>
+<!-- End Google Tag Manager -->
+```
+ GTM Noscript must match:
+```html
+<!-- Google Tag Manager (noscript) -->
+<noscript><iframe src="https://www.googletagmanager.com/ns.html?id=GTM-XXXXXX"
+height="0" width="0" style="display:none;visibility:hidden"></iframe></noscript>
+<!-- End Google Tag Manager (noscript) -->
+```

package/presets/opencode/skills/spring-auth-auditor/SKILL.md

@@ -0,0 +1,30 @@
+---
+id: spring-auth-auditor
+version: 1.0.0
+name: Spring Auth Auditor
+description: >
+  Secures Spring Security filters, JWT validations, OAuth2 setups, and CORS/CSRF headers.
+user-invokable: true
+license: MIT
+metadata:
+  author: lgzarturo
+  category: security
+compatibility:
+  tools: [claude, codex, gemini, agy, opencode]
+  stacks:
+    languages: [kotlin, java]
+    frameworks: [spring-boot, spring-security]
+---
+# Spring Auth Auditor
+
+## Core Principles
+
+1. **Explicit Security Filters**: Define clear SecurityFilterChain configurations. Do not use default broad rules.
+2. **CORS & CSRF**: Always specify explicit CORS origins and keep CSRF protection enabled unless stateless API endpoints with JWT are explicitly verified.
+3. **No Mutations in Production**: Configurations must not mutate settings based on dev/prod environments dynamically in an unsafe manner.
+
+## Verification Checklist
+
+- Validate JWT signature, issuer, and expiration time inside `OncePerRequestFilter`.
+- Do not store JWT tokens in client-accessible localStorage. Promote Cookie-based Auth with `HttpOnly` flags.
+- Ensure that endpoints matching `/api/public/**` or similar exclusions are intentionally public.

package/presets/opencode/skills/tailwind-responsive-auditor/SKILL.md

@@ -0,0 +1,30 @@
+---
+id: tailwind-responsive-auditor
+version: 1.0.0
+name: Tailwind Responsive Auditor
+description: >
+  Audits Tailwind CSS usage ensuring mobile-first responsive utilities and clean classes.
+user-invokable: true
+license: MIT
+metadata:
+  author: lgzarturo
+  category: frontend
+compatibility:
+  tools: [claude, codex, gemini, agy, opencode]
+  stacks:
+    languages: [typescript, javascript, html]
+    frameworks: [astro, nextjs, react, tailwindcss]
+---
+# Tailwind Responsive Auditor
+
+## Core Principles
+
+1. **Mobile-First Design**: Always apply styles for mobile first (without breakpoints), then override them for larger screens (`sm:`, `md:`, `lg:`, `xl:`).
+2. **Class Deduplication**: Avoid redundant classes (e.g. `w-full w-auto` or `text-red-500 text-blue-500`).
+3. **No Arbitrary Values**: Avoid using arbitrary values like `w-[327px]` or `bg-[#f0f0f0]` unless absolutely necessary. Rely on the configured Tailwind theme.
+
+## Audit Checklist
+
+- Do not use desktop-first design (e.g., max-width utilities should be avoided unless specified).
+- Ensure that elements have responsive margins, padding, and layout flex/grid direction where needed.
+- Alert on duplicate or conflicting utility classes in component files.

package/presets/opencode/skills/tdd-mutation-tester/SKILL.md

@@ -0,0 +1,28 @@
+---
+id: tdd-mutation-tester
+version: 1.0.0
+name: TDD Mutation Tester
+description: >
+  Performs simple mutation testing to verify test coverage and assertions.
+user-invokable: true
+license: MIT
+metadata:
+  author: lgzarturo
+  category: testing
+compatibility:
+  tools: [claude, codex, gemini, agy, opencode]
+  stacks:
+    languages: [typescript, javascript, python, kotlin, java, php]
+---
+# TDD Mutation Tester
+
+## Core Principles
+
+1. **Verify Assertion Quality**: Coverage percentage can be misleading. Tests must fail when business logic changes.
+2. **Mutation Process**:
+   - Locate the core logic implemented by the `implementer`.
+   - Temporarily mutate a logical operator (e.g. swap `>` for `<`, `==` for `!=`, `+` for `-`, or invert a boolean).
+   - Run the test suite.
+   - **Expected Result**: At least one test MUST fail.
+   - **Clean Up**: Revert the mutated symbol immediately after running the test.
+3. **Scorecard**: If the test suite passes even with mutated business logic, report a "0 in Real Coverage" on the scorecard and return the task for better test assertions.

package/presets/python-data-api/agents/architect.md

@@ -0,0 +1,8 @@
+# Agent Contract: Python Architect (v1.2.0)
+
+## Misión
+Eres el agente arquitecto de Python. Diseñas soluciones de datos y APIs asíncronas de alto rendimiento.
+
+## Reglas
+1. **Estricto**: Exige la validación estricta de payloads entrantes con Pydantic v2. Invocación obligatoria de la skill `fastapi-pydantic-strict`.
+2. **Estricto**: Diseña los flujos asíncronos y conexiones a base de datos de manera limpia, evitando bloqueos de I/O de red.

package/presets/python-data-api/agents/implementer.md

@@ -0,0 +1,9 @@
+# Agent Contract: Python Implementer (v1.2.0)
+
+## Misión
+Eres el agente implementador especializado en el stack de Python (FastAPI/Django). Implementas APIs rápidas, robustas y modelos de datos fuertemente validados.
+
+## Reglas y Restricciones (Hard Constraints)
+1. **Estricto**: Todo modelo de FastAPI debe utilizar Pydantic v2 configurado con modo estricto. Invocación obligatoria de la skill `fastapi-pydantic-strict`.
+2. **Estricto**: Gestiona el entorno de desarrollo y las dependencias exclusivamente usando `uv` para asegurar consistencia del lockfile.
+3. **TDD**: Escribe pruebas unitarias e integración en pytest y confirma su correcto funcionamiento antes de dar por completada la implementación.