scaffold-go-library
- Repo stars 0
- Author updated Live
- Author repo skills-registry
- Domain
- AI
- Compatible agents
-
- Claude Code
- Cursor
- Cline
- Codex
- Windsurf
- Gemini CLI
- +20
- Trust score
- 88 / 100 · community maintained
- Author / version / license
- @tomevault-io · no license declared
- Token usage
- Lean
- Setup complexity
- Guided setup
- External API key
- Not required
- Operating systems
- Unspecified (assume cross-platform)
- Runtime requirements
- No special requirements
- Permissions
-
- Read-only
- Write / modify
- Network behavior
- Local-only
- Install commands
- 26 variants
Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.
Heads up: 未限定 allowed-tools,默认拥有全部工具权限。
---
name: scaffold-go-library
description: >- Use when this capability is needed. Generate the full boilerplate for a new Go library projec…
category: ai
runtime: no special runtime
---
# scaffold-go-library output preview
## PART A: Task fit
- Use case: >- Use when this capability is needed. Generate the full boilerplate for a new Go library project. If the user provided a project name in their request, use it as the project name and skip asking for it. Still ask for the remaining parameters (description, minimum Go version, example tests) unless already provided in the user's initial request. runs entir….
- Inputs: target material, constraints, expected output, and acceptance criteria.
- Evidence boundary: follow “Workflow / 1. Gather Project Information / 2. Detect User Identity” and do not present inference as author intent.
## PART B: Execution result
- **01** The card summarizes the use case; runtime output centers on “>- Use when this capability is needed. Generate the full boilerplate for a new Go library project. If the user provided a project name in their request, use it as the project name and skip asking for it. Still ask for the remaining parameters (description, minimum Go version, example tests) unless already provided in the user's initial request. runs entir…”.
- **02** When the source has headings, the agent prioritizes “Workflow / 1. Gather Project Information / 2. Detect User Identity” so the result follows the author’s structure.
- **03** Typical output includes task judgment, concrete steps, required commands or file edits, validation, and follow-up options.
- **04** Risk context follows the fingerprint: read files, write/modify files; mostly runs locally; usually needs no extra API key.
## Running Rules
- read files, write/modify files; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding scope.
- Return the result, validation criteria, and next iteration options. The source does not require a stable slash command. After installation, invoke the skill by name and describe the task.
Name target files or source material, expected output, forbidden changes, and whether network or shell access is allowed. Permission fingerprint: read files, write/modify files.
Start with a small task and check whether the result follows “Workflow / 1. Gather Project Information / 2. Detect User Identity”. Inspect diffs, logs, previews, or tests before expanding scope.
Confirm the final output includes a concrete result, evidence, and next action. If it stays generic, tighten inputs, boundaries, and acceptance criteria.
---
name: scaffold-go-library
description: >- Use when this capability is needed. Generate the full boilerplate for a new Go library projec…
category: ai
source: tomevault-io/skills-registry
---
# scaffold-go-library
## When to use
- >- Use when this capability is needed. Generate the full boilerplate for a new Go library project. If the user provide…
- Use it when the task has clear inputs, repeatable steps, and validation criteria.
## What to provide
- Target material, scope, expected result, and forbidden changes.
- Whether network, commands, file writes, or external services are allowed.
## Execution rules
- Organize steps around “Workflow / 1. Gather Project Information / 2. Detect User Identity” and keep inference separate from source facts.
- read files, write/modify files; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding the task.
## Output requirements
- Return the deliverable, key evidence, validation method, and next action.
- Mark missing information as unknown; do not invent commands, platforms, or dependencies. The author source anchors workflow facts; repository files anchor sources and commands; Fluxly only adds fit, limitations, and quality judgment.
skill "scaffold-go-library" {
input -> user goal + target files + boundaries + acceptance criteria
context -> Workflow / 1. Gather Project Information / 2. Detect User Identity
rules -> SKILL.md triggers / order / output contract
runtime -> no special runtime | read files, write/modify files | mostly runs locally
guardrails -> usually needs no extra API key + small-sample validation + diff/log review
output -> copyable result + checklist + next iteration
} Scaffold Go Library
Generate the full boilerplate for a new Go library project.
Workflow
1. Gather Project Information
If the user provided a project name in their request, use it as the project name and skip asking for it. Still ask for the remaining parameters (description, minimum Go version, example tests) unless already provided in the user's initial request.
Ask the user for these parameters:
- Project name -- kebab-case, used as the module path and directory name (e.g.,
stipple) - Short description -- one sentence, used in README, GoReleaser release header, and doc.go
- Minimum Go version -- the oldest Go version to support in CI (default:
1.24) - Include example tests? -- whether to generate an
example_test.gowith a basicExample()function
If the user already provided some or all of these in their initial request, do not re-ask. Derive what you can from context.
2. Detect User Identity
Detect the user's GitHub username and full name for use in templates:
# GitHub username (for module paths, URLs)
gh api user -q .login
# Full name (for LICENSE copyright)
git config user.name
If either command fails or produces no output, ask the user to provide the value. Use the GitHub username wherever templates reference GITHUB-USERNAME and the full name wherever they reference COPYRIGHT-HOLDER.
3. Verify the Target Directory
The project should be scaffolded in a directory named after the project. If the current directory is already named after the project and is empty (or nearly empty), use it. Otherwise, create a subdirectory.
Derive PACKAGE-NAME from PROJECT-NAME by removing hyphens (e.g., my-lib becomes mylib). If the result looks awkward, confirm with the user.
If the directory already contains Go files, warn the user before proceeding.
4. Initialize Git
Skip if already inside a git repository.
git init
5. Initialize go.mod
Read ./references/go-mod.md for the canonical go mod init invocation.
go mod init github.com/GITHUB-USERNAME/PROJECT-NAME
No dependencies to install -- Go libraries should start stdlib-only.
6. Generate Package File
Read ./references/package-file.md for the package-file template and create PACKAGE-NAME.go from it.
- Replace
PACKAGE-NAMEwith the derived package name
This file contains the package declaration and a Version constant. No doc comment here -- that lives in doc.go.
7. Generate doc.go
Read ./references/doc-go.md for the doc.go template and create doc.go from it.
- Replace
PACKAGE-NAMEwith the derived package name - Replace
PROJECT-DESCRIPTIONwith the short description - Replace
GITHUB-USERNAMEwith the detected GitHub username - Replace
PROJECT-NAMEwith the project name
This is the canonical location for the package-level doc comment.
8. Generate Example Tests (optional)
If the user requested example tests, create example_test.go with a basic Example() function. This file is not generated from a reference template -- write it contextually based on the package name and description. The file should:
- Use
package PACKAGE-NAME_test(external test package) - Import the package being tested
- Include a single
func Example()with a basic usage demonstration - Include an
// Output:comment
9. Generate Makefile
Read ./references/makefile.md for the Makefile template and create Makefile from it.
- Replace
PROJECT-NAMEwith the project name
10. Generate .gitignore
Read ./references/gitignore.md for the .gitignore template and create .gitignore from it.
No replacements needed.
If a .gitignore already exists, merge the template entries into it rather than overwriting.
11. Generate .goreleaser.yml
Read ./references/goreleaser.md for the GoReleaser template and create .goreleaser.yml from it.
- Replace
PROJECT-NAMEwith the project name - Replace
PROJECT-DESCRIPTIONwith the short description - Replace
GITHUB-USERNAMEwith the detected GitHub username
12. Generate .golangci.yml
Read ./references/golangci.md for the golangci-lint template and create .golangci.yml from it.
- Replace
GITHUB-USERNAMEwith the detected GitHub username - Replace
PROJECT-NAMEwith the project name
13. Generate .editorconfig
Read ./references/editorconfig.md for the .editorconfig template and create .editorconfig from it.
No replacements needed.
14. Generate CI Workflow
Read ./references/ci-workflow.md for the CI workflow template and create .github/workflows/ci.yml from it.
- Replace
MINIMUM-GO-VERSIONwith the minimum Go version (from step 1)
15. Generate Release Workflow
Read ./references/release-workflow.md for the release workflow template and create .github/workflows/release.yml from it.
No replacements needed.
16. Generate LICENSE
Read ./references/license.md for the LICENSE template and create LICENSE from it.
- Replace
YEARwith the current year (rundate +%Yto get it) - Replace
COPYRIGHT-HOLDERwith the detected full name
17. Generate README.md
Read ./references/readme.md for the README template and create README.md from it.
- Replace
PROJECT-NAMEwith the project name (kebab-case) - Replace
PROJECT-TITLEwith the project name in title case - Replace
PROJECT-DESCRIPTIONwith the short description - Replace
GITHUB-USERNAMEwith the detected GitHub username - Replace
PACKAGE-NAMEwith the derived package name
18. Generate CHANGELOG.md
Create CHANGELOG.md with the initial changelog template:
# Changelog
All notable changes to this project will be documented in this file.
The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
## [Unreleased]
No replacements needed. The release skill will populate version sections and comparison links on the first release.
19. Create Directory Stubs
Create stub directories for the standard library layout:
# plans directory
mkdir -p docs/plans/todo docs/plans/done
touch docs/plans/todo/.gitkeep docs/plans/done/.gitkeep
Libraries keep tests alongside source files, so no tests/ directory. No internal/ directory -- add it when needed.
20. Tidy Modules
go mod tidy
21. Verify the Build
Run a quick build to confirm everything compiles:
go build ./...
If the build fails, diagnose and fix the issue before continuing.
22. Create Initial Commit
Stage all generated files and create the initial commit:
git add -A
git commit -S -m "feat: scaffold Go library project"
23. Update Copilot Instructions
If .github/copilot-instructions.md exists (created by the scaffold-new-repo skill when running in the bootstrap flow, or already present in an existing repo), append the following entries to the PR review section. Before appending each entry, check whether the bold key text already exists in the file; skip entries that are already present.
To locate the PR review section: look for an existing heading whose text includes "PR Review" or "Code Review" (e.g., ## PR Review, ## Code Review, ## PR Review Checklist (CRITICAL)). If no matching heading exists, append a new ## PR Review section at the end of the file and place the entries there.
- golangci-lint v2 config format is intentional: This project uses golangci-lint v2 configuration which includes
formatters:as a top-level key and supportsgolangci-lint fmtas a subcommand. These are correct v2 features. Do not suggest reverting to v1 config format. cboone/gh-actionsreusable workflows manage tool versions internally: The CI and release workflows usecboone/gh-actionsreusable workflows that handle tool installation, version pinning, caching, and SHA-256 verification internally. Do not suggest replacing reusable workflow calls with inlined third-party actions.
If .github/copilot-instructions.md does not exist, skip this step.
24. Summary
Print a summary of what was created:
- List every file and directory generated
- Note whether example tests were included
- Remind the user to:
- Run
make helpto see available Makefile targets - Tag releases with
git tag v0.1.0 && git push --tagsto trigger GoReleaser - Write tests alongside source files (e.g.,
PACKAGE-NAME_test.go) - Use
make coverageto generate an HTML coverage report - Run the add-community-files skill to add CONTRIBUTING.md, CODE_OF_CONDUCT.md, .github/SECURITY.md, and .github/PULL_REQUEST_TEMPLATE.md
- Run
Error Handling
- If
go mod initfails, check that Go is installed and on the PATH - If the target directory already contains Go files, ask the user before overwriting
- If
git initfails, continue generating files but warn the user - If the build verification fails, show the error and attempt to fix it before continuing
Reference Templates
./references/go-mod.md--go mod initsetup./references/package-file.md-- top-level package source file./references/doc-go.md--doc.gopackage doc comment./references/makefile.md-- Makefile template./references/gitignore.md--.gitignoretemplate./references/goreleaser.md--.goreleaser.ymltemplate./references/golangci.md--.golangci.ymltemplate./references/editorconfig.md--.editorconfigtemplate./references/ci-workflow.md--.github/workflows/ci.yml./references/release-workflow.md--.github/workflows/release.yml./references/license.md-- MIT license template./references/readme.md-- README template
Refresh cboone/gh-actions SHAs before scaffolding
The cboone/gh-actions reusable-workflow refs in this skill's templates are SHA-pinned with a # vX.Y.Z comment that was current when the template was authored. New releases of cboone/gh-actions rot those SHAs. Before emitting a workflow into a user's repo, refresh both the SHA and the comment to current latest:
TAG="$(gh release view --repo cboone/gh-actions --json tagName --jq '.tagName')"
SHA="$(gh api "repos/cboone/gh-actions/commits/${TAG}" --jq '.sha')"
echo "${SHA} # ${TAG}"
Replace each cboone/gh-actions/.../<workflow>.yml@<old-sha> # <old-tag> in the emitted workflow with the new SHA and tag. Dependabot in the user's repo keeps them in sync afterwards.
Source: cboone/agent-harness-plugins — distributed by TomeVault.
Decide Fit First
Design Intent
How To Use It
Boundaries And Review