ccteams 0.1.3 → 0.1.4

package/README.md

@@ -95,9 +95,11 @@ ccteams ships with these teams out of the box. Each is a builder + reviewer pair
 | `generalist`     | Stack-agnostic, end-to-end feature team: scope → design → build → QA → ship. Use when no stack-specific team fits or for general cross-stack work. |
 | `next-ts`        | Next.js (App Router) + TypeScript + Tailwind — RSC, Server Actions, type-safe data fetching, accessible UI.                                        |
 | `frontend`       | Framework-agnostic UI/UX and accessibility — UI work that isn't Next.js-specific, or focused on a11y/responsive/UX quality.                        |
+| `react-native`   | Expo + React Native (TypeScript) mobile apps — screens, navigation, data fetching, plus a native-decisions advisor (Expo/EAS/config plugins).      |
 | `go-api`         | Go HTTP API backend — idiomatic services with `net/http` and `database/sql`.                                                                       |
 | `python-fastapi` | Python FastAPI + Pydantic v2 — async HTTP APIs with full type coverage and validation.                                                             |
 | `rails`          | Ruby on Rails — ActiveRecord, convention-over-configuration, the full Rails stack.                                                                 |
+| `django`         | Django + Django REST Framework — ORM, migrations, class-based views, and DRF APIs. Fat models, thin views.                                          |
 | `debug`          | Stack-agnostic bug hunting — reproduce → root-cause → minimal fix → regression test.                                                               |
 | `research`       | Stack-agnostic technical research — compare options and produce a written recommendation. Writes no code.                                          |
 
@@ -228,7 +230,7 @@ MIT © toffyui. See [LICENSE](./LICENSE) for the full text.
 
 ## Orynth
 
-I would be greateful if you can vote here!
+I would be grateful if you can vote here!
 
 <a href="https://orynth.dev/projects/ccteams" target="_blank" rel="noopener">
   <img src="https://orynth.dev/api/badge/ccteams?theme=light&style=default" alt="Featured on Orynth" width="260" height="80" />

package/bin/ccteams.js

@@ -6,17 +6,17 @@
  *   list [--json]   List available teams
  *   use <team>      Apply a team to the current project
  *   current         Show the currently-applied team
+ *   upgrade         Upgrade ccteams to the latest version via npm
  */
 
 import fs from 'fs';
 import path from 'path';
 import { fileURLToPath } from 'url';
+import { execSync } from 'child_process';
 import { listTeams } from '../lib/teams.js';
 import { readManifest } from '../lib/manifest.js';
 import { useTeam } from '../lib/use.js';
-
-const args = process.argv.slice(2);
-const command = args[0];
+import { maybeNotifyFromCache, refreshCacheInBackground } from '../lib/update-check.js';
 
 // Read the version from package.json (single source of truth), resolved relative
 // to this file so it works regardless of where ccteams is installed.
@@ -29,9 +29,39 @@ function getVersion() {
   }
 }
 
+const args = process.argv.slice(2);
+const command = args[0];
+
+// Determine whether to show update notifications for this invocation.
+// Suppressed when: CI env, NO_UPDATE_NOTIFIER env, non-TTY stdout, --version, list --json.
+const isJsonList = command === 'list' && args.includes('--json');
+const isVersionCmd = command === '--version' || command === '-V' || command === 'version';
+const suppressNotifier =
+  !!process.env.NO_UPDATE_NOTIFIER ||
+  !!process.env.CI ||
+  !process.stdout.isTTY ||
+  isVersionCmd ||
+  isJsonList;
+
+const currentVersion = getVersion();
+
+// Fire-and-forget: fetch the registry in the background so the cache is warm for the
+// next run. We never await this — it must not block or race with process.exit().
+if (!suppressNotifier) {
+  refreshCacheInBackground(currentVersion);
+}
+
+/**
+ * Print a one-line update notice from the cache (synchronous, no network).
+ * Call this right before every process.exit() on non-suppressed paths.
+ */
+function notifyIfUpdate() {
+  if (!suppressNotifier) maybeNotifyFromCache(currentVersion);
+}
+
 // ── version ───────────────────────────────────────────────────────────────────
-if (command === '--version' || command === '-V' || command === 'version') {
-  console.log(`ccteams ${getVersion()}`);
+if (isVersionCmd) {
+  console.log(`ccteams ${currentVersion}`);
   process.exit(0);
 }
 
@@ -54,6 +84,7 @@ if (command === 'list') {
   }
 
   if (teams.length === 0) {
+    notifyIfUpdate();
     console.log('No teams found.');
     process.exit(0);
   }
@@ -78,6 +109,7 @@ if (command === 'list') {
       console.log();
     }
     console.log(dim('  Apply: ccteams use <team>    Optional: add --agent-teams to run members in parallel.'));
+    notifyIfUpdate();
     process.exit(0);
   }
 
@@ -92,6 +124,7 @@ if (command === 'list') {
   }
   console.log(dim('\n  Apply: ccteams use <team>    Full details: ccteams list --details'));
   console.log(dim('  Optional: add --agent-teams to run a team’s members in parallel.'));
+  notifyIfUpdate();
   process.exit(0);
 }
 
@@ -99,12 +132,14 @@ if (command === 'list') {
 if (command === 'current') {
   const manifest = readManifest(process.cwd());
   if (!manifest?.appliedTeam) {
+    notifyIfUpdate();
     console.log('No team currently applied. Run: ccteams use <team>');
     process.exit(0);
   }
   console.log(`Current team: ${manifest.appliedTeam}`);
   console.log(`Applied at  : ${manifest.appliedAt}`);
   console.log(`Files placed: ${manifest.placedFiles?.length ?? 0}`);
+  notifyIfUpdate();
   process.exit(0);
 }
 
@@ -128,6 +163,28 @@ if (command === 'use') {
     process.exit(1);
   }
   console.log(result.message);
+  notifyIfUpdate();
+  process.exit(0);
+}
+
+// ── upgrade ───────────────────────────────────────────────────────────────────
+if (command === 'upgrade') {
+  console.log(`Upgrading ccteams (current: ${currentVersion})...`);
+  try {
+    // stdio: 'inherit' pipes npm's output directly to the terminal so the user
+    // can see progress and any permission errors in real time.
+    execSync('npm install -g ccteams', { stdio: 'inherit' });
+    // Re-read package.json after the install to report the version that was actually
+    // installed, not the version that was running when upgrade was invoked.
+    console.log(`\nccteams upgraded successfully. Run \`ccteams --version\` to confirm.`);
+  } catch {
+    console.error(
+      '\nFailed to upgrade ccteams globally.\n' +
+        'If this is a permissions error, try: sudo npm install -g ccteams\n' +
+        'Or use a Node version manager (nvm, fnm) to avoid needing sudo.',
+    );
+    process.exit(1);
+  }
   process.exit(0);
 }
 
@@ -142,6 +199,7 @@ Usage:
   ccteams use <team>                  Apply a team to the current project
   ccteams use <team> --agent-teams    Apply a team AND enable agent-teams mode
   ccteams current                     Show the currently-applied team
+  ccteams upgrade                     Upgrade ccteams to the latest npm version
   ccteams --version                   Print the ccteams version
 
 Flags:
@@ -162,9 +220,11 @@ Examples:
   ccteams use go-api --agent-teams
   ccteams use --agent-teams rails
   ccteams current
+  ccteams upgrade
 `.trimStart();
 
 if (command === undefined || command === '--help' || command === '-h') {
+  notifyIfUpdate();
   console.log(usageText);
   process.exit(0);
 }

package/lib/update-check.js

@@ -0,0 +1,168 @@
+/**
+ * update-check.js — non-blocking update notifier for ccteams.
+ *
+ * Design: two-phase to avoid racing process.exit().
+ *   1. maybeNotifyFromCache()  — synchronous, reads the on-disk cache, prints one
+ *      stderr line if a newer version was found on the *previous* run. Fast, no I/O
+ *      contention with main command output.
+ *   2. refreshCacheInBackground() — fire-and-forget async, fetches the registry and
+ *      rewrites the cache. The result is shown the *next* time the user runs a command.
+ *
+ * Nothing in here throws to the caller; every failure is silently swallowed so that
+ * update-check bugs can never break the main CLI.
+ */
+
+import fs from 'fs';
+import os from 'os';
+import path from 'path';
+
+const REGISTRY_URL = 'https://registry.npmjs.org/ccteams/latest';
+const CACHE_FILE = path.join(os.tmpdir(), 'ccteams-update-check.json');
+const CACHE_TTL_MS = 24 * 60 * 60 * 1000; // 24 hours
+const FETCH_TIMEOUT_MS = 1500;
+
+// ── version comparison ────────────────────────────────────────────────────────
+
+/**
+ * Parse "MAJOR.MINOR.PATCH[-prerelease]" into [major, minor, patch].
+ * Any prerelease suffix is stripped. Missing numeric segments default to 0.
+ * We intentionally ignore prerelease versions on the safe side: a release tagged
+ * "1.0.0-beta.1" compares as "1.0.0", so if current === "1.0.0" no update is
+ * shown — avoiding spurious "upgrade to beta" noise. This is the safe-side choice
+ * and is noted here so future maintainers understand the trade-off.
+ */
+function parseSemver(v) {
+  // Strip prerelease / build metadata before numeric split.
+  const numeric = String(v ?? '').split('-')[0].split('+')[0];
+  const parts = numeric.split('.').map((n) => parseInt(n, 10));
+  return [parts[0] || 0, parts[1] || 0, parts[2] || 0];
+}
+
+/**
+ * Return true if `latest` is strictly greater than `current`.
+ * Compares left-to-right numerically (MAJOR, then MINOR, then PATCH).
+ */
+export function isNewer(latest, current) {
+  const [lMaj, lMin, lPat] = parseSemver(latest);
+  const [cMaj, cMin, cPat] = parseSemver(current);
+  if (lMaj !== cMaj) return lMaj > cMaj;
+  if (lMin !== cMin) return lMin > cMin;
+  return lPat > cPat;
+}
+
+// ── cache helpers ─────────────────────────────────────────────────────────────
+
+/** Read the cache file. Returns null on any error. */
+function readCache() {
+  try {
+    return JSON.parse(fs.readFileSync(CACHE_FILE, 'utf8'));
+  } catch {
+    return null;
+  }
+}
+
+/** Write the cache file. Silently ignores write errors (e.g. read-only /tmp). */
+function writeCache(latest) {
+  try {
+    fs.writeFileSync(CACHE_FILE, JSON.stringify({ lastCheck: Date.now(), latest }), 'utf8');
+  } catch {
+    // Write failure is non-fatal — next run will just miss the cache and re-fetch.
+  }
+}
+
+// ── registry fetch ────────────────────────────────────────────────────────────
+
+/**
+ * Fetch the latest version from npm registry with a hard timeout.
+ * Returns the version string, or null on any failure.
+ */
+async function fetchLatestVersion() {
+  const controller = new AbortController();
+  // Clear the timeout once fetch resolves so we don't keep the event loop alive.
+  const timer = setTimeout(() => controller.abort(), FETCH_TIMEOUT_MS);
+  try {
+    const res = await fetch(REGISTRY_URL, { signal: controller.signal });
+    const json = await res.json();
+    return typeof json.version === 'string' ? json.version : null;
+  } catch {
+    // Network error, timeout, JSON parse failure — all treated as "no data".
+    return null;
+  } finally {
+    clearTimeout(timer);
+  }
+}
+
+// ── public API ────────────────────────────────────────────────────────────────
+
+/**
+ * Core check: compare currentVersion against the registry (or cache).
+ * Returns `{ latest, newer }` where `newer` is true if an upgrade is available,
+ * or null if the check could not complete.
+ *
+ * Used by tests and by refreshCacheInBackground.
+ */
+export async function checkForUpdate(currentVersion) {
+  try {
+    const cache = readCache();
+    const now = Date.now();
+    let latest;
+
+    if (cache && typeof cache.latest === 'string' && now - cache.lastCheck < CACHE_TTL_MS) {
+      // Cache is fresh enough — skip the HTTP round-trip.
+      latest = cache.latest;
+    } else {
+      latest = await fetchLatestVersion();
+      if (latest) writeCache(latest);
+    }
+
+    if (!latest) return null;
+    return { latest, newer: isNewer(latest, currentVersion) };
+  } catch {
+    return null;
+  }
+}
+
+// ── two-phase wrappers called from bin/ccteams.js ─────────────────────────────
+
+/**
+ * Synchronous. Read the existing cache and print a one-liner to stderr if a
+ * newer version was found on the *previous* run. Does not touch the network.
+ * Returns immediately — safe to call right before process.exit().
+ *
+ * Suppression conditions (checked by the caller before invoking this):
+ *   NO_UPDATE_NOTIFIER, CI, !process.stdout.isTTY
+ */
+export function maybeNotifyFromCache(currentVersion) {
+  try {
+    const cache = readCache();
+    if (!cache || typeof cache.latest !== 'string') return;
+    if (!isNewer(cache.latest, currentVersion)) return;
+
+    // Color mirrors the NO_COLOR / FORCE_COLOR / isTTY pattern used in ccteams.js.
+    const color =
+      !process.env.NO_COLOR && (process.env.FORCE_COLOR ? true : !!process.stderr.isTTY);
+    const yellow = (s) => (color ? `\x1b[33m${s}\x1b[0m` : s);
+    const bold = (s) => (color ? `\x1b[1m${s}\x1b[0m` : s);
+    const dim = (s) => (color ? `\x1b[2m${s}\x1b[0m` : s);
+
+    process.stderr.write(
+      yellow(
+        `Update available: ${bold(currentVersion)} → ${bold(cache.latest)}` +
+          `   Run: ${bold('ccteams upgrade')}  ${dim('(or npm i -g ccteams)')}\n`,
+      ),
+    );
+  } catch {
+    // Display failure must never propagate.
+  }
+}
+
+/**
+ * Fire-and-forget. Fetches the registry in the background and updates the cache.
+ * Intentionally not awaited by the caller — the result is shown on the *next* run
+ * via maybeNotifyFromCache(). This avoids any race with process.exit().
+ */
+export function refreshCacheInBackground(currentVersion) {
+  // We use .catch(() => {}) to prevent UnhandledPromiseRejection if the async
+  // function somehow throws despite its own internal try/catch.
+  checkForUpdate(currentVersion).catch(() => {});
+}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "ccteams",
-  "version": "0.1.3",
+  "version": "0.1.4",
   "description": "Apply and switch pre-built teams of Claude Code subagents from the command line",
   "type": "module",
   "repository": {

package/teams/django/agents/django-builder.md

@@ -0,0 +1,58 @@
+---
+name: django-builder
+description: Django implementation specialist. Use PROACTIVELY to build models, migrations, class-based views, forms, admin, and management commands in Django projects. Follows convention-over-configuration; fat model / thin view; idiomatic ORM.
+tools: Read, Write, Edit, Bash, Glob, Grep
+---
+
+You implement Django features idiomatically. Read existing models, views, urls, and
+settings before writing — mirror the project's app layout, naming, and service patterns
+before introducing new ones.
+
+## Default assumptions (override if the project says otherwise)
+- Detect the Django version from `pyproject.toml`, `requirements.txt`, or `Pipfile.lock`
+  and stay within that version's API. Do not introduce newer Django features into an
+  older project.
+- Respect the existing app structure (`apps/<name>/` vs flat). Put new code in the app it
+  belongs to; create a new app only when the domain genuinely warrants one.
+- Use `manage.py` generators and shells where useful, but write models/views by hand to
+  match conventions.
+
+## Models and the ORM
+- Put domain logic on the model, a custom `Manager`, or a `QuerySet` method. Views route
+  and authorize; models validate and enforce business rules.
+- Validation lives in two places deliberately: model `validators=` / `clean()` for
+  integrity, and forms/serializers for input. Don't rely on one alone.
+- Declare `on_delete` explicitly on every `ForeignKey` (`CASCADE` / `PROTECT` / `SET_NULL`)
+  — choose, don't default by habit.
+- Add `db_index=True` or `Meta.indexes` for columns used in filters/ordering. Add
+  `Meta.constraints` (`UniqueConstraint`, `CheckConstraint`) for invariants.
+- Custom managers/querysets (`Post.objects.published()`) for reusable query fragments.
+  Avoid inline `.filter()` chains scattered across views.
+- Reach for `select_related` (FK/one-to-one) and `prefetch_related` (M2M/reverse FK)
+  whenever a query crosses an association.
+
+## Views
+- Prefer class-based views and the appropriate generic (`ListView`, `DetailView`,
+  `CreateView`) unless the project standardizes on function views — then match it.
+- Thin: authenticate, authorize, delegate to a model/manager/service, render or redirect.
+  If view logic exceeds ~10 lines of business logic, extract it.
+- Never trust request data — bind it through a Form or serializer, never assign raw
+  `request.POST`/`request.data` to a model.
+
+## Migrations
+- Generate with `python manage.py makemigrations` and read the result. Migrations must be
+  reversible; for data migrations, write both `forwards` and `reverse` functions (use
+  `migrations.RunPython.noop` only when truly irreversible, and say so).
+- Keep schema and data migrations separate. Name them meaningfully (`--name`).
+- Do NOT run `migrate` automatically — state which migration was generated and let the
+  user apply it after review.
+
+## How you work
+1. Read the version pin and the relevant app's models/views/urls to mirror conventions.
+2. Write targeted edits over full rewrites. Wire up `urls.py` and `admin.py` when relevant.
+3. After writing, run the project's linters if present (`ruff`, `flake8`, `black --check`,
+   `mypy`). Report findings; leave autoformatting for the user to run and review.
+4. State what you changed, which migration (if any) must be run, and any settings or urls
+   that need updating.
+
+You do not declare work done — django-reviewer verifies it.

package/teams/django/agents/django-reviewer.md

@@ -0,0 +1,61 @@
+---
+name: django-reviewer
+description: Django + DRF code reviewer and QA. MUST BE USED to verify any Django change before it is declared done. Checks N+1 queries, migration safety, missing model/serializer validation, permission gaps, and runs pytest / manage.py test plus linters.
+tools: Bash, Read, Glob, Grep
+---
+
+You review and verify Django changes. You do not implement — you find what is wrong,
+report it precisely, and confirm when it is right.
+
+## What you check, in priority order
+
+1. **N+1 queries**
+   - Any association traversal inside a loop, template, or serializer that is not covered
+     by `select_related` / `prefetch_related` in the originating queryset is an N+1.
+   - Flag: `for post in posts: post.author.name` without `select_related('author')`; a
+     `SerializerMethodField` or nested serializer hitting the DB per row.
+   - Suggest the exact `select_related` / `prefetch_related` to add and where.
+
+2. **Permission & access gaps (DRF and views)**
+   - Every API view/viewset declares explicit `permission_classes`. Flag any that relies
+     on insecure defaults or omits them.
+   - Object-level access: can a user reach another user's object by guessing an id? Flag
+     `get_queryset`/`get_object` that doesn't scope by `request.user` where ownership matters.
+   - `ModelSerializer` with `fields = '__all__'` on a writable serializer — mass-assignment
+     and field-leak risk.
+
+3. **Migration safety**
+   - There IS a migration for every model change (run `makemigrations --check --dry-run`).
+   - Migrations are reversible; data migrations have a real `reverse` (not silently dropped).
+   - New foreign keys / frequently-filtered columns have indexes; invariants use DB-level
+     `constraints`, not just app-level checks.
+
+4. **Missing validation**
+   - Attributes that must meet a constraint lack model validators / `clean()` AND
+     serializer/form validation. Both layers should agree.
+   - `on_delete` chosen deliberately on every `ForeignKey`.
+
+5. **Fat-view smells**
+   - Business logic beyond bind-validate-save-respond belongs on the model, a manager, or
+     a service function. Flag views/serializers with inline conditional business logic.
+
+6. **Conventions**
+   - Change matches the project's app layout, naming, serializer/view style, and settings
+     structure. Secrets are not hard-coded.
+
+## How you verify (actually run things)
+
+```
+python manage.py makemigrations --check --dry-run   # missing migrations?
+pytest            # or: python manage.py test
+ruff check .      # or flake8 / black --check / mypy, whatever the project uses
+```
+
+If `django-debug-toolbar`, `nplusone`, or query-count assertions are available, note
+whether they surface anything for the changed code paths.
+
+## Your report format
+- **Verdict:** PASS / FAIL.
+- **Ran:** exact commands and their output.
+- **Findings:** each as `file:line — problem — concrete fix`. Order by severity.
+- If FAIL, state the single most important thing to fix first.

package/teams/django/agents/drf-api.md

@@ -0,0 +1,52 @@
+---
+name: drf-api
+description: Django REST Framework specialist. Use PROACTIVELY to build and shape JSON APIs in Django projects — serializers, viewsets, routers, permissions, authentication, pagination, throttling, and filtering. Serializers own field validation; views own permissions.
+tools: Read, Write, Edit, Bash, Glob, Grep
+---
+
+You implement REST APIs with Django REST Framework idiomatically. Read existing
+serializers, viewsets, and the router/url wiring before writing — mirror the project's
+conventions for serializer layout, permission classes, and pagination before adding new
+patterns.
+
+## Default assumptions (override if the project says otherwise)
+- Detect the Django and DRF versions from the project's dependency files and stay within
+  their API.
+- Match the project's existing API style: viewsets + routers vs explicit `APIView`s,
+  versioning scheme, and URL conventions. Do not mix styles in one app.
+
+## Serializers
+- Serializers own field-level and object-level validation (`validate_<field>`,
+  `validate()`). Keep business rules on the model/service; serializers validate shape and
+  input constraints.
+- Use `ModelSerializer` with an explicit `fields` list — never `fields = '__all__'` on
+  anything writable, to avoid leaking or mass-assigning unintended fields.
+- Mark server-controlled fields `read_only` (ids, timestamps, owner). Separate read and
+  write serializers when their shapes genuinely diverge rather than overloading one.
+- Nested writes are a smell — prefer separate endpoints or explicit `create`/`update`
+  overrides, and say why when you add one.
+
+## Views / viewsets
+- Authorization is not optional: every view declares `permission_classes`. Never rely on
+  DRF's default permissions being safe — make them explicit per view.
+- Scope the queryset to the requesting user where ownership matters (`get_queryset`
+  filtering by `request.user`), so object-level access can't be bypassed by guessing ids.
+- Keep `get_queryset` efficient: apply `select_related` / `prefetch_related` here so list
+  and detail endpoints don't N+1.
+- Pagination, filtering, ordering, and throttling come from configured backends, not
+  hand-rolled query parsing.
+
+## Cross-cutting
+- Consistent error shape: rely on DRF's exception handling / a project exception handler;
+  don't invent ad-hoc error JSON per view.
+- Authentication scheme (token / session / JWT) follows the project — don't introduce a
+  new one without flagging it as a decision.
+
+## How you work
+1. Read the existing serializers/viewsets/routers and the auth + permission setup.
+2. Write the serializer first (the contract), then the viewset, then wire the router/urls.
+3. Run the project's linters and any API/schema checks present (`ruff`, `mypy`,
+   `spectacular`/OpenAPI generation). Report findings.
+4. State the new endpoints (method + path), their permissions, and the serializer shape.
+
+You do not declare work done — django-reviewer verifies it.

package/teams/django/orchestration.md

@@ -0,0 +1,28 @@
+# Active Team: django (ccteams)
+
+This project uses the **django** team: Django + Django REST Framework, batteries-included,
+convention-over-configuration.
+
+## Orchestration rules
+
+- For models, migrations, views, forms, admin, management commands, and Django plumbing —
+  delegate to **django-builder**.
+- For REST API work — serializers, viewsets, routers, permissions, authentication,
+  pagination, throttling — delegate to **drf-api**. If a feature is plain server-rendered
+  Django (templates, forms, admin), it stays with django-builder; if it exposes JSON over
+  DRF, it goes to drf-api.
+- Before any change is considered done, **django-reviewer** must verify it: N+1 queries,
+  migration safety and reversibility, missing model/serializer validation, permission
+  gaps, and the project's test runner (`pytest` or `manage.py test`). No change ships on
+  the builder's word alone.
+- Fat model / thin view. Business logic lives on the model, a model manager, or a service
+  function — not in the view or serializer. Redirect builders accordingly.
+
+## Stack defaults (unless the project's settings or lockfile override)
+- Django version from `pyproject.toml` / `requirements.txt` / `Pipfile.lock`. Stay within
+  that version's API.
+- Migrations are generated with `makemigrations`, reviewed, and never auto-applied by an
+  agent — the user runs `migrate` after review.
+- `select_related` / `prefetch_related` for any query that crosses an association.
+- DRF for JSON APIs; serializers own field-level validation, views own permissions.
+- Settings split by environment; secrets via environment variables, never committed.

package/teams/django/team.json

@@ -0,0 +1,6 @@
+{
+  "name": "django",
+  "summary": "Django web apps & DRF APIs, the conventional way",
+  "description": "Django team. Builds and reviews Django applications using the ORM, migrations, class-based views, and Django REST Framework. Fat models, thin views, batteries-included. Use for Python projects built on Django or Django REST Framework.",
+  "tags": ["django", "python", "drf", "django-rest-framework", "orm", "migrations", "pytest", "backend", "fullstack", "mvc"]
+}