diff --git a/README.md b/README.md index 59377e6a..c84f1d82 100644 --- a/README.md +++ b/README.md @@ -150,13 +150,13 @@ Current Socket catalog shape: - `apple-creator-studio-skills`: source-preserving Final Cut Pro editing, Motion template, Compressor delivery, Logic Pro production, MainStage concert, and GarageBand project workflows with local Help Viewer discovery, explicit Computer Use safeguards, and artifact or rehearsal verification - `apple-dev-skills`: Apple, Swift, SwiftPM, macOS-hosted boundary selection, custom Virtualization framework hosts, persistent Linux development guests, clean macOS development guests, imaging, Vision/Core ML, camera, spatial sensing, media/audio, SwiftUI, AppKit, Xcode, Safari, OpenAPI, and DocC workflows, plus the source-bundled `swift-steward` custom-agent definition with its own roadmap - `cardhop-app`: mixed skill plus bundled MCP server for Cardhop.app contact workflows -- `cloud-deployment-skills`: cloud provider deployment routing, official provider plugin selection, credential and mutation boundary checks, and AWS handoff to the official AWS Agent Toolkit rather than duplicated AWS MCP, CLI, or SAM setup +- `cloud-deployment-skills`: cloud provider deployment routing, official provider plugin selection, credential and mutation boundary checks, AWS handoff to the official AWS Agent Toolkit, and Azure handoff to Microsoft's Azure Skills plugin rather than duplicated provider MCP or CLI setup - `cloud-inference-skills`: cloud AI inference, training, model conversion, and GPU infrastructure routing for Runpod, Hugging Face, AWS, Vast.ai, CoreWeave, and similar providers, with bundled Runpod MCP server configuration, upstream Runpod skill mirrors, and first-party Hugging Face/AWS handoffs - `cybersecurity-skills`: suspicious-content triage, evidence preservation, isolation selection, disposable Linux and macOS analysis-lab preparation, malware analysis, agentic security-tool controls, macOS investigation and defense, vulnerability validation, authorized testing, incident response, threat hunting, detection content, and clear non-specialist advice - `messaging-collaboration-skills`: chat-app, bot, business-messaging, meeting-collaboration, iMessage collaboration, Communication Notifications, Push to Talk, VoIP/SIP, documented iOS/iPadOS default communication roles, and app-owned macOS client workflows for Discord, Telegram, Slack, Teams, WhatsApp Business, SMS/MMS/RCS, Google Meet, and Apple communication surfaces, with explicit Signal and Mac operator-automation boundaries - `model-lab-skills`: reproducible language-model experiment design, dataset preparation, fine-tuning, evaluation, checkpoint comparison, representation and steering research, refusal ablation, authorized jailbreak and tool-calling evaluation, runtime benchmarking, and current-source routing across Core AI, Core ML, MLX, ExecuTorch, and Foundation Models - `agentdeck`: local Codex runtime utilities, starting with hooks that prefix generated Codex thread titles with the project directory name -- `dotnet-skills`: .NET, F#, and C# project-shape, bootstrap, implementation, test, package, diagnostics, ASP.NET Core, interop, CI, upgrade, and tooling guidance +- `dotnet-skills`: .NET, F#, and C# project-shape, bootstrap, implementation, test, package, diagnostics, ASP.NET Core, Giraffe, Falco, Oxpecker, interop, CI, upgrade, and tooling guidance - `game-dev-skills`: Apple platform game development workflows for native Metal and Metal 4 renderers, GPTK 3/4 routing, MetalFX, GPU asset streaming, experimental neural rendering, SpriteKit, SceneKit, GameplayKit simulation, Game Controller input, Core Haptics feedback, Xcode profiling, game-stack routing, and device-aware validation handoffs - `network-protocol-skills`: modern networking and application-protocol workflows for transport selection, HTTP/3 and QUIC planning, Media over QUIC draft-aware guidance, WebRTC signaling/media/data-channel work, and protocol diagnostics with stack-plugin handoffs - `productivity-skills`: general-purpose maintainer, documentation, Dice MCP job-search with bundled remote MCP config, Codex GUI worktree workflow, and automation-design workflows plus source-bundled docs-audit and code-tracing custom-agent definitions diff --git a/ROADMAP.md b/ROADMAP.md index 453d85e9..81c8c681 100644 --- a/ROADMAP.md +++ b/ROADMAP.md @@ -130,6 +130,8 @@ Completed - [x] Update `plugins/dotnet-skills/.codex-plugin/plugin.json` so plugin metadata includes F# and avoids C#-only wording. - [x] Add first-slice skills for project-shape choice, solution bootstrap, F# project implementation, C# project implementation, and test workflow. - [x] Add second-slice skills for package workflow, diagnostics, ASP.NET Core services, F#/C# interop, CI, upgrades, and tooling/style alignment. +- [x] Add F# web-framework selection plus focused Giraffe, Falco, and Oxpecker workflows; keep Saturn and browser-client frameworks as explicit selection boundaries until a project needs deeper coverage. +- [x] Route F# web application Azure work through Microsoft's official Azure Skills plugin rather than duplicating Azure MCP, Azure CLI, Azure Developer CLI, or deployment guidance in Socket. - [x] Switch the root marketplace entry for `dotnet-skills` from placeholder to installable only after real skill content exists. - [x] Update root README and maintainer docs so users understand the new installable child plugin surface. - [x] Run root metadata validation with `uv run scripts/validate_socket_metadata.py` and any child-plugin checks added by the new plugin. @@ -140,6 +142,7 @@ Completed - [x] The new skills can help an agent choose a `.NET` project shape before implementation. - [x] The new skills guide F# and C# implementation without making either language a secondary path. - [x] The testing guidance uses `dotnet test` as the stable command surface while respecting repo-local test framework choices. +- [x] The F# web guidance distinguishes Giraffe, Falco, and Oxpecker contracts while preserving ordinary ASP.NET Core and F# domain boundaries. - [x] Root Socket docs, marketplace wiring, and validation agree on the plugin's install surface. ## Milestone 7: Python skills plugin expansion @@ -686,6 +689,7 @@ Completed - [x] Add a thin Socket-hosted `cloud-deployment-skills` child plugin for cloud provider routing, official provider plugin selection, credential and mutation boundary checks, and cross-provider deployment handoffs. - [x] Delegate AWS MCP configuration, AWS CLI setup, AWS SAM setup, and curated AWS skill content to the official [`aws/agent-toolkit-for-aws`](https://github.com/aws/agent-toolkit-for-aws) marketplace and its `aws-core` plugin. +- [x] Delegate Azure MCP, Foundry MCP, Azure CLI and Azure Developer CLI workflows, and Azure provider guidance to Microsoft's official [`microsoft/azure-skills`](https://github.com/microsoft/azure-skills) marketplace and its `azure` plugin. - [x] Keep framework-specific deployment implementation in the owning stack plugins, such as Server-Side Swift Fly.io deployment guidance. - [x] Keep the first Socket slice guidance-only: do not bundle AWS MCP config, copied AWS skills, credential setup scripts, provider templates, or local cloud state. @@ -696,12 +700,14 @@ Completed - [x] Add `cloud-deployment-skills:cloud-deployment-routing-workflow` for provider routing, AWS Agent Toolkit handoff, mutation boundaries, and validation choices. - [x] Wire `cloud-deployment-skills` into the root Socket marketplace as an installable child plugin. - [x] Update root README and ROADMAP so users understand the new plugin surface and the AWS delegation decision. +- [x] Update root README and maintainer guidance so users understand the Azure Skills delegation decision and F# web-framework handoff. - [x] Run root metadata validation with `uv run scripts/validate_socket_metadata.py`. ### Exit Criteria - [x] The Socket marketplace exposes `cloud-deployment-skills` as an installable child plugin. - [x] AWS work routes to the official AWS Agent Toolkit for AWS by default instead of duplicated Socket-owned AWS MCP, AWS CLI, or AWS SAM setup guidance. +- [x] Azure work routes to Microsoft's official Azure Skills plugin by default instead of duplicated Socket-owned Azure MCP, CLI, or Azure Developer CLI setup guidance. - [x] The plugin boundary is clear enough for future provider slices without absorbing framework-specific deployment workflows. - [x] Root Socket docs, marketplace wiring, and validation agree on the exported cloud-deployment skill surface. diff --git a/docs/maintainers/cloud-deployment-skills-plugin-plan.md b/docs/maintainers/cloud-deployment-skills-plugin-plan.md index 7406b77d..8106a0a6 100644 --- a/docs/maintainers/cloud-deployment-skills-plugin-plan.md +++ b/docs/maintainers/cloud-deployment-skills-plugin-plan.md @@ -10,6 +10,7 @@ The first practical use case is AWS. AWS now publishes the official [`aws/agent- - `cloud-deployment-skills` owns provider selection, official-tool routing, credential and mutation boundary checks, and cross-provider deployment handoffs. - AWS owns the AWS Agent Toolkit, AWS MCP Server configuration, and AWS skill content. +- Microsoft owns Azure Skills, Azure MCP and Foundry MCP configuration, and Azure provider workflows. - Stack plugins keep framework-specific deployment details, such as Server-Side Swift Fly.io deploy workflows. ## First Slice @@ -25,7 +26,8 @@ The first practical use case is AWS. AWS now publishes the official [`aws/agent- - Add Cloudflare deployment routing if Socket needs guidance beyond existing Cloudflare docs and tooling. - Add Vercel deployment routing if web project handoffs need a first-party Socket decision layer. - Add Fly.io provider-neutral routing only if the existing Server-Side Swift workflow is too narrow for non-Swift projects. -- Add Terraform, Pulumi, CDK, Azure, or GCP slices only after concrete project use proves that official provider docs or plugins are not enough. +- Use the official Microsoft Azure Skills plugin for Azure. Add a Socket Azure slice only after a concrete project proves that the official provider plugin cannot cover a provider-neutral routing or repository-boundary need. +- Add Terraform, Pulumi, CDK, or GCP slices only after concrete project use proves that official provider docs or plugins are not enough. ## Validation diff --git a/docs/maintainers/dotnet-skills-plugin-plan.md b/docs/maintainers/dotnet-skills-plugin-plan.md index cb5863bc..c535c244 100644 --- a/docs/maintainers/dotnet-skills-plugin-plan.md +++ b/docs/maintainers/dotnet-skills-plugin-plan.md @@ -292,6 +292,31 @@ The second slice broadens the plugin from core project/test guidance into packag - [x] `dotnet:tooling-style-workflow`. - [ ] install testing with a temporary `CODEX_HOME`. +## Third Implementation Slice: F# Web Frameworks + +This slice makes the existing ASP.NET Core service workflow actionable for the +F# frameworks that have distinct handler and routing contracts. It is a durable +building-block change: it removes the current ambiguity between generic ASP.NET +Core guidance and framework-specific F# code, while keeping cloud operations in +Microsoft's official Azure Skills plugin. + +- [x] `dotnet:choose-fsharp-web-framework` selects Minimal APIs, Giraffe, + Falco, Oxpecker, or Saturn from the application's actual HTTP and ownership + needs. +- [x] `dotnet:build-giraffe-web-app` covers composable `HttpHandler` work. +- [x] `dotnet:build-falco-web-app` covers functional routes, response helpers, + and ASP.NET Core integration. +- [x] `dotnet:build-oxpecker-web-app` covers endpoint routing, + `EndpointHandler`, and `EndpointMiddleware` contracts. +- [x] Keep Saturn, SAFE Stack, Fable, Bolero, and WebSharper as explicit + selection or handoff boundaries until a concrete project requires deeper + framework-specific workflows. +- [x] Export the new portable instructions through the Hermes tap; do not claim + that the Codex plugin manifest itself is a Hermes plugin. +- [x] Route Azure infrastructure, diagnostics, and deployment work to the + official Microsoft Azure Skills plugin rather than adding an Azure MCP server + or duplicated IaC workflow to `dotnet-skills`. + ## Deferred Scope After the first two slices prove useful, consider deeper specialized workflows. These are useful but should not block the current installable plugin: @@ -305,6 +330,10 @@ After the first two slices prove useful, consider deeper specialized workflows. - custom project template generation - bundled MCP servers or app connectors +The F# web-framework slice intentionally does not add a new runtime plugin, +framework template feed, browser-client framework implementation, or Azure +adapter. Those would broaden the architecture beyond the shared guidance need. + ## Open Decisions Before Implementation ### Skill Names diff --git a/docs/maintainers/hermes-compatibility.md b/docs/maintainers/hermes-compatibility.md index 8ece07c1..56a97887 100644 --- a/docs/maintainers/hermes-compatibility.md +++ b/docs/maintainers/hermes-compatibility.md @@ -105,6 +105,13 @@ It resolves operator-installed Swiftly and Xcode tools and plans SwiftPM plugin, macro, trait, generated-source, and permission work without bundling a compiler, plugin runtime, MCP server, or native Hermes extension. +The exported F# web-framework workflows are portable instruction contracts. They +use the operator's .NET SDK and project dependencies but bundle no runtime, +framework package, MCP server, hook, or native Hermes extension. The cloud +deployment routing workflow is also portable guidance: it routes Azure work to +Microsoft's official Azure Skills plugin but does not claim that Azure MCP is +automatically installed or configured in Hermes. + The exported macOS platform-security workflows are portable instruction contracts. Public app permission, sandbox file-access, and entitlement diagnosis remain in Apple Dev Skills; exact-build private-control research remains in Reverse Engineering Skills; defensive host investigation remains in Cybersecurity Skills. Hermes does not receive a TCC database tool, permission grant service, privileged helper, protection bypass, or native runtime plugin from this work. ## Maintainer Workflow diff --git a/plugins/agent-portability-skills/.codex-plugin/plugin.json b/plugins/agent-portability-skills/.codex-plugin/plugin.json index 493714d7..678c12a3 100644 --- a/plugins/agent-portability-skills/.codex-plugin/plugin.json +++ b/plugins/agent-portability-skills/.codex-plugin/plugin.json @@ -1,6 +1,6 @@ { "name": "agent-portability-skills", - "version": "9.21.0", + "version": "9.22.0", "description": "Maintainer skills for Socket-owned agent skill portability, Codex plugin surfaces, and host adapter guidance.", "author": { "name": "Gale", diff --git a/plugins/agent-portability-skills/pyproject.toml b/plugins/agent-portability-skills/pyproject.toml index be4346ad..2512c233 100644 --- a/plugins/agent-portability-skills/pyproject.toml +++ b/plugins/agent-portability-skills/pyproject.toml @@ -1,6 +1,6 @@ [project] name = "agent-portability-skills-maintenance" -version = "9.21.0" +version = "9.22.0" description = "Maintainer-only Python tooling baseline for Agent Portability Skills." requires-python = ">=3.11" dependencies = [] diff --git a/plugins/agent-portability-skills/uv.lock b/plugins/agent-portability-skills/uv.lock index 4ced2f2b..3f79c821 100644 --- a/plugins/agent-portability-skills/uv.lock +++ b/plugins/agent-portability-skills/uv.lock @@ -8,7 +8,7 @@ resolution-markers = [ [[package]] name = "agent-portability-skills-maintenance" -version = "9.21.0" +version = "9.22.0" source = { virtual = "." } [package.dev-dependencies] diff --git a/plugins/agentdeck/.codex-plugin/plugin.json b/plugins/agentdeck/.codex-plugin/plugin.json index 5c3ef7bf..c2e0ecb3 100644 --- a/plugins/agentdeck/.codex-plugin/plugin.json +++ b/plugins/agentdeck/.codex-plugin/plugin.json @@ -1,6 +1,6 @@ { "name": "agentdeck", - "version": "9.21.0", + "version": "9.22.0", "description": "Local Codex runtime utilities for thread, hook, and app-server workflows.", "author": { "name": "Gale", diff --git a/plugins/android-dev-skills/.codex-plugin/plugin.json b/plugins/android-dev-skills/.codex-plugin/plugin.json index d2bb1d09..90becf3c 100644 --- a/plugins/android-dev-skills/.codex-plugin/plugin.json +++ b/plugins/android-dev-skills/.codex-plugin/plugin.json @@ -1,6 +1,6 @@ { "name": "android-dev-skills", - "version": "9.21.0", + "version": "9.22.0", "description": "Android, Kotlin, Java, Gradle, Android Gradle Plugin, testing, lint, UI implementation, and release-readiness workflow skills.", "author": { "name": "Gale", diff --git a/plugins/apple-creator-studio-skills/.codex-plugin/plugin.json b/plugins/apple-creator-studio-skills/.codex-plugin/plugin.json index 07697e11..287ded34 100644 --- a/plugins/apple-creator-studio-skills/.codex-plugin/plugin.json +++ b/plugins/apple-creator-studio-skills/.codex-plugin/plugin.json @@ -1,6 +1,6 @@ { "name": "apple-creator-studio-skills", - "version": "9.21.0", + "version": "9.22.0", "description": "Human-facing and Computer Use-aware Apple Creator Studio workflows for Final Cut Pro editing, Motion templates, Compressor delivery, Logic Pro production, MainStage concert preparation, and GarageBand projects.", "author": { "name": "Gale", diff --git a/plugins/apple-dev-skills/.codex-plugin/plugin.json b/plugins/apple-dev-skills/.codex-plugin/plugin.json index 4e051b14..03635252 100644 --- a/plugins/apple-dev-skills/.codex-plugin/plugin.json +++ b/plugins/apple-dev-skills/.codex-plugin/plugin.json @@ -1,6 +1,6 @@ { "name": "apple-dev-skills", - "version": "9.21.0", + "version": "9.22.0", "description": "Apple development workflows for Codex, including macOS privacy permissions, sandbox file access, entitlement diagnosis, virtualization, SwiftPM, Xcode, app extensions, media, provisioning, SwiftUI, AppKit, Safari, security, OpenAPI, and DocC.", "author": { "name": "Gale", diff --git a/plugins/apple-dev-skills/pyproject.toml b/plugins/apple-dev-skills/pyproject.toml index c014834e..2c854544 100644 --- a/plugins/apple-dev-skills/pyproject.toml +++ b/plugins/apple-dev-skills/pyproject.toml @@ -1,6 +1,6 @@ [project] name = "apple-dev-skills-maintainer" -version = "9.21.0" +version = "9.22.0" description = "Maintainer tooling for the apple-dev-skills repository" requires-python = ">=3.10" dependencies = [] diff --git a/plugins/apple-dev-skills/uv.lock b/plugins/apple-dev-skills/uv.lock index 93ed97e9..2acbfa9b 100644 --- a/plugins/apple-dev-skills/uv.lock +++ b/plugins/apple-dev-skills/uv.lock @@ -4,7 +4,7 @@ requires-python = ">=3.10" [[package]] name = "apple-dev-skills-maintainer" -version = "9.21.0" +version = "9.22.0" source = { virtual = "." } [package.dev-dependencies] diff --git a/plugins/cardhop-app/.codex-plugin/plugin.json b/plugins/cardhop-app/.codex-plugin/plugin.json index 337a3057..65df7ebb 100644 --- a/plugins/cardhop-app/.codex-plugin/plugin.json +++ b/plugins/cardhop-app/.codex-plugin/plugin.json @@ -1,6 +1,6 @@ { "name": "cardhop-app", - "version": "9.21.0", + "version": "9.22.0", "description": "Cardhop.app workflow guidance plus a bundled local MCP server for contact capture and updates on macOS.", "author": { "name": "Gale", diff --git a/plugins/cardhop-app/mcp/pyproject.toml b/plugins/cardhop-app/mcp/pyproject.toml index 4a7e736d..58ad966e 100644 --- a/plugins/cardhop-app/mcp/pyproject.toml +++ b/plugins/cardhop-app/mcp/pyproject.toml @@ -1,6 +1,6 @@ [project] name = "cardhop-app-mcp" -version = "9.21.0" +version = "9.22.0" requires-python = ">=3.13" dependencies = [ "fastmcp>=3.0.2", diff --git a/plugins/cardhop-app/mcp/uv.lock b/plugins/cardhop-app/mcp/uv.lock index 0c3c7b58..b8250328 100644 --- a/plugins/cardhop-app/mcp/uv.lock +++ b/plugins/cardhop-app/mcp/uv.lock @@ -141,7 +141,7 @@ wheels = [ [[package]] name = "cardhop-app-mcp" -version = "9.21.0" +version = "9.22.0" source = { virtual = "." } dependencies = [ { name = "fastmcp" }, diff --git a/plugins/cloud-deployment-skills/.codex-plugin/plugin.json b/plugins/cloud-deployment-skills/.codex-plugin/plugin.json index a2986185..7b69c7f2 100644 --- a/plugins/cloud-deployment-skills/.codex-plugin/plugin.json +++ b/plugins/cloud-deployment-skills/.codex-plugin/plugin.json @@ -1,6 +1,6 @@ { "name": "cloud-deployment-skills", - "version": "9.21.0", + "version": "9.22.0", "description": "Codex skills for routing cloud deployment work through official provider plugins, MCP servers, CLIs, and Socket-owned deployment guidance.", "author": { "name": "Gale", @@ -18,6 +18,8 @@ "deployment", "aws", "agent-toolkit", + "azure", + "azure-mcp", "mcp", "cloudflare", "vercel", @@ -27,7 +29,7 @@ "interface": { "displayName": "Cloud Deployment Skills", "shortDescription": "Cloud provider and deployment routing guidance for Codex.", - "longDescription": "Guide Codex agents through cloud deployment routing, official provider plugin selection, credential and mutation safety checks, and provider handoffs. The first slice delegates AWS work to the official AWS Agent Toolkit for AWS and keeps Socket focused on thin cross-provider deployment decisions instead of duplicating AWS MCP, AWS CLI, or AWS SAM setup.", + "longDescription": "Guide Codex agents through cloud deployment routing, official provider plugin selection, credential and mutation safety checks, and provider handoffs. Socket delegates AWS work to the official AWS Agent Toolkit and Azure work to Microsoft's Azure Skills plugin, keeping Socket focused on thin cross-provider decisions instead of duplicating provider MCP, CLI, or deployment workflows.", "developerName": "gaelic-ghost", "category": "Developer Tools", "capabilities": [ @@ -36,7 +38,7 @@ ], "websiteURL": "https://github.com/gaelic-ghost/socket/tree/main/plugins/cloud-deployment-skills", "defaultPrompt": [ - "Choose the right cloud deployment path and route AWS work through the official AWS Agent Toolkit when appropriate.", + "Choose the right cloud deployment path and route AWS or Azure work through the applicable official provider plugin when appropriate.", "Decide whether this deployment should use an official provider plugin, provider CLI, MCP server, framework-owned deploy workflow, or a Socket-owned provider skill." ], "brandColor": "#22D3EE", diff --git a/plugins/cloud-deployment-skills/AGENTS.md b/plugins/cloud-deployment-skills/AGENTS.md index ef9c4552..487cce92 100644 --- a/plugins/cloud-deployment-skills/AGENTS.md +++ b/plugins/cloud-deployment-skills/AGENTS.md @@ -15,7 +15,9 @@ This file is the Cloud Deployment Skills child-repo override for work done from - Match the `socket` shared semantic version exactly; use the Socket root release workflow for version inventory and bumps. - Prefer official provider plugins, MCP servers, CLIs, and docs before adding Socket-authored setup guidance. - For AWS work, route Codex users to the official `aws/agent-toolkit-for-aws` marketplace and its `aws-core` plugin before considering Socket-owned AWS guidance. +- For Azure work, route Codex users to the official `microsoft/azure-skills` marketplace and its `azure` plugin before considering Socket-owned Azure guidance. - Do not bundle AWS MCP configuration, AWS CLI setup instructions, AWS SAM setup instructions, or copied AWS Agent Toolkit skills in this plugin while the official AWS plugin owns that surface. +- Do not bundle Azure MCP configuration, Azure CLI or Azure Developer CLI setup instructions, or copied Azure Skills content while the official Microsoft plugin owns that surface. - Treat provider credentials, account configuration, API mutation, billing, and production deployment as high-impact operations. Verify the target account, region, profile, project, and intended mutation before taking action. - Keep provider-specific skills small and explicit. Add a new provider workflow only when it removes real routing ambiguity or covers a provider that does not already offer a first-party agent plugin. - Do not commit machine-local credentials, profiles, `.env` files, cloud state, generated deployment artifacts, or local cache paths. diff --git a/plugins/cloud-deployment-skills/skills/cloud-deployment-routing-workflow/SKILL.md b/plugins/cloud-deployment-skills/skills/cloud-deployment-routing-workflow/SKILL.md index e5be0ebf..677a4a21 100644 --- a/plugins/cloud-deployment-skills/skills/cloud-deployment-routing-workflow/SKILL.md +++ b/plugins/cloud-deployment-skills/skills/cloud-deployment-routing-workflow/SKILL.md @@ -1,6 +1,6 @@ --- name: cloud-deployment-routing-workflow -description: Choose the right cloud deployment path before implementation, routing AWS work through the official AWS Agent Toolkit for AWS when appropriate and keeping provider credentials, regions, and mutation boundaries explicit. +description: Choose a cloud deployment path before implementation. Route AWS work to the official AWS Agent Toolkit and Azure work to Microsoft's Azure Skills plugin while keeping credentials, regions, and mutation boundaries explicit. license: Apache-2.0 compatibility: Designed for Codex and compatible Agent Skills clients working with cloud deployments, provider CLIs, provider plugins, MCP servers, and repository-owned deployment configuration. metadata: @@ -34,6 +34,9 @@ Use repo-local deployment files, checked-out provider config, installed provider - [AWS MCP Server setup](https://docs.aws.amazon.com/agent-toolkit/latest/userguide/getting-started-aws-mcp-server.html) - [AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/) - [AWS SAM CLI](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/what-is-sam.html) +- [Azure Skills](https://github.com/microsoft/azure-skills) +- [Azure MCP Server](https://learn.microsoft.com/azure/developer/azure-mcp-server/) +- [Azure Developer CLI](https://learn.microsoft.com/azure/developer/azure-developer-cli/) Translate any documentation rule into the concrete repository decision it changes. @@ -65,6 +68,12 @@ Translate any documentation rule into the concrete repository decision it change - Do not duplicate AWS MCP configuration in Socket while `aws-core` bundles that configuration. - Do not copy AWS Agent Toolkit skills into Socket. 4. Route non-AWS work: + - For Azure, prefer Microsoft's Azure Skills plugin for Azure MCP, Foundry MCP, + preparation, validation, deployment, diagnostics, cost, RBAC, and service + guidance. Add its marketplace with `codex plugin marketplace add + microsoft/azure-skills`, then install `azure` through `/plugins`. + - Do not duplicate Azure MCP declarations, Azure CLI or Azure Developer CLI + setup, Azure Skills workflows, or account-specific IaC in Socket. - Use a first-party provider plugin or MCP server when one exists and is current. - Use framework-owned Socket skills when the deployment surface is already covered by a stack workflow, such as `server-side-swift:fly-io-deployment-workflow`. - Add or use a Socket-owned provider skill only when no official provider-owned agent surface exists or when Socket needs a small provider-neutral decision layer. @@ -91,13 +100,25 @@ Use the official AWS Agent Toolkit for AWS as the default Codex path. It owns AW Use Socket only for the routing decision, local repo handoff, and any project-specific deployment guardrails that the official AWS plugin does not know. +### Azure + +Use Microsoft's Azure Skills plugin as the default Codex path. It owns Azure MCP +and Foundry MCP configuration plus the provider workflows for preparation, +validation, deployment, diagnostics, cost, identity, and Azure services. + +Use Socket only to select that official surface, preserve repository-specific +deployment boundaries, and hand framework implementation back to the owning stack +plugin. For an F# web app, select Giraffe, Falco, Oxpecker, or another server +shape through `dotnet:choose-fsharp-web-framework` before asking Azure Skills to +plan or mutate Azure infrastructure. + ### Framework-Owned Deployments When a stack plugin already owns a deployment path, use that plugin for stack-specific implementation details. For example, Fly.io deployment for Vapor or Hummingbird services belongs in `server-side-swift` because that workflow depends on Swift package, Dockerfile, health-check, and runtime conventions. ### Future Provider Skills -Add future provider skills as small routing or implementation slices. Good candidates include Cloudflare, Vercel, Fly.io, Azure, GCP, Terraform, Pulumi, and CDK when an official provider plugin does not already give Codex a better maintained path. +Add future provider skills as small routing or implementation slices. Good candidates include Cloudflare, Vercel, Fly.io, GCP, Terraform, Pulumi, and CDK when an official provider plugin does not already give Codex a better maintained path. ## Output Shape @@ -115,5 +136,6 @@ Return: - Do not invent provider setup steps when an official provider plugin or current provider docs own the path. - Do not configure or mutate cloud accounts without confirming account, region, profile, environment, and intended resource changes. - Do not store credentials, tokens, account IDs, secrets, local profiles, or `.env` files in git. -- Do not present an AWS CLI, AWS SAM CLI, or AWS MCP setup path as Socket-owned while AWS Agent Toolkit owns the official Codex path. +- Do not present AWS CLI, AWS SAM CLI, or AWS MCP setup as Socket-owned while AWS Agent Toolkit owns the official Codex path. +- Do not present Azure CLI, Azure Developer CLI, Azure MCP, Foundry MCP, or Azure Skills setup as Socket-owned while Microsoft's Azure Skills plugin owns the official Codex path. - Do not deploy to production by default. Use planning, validation, and explicit user confirmation before production mutations. diff --git a/plugins/cloud-inference-skills/.codex-plugin/plugin.json b/plugins/cloud-inference-skills/.codex-plugin/plugin.json index c67ee646..5f4bc007 100644 --- a/plugins/cloud-inference-skills/.codex-plugin/plugin.json +++ b/plugins/cloud-inference-skills/.codex-plugin/plugin.json @@ -1,6 +1,6 @@ { "name": "cloud-inference-skills", - "version": "9.21.0", + "version": "9.22.0", "description": "Cloud AI inference workflow skills for routing model serving, training, conversion, and GPU infrastructure work across Runpod, Hugging Face, AWS, Vast.ai, CoreWeave, and similar providers.", "author": { "name": "Gale", diff --git a/plugins/cybersecurity-skills/.codex-plugin/plugin.json b/plugins/cybersecurity-skills/.codex-plugin/plugin.json index b012feee..80adc757 100644 --- a/plugins/cybersecurity-skills/.codex-plugin/plugin.json +++ b/plugins/cybersecurity-skills/.codex-plugin/plugin.json @@ -1,6 +1,6 @@ { "name": "cybersecurity-skills", - "version": "9.21.0", + "version": "9.22.0", "description": "Defensive cybersecurity, isolated Linux and macOS analysis labs, suspicious-content and malware analysis, macOS defense, vulnerability testing, pentesting, and incident response workflows.", "skills": "./skills/", "author": { diff --git a/plugins/dotnet-skills/.codex-plugin/plugin.json b/plugins/dotnet-skills/.codex-plugin/plugin.json index d9b6d9cf..4fdb686b 100644 --- a/plugins/dotnet-skills/.codex-plugin/plugin.json +++ b/plugins/dotnet-skills/.codex-plugin/plugin.json @@ -1,7 +1,7 @@ { "name": "dotnet-skills", - "version": "9.21.0", - "description": "Codex skills for choosing, bootstrapping, building, testing, packaging, diagnosing, and maintaining .NET projects with F# and C# as equal first-party languages.", + "version": "9.22.0", + "description": "Codex skills for choosing, bootstrapping, building, testing, packaging, diagnosing, and maintaining .NET projects, including F# web applications, with F# and C# as equal first-party languages.", "author": { "name": "Gale", "email": "mail@galewilliams.com", @@ -16,13 +16,17 @@ "skills", "dotnet", "fsharp", + "giraffe", + "falco", + "oxpecker", + "aspnet-core", "csharp" ], "skills": "./skills/", "interface": { "displayName": ".NET Skills", "shortDescription": ".NET, F#, and C# workflow guidance for Codex.", - "longDescription": "Guide Codex agents through choosing .NET project shapes, bootstrapping reproducible solutions, building idiomatic F# and C# projects, running tests, validating packages, diagnosing failures, designing ASP.NET Core services, maintaining mixed-language boundaries, and aligning CI, upgrades, and tooling through the .NET CLI.", + "longDescription": "Guide Codex agents through choosing .NET project shapes, bootstrapping reproducible solutions, building idiomatic F# and C# projects, choosing and maintaining F# ASP.NET Core applications with Giraffe, Falco, or Oxpecker, running tests, validating packages, diagnosing failures, maintaining mixed-language boundaries, and aligning CI, upgrades, and tooling through the .NET CLI.", "developerName": "gaelic-ghost", "category": "Developer Tools", "capabilities": [ @@ -39,6 +43,8 @@ "Validate this .NET package surface without publishing it.", "Diagnose why this .NET restore, build, test, or pack command failed.", "Design the F# and C# boundary in this mixed .NET solution.", + "Choose the right F# web framework before building this ASP.NET Core application.", + "Build this Giraffe, Falco, or Oxpecker app idiomatically and test its endpoint contract.", "Align this .NET repo's CI, upgrade, formatting, and analyzer workflow." ], "brandColor": "#512BD4", diff --git a/plugins/dotnet-skills/skills/build-falco-web-app/SKILL.md b/plugins/dotnet-skills/skills/build-falco-web-app/SKILL.md new file mode 100644 index 00000000..d138cda2 --- /dev/null +++ b/plugins/dotnet-skills/skills/build-falco-web-app/SKILL.md @@ -0,0 +1,48 @@ +--- +name: build-falco-web-app +description: Build or modify a Falco web application in idiomatic F#, using functional routing, request and response helpers, explicit ASP.NET Core integration, security boundaries, and focused tests. +--- + +# Build Falco Web App + +Use Falco for its lightweight functional HTTP surface while leaving business +behavior as ordinary, testable F# code. + +## Source Check + +Read existing routes, the web host, project references, tests, and configuration +before editing. Consult [Falco's source and documentation](https://github.com/falcoframework/Falco) +and [ASP.NET Core documentation](https://learn.microsoft.com/aspnet/core/) for +current package behavior. + +## Workflow + +1. Confirm Falco is the selected framework; otherwise start with + `dotnet:choose-fsharp-web-framework`. +2. Define route handlers around one request job. Parse input, call a domain + function, then write one explicit response shape. +3. Keep routing declarative and readable. Split route groups by feature instead + of building one mutable registration surface. +4. Use the existing ASP.NET Core host for configuration, dependency registration, + authentication, authorization, logging, and rate or upload limits. Do not hide + those platform concerns in unrelated response helpers. +5. Treat HTML/view code as presentation. Keep it separate from request parsing, + authorization, and persistence behavior. +6. Test domain modules without a host, then add endpoint or integration coverage + for routes, input validation, auth decisions, and response contracts. + +## Validation + +Run the repository's targeted commands. If it has none, use: + +```zsh +dotnet build +dotnet test +``` + +## Boundaries + +- Preserve F# compile order and explicit task or async boundaries. +- Do not translate C# controller or service patterns mechanically into Falco. +- For Azure resources, hosting, monitoring, identity, or deployment, use the + official Azure Skills handoff rather than inventing provider commands here. diff --git a/plugins/dotnet-skills/skills/build-giraffe-web-app/SKILL.md b/plugins/dotnet-skills/skills/build-giraffe-web-app/SKILL.md new file mode 100644 index 00000000..fc95ddf7 --- /dev/null +++ b/plugins/dotnet-skills/skills/build-giraffe-web-app/SKILL.md @@ -0,0 +1,54 @@ +--- +name: build-giraffe-web-app +description: Build or modify a Giraffe web application in idiomatic F#, using composable HttpHandler functions, explicit ASP.NET Core integration, configuration, authentication, and focused endpoint tests. +--- + +# Build Giraffe Web App + +Use Giraffe's functional handler composition as the HTTP boundary, not as a +reason to place business rules in route declarations. + +## Source Check + +Inspect the existing host, package lock or project references, handlers, tests, +and configuration first. Use the [Giraffe documentation](https://giraffe.wiki/) +and [ASP.NET Core documentation](https://learn.microsoft.com/aspnet/core/) when +repository evidence is insufficient. + +## Workflow + +1. Confirm that Giraffe is already selected; otherwise use + `dotnet:choose-fsharp-web-framework` first. +2. Keep request parsing, authentication context, and response writing in narrow + `HttpHandler` functions. Compose reusable HTTP concerns with `>=>` only when + they have one clear request-pipeline responsibility. +3. Put domain transformations and external-dependency contracts in separately + testable F# modules. Pass dependencies explicitly or resolve genuine host + dependencies at a clear ASP.NET Core boundary. +4. Preserve ASP.NET Core ordering: routing, authentication, authorization, + static files, exception handling, and Giraffe middleware must remain aligned + with the application's existing host contract. +5. Make response errors specific: route, failed input or dependency, and the + safe client-facing outcome. Do not leak secrets or internal exception details. +6. Test pure domain behavior first, then handler or host behavior for route, + authorization, binding, status, and response regressions. + +## Validation + +Use the narrowest project commands available, normally: + +```zsh +dotnet build +dotnet test +``` + +Do not run a live deployment or add a replacement middleware stack merely to +exercise one handler. + +## Boundaries + +- Keep `.fsproj` file order valid as modules are added. +- Use ordinary ASP.NET Core middleware and services when that is the existing + integration surface; do not reimplement them as Giraffe helpers. +- Route Azure hosting, identity, resource configuration, and deployment work to + the official Azure Skills plugin through `cloud-deployment-routing-workflow`. diff --git a/plugins/dotnet-skills/skills/build-oxpecker-web-app/SKILL.md b/plugins/dotnet-skills/skills/build-oxpecker-web-app/SKILL.md new file mode 100644 index 00000000..89cd4a36 --- /dev/null +++ b/plugins/dotnet-skills/skills/build-oxpecker-web-app/SKILL.md @@ -0,0 +1,51 @@ +--- +name: build-oxpecker-web-app +description: Build or modify an Oxpecker web application in idiomatic F#, using endpoint routing, functional EndpointHandler and EndpointMiddleware composition, ASP.NET Core metadata, and focused endpoint tests. +--- + +# Build Oxpecker Web App + +Use Oxpecker's endpoint-routing model deliberately. Its F# DSL sits on ASP.NET +Core Endpoint Routing, so native endpoint metadata and middleware behavior remain +part of the application contract. + +## Source Check + +Inspect the existing host, endpoints, middleware, project references, tests, and +configuration. Use the [Oxpecker documentation](https://lanayx.github.io/Oxpecker/src/Oxpecker/) +and [ASP.NET Core routing documentation](https://learn.microsoft.com/aspnet/core/fundamentals/routing) +when local evidence does not answer the question. + +## Workflow + +1. Confirm Oxpecker is selected through `dotnet:choose-fsharp-web-framework`. +2. Model one endpoint as an `EndpointHandler`: validate or bind input, invoke a + focused domain operation, and produce the response. +3. Use `EndpointMiddleware` for a reusable pipeline concern with an explicit + before/after or short-circuit behavior. Do not use it as a generic service + locator or business-rule container. +4. Keep route patterns, HTTP methods, authorization requirements, tags, and + other endpoint metadata co-located enough to review as one API contract. +5. Continue using ASP.NET Core for host configuration, authentication, + authorization, logging, and cross-cutting middleware. Preserve its pipeline + ordering when introducing Oxpecker endpoints. +6. Test domain behavior independently and endpoint behavior for routing, binding, + status, metadata, authorization, and serialized response contracts. + +## Validation + +Use the smallest project-level validation available, normally: + +```zsh +dotnet build +dotnet test +``` + +## Boundaries + +- Keep `.fsproj` file ordering explicit and preserve `Task` boundaries at the + `HttpContext` edge. +- Do not assume Giraffe handlers or middleware map mechanically to Oxpecker; + migrate only with an explicit route and test-contract review. +- Use the official Azure Skills plugin for Azure architecture, provisioning, + diagnostics, and deployment decisions. diff --git a/plugins/dotnet-skills/skills/choose-fsharp-web-framework/SKILL.md b/plugins/dotnet-skills/skills/choose-fsharp-web-framework/SKILL.md new file mode 100644 index 00000000..59b848a8 --- /dev/null +++ b/plugins/dotnet-skills/skills/choose-fsharp-web-framework/SKILL.md @@ -0,0 +1,66 @@ +--- +name: choose-fsharp-web-framework +description: Choose an F# web application framework before implementation, comparing ASP.NET Core Minimal APIs, Giraffe, Falco, Oxpecker, and Saturn by application shape, composition model, dependencies, testing, and deployment boundaries. +--- + +# Choose F# Web Framework + +Choose the web surface before scaffolding. Keep the application's F# domain model, +HTTP host, persistence, and deployment decision explicit instead of treating a +framework DSL as the whole architecture. + +## Source Check + +Inspect the repository and its locked packages first. When a current framework +behavior matters, use its official documentation before generating code: + +- [ASP.NET Core Minimal APIs](https://learn.microsoft.com/aspnet/core/fundamentals/minimal-apis) +- [Giraffe](https://giraffe.wiki/) +- [Falco](https://github.com/falcoframework/Falco) +- [Oxpecker](https://lanayx.github.io/Oxpecker/src/Oxpecker/) +- [Saturn](https://saturnframework.org/) + +## Selection + +| Need | Default fit | Why | +| --- | --- | --- | +| Small service using standard ASP.NET endpoint conventions | Minimal APIs | Least extra framework surface; keep idiomatic F# modules around the host. | +| Composable middleware-style functional handlers | Giraffe | `HttpHandler` composition over the ASP.NET Core pipeline. | +| Lightweight functional API or full-stack server toolkit | Falco | Direct routing and response helpers with ordinary ASP.NET Core integration. | +| Endpoint-routing / Minimal-API-shaped F# DSL | Oxpecker | F# endpoint handlers and middleware on ASP.NET Core Endpoint Routing. | +| Established convention-heavy F# MVC application | Saturn | Use only when its MVC/scaffolding shape is desired by the project. | + +Do not select from popularity alone. Check existing package choices, team +experience, endpoint style, HTML/view needs, authentication, hosting, and how +much framework-specific API the project is willing to own. + +## Workflow + +1. Classify the application: API, HTML server app, webhook, internal tool, + background worker with health endpoints, or full-stack application. +2. Inspect its existing ASP.NET Core host, package versions, test harness, + configuration, and deployment files. +3. State the chosen framework and why the alternatives do not fit this project. +4. Keep domain operations in F# modules independent of HTTP handlers. +5. Use the matching framework skill for Giraffe, Falco, or Oxpecker. For Minimal + APIs use `dotnet:aspnet-core-service-workflow`; for Saturn, inspect its local + conventions and official documentation before making framework-specific edits. +6. Select the smallest useful test level and run `dotnet build` plus the relevant + `dotnet test` command. + +## Boundaries + +- SAFE Stack, Fable, Bolero, WebSharper, and browser-client architecture are + separate decisions; do not imply that a server framework selects a client. +- Keep F# compile order deliberate in `.fsproj` files. +- Do not introduce a repository, service, or view-model layer merely to mirror a + framework's API. Name the concrete external dependency or reuse boundary first. +- For Azure architecture, provisioning, diagnostics, or deployment, hand off to + the official Microsoft Azure Skills plugin through the cloud deployment routing + workflow; do not duplicate its MCP or infrastructure guidance here. + +## Output + +Return the application shape, selected framework, rejected alternatives, host and +domain ownership, test approach, Azure handoff if applicable, and exact validation +commands. diff --git a/plugins/game-dev-skills/.codex-plugin/plugin.json b/plugins/game-dev-skills/.codex-plugin/plugin.json index 7c974f0c..1eee810d 100644 --- a/plugins/game-dev-skills/.codex-plugin/plugin.json +++ b/plugins/game-dev-skills/.codex-plugin/plugin.json @@ -1,6 +1,6 @@ { "name": "game-dev-skills", - "version": "9.21.0", + "version": "9.22.0", "description": "Apple platform game development workflow skills for native Metal rendering, Game Porting Toolkit routing, MetalFX, GPU asset streaming, neural rendering, frameworks, input, haptics, and profiling.", "author": { "name": "Gale", diff --git a/plugins/messaging-collaboration-skills/.codex-plugin/plugin.json b/plugins/messaging-collaboration-skills/.codex-plugin/plugin.json index f4c76813..c9cc1691 100644 --- a/plugins/messaging-collaboration-skills/.codex-plugin/plugin.json +++ b/plugins/messaging-collaboration-skills/.codex-plugin/plugin.json @@ -1,6 +1,6 @@ { "name": "messaging-collaboration-skills", - "version": "9.21.0", + "version": "9.22.0", "description": "Codex workflows for chat apps, bots, collaboration, iMessage, Apple notifications and Push to Talk, VoIP, and default communication-app planning.", "author": { "name": "Gale", diff --git a/plugins/model-lab-skills/.codex-plugin/plugin.json b/plugins/model-lab-skills/.codex-plugin/plugin.json index f247a9dc..78328eb2 100644 --- a/plugins/model-lab-skills/.codex-plugin/plugin.json +++ b/plugins/model-lab-skills/.codex-plugin/plugin.json @@ -1,6 +1,6 @@ { "name": "model-lab-skills", - "version": "9.21.0", + "version": "9.22.0", "description": "Reproducible model training, evaluation, intervention, and runtime research workflows.", "author": { "name": "Gale" diff --git a/plugins/network-protocol-skills/.codex-plugin/plugin.json b/plugins/network-protocol-skills/.codex-plugin/plugin.json index 39aba367..a8ca5da6 100644 --- a/plugins/network-protocol-skills/.codex-plugin/plugin.json +++ b/plugins/network-protocol-skills/.codex-plugin/plugin.json @@ -1,6 +1,6 @@ { "name": "network-protocol-skills", - "version": "9.21.0", + "version": "9.22.0", "description": "Codex skills for choosing, planning, implementing, and diagnosing modern application transports and real-time networking protocols, including QUIC, HTTP/3, WebRTC, Media over QUIC, WebTransport-adjacent handoffs, protocol maturity checks, and stack-specific implementation routing.", "author": { "name": "Gale", diff --git a/plugins/productivity-skills/.codex-plugin/plugin.json b/plugins/productivity-skills/.codex-plugin/plugin.json index e36994ba..35faa7d3 100644 --- a/plugins/productivity-skills/.codex-plugin/plugin.json +++ b/plugins/productivity-skills/.codex-plugin/plugin.json @@ -1,6 +1,6 @@ { "name": "productivity-skills", - "version": "9.21.0", + "version": "9.22.0", "description": "Broadly useful productivity workflows for Codex.", "author": { "name": "Gale", diff --git a/plugins/productivity-skills/pyproject.toml b/plugins/productivity-skills/pyproject.toml index 9a8e3605..3f2af644 100644 --- a/plugins/productivity-skills/pyproject.toml +++ b/plugins/productivity-skills/pyproject.toml @@ -1,6 +1,6 @@ [project] name = "productivity-skills-maintenance" -version = "9.21.0" +version = "9.22.0" description = "Maintainer-only Python tooling baseline for productivity-skills." requires-python = ">=3.11" dependencies = [] diff --git a/plugins/productivity-skills/uv.lock b/plugins/productivity-skills/uv.lock index d2feec5a..38e56760 100644 --- a/plugins/productivity-skills/uv.lock +++ b/plugins/productivity-skills/uv.lock @@ -228,7 +228,7 @@ wheels = [ [[package]] name = "productivity-skills-maintenance" -version = "9.21.0" +version = "9.22.0" source = { virtual = "." } [package.dev-dependencies] diff --git a/plugins/python-skills/.codex-plugin/plugin.json b/plugins/python-skills/.codex-plugin/plugin.json index 0234c896..53b7844f 100644 --- a/plugins/python-skills/.codex-plugin/plugin.json +++ b/plugins/python-skills/.codex-plugin/plugin.json @@ -1,6 +1,6 @@ { "name": "python-skills", - "version": "9.21.0", + "version": "9.22.0", "description": "Bundled Python-focused Codex skills for uv bootstrapping, project implementation, diagnostics, packaging, tooling, CI, upgrades, FastAPI, FastMCP, and pytest workflows.", "author": { "name": "Gale", diff --git a/plugins/python-skills/pyproject.toml b/plugins/python-skills/pyproject.toml index 95b9c454..eaaed7ca 100644 --- a/plugins/python-skills/pyproject.toml +++ b/plugins/python-skills/pyproject.toml @@ -1,6 +1,6 @@ [project] name = "python-skills-maintainer" -version = "9.21.0" +version = "9.22.0" description = "Maintainer tooling for the python-skills repository" requires-python = ">=3.11" dependencies = [] diff --git a/plugins/python-skills/uv.lock b/plugins/python-skills/uv.lock index 692e0e01..962edcf5 100644 --- a/plugins/python-skills/uv.lock +++ b/plugins/python-skills/uv.lock @@ -251,7 +251,7 @@ wheels = [ [[package]] name = "python-skills-maintainer" -version = "9.21.0" +version = "9.22.0" source = { virtual = "." } [package.dev-dependencies] diff --git a/plugins/reverse-engineering-skills/.codex-plugin/plugin.json b/plugins/reverse-engineering-skills/.codex-plugin/plugin.json index 5c75394c..40531f11 100644 --- a/plugins/reverse-engineering-skills/.codex-plugin/plugin.json +++ b/plugins/reverse-engineering-skills/.codex-plugin/plugin.json @@ -1,6 +1,6 @@ { "name": "reverse-engineering-skills", - "version": "9.21.0", + "version": "9.22.0", "description": "Workflow skills for reverse engineering, decompilation, disassembly, symbols, artifact analysis, and exact-build macOS security-control research.", "skills": "./skills/", "author": { diff --git a/plugins/rust-skills/.codex-plugin/plugin.json b/plugins/rust-skills/.codex-plugin/plugin.json index 35945208..af7c7823 100644 --- a/plugins/rust-skills/.codex-plugin/plugin.json +++ b/plugins/rust-skills/.codex-plugin/plugin.json @@ -1,6 +1,6 @@ { "name": "rust-skills", - "version": "9.21.0", + "version": "9.22.0", "description": "Rust, Cargo, rustup, crate, workspace, CLI, library, package, CI, testing, linting, and formatting workflow skills.", "skills": "./skills/", "author": { diff --git a/plugins/server-side-jvm/.codex-plugin/plugin.json b/plugins/server-side-jvm/.codex-plugin/plugin.json index 12f72702..fb13952a 100644 --- a/plugins/server-side-jvm/.codex-plugin/plugin.json +++ b/plugins/server-side-jvm/.codex-plugin/plugin.json @@ -1,6 +1,6 @@ { "name": "server-side-jvm", - "version": "9.21.0", + "version": "9.22.0", "description": "Codex skills for choosing, building, testing, and maintaining server-side JVM backend projects with Java and Scala as equal first-party languages and future Clojure support planned.", "author": { "name": "Gale", diff --git a/plugins/server-side-swift/.codex-plugin/plugin.json b/plugins/server-side-swift/.codex-plugin/plugin.json index 5f0da906..c7ef670d 100644 --- a/plugins/server-side-swift/.codex-plugin/plugin.json +++ b/plugins/server-side-swift/.codex-plugin/plugin.json @@ -1,6 +1,6 @@ { "name": "server-side-swift", - "version": "9.21.0", + "version": "9.22.0", "description": "Codex skills for bootstrapping, syncing, building, running, containerizing, deploying, and maintaining server-side Swift services, including Vapor, Hummingbird, hb, persistence, Swift OpenAPI, RPC-fit decisions, SwiftNIO, observability, auth, app sync, Docker, Apple Containerization, Fly.io, and SwiftPM-first workflows.", "author": { "name": "Gale", diff --git a/plugins/spotify/.codex-plugin/plugin.json b/plugins/spotify/.codex-plugin/plugin.json index eb0fef94..f445f666 100644 --- a/plugins/spotify/.codex-plugin/plugin.json +++ b/plugins/spotify/.codex-plugin/plugin.json @@ -1,6 +1,6 @@ { "name": "spotify", - "version": "9.21.0", + "version": "9.22.0", "description": "Placeholder plugin repository for future Spotify-focused Codex workflows.", "author": { "name": "Gale", diff --git a/plugins/swift-lang/.codex-plugin/plugin.json b/plugins/swift-lang/.codex-plugin/plugin.json index bf30c46d..c15f6431 100644 --- a/plugins/swift-lang/.codex-plugin/plugin.json +++ b/plugins/swift-lang/.codex-plugin/plugin.json @@ -1,6 +1,6 @@ { "name": "swift-lang", - "version": "9.21.0", + "version": "9.22.0", "description": "Shared Swift language and tooling skills for API style, errors, functional pipelines, formatting, source organization, SwiftSyntax, compiler inspection, SourceKit, indexing, SourceKit-LSP, and modernization.", "skills": "./skills/", "author": { diff --git a/plugins/swiftasb-skills/.codex-plugin/plugin.json b/plugins/swiftasb-skills/.codex-plugin/plugin.json index dc8144d7..af35f07b 100644 --- a/plugins/swiftasb-skills/.codex-plugin/plugin.json +++ b/plugins/swiftasb-skills/.codex-plugin/plugin.json @@ -1,6 +1,6 @@ { "name": "swiftasb-skills", - "version": "9.21.0", + "version": "9.22.0", "description": "Codex skills for explaining SwiftASB and building SwiftUI, AppKit, and Swift package integrations on top of it.", "author": { "name": "Gale", diff --git a/plugins/things-app/.codex-plugin/plugin.json b/plugins/things-app/.codex-plugin/plugin.json index dca49f25..f0ceba02 100644 --- a/plugins/things-app/.codex-plugin/plugin.json +++ b/plugins/things-app/.codex-plugin/plugin.json @@ -1,6 +1,6 @@ { "name": "things-app", - "version": "9.21.0", + "version": "9.22.0", "description": "Things.app skills and a bundled local MCP server for reminders, planning digests, and structured task workflows.", "author": { "name": "Gale", diff --git a/plugins/things-app/mcp/pyproject.toml b/plugins/things-app/mcp/pyproject.toml index a44832f7..76fffaab 100644 --- a/plugins/things-app/mcp/pyproject.toml +++ b/plugins/things-app/mcp/pyproject.toml @@ -7,7 +7,7 @@ packages = ["app"] [project] name = "things-mcp" -version = "9.21.0" +version = "9.22.0" requires-python = ">=3.13" dependencies = [ "fastmcp>=3.0.2", diff --git a/plugins/things-app/mcp/uv.lock b/plugins/things-app/mcp/uv.lock index 9c9b7377..f52f639a 100644 --- a/plugins/things-app/mcp/uv.lock +++ b/plugins/things-app/mcp/uv.lock @@ -1244,7 +1244,7 @@ wheels = [ [[package]] name = "things-mcp" -version = "9.21.0" +version = "9.22.0" source = { editable = "." } dependencies = [ { name = "fastmcp" }, diff --git a/plugins/things-app/pyproject.toml b/plugins/things-app/pyproject.toml index 55d9717f..16565bf0 100644 --- a/plugins/things-app/pyproject.toml +++ b/plugins/things-app/pyproject.toml @@ -1,6 +1,6 @@ [project] name = "things-app-maintenance" -version = "9.21.0" +version = "9.22.0" description = "Maintainer-only Python tooling baseline for things-app skills and plugin packaging." requires-python = ">=3.11" dependencies = [] diff --git a/plugins/things-app/uv.lock b/plugins/things-app/uv.lock index 8b3f982b..e9670a19 100644 --- a/plugins/things-app/uv.lock +++ b/plugins/things-app/uv.lock @@ -120,7 +120,7 @@ wheels = [ [[package]] name = "things-app-maintenance" -version = "9.21.0" +version = "9.22.0" source = { virtual = "." } [package.dev-dependencies] diff --git a/plugins/web-dev-skills/.codex-plugin/plugin.json b/plugins/web-dev-skills/.codex-plugin/plugin.json index a20140ec..7e325996 100644 --- a/plugins/web-dev-skills/.codex-plugin/plugin.json +++ b/plugins/web-dev-skills/.codex-plugin/plugin.json @@ -1,6 +1,6 @@ { "name": "web-dev-skills", - "version": "9.21.0", + "version": "9.22.0", "description": "Codex skills for focused web and Expo native-boundary workflows.", "author": { "name": "Gale", diff --git a/pyproject.toml b/pyproject.toml index 17439945..5a2ffb53 100644 --- a/pyproject.toml +++ b/pyproject.toml @@ -1,6 +1,6 @@ [project] name = "socket-maintenance" -version = "9.21.0" +version = "9.22.0" description = "Root uv tooling baseline for the socket superproject." requires-python = ">=3.11" dependencies = [] diff --git a/scripts/export_hermes_skills.py b/scripts/export_hermes_skills.py index fb203643..e1d79ecc 100644 --- a/scripts/export_hermes_skills.py +++ b/scripts/export_hermes_skills.py @@ -23,6 +23,8 @@ SERVER_SIDE_SWIFT_SOURCE_ROOT = REPO_ROOT / "plugins" / "server-side-swift" / "skills" SWIFT_LANG_SOURCE_ROOT = REPO_ROOT / "plugins" / "swift-lang" / "skills" MODEL_LAB_SOURCE_ROOT = REPO_ROOT / "plugins" / "model-lab-skills" / "skills" +DOTNET_SOURCE_ROOT = REPO_ROOT / "plugins" / "dotnet-skills" / "skills" +CLOUD_DEPLOYMENT_SOURCE_ROOT = REPO_ROOT / "plugins" / "cloud-deployment-skills" / "skills" EXPORT_ROOT = REPO_ROOT / "skills" AGENT_PORTABILITY_SKILLS = ( "bootstrap-skills-plugin-repo", @@ -126,6 +128,13 @@ "evaluate-tool-calling-model", "benchmark-model-runtime", ) +DOTNET_SKILLS = ( + "choose-fsharp-web-framework", + "build-giraffe-web-app", + "build-falco-web-app", + "build-oxpecker-web-app", +) +CLOUD_DEPLOYMENT_SKILLS = ("cloud-deployment-routing-workflow",) EXPORTED_SKILLS = ( AGENT_PORTABILITY_SKILLS + MESSAGING_SKILLS @@ -135,6 +144,8 @@ + REVERSE_ENGINEERING_SKILLS + SWIFT_LANG_SKILLS + MODEL_LAB_SKILLS + + DOTNET_SKILLS + + CLOUD_DEPLOYMENT_SKILLS ) @@ -162,6 +173,11 @@ def source_paths(source_root: Path | None = None) -> dict[str, Path]: }, **{skill_name: SWIFT_LANG_SOURCE_ROOT for skill_name in SWIFT_LANG_SKILLS}, **{skill_name: MODEL_LAB_SOURCE_ROOT for skill_name in MODEL_LAB_SKILLS}, + **{skill_name: DOTNET_SOURCE_ROOT for skill_name in DOTNET_SKILLS}, + **{ + skill_name: CLOUD_DEPLOYMENT_SOURCE_ROOT + for skill_name in CLOUD_DEPLOYMENT_SKILLS + }, } return { skill_name: roots[skill_name] / skill_name for skill_name in EXPORTED_SKILLS diff --git a/skills.sh.json b/skills.sh.json index 526a950d..924379e1 100644 --- a/skills.sh.json +++ b/skills.sh.json @@ -89,6 +89,21 @@ "apple-containerization-workflow" ] }, + { + "title": ".NET Skills", + "skills": [ + "choose-fsharp-web-framework", + "build-giraffe-web-app", + "build-falco-web-app", + "build-oxpecker-web-app" + ] + }, + { + "title": "Cloud Deployment Skills", + "skills": [ + "cloud-deployment-routing-workflow" + ] + }, { "title": "Reverse Engineering Skills", "skills": [ diff --git a/skills/build-falco-web-app/SKILL.md b/skills/build-falco-web-app/SKILL.md new file mode 100644 index 00000000..d138cda2 --- /dev/null +++ b/skills/build-falco-web-app/SKILL.md @@ -0,0 +1,48 @@ +--- +name: build-falco-web-app +description: Build or modify a Falco web application in idiomatic F#, using functional routing, request and response helpers, explicit ASP.NET Core integration, security boundaries, and focused tests. +--- + +# Build Falco Web App + +Use Falco for its lightweight functional HTTP surface while leaving business +behavior as ordinary, testable F# code. + +## Source Check + +Read existing routes, the web host, project references, tests, and configuration +before editing. Consult [Falco's source and documentation](https://github.com/falcoframework/Falco) +and [ASP.NET Core documentation](https://learn.microsoft.com/aspnet/core/) for +current package behavior. + +## Workflow + +1. Confirm Falco is the selected framework; otherwise start with + `dotnet:choose-fsharp-web-framework`. +2. Define route handlers around one request job. Parse input, call a domain + function, then write one explicit response shape. +3. Keep routing declarative and readable. Split route groups by feature instead + of building one mutable registration surface. +4. Use the existing ASP.NET Core host for configuration, dependency registration, + authentication, authorization, logging, and rate or upload limits. Do not hide + those platform concerns in unrelated response helpers. +5. Treat HTML/view code as presentation. Keep it separate from request parsing, + authorization, and persistence behavior. +6. Test domain modules without a host, then add endpoint or integration coverage + for routes, input validation, auth decisions, and response contracts. + +## Validation + +Run the repository's targeted commands. If it has none, use: + +```zsh +dotnet build +dotnet test +``` + +## Boundaries + +- Preserve F# compile order and explicit task or async boundaries. +- Do not translate C# controller or service patterns mechanically into Falco. +- For Azure resources, hosting, monitoring, identity, or deployment, use the + official Azure Skills handoff rather than inventing provider commands here. diff --git a/skills/build-giraffe-web-app/SKILL.md b/skills/build-giraffe-web-app/SKILL.md new file mode 100644 index 00000000..fc95ddf7 --- /dev/null +++ b/skills/build-giraffe-web-app/SKILL.md @@ -0,0 +1,54 @@ +--- +name: build-giraffe-web-app +description: Build or modify a Giraffe web application in idiomatic F#, using composable HttpHandler functions, explicit ASP.NET Core integration, configuration, authentication, and focused endpoint tests. +--- + +# Build Giraffe Web App + +Use Giraffe's functional handler composition as the HTTP boundary, not as a +reason to place business rules in route declarations. + +## Source Check + +Inspect the existing host, package lock or project references, handlers, tests, +and configuration first. Use the [Giraffe documentation](https://giraffe.wiki/) +and [ASP.NET Core documentation](https://learn.microsoft.com/aspnet/core/) when +repository evidence is insufficient. + +## Workflow + +1. Confirm that Giraffe is already selected; otherwise use + `dotnet:choose-fsharp-web-framework` first. +2. Keep request parsing, authentication context, and response writing in narrow + `HttpHandler` functions. Compose reusable HTTP concerns with `>=>` only when + they have one clear request-pipeline responsibility. +3. Put domain transformations and external-dependency contracts in separately + testable F# modules. Pass dependencies explicitly or resolve genuine host + dependencies at a clear ASP.NET Core boundary. +4. Preserve ASP.NET Core ordering: routing, authentication, authorization, + static files, exception handling, and Giraffe middleware must remain aligned + with the application's existing host contract. +5. Make response errors specific: route, failed input or dependency, and the + safe client-facing outcome. Do not leak secrets or internal exception details. +6. Test pure domain behavior first, then handler or host behavior for route, + authorization, binding, status, and response regressions. + +## Validation + +Use the narrowest project commands available, normally: + +```zsh +dotnet build +dotnet test +``` + +Do not run a live deployment or add a replacement middleware stack merely to +exercise one handler. + +## Boundaries + +- Keep `.fsproj` file order valid as modules are added. +- Use ordinary ASP.NET Core middleware and services when that is the existing + integration surface; do not reimplement them as Giraffe helpers. +- Route Azure hosting, identity, resource configuration, and deployment work to + the official Azure Skills plugin through `cloud-deployment-routing-workflow`. diff --git a/skills/build-oxpecker-web-app/SKILL.md b/skills/build-oxpecker-web-app/SKILL.md new file mode 100644 index 00000000..89cd4a36 --- /dev/null +++ b/skills/build-oxpecker-web-app/SKILL.md @@ -0,0 +1,51 @@ +--- +name: build-oxpecker-web-app +description: Build or modify an Oxpecker web application in idiomatic F#, using endpoint routing, functional EndpointHandler and EndpointMiddleware composition, ASP.NET Core metadata, and focused endpoint tests. +--- + +# Build Oxpecker Web App + +Use Oxpecker's endpoint-routing model deliberately. Its F# DSL sits on ASP.NET +Core Endpoint Routing, so native endpoint metadata and middleware behavior remain +part of the application contract. + +## Source Check + +Inspect the existing host, endpoints, middleware, project references, tests, and +configuration. Use the [Oxpecker documentation](https://lanayx.github.io/Oxpecker/src/Oxpecker/) +and [ASP.NET Core routing documentation](https://learn.microsoft.com/aspnet/core/fundamentals/routing) +when local evidence does not answer the question. + +## Workflow + +1. Confirm Oxpecker is selected through `dotnet:choose-fsharp-web-framework`. +2. Model one endpoint as an `EndpointHandler`: validate or bind input, invoke a + focused domain operation, and produce the response. +3. Use `EndpointMiddleware` for a reusable pipeline concern with an explicit + before/after or short-circuit behavior. Do not use it as a generic service + locator or business-rule container. +4. Keep route patterns, HTTP methods, authorization requirements, tags, and + other endpoint metadata co-located enough to review as one API contract. +5. Continue using ASP.NET Core for host configuration, authentication, + authorization, logging, and cross-cutting middleware. Preserve its pipeline + ordering when introducing Oxpecker endpoints. +6. Test domain behavior independently and endpoint behavior for routing, binding, + status, metadata, authorization, and serialized response contracts. + +## Validation + +Use the smallest project-level validation available, normally: + +```zsh +dotnet build +dotnet test +``` + +## Boundaries + +- Keep `.fsproj` file ordering explicit and preserve `Task` boundaries at the + `HttpContext` edge. +- Do not assume Giraffe handlers or middleware map mechanically to Oxpecker; + migrate only with an explicit route and test-contract review. +- Use the official Azure Skills plugin for Azure architecture, provisioning, + diagnostics, and deployment decisions. diff --git a/skills/choose-fsharp-web-framework/SKILL.md b/skills/choose-fsharp-web-framework/SKILL.md new file mode 100644 index 00000000..59b848a8 --- /dev/null +++ b/skills/choose-fsharp-web-framework/SKILL.md @@ -0,0 +1,66 @@ +--- +name: choose-fsharp-web-framework +description: Choose an F# web application framework before implementation, comparing ASP.NET Core Minimal APIs, Giraffe, Falco, Oxpecker, and Saturn by application shape, composition model, dependencies, testing, and deployment boundaries. +--- + +# Choose F# Web Framework + +Choose the web surface before scaffolding. Keep the application's F# domain model, +HTTP host, persistence, and deployment decision explicit instead of treating a +framework DSL as the whole architecture. + +## Source Check + +Inspect the repository and its locked packages first. When a current framework +behavior matters, use its official documentation before generating code: + +- [ASP.NET Core Minimal APIs](https://learn.microsoft.com/aspnet/core/fundamentals/minimal-apis) +- [Giraffe](https://giraffe.wiki/) +- [Falco](https://github.com/falcoframework/Falco) +- [Oxpecker](https://lanayx.github.io/Oxpecker/src/Oxpecker/) +- [Saturn](https://saturnframework.org/) + +## Selection + +| Need | Default fit | Why | +| --- | --- | --- | +| Small service using standard ASP.NET endpoint conventions | Minimal APIs | Least extra framework surface; keep idiomatic F# modules around the host. | +| Composable middleware-style functional handlers | Giraffe | `HttpHandler` composition over the ASP.NET Core pipeline. | +| Lightweight functional API or full-stack server toolkit | Falco | Direct routing and response helpers with ordinary ASP.NET Core integration. | +| Endpoint-routing / Minimal-API-shaped F# DSL | Oxpecker | F# endpoint handlers and middleware on ASP.NET Core Endpoint Routing. | +| Established convention-heavy F# MVC application | Saturn | Use only when its MVC/scaffolding shape is desired by the project. | + +Do not select from popularity alone. Check existing package choices, team +experience, endpoint style, HTML/view needs, authentication, hosting, and how +much framework-specific API the project is willing to own. + +## Workflow + +1. Classify the application: API, HTML server app, webhook, internal tool, + background worker with health endpoints, or full-stack application. +2. Inspect its existing ASP.NET Core host, package versions, test harness, + configuration, and deployment files. +3. State the chosen framework and why the alternatives do not fit this project. +4. Keep domain operations in F# modules independent of HTTP handlers. +5. Use the matching framework skill for Giraffe, Falco, or Oxpecker. For Minimal + APIs use `dotnet:aspnet-core-service-workflow`; for Saturn, inspect its local + conventions and official documentation before making framework-specific edits. +6. Select the smallest useful test level and run `dotnet build` plus the relevant + `dotnet test` command. + +## Boundaries + +- SAFE Stack, Fable, Bolero, WebSharper, and browser-client architecture are + separate decisions; do not imply that a server framework selects a client. +- Keep F# compile order deliberate in `.fsproj` files. +- Do not introduce a repository, service, or view-model layer merely to mirror a + framework's API. Name the concrete external dependency or reuse boundary first. +- For Azure architecture, provisioning, diagnostics, or deployment, hand off to + the official Microsoft Azure Skills plugin through the cloud deployment routing + workflow; do not duplicate its MCP or infrastructure guidance here. + +## Output + +Return the application shape, selected framework, rejected alternatives, host and +domain ownership, test approach, Azure handoff if applicable, and exact validation +commands. diff --git a/skills/cloud-deployment-routing-workflow/SKILL.md b/skills/cloud-deployment-routing-workflow/SKILL.md new file mode 100644 index 00000000..677a4a21 --- /dev/null +++ b/skills/cloud-deployment-routing-workflow/SKILL.md @@ -0,0 +1,141 @@ +--- +name: cloud-deployment-routing-workflow +description: Choose a cloud deployment path before implementation. Route AWS work to the official AWS Agent Toolkit and Azure work to Microsoft's Azure Skills plugin while keeping credentials, regions, and mutation boundaries explicit. +license: Apache-2.0 +compatibility: Designed for Codex and compatible Agent Skills clients working with cloud deployments, provider CLIs, provider plugins, MCP servers, and repository-owned deployment configuration. +metadata: + owner: gaelic-ghost + repo: socket + category: cloud-deployment-routing +allowed-tools: Read Bash(rg:*) Bash(git:*) Bash(codex:*) Bash(aws:*) Bash(uv:*) Bash(uvx:*) +--- + +# Cloud Deployment Routing Workflow + +## Purpose + +Choose the smallest correct cloud deployment path before changing infrastructure, credentials, or production-facing configuration. + +The practical decision is whether the agent should use an official provider plugin, a provider MCP server, a provider CLI, a framework-owned deployment workflow, or a Socket-owned provider skill. + +## When To Use + +- Use this skill when the user wants cloud deployment help and has not chosen a provider-owned workflow. +- Use this skill when a project mentions AWS, Cloudflare, Vercel, Fly.io, Azure, GCP, Terraform, Pulumi, CDK, CloudFormation, SAM, containers, serverless, hosting, DNS, secrets, deployment, or production infrastructure. +- Use this skill before adding provider credentials, changing cloud resources, deploying production services, or wiring new MCP server configuration. +- Use this skill when an official provider plugin may already own the requested work. + +## Source Check + +Use repo-local deployment files, checked-out provider config, installed provider CLIs, official provider plugins, and official provider documentation before making claims about current deployment behavior: + +- [Agent Toolkit for AWS](https://github.com/aws/agent-toolkit-for-aws) +- [AWS Agent Toolkit plugins](https://docs.aws.amazon.com/agent-toolkit/latest/userguide/plugins.html) +- [AWS MCP Server setup](https://docs.aws.amazon.com/agent-toolkit/latest/userguide/getting-started-aws-mcp-server.html) +- [AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/) +- [AWS SAM CLI](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/what-is-sam.html) +- [Azure Skills](https://github.com/microsoft/azure-skills) +- [Azure MCP Server](https://learn.microsoft.com/azure/developer/azure-mcp-server/) +- [Azure Developer CLI](https://learn.microsoft.com/azure/developer/azure-developer-cli/) + +Translate any documentation rule into the concrete repository decision it changes. + +## Routing Workflow + +1. Inspect the project shape: + - deployment manifests such as `template.yaml`, `serverless.yml`, `cloudformation.yml`, `cdk.json`, `samconfig.toml`, `wrangler.toml`, `vercel.json`, `fly.toml`, `Dockerfile`, `compose.yaml`, Terraform, or Pulumi files + - package scripts, Make targets, CI workflows, release docs, and provider-specific README sections + - existing credentials guidance, environment variables, account aliases, regions, profiles, and secret names +2. Identify the deployment job: + - provider selection + - local credential setup + - documentation lookup + - infrastructure planning + - preview or diff + - dev/staging deploy + - production deploy + - failure triage + - cost, IAM, observability, or rollback review +3. Route AWS work first: + - Prefer the official AWS Agent Toolkit for AWS for Codex when the task is general AWS discovery, AWS MCP access, AWS CLI or AWS SAM setup, CDK, CloudFormation, serverless, containers, storage, observability, billing, SDK usage, or deployment. + - Install path for Codex users: + + ```bash + codex plugin marketplace add aws/agent-toolkit-for-aws + ``` + + Then use `/plugins` in Codex to install `aws-core`. + - Do not duplicate AWS MCP configuration in Socket while `aws-core` bundles that configuration. + - Do not copy AWS Agent Toolkit skills into Socket. +4. Route non-AWS work: + - For Azure, prefer Microsoft's Azure Skills plugin for Azure MCP, Foundry MCP, + preparation, validation, deployment, diagnostics, cost, RBAC, and service + guidance. Add its marketplace with `codex plugin marketplace add + microsoft/azure-skills`, then install `azure` through `/plugins`. + - Do not duplicate Azure MCP declarations, Azure CLI or Azure Developer CLI + setup, Azure Skills workflows, or account-specific IaC in Socket. + - Use a first-party provider plugin or MCP server when one exists and is current. + - Use framework-owned Socket skills when the deployment surface is already covered by a stack workflow, such as `server-side-swift:fly-io-deployment-workflow`. + - Add or use a Socket-owned provider skill only when no official provider-owned agent surface exists or when Socket needs a small provider-neutral decision layer. +5. Confirm mutation boundaries: + - account or organization + - project or app + - region + - profile or identity + - environment such as local, dev, staging, or production + - exact resource mutations + - expected cost or billing effect + - rollback or cleanup path +6. Choose validation: + - read-only documentation or discovery query for planning + - provider CLI version and auth check for local setup + - plan, diff, dry-run, validate, package, or synth command before deploy + - smoke test, logs, metrics, and rollback checks after deploy + +## Recommendations + +### AWS + +Use the official AWS Agent Toolkit for AWS as the default Codex path. It owns AWS MCP setup and the curated AWS skill set, including common deployment, CDK, CloudFormation, serverless, container, storage, observability, billing, and SDK workflows. + +Use Socket only for the routing decision, local repo handoff, and any project-specific deployment guardrails that the official AWS plugin does not know. + +### Azure + +Use Microsoft's Azure Skills plugin as the default Codex path. It owns Azure MCP +and Foundry MCP configuration plus the provider workflows for preparation, +validation, deployment, diagnostics, cost, identity, and Azure services. + +Use Socket only to select that official surface, preserve repository-specific +deployment boundaries, and hand framework implementation back to the owning stack +plugin. For an F# web app, select Giraffe, Falco, Oxpecker, or another server +shape through `dotnet:choose-fsharp-web-framework` before asking Azure Skills to +plan or mutate Azure infrastructure. + +### Framework-Owned Deployments + +When a stack plugin already owns a deployment path, use that plugin for stack-specific implementation details. For example, Fly.io deployment for Vapor or Hummingbird services belongs in `server-side-swift` because that workflow depends on Swift package, Dockerfile, health-check, and runtime conventions. + +### Future Provider Skills + +Add future provider skills as small routing or implementation slices. Good candidates include Cloudflare, Vercel, Fly.io, GCP, Terraform, Pulumi, and CDK when an official provider plugin does not already give Codex a better maintained path. + +## Output Shape + +Return: + +1. `Provider`: AWS, Cloudflare, Vercel, Fly.io, Azure, GCP, multi-cloud, or undecided. +2. `Primary surface`: official provider plugin, MCP server, provider CLI, framework-owned skill, Socket provider skill, or user decision needed. +3. `Credential boundary`: account, region, profile, environment, and whether credentials are required for the next step. +4. `Mutation boundary`: read-only, plan/diff, staging deploy, production deploy, cleanup, or blocked. +5. `Validation path`: exact commands or agent checks to run before and after mutation. +6. `Next handoff`: official plugin install, provider docs, stack skill, or provider-specific Socket backlog item. + +## Guardrails + +- Do not invent provider setup steps when an official provider plugin or current provider docs own the path. +- Do not configure or mutate cloud accounts without confirming account, region, profile, environment, and intended resource changes. +- Do not store credentials, tokens, account IDs, secrets, local profiles, or `.env` files in git. +- Do not present AWS CLI, AWS SAM CLI, or AWS MCP setup as Socket-owned while AWS Agent Toolkit owns the official Codex path. +- Do not present Azure CLI, Azure Developer CLI, Azure MCP, Foundry MCP, or Azure Skills setup as Socket-owned while Microsoft's Azure Skills plugin owns the official Codex path. +- Do not deploy to production by default. Use planning, validation, and explicit user confirmation before production mutations. diff --git a/tests/test_validate_hermes_compatibility.py b/tests/test_validate_hermes_compatibility.py index 5d2c3965..970ecc59 100644 --- a/tests/test_validate_hermes_compatibility.py +++ b/tests/test_validate_hermes_compatibility.py @@ -77,6 +77,8 @@ def configure_paths(repo_root: Path, monkeypatch: pytest.MonkeyPatch) -> None: monkeypatch.setattr(export_hermes_skills, "REVERSE_ENGINEERING_SOURCE_ROOT", repo_root / "plugins" / "agent-portability-skills" / "skills") monkeypatch.setattr(export_hermes_skills, "SWIFT_LANG_SOURCE_ROOT", repo_root / "plugins" / "agent-portability-skills" / "skills") monkeypatch.setattr(export_hermes_skills, "MODEL_LAB_SOURCE_ROOT", repo_root / "plugins" / "agent-portability-skills" / "skills") + monkeypatch.setattr(export_hermes_skills, "DOTNET_SOURCE_ROOT", repo_root / "plugins" / "agent-portability-skills" / "skills") + monkeypatch.setattr(export_hermes_skills, "CLOUD_DEPLOYMENT_SOURCE_ROOT", repo_root / "plugins" / "agent-portability-skills" / "skills") monkeypatch.setattr(export_hermes_skills, "EXPORT_ROOT", repo_root / "skills") monkeypatch.setattr(validate_hermes_compatibility, "REPO_ROOT", repo_root) monkeypatch.setattr(validate_hermes_compatibility, "EXPORT_ROOT", repo_root / "skills") diff --git a/uv.lock b/uv.lock index a4af1e4b..96f0102c 100644 --- a/uv.lock +++ b/uv.lock @@ -286,7 +286,7 @@ wheels = [ [[package]] name = "socket-maintenance" -version = "9.21.0" +version = "9.22.0" source = { virtual = "." } [package.dev-dependencies]