From arn-spark
This skill should be used when the user says "scaffold", "arn scaffold", "set up the project", "create project", "initialize project", "bootstrap project", "create the skeleton", "install dependencies", "configure the project", or wants to create a working project skeleton from architecture decisions with installed dependencies, configured build tools, and a UI toolkit ready for development.
npx claudepluginhub appsvortex/arness --plugin arn-sparkThis skill uses the workspace's default tool permissions.
Searches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.
Searches prompts.chat for AI prompt templates by keyword or category, retrieves by ID with variable handling, and improves prompts via AI. Use for discovering or enhancing prompts.
Benchmarks web page Core Web Vitals/bundle sizes, API latency under load, build times; detects regressions via before/after PR comparisons.
Set up a working project skeleton from architecture vision decisions through guided conversation, aided by the arn-spark-scaffolder agent for project creation and optionally the arn-spark-tech-evaluator agent for UI toolkit comparisons. This is a conversational skill that runs in normal conversation (NOT plan mode). The primary artifact is a buildable project with all dependencies installed and configured.
This skill covers the initial project setup: framework scaffolding, dependency installation, build configuration, linting, and UI toolkit setup. It does not implement features, create screens, or write application logic -- those are handled by subsequent skills (/arn-spark-spike, /arn-spark-style-explore, /arn-spark-static-prototype, /arn-spark-clickable-prototype).
An architecture vision document must exist. Check in order:
CLAUDE.md for a ## Arness section. If found, check the configured Vision directory for architecture-vision.md## Arness section exists or Arness Spark fields are missing, inform the user: "Arness Spark is not configured for this project yet. Run /arn-brainstorming to get started — it will set everything up automatically." Do not proceed without it.## Arness exists but no architecture vision found, check .arness/vision/architecture-vision.md at the project rootIf an architecture vision is found: Read it and proceed to Step 1.
If no architecture vision is found: Inform the user:
"No architecture vision document found. I recommend running /arn-spark-arch-vision first to define your technology stack. The scaffold needs to know which frameworks, build tools, and libraries to set up."
Do not proceed without an architecture vision or explicit technology stack from the user.
Determine the project root:
package.json, Cargo.toml, or similar, warn the user: "This directory already has a project manifest. Do you want to extend the existing project or start fresh in a subdirectory?"Read the architecture vision document. Extract technology decisions for each layer:
Also load the product concept document (same Vision directory) and extract the Product Pillars section if it exists. Pillars guide UI toolkit decisions in Step 2 — for example, a "design fidelity" pillar means the component library must allow full visual customization, while a "simplicity" pillar favors pre-styled components with minimal configuration.
Present the extracted stack and relevant pillars to the user:
"Based on your architecture vision, here is the stack I will scaffold:
| Layer | Technology |
|---|---|
| Framework | [value] |
| UI | [value] |
| Build | [value] |
| ... | ... |
[If pillars found:] Your product pillars that will guide UI toolkit choices:
Ask (using AskUserQuestion):
"Does this stack look right?"
Options:
The architecture vision defines the high-level UI framework (e.g., Svelte) but typically does not specify the CSS approach and component library. These decisions happen now because they affect the scaffold setup and all subsequent work (style exploration, prototyping, production code).
When product pillars are available, annotate each option with how it serves or challenges the pillars. This helps the user make an informed choice aligned with their product's non-negotiable qualities.
Profile-aware recommendations: Read user profile. Check .claude/arness-profile.local.md first (project override takes precedence), then ~/.arness/user-profile.yaml. Also check .arness/preferences.yaml for project-level team preferences. If the user lists specific frameworks (e.g., "React"), suggest compatible component libraries the user likely knows. If development_experience: learning, favor pre-styled libraries (DaisyUI, Chakra) over headless ones (shadcn, Radix) -- pre-styled libraries have less configuration overhead and visible results faster. If development_experience: non-technical, favor the most mainstream option with the largest community and most tutorials. Apply the advisory pattern for all toolkit recommendations: present the technically optimal recommendation first, then a preference-aligned alternative with pros/cons if they differ.
Ask the user about each:
CSS approach:
Ask (using AskUserQuestion):
"Which CSS framework should we use?"
Offer common options for the chosen UI framework, noting pillar alignment where relevant. For example, for Svelte with a "design fidelity" pillar:
Options:
Component library:
Ask (using AskUserQuestion):
"Which component library should we use?"
Offer common options for the chosen UI framework + CSS approach, noting pillar alignment. For example, for Svelte + Tailwind with a "design fidelity" pillar:
Options:
Note: Limit to 4 options. If more options exist, group or prioritize based on the chosen framework.
Icon library (optional):
Ask (using AskUserQuestion):
"Do you want an icon library?"
Options:
If the user is unsure about CSS or component library choices, invoke the arn-spark-tech-evaluator agent with a head-to-head comparison request for the specific options — include the product pillars so the evaluator can assess pillar alignment. Present the comparison and let the user decide.
Record all UI toolkit decisions for the scaffolder.
Invoke the arn-spark-scaffolder agent with:
The agent creates the project structure, installs dependencies, configures build tools, sets up the UI toolkit, creates a minimal entry point, and runs the build to verify.
Staging behavior: When using official project creation tools (npm create, etc.), the scaffolder uses a _scaffold-staging/ subdirectory to avoid overwriting existing project content (.arness/, CLAUDE.md, .git/, and any other files already present). Generated files are merged into the project root after creation, skipping any that already exist. The staging directory is removed after a successful merge. On failure, the staging directory is left in place so the user can inspect it.
After the scaffolder reports completion, verify using the scaffold checklist:
Read
${CLAUDE_PLUGIN_ROOT}/skills/arn-spark-scaffold/references/scaffold-checklist.md
Walk through all checklist categories:
For any failed checks:
Write a scaffold summary document so downstream skills have a record of the full technology stack including UI toolkit decisions made during scaffolding.
Read the template:
Read
${CLAUDE_PLUGIN_ROOT}/skills/arn-spark-scaffold/references/scaffold-summary-template.md
Populate the template with the scaffolding results:
Determine the output directory:
CLAUDE.md for the configured Vision directory.arness/vision at the project rootWrite the document to the Vision directory as scaffold-summary.md
Present what was created:
"Project scaffolded successfully. Here is what was set up:
Stack:
| Layer | Technology | Version |
|---|---|---|
| ... | ... | ... |
Key files created:
Commands:
[command][command][command][command]Build result: [pass/fail]
Scaffold summary saved to [path]/scaffold-summary.md.
Recommended next steps:
/arn-spark-dev-setup to configure setup scripts, CI, dev containers, and developer onboarding/arn-spark-spike to test technical risks from your architecture vision/arn-spark-style-explore to define the look and feel"Adapt next steps based on context. If the architecture vision identified critical risks, emphasize spiking first. If the user is eager to see UI, suggest style exploration.
| Situation | Action |
|---|---|
| Initial scaffold (Step 3) | Invoke arn-spark-scaffolder with full stack + UI toolkit decisions |
| User unsure about CSS framework | Invoke arn-spark-tech-evaluator with comparison request |
| User unsure about component library | Invoke arn-spark-tech-evaluator with comparison request |
| User asks about code patterns | Defer: "Code patterns will be established when features are built. The scaffold just sets up the foundation." |
| User asks about features or screens | Defer: "Features come after the scaffold. Next steps are /arn-spark-spike or /arn-spark-style-explore." |
| Build fails after scaffold | Ask arn-spark-scaffolder to diagnose and fix |
/arn-spark-arch-vision first./arn-spark-scaffold to continue or start fresh.