odoo-implement

Files (1)

• SKILL.md

SKILL.md (first lines)

# Odoo Implement (Phase 1 — Vibe Coding)

Implement an Odoo feature from proposal to working deployment.

This skill:
1. Sets up the worktree environment
2. Creates a proposal (via `openspec-propose`)
3. Implements all tasks (via `openspec-apply-change`)
4. Deploys and smoke-tests the result
5. Asks the user to verify
6. Handles bug-fix prompts in a tight fix → deploy → verify loop

**Phase 1 goal:** Working code, deployed and verifiable. Fast iteration.
**No translations, no coverage gates, no fresh rebuild.**
Those are Phase 2 (`/odoo-harden`) concerns.

---

## Before You Begin

Read the Phase 1 coding reference:

```
~/.config/opencode/odoo/reference-phase1.md
```

This contains:
- Deployment cycle commands (upgrade / restart / smoke)
- Standard mixins and widgets to use proactively
- OCA coding standards, class structure, naming conventions
- Test patterns, module structure, infrastructure conventions

---

## Workflow

### Phase 0: Worktree Setup

```
skill({ name: "odoo-worktree-setup" })
```

Ensures container, database, Caddy routing, and env vars are correct.
No-op if not a worktree.

### Phase 0.5: Guidelines Reference

Load the house rules skill:

```
skill({ name: "odoo-guidelines" })
```

Provides module structure, manifest, Python/ORM, fields, controllers, XML views and data, QWeb reports, access rights, performance, and tests conventions. Apply this knowledge throughout Phase 2 implementation — do **not** mix conventions from different versions.

### Phase 1: Proposal

```
skill({ name: "openspec-propose" })
```

Creates:
- `proposal.md` — what and why
- `design.md` — technical approach
- `tasks.md` — implementation checklist

### Phase 2: Implementation

```
skill({ name: "openspec-apply-change" })
```

Work through all tasks, marking complete as you go.

While implementing, proactively apply patterns from two sources:

1. **Guidelines skill** (loaded in Phase 0.5) — consult for ORM API, view syntax, field types, security, OWL patterns, and house rules.
2. **`reference-phase1.md`** — deployment cycle, mixins, widgets, OCA standards, module structure, code correctness checklist.

Key checklist items (from reference-phase1.md):
- Use standard mixins instead of reimplementing (check `~/shared/odoo-src/<version>/`)
- Use standard widgets instead of custom JS
- Follow class structure, naming conventions, XML standards
- Apply the key code correctness checklist (ensure_one, model_create_multi, index, etc.)

Following these patterns now avoids major refactoring in Phase 2.

### Phase 3: Deployment

When all tasks are `[x]`, run the deployment cycle once:

```
skill: run the deployment cycle from reference-phase1.md
```

**Do not run the deployment cycle between individual tasks** — complete all tasks
first, then deploy.

### Phase 4: Phase 1 Definition of Done

After a green smoke test, verify:

1. **All tasks `[x]`** in `tasks.md`
2. **Module installs without errors:**
   ```bash
   docker exec <CONTAINER> odoo -c /etc/odoo/odoo.conf -d <DB> -i <module> --stop-after-init
   ```
3. **Existing tests pass:**
   ```bash
   make test
   # or: docker run ... odoo -d test_<module>_$(date +%s) -i <module> --test-enable --test-tags=/<module> --stop-after-init --http-port=18069
   ```
   No coverage gate. No new test requirement. Just verify nothing is broken.
4. **Smoke test green** (login 200, assets 200)

Then report to the user:

```
## Phase 1 Complete

From sozialinfo/opencode, MIT.

More from sozialinfo/opencode