kramme-cc-workflow/skills/kramme:nx:setup-portless/SKILL.md
Set up portless in an Nx workspace with dev:local/dev:full targets. Use when adding portless to an Nx project or wiring up Nx targets for local HTTPS development.
npx skillsauth add abildtoft/kramme-cc-workflow kramme:nx:setup-portlessInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
4 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Wire portless into an Nx workspace so apps get stable https://<name>.localhost URLs via Nx targets. The proxy auto-starts when you launch an app, and Nx targets give you a repeatable place to trust the CA, run apps, and fall back to manual proxy control when a task runner needs it.
Experimental: This skill is early and may change as we refine the Nx + portless workflow.
Examples below invoke Nx as
nx …. If Nx isn't on your PATH, prefix with your package manager's runner:yarn nx,pnpm nx, ornpx nx.
dev:local / dev:full targets for an Nx projectNot for: non-Nx projects, or production/public TLS — portless is a local development proxy only.
What this touches: installs portless as a dev dependency, edits one or more project.json files, and (via proxy:trust) installs a locally-trusted root CA into your machine's trust store.
Platform: macOS and Linux. Steps rely on sudo, $HOME, port 443, and .localhost resolution; Windows is not covered.
portless <app-name> <dev-command> starts an app, assigns it a port, and registers it with the proxy.portless run <dev-command> does the same thing, but infers the app name from package.json.https://<name>.localhost to the correct dev server.PORT env var. Frameworks that ignore it receive matching --port and --host flags automatically.proxy:start target and then launch the app.# Using the workspace package manager
yarn add -D portless
# or: npm install -D portless / pnpm add -D portless
Add this target to one project's project.json (typically the primary app). It only needs to exist once in the workspace.
// packages/<app>/project.json
{
"targets": {
"proxy:trust": {
"command": "sudo portless trust",
"options": { "cwd": "packages/<app>" },
},
},
}
nx run <app>:proxy:trust
This installs a locally-trusted root CA (similar to mkcert) so browsers accept https://*.localhost. It affects the whole machine — run it only on trusted dev machines.
Re-running is safe: skip any target that already exists in
project.jsoninstead of duplicating it, and skip the dependency install andproxy:trustwhen the workspace already has portless.
dev:local target// packages/<app>/project.json
{
"targets": {
"dev:local": {
"command": "portless <app-name> <dev-command>",
"options": { "cwd": "packages/<app>" },
},
},
}
Replace:
<app-name> — the subdomain name (e.g., my-app → https://my-app.localhost)<dev-command> — the framework dev command (e.g., next dev, vite dev, ng serve)Portless auto-detects common frameworks and injects the correct --port/--host flags automatically.
Example for Next.js:
"dev:local": {
"command": "portless my-app next dev",
"options": { "cwd": "packages/app" }
}
Alternatively, use portless run to infer the app name from package.json:
"dev:local": {
"command": "portless run next dev",
"options": { "cwd": "packages/app" }
}
dev:full target (optional)If the app has companion services (e.g., a Convex backend), create a composite target. -t lists the targets to run across the projects selected by -p:
"dev:full": {
"command": "nx run-many -t dev:local convex-dev -p <app> --parallel=2"
}
Adjust the targets, projects, and parallelism for the services the app needs.
The proxy auto-starts when you launch an app — no manual proxy start needed.
# Start the app
nx run <app>:dev:local
# or with all services:
nx run <app>:dev:full
# Open https://<app-name>.localhost
Multiple apps run simultaneously through the same proxy:
# Terminal 1
nx run app-one:dev:local # → https://app-one.localhost
# Terminal 2
nx run app-two:dev:local # → https://app-two.localhost
my-cool-app → https://my-cool-app.localhostportless api.my-app next dev → https://api.my-app.localhostrun, get, alias, hosts, list, trust, clean, proxy — use portless run or portless --name <name> insteadIf you need explicit proxy control (e.g., task runners that don't support auto-start, or custom port/TLD/LAN settings), add these targets:
// packages/<app>/project.json
{
"targets": {
"proxy:start": {
"command": "sudo PORTLESS_STATE_DIR=$HOME/.portless portless proxy start",
"options": { "cwd": "packages/<app>" },
},
"proxy:stop": {
"command": "sudo PORTLESS_STATE_DIR=$HOME/.portless portless proxy stop",
"options": { "cwd": "packages/<app>" },
},
},
}
Why PORTLESS_STATE_DIR? — Under sudo, the home directory changes to /root. This env var ensures the proxy daemon writes state to the user's home directory so proxy:stop can find and stop it later.
Common proxy:start additions:
--lan to advertise .local hostnames on your LAN--tld test to use .test instead of .localhost--wildcard to let unregistered subdomains fall back to a parent app-p 8080 to avoid privileged ports and sudoUseful env vars when you need them:
PORTLESS_PORT to override the proxy portPORTLESS_HTTPS=0 to disable TLS (local non-HTTPS use only — drops the trusted-cert setup)PORTLESS_LAN=1 to default to LAN modePORTLESS_TLD=test to change the TLDPORTLESS_STATE_DIR to override the proxy state directory| Problem | Fix |
| --- | --- |
| portless exits because there is no TTY or it cannot prompt for elevation | Pre-start the proxy with nx run <app>:proxy:start, then launch dev:local |
| Permission error on port 443 | Keep sudo, or run the proxy on an unprivileged port such as -p 8080 |
| Browser shows a certificate warning | Run nx run <app>:proxy:trust again |
| Safari cannot resolve the local hostname | Run portless hosts sync to add host entries |
tools
Requires Linear MCP. Implements one Linear issue end to end, selects applicable code-review, convention, and PR-refactor gates, runs them to bounded convergence, verifies, and optionally opens the PR and iterates on CI and review feedback until green. Use when the user wants a single Linear issue taken from implementation through a clean Pull Request. Not for implementation-only work, SIW-tracked issues, stacked PRs, existing PR updates, or post-merge rollout.
development
Reviews PR and local changes for convention drift and overcaution against documented rules and mined peer-file practice. Use for new patterns, dependencies, abstractions, or defensive complexity that departs from established practice; every finding cites evidence. Supports --inline. Not for general code quality (use kramme:pr:code-review) or spec review (use kramme:siw:spec-audit --team).
testing
Charts huge or foggy initiatives into a local `.context` decision map and resolves one typed frontier ticket per session until the work is ready for SIW or another execution workflow. Use when the route to a destination cannot fit in one agent session or parallel workspaces need coordinated planning state. Not for clear specs, ordinary issue decomposition, implementation, or Linear-native tracking.
development
Investigates a question against primary sources and saves one cited Markdown artifact. Use for reading legwork: official docs/API facts, source-code or spec checks, standards, and first-party service behavior before planning or implementation. Not for making product or architecture decisions, implementing code, broad web search, secondary blog summaries, or uncited answers.