agentleFS
Sign inStart free
Microsoft AzureKnown publisherAzure/azure-cosmos-dotnet-v3/.github/skills/openspec-apply-change/SKILL.md

openspec-apply-change

Skill798 starsChanged 6 months agoMITView on GitHub

Implement tasks from an OpenSpec change. Use when the user wants to start implementing, continue implementation, or work through tasks.

We split this skill into the rules it gives an agent

18 rules. 13 are common, 0 are distinctive, and 5 are very specific to this project.

  • 13

    Common

    Most of the 122 edited versions we read keep these.

  • 0

    Distinctive

    This author's own choices. Worth a look.

  • 5

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Common:

    If a name is provided, use it.

    line 20
  2. Very specific:

    If ambiguous, run openspec list --json to get available changes and use the AskUserQuestion tool to let the user select

    line 23
  3. Very specific:

    Always announce: "Using change: <name>" and how to override (e.g., /opsx:apply <other>).

    line 25
  4. Very specific:

    If state: "blocked" (missing artifacts): show message, suggest using openspec-continue-change

    line 48
  5. Very specific:

    If state: "all_done": congratulate, suggest archive

    line 49
  6. Very specific:

    Read the files listed in contextFiles from the apply instructions output.

    line 54
  7. Common:

    Keep changes minimal and focused

    line 72
  8. Common:

    If all done: suggest archive

    line 87
  9. Common:

    If paused: explain why and wait for guidance

    line 88
  10. Common:

    Keep going through tasks until done or blocked

    line 142
  11. Common:

    Always read context files before starting (from the apply instructions output)

    line 143
  12. Common:

    If task is ambiguous, pause and ask before implementing

    line 144
  13. Common:

    If implementation reveals issues, pause and suggest artifact updates

    line 145
  14. Common:

    Keep code changes minimal and scoped to each task

    line 146
  15. Common:

    Update task checkbox immediately after completing each task

    line 147
  16. Common:

    Use contextFiles from CLI output, don't assume specific file names

    line 149
  17. Common:

    Can be invoked anytime: Before all artifacts are done (if tasks exist), after partial implementation, interleaved with other actions

    line 155
  18. Common:

    Allows artifact updates: If implementation reveals design issues, suggest updating artifacts - not phase-locked, work fluidly

    line 156

“Common” is measured: kept by at least 6 in 10 of the 122 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Implement tasks from an OpenSpec change.

Input: Optionally specify a change name. If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.

Steps

  1. Select the change

    If a name is provided, use it. Otherwise:

    • Infer from conversation context if the user mentioned a change
    • Auto-select if only one active change exists
    • If ambiguous, run openspec list --json to get available changes and use the AskUserQuestion tool to let the user select

    Always announce: "Using change: <name>" and how to override (e.g., /opsx:apply <other>).

  2. Check status to understand the schema
    openspec status --change "<name>" --json
    Parse the JSON to understand:
    • schemaName: The workflow being used (e.g., "spec-driven")
    • Which artifact contains the tasks (typically "tasks" for spec-driven, check status for others)

  3. Get apply instructions

    openspec instructions apply --change "<name>" --json

    This returns:

    • Context file paths (varies by schema - could be proposal/specs/design/tasks or spec/tests/implementation/docs)
    • Progress (total, complete, remaining)
    • Task list with status
    • Dynamic instruction based on current state

    Handle states:

    • If state: "blocked" (missing artifacts): show message, suggest using openspec-continue-change
    • If state: "all_done": congratulate, suggest archive
    • Otherwise: proceed to implementation

  4. Read context files

    Read the files listed in contextFiles from the apply instructions output. The files depend on the schema being used:

    • spec-driven: proposal, specs, design, tasks
    • Other schemas: follow the contextFiles from CLI output

  5. Show current progress

    Display:

    • Schema being used
    • Progress: "N/M tasks complete"
    • Remaining tasks overview
    • Dynamic instruction from CLI

  6. Implement tasks (loop until done or blocked)

    For each pending task:

    • Show which task is being worked on
    • Make the code changes required
    • Keep changes minimal and focused
    • Mark task complete in the tasks file: - [ ] → - [x]
    • Continue to next task

    Pause if:

    • Task is unclear → ask for clarification
    • Implementation reveals a design issue → suggest updating artifacts
    • Error or blocker encountered → report and wait for guidance
    • User interrupts

  7. On completion or pause, show status

    Display:

    • Tasks completed this session
    • Overall progress: "N/M tasks complete"
    • If all done: suggest archive
    • If paused: explain why and wait for guidance

Output During Implementation

## Implementing: <change-name> (schema: <schema-name>)

Working on task 3/7: <task description>
[...implementation happening...]
✓ Task complete

Working on task 4/7: <task description>
[...implementation happening...]
✓ Task complete

Output On Completion

## Implementation Complete

**Change:** <change-name>
**Schema:** <schema-name>
**Progress:** 7/7 tasks complete ✓

### Completed This Session
- [x] Task 1
- [x] Task 2
...

All tasks complete! Ready to archive this change.

Output On Pause (Issue Encountered)

## Implementation Paused

**Change:** <change-name>
**Schema:** <schema-name>
**Progress:** 4/7 tasks complete

### Issue Encountered
<description of the issue>

**Options:**
1. <option 1>
2. <option 2>
3. Other approach

What would you like to do?

Guardrails

  • Keep going through tasks until done or blocked
  • Always read context files before starting (from the apply instructions output)
  • If task is ambiguous, pause and ask before implementing
  • If implementation reveals issues, pause and suggest artifact updates
  • Keep code changes minimal and scoped to each task
  • Update task checkbox immediately after completing each task
  • Pause on errors, blockers, or unclear requirements - don't guess
  • Use contextFiles from CLI output, don't assume specific file names

Fluid Workflow Integration

This skill supports the "actions on a change" model:

  • Can be invoked anytime: Before all artifacts are done (if tasks exist), after partial implementation, interleaved with other actions
  • Allows artifact updates: If implementation reveals design issues, suggest updating artifacts - not phase-locked, work fluidly

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

Reviews can't be read right now.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free