This record maps the skills this marketplace bundles to the work the Devantler Tech portfolio actually does. For each gap it gives one decision: covered, owned by an existing issue, adopt an upstream skill, or do not add. It answers #637. Whether agents load the skills they have is measured separately: the activation baseline is in #642, and the eval suite is #651.
This is an engineering inventory. It makes no legal or compliance claim.
- Skills: 39 skills at
73c39b3: 35 inagentic-engineering, 1 inksailand 3 invibe-coding. The monorepo also carries 4 deployment overlays and 17 product cards under.claude/skills/. Three of the overlays extend the bundledportfolio-maintenance,product-engineeringandself-improvementskills for that deployment. The fourth,finops, is a deployment-only procedure for the engineer's spend mandate. None of the overlays is bundled here. - Portfolio use: code search scoped to
devantler-techand the product manifests, read on 2026-11-04. Product evidence links are pinned to that day's default-branch commit. - Candidates: official vendor or project repositories first. Licence, maintainer and last push were read from the GitHub API on 2026-11-04. Skill directories that mirror other repositories were not used as sources.
- Importance: High means production or personal data, customer-facing legal exposure, or a security boundary. Medium means recurring work on a production system. Low means no product does this work today.
| Area | Portfolio use | Bundled resources | Gap | Importance | Decision |
|---|---|---|---|---|---|
| Privacy and GDPR | contact handling, customer identity and invoices in the business-site portal; guest RSVPs in wedding-app | none | all of it | High | Owned by #638 |
| Danish commerce, consumer and accessibility rules | client sites with service offerings and booking (ascoachingogvaner); business-site invoicing | web-design-guidelines covers UI accessibility review, not Danish law |
the legal rules | High | Owned by #639 |
| Application security and tenant isolation | the business-site customer portal, KHoist's data product API, tenant apps on the shared platform | CI and supply chain: github-actions-hardening, codeql, secret-scanning, dependency-scanning, dependabot. Cluster tenants: gitops-tenant-onboarding |
application layer: object-level authorization, sessions, webhook verification, threat models | High | Owned by #640 |
| SvelteKit and TypeScript | business-site web/, wedding-app, ascoachingogvaner |
none; frontend-design and web-design-guidelines are framework-neutral |
Svelte framework guidance. TypeScript itself is not treated as a gap; if that needs checking, add a TypeScript case to #651 | Medium | Adopt: #652 |
| Astro | the KSail docs and the KHoist website | astro, product-documentation, write-docs-introduction |
none | Medium | Covered |
| Go | ksail, khoist, the business-site server, platform helpers | golang-pro, test-driven-development, refactor |
activation only: 0 loads in a week with at least 34 Go sessions (#642) | Medium | Covered; measured by #651 |
| API and form validation | request handling in the SvelteKit sites (for example the wedding-app RSVP endpoint) and the Go portal | web-design-guidelines covers form markup |
server-side validation, rate limits and uploads belong to application security; personal data in forms belongs to privacy | Medium | Do not add a separate skill: owned by #640 and #638 |
| PostgreSQL schema and migrations | the business-site portal schema, wedding-app on Drizzle migrations, KHoist's CloudNativePG provider | none | schema design, query plans, lock-safe migrations | High | Adopt: #653 |
| PostgreSQL backup and restore | the platform's CloudNativePG and Velero procedures | none | none for a skill: the procedure is specific to one repository | High | Do not add: stays in the platform's docs and verifiers |
| ClickHouse | only as Coroot's log and trace storage, which the platform runs but no product queries | none | none today | Low | Do not add. Revisit when a product writes ClickHouse schemas or queries |
| Prometheus and OpenTelemetry | Coroot with its bundled Prometheus, which Flagger and KEDA query in PromQL; Alertmanager; an OpenTelemetry log forwarder | none; gitops-cluster-debug reads metrics only through the Flux MCP server |
PromQL, alert rules, collector pipelines | Medium | Adopt: #654 |
| SLOs | the platform alerts on Coroot's built-in per-application SLOs; no repository sets its own SLO targets or error-budget policy | none | SLO targets and error-budget policy, which nobody authors today | Low | Do not add. Tuning Coroot's SLO alerts goes with #654. Revisit when a product sets its own SLO targets |
| FinOps | the engineer's spend mandate (stewardship disabled by contract) | the agentic-engineer agent and the github-actions-efficiency skill; the monorepo finops overlay is outside this repository |
none | Medium | Covered |
| Payments, subscriptions and webhooks | no product takes payments: the code search org:devantler-tech stripe on 2026-11-04 returned 7 matches, all dependency metadata, a bookmark, game assets or a skill reference |
none | none today | Low | Do not add. Webhook verification belongs to #640, subscription disclosures to #639. Revisit when a product commits to payments |
| GitOps, Kubernetes and deployment | the platform, ksail and the templates | skills gitops-knowledge, gitops-cluster-debug, gitops-tenant-onboarding, ksail and siderolabs; the bundled Flux MCP server |
activation only: 0 loads with at least 11 manifest sessions (#642) | High | Covered; measured by #651 |
Owned means the audit hands the gap to an existing issue instead of filing an overlapping one. The candidate comparison and the adopt-or-build decision for those three gaps happen there: each issue's acceptance criteria require a candidate assessment before anything is built.
The matrix maps the 19 domain skills it names. The other 20 bundled skills are about how engineering work is run, not about a stack, so they have no domain row:
- run procedures and roles:
portfolio-maintenance,product-engineering,self-improvement,agent-improvement; - repository workflow:
ways-of-working,git-commit,conventional-release,github-issues,gh-cli,gh-stack,github-actions-docs; - writing:
agent-instructions,write-readme,write-contributing; - thinking aids:
grilling,prototype,find-skills; - conversational building (
vibe-coding):needs-stack-mapping,allowed-stack-guardrail,jargon-free-voice.
Whether these load when they should is part of #642's baseline and #651's suite. The adoption process itself belongs to #641.
Activation conditions for the adopted skills are their trigger cases. Each follow-up issue lists them: should-trigger, near-miss and over-trigger cases that #651's suite runs.
| Gap | Candidate | Licence and owner | Last push | Fit and risk | Decision |
|---|---|---|---|---|---|
| SvelteKit | svelte-core-bestpractices, svelte-code-writer |
MIT, the Svelte team | 2026-11-04 | Official. The code writer runs npx @sveltejs/mcp without a pinned version, so its tool use needs a supply-chain review |
Adopt, after #641's rubric (#652) |
| PostgreSQL | supabase-postgres-best-practices |
MIT, Supabase | 2026-10-02 | Says it applies to "Postgres running anywhere" and covers migrations. Check the Supabase-only parts | Adopt if it passes #641's rubric (#653) |
| PostgreSQL | infra-postgres |
Apache-2.0, ClickHouse | 2026-11-02 | Provisions Postgres through the clickhousectl CLI; no schema, query or migration guidance |
Do not add |
| Observability | promql, prometheus, opentelemetry |
Apache-2.0, Grafana Labs | 2026-11-03 | Official. Much of the repository targets Grafana Cloud, so take only the self-hosted subset | Adopt a subset (#654) |
| Observability | community skills such as opentelemetry and observability-sre |
MIT, individual maintainers | 2026-05-22, 2026-11-04 | General-purpose. The vendor-maintained Grafana skills cover the same scope | Rejected |
| ClickHouse | clickhouse-best-practices |
Apache-2.0, ClickHouse | 2026-11-02 | Strong, but no product authors ClickHouse work | Do not add yet |
| Payments | stripe-best-practices |
MIT, Stripe | 2026-11-04 | Official, but no product takes payments and no provider is chosen | Do not add yet |
| Any gap | author a first-party skill | this repository | — | A maintained official candidate exists for every adopted gap | Rejected (#637's adoption-first workflow) |
Candidates for privacy, Danish rules and application security will be compared in #638, #639 and #640, as the note under the matrix says. One note for #640: trailofbits/skills is licensed CC-BY-SA-4.0. Its share-alike terms need the redistribution review that #581 owns before anything is bundled.
- A skill here holds guidance that is true for any repository using the tool: Svelte, Postgres, PromQL, a GDPR engineering checklist. A skill never names a portfolio product.
- A product's
AGENTS.md, or its monorepo product card, holds the facts about that one product: which data is personal, which customers are consumers, how its database is backed up and restored, its tenant values. A product card never restates a skill. - A monorepo deployment overlay (
portfolio-maintenance,product-engineering,self-improvement,finops) binds a reviewed plugin role to this deployment.
One drift found (monorepo#4845): the
business-site product card still describes an Astro application, but the site now builds
with SvelteKit and a Go server. An agent that trusts the card would choose astro.
- Prerequisites for every adoption: the adopt-or-build rubric and pinning lifecycle (#641, with #581, #583 and #598), the activation suite (#651), and stale user-level copies that shadow plugin skills (monorepo#4840). Each adoption also adds description text, and #642 found 30 of 94 listed skills shown by name only. So every adoption PR reports how many description characters it adds.
- Application security and tenant isolation (#640). High exposure, and the customer portal is in active development.
- Privacy and GDPR (#638). Personal data in two products.
- PostgreSQL schema and migrations (#653). Production data with no guidance.
- Danish commerce, consumer and accessibility rules (#639).
- SvelteKit (#652). Three products, and a framework-specific gap.
- Prometheus and OpenTelemetry (#654).
Not now: ClickHouse, payments, SLOs and a separate validation skill. Each row above says what would change that.
Update this file in place, never by adding another. Revisit it when a product adopts a new stack, when an adoption issue above closes, or after #651's first two baselines.