scaffold-rust-cli
- 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
- macOS
- Runtime requirements
- No special requirements
- Permissions
-
- Read-only
- Write / modify
- Shell exec
- 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-rust-cli
description: >- Use when this capability is needed. Generate the full boilerplate for a new Rust CLI project.…
category: ai
runtime: no special runtime
---
# scaffold-rust-cli output preview
## PART A: Task fit
- Use case: >- Use when this capability is needed. Generate the full boilerplate for a new Rust CLI 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 unless already provided in the user's initial request. runs entirely locally. Works with Claude Code, Cursor, Cline ….
- 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 Rust CLI 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 unless already provided in the user's initial request. runs entirely locally. Works with Claude Code, Cursor, Cline …”.
- **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, run shell commands; mostly runs locally; usually needs no extra API key.
## Running Rules
- read files, write/modify files, run shell commands; 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, run shell commands.
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-rust-cli
description: >- Use when this capability is needed. Generate the full boilerplate for a new Rust CLI project.…
category: ai
source: tomevault-io/skills-registry
---
# scaffold-rust-cli
## When to use
- >- Use when this capability is needed. Generate the full boilerplate for a new Rust CLI project. If the user provided…
- 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, run shell commands; 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-rust-cli" {
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, run shell commands | mostly runs locally
guardrails -> usually needs no extra API key + small-sample validation + diff/log review
output -> copyable result + checklist + next iteration
} Scaffold Rust CLI
Generate the full boilerplate for a new Rust CLI 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 unless already provided in the user's initial request.
Ask the user for these parameters:
- Project name -- kebab-case, used as the crate name, binary name, and directory name (e.g.,
my-tool) - Short description -- one sentence, used in
Cargo.tomland README - Include clap? -- whether to add clap for CLI argument parsing (adds
clapdependency withderivefeature and generates a skeleton with argument structs) - macOS-only project? -- whether this project targets only macOS (affects CI runner selection and release workflow targets). Default: no (cross-platform).
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 repository URLs, Homebrew tap)
gh api user -q .login
# Full name (for LICENSE copyright, Cargo.toml authors)
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.
If the directory already contains Rust files (Cargo.toml, src/), warn the user before proceeding.
4. Initialize Git
Skip if already inside a git repository.
git init
5. Generate Cargo.toml
Read ./references/cargo-toml.md for the Cargo.toml template and create Cargo.toml from it.
- Replace
PROJECT-NAMEwith the project name - Replace
PROJECT-DESCRIPTIONwith the short description - Replace
GITHUB-USERNAMEwith the detected GitHub username - Replace
COPYRIGHT-HOLDERwith the detected full name
If clap was selected, add clap = { version = "4", features = ["derive"] } to the [dependencies] section.
6. Generate src/main.rs
Choose the template based on the clap parameter:
- Without clap: read
./references/main-rs.md - With clap: read
./references/main-rs-with-clap.md
Replace in the with-clap template:
PROJECT-NAMEwith the project namePROJECT-DESCRIPTIONwith the short description
7. Generate rust-toolchain.toml
Read ./references/rust-toolchain.md for the template and create rust-toolchain.toml from it.
No replacements needed.
8. Generate rustfmt.toml
Read ./references/rustfmt.md for the template and create rustfmt.toml from it.
No replacements needed.
9. Generate deny.toml
Read ./references/deny.md for the template and create deny.toml from it.
No replacements needed.
10. Generate typos.toml
Read ./references/typos.md for the template and create typos.toml from it.
- Replace
PROJECT-NAMEwith the project name
11. Generate cliff.toml
Read ./references/cliff.md for the template and create cliff.toml from it.
No replacements needed.
12. Generate Makefile
Read ./references/makefile.md for the template and create Makefile from it.
No replacements needed.
13. Generate .gitignore
Read ./references/gitignore.md for the template and create .gitignore from it.
No replacements needed.
If a .gitignore already exists, merge the template entries into it rather than overwriting.
14. Generate CI Workflow
Choose the appropriate CI template:
- Cross-platform (default): read
./references/ci-workflow.md - macOS-only: read
./references/ci-workflow-macos-only.md
Create .github/workflows/ci.yml from the chosen template. No replacements needed (the workflow is project-name-independent).
15. Generate Release Workflow
Choose the appropriate release template:
- Cross-platform (default): read
./references/release-workflow.md - macOS-only: read
./references/release-workflow-macos-only.md
Create .github/workflows/release.yml from the chosen template.
- Replace
PROJECT-NAMEwith the project name
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-DESCRIPTIONwith the short description - Replace
GITHUB-USERNAMEwith the detected GitHub username
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 project layout:
# plans directory
mkdir -p docs/plans/todo docs/plans/done
touch docs/plans/todo/.gitkeep docs/plans/done/.gitkeep
# tests directory
mkdir -p tests
touch tests/.gitkeep
20. Verify the Build
Run a quick build to confirm everything compiles:
cargo build
If the build fails, diagnose and fix the issue before continuing.
21. Create Initial Commit
Stage all generated files and create the initial commit:
git add -A
git commit -S -m "feat: scaffold Rust CLI project"
22. 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.
- Rust edition 2024 is intentional: This project uses Rust edition 2024 in both
Cargo.tomlandrustfmt.toml. Do not suggest downgrading to edition 2021. - cargo-deny and typos are CI-verified: The CI workflow includes
cargo deny checkandtyposjobs. Do not suggest removing these checks or marking them as optional.
If .github/copilot-instructions.md does not exist, skip this step.
23. Summary
Print a summary of what was created:
- List every file and directory generated
- Note which optional features were included (clap, macOS-only)
- Remind the user to:
- Run
make helpto see available Makefile targets - Run the add-community-files skill to add CONTRIBUTING.md, CODE_OF_CONDUCT.md, .github/SECURITY.md, and .github/PULL_REQUEST_TEMPLATE.md
- Run the set-up-installers skill when ready to set up a Homebrew formula and shell install script
- Tag a release with
git tag v0.1.0 && git push origin v0.1.0to trigger the release workflow - Use
make changelog(requiresgit-cliff) to generate the changelog from conventional commits
- Run
Error Handling
- If
cargo buildfails, check that Rust is installed and on the PATH. Verify the edition is supported by the installed toolchain. - If
cargo buildfails for clap, check that the dependency specification is correct inCargo.toml - If the target directory already contains Rust files (
Cargo.toml,src/), 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/cargo-toml.md--Cargo.tomltemplate./references/main-rs.md--src/main.rswithout clap./references/main-rs-with-clap.md--src/main.rswith clap./references/rust-toolchain.md--rust-toolchain.toml./references/rustfmt.md--rustfmt.toml./references/deny.md--deny.toml./references/typos.md--typos.toml./references/cliff.md--cliff.toml./references/makefile.md-- Makefile template./references/gitignore.md--.gitignoretemplate./references/ci-workflow.md-- cross-platform CI workflow./references/ci-workflow-macos-only.md-- macOS-only CI workflow./references/release-workflow.md-- cross-platform release workflow./references/release-workflow-macos-only.md-- macOS-only release workflow./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