scaffold-project

Plans and applies approved repository scaffolds through digest-bound, guarded file operations.

7|5|Updated Jul 22, 2025
One-click install
npx skills add https://github.com/nebius/nebius-ps-services --skill scaffold-project-nebius
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: scaffold-project
Source: https://github.com/nebius/nebius-ps-services/tree/main/skills/scaffold-project
Command: npx skills add https://github.com/nebius/nebius-ps-services --skill scaffold-project-nebius

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes scripts (resource) and references (resource) components.

What problem does it solve? Creating a new repository or adding components to an existing one often means hand-assembling files across Python, frontend, Terraform, Helm, container, and CI concerns, with risks of overwriting existing content or drifting from the approved architecture. This Skill converts an approved architecture into a path-owned scaffold plan and applies it only through a validated, digest-bound executor. ## Core Features & Use Cases - Path-ownership planning: Assigns exactly one specialist owner (python-project, frontend-project, container, terraform, helmchart, github-workflows, gitignore, shell-scripting) to every planned file and rejects collisions or unsupported artifacts. - Digest-bound guarded apply: Finalizes candidates into a private 0700 bundle, validates manifests and preconditions, and applies only after explicit approval of the exact bundle digest, with atomic no-replace publication and a crash-safe journal. - Brownfield-safe merges: Supports create, unchanged, and restricted semantic-merge operations for .gitignore, README.md, and Makefile without deleting or blindly overwriting existing content. - Use Case: After an app-stack decision approves a React/Vite frontend plus Python backend, invoke the skill to produce the full repository tree, review the operations and digest, then apply it with zero network, Git, or install side effects. ## Quick Start Ask the agent to run $scaffold-project to plan a new repository scaffold from your approved architecture, review the proposed tree and digest, then approve that exact digest to apply it.

Frequently Asked Questions about scaffold-project

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I scaffold a new repository from an approved architecture?

Explicitly invoke $scaffold-project with the target directory and approved architecture reference. It plans the topology, collects exact candidate files from specialist skills, finalizes a digest-bound bundle, and applies only after you approve the exact digest.

Can scaffold-project add a component to an existing repository?

Yes, it supports additive brownfield standardization. Existing files are classified per path, and only create, unchanged, or restricted semantic-merge operations on .gitignore, README.md, and Makefile are permitted, with backups kept in private state.

Does scaffold-project choose technologies or run package installs?

No. It never selects the stack, initializes Git, installs dependencies, accesses the network, provisions, deploys, or commits. Those remain separate explicitly authorized actions; technology decisions must come from an approved design or app-stack handoff.

What happens if a scaffold apply is interrupted mid-way?

The executor stops, marks the journal partial, and preserves completed writes. Run the status command to classify each path as before, after, or conflict; resume only when every path matches a recorded state, with no automatic rollback.

Which platforms support the scaffold apply step?

Apply supports macOS and Linux with POSIX descriptor and locking primitives, requiring renameatx_np(RENAME_EXCL) or renameat2(RENAME_NOREPLACE). Other platforms can plan, finalize, validate, and inspect status but apply fails closed.

When should I not use scaffold-project?

Avoid it for undecided architecture, isolated single-language work better handled by a specialist skill directly, feature or business-logic implementation, and any active Agentic SDLC workflow, which it must not invoke or modify.