Desktop Control
Start an OpenSpec change with a strict proposal-only gate so agents do not code before specs and tasks are approved.
Overview
desktop-control is an agent skill most often used in Validate scope (also Build pm, Ship review) that scaffolds OpenSpec changes and blocks implementation until proposal artifacts pass strict validation.
Install
npx skills add https://github.com/patrickporto/desktop-agent --skill desktop-controlWhat is this skill?
- Proposal stage HARD-GATE: no code—only design documents and spec deltas
- Steps reference openspec list, project.md, and verb-led change-id scaffolding
- Requires clarifying vague details before editing files
- design.md for cross-system trade-offs before committing to specs
- 5 numbered proposal workflow steps in guardrailed OpenSpec flow
- Explicit no-code rule during proposal stage
Adoption & trust: 3.6k installs on skills.sh; 1 GitHub stars; 1/3 security scanners passed (skills.sh audits).
What problem does it solve?
You asked for a feature and the agent started coding without a written proposal, tasks, or spec deltas aligned to your OpenSpec repo.
Who is it for?
Repos already using OpenSpec where you want Claude-style agents to respect proposal-then-apply discipline on small teams of one.
Skip if: Greenfield apps with no openspec/ directory, or when you already have an approved spec and only need straight implementation.
When should I use this skill?
Starting a new OpenSpec change that needs proposal.md, tasks.md, design.md, and spec deltas with strict validation before implementation.
What do I get? / Deliverables
A new change folder exists with proposal, tasks, optional design, and mapped spec deltas—ready for human approval before any apply-stage implementation.
- openspec/changes/<change-id>/proposal.md
- tasks.md
- Optional design.md and spec delta files
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
OpenSpec proposal scaffolding belongs where you nail scope and behavior before Build—Validate is the first hard gate for structured spec-driven work. Scoping ambiguous requests into proposal.md, tasks.md, and spec deltas is classic validate/scope work, not implementation.
Where it fits
Turn a vague desktop-agent feature ask into proposal.md and tasks.md under a new verb-led change-id.
Break a multi-scope effort into distinct spec deltas with sequencing before any apply-stage coding.
Cross-check merged code against the approved OpenSpec change folder before release.
How it compares
OpenSpec proposal ritual in skill form—not a desktop automation or GUI control integration despite the slug name.
Common Questions / FAQ
Who is desktop-control for?
Solo builders and agent maintainers on OpenSpec-backed projects who need automated scaffolding that refuses to write code during the proposal stage.
When should I use desktop-control?
In Validate scope when kicking off a new change-id; in Build pm when splitting a large effort into sequenced spec deltas; in Ship review when confirming implementation matched an approved OpenSpec change.
Is desktop-control safe to install?
The skill instructs file scaffolding and OpenSpec CLI inspection—review the Security Audits panel on this Prism page and verify the parent desktop-agent repo matches your expectations given the OpenSpec-focused content.
SKILL.md
READMESKILL.md - Desktop Control
<!-- OPENSPEC:START --> **Guardrails** - Favor straightforward, minimal implementations first and add complexity only when it is requested or clearly required. - Keep changes tightly scoped to the requested outcome. - Refer to `openspec/AGENTS.md` (located inside the `openspec/` directory—run `ls openspec` or `openspec update` if you don't see it) if you need additional OpenSpec conventions or clarifications. - Identify any vague or ambiguous details and ask the necessary follow-up questions before editing files. - Do not write any code during the proposal stage. Only create design documents (proposal.md, tasks.md, design.md, and spec deltas). Implementation happens in the apply stage after approval. **Steps** 1. Review `openspec/project.md`, run `openspec list` and `openspec list --specs`, and inspect related code or docs (e.g., via `rg`/`ls`) to ground the proposal in current behaviour; note any gaps that require clarification. 2. Choose a unique verb-led `change-id` and scaffold `proposal.md`, `tasks.md`, and `design.md` (when needed) under `openspec/changes/<id>/`. 3. Map the change into concrete capabilities or requirements, breaking multi-scope efforts into distinct spec deltas with clear relationships and sequencing. 4. Capture architectural reasoning in `design.md` when the solution spans multiple systems, introduces new patterns, or demands trade-off discussion before committing to specs. 5. Draft spec deltas in `changes/<id>/specs/<capability>/spec.md` (one folder per capability) using `## ADDED|MODIFIED|REMOVED Requirements` with at least one `#### Scenario:` per requirement and cross-reference related capabilities when relevant. 6. Draft `tasks.md` as an ordered list of small, verifiable work items that deliver user-visible progress, include validation (tests, tooling), and highlight dependencies or parallelizable work. 7. Validate with `openspec validate <id> --strict` and resolve every issue before sharing the proposal. **Reference** - Use `openspec show <id> --json --deltas-only` or `openspec show <spec> --type spec` to inspect details when validation fails. - Search existing requirements with `rg -n "Requirement:|Scenario:" openspec/specs` before writing new ones. - Explore the codebase with `rg <keyword>`, `ls`, or direct file reads so proposals align with current implementation realities. <!-- OPENSPEC:END --> --- description: Implement an approved OpenSpec change and keep tasks in sync. --- <!-- OPENSPEC:START --> **Guardrails** - Favor straightforward, minimal implementations first and add complexity only when it is requested or clearly required. - Keep changes tightly scoped to the requested outcome. - Refer to `openspec/AGENTS.md` (located inside the `openspec/` directory—run `ls openspec` or `openspec update` if you don't see it) if you need additional OpenSpec conventions or clarifications. **Steps** Track these steps as TODOs and complete them one by one. 1. Read `changes/<id>/proposal.md`, `design.md` (if present), and `tasks.md` to confirm scope and acceptance criteria. 2. Work through tasks sequentially, keeping edits minimal and focused on the requested change. 3. Confirm completion before updating statuses—make sure every item in `tasks.md` is finished. 4. Update the checklist after all work is done so each task is marked `- [x]` and reflects reality. 5. Reference `openspec list` or `openspec show <item>` when additional context is required. **Reference** - Use `openspec show <id> --json --deltas-only` if you need additional context from the proposal while implementing. <!-- OPENSPEC:END --> --- description: Archive a deployed OpenSpec change and update specs. --- <!-- OPENSPEC:START --> **Guardrails** - Favor straightforward, minimal implementations first and add complexity only when it is requested or clearly required. - Keep changes tightly scoped to the requested outcome. - Refer to `openspec/AGENTS.md` (located