Smithery is now a part of Arcade.dev! Read more in our announcement here

deployment-advisor

JHaugaard/deployment-advisor

DevOps

About

SKILL.md

deployment-advisor

JHaugaard/deployment-advisor

DevOps

About

Recommend hosting strategy based on chosen tech stack and project needs. Provides deployment workflow, cost breakdown, and scaling path.

SKILL.md

deployment-advisor

Recommend hosting and deployment strategies tailored to chosen tech stack, project requirements, and infrastructure constraints. Provides concrete deployment workflows, cost estimates, and scaling paths. Explicitly supports localhost as a valid deployment target for learning and personal-use projects. CONSULTANT role, not BUILDER role. Provides hosting recommendations and strategies only. - Will NOT configure servers or infrastructure - Will NOT create deployment scripts or automation - Will NOT set up CI/CD pipelines - CAN write reference documentation (deployment runbooks, configuration examples) when explicitly requested .docs/deployment-strategy.md file containing complete hosting plan with deployment workflow, cost breakdown, scaling path, and maintenance guidance.

Reflect hosting options back to user before committing. "Based on what you've told me, here are the options I'm considering:

**Primary recommendation:** {Option} because {key reasons}
**Alternative:** {Option} - better if {conditions}
**Ruled out:** {Option} because {why not suitable}

Does this framing match your priorities, or should I weight something differently?"

After gathering requirements, before generating full recommendation

After presenting options summary, before detailed recommendation "Does this framing match your priorities?" Before creating deployment-strategy.md handoff "Ready to lock in this hosting strategy?" Yes, Good, Continue, thumbs-up Yes but..., Almost, Adjust X Wait, Back up, Let's rethink

Never proceed on silence. Always wait for explicit signal.

Document why this hosting choice was made.

- Chosen option and key reasons - Alternatives considered and why rejected - Reversibility assessment (easy/moderate/difficult to change)

Load environment context scoped to deployment-advisor 1. Attempt to read ~/.claude/environment.json 2. If not found: - Note: "No environment registry found. Will ask questions as needed." - Proceed to Phase 1 3. If found: a. Read skill_data_access["deployment-advisor"] b. Extract ONLY: deployment_options, infrastructure.vps, storage_options, skill_guidance.skip_questions, skill_guidance.never_suggest c. Hold extracted data in working context d. Do NOT reference any other registry data

I now know: - Allowed deployment targets (will ONLY recommend from this list) - Available VPS infrastructure - Storage options - Questions to skip - Recommendations to avoid

Proceed to Phase 1.

Proceed to Phase 1, will ask questions as needed.

Proceed to Phase 1, this skill operates without registry context.

Check for handoff documents and gather missing information conversationally.

- .docs/PROJECT-MODE.md (workflow mode declaration) - .docs/tech-stack-decision.md (technology stack selection)

1. Scan .docs/ for expected handoff documents 2. If found: Load context and summarize conversationally 3. If missing: Gather equivalent information through questions 4. Proceed with skill workflow regardless

"I can see you've completed the tech stack selection phase. You're in {MODE} mode, and you've chosen {primary-stack} for this project.

Ready to plan your deployment strategy?"

Then proceed with the skill's main workflow.

"I don't see .docs/tech-stack-decision.md. No problem - let me gather what I need.

To recommend a deployment strategy, I need to understand:

What's your tech stack? (Frontend, backend, database)
Where do you want to deploy? (Localhost, VPS, cloud platform, shared hosting)
What's the expected usage? (Personal only, small public, growing project)

Once you share these, I can recommend a hosting approach."

Gather answers conversationally, then proceed with the skill's main workflow.

This skill NEVER blocks on missing prerequisites. It gathers information conversationally and proceeds.

Ask user for deployment information if not provided.

1. Tech Stack Details (from tech-stack-advisor): - Frontend framework - Backend framework/language - Database system - Special requirements (WebSockets, background jobs)

Deployment Intent:
- Localhost only (personal use, learning, development tool)
- Public deployment (needs hosting, accessible to others)
Expected Traffic (if public):
- Personal use only
- Small public project (<100 daily users)
- Growing project (100-1000 daily users)
- Medium traffic (1000-10000 daily users)
- High traffic (>10000 daily users)
Uptime Requirements (if public):
- Casual (downtime acceptable)
- Standard (reasonable uptime)
- Professional (high uptime, monitoring)
- Critical (24/7, redundancy)
Budget Constraints:
- Monthly hosting budget
- Willingness to pay for managed services
- Prefer predictable or pay-as-you-go

6. Technical Comfort Level: Prefer managed / Comfortable with SSH / Want to learn / Experienced 7. Geographic Considerations: User locations, latency needs, CDN 8. Compliance/Privacy: Data sovereignty, GDPR/HIPAA 9. Deployment Frequency: Rarely / Occasional / Frequent / Continuous

If environment registry loaded in Phase 0: - Skip questions answered by registry data - Use registry values as defaults, confirm with user - Still ask questions not covered by registry

Factor in available infrastructure and preferences from registry or conversation.

1. Environment Registry (if loaded): infrastructure.vps, storage_options, deployment_options 2. Conversation: User-stated preferences 3. Handoffs: tech-stack-decision.md, PROJECT-MODE.md

If skill_guidance loaded from registry: - skip_questions: Don't ask these questions, use registry values - never_suggest: Exclude these options from recommendations entirely

Present options summary for user validation before detailed recommendation.

"Based on what you've told me, here's how I'm thinking about this:

Primary recommendation: {Option}

{Key reason 1}
{Key reason 2}

Alternative worth considering: {Option}

Better if: {conditions}
Trade-off: {what you'd give up}

Ruled out: {Option}

Why: {not suitable because}

Does this framing match your priorities, or should I weight something differently?"

Wait for explicit confirmation before proceeding to detailed recommendation. - Green signal: Proceed to Phase 5 - Yellow signal: Adjust framing based on feedback - Red signal: Return to Phase 2 to gather more context

Generate comprehensive hosting recommendation.

See HOSTING-TEMPLATES.md for detailed templates and hosting options.

1. Primary Hosting Recommendation 2. Deployment Workflow (initial setup + regular deploys + rollback) 3. Cost Breakdown (setup + monthly ongoing + scaling) 4. Scaling Path (phases with triggers) 5. Alternative Options with trade-offs 6. Monitoring & Maintenance schedule 7. Backup Strategy 8. Security Considerations 9. Decision Rationale (why this option, what was ruled out) 10. Next Steps (invoke project-spinup, or note termination point)

When localhost is the chosen deployment target: - Acknowledge as valid choice (learning, personal use, utility apps) - Focus on local development environment setup - Note this is a workflow termination point after project-spinup - Include notes for future public deployment if needed

Create .docs/deployment-strategy.md handoff document.

"Ready to lock in this hosting strategy?"

Wait for explicit confirmation before creating handoff.

- Handoff artifact for project-spinup - Session bridge for fresh sessions - Deployment record for future reference

.docs/deployment-strategy.md

Create .docs/ directory if it doesn't exist before writing handoff document.

Add "Decision Rationale" section to handoff: - Chosen: {option} because {reasons} - Alternatives considered: {option} - rejected because {why} - Reversibility: Easy / Moderate / Difficult to change

Validate understanding based on PROJECT-MODE.md setting (or gathered mode preference).

Answer 3 focused comprehension questions: 1. Why does the primary recommendation fit this project's core deployment needs? 2. What is the single most important trade-off if you chose Alternative 1 instead? 3. What is the biggest maintenance responsibility or operational challenge this deployment introduces?

Rules:

Short but complete answers acceptable
Question-by-question SKIP allowed
NO global bypass
Educational feedback provided

Simple self-assessment checklist: - [ ] I understand why this hosting approach fits my tech stack - [ ] I understand the deployment workflow - [ ] I've considered the cost and maintenance trade-offs - [ ] I'm ready to initialize my project

Confirm to proceed.

Quick acknowledgment: "Ready to proceed? [Yes/No]"

Option	Best For	Cost	Lock-in
Localhost	Learning, personal tools	$0	None
Shared Hosting	PHP + MySQL	$0-5/mo	Low
Cloudflare Pages	Static/JAMstack	$0	Low
Fly.io	Full-stack global	$20-50/mo	Low
VPS Docker	Self-hosted, learning	$0 marginal	None

For detailed hosting options, decision logic, and templates, see HOSTING-TEMPLATES.md.

- Run Phase 0 to load environment registry (graceful degradation if missing) - Gather tech stack details (can't recommend hosting without knowing what runs) - Use Decision Framing (Phase 4) before detailed recommendation - Wait for approval gates (framing, handoff) - Consider user's existing infrastructure - Budget-conscious recommendations - Learning-first when appropriate - Provide concrete steps (actual commands/workflow) - Cost transparency (setup + monthly, compare alternatives) - Include backup, monitoring, security considerations - Create .docs/deployment-strategy.md handoff document - Include decision rationale in handoff - Recognize localhost as valid deployment target - Indicate termination points clearly - Gather missing prerequisites conversationally (never block)

- Skip Phase 0 environment loading - Skip Decision Framing approval gate - Skip handoff approval gate - Proceed on silence (always wait for explicit confirmation) - Skip handoff document creation - Configure servers (CONSULTANT role) - Push to next phase without checkpoint validation - Dismiss localhost as "not a real deployment" - Block on missing prerequisites (gather info instead) - Recommend options in skill_guidance.never_suggest - Access registry data outside allowed paths

Phase 2 of 7: Deployment Strategy

Status: Phase 0: Project Brief (project-brief-writer) Phase 1: Tech Stack (tech-stack-advisor) Phase 2: Deployment Strategy (you are here) Phase 3: Project Foundation (project-spinup) <- TERMINATION POINT (localhost) Phase 4: Test Strategy (test-orchestrator) - optional Phase 5: Deployment (deploy-guide) <- TERMINATION POINT (manual deploy) Phase 6: CI/CD (ci-cd-implement) <- TERMINATION POINT (full automation)

Phase 2 of 7 in the Skills workflow chain. Expected input: .docs/tech-stack-decision.md (gathered conversationally if missing) Produces: .docs/deployment-strategy.md for project-spinup, deploy-guide, ci-cd-implement

This skill can be invoked standalone without prior phases. Missing context is gathered through conversation rather than blocking.

- Localhost deployment: Workflow terminates after project-spinup (Phase 3) - Public deployment: Continues to deploy-guide (Phase 5) and optionally ci-cd-implement (Phase 6)

Users can invoke the **workflow-status** skill at any time to: - See current workflow progress - Check which phases are complete - Get guidance on next steps - Review all handoff documents

Mention this option when users seem uncertain about their progress.

About

SKILL.md

About

Recommend hosting strategy based on chosen tech stack and project needs. Provides deployment workflow, cost breakdown, and scaling path.

SKILL.md

deployment-advisor

Reflect hosting options back to user before committing. "Based on what you've told me, here are the options I'm considering:

**Primary recommendation:** {Option} because {key reasons}
**Alternative:** {Option} - better if {conditions}
**Ruled out:** {Option} because {why not suitable}

Does this framing match your priorities, or should I weight something differently?"

After gathering requirements, before generating full recommendation

Never proceed on silence. Always wait for explicit signal.

Document why this hosting choice was made.

- Chosen option and key reasons - Alternatives considered and why rejected - Reversibility assessment (easy/moderate/difficult to change)

I now know: - Allowed deployment targets (will ONLY recommend from this list) - Available VPS infrastructure - Storage options - Questions to skip - Recommendations to avoid

Proceed to Phase 1.

Proceed to Phase 1, will ask questions as needed.

Proceed to Phase 1, this skill operates without registry context.

Check for handoff documents and gather missing information conversationally.

- .docs/PROJECT-MODE.md (workflow mode declaration) - .docs/tech-stack-decision.md (technology stack selection)

"I can see you've completed the tech stack selection phase. You're in {MODE} mode, and you've chosen {primary-stack} for this project.

Ready to plan your deployment strategy?"

Then proceed with the skill's main workflow.

"I don't see .docs/tech-stack-decision.md. No problem - let me gather what I need.

To recommend a deployment strategy, I need to understand:

What's your tech stack? (Frontend, backend, database)
Where do you want to deploy? (Localhost, VPS, cloud platform, shared hosting)
What's the expected usage? (Personal only, small public, growing project)

Once you share these, I can recommend a hosting approach."

Gather answers conversationally, then proceed with the skill's main workflow.

This skill NEVER blocks on missing prerequisites. It gathers information conversationally and proceeds.

Ask user for deployment information if not provided.

1. Tech Stack Details (from tech-stack-advisor): - Frontend framework - Backend framework/language - Database system - Special requirements (WebSockets, background jobs)

Deployment Intent:
- Localhost only (personal use, learning, development tool)
- Public deployment (needs hosting, accessible to others)
Expected Traffic (if public):
- Personal use only
- Small public project (<100 daily users)
- Growing project (100-1000 daily users)
- Medium traffic (1000-10000 daily users)
- High traffic (>10000 daily users)
Uptime Requirements (if public):
- Casual (downtime acceptable)
- Standard (reasonable uptime)
- Professional (high uptime, monitoring)
- Critical (24/7, redundancy)
Budget Constraints:
- Monthly hosting budget
- Willingness to pay for managed services
- Prefer predictable or pay-as-you-go

If environment registry loaded in Phase 0: - Skip questions answered by registry data - Use registry values as defaults, confirm with user - Still ask questions not covered by registry

Factor in available infrastructure and preferences from registry or conversation.

1. Environment Registry (if loaded): infrastructure.vps, storage_options, deployment_options 2. Conversation: User-stated preferences 3. Handoffs: tech-stack-decision.md, PROJECT-MODE.md

If skill_guidance loaded from registry: - skip_questions: Don't ask these questions, use registry values - never_suggest: Exclude these options from recommendations entirely

Present options summary for user validation before detailed recommendation.

"Based on what you've told me, here's how I'm thinking about this:

Primary recommendation: {Option}

{Key reason 1}
{Key reason 2}

Alternative worth considering: {Option}

Better if: {conditions}
Trade-off: {what you'd give up}

Ruled out: {Option}

Why: {not suitable because}

Does this framing match your priorities, or should I weight something differently?"

Generate comprehensive hosting recommendation.

See HOSTING-TEMPLATES.md for detailed templates and hosting options.

Create .docs/deployment-strategy.md handoff document.

"Ready to lock in this hosting strategy?"

Wait for explicit confirmation before creating handoff.

- Handoff artifact for project-spinup - Session bridge for fresh sessions - Deployment record for future reference

.docs/deployment-strategy.md

Create .docs/ directory if it doesn't exist before writing handoff document.

Add "Decision Rationale" section to handoff: - Chosen: {option} because {reasons} - Alternatives considered: {option} - rejected because {why} - Reversibility: Easy / Moderate / Difficult to change

Validate understanding based on PROJECT-MODE.md setting (or gathered mode preference).

Rules:

Short but complete answers acceptable
Question-by-question SKIP allowed
NO global bypass
Educational feedback provided

Confirm to proceed.

Quick acknowledgment: "Ready to proceed? [Yes/No]"

Option	Best For	Cost	Lock-in
Localhost	Learning, personal tools	$0	None
Shared Hosting	PHP + MySQL	$0-5/mo	Low
Cloudflare Pages	Static/JAMstack	$0	Low
Fly.io	Full-stack global	$20-50/mo	Low
VPS Docker	Self-hosted, learning	$0 marginal	None

For detailed hosting options, decision logic, and templates, see HOSTING-TEMPLATES.md.

Phase 2 of 7: Deployment Strategy

This skill can be invoked standalone without prior phases. Missing context is gathered through conversation rather than blocking.

- Localhost deployment: Workflow terminates after project-spinup (Phase 3) - Public deployment: Continues to deploy-guide (Phase 5) and optionally ci-cd-implement (Phase 6)

Users can invoke the **workflow-status** skill at any time to: - See current workflow progress - Check which phases are complete - Get guidance on next steps - Review all handoff documents

Mention this option when users seem uncertain about their progress.