Add mission-control skill: customizable always-on status dashboard

[dvelton]

What this adds

A new skill called mission-control that provides a customizable always-on status line for Copilot CLI sessions.

The idea

Copilot CLI sessions generate a lot of state that users lose track of: how many files the agent has changed, whether those changes have been tested, how long since the last git commit, whether the conversation has drifted off-task, and what model (and cost tier) is currently active. Mission Control surfaces this as a compact status line appended to every response.

How it works

On first use, the skill presents a setup menu with 19 modules across five categories:

Category	Modules
Safety & Risk	Safety Net (git state), Blast Radius (files/lines changed), Cascade Risk (dependency count), Verify Status (test coverage)
Awareness	Context Health, Drift Detector, Complexity, Branch Info
Cost & Efficiency	Cost Rate (model multiplier), Savings Jar (PRUs saved), Quota Forecast, Range
Productivity	Session Clock, Todo Progress, Momentum, Turns
Infrastructure	MCP Health, Model name, Context Window usage

Users pick individual modules or choose a preset profile (Safety First, Budget Hawk, Productivity, Full Ops, or Recommended). Configuration persists to ~/.copilot/mission-control.json across sessions.

Example status lines

Normal operation:

mission control │ git:clean 4m │ 3F/14L │ strong │ 1x │ auth-refactor │ 18m

Things getting risky:

mission control │ 6 unstaged 47m │ 11F/342L/2D │ thin │ 4x │ drifting │ 1h12m

Each module has defined normal, warning, and critical states with escalating visual indicators. The design principle is peripheral vision: you ignore it when everything is green and notice it when something turns yellow or red.

Validation

• npm run skill:validate passes (214 skills valid)
• npm run build regenerates README and marketplace
• Line endings normalized

[Copilot]

Pull request overview

Adds a new mission-control skill to the repository, intended to provide an always-on, configurable status line for Copilot CLI sessions and to be discoverable via the skills index.

Changes:

• Added skills/mission-control/SKILL.md describing the setup flow, module menu/presets, status line format, per-module state specs, runtime commands, and persistence format.
• Registered the new skill in docs/README.skills.md so it appears in the skills catalog.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.

File	Description
skills/mission-control/SKILL.md	New skill definition and detailed module specifications for the Mission Control status line/dashboard.
docs/README.skills.md	Adds the mission-control entry to the skills README table for discoverability.

Comments suppressed due to low confidence (1)

skills/mission-control/SKILL.md:113

• Blast Radius’s “Heavy” and “Critical” rows show the same example output (11F/342L/2D), but the spec below says /[Deleted]D should only be appended if deletions have occurred—and deletions are what make the state critical. This example makes it ambiguous whether D can appear in non-critical states. Consider updating the Heavy example to omit /2D (or clarifying the precedence rules: when deletions exist, always show Critical and include D).

| State | Display | Trigger |
|---|---|---|
| Light | `2F/8L` | Fewer than 5 files, fewer than 50 lines |
| Heavy | `11F/342L/2D` | 5+ files or 50+ lines |
| Critical | `11F/342L/2D` | Any files deleted (append D count) |

Data source: Maintain an internal count of files edited, lines changed, and files deleted during the session. Increment these counters each time you use the edit, create, or delete tools. Format: `[Files]F/[Lines]L` with `/[Deleted]D` appended only if deletions have occurred.

---

You can also share your feedback on Copilot code review. Take the survey.

[Copilot]

The section says each module has three states “normal, warning, critical”, but several modules define different/extra state labels (e.g., Blast Radius uses Light/Heavy/Critical, Verify Status uses Good/Gaps/None, Session Clock has a single informational state). This is internally inconsistent and will make it unclear how to map module states to the intended normal/warn/critical visual indicators. Consider either standardizing the state names across modules, or rewording this paragraph to describe severity levels (info/normal/warn/critical) while allowing modules to choose custom labels.

This issue also appears on line 107 of the same file.

Suggested change

	Each module has three states: normal, warning, and critical. Use the appropriate state based on the data. Warning and critical states should be visually distinct so the user notices them through peripheral vision.
	Each module reports a severity level (for example: informational, normal, warning, or critical) and may use its own display labels for those levels. Map each module’s labels onto these severity levels so you can drive consistent color and visual treatment across the status line. Warning and critical severities should be visually distinct so the user notices them through peripheral vision.

[Copilot]

Safety Net’s display/trigger is based on “unstaged changes”, but the data-source note suggests counting lines from git status --porcelain (which includes staged changes and untracked files). That would misreport the “unstaged” count and could incorrectly trigger warnings. Consider parsing the porcelain status columns to count unstaged vs staged separately (and handle untracked explicitly), and use a timestamp format (e.g., %ct) rather than parsing %cr human text to compute the minutes-since-commit thresholds reliably.

Suggested change

	Data source: Run `git status --porcelain` and `git log -1 --format=%cr` to determine state. Track the count of lines in porcelain output (each line is an unstaged or staged change). Parse the relative time from the last commit.
	Data source: Run `git status --porcelain` and parse the two status columns to count only unstaged changes (where the worktree column is not a space), treating untracked files (`??`) as unstaged. Use `git log -1 --format=%ct` to get the last-commit timestamp in epoch seconds and compute minutes since that commit from the numeric value.

[Copilot]

git rev-list --count HEAD..@{u} will fail if the current branch has no upstream configured (or in detached HEAD), which would make the Branch Info module noisy/error-prone in common cases (new branches, local-only work). Consider adding instructions to first detect whether an upstream exists (and/or catch errors) and display an “no upstream” / “detached” state instead of surfacing command failures.

Suggested change

Data source: Run `git branch --show-current` for branch name. Run `git rev-list --count HEAD..@{u}` for behind count. Use GitHub MCP tools to check for open PRs on the current branch if available.

Data source: Run `git branch --show-current` for branch name. First, check whether the current HEAD has an upstream and is not in a detached state (for example, with `git rev-parse --abbrev-ref --symbolic-full-name @{u}` and treating failures as “no upstream” / “detached”). Only if an upstream exists, run `git rev-list --count HEAD..@{u}` for the behind count; otherwise, surface a dedicated “no upstream” or “detached” state instead of the raw git error. Use GitHub MCP tools to check for open PRs on the current branch if available.

[Copilot]

Cost Rate defines a “Free” display of 0x and says models like Haiku have “no premium cost”, but the multiplier table below lists several “free” models at 0.25x. That’s a semantic mismatch: 0.25x isn’t 0x, and “no premium cost” conflicts with “multiplier”. Consider aligning the display/state definitions with the table (e.g., show 0.25x for low-cost models, or rename the state to “Low” and reserve 0x for truly zero-cost models if any exist).

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.

---

You can also share your feedback on Copilot code review. Take the survey.

[aaronpowell]

I don't quite understand the value of this over the slash commands already available in Copilot CLI.

• /session will return you a bunch of information about the current session, such as token usage, file changes, premium requests, etc.
• /diff can show you any active diff
• /usage shows the overall usage stats for copilot
• /mcp reports MCP servers and their health
• /context shows the context info

Arguably, this could be achieved using hooks because that would not be adding additional information into the context windows that can cause drift during a session.

[dvelton]

Is it possible to keep the data from those slash commands up and running as a persistent "status bar" visual? The visual part of it was the goal, but I see your point.

[aaronpowell]

No, you have to opt-in to calling them to get their information out. I wonder if it would be possible to have the skill call those slash commands rather than attempting to remember stuff along the way

[dvelton]

I'll close this PR and think through this some more