Run any Skill in Manus with one click

install-stack

Stars0

Forks1

UpdatedJune 25, 2026 at 21:50

Use this skill to install and scaffold a project from an approved, version-pinned stack YAML (the output of the decide-stack skill). Trigger it whenever a user has a locked stack file and wants the project actually set up, or says "install my stack", "set up the project from this YAML", "scaffold the project", "run the installs", or hands you a stack file with concrete tools, versions, and install steps. This skill runs real commands on the user's machine: it goes through the stack in install order, runs each tool's official install steps at the pinned version, handles interactive prompts, verifies each step, and continues until the project is fully set up. It does NOT choose tools or research them; that is the separate decide-stack skill.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

pricklywiggles

pricklywiggles/fractally-claude-marketplace

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

File Explorer

3 files

SKILL.md

readonly

name

install-stack

description

Install Stack

Install and scaffold a project from an approved, version-pinned stack YAML produced by the decide-stack skill. This skill runs real commands that modify the user's machine, so it proceeds deliberately and keeps the user informed.

Input

Expect the locked stack YAML from decide-stack, by default at .claude/stack-it/stack.yaml (or a path the user gives):

project:
  description: ...
  type: ...
  platforms: [...]
stack:
  - slot: <category>
    choice: <chosen tool>
    version: <exact pinned version>
    install:
      - <official install command or step>
    caveats: [...]
    notes: <or null>

The stack list order is the install order; trust it. If no stack YAML is present at .claude/stack-it/stack.yaml (and the user gives no other path), ask for it or point the user to decide-stack first. This skill installs; it doesn't choose or research tools.

Before doing anything, validate the file with ${CLAUDE_PLUGIN_ROOT}/scripts/validate_yaml.py --stage stack .claude/stack-it/stack.yaml. A malformed or unversioned stack file should fail here, before any command runs. Surface any caveats from the file to the user up front so they go in aware of known issues, even though those were already discussed in the decide stage.

Execution rules

Go through the stack list in order and run each entry's install steps. Because the list is dependency-ordered, installs are generally sequential and must not be parallelized (a plugin can't install before its framework). Where two adjacent entries are genuinely independent (no shared dependency, no ordering relationship), they may run concurrently, but only when you're confident the order doesn't matter; when in doubt, stay sequential.

For each step:

Show before running. Show the user the exact command before running anything that changes the system. Routine, expected installs can run as you go with a report of what you did; anything destructive, irreversible, or surprising needs confirmation first.
Install the pinned version. Use the exact version from the YAML, not "latest", so the result matches what was vetted in the decide stage.
Handle interactive prompts as they come. Installers and scaffolding tools often ask questions (project name, options, feature toggles). Answer from the project context and the YAML where the answer is clear; ask the user when it's a real preference you can't infer.
Verify each step before moving on. After each install, do a quick success check (version prints, command resolves, expected files exist). If a step fails, stop and resolve it with the user before continuing; don't plow ahead on a broken foundation.
Respect the boundary. Don't enter credentials, create accounts, log in, or modify access controls on the user's behalf. If a step needs a secret, an account, or a sign-in, hand that step to the user with clear instructions and continue once they confirm it's done.
Keep the lockfile current. When what actually gets installed diverges from the file (you had to take the nearest available patch of a pinned version, an install step needed adjusting to work, or a caveat turned out resolved or newly relevant), update .claude/stack-it/stack.yaml in place so it stays an accurate record of the installed stack for scaffold-and-verify and the user. This is for staying faithful to reality within each slot's chosen tool. It is not license to change which tool fills a slot: if a chosen tool can't be installed at all, stop and send the user back to decide-stack rather than silently substituting another.

Finishing

Continue until the project is fully set up. Then give a short summary: the tools and versions installed, anything the user still needs to do manually (accounts, secrets, env files), and the obvious next step (how to run the dev server, the test suite, or the build).

Bundled resources

${CLAUDE_PLUGIN_ROOT}/scripts/validate_yaml.py: Validates the locked stack file before installation: checks that every entry has a choice, an exact version, and at least one install step, and that the file parses. Run python ${CLAUDE_PLUGIN_ROOT}/scripts/validate_yaml.py --help for usage. Always run this first; it's cheap insurance against a malformed handoff.

More from this repository

same repository

decide-stack

pricklywiggles/fractally-claude-marketplace

Use this skill to turn a list of project stack slots (decision categories like "web framework", "test framework", "database") into concrete, version-pinned, security-vetted tool choices. This is the decision stage that comes after identify-stack-slots and before install-stack. Trigger it whenever a user has a slots YAML and needs to pick the actual tools, or says "pick my stack", "choose tools for these slots", "research and recommend my dependencies", "what should I use for each part of my stack", or hands you a slots list to fill in. This skill collects hard preferences, settles the keystone language/framework decision first (presented as a coupled pair when the two are tightly linked, so a downstream pick never silently corners the language), researches each remaining open slot's options and versions in that constraint, gets the user's picks, then pulls the exact version-specific install steps from each chosen tool's official docs, checks known vulnerabilities and recent-release supply-chain threats, and o

2026-06-250

identify-stack-slots

pricklywiggles/fractally-claude-marketplace

Use this skill at the very start of a brand new coding project of any kind (CLI, web app, API service, library, mobile app, desktop app, server, etc.) to figure out the categories of technology decisions the project's stack is composed of. Trigger this whenever a user is kicking off a new project and needs to plan their stack, asks "what do I need to decide" / "help me set up the stack" / "I'm starting a new X project", or whenever you're about to scaffold a project and haven't yet established which decision categories apply. This produces a YAML list of stack "slots" (categories like "web framework", "test framework", "database"), NOT concrete tool picks. The YAML output feeds a later stage that fills each slot.

2026-06-250

setup-stack

pricklywiggles/fractally-claude-marketplace

Use this skill to run the entire stack-it pipeline end to end in one guided pass. It takes a project from nothing to a working, verified, documented tech stack by running each stage skill in order (identify-stack-slots, decide-stack, install-stack, scaffold-and-verify, document-stack), resumes from wherever the project already is, optionally sets up git and commits a checkpoint after each stage, and keeps a running task list so the user can see how much is left. Use it whenever someone wants their whole stack set up rather than just one step. Phrasings like "set up my stack", "set up my whole project stack", "help me start a new project from scratch", "pick, install, and verify my stack", "take me from zero to a working project", "bootstrap my project", or "run the whole stack-it pipeline" should trigger it. It pauses only where it genuinely needs the user (their tool picks in the decide stage, an install confirmation, a stack-fault re-pick, an OK before writing docs) and handles the loop where a broken tool

2026-06-250

ci-fix

pricklywiggles/fractally-claude-marketplace

Watch a pull request's CI to completion and fix any failures in its branch, bounded and cause-only. Use when CI is red on a PR or branch and you want it driven to green ("fix the CI on this PR", "CI is failing, sort it out", "watch the checks and fix what breaks"). Acts on a PR number, URL, or branch you name, or the current branch's open PR if you name none. Also called by the ship-it orchestrator's post-PR phase, one watcher per PR. Not for reviewing code quality (use a reviewer) or fixing local errors with no PR/CI (just fix those directly).

2026-06-230

comment-cleanup

pricklywiggles/fractally-claude-marketplace

Audit code comments against the user's strict "comments explain non-obvious why, never narrate what the code does" standard, and propose concrete fixes (keep / trim / delete, or clarify the code so the comment is unnecessary). Use this whenever the user asks to review, audit, clean up, sanity-check, or justify comments; whenever they ask "did I follow the comment rules / our comment guidelines"; right after writing or heavily editing code; and before committing or opening a PR. Also use it proactively when you have just generated more than a couple of comments. The caller may restrict the audit to a path, a function/symbol, a glob, "staged", "the branch diff", or "the PR"; if no scope is given, audit only newly written or changed code, never the whole repo.

2026-06-230

fix-one-issue

pricklywiggles/fractally-claude-marketplace

Implement a single work-unit (a tracker issue or a described task) end to end in its branch: explore, make the smallest correct change, verify, and commit. Use for "implement this issue", "fix issue 123", "make this change and verify it". The implement stage of the ship-it orchestrator, and usable standalone on an issue or a described task. Not for review (use review-and-address), comments (comment-cleanup), or CI (ci-fix).

2026-06-230

name

install-stack

description

Install Stack

Input

Expect the locked stack YAML from decide-stack, by default at .claude/stack-it/stack.yaml (or a path the user gives):

project:
  description: ...
  type: ...
  platforms: [...]
stack:
  - slot: <category>
    choice: <chosen tool>
    version: <exact pinned version>
    install:
      - <official install command or step>
    caveats: [...]
    notes: <or null>

Execution rules

For each step:

Show before running. Show the user the exact command before running anything that changes the system. Routine, expected installs can run as you go with a report of what you did; anything destructive, irreversible, or surprising needs confirmation first.
Install the pinned version. Use the exact version from the YAML, not "latest", so the result matches what was vetted in the decide stage.
Handle interactive prompts as they come. Installers and scaffolding tools often ask questions (project name, options, feature toggles). Answer from the project context and the YAML where the answer is clear; ask the user when it's a real preference you can't infer.
Verify each step before moving on. After each install, do a quick success check (version prints, command resolves, expected files exist). If a step fails, stop and resolve it with the user before continuing; don't plow ahead on a broken foundation.
Respect the boundary. Don't enter credentials, create accounts, log in, or modify access controls on the user's behalf. If a step needs a secret, an account, or a sign-in, hand that step to the user with clear instructions and continue once they confirm it's done.
Keep the lockfile current. When what actually gets installed diverges from the file (you had to take the nearest available patch of a pinned version, an install step needed adjusting to work, or a caveat turned out resolved or newly relevant), update .claude/stack-it/stack.yaml in place so it stays an accurate record of the installed stack for scaffold-and-verify and the user. This is for staying faithful to reality within each slot's chosen tool. It is not license to change which tool fills a slot: if a chosen tool can't be installed at all, stop and send the user back to decide-stack rather than silently substituting another.

Finishing

Bundled resources

${CLAUDE_PLUGIN_ROOT}/scripts/validate_yaml.py: Validates the locked stack file before installation: checks that every entry has a choice, an exact version, and at least one install step, and that the file parses. Run python ${CLAUDE_PLUGIN_ROOT}/scripts/validate_yaml.py --help for usage. Always run this first; it's cheap insurance against a malformed handoff.