new-project
- Repo stars 0
- Author updated Live
- Author repo skills-registry
- Domain
- Documentation
- 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
- Plug-and-play
- External API key
- Not required
- Operating systems
- Unspecified (assume cross-platform)
- Runtime requirements
- Python
- Permissions
-
- Read-only
- Write / modify
- Env read
- 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: new-project
description: Scaffold a new project with the full AI-assisted development workflow — Makefile targets, linter…
category: documentation
runtime: Python
---
# new-project output preview
## PART A: Task fit
- Use case: Scaffold a new project with the full AI-assisted development workflow — Makefile targets, linter/formatter configs, pre-commit hooks, CLAUDE.md, docs skeleton, tailored to the chosen stack (python, go, typescript/nextjs, rust, etc.). Use when the user says 'start a new project', 'bootstrap a repo', 'scaffold X', 'set up a fresh codebase for Y', 'init a new service'. Use when this capability is needed..
- Inputs: target material, constraints, expected output, and acceptance criteria.
- Evidence boundary: follow “Process / 1. Interview (if needed) / 2. Initialize the project” and do not present inference as author intent.
## PART B: Execution result
- **01** The card summarizes the use case; runtime output centers on “Scaffold a new project with the full AI-assisted development workflow — Makefile targets, linter/formatter configs, pre-commit hooks, CLAUDE.md, docs skeleton, tailored to the chosen stack (python, go, typescript/nextjs, rust, etc.). Use when the user says 'start a new project', 'bootstrap a repo', 'scaffold X', 'set up a fresh codebase for Y', 'init a new service'. Use when this capability is needed.”.
- **02** When the source has headings, the agent prioritizes “Process / 1. Interview (if needed) / 2. Initialize the project” 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, read environment variables; mostly runs locally; usually needs no extra API key.
## Running Rules
- read files, write/modify files, read environment variables; 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 mentions slash commands such as `/new-project`, `/architecture`, `/tdd`, `/security`, `/adr`; use them first when your agent supports command triggers.
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, read environment variables.
Start with a small task and check whether the result follows “Process / 1. Interview (if needed) / 2. Initialize the project”. 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: new-project
description: Scaffold a new project with the full AI-assisted development workflow — Makefile targets, linter…
category: documentation
source: tomevault-io/skills-registry
---
# new-project
## When to use
- Scaffold a new project with the full AI-assisted development workflow — Makefile targets, linter/formatter configs, pr…
- 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 “Process / 1. Interview (if needed) / 2. Initialize the project” and keep inference separate from source facts.
- read files, write/modify files, read environment variables; 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 "new-project" {
input -> user goal + target files + boundaries + acceptance criteria
context -> Process / 1. Interview (if needed) / 2. Initialize the project
rules -> SKILL.md triggers / order / output contract
runtime -> Python | read files, write/modify files, read environment variables | mostly runs locally
guardrails -> usually needs no extra API key + small-sample validation + diff/log review
output -> copyable result + checklist + next iteration
} Scaffold a new project with the AI-assisted development workflow.
Argument format: <project-name> [language/framework]
<project-name>(required) — name of the project directory to create[language/framework](optional) — the tech stack, used to tailor Makefile targets, linter config, .gitignore, and pre-commit hooks. Examples:python,python/fastapi,go,typescript/nextjs,rust. If omitted, you will be asked.
Examples:
/new-project my-api python/fastapi— creates./my-api/with Python/FastAPI tooling/new-project my-cli go— creates./my-cli/with Go tooling/new-project my-app— creates./my-app/, asks what stack to use
Process
1. Interview (if needed)
If no language/framework was given, ask the user:
- What language/framework?
- What type of project? (API, CLI, library, web app, etc.)
- Any specific tooling preferences? (test framework, linter, etc.)
2. Initialize the project
Create the project directory inside the current working directory and initialize git:
mkdir -p <project-name>
cd <project-name>
git init
The project is created at $PWD/<project-name>/. If you want it elsewhere, cd to the desired parent directory first.
3. Create workflow structure
Create these directories:
.claude/
.claude/agents/
docs/
docs/specs/
docs/roadmap/
docs/adr/
docs/rfc/
Note: Skills are installed globally at ~/.claude/skills/. Do NOT create project-level skill copies — they'd duplicate and drift from the global versions. The global skills (/architecture, /tdd, /security, /adr, /rfc, /spec, /roadmap, /feature, /fix, /review, /autopilot) are already available. For stack-aware code review, install Anthropic's official code-review skill from claude-code-plugins. Only create project-level agents and settings.
4. Create CLAUDE.md
Create a CLAUDE.md at the project root tailored to the language/framework:
# CLAUDE.md
## Build & Test
- `make test` — run test suite
- `make lint` — run linters
- `make typecheck` — type checking (if applicable)
- `make build` — build the project (if applicable)
## Code Style
- [Language-specific conventions that Claude might get wrong]
## Architecture
- [Brief description of project structure]
## Workflow
- All PRs require passing CI + human review
- Commit messages use conventional commits (feat:, fix:, refactor:, chore:)
- Security-sensitive changes require /sec-review before PR
- Features start with a spec in docs/specs/
Adapt the build commands and style section to the chosen language/framework.
5. Create project-level agents
Copy the security-reviewer and architecture-reviewer into .claude/agents/, tailored to the project's language if needed.
6. Create project-level settings
Create .claude/settings.json with hooks appropriate to the language:
{
"hooks": {
"PostToolUse": [
{
"matcher": "Edit|Write",
"command": "make lint-changed 2>&1 | head -20",
"description": "Lint after every file edit"
}
]
}
}
7. Create Makefile
Create a Makefile with standard targets for the chosen language/framework:
test— run testslint— run lintertypecheck— run type checker (if applicable)build— build (if applicable)lint-changed— lint only changed filessecurity-scan— run security scanner (gitleaks, bandit, gosec, etc.)
8. Create .pre-commit-config.yaml
Set up pre-commit hooks:
- Language-appropriate linter
- Type checker (if applicable)
- Test runner
- gitleaks for secret detection
9. Create .gitignore
Appropriate for the language/framework. Always include:
.claude/local files.env- Language-specific build artifacts
10. Create initial docs
Create .gitkeep files to preserve directory structure:
docs/specs/.gitkeepdocs/roadmap/.gitkeepdocs/adr/.gitkeepdocs/rfc/.gitkeep
11. Summary
Tell the user what was created and suggest next steps:
cd <project-name>pre-commit install/prd <project-name>— define what we're building/architecture— define system structure/tdd— define testing strategy, dev environment, CI/CD/security— define the threat model (if applicable)/spec <first-feature>— write your first feature spec/feature docs/specs/<first-feature>.md— implement it
Source: 0xrafasec/ai-workflow — distributed by TomeVault.
Decide Fit First
Design Intent
How To Use It
Boundaries And Review