Keep AI Agent Skills Updated

Use Dependabot to keep versioned AI agent skills up to date.

Introduction

30 Second Summary

The guidance your coding assistant follows can quietly fall behind as newer versions become available. Checking every skill for updates by hand makes that guidance easy to neglect.

In this project, you will create a public GitHub repository that treats an agent skill as a versioned dependency. You'll use Dependabot support for Agent Package Manager to automate the update through a pull request.

What You'll Build

You'll open your repository to find a Dependabot pull request that updates your agent skill while keeping its manifest and lockfile in sync.

By the end of this project, you'll have:

A public repository with a versioned skill manifest in apm.yml and an exact dependency record in apm.lock.yaml.
A Dependabot update setup in .github/dependabot.yml that you can confirm from the repository's Insights area.
An automated update pull request that you can inspect for manifest changes and lockfile changes before merging.
Secret Mission: An optional challenge to push your dependency automation skills further.

Are there any prerequisites?

You need a GitHub account. You also need an agent skill hosted in a Git repository with more than one tagged version.

Before We Start

Your Dependabot workflow depends on three connections working together. GitHub hosts the repository. Git moves changes between your computer and GitHub.

The Agent Package Manager creates the lockfile that Dependabot updates. In this step, you'll prepare each tool without creating the project repository.

In this step, get ready to:

Confirm that your GitHub account can create public repositories.
Install Git plus GitHub CLI with local authentication.
Install the APM CLI for managing agent skills.

Confirm your GitHub access

Dependabot runs inside a GitHub repository. Your account needs access to the repository creation form with public visibility available.

GitHub handles your credentials on its own website. You never need to paste your password into this project.

✔️ I can sign in

Visit the GitHub sign-in page in your web browser.
Sign in with the GitHub account you want to use for this project.

You should land on GitHub while signed in to your account.

ⓧ I need an account

Visit the GitHub sign-up page in your web browser.
Create your account by following the registration prompts.
Verify your email address when GitHub sends the verification message.
Sign in to your new account after verification.

You should land on GitHub while signed in to your new account.

Open the new repository form to confirm your repository permissions.

You should see your account in the Owner field. You should also see Public as an available visibility option.

Leave the form without selecting Create repository.

Public visibility unavailable?

Confirm that the Owner field shows your personal account. An organization owner can restrict repository creation or visibility inside an organization.

Use a personal GitHub account that permits public repositories for this project.

Help me check why public repository creation is unavailable.

Set up Git and local authentication

Git tracks the files that eventually become your manifest and lockfile. GitHub CLI connects those local Git operations to your GitHub account through browser authentication.

Press Cmd+Space (macOS) or the Windows key (Windows) to open your search bar.
Type Terminal (macOS) or PowerShell (Windows).
Press Enter to open the terminal.
Check whether Git is installed by running:

git --version

What does this check do?

The command asks Git to print its installed version. A version line confirms that the git command is available in your terminal.

✔️ I see a Git version

Git is ready. Continue to the GitHub CLI check below.

ⓧ Command not found

Git needs to be installed before APM can retrieve git-hosted agent skills.

macOS

Start the Xcode Command Line Tools installer by running:

xcode-select --install

What does this command do?

This asks macOS to install the command-line developer tools that include Git. macOS opens an installation dialog for you to complete.

Complete the macOS installation dialog.
Close the terminal window after installation finishes.
Use your search bar to open a new Terminal window.
Verify Git by running:

git --version

What confirms the installation?

A Git version line confirms that the new terminal can find the installed command.

Windows

Install Git through WinGet by running:

winget install --id Git.Git -e --source winget

What does this command do?

WinGet installs the Git package from its configured package source. Windows may ask you to approve the installation.

Approve the installation if Windows requests permission.
Close the PowerShell window after installation finishes.
Use your search bar to open a new PowerShell window.
Verify Git by running:

git --version

What confirms the installation?

A Git version line confirms that the new PowerShell window can find the installed command.

Git still unavailable?

Close every terminal window after the installation. A fresh terminal reloads the command paths on your computer.

Help me get Git working in my terminal.

Check whether GitHub CLI is installed by running:

gh --version

What does this check do?

The command asks GitHub CLI to print its version. A version line confirms that the gh command is available.

✔️ I see a GitHub CLI version

GitHub CLI is ready. Continue to authentication below.

ⓧ Command not found

GitHub CLI provides the browser sign-in flow that also configures local Git authentication.

macOS

The release assets list can feel crowded. The universal macOS installer is the package designed to work across current Mac processors.

Visit the latest GitHub CLI release in your browser.
Download the universal macOS installer from the release assets.
Run the downloaded installer.
Complete the installation prompts.
Close the Terminal window after installation finishes.
Use your search bar to open a new Terminal window.
Verify GitHub CLI by running:

gh --version

What confirms the installation?

A GitHub CLI version line confirms that the new terminal can find the gh command.

Windows

Install GitHub CLI through WinGet by running:

winget install --id GitHub.cli --source winget

What does this command do?

WinGet installs GitHub CLI from the Windows package source. The installer updates your command path for future terminal windows.

Close the entire PowerShell window after installation finishes.
Use your search bar to open a new PowerShell window.
Verify GitHub CLI by running:

gh --version

What confirms the installation?

A GitHub CLI version line confirms that the new PowerShell window can find the gh command.

What prompts will I see?

Choose GitHub.com as the account host.
Choose HTTPS as the Git protocol.
Confirm that GitHub CLI may authenticate Git with your GitHub credentials.
Complete the authorization flow in your browser.

Start local GitHub authentication by running:

gh auth login

What does this command do?

GitHub CLI opens an interactive sign-in flow. Choosing HTTPS allows Git operations such as pushes and pulls to use the stored GitHub credentials.

Confirm your local authentication by running:

gh auth status

What confirms authentication?

The status output identifies the active GitHub account for GitHub.com. It also confirms that GitHub CLI has a valid authentication session.

That connection is in place. Your terminal can now work with GitHub without asking you to paste a password into Git commands.

Authentication not completing?

Confirm that the browser authorization uses the same GitHub account you checked earlier. Restart the sign-in flow if the browser was signed in to another account.

Help me authenticate Git and GitHub CLI.

Install the APM CLI

The APM CLI reads apm.yml and resolves its agent dependencies. It records the resolved dependency tree in apm.lock.yaml so future installs can reproduce the same versions.

Check whether APM is already installed by running:

apm --version

What does this check do?

The command asks APM to print its installed version. A version line confirms that the apm command is available.

✔️ I see an APM version

APM is ready. Continue to the final setup check below.

ⓧ Command not found

The standalone installer adds APM without requiring a separate Python installation.

macOS

Install APM with its standalone installer by running:

curl -sSL https://aka.ms/apm-unix | sh

What does this command do?

The command downloads the official Unix installer and runs it for your user account. The installer configures future terminal sessions to find APM when it can update your shell profile safely.

Linux users can follow these same instructions in their terminal.

Close the terminal window after installation finishes.
Use your search bar to open a new Terminal window.
Verify APM by running:

apm --version

What confirms the installation?

An APM version line confirms that the new terminal can find the installed command.

Windows

Install APM with its standalone PowerShell installer by running:

irm https://aka.ms/apm-windows | iex

What does this command do?

PowerShell downloads the official Windows installer and runs it for your account. The installer adds APM to the command path used by future terminal windows.

Close the entire PowerShell window after installation finishes.
Use your search bar to open a new PowerShell window.
Verify APM by running:

apm --version

What confirms the installation?

An APM version line confirms that the new PowerShell window can find the installed command.

APM still unavailable?

Open a completely new terminal window after installation. The current window may still be using the old command path.

Follow any shell-specific path command printed by the installer if it reports that your profile could not be updated.

Help me get APM working in my terminal.

Before you run the final check, do you expect all three commands to confirm a working setup?

Verify Git, GitHub authentication, and APM by running these checks:

git --version
gh auth status
apm --version

What do these checks prove?

The first check confirms that Git is installed locally.
The second check confirms that GitHub CLI is authenticated to your account.
The third check confirms that APM is available for the lockfile workflow.

You should see version information for Git and APM. You should also see your active GitHub account in the authentication status.

Your GitHub account and local tools are ready. Next up, you'll create the public repository that gives your agent skills a versioned home.

Create Your Skills Repository

Agent instructions need a reliable home before automated updates can protect them. A public GitHub repository gives every manifest change a visible history.

An Agent Package Manager (APM) manifest turns agent skills into versioned dependencies. Dependabot can later compare those declared versions with newer Git tags.

In this step, you'll create a public repository for those dependencies. Its first commit will contain apm.yml with one intentionally old skill pin.

In this step, get ready to:

Create a public GitHub repository for your agent skills.
Declare a git-hosted agent skill at an intentionally older version.
Commit the APM manifest to the repository's default branch.

Create the public repository

A public repository exposes every committed file to anyone on the internet. This project only stores dependency configuration with no credentials.

In GitHub, select the create menu in the upper-right corner.
Click New repository.
Select your personal account from the Owner menu.
Enter agent-skills in the Repository name field.
Enter Versioned agent skills managed with Dependabot in the Description field.
Select Public under repository visibility.
Leave Add a README file turned off.
Click Create repository.

Good progress. Your public repository is ready for its first tracked file.

Leaving the repository empty makes apm.yml part of the initial commit.

Can't create the repository?

Check that the Repository name field contains agent-skills with no spaces. Confirm that your selected owner allows you to create public repositories.

If that name already belongs to one of your repositories, delete the unused repository before retrying this project.

Help me troubleshoot why GitHub will not create my public repository.

Add the pinned APM manifest

The apm.yml manifest uses YAML to describe your agent dependencies. A pinned Git tag gives Dependabot a specific version to compare against future releases.

Click Add file above the empty repository.
Click Create new file.
Enter apm.yml in the file name field.
Populate apm.yml by pasting this manifest into the file editor:

# Name this repository's APM workspace.
name: agent-skills
version: "1.0.0"

dependencies:
  apm:
    # Track one git-hosted Android skill.
    - git: android/skills
      path: devtools/android-cli
      ref: v1.0.0 # Temporary old pin for the Dependabot update demo.

What does this manifest do?

The name field identifies this APM workspace as agent-skills.
The version field records the workspace manifest version as 1.0.0.
The dependencies.apm section holds the agent packages managed by APM.
The git field points to the public android/skills repository.
The path field selects the devtools/android-cli skill.
The ref field pins that skill to the older v1.0.0 tag.

Click Preview to review the rendered file.
Click Commit changes.
Enter Add APM manifest in the Commit message field.
Click Commit changes in the commit dialog.

GitHub now shows the committed apm.yml file on the repository's default branch.

That's the foundation in place. Your agent skill now has a versioned declaration that Dependabot can inspect.

Don't see apm.yml?

Check that the file name is exactly apm.yml. Confirm that you completed the commit dialog after entering the commit message.

If the manifest preview reports invalid formatting, compare the indentation beneath dependencies with the complete file below.

Help me fix my APM manifest or GitHub commit.

✔️ Awesome, I've got everything!

Great. Confirm that apm.yml is saved in your public agent-skills repository.

ⓧ I'd like to double check the full code

# Name this repository's APM workspace.
name: agent-skills
version: "1.0.0"

dependencies:
  apm:
    # Track one git-hosted Android skill.
    - git: android/skills
      path: devtools/android-cli
      ref: v1.0.0 # Temporary old pin for the Dependabot update demo.

Verify the first commit

Before you check, do you expect the repository to be public? Which file should the initial commit contain?

Click the repository name at the top of the page to return to its main view.
Check the visibility badge beside the repository name.
Select apm.yml from the file list.

The visibility badge shows Public. Your first commit is now stored on GitHub's remote default branch.

The manifest lists android/skills as its Git source. It selects devtools/android-cli at v1.0.0.

Your versioned skills repository is live with an intentionally old dependency. Next, you'll generate its lockfile so the exact resolved skill can be reproduced.

Generate the Skill Lockfile

Your public GitHub repository now has an apm.yml manifest that requests an intentionally older skill version. The next job is to resolve that request into a reproducible baseline.

The Agent Package Manager creates a lockfile that records the exact dependency it resolved. Committing this file gives future updates a fixed starting point.

In this step, get ready to:

Confirm that APM is available locally.
Generate apm.lock.yaml from apm.yml.
Commit the lockfile to your public repository.

Check APM locally

APM reads the dependency declaration in apm.yml. Its command-line tool resolves that declaration into a lockfile.

Switch back to the terminal in your local repository from the previous step.
Check whether APM is available by running this command:

apm --version

What does this command do?

This command asks APM for its installed version. A version number confirms that your terminal can find the tool.

✔️ I see a version number

APM is ready. Keep using this repository terminal for the next substep.

ⓧ Command not found

APM needs to be installed before it can resolve your manifest. Use a separate terminal for the installation so your repository terminal stays open.

macOS

Press Cmd+Space to open Spotlight.
Type Terminal into Spotlight.
Press Enter to start a separate terminal.
Install APM with its standalone installer by running this command:

curl -sSL https://aka.ms/apm-unix | sh

What does this command do?

This downloads the official Unix installer. The installer adds APM to your user environment.

Windows

Press the Windows key to open search.
Type PowerShell into search.
Press Enter to start a separate PowerShell window.
Install APM with its standalone installer by running this command:

irm https://aka.ms/apm-windows | iex

What does this command do?

This downloads the official Windows installer through PowerShell. The installer adds APM to your user environment.

Linux

Open your application launcher.
Search for Terminal.
Select Terminal to start a separate terminal.
Install APM with its standalone installer by running this command:

curl -sSL https://aka.ms/apm-unix | sh

What does this command do?

This downloads the official Unix installer. The installer adds APM to your user environment.

Close the installation terminal after the command finishes.
Start a fresh terminal session with the same application search you just used.
Verify the installation by running this command:

apm --version

What should I see?

You should see an APM version number. This confirms that the fresh terminal loaded the updated command path.

The installation is complete. APM is ready to resolve your skill dependency.

Return to the local repository directory from the previous step in this fresh terminal.

Still unable to run APM?

Make sure you started a fresh terminal after the installer completed. Shell configuration changes often load when a new session starts.

Follow any PATH instruction printed by the installer before checking the version again.

Help me finish installing APM.

Generate the lockfile

Your manifest holds the older version you requested. APM can now resolve that request into the exact Git-hosted dependency recorded by apm.lock.yaml.

Generate the lockfile from the existing manifest by running this command:

apm lock

What does this command do?

The command resolves every dependency declared in apm.yml.
It writes the resolved dependency graph to apm.lock.yaml.
It leaves files in your agent targets unchanged.

You should see the command finish after resolving the Git-hosted skill. Your local repository now contains apm.lock.yaml beside apm.yml.

Confirm that apm.lock.yaml appears in the local repository file list.

Lockfile missing?

Check that you ran the command inside the local repository containing apm.yml.

Confirm that the dependency in apm.yml still points to a valid Git-hosted skill version.

Help me generate the lockfile.

Commit and verify the lockfile

The generated lockfile currently exists only on your computer. Git needs to record it before GitHub can use it as the repository baseline.

Stage the manifest plus the generated lockfile by running this command:

git add apm.yml apm.lock.yaml

What does this command do?

This places the manifest plus the lockfile in Git's staging area. The next commit records the requested dependency beside its resolved state.

Commit the staged lockfile by running this command:

git commit -m "Add APM dependencies"

What does this command do?

This creates a local repository snapshot from the staged files. The snapshot gives the resolved skill dependency a permanent place in the repository history.

You should see a commit summary that includes the new apm.lock.yaml file.

Commit did not include the lockfile?

Check that apm.lock.yaml sits beside apm.yml in the same local repository.

Run the staging command again after confirming the file location.

Help me commit the lockfile.

Before you push, which generated file do you expect to appear in your public repository?

Publish the new commit to the tracked GitHub branch by running this command:

git push

What does this command do?

This sends your local commit to the remote branch that the repository already tracks. GitHub can now read both APM files from the default branch.

You should see the push complete without a rejected update. The remote repository now has your lockfile commit.

Push did not complete?

Complete any GitHub authentication request shown by your terminal before trying the push again.

Confirm that you are using the same local repository that you pushed in the previous step.

Help me push the lockfile commit.

Return to the public GitHub repository page from the previous step.
Refresh the repository page.
Confirm that the file list contains apm.yml.
Confirm that the file list contains apm.lock.yaml.
Select apm.lock.yaml from the repository file list.

You should see the resolved Git-hosted skill with the same older version declared by your manifest. That match proves the lockfile captured your intended baseline.

You have the reproducible baseline in place. Your public repository now carries both the dependency request and its exact resolution.

Do not see the lockfile on GitHub?

Return to your terminal to confirm that the commit and push both completed. A local file remains off GitHub until its commit reaches the remote repository.

Refresh the repository page after the push finishes. Your browser may still be showing the earlier file list.

Help me find the pushed lockfile.

Your older skill version is now pinned in a committed lockfile. Next, you will configure Dependabot to watch this APM dependency for updates.

Configure Dependabot for APM

Your committed Agent Package Manager (APM) manifest now declares the skill version your repository uses. The generated lockfile preserves the exact resolved version.

Dependabot needs a configuration file before it can monitor that dependency. You will connect the manifest to GitHub's update system with a daily schedule.

In this step, get ready to:

Create an APM update configuration for Dependabot.
Commit the configuration to the repository's default branch.
Confirm that Dependabot appears in the repository's Insights area.

Create the Dependabot configuration

GitHub reads Dependabot settings from .github/dependabot.yml on the default branch. The configuration names the package ecosystem containing your manifest.

Return to the public skills repository on GitHub from earlier.
Select Add file above the repository file list.
Select Create new file.
Enter .github/dependabot.yml in the file name field.
Add the APM settings by pasting this code into the file editor:

# Use Dependabot configuration syntax version 2.
version: 2

updates:
  # Monitor the APM manifest in the repository root.
  - package-ecosystem: "apm"
    directory: "/"
    # Check for version updates every weekday.
    schedule:
      interval: "daily"

What does this configuration do?

The version: 2 setting selects the current Dependabot configuration syntax.
The package-ecosystem: "apm" setting tells Dependabot to monitor Agent Package Manager dependencies.
The directory: "/" setting points to the repository root containing apm.yml.
The interval: "daily" setting schedules an update check every weekday.

This entry enables Dependabot version updates for supported git dependencies. It does not enable security updates.

Select Preview above the file editor.
Confirm that the preview contains the apm ecosystem.
Click Commit changes.
Enter Configure Dependabot for APM in the Commit message field.
Choose the option that commits to the current default branch.
Click Commit changes to record the file.

Good progress. You'll return to the repository with .github/dependabot.yml committed alongside your existing APM files.

File missing from the repository?

Check that the file path is exactly .github/dependabot.yml.
Confirm that the commit was added to the repository's default branch.
Return to the repository file list to confirm that the .github directory is present.

Help me check my Dependabot configuration.

✔️ Awesome, I've got everything!

Great. Your repository now contains the configuration that tells Dependabot where to find the APM manifest.

ⓧ I'd like to double check the full code

# Use Dependabot configuration syntax version 2.
version: 2

updates:
  # Monitor the APM manifest in the repository root.
  - package-ecosystem: "apm"
    directory: "/"
    # Check for version updates every weekday.
    schedule:
      interval: "daily"

Confirm Dependabot is monitoring APM

The dependency graph includes a Dependabot view for configured version updates. This view confirms that GitHub has recognized your new configuration.

Before you check, which package ecosystem do you expect GitHub to list?

Click Insights under the repository name.
Click Dependency graph in the left sidebar.
Click Dependabot under the Dependency graph section.

You should see an APM entry among the package managers configured for version updates. This confirms that GitHub found apm.yml through your Dependabot configuration.

APM missing from Dependabot?

Confirm that .github/dependabot.yml exists on the default branch.
Check that package-ecosystem uses the value apm.
Check that directory uses / because apm.yml is in the repository root.

Help me find the missing APM entry.

That's the monitoring connection in place. Dependabot now recognizes your APM manifest as a source for version updates.

Dependabot now knows where your skill dependency lives. Next up, you'll ask it to check for a newer version.

Trigger a Dependency Update Check

Your GitHub repository now gives Dependabot everything it needs to monitor the Agent Package Manager manifest.

The daily schedule runs on its own. This step starts a check now so you can watch that automation produce a pull request.

In this step, get ready to:

Start a Dependabot version update check.
Wait for the APM update job to finish.
Confirm that Dependabot opens a pull request for the newer skill version.

Run the version update check

Dependabot normally follows the schedule in .github/dependabot.yml. A manual check lets you test the same update process immediately.

Return to the repository's Insights area from earlier.
Select Dependency graph in the left sidebar.
Select Dependabot under Dependency graph.
Find the row for apm.yml.
Click Recent update jobs beside apm.yml.

Before you trigger the check, predict whether Dependabot will find a newer tag for the pinned skill.

Click Check for updates beside apm.yml.

You'll see an update job start for the apm package ecosystem. Dependabot compares the pinned git dependency with the available tagged versions.

Stay on the update jobs page until the current run finishes.

The completed check shows that Dependabot found the available newer version. It can now prepare the dependency update.

Update check failed?

Open the job log for the failed run.
Confirm that the configured directory contains apm.yml.
Confirm that apm.yml declares a supported git dependency.
Correct the first configuration or dependency error shown in the log.

Help me understand my Dependabot update job failure.

Find the new pull request

When Dependabot finds an outdated supported git dependency, it opens a pull request with the proposed version update. This gives you one review point before the newer skill reaches your default branch.

Before you check the pull requests, predict whether the manual run found the newer tag.

Return to the repository's main page.
Click the Pull requests tab under the repository name.
Select the open pull request authored by Dependabot for your agent skill.

You'll see an open pull request that proposes moving the skill from the older pinned version to an available newer version. That's the automation loop working: a stale agent skill has become a reviewable update.

Why does the lockfile change too?

Dependabot updates the supported git dependency declared in apm.yml. Since apm.lock.yaml is present, Dependabot regenerates the lockfile in the same pull request.

This is a version update. It does not report a security update.

Pull request missing?

Confirm that apm.yml still pins the intentionally older tagged version.
Confirm that the skill's source repository has an available newer tagged version.
Return to Recent update jobs to inspect the latest run.

Help me find why Dependabot did not open a pull request.

Dependabot has turned your older skill pin into an open update proposal. Next, you'll inspect the version change and regenerated lockfile before merging the pull request.

Review and Merge the Update

Dependabot has found a newer version of your agent skill. Its GitHub pull request puts the proposed update in one reviewable place.

Your review checks that the Agent Package Manager manifest requests the newer version. You will also confirm the regenerated lockfile resolves that same version before the change reaches the default branch.

In this step, get ready to:

Review the version change in apm.yml.
Compare the regenerated resolved version in apm.lock.yaml.
Merge the update into the default branch.

Review the manifest change

A diff separates removed content from added content. For this review, the manifest diff shows the exact version change that Dependabot proposes.

Select Files changed at the top of the pull request.
Choose apm.yml in the file tree.
Inspect the removed dependency version.
Inspect the added dependency version.
Confirm the temporary old-version note remains unchanged.

What should the manifest diff prove?

The dependency in apm.yml changes from the older pinned version to the available newer version.
The temporary old-version note remains in the file for the wrap-up task.

Check the regenerated lockfile

The lockfile records the version APM resolved for the dependency. Matching versions across both files keeps future installations reproducible.

Choose apm.lock.yaml in the file tree.
Inspect the removed resolved version.
Inspect the added resolved version.
Confirm the added resolved version matches the newer version in apm.yml.

Why Review Both Files?

The apm.yml manifest declares the requested dependency version. The apm.lock.yaml lockfile records the version that APM resolved.

Agreement between those files confirms the pull request updates the dependency as one consistent unit.

Merge and verify the update

Merging applies the reviewed changes to the repository's default branch. This completes the update that Dependabot proposed.

Select the Conversation tab.
Scroll to the bottom of the pull request.
Click Merge pull request.
Keep the default commit message if GitHub prompts you.
Click Confirm merge.

GitHub should mark the pull request as merged. The proposed dependency update is now part of the repository.

Can't Merge the Pull Request?

Check the merge section for an unmet review requirement.
Check the merge section for an incomplete status check.
Use the merge dropdown menu to select Create a merge commit when Merge pull request is not shown.

Help me understand why this Dependabot pull request cannot be merged.

Before you check the default branch, which version do you expect both dependency files to show?

Return to the repository's file list.
Confirm the branch selector shows the repository's default branch.
Open apm.yml.
Confirm the skill dependency uses the newer version from the pull request.
Confirm the temporary old-version note remains in the manifest.
Return to the repository's file list.
Open apm.lock.yaml.
Confirm the resolved version matches the newer version in apm.yml.

That's the update loop complete. Your default branch now uses the newer agent skill version while the merged pull request preserves the review history.

Secret mission

Set a Weekly Agent Skill Update Routine

Turn your successful update test into a sustainable maintenance routine. You will remove the temporary old-version note from the APM manifest. You will also schedule future Dependabot checks to run weekly.

Clean Up Your Resources

Your public skills repository has no ongoing project cost on GitHub. Decide whether to keep it available, leave it untouched for later, or delete it entirely.

Resources you used:

Public GitHub repository serving as the maintained home for your agent skills.

Keep everything running

No action is needed. Choose this option if the repository remains your home for agent skills.

Leave .github/dependabot.yml in place.
Let Dependabot continue its weekly version checks.
Review future agent-skill update pull requests before merging them.

Pause - I'll come back to this later

No local process or cloud compute is running for this project. Leaving the repository unchanged preserves everything for your return.

Leave apm.yml at the newer merged skill version.
Keep apm.lock.yaml with the resolved newer version.
Return to the repository when a weekly Dependabot pull request needs review.

Delete - I don't want to use this again

Deleting the repository permanently removes its files. Your GitHub account stays intact.

Return to the public skills repository from earlier.
Open the repository settings area from its navigation.
Open the general repository settings.
Scroll to the repository deletion controls at the bottom of the page.
Choose the permanent repository deletion option.
Enter the full repository name shown in the confirmation prompt.
Confirm the deletion.
Return to your GitHub repository list.

You should no longer see the public skills repository in your repository list. That completes the repository cleanup.

Nice Work!

You did it. You turned a public GitHub repository into a maintained home for versioned agent skills. Dependabot now keeps your Agent Package Manager dependencies current through reviewable pull requests.

You've learned how to:

Declared a git-hosted agent skill as a versioned dependency in apm.yml.
Generated an APM lockfile that records the resolved skill version in apm.lock.yaml.
Configured Dependabot version updates for APM. You reviewed the manifest change in its pull request. You also confirmed the regenerated lockfile before merging.
Secret Mission: Removed the temporary old-version note. You also changed the APM update schedule to weekly for a manageable maintenance routine.

Ready to quiz yourself?