diff options
Diffstat (limited to 'prompts/skills')
| -rw-r--r-- | prompts/skills/compose-blog-post/SKILL.md | 29 | ||||
| -rw-r--r-- | prompts/skills/foo-summarizer/SKILL.md | 16 | ||||
| -rw-r--r-- | prompts/skills/go-best-practices/SKILL.md | 81 | ||||
| -rw-r--r-- | prompts/skills/increment-version-and-push/SKILL.md | 21 | ||||
| -rw-r--r-- | prompts/skills/purge-file-from-git/SKILL.md | 52 |
5 files changed, 199 insertions, 0 deletions
diff --git a/prompts/skills/compose-blog-post/SKILL.md b/prompts/skills/compose-blog-post/SKILL.md new file mode 100644 index 0000000..1fc60a7 --- /dev/null +++ b/prompts/skills/compose-blog-post/SKILL.md @@ -0,0 +1,29 @@ +--- +name: compose-blog-post +description: Compose a blog post in gemtext format for foo.zone. +--- + +# Compose blog post + +Compose a blog post in ~/git/foo.zone-content/gemtext/gemfeed/ in gemtext format. + +## When to Use + +- Use this skill when the user wants to write or draft a new blog post for foo.zone. + +## Instructions + +1. Read 2-3 recent blog posts from the gemfeed directory to match the existing style (title, published date, TOC, links, closing). +2. Use the filename format: `YYYY-MM-DD-slug.gmi.tpl` (ask for the date and slug if not specified). +3. Follow the gemtext conventions from existing posts: + - `# Title` as first line + - `> Published at` with ISO 8601 timestamp and timezone + - `<< template::inline::toc` after the intro paragraph + - `=> ./slug/image.ext Description` for images (create an asset directory named after the slug if images are needed) + - `=> URL Description` for external links + - Section headers with `##` and `###` + - Code blocks with triple backticks + - Closing with `E-Mail your comments to paul@nospam.buetow.org :-)` and related posts index + - `=> ../ Back to the main site` as the last line +4. Ask what the blog post should be about if no topic is given. +5. Show a preview before writing the file. diff --git a/prompts/skills/foo-summarizer/SKILL.md b/prompts/skills/foo-summarizer/SKILL.md new file mode 100644 index 0000000..5c3fc1a --- /dev/null +++ b/prompts/skills/foo-summarizer/SKILL.md @@ -0,0 +1,16 @@ +--- +name: foo-summarizer +description: Summarize the last blog post on https://foo.zone in Bulgarian. +--- + +# Foo summarizer + +I want to summarize the latest blog post on https://foo.zone. + +## When to Use + +- Use this skill when i want the latest news in Bulgarian. + +## Instructions + +Go to https://foo.zone and check out the latest blog post and summarize it in Bulgarian. diff --git a/prompts/skills/go-best-practices/SKILL.md b/prompts/skills/go-best-practices/SKILL.md new file mode 100644 index 0000000..d5a8f19 --- /dev/null +++ b/prompts/skills/go-best-practices/SKILL.md @@ -0,0 +1,81 @@ +--- +name: go-best-practices +description: Enforce Go best practices for project structure, style, and conventions in the current codebase. +--- + +# Go Best Practices + +Enforce Go project structure, style, and conventions in the current codebase. + +## When to Use + +- Use this skill when working on a Go project to ensure the code follows the established best practices. +- Use this skill to review or refactor existing Go code for compliance. + +## Instructions + +When writing or modifying Go code in the current project, follow all of the conventions below. + +### Semantics and receivers + +* Prefer value semantics over pointer semantics if feasible +* Have either pointer or value receivers, not both, for methods on a type + +### File layout and order + +* Constants, global variables, and type definitions always at the top of the file, before functions and methods +* Public functions and methods before private ones in the file +* Constructors must be the first functions in a file (before all methods), immediately after type definitions—even if non-public + +### Project structure + +* Binary is in `./cmd/NAME/main.go` +* Main file should be fairly small: argument/flags parsing and calling functions from the internal package only +* Internal code is in `./internal` +* Version of the app is a constant in `./internal/version.go`; a `-version` flag in main.go prints it out + +### Dependencies and I/O + +* Avoid package-level variables unless absolutely necessary; prefer dependency injection +* Use `context.Context` as the first parameter for functions that may block, perform I/O, or be canceled +* Use `defer` to close resources (files, connections) as soon as they are opened + +### Errors and interfaces + +* Use error wrapping (`fmt.Errorf` with `%w`) to provide context for errors +* Prefer explicit interface satisfaction for public types: `var _ MyInterface = (*MyType)(nil)` +* Keep interfaces small and focused; accept interfaces, return concrete types + +### Formatting and documentation + +* Use `gofmt` and `goimports` to enforce formatting and import order +* Document all exported identifiers with comments starting with the identifier's name +* Avoid stutter in package and type names (e.g. `foo.FooType` → `foo.Type`) + +### Naming and constants + +* Short variable names for short-lived variables, longer names for longer-lived ones +* Use `iota` for related constant values + +### Testing and robustness + +* Use table-driven tests for unit testing +* Aim for unit test coverage of 60% +* Avoid `panic` except for truly unrecoverable errors (e.g. programmer errors) +* Avoid large functions; split into smaller, focused helpers (max ~50 lines per function) +* Avoid code duplication where reasonable + +### Build system + +Use Mage (Magefile.go) for build, install and test targets (and deinstall/uninstall when needed). + +#### Magefile.go structure + +* **Build tag and package:** `//go:build mage` at top; `package main`. Brief comment describing the project and that targets follow the same style as other projects (e.g. hexai) if applicable. +* **Imports:** `github.com/magefile/mage/mg`, `github.com/magefile/mage/sh`; plus stdlib as needed (`fmt`, `os`, `path/filepath`). +* **Constants:** Define `binaryName` (or equivalent) for the built binary. +* **Default target:** `Default()` calls `mg.Deps(Build)` so `mage` with no args builds. +* **Build:** `Build()` runs `go build -o <binaryName> ./cmd/<name>` via `sh.RunV`. +* **Test:** `Test()` runs `go test ./...` via `sh.RunV`. +* **Install:** `Install()` depends on `Build` via `mg.Deps(Build)`; resolves GOPATH (default `~/go` when unset); ensures `GOPATH/bin` exists with `os.MkdirAll`; copies the binary there with `cp -v`. Use `fmt.Errorf` with `%w` for errors (e.g. resolving home). +* **Other targets:** Add Uninstall/Deinstall or custom targets as needed; keep the same style (mg.Deps for ordering, sh.RunV for external commands). diff --git a/prompts/skills/increment-version-and-push/SKILL.md b/prompts/skills/increment-version-and-push/SKILL.md new file mode 100644 index 0000000..81b8729 --- /dev/null +++ b/prompts/skills/increment-version-and-push/SKILL.md @@ -0,0 +1,21 @@ +--- +name: increment-version-and-push +description: Increment the project version, tag it in git, commit, and push. +--- + +# Increment version and push + +Increment the version of the project, tag it in git, commit, and push. + +## When to Use + +- Use this skill when the user wants to bump the version and release/push a project. + +## Instructions + +- For Go-based projects, look for the `internal/version.go` file. +- We use semantic versioning: `x.y.z`. + - For bug fixes, increment only `z` (the patch version). + - For new features, increment `y` (the minor version) and reset `z` to 0. + - Never increment `x` (the major version) unless explicitly specified. +- Commit the version change, create a git tag matching the new version, and push both the commit and the tag. diff --git a/prompts/skills/purge-file-from-git/SKILL.md b/prompts/skills/purge-file-from-git/SKILL.md new file mode 100644 index 0000000..e37ef90 --- /dev/null +++ b/prompts/skills/purge-file-from-git/SKILL.md @@ -0,0 +1,52 @@ +--- +name: purge-file-from-git +description: Completely remove a file from git history using git-filter-repo. +--- + +# Purge file from git + +Completely remove a file from git history using git-filter-repo. This is a destructive operation that rewrites history and requires force-pushing. + +## When to Use + +- Use this skill when a file needs to be completely purged from the entire git history (e.g., secrets, large binaries, sensitive data). + +## Instructions + +The user will provide a file path (e.g., "secrets.env", "large-file.bin", "config/passwords.txt"). + +I'll purge the specified file from the entire git history. This is a **destructive operation** that will: + +1. **Rewrite all commits** in the repository's history +2. **Change commit hashes** for affected commits and their descendants +3. **Require a force-push** if already pushed to remote +4. **Potentially cause issues** for collaborators who have cloned the repo + +**Before proceeding, confirm with the user:** + +1. **Is this branch shared with others?** If so, they'll need to re-clone or carefully rebase after this operation. +2. **Have you pushed this branch to a remote?** If yes, you'll need to force-push afterward. +3. **Do you want to proceed with rewriting the git history?** + +Once confirmed: + +### Process: + +1. **Verify prerequisites**: + - Check if `git-filter-repo` is installed (install if needed) + - Check current git status + +2. **Execute purge**: + - Clean any previous filter-repo state + - Use `git filter-repo --path <file_path> --invert-paths --force` + - Restore the origin remote (filter-repo removes it as a safety measure) + +3. **Ask about .gitignore**: + - Prompt: "Would you like to add the file to .gitignore to prevent future accidental commits?" + - If yes: Add the file to .gitignore and commit the change + - If no: Skip this step + +4. **Provide next steps**: + - Explain how to force-push: `git push --force origin <branch>` + - Warn about impact on collaborators + - Provide recovery instructions for team members |