Question 1

How is this different from a dotfiles repo?

Accepted Answer

A dotfiles repo versions your config files, but it doesn't know what's installed, whether it still works together, or how to fix it when it doesn't. DevForgeKit does the dotfiles part too (with backup-before-overwrite, never silent), but adds a compatibility-aware package registry, a repair engine with rollback, an environment graph, and a TUI dashboard to see all of it. It's a dotfiles repo that also knows what it did.

Question 2

Why not just use Ansible or chezmoi?

Accepted Answer

Ansible and chezmoi are strong choices, especially for teams managing many machines or complex templating across dotfiles. DevForgeKit is scoped narrower and deeper: one developer's own workstation, with a registry that understands package compatibility, diagnostics and repair without writing a playbook, project scaffolding, and an interactive dashboard, with no YAML to author. That focus is the trade-off: it's not a general configuration-management tool, and isn't trying to be.

Question 3

How do I install DevForgeKit?

Accepted Answer

npm install -g devforgekit or brew install nouradinabdurahman/devforgekit/devforgekit, then run devforgekit install. On a first-ever run in a real terminal, an interactive wizard walks you through Minimal, Recommended, Full, or Custom (pick your own categories), then previews exactly what will install: package counts, VS Code/Cursor extensions, services, and a real download-size total, before anything runs. The installer is idempotent, safe to run more than once. Prefer to build from source instead (for contributing, or to run without installing a package)? Clone the repository, make the entry scripts executable, and run ./devforgekit install the same way.

Question 4

Will bootstrap overwrite my .zshrc?

Accepted Answer

Not silently. Every config file is copied with a safety wrapper that backs up the existing file as .backup- before overwriting, and skips files that are already identical.

Question 5

Is there a lighter install?

Accepted Answer

Yes. devforgekit install --profile minimal installs bare-essentials CLI tooling, and --profile recommended adds everyday tooling (Docker, VS Code extensions) without Flutter, Android Studio, or databases. Profiles for flutter and backend install stack-specific subsets, and --dry-run validates everything with no side effects. Run the installer with no flags in a real terminal for a wizard that walks through these choices interactively. (Building from source instead? Use ./devforgekit install with the same flags.)

Question 6

What happens if a package fails to install?

Accepted Answer

The installer continues past it rather than aborting. Homebrew itself stops at the first broken package, so DevForgeKit retries the rest one at a time. Every package's outcome is recorded, and the next devforgekit install run offers to resume against just what failed. devforgekit repair install re-checks and retries failed packages, the global command symlink, and the CLI's own dependencies on demand.

Question 7

How do I uninstall DevForgeKit?

Accepted Answer

devforgekit uninstall, in a real terminal with no flags, shows a checklist (installed packages, VS Code/Cursor extensions, configuration, services) and always previews before removing anything. Use --all, --packages, --config, --vscode, --cursor, or --services for a specific subset non-interactively (add --force outside a real terminal; it never runs unattended without it). Configuration files are backed up as .backup- before removal, never deleted outright.

Question 8

Why doesn't the npm command exist on my machine?

Accepted Answer

npm ships with Node.js, so if npm isn't found, Node.js likely isn't installed (or isn't on your PATH yet). Install the current LTS release from nodejs.org, then open a new terminal window; npm install -g devforgekit will work immediately after.

Question 9

Why doesn't the brew command exist on my machine?

Accepted Answer

Homebrew has to be installed once per Mac; it doesn't come preinstalled with macOS. Install it from brew.sh, then open a new terminal window so its install location is on your PATH. DevForgeKit's bootstrap can also provision Homebrew automatically on a factory-fresh Mac.

Question 10

Do I need Node.js forever, even after DevForgeKit is installed?

Accepted Answer

No. Node.js is only the delivery mechanism for the npm install method. Once DevForgeKit is installed, the devforgekit command runs on its own; you don't need Node.js to use any DevForgeKit feature, and you're free to uninstall Node.js afterward (though you'd need it again to update DevForgeKit via npm).

Question 11

Can I update DevForgeKit?

Accepted Answer

Yes. npm update -g devforgekit or brew upgrade nouradinabdurahman/devforgekit/devforgekit, depending on how you installed it. Building from source, git pull and re-run ./devforgekit install, or use devforgekit self-update.

Question 12

Can I use multiple profiles?

Accepted Answer

Yes. Re-run devforgekit install --profile <name> any time to layer another profile's packages on top of what's already installed; nothing already present is reinstalled or removed. Profiles are minimal, recommended, full, flutter, and backend, or Custom category selection from the interactive wizard.

Question 13

Can I reinstall tools if something breaks?

Accepted Answer

Yes. devforgekit repair install retries just the packages, symlink, or CLI dependencies that failed or went missing, without touching anything that's already working. For a broader reset, devforgekit install --profile <name> again is idempotent and safe to run repeatedly.

Question 14

Why doesn't the devforgekit command work after installing?

Accepted Answer

Almost always PATH. PATH is the list of folders your terminal searches for commands; npm and Homebrew add their install location to it automatically, but your already-open terminal window won't see the change until you close it and open a new one. If it still doesn't work after restarting your terminal, run devforgekit doctor --fix (or devforgekit repair install if the command itself is missing).

Question 15

Does DevForgeKit work on Linux and Windows?

Accepted Answer

Linux: yes - npm install -g devforgekit or Homebrew both work natively, and the CLI supports Linux package managers (apt, dnf, pacman) with runtime detection. Certified on real Ubuntu and Debian; Fedora and Arch use the same code paths but aren't yet certified on real hardware. Windows: not natively supported - npm install -g devforgekit fails with EBADPLATFORM on stock Windows (cmd.exe/PowerShell), because the devforgekit command is a bash script and needs a POSIX shell. Install and run it from inside WSL instead - a supported installation path with real fixed bugs, though full certification on real Windows/WSL2 hardware is still pending; once running there, Windows package managers (winget, choco, scoop) are supported for installing individual tools. Native Windows support with no WSL required is planned for v3.1 - see the Roadmap.

Question 16

Does it work on Intel Macs?

Accepted Answer

Expected to work - architecture detection adjusts the Homebrew prefix automatically for Apple Silicon (/opt/homebrew) versus Intel (/usr/local) - but not yet certified on real Intel Mac hardware (none available to this project yet). Certified on Apple Silicon.

Question 17

Does the AI Assistant work without an API key?

Accepted Answer

Yes, safely. Every AI command degrades to a clear, actionable message rather than crashing. Configure any of the 7 providers when you're ready; local providers like Ollama and LM Studio need no key at all.

Question 18

What does the AI Assistant send to providers?

Accepted Answer

Prompts include aggregated environment context: installed components, compatibility score, active workspace, and git status. Chat contents live in memory only and are discarded when a session ends; the local event log records what happened, never conversation contents.

Question 19

How are registry packages validated?

Accepted Answer

Every manifest is validated against a JSON Schema and cross-checked for referential integrity: every dependency, conflict, and collection member must resolve to a real package. A 13-check quality score covers metadata, documentation, reliability, discoverability, compatibility, and platform support.

Question 20

Are plugins sandboxed?

Accepted Answer

Plugins run with a timeout execution limit, and third-party plugins are Ed25519-signed with explicit trust management (your own key is auto-trusted; others require devforgekit plugin trust). The timeout is an execution limit, not a security boundary, so install plugins you trust.

Question 21

Can I use the CLI without the TUI?

Accepted Answer

Yes. Any argument skips the dashboard: devforgekit doctor runs straight in the terminal. You can also set DEVFORGEKIT_NO_TUI=1 to disable the dashboard entirely.

Question 22

What do generated projects include?

Accepted Answer

Tests, CI workflow, Docker where it fits the stack, editor config, a real working example, and your choice of license (MIT, Apache-2.0, GPL-3.0, or none). Official scaffolding CLIs are used where they exist.

Question 23

How fast is the CLI?

Accepted Answer

Registry loaders are cached in memory with O(1) package lookup and a pre-built search index. v2.2.2 cut typical response times roughly in half (registry stats: 0.40s to 0.19s). The TUI startup animation doubles as a cache warm-up.

Frequently asked questions

General

Installation

Cross-Platform

AI Assistant

Registry

Plugins

Project Generator

Performance

Still stuck?