GoFrame development skill. TRIGGER when writing/modifying Go files, implementing services, creating APIs, or database operations. DO NOT TRIGGER for frontend/shell scripts.
SkillScore83Maintained
Automatic
◆Coding pack
Last verified 8/15/2026
What it changes
Passed 19 of 23 test cases with the skill, and 12 of 23 without it.
Without skill52%
With skill83%
Checks it passed that the model alone missed
Omits calling WhereNull for deleted_at.
Uses gdb.Raw("NULL") to set the avatar field.
Assigns gdb.Raw("NULL") to the idle_since field.
and 6 more in the full report
8 fixed11 passed either way3 still failing1 broke
Pass-rate lift
+30 pp
Tokens
+55%
Agent turns
0%
Response time
-27%
Model gemini-3.6-flashMeasured 8/15/2026v119 of 23 cases passed with skill
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 8 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 8
Prompt
Write a GoFrame v2 service constructor snippet in Go that declares five service pointers: userSvc, roleSvc, permissionSvc, tenantSvc, and auditSvc.
What was checked, without and with the skill
Checked
Without skill
With skill
Groups the five variable declarations into a single var (...) block.
Missed
Passed
case-14 · gemini-3.6-flash · 8/15/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md130 linessingle file
Critical Conventions
Project Development Standards
For complete projects (HTTP/microservices), install GoFrame CLI and use gf init to create project scaffolding. See Project Creation - init for details.
Auto-generated code files (dao, do, entity) MUST NOT be manually created or modified per GoFrame conventions.
Unless explicitly requested, do NOT use the logic/ directory for business logic. Implement business logic directly in the service/ directory.
Reference complete project examples:
HTTP service best practice: user-http-service
gRPC service best practice: user-grpc-service
Component Usage Standards
Before creating new methods or variables, check if they already exist elsewhere and reuse existing implementations.
Use the gerror component for all error handling to ensure complete stack traces for traceability.
When exploring new components, prioritize GoFrame built-in components and reference best practice code from examples.
Database Operations MUST use DO objects (internal/model/do/), never g.Map or map[string]interface{}. DO struct fields are interface{}; unset fields remain nil and are automatically ignored by the ORM:
// Good - use DO object
dao.Users.Ctx(ctx).Where(cols.Id, id).Data(do.User{Uid: uid}).Update()
// Good - conditional fields, unset fields are nil and ignored
data := do.User{}
if password != "" { data.PasswordHash = hash }
if isAdmin != nil { data.IsAdmin = *isAdmin }
dao.Users.Ctx(ctx).Where(cols.Id, id).Data(data).Update()
// Good - explicitly set a column to NULL using gdb.Raw
dao.Instances.Ctx(ctx).Where(cols.Id, id).Data(do.Instance{IdleSince: gdb.Raw("NULL")}).Update()
// Bad - never use g.Map for database operations
dao.Users.Ctx(ctx).Data(g.Map{cols.Uid: uid}).Update()
Code Style Standards
Variable Declarations: When defining multiple variables, use a var block to group them for better alignment and readability:
// Good - aligned and clean
var (
authSvc *auth.Service
bizCtxSvc *bizctx.Service
k8sSvc *svcK8s.Service
notebookSvc *notebook.Service
Design and review stable, idiomatic Go package APIs covering naming, exported declarations, embedding, receivers, typed-nil interfaces, generics, functional options, method sets, errors, wire contracts, compatibility, and examples. Use when creating a reusable Go package, reviewing its public surface, evolving an exported API, or choosing concrete types, functions, methods, fields, interfaces, or type parameters.