メニュー
Build, lint, test, and verification workflow for the portal-tunnel Go+frontend monorepo. Use when setting up the repo, running CI-equivalent checks, or before committing changes.
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/gosuda/portal-tunnel --skill dev-workflowコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
How the portal-tunnel client CLI (cmd/portal-tunnel) is structured and invoked — expose/agent/list/update subcommands, flags, validation rules, and x402/routing options. Use when changing or testing client-side tunnel behavior.
Expose, preview, protect with x402 payments, or keep a local web app, static site, HTTP route set, or explicitly requested TCP/UDP service reachable through Portal, then verify the public endpoint and report its lifecycle. Use when the user asks to deploy, publish, share, tunnel, expose, create a public preview, add a paid route, or configure x402 for a local app with Portal. Do not use for deploying a Portal relay, generic cloud hosting, or publishing this plugin.
Set up and run a public Portal relay on any Linux host with a public IP — Docker Compose deployment, embedded authoritative DNS with one-time NS delegation, optional TCP/UDP lease ports for game hosting, and registration in the public relay pool. Use when the user asks to run their own relay, contribute a relay to the Portal network, self-host a relay instead of using public ones, or open a relay with game-server support. Do not use for exposing a local service (portal-expose) or for accessing a CLI agent remotely.
SKILL.md を表示中
| name | dev-workflow |
| description | Build, lint, test, and verification workflow for the portal-tunnel Go+frontend monorepo. Use when setting up the repo, running CI-equivalent checks, or before committing changes. |
go1.26.4 via go.mod; the Makefile exports GOTOOLCHAIN=go1.26.4, so make targets self-pin even on other Go installs.make install installs the pinned dev tools: goimports@v0.41.0 and golangci-lint@v2.11.1 (into $(go env GOPATH)/bin, usually ~/go/bin — put it on PATH).bun is needed only for make build-docs.Run these three before pushing; they are what CI enforces:
make vet # go vet ./cmd/... ./portal/... ./sdk/... ./types/... ./utils/...
make lint # golangci-lint run (same package set)
make test # go test -coverprofile=coverage.out (same set) + `cd frontend && npm test` (vitest)
Per AGENTS.md, run tests only when needed/asked; make tidy is local maintenance, not a CI gate.
.pre-commit-config.yaml runs whitespace/EOL/BOM fixers, golangci-lint (config-verify, --new-from-rev HEAD --fix, and full --fix), plus local make fmt and go vet ./....
make fmt runs gofmt -w . then goimports -w ., so goimports MUST be on PATH or the commit hook fails with goimports: No such file or directory — run make install first.v2.10.1) and the Makefile (v2.11.1); expect minor lint-behavior drift.make build → build-tunnel + build-server (full artifacts).make build-frontend builds the SPA (cd frontend && npm ci && npm run build) and copies frontend/dist/. into cmd/relay-server/dist/app (embedded by the relay via //go:embed dist/*).make build-server-bin compiles only bin/relay-server; it assumes dist/app already exists (use after build-frontend, or the binary fails at startup asking you to run make build-frontend).make build-tunnel cross-compiles cmd/portal-tunnel for linux/darwin/windows × amd64/arm64.GO_BUILD_FLAGS (-trimpath -ldflags "-s -w"); the Dockerfile calls make build-server-bin rather than duplicating them.types/ (e.g. types/paths.go), never duplicated in runtime/helpers.utils/; stateful/domain logic stays with its real owner (sdk/ or portal/).