Skills
Chapter 20 of 28
Plan how to split an Encore Go application into services and lay out its directory structure.
1 minute · 202 words · 12 sections
In Encore Go, each package with an API endpoint is automatically a service. No special configuration needed.
Simply create a package with at least one //encore:api endpoint:
// user/user.go
package user
import "context"
type User struct {
ID string `json:"id"`
Email string `json:"email"`
Name string `json:"name"`
}
//encore:api public method=GET path=/users/:id
func GetUser(ctx context.Context, params *GetUserParams) (*User, error) {
// This makes "user" a service
}user/
├── user.go # API endpoints
├── db.go # Database (if needed)
└── migrations/ # SQL migrations
└── 1_create_users.up.sqlBest for new projects - start simple, split later if needed:
my-app/
├── encore.app
├── go.mod
├── api.go # All endpoints
├── db.go # Database
└── migrations/
└── 1_initial.up.sqlFor distributed systems with clear domain boundaries:
my-app/
├── encore.app
├── go.mod
├── user/
│ ├── user.go
│ ├── db.go
│ └── migrations/
├── order/
│ ├── order.go
│ ├── db.go
│ └── migrations/
└── notification/
└── notification.goGroup related services into systems:
my-app/
├── encore.app
├── go.mod
├── commerce/
│ ├── order/
│ │ └── order.go
│ ├── cart/
│ │ └── cart.go
│ └── payment/
│ └── payment.go
├── identity/
│ ├── user/
│ │ └── user.go
│ └── auth/
│ └── auth.go
└── comms/
├── email/
│ └── email.go
└── push/
└── push.goJust import and call the function directly - Encore handles the RPC:
package order
import (
"context"
"myapp/user" // Import the user service
)
//encore:api auth method=GET path=/orders/:id
func GetOrderWithUser(ctx context.Context, params *GetOrderParams) (*OrderWithUser, error) {
order, err := getOrder(ctx, params.ID)
if err != nil {
return nil, err
}
// This becomes an RPC call - Encore handles it
orderUser, err := user.GetUser(ctx, &user.GetUserParams{ID: order.UserID})
if err != nil {
return nil, err
}
return &OrderWithUser{Order: order, User: orderUser}, nil
}Split when you have:
| Signal | Action |
|---|---|
| Different scaling needs | Split (e.g., auth vs analytics) |
| Different deployment cycles | Split |
| Clear domain boundaries | Split |
| Shared database tables | Keep together |
| Tightly coupled logic | Keep together |
| Just organizing code | Use sub-packages, not services |
Create packages without //encore:api endpoints for shared code:
my-app/
├── user/
│ └── user.go # Service (has API)
├── order/
│ └── order.go # Service (has API)
└── internal/
├── util/
│ └── util.go # Not a service (no API)
└── validation/
└── validate.go//encore:api endpointsInstall this repository
npx skills add encoredev/skills/plugin marketplace add encoredev/skillsSkills install per repository, not per chapter — the CLI has no documented per-skill form, so we do not print one.
Plan how to split an Encore Go application into services and lay out its directory structure. Architecture and decomposition, not first-time CLI install (that's `encore-go-getting-started`).
The verbatim description from this skill’s front matter — the string an agent matches on to decide whether to load it.
main, last pushed 15 May 2026.SKILL.md, not by matching a directory convention. One layout observed: encore/*/SKILL.md.h1 and no skipped levels:.claude-plugin/marketplace.json by Encore, declaring 1 plugin. It is read for editorial metadata only — never as the skill index, which is always the repository tree./encoredev/skills.md, and each chapter at its own .md URL.