feat: add Django skill

[sarahxsanders]

I'm sorry to do this, but I needed a clean PR... I don't know what rebasing hell happened on the last one, this is just easier

Changes

adds a Django example project

Updated testing

consistent 4/5s, yay!

checked the code in my example file after it ran to validate, verified it against instructions we give in docs too, ran it locally, generated a bunch of PostHog events ✅

eval results as well:

I have now read all the changed files. Let me compile my evaluation report.

---

## PR Evaluation Report

### Summary
This PR adds a new Django test application (`apps/test-django`) with PostHog integration for wizard testing purposes, along with updates to the PR evaluator prompts to support Python/Django patterns and modifications to the wizard-ci utils to detect Python/Django projects.

| Files changed | Lines added | Lines removed |
|---------------|-------------|---------------|
| 24 | +906 | -6 |

### Confidence score: 4/5 👍

- **No reverse proxy configuration**: Events are sent directly to PostHog host without a reverse proxy setup to circumvent adblockers. [MEDIUM]
- **Potential PII concern with email tagging**: In `subscribe()`, the `tag('email', email)` call associates the user's email with their profile, which may be intentional but should be documented as a deliberate choice. [LOW]

---

### File changes

| Filename | Score | Description |
|----------|-------|-------------|
| `apps/test-django/.env.example` | 5/5 | Proper environment variable documentation for PostHog configuration |
| `apps/test-django/.gitignore` | 5/5 | Comprehensive Python/Django gitignore covering all common patterns |
| `apps/test-django/manage.py` | 5/5 | Standard Django manage.py with correct settings module reference |
| `apps/test-django/mysite/__init__.py` | 5/5 | Empty init file as expected |
| `apps/test-django/mysite/asgi.py` | 5/5 | Standard Django ASGI configuration |
| `apps/test-django/mysite/settings.py` | 4/5 | Good settings with PostHog config via env vars; includes PosthogContextMiddleware |
| `apps/test-django/mysite/urls.py` | 5/5 | Clean URL configuration routing to pages app |
| `apps/test-django/mysite/wsgi.py` | 5/5 | Standard Django WSGI configuration |
| `apps/test-django/pages/__init__.py` | 5/5 | Empty init file as expected |
| `apps/test-django/pages/admin.py` | 5/5 | Standard Django admin stub |
| `apps/test-django/pages/apps.py` | 5/5 | Excellent PostHog initialization in `ready()` method following Django best practices |
| `apps/test-django/pages/migrations/__init__.py` | 5/5 | Empty init file for migrations package |
| `apps/test-django/pages/models.py` | 5/5 | Standard Django models stub |
| `apps/test-django/pages/templates/pages/about.html` | 5/5 | Clean template extending base |
| `apps/test-django/pages/templates/pages/base.html` | 5/5 | Well-structured base template with navigation and styling |
| `apps/test-django/pages/templates/pages/contact.html` | 5/5 | Proper form template with CSRF protection |
| `apps/test-django/pages/templates/pages/home.html` | 5/5 | Home page with newsletter form and proper AJAX handling |
| `apps/test-django/pages/templates/pages/pricing.html` | 5/5 | Pricing page template |
| `apps/test-django/pages/tests.py` | 5/5 | Standard Django tests stub |
| `apps/test-django/pages/urls.py` | 5/5 | Clean URL patterns for pages app |
| `apps/test-django/pages/views.py` | 4/5 | Good PostHog integration using Python SDK v7+ context-based API correctly |
| `apps/test-django/requirements.txt` | 5/5 | Correct dependencies: Django, posthog, python-dotenv |
| `services/pr-evaluator/prompts/evaluation.md` | 5/5 | Good updates to support Python/Django evaluation patterns |
| `services/wizard-ci/utils.ts` | 5/5 | Proper extension to detect Django/Python projects alongside JS projects |

---

### App sanity check: 4/5 ✅

| Criteria | Result | Description |
|----------|--------|-------------|
| **App builds and runs** | Yes | Standard Django project structure that should run with `python manage.py runserver` after installing deps |
| **Preserves existing env vars & configs** | Yes | This is a new app; existing services modified minimally |
| **No syntax or type errors** | Yes | All Python files have correct syntax and imports |
| **Correct imports/exports** | Yes | PostHog imports use correct v7+ API (`new_context`, `identify_context`, `capture`, `tag`) |
| **Minimal, focused changes** | Yes | New Django test app with focused PostHog integration; service changes are targeted |

#### Issues
- **PosthogContextMiddleware dependency**: The `settings.py` includes `'posthog.integrations.django.PosthogContextMiddleware'` which requires the middleware to be available. This should work with the posthog package but needs the correct version. [LOW]

<details>
<summary><h4>Other completed criteria</h4></summary>

- Environment variables documented in `.env.example`
- Build configuration valid (requirements.txt with pinned Django version range)
- Clear, readable code throughout
- Consistent with Django patterns
- Appropriate error handling in views (form validation)
- CSRF protection properly implemented
</details>

---

### PostHog implementation: 4/5 ✅

| Criteria | Result | Description |
|----------|--------|-------------|
| **PostHog SDKs installed** | Yes | `posthog` in requirements.txt |
| **PostHog client initialized** | Yes | Initialized in `PagesConfig.ready()` via `AppConfig.ready()` pattern - correct for Django |
| **capture()** | Yes | `capture()` called for page views, form submissions, newsletter subscriptions |
| **Identify()** | Yes | `identify_context()` used within `new_context()` blocks - correct Python SDK v7+ pattern |
| **Error tracking** | No | No exception capture setup |
| **Reverse proxy** | No | No reverse proxy configuration to circumvent adblockers |

#### Issues
- **No exception/error tracking**: The integration doesn't capture Python exceptions to PostHog. Consider adding a middleware or decorator to capture server-side errors. [MEDIUM]
- **No reverse proxy setup**: Events are sent directly to `us.i.posthog.com`. For production use, a reverse proxy should be configured to bypass adblockers. [MEDIUM]

<details>
<summary><h4>Other completed criteria</h4></summary>

- API key via environment variable (`POSTHOG_API_KEY`)
- Correct API host configuration (`POSTHOG_HOST`)
- Debug mode enabled in development
- Disable flag available (`POSTHOG_DISABLED`)
- Django middleware for PostHog context included
- Proper context management with `new_context()` blocks
</details>

---

### PostHog insights and events: 4/5 ✅

| Filename | PostHog events | Description |
|----------|-----------------|-------------|
| `pages/views.py` | `page_viewed` | Tracks page views for home, about, contact, pricing with `page_name` and `path` properties |
| `pages/views.py` | `contact_form_submitted` | Tracks successful contact form submissions with `has_email` and `message_length` |
| `pages/views.py` | `contact_form_error` | Tracks form validation errors with `missing_name`, `missing_email`, `missing_message` flags |
| `pages/views.py` | `newsletter_subscribed` | Tracks newsletter subscriptions with `source` property and associates email with user via `tag()` |
| `pages/views.py` | `newsletter_subscription_failed` | Tracks failed subscription attempts with `reason` |

#### Issues
- **Missing button click tracking**: Multiple CTA buttons on templates (e.g., "Try Now", "View Demo", "Start Pro Trial") are not tracked. These would provide valuable funnel insights. [MEDIUM]
- **No pricing tier selection tracking**: When users click pricing tier buttons, no events are captured to understand pricing page conversion. [LOW]

<details>
<summary><h4>Other completed criteria</h4></summary>

- Events represent real user actions (form submissions, page views, newsletter signup)
- Events enriched with relevant properties (page_name, path, message_length)
- No PII in event properties (email only used for user tagging, not in event properties)
- Events can build funnels: page_viewed → contact_form_submitted or newsletter_subscribed
</details>

---

Reviewed by wizard workbench PR evaluator

[github-actions]

🧙 Wizard CI

Run the Wizard CI and test your changes against wizard-workbench example apps by replying with a GitHub comment using one of the following commands:

Test all apps:

• /wizard-ci all

Test all apps in a directory:

• /wizard-ci next-js
• /wizard-ci react-router

Test an individual app:

• /wizard-ci next-js/15-app-router-saas
• /wizard-ci next-js/15-app-router-todo
• /wizard-ci next-js/15-pages-router-saas

Show more apps

• /wizard-ci next-js/15-pages-router-todo
• /wizard-ci react-router/react-router-v7-project
• /wizard-ci react-router/rrv7-starter
• /wizard-ci react-router/saas-template
• /wizard-ci react-router/shopper

Results will be posted here when complete.

[daniloc]

All good. nice! That skill package looks legit. how is it performing in integrations?

[sarahxsanders]

All good. nice! That skill package looks legit. how is it performing in integrations?

okie dokie, I did one last commandments tweak after a run went so-so

details in the test section in the PR description :)

[edwinyjlim]

i'm getting a serialized error in the SKILLS.md file, probably some string conversion

[edwinyjlim]

This refers to the posthog-js SDK. I wonder if we should remove or tweak in case we confuse the agent. This context would only strictly make sense if the codebase is a monorepo with python + js, which is unlikely

[edwinyjlim]

on a broader note: now that we're packaging skills at the framework level, which I think is the right move, should we be including the core SDK docs into the /references directory of the skill?

skills/
  django/
    references/
      *python-sdk-docs.md* (core SDK docs)
      django.md (framework docs)
      EXAMPLE.md
      identify-users.md
      basic-integration-begin.md
      basic-integration-edit.md
      ...
    SKILL.md
  next-js/
    references/
      *posthog-js-docs.md* (core SDK docs)
      *posthog-node-docs.md* (core SDK docs)
      nextjs.md (framework docs)
      EXAMPLE.md
      identify-users.md
      basic-integration-begin.md
      basic-integration-edit.md
      ...
    SKILL.md

With progressive disclosure, I don't see the downside. And if we're leaving the skill behind, the developer will need to work with the core language SDK after the wizard has provided the initial PostHog setup in the framework.

[sarahxsanders]

This refers to the posthog-js SDK. I wonder if we should remove or tweak in case we confuse the agent. This context would only strictly make sense if the codebase is a monorepo with python + js, which is unlikely

oooooo great flag. I feel like making this more general and relying on commandments and skills for specifics is best

edit: going to test in follow up