devcouncil 0.1.1 → 0.3.0

package/src/devcouncil/reporting/report_builder.py

@@ -1,10 +1,12 @@
+from pathlib import Path
+
 from devcouncil.artifacts.graph import ArtifactGraph
 from devcouncil.reporting.markdown_report import MarkdownReportGenerator
 from devcouncil.reporting.json_report import JsonReportGenerator
 
 class ReportBuilder:
     """Builds reports in various formats from the artifact graph."""
-    
+
     @staticmethod
     def build_markdown(graph: ArtifactGraph, live_review: dict | None = None) -> str:
         return MarkdownReportGenerator.generate(graph, live_review=live_review)
@@ -12,3 +14,18 @@ class ReportBuilder:
     @staticmethod
     def build_json(graph: ArtifactGraph, live_review: dict | None = None) -> str:
         return JsonReportGenerator.generate(graph, live_review=live_review)
+
+    @staticmethod
+    def build_okf_bundle(
+        graph: ArtifactGraph,
+        output_dir: Path,
+        repo_map=None,
+        project_name: str = "DevCouncil Project",
+        timestamp: str = "",
+    ) -> list[Path]:
+        """Export the artifact graph as an Open Knowledge Format bundle on disk."""
+        from devcouncil.reporting.okf_bundle_writer import OKFBundleWriter
+
+        return OKFBundleWriter.generate(
+            graph, output_dir, repo_map=repo_map, project_name=project_name, timestamp=timestamp
+        )

package/src/devcouncil/skills/__init__.py

@@ -0,0 +1,19 @@
+"""DevCouncil skills library."""
+
+from devcouncil.skills.registry import (
+    Skill,
+    get_skill,
+    load_skills,
+    render_preamble,
+    scaffold_skills,
+    select_skills,
+)
+
+__all__ = [
+    "Skill",
+    "get_skill",
+    "load_skills",
+    "render_preamble",
+    "scaffold_skills",
+    "select_skills",
+]

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).