Scaffold 文档测试

AI 智能社区

作者仓库星标 0
作者仓库 skills-registry

解读按原文结构重写，命令、链接、术语均保留；右侧可核对作者原始 SKILL.md

方法与流程

Workflow：原文以此为独立章节。
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-VERSION with 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.

适用与边界

当前原文没有单列适用场景。
当前原文没有单列不适用场景或限制。

原文中的明确线索

要点：「Project name」、「Short description」、「Minimum Go version」、「Include example tests?」、「golangci-lint v2 config format is intentional」、「cboone/gh-actions reusable workflows manage tool versions internally」
文件与命令：stipple、1.24、exampletest.go、Example()、GITHUB-USERNAME、COPYRIGHT-HOLDER、PACKAGE-NAME、PROJECT-NAME

流狐整理：以上内容来自当前 SKILL.md 的章节与原词；未补写作者没有声明的工具、兼容性或能力。

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.go with a basic Example() 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-NAME with 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-NAME with the derived package name
Replace PROJECT-DESCRIPTION with the short description
Replace GITHUB-USERNAME with the detected GitHub username
Replace PROJECT-NAME with 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-NAME with 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-NAME with the project name
Replace PROJECT-DESCRIPTION with the short description
Replace GITHUB-USERNAME with 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-USERNAME with the detected GitHub username
Replace PROJECT-NAME with 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-VERSION with 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 YEAR with the current year (run date +%Y to get it)
Replace COPYRIGHT-HOLDER with the detected full name

17. Generate README.md

Read ./references/readme.md for the README template and create README.md from it.

Replace PROJECT-NAME with the project name (kebab-case)
Replace PROJECT-TITLE with the project name in title case
Replace PROJECT-DESCRIPTION with the short description
Replace GITHUB-USERNAME with the detected GitHub username
Replace PACKAGE-NAME with 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 supports golangci-lint fmt as a subcommand. These are correct v2 features. Do not suggest reverting to v1 config format.
cboone/gh-actions reusable workflows manage tool versions internally: The CI and release workflows use cboone/gh-actions reusable 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 help to see available Makefile targets
- Tag releases with git tag v0.1.0 && git push --tags to trigger GoReleaser
- Write tests alongside source files (e.g., PACKAGE-NAME_test.go)
- Use make coverage to 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

Error Handling

If go mod init fails, check that Go is installed and on the PATH
If the target directory already contains Go files, ask the user before overwriting
If git init fails, 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 init setup
./references/package-file.md -- top-level package source file
./references/doc-go.md -- doc.go package doc comment
./references/makefile.md -- Makefile template
./references/gitignore.md -- .gitignore template
./references/goreleaser.md -- .goreleaser.yml template
./references/golangci.md -- .golangci.yml template
./references/editorconfig.md -- .editorconfig template
./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.

流狐档案作者与许可取自来源；运行、权限和网络为流狐检测或估算

流狐分类: AI 智能
作者声明 Agent: 未找到明确声明；不据此推断已兼容或已测试
静态检查: 88 / 100 · 启发式扫描，不代表运行安全
作者 / 版本 / 许可: @tomevault-io · 未声明 license
流狐 Token 估算: 低消耗
流狐接入估算: 需简单配置
是否需要外部 API Key: 未发现要求
检测到的系统要求: 未声明
底层运行要求: 未声明
检测到的文件与系统行为: 只读
允许写入 / 修改
检测到的网络行为: 仅限本地
安装命令数: 无（仅作为资料）

档案由构建时根据 SKILL.md 与安装命令自动衍生，可能与作者实际意图存在差异。

需要注意： 未限定 allowed-tools，默认拥有全部工具权限。

输出预览 scaffold-go-library.preview

# 8. Generate Example Tests (optional)

- 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

SKILL.md SKILL.md

# 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.go` with a basic `Example()` 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:

```bash
# GitHub username (for module paths, URLs)
gh api user -q .login
```

```bash
# 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.

…

证据边界与执行链路

作者原文负责流程事实；流狐只索引当前章节、要点、文件与命令。

章节    -> Workflow → 1. Gather Project Information → 2. Detect User Identity → 3. Verify the Target Directory → 4. Initialize Git → 5. Initialize go.mod
要点    -> Project name · Short description · Minimum Go version · Include example tests? · golangci-lint v2 config format is intentional · cboone/gh-actions reusable workflows manage tool versions internally
文件/命令 -> stipple · 1.24 · exampletest.go · Example() · GITHUB-USERNAME · COPYRIGHT-HOLDER · PACKAGE-NAME · PROJECT-NAME
内容 SHA-256 -> c2a5a270010e

方法与流程

适用与边界

原文中的明确线索

Scaffold Go Library

Workflow

1. Gather Project Information

2. Detect User Identity

3. Verify the Target Directory

4. Initialize Git

5. Initialize go.mod

6. Generate Package File

7. Generate doc.go

8. Generate Example Tests (optional)

9. Generate Makefile

10. Generate .gitignore

11. Generate .goreleaser.yml

12. Generate .golangci.yml

13. Generate .editorconfig

14. Generate CI Workflow

15. Generate Release Workflow

16. Generate LICENSE

17. Generate README.md

18. Generate CHANGELOG.md

19. Create Directory Stubs

20. Tidy Modules

21. Verify the Build

22. Create Initial Commit

23. Update Copilot Instructions

24. Summary

Error Handling

Reference Templates

Refresh cboone/gh-actions SHAs before scaffolding

讨论

Refresh `cboone/gh-actions` SHAs before scaffolding