agentleFS
sazardevsazardev/goca/.github/skills/goca-architecture/SKILL.md

goca-architecture

Skill299 starsChanged 6 months agoMITView on GitHub

Domain: Understanding the internal architecture of the Goca CLI code generator — how commands, templates, validators, and subsystems interact. When a user runs goca entity Product --fields "Name:string": The central data structure passed to all templates: All template variables MUST reference TemplateData fields — never hardcoded strings. Config is resolved in this priority order (highest first): Supports all standard Go types plus complex ones: Invalid map keys (not comparable): map[[]string]int, map[func()]string Goca supports 8 database backends. Repository templates vary by…

The file

We split this skill into the rules it gives an agent

2 rules. About 0 are common, 0 are distinctive, and 2 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈0

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    When a user runs goca entity Product --fields "Name:string":

    line 9
  2. Very specific:

    All template variables MUST reference TemplateData fields — never hardcoded strings.

    line 54

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Skill: Goca Architecture

Domain: Understanding the internal architecture of the Goca CLI code generator — how commands, templates, validators, and subsystems interact.


How a Goca Command Works (End-to-End)

When a user runs goca entity Product --fields "Name:string":

cobra.Command.Run()
    ↓
1. Flag parsing (cobra flags → local vars)
    ↓
2. ConfigIntegration.LoadConfigForProject() — reads .goca.yaml
   ConfigIntegration.MergeWithCLIFlags()    — CLI overrides config
    ↓
3. SafetyManager = NewSafetyManager(dryRun, force, backup)
    ↓
4. CommandValidator.ValidateEntityName(name) — rejects invalid names
   FieldValidator.ParseFields(fieldsStr)    — parses "Name:string,Price:float64"
    ↓
5. TemplateGenerator.BuildTemplateData()    — populates TemplateData struct
    ↓
6. TemplateGenerator.GenerateFromTemplate() — text/template rendering
    ↓
7. SafetyManager.WriteFile(path, content)   — writes with conflict checking
    ↓
8. DependencyManager.AddDependency()        — queues go.mod updates
   DependencyManager.RunGoGet()             — executes go get
    ↓
9. Print summary (files created, dry-run preview, etc.)

Key Subsystem Details

TemplateData Struct

The central data structure passed to all templates:

type TemplateData struct {
    Entity   EntityData    // Name, NameLower, NamePlural, Package
    Fields   []FieldData   // Name, Type, JSONTag, GormTag, ValidateTag, flags
    Module   string        // go module path (e.g. "github.com/user/project")
    Database string        // "postgres", "mysql", "sqlite", etc.
    Features FeatureFlags  // Validation, BusinessRules, Timestamps, SoftDelete, etc.
    Imports  []string      // deduplicated import paths for the generated file
    Methods  []MethodData  // (for use case / handler templates)
}

All template variables MUST reference TemplateData fields — never hardcoded strings.

SafetyManager Flow

WriteFile(path, content)
    → CheckFileConflict(path)
        → if file exists AND !Force → error
        → if file exists AND Backup → BackupFile(path)
        → if DryRun → record to createdFiles, return nil (no write)
    → os.MkdirAll(dir, 0755)
    → os.WriteFile(path, []byte(content), 0644)
    → append to createdFiles

ConfigIntegration Priority

Config is resolved in this priority order (highest first):

  1. CLI flags explicitly set by user (--database postgres)
  2. .goca.yaml configuration file values
  3. Built-in defaults (e.g., database: sqlite)

FieldValidator Type Support

Supports all standard Go types plus complex ones:

  • Basic: string, int, int64, float64, bool, uint, byte, rune
  • Pointers: *string, *User
  • Slices: []string, []*User, [][]string
  • Arrays: [10]string
  • Maps: map[string]string, map[string]interface{}
  • Channels: chan string, <-chan int, chan<- bool
  • Functions: func(), func(string) error
  • Interfaces: interface{}, io.Reader
  • Qualified: time.Time, uuid.UUID

Invalid map keys (not comparable): map[[]string]int, map[func()]string

Database Backend Matrix

Goca supports 8 database backends. Repository templates vary by database:

DatabaseDriver PackageConnection TypeGenerated Driver Import
postgresgorm.io/driver/postgresDSN string✓
mysqlgorm.io/driver/mysqlDSN string✓
sqlitegorm.io/driver/sqlitefile path✓
sqlservergorm.io/driver/sqlserverDSN string✓
mongodbgo.mongodb.org/mongo-driverURI + client✓ (non-GORM)
redisgithub.com/redis/go-redis/v9options✓ (non-GORM)
cassandragithub.com/gocql/gocqlcluster✓ (non-GORM)
dynamodbgithub.com/aws/aws-sdk-go-v2config✓ (non-GORM)

MongoDB, Redis, Cassandra, and DynamoDB use non-GORM templates — they have separate template functions.

Handler Protocol Matrix

ProtocolTemplateGenerated FileRoutes
httpHTTP RESThandler/http/<entity>_handler.gogorilla/mux
grpcgRPC servicehandler/grpc/<entity>_handler.goproto-based
cliCLI subcommandhandler/cli/<entity>_handler.gocobra
workerBackground jobhandler/worker/<entity>_handler.gogoroutine

Template String Organization

cmd/templates.go              ← entity, usecase, repository, handler templates
cmd/template_components.go    ← reusable partial templates (field blocks, import blocks)
cmd/project_templates.go      ← goca init project structure templates (main.go, go.mod, etc.)

Error Types (cmd/errors.go)

Typed errors for clean error handling:

  • ErrInvalidEntityName — name fails regex validation
  • ErrInvalidFieldType — field type not supported
  • ErrInvalidDatabase — unknown database backend
  • ErrFileConflict — file already exists (use --force)
  • ErrTemplateRender — template execution failed
  • ErrDependencyInstall — go get failed

Integration Test Architecture

internal/testing/tests/
├── entity_test.go      Tests goca entity command end-to-end
├── feature_test.go     Tests goca feature command (all layers)
├── usecase_test.go     Tests goca usecase command
├── handler_test.go     Tests goca handler command
├── init_test.go        Tests goca init command (project scaffold)
└── safety_test.go      Tests SafetyManager, NameConflictDetector, DependencyManager

Each test:

  1. Creates t.TempDir() as project root
  2. Initializes a Go module with go mod init <test-module>
  3. Runs the command targeting that directory
  4. Verifies expected files exist
  5. Runs go build ./... and go vet ./... to confirm validity

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.