devcouncil 0.1.0 → 0.2.0

package/src/devcouncil/skills/library/README.md

@@ -0,0 +1,46 @@
+# DevCouncil skills library
+
+Each `*.md` file here (except this README) is a **skill**: reusable guidance that
+DevCouncil selects for a goal/repo, embeds into `dev prompt` output, and scaffolds
+into a target repo's `.claude/skills/<name>/SKILL.md`.
+
+A skill is a markdown file with YAML frontmatter:
+
+```markdown
+---
+name: my-domain            # required — unique slug; files without a name are ignored
+title: My Domain Intake    # optional human title
+description: One-line directive shown in `dev skills` and embedded into prompts.
+always: false              # true = always selected (only core-engineering uses this)
+triggers:                  # how this skill is auto-selected (omit for always-on)
+  keywords: [foo, bar]     # matched against the goal text (case-insensitive substring)
+  globs: ["*.foo", "build.bar"]   # matched against repo file basenames
+---
+
+# Body
+
+The full guidance the agent reads. For domain skills, write a "senior-dev intake":
+what current versions, deprecations, recommended libraries, official guidelines, and
+CLI/build tools to confirm *before* writing code.
+```
+
+## Adding a skill
+
+1. Create `<name>.md` with the frontmatter above.
+2. Choose triggers: `keywords` (goal text) and/or `globs` (repo files). Both are ORed.
+3. Verify: `dev skills` lists it; `dev skills show <name>` prints it.
+
+Selection is keyword-based inside `dev prompt` (fast, no repo walk) and
+keyword-plus-file-based for `dev skills` / `dev skills scaffold` / init scaffolding.
+Keep `description` actionable — it is what the agent sees inline in the task prompt.
+
+## Repo-local skills
+
+You don't have to edit this packaged library to add a skill. Drop your own
+`SKILL.md` (same frontmatter) into a project's **`.claude/skills/<name>/SKILL.md`**
+(or `.devcouncil/skills/*.md`) and DevCouncil discovers it automatically — it shows
+up in `dev skills` (source `repo`), participates in selection, and is folded into the
+codebase-aware prompt enhancer and the task prompts. A repo-local skill **overrides a
+packaged skill with the same name**, so a team can keep its own house rules for
+`android`/`web`/etc. Give it `triggers` (or `always: true`) if you want it
+auto-selected; without triggers it stays available but dormant.

package/src/devcouncil/skills/library/ai-training.md

@@ -0,0 +1,50 @@
+---
+name: ai-training
+title: AI / ML Model Training Intake
+description: Before writing model-training code, retrieve current framework versions, hardware/driver constraints, deprecations, dataset/eval practices, and the right tooling — like a senior ML engineer.
+triggers:
+  keywords: [train, training, model, pytorch, torch, tensorflow, keras, jax, huggingface, transformers, finetune, "fine-tune", dataset, llm, ml, cuda, embedding]
+  globs: ["*.ipynb", "train.py", "trainer.py", "requirements.txt", "environment.yml", "pyproject.toml", "accelerate*.yaml", "deepspeed*.json"]
+---
+
+# AI / ML Model Training Intake
+
+Do this **before** writing or changing model-training code. Frameworks, hardware
+drivers, and recommended recipes change frequently, and silent version mismatches
+waste expensive compute. Confirm against the framework docs and the project's
+environment files.
+
+## Establish current state first
+
+1. **Framework & environment** — read `requirements.txt` / `environment.yml` /
+   `pyproject.toml`: the framework (PyTorch, TensorFlow/Keras, JAX, Hugging Face
+   `transformers`/`accelerate`/`peft`), its version, Python version, and the
+   CUDA/cuDNN/ROCm requirement. Match the existing stack.
+2. **Hardware & precision** — available accelerators (GPU/TPU), memory budget, and
+   the precision strategy (fp32/fp16/bf16, mixed precision, quantization). Confirm the
+   training approach fits the hardware (single-GPU vs distributed: DDP/FSDP/DeepSpeed).
+3. **Deprecations & API shifts** — note moved/renamed APIs (e.g. `transformers`
+   trainer/argument changes, optimizer/scheduler APIs, dataset loaders) and avoid
+   patterns deprecated in the installed version.
+4. **Recommended practices** — reproducibility (seed, deterministic flags, pinned
+   versions), data pipeline (streaming vs in-memory, tokenization), checkpointing and
+   resume, and evaluation (held-out split, the metric that actually matters, no leakage
+   between train/val/test).
+5. **Cost & safety** — estimate compute/time before launching long runs; log metrics
+   (Weights & Biases / TensorBoard) and checkpoint so a crash isn't a total loss.
+
+## Tools
+
+- `python`/`accelerate launch`/`torchrun` for training entry points.
+- Experiment tracking (W&B, MLflow, TensorBoard) and `nvidia-smi` for GPU monitoring.
+- `datasets`/`dvc` for data, and a pinned environment (`uv`/`conda`/`pip-tools`).
+
+## What to record before coding
+
+- Framework + version, Python + CUDA versions, and the hardware/precision plan.
+- Deprecated APIs to avoid and their current replacements.
+- How the run is validated: the eval split, the metric, the checkpoint cadence, and a
+  short smoke run (a few steps) before the full training job.
+
+Start with a tiny smoke run to validate the pipeline end-to-end before committing to a
+long, expensive training run.

package/src/devcouncil/skills/library/android.md

@@ -0,0 +1,50 @@
+---
+name: android
+title: Android App Development Intake
+description: Before writing Android code, retrieve current SDK/AGP/Kotlin/Compose versions, platform behavior changes, deprecations, recommended Jetpack libraries, and the right CLI/build tools — like a senior Android engineer briefing themselves.
+triggers:
+  keywords: [android, kotlin, jetpack, compose, gradle, agp, apk, aab, espresso, room, hilt]
+  globs: ["build.gradle", "build.gradle.kts", "settings.gradle", "settings.gradle.kts", "AndroidManifest.xml", "*.kt", "gradle/libs.versions.toml"]
+---
+
+# Android App Development Intake
+
+Do this **before** writing or changing Android code. Don't rely on training data —
+Android moves fast and the answer that was right a year ago is often deprecated.
+Confirm against `developer.android.com`, the AGP/Kotlin/Compose release notes, and
+the project's own version catalog.
+
+## Establish current state first
+
+1. **Toolchain versions in use** — read `gradle/libs.versions.toml`, `build.gradle[.kts]`,
+   and `gradle-wrapper.properties`: `compileSdk` / `targetSdk` / `minSdk`, Android
+   Gradle Plugin (AGP), Kotlin, Gradle, Jetpack Compose / Compose Compiler, and core
+   Jetpack libraries.
+2. **Latest platform & API level** — current stable Android release, its behavior
+   changes, and the newest `targetSdk` Google Play will require. Note anything that
+   affects this task.
+3. **Deprecations & removals** — APIs deprecated or removed between the project's
+   `targetSdk` and current (e.g. background-execution limits, storage/scoped-storage
+   changes, notification/permission model, `AsyncTask`, `onBackPressed`, implicit
+   intents). List the ones this change touches and their replacements.
+4. **Recommended libraries** — prefer current Jetpack: Compose (+ adaptive layouts),
+   Navigation, Room, WorkManager, Hilt, DataStore (not SharedPreferences for new code),
+   Lifecycle/ViewModel. Confirm the recommended artifact and version.
+5. **Guidelines** — Material 3, adaptive/large-screen & foldable support, edge-to-edge,
+   the runtime permission model, and predictive back.
+
+## Build & CLI tools
+
+- `gradlew`/`gradlew.bat` for builds; `adb` for device/log work; `R8` for shrink/obfuscate.
+- The `android` command-line tool and `sdkmanager`/`avdmanager` for SDK and emulator setup.
+- Android Studio for profiling (Perfetto traces) and Compose preview.
+
+## What to record before coding
+
+- Effective `minSdk`/`targetSdk` and the version catalog entries you will use.
+- Deprecated APIs to avoid and their modern replacements, with migration steps.
+- The build/test commands you will run (`gradlew :app:assembleDebug`, `:app:testDebugUnitTest`,
+  connected/instrumented tests) so the change is verifiable.
+
+If the project mixes Views and Compose, match the file you're editing; don't migrate
+unrelated screens as a side effect (see the surgical-changes rule in core-engineering).

package/src/devcouncil/skills/library/backend.md

@@ -0,0 +1,52 @@
+---
+name: backend
+title: Backend / API / Services Intake
+description: Before writing server-side code, retrieve current framework and runtime versions, security and auth guidance, database/migration tooling, and the right CLI/build/test commands — like a senior backend engineer briefing themselves on the stack.
+triggers:
+  keywords: [backend, server, api, rest, grpc, graphql, microservice, fastapi, django, flask, starlette, express, nestjs, rails, spring, laravel, gin, fiber, echo, axum, actix, sqlalchemy, alembic, prisma, postgres, postgresql, mysql, sqlite, redis, mongodb, celery, rabbitmq, kafka, docker, kubernetes, migration, webhook, jwt, oauth]
+  globs: ["manage.py", "wsgi.py", "asgi.py", "alembic.ini", "Dockerfile", "docker-compose.yml", "docker-compose.yaml", "go.mod", "Cargo.toml", "*.proto", "Gemfile", "Procfile", "main.go", "openapi.yaml", "openapi.json"]
+---
+
+# Backend / API / Services Intake
+
+Do this **before** writing or changing server-side code. Don't rely on training data —
+frameworks, runtimes, and security guidance change, and a pattern that was fine a year
+ago may now be deprecated or insecure. Confirm against the framework's current docs and
+release notes, and against the project's own dependency manifests.
+
+## Establish current state first
+
+1. **Runtime & framework versions in use** — read the dependency manifest
+   (`pyproject.toml`/`requirements.txt`, `package.json`, `go.mod`, `Cargo.toml`, `Gemfile`,
+   `pom.xml`) and any lockfile: language runtime version, web framework (FastAPI/Django/
+   Flask/Express/NestJS/Gin/Axum/Spring/Rails), and ORM/data layer. Match what's already there.
+2. **Current stable versions & deprecations** — the framework's latest stable release and
+   anything deprecated/removed between the project's version and current (routing, lifecycle
+   hooks, settings, async APIs). List the ones this change touches and their replacements.
+3. **Data & migrations** — how schema changes are managed (Alembic, Django migrations,
+   Prisma Migrate, golang-migrate). Never hand-edit schema without a migration; generate one
+   and confirm it runs forward and back.
+4. **Security & correctness** — input validation, authn/authz on every new endpoint, secrets
+   from config/env (never hard-coded), parameterized queries (no string-built SQL), safe
+   defaults for CORS/headers, and rate limits where relevant. Check the framework's current
+   security guidance for the version in use.
+5. **Contracts** — if there's an API schema (OpenAPI, `.proto`, GraphQL SDL), update it with
+   the change and keep it the source of truth; note backward-compatibility for existing clients.
+
+## Build & CLI tools
+
+- Run/serve and migrate via the project's tooling: `uvicorn`/`gunicorn`, `python manage.py`,
+  `npm run`/`pnpm`, `go run`/`go build`, `cargo run`/`cargo build`, `rails`, `./gradlew`.
+- Tests: `pytest`, `go test ./...`, `cargo test`, `npm test`, `python manage.py test` — prefer
+  the command the repo already uses so the change is verifiable.
+- Containers: `docker build` / `docker compose up` when the service is containerized.
+
+## What to record before coding
+
+- The runtime/framework versions and the exact dependencies you will use.
+- Deprecated APIs to avoid and their modern replacements, with migration steps.
+- Any new migration to generate, and the auth/validation each new endpoint enforces.
+- The build/test commands you will run so the change is provably correct.
+
+Don't broaden the change beyond the task — no incidental framework upgrades or schema
+churn on unrelated tables (see the surgical-changes rule in core-engineering).

package/src/devcouncil/skills/library/core-engineering.md

@@ -0,0 +1,95 @@
+---
+name: core-engineering
+title: Core Engineering Discipline
+description: Always-on coding discipline for AI agents — think before coding, keep it simple, edit surgically, drive to a verifiable goal, and communicate like a senior engineer.
+always: true
+source: Merged from Andrej Karpathy's LLM coding guidelines and the Claude Fable 5 behavioral framework, distilled for DevCouncil-orchestrated coding work.
+---
+
+# Core Engineering Discipline
+
+This is the baseline contract for any change you make in this repository. It is
+always in effect. The four principles come from Andrej Karpathy's observations
+about how LLMs write code; the communication and honesty rules come from the
+Claude Fable 5 framework. Together they describe how a senior engineer works.
+
+## 1. Think before coding
+
+Most bad LLM changes come from a wrong assumption made silently. Before writing
+code:
+
+- State the assumptions your solution depends on. If any are uncertain, surface
+  them instead of guessing.
+- Read the surrounding code first. Match its existing patterns, naming, and
+  conventions rather than importing your own.
+- If the request is ambiguous or has real tradeoffs, name them and recommend one
+  path — don't quietly pick one and hide the choice.
+- Verify facts against the current codebase and current documentation, not from
+  memory. Library APIs, framework defaults, and best practices change; confirm
+  before relying on them. (For platform-specific work, the matching domain skill
+  tells you exactly what to confirm.)
+
+## 2. Simplicity first
+
+Write the minimal code that solves the stated problem.
+
+- No speculative features, options, or abstractions for requirements that don't
+  exist yet. Do the simplest thing that works well.
+- Don't add error handling, fallbacks, or validation for situations that cannot
+  occur. Trust internal code and framework guarantees; validate only at real
+  boundaries (user input, external APIs).
+- Prefer a direct implementation over a clever or layered one. If you introduce
+  an abstraction, be able to justify why the direct version was insufficient.
+- No feature flags or backwards-compatibility shims when you can just change the
+  code.
+
+## 3. Surgical changes
+
+Change only what the task requires.
+
+- Touch the smallest set of lines that accomplishes the goal. Leave unrelated
+  code alone, even if you would have written it differently.
+- Do not reformat, rename, or refactor code orthogonal to the task. Those are
+  separate changes with their own review.
+- Preserve the existing style of each file you edit. Your diff should read like
+  the person who wrote the file made it.
+- A bug fix does not need surrounding cleanup. A one-line change should produce a
+  one-line diff.
+
+## 4. Goal-driven execution
+
+Define what "done and correct" means before you start, then prove it.
+
+- Write down the verifiable success criteria. In DevCouncil terms, these are the
+  acceptance checks and the tests that must pass.
+- Prefer a tests-first loop: establish how you will check the work, make the
+  change, then run the check and iterate until it passes.
+- Verify against evidence, not vibes. Run the tests, read the output, and only
+  then claim success.
+
+## Communication & honesty (how you report the work)
+
+- **Lead with the outcome.** Your first sentence should answer "what happened" or
+  "what did you find." Supporting detail comes after.
+- **Be clear over terse.** Use plain, complete sentences. Avoid arrow-chains
+  (`A → B → fails`), stacked jargon, and invented shorthand. If you must choose
+  between short and clear, choose clear.
+- **Don't over-format.** Use prose by default; reach for lists or tables only
+  when they genuinely aid scanning. Skip decorative bolding and meta-commentary.
+- **Own mistakes plainly,** without excessive apology, and correct course.
+- **Ground every progress claim in evidence** from this session. If tests fail,
+  say so with the output. If a step was skipped, say that. If something is done
+  and verified, state it plainly without hedging. Never report success you have
+  not observed.
+- **Respect scope.** When the user is describing a problem, asking a question, or
+  thinking out loud, the deliverable is your assessment — report it and stop;
+  don't apply a fix until asked. For reversible actions clearly implied by the
+  request, proceed; for destructive or out-of-scope actions, confirm first.
+
+## Before you reach for more capability
+
+Check whether a relevant skill, helper, or existing convention already covers
+the task before writing new code or pulling in a new dependency. Use the matching
+domain skill (Android, iOS, Windows, web, AI training, …) to load current,
+platform-specific guidance the way a senior engineer would brief themselves
+before starting.

package/src/devcouncil/skills/library/data-engineering.md

@@ -0,0 +1,47 @@
+---
+name: data-engineering
+title: Data Engineering / Pipelines / Warehouses Intake
+description: Before changing data pipelines, transformations, or warehouse models, retrieve current engine/tool versions, schema and partitioning conventions, idempotency and backfill guidance, and the right run/test CLI commands — like a senior data engineer briefing themselves.
+triggers:
+  keywords: [etl, elt, "data pipeline", "data engineering", airflow, dagster, prefect, dbt, spark, pyspark, flink, beam, snowflake, bigquery, redshift, databricks, "data warehouse", "data lake", lakehouse, iceberg, "delta lake", parquet, partition, backfill, ingestion]
+  globs: ["dbt_project.yml", "profiles.yml", "airflow.cfg", "dagster.yaml", "*.dbt", "dbt_packages", "great_expectations.yml", "*.avsc"]
+---
+
+# Data Engineering / Pipelines / Warehouses Intake
+
+Do this **before** changing pipelines, transformations, or warehouse models. Don't rely on
+training data — engines, SQL dialects, and orchestration APIs change, and a careless change
+can silently corrupt data or break downstream consumers. Confirm against the engine/tool's
+current docs and the project's own conventions.
+
+## Establish current state first
+
+1. **Engine & tool versions in use** — read the manifests (`dbt_project.yml`, `requirements`,
+   cluster/runtime config): orchestrator (Airflow/Dagster/Prefect), transform tool (dbt/Spark),
+   warehouse/engine (Snowflake/BigQuery/Redshift/Databricks) and its SQL dialect. Match them.
+2. **Schema, contracts & lineage** — the tables/models this touches, their schema, primary/unique
+   keys, and the downstream consumers (BI, models, other DAGs). A column rename or type change is
+   a breaking contract — coordinate it and update the dependents.
+3. **Idempotency & partitioning** — pipelines must be safe to re-run: idempotent writes
+   (MERGE/upsert, partition overwrite), correct partition/cluster keys, and no duplicate or
+   out-of-order side effects. Confirm how backfills are run and bounded.
+4. **Data quality** — null/uniqueness/referential tests, row-count and freshness checks, and
+   what happens on failure (block vs warn). Add or update tests for the change.
+5. **Cost & scale** — scan/partition pruning, avoid full-table rewrites, and watch warehouse
+   compute/credits for big backfills.
+
+## Build & CLI tools
+
+- `dbt run`/`dbt test`/`dbt build` (with `--select` to scope), `airflow dags test`/`tasks test`,
+  `dagster job execute`, `spark-submit`/`pyspark`. Prefer the project's wrapper/Makefile.
+- Validate transforms on a dev schema/sample before touching production datasets.
+
+## What to record before coding
+
+- The engine/dialect and the exact models/DAGs you will change.
+- Schema/contract changes and the downstream consumers to coordinate with.
+- The idempotency/partition strategy and how a backfill will be scoped and rolled back.
+- The `dbt test`/DAG-test/data-quality commands that prove the change is correct.
+
+Don't broaden the change beyond the task — no incidental model refactors or schema churn on
+unrelated tables (see the surgical-changes rule in core-engineering).

package/src/devcouncil/skills/library/desktop.md

@@ -0,0 +1,46 @@
+---
+name: desktop
+title: Cross-Platform Desktop (Electron / Tauri / Qt) Intake
+description: Before changing desktop-app code, retrieve current framework versions, the process/IPC and security model, packaging/auto-update guidance, and the right build/run CLI commands across OSes — like a senior desktop engineer briefing themselves.
+triggers:
+  keywords: [electron, tauri, qt, qml, gtk, wxwidgets, "desktop app", "system tray", ipc, "main process", "renderer process", webview, "auto-update", "code signing", notarization]
+  globs: ["tauri.conf.json", "*.qml", "*.pro", "CMakeLists.txt.user", "electron-builder.yml", "electron-builder.json", "forge.config.js", "*.desktop"]
+---
+
+# Cross-Platform Desktop (Electron / Tauri / Qt) Intake
+
+Do this **before** writing or changing desktop-app code. Don't rely on training data — these
+frameworks change their process and security models, and a desktop app must build, sign, and
+behave correctly across Windows, macOS, and Linux. Confirm against the framework's current docs
+and the project's own pinned versions.
+
+## Establish current state first
+
+1. **Framework & version in use** — Electron (version, `package.json`), Tauri (`tauri.conf.json`,
+   Rust + WebView2/WKWebView), or Qt (version, Widgets vs QML). Match what's there.
+2. **Process & IPC model** — main/renderer (Electron) or core/WebView (Tauri) boundaries, and the
+   IPC surface. Keep the boundary explicit; validate everything crossing it.
+3. **Security** — Electron: `contextIsolation` on, `nodeIntegration` off, a `contextBridge`
+   preload, and a strict CSP; Tauri: the allowlist/capabilities scoped to the minimum. Never
+   expose Node/shell/filesystem broadly to the renderer; treat loaded web content as untrusted.
+4. **Platform integration** — file dialogs, tray, notifications, menus, deep links, and
+   permissions differ per OS. Implement and test the ones this change touches on each target.
+5. **Packaging & updates** — code signing (Windows Authenticode, macOS notarization), the
+   installer format, and the auto-update channel. A change can silently break signing or updates.
+
+## Build & CLI tools
+
+- Electron: `npm`/`pnpm` scripts, `electron .`, `electron-builder`/`electron-forge make`, Spectron/
+  Playwright for e2e.
+- Tauri: `cargo tauri dev`/`cargo tauri build`, plus the frontend's own build.
+- Qt: `qmake`/`cmake` + `make`/`ninja`, `windeployqt`/`macdeployqt`, `ctest`.
+
+## What to record before coding
+
+- The framework + version and the OS targets you must support.
+- The IPC surface touched and the security settings (isolation/allowlist/CSP) that must hold.
+- The platform-integration features changed and how they're tested per OS.
+- The build/sign/package commands and tests that prove the change works and still ships.
+
+Don't broaden the change beyond the task — no incidental framework upgrades or weakening the
+security model for convenience (see the surgical-changes rule in core-engineering).

package/src/devcouncil/skills/library/devops.md

@@ -0,0 +1,48 @@
+---
+name: devops
+title: DevOps / Infrastructure-as-Code / CI-CD Intake
+description: Before changing infrastructure, pipelines, or deployment config, retrieve current provider/tool versions, security and least-privilege guidance, state/secret handling, and the right plan/apply CLI commands — like a senior platform engineer briefing themselves.
+triggers:
+  keywords: [devops, terraform, opentofu, kubernetes, helm, kustomize, ansible, pulumi, cloudformation, bicep, gitops, argocd, infrastructure, "infrastructure as code", iac, provisioning, deployment, "ci/cd", cicd, jenkins, "github actions", iam, "least privilege"]
+  globs: ["*.tf", "*.tfvars", "Chart.yaml", "kustomization.yaml", "kustomization.yml", "Jenkinsfile", "*.bicep", "playbook.yml", "ansible.cfg", "skaffold.yaml", "argocd*.yaml", "*.hcl"]
+---
+
+# DevOps / Infrastructure-as-Code / CI-CD Intake
+
+Do this **before** changing infrastructure, pipelines, or deployment config. Don't rely
+on training data — providers, modules, and runner images change fast, and an insecure or
+deprecated default can be costly. Confirm against the provider/tool's current docs and the
+project's own pinned versions and state.
+
+## Establish current state first
+
+1. **Tool & provider versions in use** — read the version pins (`required_version`,
+   `required_providers`, `Chart.yaml`/`appVersion`, action `uses: @vX`, runner image,
+   k8s API versions) and any lockfile (`.terraform.lock.hcl`). Match what's already there.
+2. **State & backends** — where state lives (remote backend, workspace, locking). Never run
+   a destructive `apply`/`destroy` blindly; read the plan first and understand what changes.
+3. **Deprecations & breaking changes** — between the pinned versions and current (provider
+   resource renames, removed k8s APIs, deprecated action inputs, runner image changes). List
+   the ones this change touches and their replacements.
+4. **Security & least privilege** — IAM/roles scoped to the minimum needed, no wildcard
+   permissions, secrets from a vault/secret store (never committed), network/ingress locked
+   down, and encrypted state/storage. Check the provider's current security guidance.
+5. **Blast radius** — what this change can take down (shared modules, prod vs staging
+   workspace, a pipeline that gates deploys). Prefer a dry run / plan and a staged rollout.
+
+## Build & CLI tools
+
+- `terraform`/`tofu plan|apply`, `kubectl`/`helm`/`kustomize`, `ansible-playbook --check`,
+  `pulumi preview`, `aws`/`gcloud`/`az` CLIs — use the project's wrapper/Makefile if present.
+- Validate before applying: `terraform validate`/`fmt`, `helm lint`/`template`, `kubeval`,
+  `actionlint`, and a CI dry run.
+
+## What to record before coding
+
+- The pinned versions and provider/module sources you will use.
+- Deprecated resources/APIs to avoid and their replacements, with migration steps.
+- The plan/preview output and the blast radius, plus how you'll roll back.
+- The validate/plan commands that prove the change is safe before apply.
+
+Don't broaden the change beyond the task — no incidental provider upgrades or touching
+unrelated modules/environments (see the surgical-changes rule in core-engineering).

package/src/devcouncil/skills/library/game-dev.md

@@ -0,0 +1,46 @@
+---
+name: game-dev
+title: Game Development (Unity / Unreal / Godot) Intake
+description: Before changing game code, retrieve current engine versions, the frame-loop and performance budget, asset/scene conventions, and the right build/play CLI commands — like a senior game engineer briefing themselves on the engine and project.
+triggers:
+  keywords: [unity, unreal, "unreal engine", godot, gameplay, gamedev, "game engine", "game loop", shader, hlsl, glsl, ecs, dots, "frame rate", physics, collider, gdscript]
+  globs: ["*.unity", "*.uproject", "*.uplugin", "project.godot", "*.gd", "*.tscn", "*.tres", "Assets", "ProjectSettings"]
+---
+
+# Game Development (Unity / Unreal / Godot) Intake
+
+Do this **before** writing or changing game code. Don't rely on training data — engine APIs
+and recommended patterns change between major versions, and gameplay code runs every frame so
+small mistakes show up as stutter or crashes. Confirm against the engine's current docs and the
+project's own version and conventions.
+
+## Establish current state first
+
+1. **Engine & version in use** — Unity (`ProjectSettings/ProjectVersion.txt`, render pipeline
+   URP/HDRP/Built-in, input system), Unreal (`.uproject` engine association, Blueprint vs C++),
+   or Godot (`project.godot`, Godot 3 vs 4, GDScript vs C#/GDExtension). Match it exactly.
+2. **The frame loop & budget** — what runs per-frame (`Update`/`Tick`/`_process`) vs fixed-step
+   physics (`FixedUpdate`/`_physics_process`). Keep per-frame work cheap; respect the target
+   frame rate and platform budget (mobile/console/VR are tighter).
+3. **Allocations & GC** — avoid per-frame allocations (no `new`/LINQ in `Update`, pool objects);
+   GC spikes cause hitches. In Unreal, mind UObject lifetime/GC and `TWeakObjectPtr`.
+4. **Scenes, prefabs & assets** — follow the project's scene/prefab/asset layout; serialized
+   fields and `.meta`/GUID references are easy to break. Don't reformat scene/asset files by hand.
+5. **Determinism & netcode** — if gameplay is networked or replay-based, keep simulation
+   deterministic and authority/replication correct.
+
+## Build & CLI tools
+
+- Unity: batch mode `Unity -batchmode -runTests`/`-buildTarget`, the Test Runner, the Profiler.
+- Unreal: `UnrealBuildTool`/`RunUAT BuildCookRun`, Automation tests, Unreal Insights.
+- Godot: `godot --headless --export-release`, `godot --headless --run-tests` / GUT.
+
+## What to record before coding
+
+- The engine + version, render pipeline / scripting backend, and target platform budget.
+- The per-frame vs fixed-step work the change adds, and how you keep it allocation-light.
+- The scenes/prefabs/assets touched and any serialized references at risk.
+- The build/play/test commands (and a profiler check) that prove performance and correctness.
+
+Don't broaden the change beyond the task — no incidental engine upgrades or scene-wide edits
+(see the surgical-changes rule in core-engineering).

package/src/devcouncil/skills/library/ios.md

@@ -0,0 +1,48 @@
+---
+name: ios
+title: iOS / Apple Platform Development Intake
+description: Before writing iOS/macOS code, retrieve current Swift/SwiftUI/Xcode versions, deployment targets, deprecations, recommended frameworks, and the right CLI/build tools — like a senior Apple-platform engineer.
+triggers:
+  keywords: [ios, ipados, macos, swift, swiftui, uikit, xcode, cocoapods, spm, swiftpm, combine]
+  globs: ["*.swift", "*.xcodeproj", "*.xcworkspace", "Podfile", "Package.swift", "*.entitlements", "Info.plist"]
+---
+
+# iOS / Apple Platform Development Intake
+
+Do this **before** writing or changing Swift/iOS code. Confirm against
+`developer.apple.com`, the Xcode/Swift release notes, and the project's own settings —
+Apple deprecates APIs aggressively and gates features on OS version.
+
+## Establish current state first
+
+1. **Toolchain & targets** — read the Xcode project / `Package.swift` / `Podfile`:
+   Swift language version, Xcode version, iOS/macOS **deployment target**, and the
+   dependency manager (Swift Package Manager vs CocoaPods — prefer SPM for new work).
+2. **Latest OS & SDK** — the current iOS/macOS release, its SDK, and notable
+   behavior/privacy changes (App Tracking Transparency, privacy manifests, required
+   reason APIs). Note what gates this task.
+3. **Deprecations & availability** — APIs deprecated or unavailable below the
+   deployment target. Use `@available` / `if #available` correctly rather than
+   assuming an API exists. Common shifts: UIKit → SwiftUI patterns, `NSUserActivity`,
+   completion handlers → `async/await`, Combine → Swift Concurrency / Observation.
+4. **Recommended frameworks** — SwiftUI (+ Observation `@Observable`), Swift
+   Concurrency (`async/await`, actors), SwiftData vs Core Data, the current navigation
+   API. Confirm the recommended approach for the deployment target.
+5. **Guidelines** — Human Interface Guidelines, accessibility (Dynamic Type,
+   VoiceOver), and App Store / privacy requirements relevant to the change.
+
+## Build & CLI tools
+
+- `xcodebuild` for builds/tests/archives; `xcrun simctl` for simulators.
+- `swift build` / `swift test` for SwiftPM targets; `swiftformat`/`swiftlint` if configured.
+- Instruments for profiling.
+
+## What to record before coding
+
+- Swift version, deployment target, and dependency-manager choice.
+- Deprecated/unavailable APIs to avoid and their `@available`-guarded replacements.
+- The build/test commands you will run (`xcodebuild test -scheme … -destination …`,
+  or `swift test`) so the change is verifiable.
+
+Match the paradigm of the file you're editing (UIKit vs SwiftUI); don't rewrite
+unrelated screens as a side effect.

package/src/devcouncil/skills/library/mobile-cross-platform.md

@@ -0,0 +1,46 @@
+---
+name: mobile-cross-platform
+title: Cross-Platform Mobile (Flutter / React Native) Intake
+description: Before changing Flutter or React Native code, retrieve current SDK/framework versions, platform-channel and native-module guidance, deprecations, and the right build/run CLI commands for both iOS and Android — like a senior cross-platform mobile engineer briefing themselves.
+triggers:
+  keywords: [flutter, dart, "react native", "react-native", expo, "cross-platform mobile", cupertino]
+  globs: ["pubspec.yaml", "pubspec.lock", "*.dart", "metro.config.js", "app.config.js", "app.config.ts", "react-native.config.js", "expo.json"]
+---
+
+# Cross-Platform Mobile (Flutter / React Native) Intake
+
+Do this **before** writing or changing Flutter/React Native code. Don't rely on training
+data — these frameworks and their native toolchains move quickly, and a change that builds
+on one platform can break the other. Confirm against the framework's current docs and the
+project's own pinned versions.
+
+## Establish current state first
+
+1. **Framework & SDK versions in use** — Flutter/Dart SDK from `pubspec.yaml` and
+   `.fvm`/`flutter --version`; React Native / Expo from `package.json` and the RN/Expo release
+   notes. Note the JS engine (Hermes) and architecture (new arch / Fabric / TurboModules).
+2. **Both native platforms** — iOS (CocoaPods/SPM, min iOS, Xcode) and Android (Gradle/AGP,
+   min/target SDK). A dependency or native change must build and run on **both**.
+3. **Deprecations & breaking changes** — between the pinned versions and current (Flutter API
+   removals, RN bridge → JSI/TurboModules, deprecated Expo modules). List what this change touches.
+4. **State & navigation** — match the project's existing approach (Riverpod/Bloc/Provider for
+   Flutter; Redux/Zustand/Context + React Navigation/Expo Router for RN); don't introduce a new one.
+5. **Native interop** — if the change needs platform code, use the current channel/module API
+   (Flutter platform channels / Pigeon; RN TurboModules/native modules) and implement both sides.
+
+## Build & CLI tools
+
+- Flutter: `flutter pub get`, `flutter run`, `flutter build apk|ios`, `flutter test`,
+  `flutter analyze`, `dart format`.
+- React Native / Expo: `npm`/`yarn`/`pnpm`, `npx react-native run-android|run-ios`,
+  `pod install` (iOS), `npx expo start`, `eas build`, `npm test`.
+
+## What to record before coding
+
+- The framework/SDK versions and the iOS/Android minimums you must support.
+- Deprecated APIs to avoid and their modern replacements, with migration steps.
+- The state/navigation libraries already in use, and any native-module work needed on both sides.
+- The build/test/analyze commands you will run on both platforms to prove the change works.
+
+If the project mixes platform-specific code, match the file you're editing; don't migrate
+unrelated screens as a side effect (see the surgical-changes rule in core-engineering).

package/src/devcouncil/skills/library/security.md

@@ -0,0 +1,48 @@
+---
+name: security
+title: Application Security / Secure Coding Intake
+description: Before writing security-sensitive code or assessing a vulnerability, retrieve current guidance for the relevant class (injection, authn/z, crypto, deserialization), the project's existing controls, and the right scanning/test commands — like a senior application-security engineer briefing themselves.
+triggers:
+  keywords: [security, vulnerability, "secure coding", hardening, "security audit", pentest, "penetration test", owasp, xss, csrf, ssrf, "sql injection", sqli, rce, deserialization, "path traversal", cryptography, encryption, "threat model", sast, dast, cve, sandbox, "least privilege", "input validation"]
+  globs: [".semgrep.yml", ".semgrep.yaml", "bandit.yaml", ".bandit", "*.nuclei.yaml", "trivy.yaml", ".snyk"]
+---
+
+# Application Security / Secure Coding Intake
+
+Do this **before** writing security-sensitive code or judging a vulnerability. Don't rely on
+training data — attack techniques and recommended mitigations evolve, and a plausible-looking
+fix can be incomplete or introduce a new hole. Confirm against current guidance (OWASP, the
+framework's security docs, the relevant CVE/advisory) and the project's existing controls.
+
+## Establish current state first
+
+1. **Trust boundaries & data flow** — where untrusted input enters and where it reaches a sink
+   (DB, shell, filesystem, deserializer, template, HTTP). Map the path this change touches.
+2. **Vulnerability class & correct mitigation** — identify the class precisely and use the
+   *current* canonical defense: parameterized queries (not escaping) for SQLi; context-aware
+   output encoding for XSS; allow-lists + canonicalization for path/SSRF; safe deserializers;
+   constant-time comparison for secrets. Avoid blacklist/regex "sanitizers."
+3. **AuthN / AuthZ** — every new entry point authenticates and authorizes (object-level too —
+   no IDOR); sessions/tokens follow the project's scheme; deny by default.
+4. **Secrets & crypto** — secrets from a vault/env, never committed or logged; use vetted
+   libraries and current algorithms/parameters (no home-rolled crypto, no MD5/SHA1 for security).
+5. **Dependencies & config** — check for known-vulnerable dependencies and insecure defaults
+   (CORS, headers, TLS, file permissions). Note anything in scope.
+
+## Build & CLI tools
+
+- Static/secret scanning: `semgrep`, `bandit` (Python), `gosec`, `npm audit`/`pip-audit`,
+  `gitleaks`/`trufflehog`, `trivy`/`grype` for images and deps.
+- Dynamic/dependency: the project's DAST/`snyk`/`nuclei` flow where present.
+- Add or update a test that *proves* the vulnerability is closed (a failing-then-passing case),
+  not just that the happy path still works.
+
+## What to record before coding
+
+- The vulnerability class, the trust boundary, and the exact sink involved.
+- The current canonical mitigation chosen (and why a weaker one was rejected).
+- The authz/secret/crypto requirements the change must satisfy.
+- The scan/test commands and the regression test that prove the issue is fixed.
+
+Stay surgical: fix the specific weakness without unrelated refactors, and never weaken an
+existing control as a side effect (see core-engineering).