feat(install): one-command install and update with staleness checks

Open
  • Is something wrong?
#410 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
30/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Stale
Tech stack
csharp, powershell
Domain
developer-experience, tooling

Research direction

Start by reading build.ps1, scripts/install-claude-desktop.ps1, and scripts/package-chat-skill.ps1, then check the dependency issue nevridge/taskflow-assistant#11 and the transfer issue nevridge/taskflow-assistant#38. The issue says this work is complete after the monorepo move in nevridge/TaskFlow#397; verify the new layout and transferred scope before considering any implementation.

Written by the indexing model from the issue text.

Description

enhancement

Status 2026-11-06: the monorepo move is done (#398), and the dependency nevridge/taskflow-assistant#11 shipped (PR nevridge/taskflow-assistant#23). This issue is no longer blocked by #400 and is first in #420, because it changes how the assistant is run every day. Redesigned the same day: the plugin and the MCP server run from a runtime folder outside the repo, not from the clone.

Background

Before the move, the assistant repo was a standalone clone, and the plugin and Claude Desktop ran from that same folder. It is now assistant/ inside nevridge/TaskFlow, whose working tree changes branch daily. Running the assistant in place means:

  • the skills, agent and chat references you use every day follow whatever branch is checked out;
  • an unfinished assistant change runs as your live tool;
  • build.ps1 refuses to run while a server is using plugin/bin, and the server is always running;
  • the daily tool runs from a code repo, not from an install location.

The #398 work worked around this with a dedicated worktree (C:\code\TaskFlow-live, detached at origin/main). That is a stopgap: another repo-shaped folder to keep current by hand.

Keeping a local environment current after a pull also takes several manual steps across four pieces, and only one of them is scripted:

Piece Today Gap
MCP server (plugin/bin) Manual ./build.ps1 Easy to forget after a pull; unsafe while a server runs (see nevridge/taskflow-assistant#11)
Plugin skills and agents Loaded in place from the local marketplace path; /reload-plugins Follow the checked-out branch
Claude Desktop MCP registration scripts/install-claude-desktop.ps1, run once Holds an absolute path to the DLL; no check that it still points at the right place
Chat skill scripts/package-chat-skill.ps1, then a manual upload of the zip No way to tell whether chat/ changed since the last upload

Both Claude Code (plugin) and Claude Desktop (Chat) are used daily, so both paths need to stay current. A GitHub install is not an option today: plugin/bin is gitignored, so a copy installed from GitHub has no server.

Problem

Forgetting to rebuild or re-upload after a pull is a silent failure: the plugin skills update, but the server or the Chat skill lags behind, so tool behavior and instructions drift apart. And the live tool is tied to the state of a code checkout.

Proposed approach (ungroomed)

  1. An install step that stages everything into a runtime folder outside the repo, by default %LOCALAPPDATA%\TaskFlowAssistant\ (overridable):
    • the built server (TaskFlow.Mcp.dll and its files);
    • a copy of the plugin (skills, agent, .mcp.json, plugin.json) with a marketplace.json that points at it;
    • the packaged Chat skill zip;
    • a build-info.json stamp (source commit or hash).
  2. Claude Code adds the marketplace from the staged folder, and Claude Desktop's config points at the staged DLL. The repo can then be on any branch or in any state. Updating is re-running the script.
  3. A single update.ps1 entry point that:
    • stops if a server is running from the runtime folder (the check from nevridge/taskflow-assistant#11, now against the install folder);
    • builds and stages;
    • re-packages the Chat skill only when chat/ changed;
    • prints the manual steps still needed for this run (/reload-plugins, restart Claude Desktop, upload the zip).
  4. The same script does the first-time install, idempotent on re-run: marketplace add, plugin install, Claude Desktop registration. It also covers the one-time move off a marketplace registered from a repo path (the marketplace name stays taskflow-assistant, so the old one is removed first).
  5. Staleness: update.ps1 -Check reports, without changing anything, whether the staged build is older than src/, whether the Chat zip is older than chat/, and whether Desktop's config points at the runtime folder. build.ps1 exits early when the stamp already matches the source.
  6. The plugin's api_url is lost when the plugin is reinstalled (it resets to the default). The script should keep it or re-apply it (claude plugin configure ... --values-stdin), and install-claude-desktop.ps1 -ApiUrl must stay a parameter.

Out of scope

  • CI-published binaries or a GitHub release install.
  • Automating the Chat skill upload (not possible; the script only reports when it is needed).
  • Killing running processes automatically.

Open questions

  • Overwrite the runtime folder in place, or keep one folder per version for an easy rollback? (Earlier this issue ruled out side-by-side versioned folders; that is open again.)
  • Does Claude Code re-read a staged plugin folder on /reload-plugins the way it did for the worktree? (The reload output named the folder; confirm when building this.)
  • Should update.ps1 run git pull itself, or leave that to the user?
  • Does update.ps1 replace build.ps1, or wrap it? Dev builds in the repo (dotnet test, plugin/bin for local runs) still need to work.
  • Is the default location %LOCALAPPDATA%\TaskFlowAssistant right, and should -InstallDir be remembered?
  • Should the optional post-merge hook warning be included, given hooks are not versioned?
  • Is the plugin.json version bump still needed to refresh an installed copy?

Dependencies

None open. nevridge/taskflow-assistant#11 and the move (#398) are done. Build with the merged pipeline (#400) if it has landed; it does not block this.

Dominant language
C#
Stars
1
Forks
0
Avg merge
2h 2m
Merged PRs (30d)
98

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from nevridge/TaskFlow

All issues in nevridge/TaskFlow

Similar issues

More C# issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.