Migrate Go projects onto Forge scaffolds with safe porting order.
npx skills add https://github.com/reliant-labs/forge --skill migration-reliant-labs
Please help me install this Agent Skill. Skill: migration Source: https://github.com/reliant-labs/forge/tree/main/internal/templates/project/skills/forge/migration Command: npx skills add https://github.com/reliant-labs/forge --skill migration-reliant-labs
This Skill prevents broken or subtly incorrect scaffolds when porting an existing Go codebase into a Forge-generated project structure, by guiding the required pre-flight checks and a safe porting order. It also reduces time wasted on environment/tooling mismatches and common migration footguns that only surface after codegen or runtime failures.
service, cli, or library scaffold shape and plan a safe -next cutover module strategy.forge generate, go mod tidy, go build, and forge lint, including an early contracts floor and per-phase contract linting.Follow the migration pre-flight checklist, scaffold a <name>-next project with the correct --kind and --mod, then port internal packages first while running forge generate and lint after each component addition until you reach a clean build baseline.
High-intent search queries and answers about installing and using this skill.
To migrate a Go project into a Forge scaffold safely, scaffold a `<name>-next` project with the correct `--kind` and `--mod`, then port internal packages first while running `forge generate` and `forge lint` after each component addition until you reach a clean build baseline.
Pre-flight checks for Forge project porting verify tool availability and environment PATH visibility so Forge subprocess codegen behaves deterministically, alongside setting up an early contracts policy floor in your `forge.yaml` configuration.
Choosing the correct scaffold shape requires selecting `service`, `cli`, or `library` based on your project type, and planning a safe `-next` cutover module strategy to handle the Go module path transition without breaking existing imports.
The safest pack and component install order for Forge migration is incremental: port internal packages first, followed by handlers and dependency wiring, while repeatedly running `forge generate`, `go mod tidy`, `go build`, and `forge lint` after each phase.
Forge codegen and runtime behavior fail during Go codebase porting due to environment and tooling mismatches, incorrect module-path strategies, or bypassing the required pre-flight checks and deterministic per-phase contract linting verification gates.
You cannot safely port a Go project using Forge without an early contracts floor defined in `forge.yaml`, as per-phase contract linting is required to prevent subtle scaffold inaccuracies and verify the build baseline after each component addition.
agoodwayGenerate typed Go OpenAPI clients and models from OpenAPI 3.0 specs.
itou-daikiDiagnose and fix Go build errors, vet warnings, and lint issues.
ByteLandTechnologyDefine and lock a CLI contract for the cli-forge plan stage.
deandumScaffold Go services, CLIs, and libraries with standardized structure and tooling.