Compare commits

..

4 Commits

Author SHA1 Message Date
dda0d01faa Merge pull request 'style(go): add rule against type-only packages (per upaas #126 review)' (#2) from clawbot/prompts:add-no-type-only-packages-rule into main
Some checks failed
check / check (push) Failing after 6s
Reviewed-on: sneak/prompts#2
2026-02-23 22:14:02 +01:00
user
7676ec16c3 style(go): add Stringer rule for custom string-based types 2026-02-23 11:56:16 -08:00
user
f9dcef4c9e style(go): add rule against type-only packages
Types should live alongside their implementations, not in separate
'types', 'domain', or 'models' packages. Type-only packages cause
alias imports and indicate poor package design.

Prompted by review feedback on upaas PR #126.
2026-02-23 11:47:50 -08:00
189e54862e Add template repos section to README
All checks were successful
check / check (push) Successful in 7s
2026-02-23 01:38:38 +07:00
2 changed files with 39 additions and 0 deletions

View File

@ -115,6 +115,22 @@ subdirectory. Each file contains one or more related prompts or policy
documents. There is no build step or runtime component; the prompts are consumed
by copying them into other projects or referencing them directly.
## Template Repos
These template repositories implement the policies defined in this repo and
serve as starting points for new projects. They must be kept in sync when
policies change.
- **[template-app-go](https://git.eeqj.de/sneak/template-app-go)** — Go HTTP
server template (Uber fx, chi, SQLite, session auth, Prometheus metrics)
- **[template-app-js](https://git.eeqj.de/sneak/template-app-js)** — JavaScript
SPA template (Vite, Tailwind CSS v4, nginx Docker deployment)
- **[template-app-python](https://git.eeqj.de/sneak/template-app-python)** —
Python web application template (FastAPI, uvicorn, pytest, black, ruff)
When updating policies in this repo, also update the template repos to match
(Makefile targets, Dockerfile conventions, CI workflows, required files, etc.).
## TODO
- Add more prompt templates for common development tasks

View File

@ -229,6 +229,29 @@ last_modified: 2026-02-22
1. Define your struct types near their constructors.
1. Do not create packages whose sole purpose is to hold type definitions.
Packages named `types`, `domain`, or `models` that contain only structs and
interfaces (with no behavior) are a code smell. Define types alongside the
code that uses them. Type-only packages force consuming packages into alias
imports and circular-dependency gymnastics, and indicate that the package
boundaries were drawn around nouns instead of responsibilities. If multiple
packages need the same type, put it in the package that owns the behavior,
or in a small, focused interface package — not in a grab-bag types package.
1. When defining custom string-based types (e.g. `type ImageID string`),
implement `fmt.Stringer`. Use `.String()` at SDK and library boundaries
instead of `string(v)`. This makes type conversions explicit, grep-able,
and consistent across the codebase. Example:
```go
type ContainerID string
func (id ContainerID) String() string { return string(id) }
// At the Docker SDK boundary:
resp, err := c.docker.ContainerStart(ctx, id.String(), opts)
```
1. Define your interface types near the functions that use them, or if you have
multiple conformant types, put the interface(s) in their own file.