Compare commits
No commits in common. "main" and "improve-quickstart-commands" have entirely different histories.
main
...
improve-qu
16
README.md
16
README.md
@ -115,22 +115,6 @@ 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
|
||||
|
||||
@ -229,29 +229,6 @@ 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.
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user