# Description

CONTRIBUTING.md lists "Update CHANGELOG.md" as step 4 of the Pull
Request Process, but no CHANGELOG.md file exists in the repository. The
project uses `release-note` blocks in PR descriptions instead.

This PR replaces the outdated CHANGELOG.md reference with guidance to
include a `release-note` block in the PR description, which matches the
actual project workflow.

Fixes #203

# Change Type

/kind cleanup

# Changelog

```release-note
NONE
```

# Additional Notes

None

# Description

Extracts linting from build.yml into a dedicated lint.yml workflow. The
previous setup unnecessarily ran a full Next.js production build before
linting. Now we have parallel lint-go and lint-ui jobs, with a new
lint-ui Makefile target that only installs dependencies.

/kind cleanup

```release-note
NONE
```

…actor (#208)

# Description

After PR #185 (commit fb54b9f), which removed `/admin/v0` endpoints from
the backend, the UI was not updated and continues trying to call the
now-deleted endpoints. This causes all admin UI pages to fail with 404
errors.

**What changed:**
- Updated `ui/lib/admin-api.ts` to use `/v0/*` endpoints instead of
`/admin/v0/*`, matching the current backend API structure
- Changed all 26 occurrences of `/admin/v0` to `/v0`
- Updated comment to reflect correct API path

**Testing:**
- ✅ Verified UI can successfully fetch servers, agents, skills, and
deployments
- ✅ Confirmed all admin UI pages load without 404 errors
- ✅ Tested against local registry server

Fixes the admin UI broken since PR #185.

# Change Type

/kind fix

# Changelog

```release-note
fix(ui): Update API client to use /v0 endpoints after backend refactor removed /admin/v0 routes
```

# Additional Notes

This is a critical bug fix - the admin UI has been completely
non-functional since the backend refactor in PR #185. All API calls were
returning 404 errors because the UI was calling endpoints that no longer
exist.

# Description

Admin endpoints are no longer used. Remove it for
the /servers delete handler.

# Change Type

```
/kind bug_fix
```

# Changelog

```release-note
NONE
```

# Additional Notes

Fixes #210

Signed-off-by: Shashank Ram <[email protected]>

# Description

Hot fixes for authn integration

## Changes

- Added path skipping to certain paths to prevent API AuthN middleware
checks on them (e.g. /ping).
- Created new `ErrCLINoStoredToken` error, to avoid CLI AuthN checks
blocking commands when not logged into registry (e.g. init).
- Added callback for token management
- e.g. this goes through authn and has access token, then this token can
easily be configured in the extension side (if needed) using the
callback. good for cases where extension needs the token without having
to re-authn on its end
- Updated CLIAuthn to be factory-based
- Rename `push` to `publish` to keep verbiage in sync.

**metadata**
```
/kind cleanup
```
```release-note
NONE
```

---------

Signed-off-by: Fabian Gonzalez <[email protected]>

# Description

`arctl skill publish` produces invalid Docker image references with
duplicated
tags (e.g., `docker.io/user/my-project:latest:latest`).

**Root cause:** In `buildSkillDockerImage`, `BuildRegistryImageName` was
called
with the output of `BuildLocalImageName` (which already includes a
version tag)
instead of the raw name. Since `BuildRegistryImageName` internally calls
`BuildLocalImageName`, the tag was applied twice.

**Fix:** Pass `fm.Name` directly to `BuildRegistryImageName`, matching
the
existing pattern in `GetImageNameFromManifest` (common.go:58).

Fixes #178

# Change Type

/kind fix

# Changelog

```release-note
Fix Docker image tag duplication (`:latest:latest`) in `arctl skill publish`
```

# Additional Notes

- Added 2 test cases to `TestBuildRegistryImageName` covering registry
URLs with path components
- Added `TestBuildRegistryImageName_NoDoubleTag` regression test
asserting no double-tag patterns
- Removed unused `repoName` variable

# Description

Add complementary unit tests for CLI command tree structure, flag
registration, required flag validation, hidden command detection,
and argument count validators.

Test coverage includes:
- `TestCommandTree` - verifies all 8 top-level commands and subcommand
counts
- `TestCommandsHaveRequiredMetadata` - walks entire tree checking
Use/Short fields
- `TestHiddenCommands` - verifies import/export are hidden
- `TestAgentInitFlags` - 6 flags with correct defaults
- `TestSkillPublishFlags` - 5 flags with defaults + required flag check
- `TestRequiredFlags` - 4 commands with required flags validated
- `TestRootPersistentFlags` - registry-url and registry-token
- `TestArgsValidators` - 16 cases testing ExactArgs/ArbitraryArgs
enforcement

Uses `slices.Sort` instead of forbidden `sort` package.

Fixes #77

# Change Type

/kind feature

# Changelog

```release-note
Add CLI command registration and flag unit tests
```

# Additional Notes

- Complementary to PR #137 (stalled on lint failure from `sort` package
usage)
- Uses `slices.Sort` to comply with `depguard` linter rule
- Single new file: `pkg/cli/commands_test.go` (346 lines, 39+ subtests)

# Description

Moving vector db helpers to a public package so extensions can reuse it.

# Change Type

```
/kind fix
```

# Changelog

```release-note
Move internal vector db helper methods to public package.
```

Signed-off-by: Fabian Gonzalez <[email protected]>

…lp output (#200)

# Description

The `agent init` command accepts `[framework] [language]` positional
args but never documented which values are valid — users had no way to
discover supported options without hitting a validation error or reading
source code.

**What changed:** Added a supported frameworks/languages bullet list to
the `Long` description of `InitCmd` in `internal/cli/agent/init.go`.

# Change Type

/kind cleanup

# Changelog

```release-note
NONE
```

# Additional Notes

Currently only `adk` (python) is supported. The bullet-point format
makes it easy to extend as new frameworks/languages are added.

<!-- START COPILOT ORIGINAL PROMPT -->



<details>

<summary>Original prompt</summary>

> 
> ----
> 
> *This section details on the original issue you should resolve*
> 
> <issue_title>agent init help output should indicate which
frameworks/languages are supported</issue_title>
> <issue_description>The agent init command has a [framework] positional
arg, and mentions adk throughout the example output, but doesn't
explicitly list if there are other frameworks that are supported outside
of adk. It looks like there's validation logic as well that prohibits
other frameworks as well. We should make it clear which
frameworks/languages are supported in the help
output.</issue_description>
> 
> ## Comments on the Issue (you are @copilot in this section)
> 
> <comments>
> </comments>
> 


</details>



<!-- START COPILOT CODING AGENT SUFFIX -->

- Fixes #197

<!-- START COPILOT CODING AGENT TIPS -->
---

✨ Let Copilot coding agent [set things up for
you](https://github.com/agentregistry-dev/agentregistry/issues/new?title=✨+Set+up+Copilot+instructions&body=Configure%20instructions%20for%20this%20repository%20as%20documented%20in%20%5BBest%20practices%20for%20Copilot%20coding%20agent%20in%20your%20repository%5D%28https://gh.io/copilot-coding-agent-tips%29%2E%0A%0A%3COnboard%20this%20repo%3E&assignees=copilot)
— coding agent works faster and does higher quality work when set up for
your repo.

---------

Co-authored-by: copilot-swe-agent[bot] <[email protected]>
Co-authored-by: timflannagan <[email protected]>

# Description

Follow-up to #198 that added support for adding metadata to the
agent.yaml. This commit adds runtime skill resolution and
materialization for `agent run` workflows. When skills have been
configured for an agent, we resolve those [ image, registryURL ] input
sources to images, and then leverage docker create/cp/etc. to fetch
those contents and extract directly to disk.

We leverage existing kagent-adk functionality here where it supports
reading skills from an envvar so I only had to extend the docker compose
template to mount that directory correctly.

# Change Type

/kind feature

# Changelog

```release-note
NONE
```

---------

Signed-off-by: timflannagan <[email protected]>

<!--
Thanks for opening a PR! Please delete any sections that don't apply.
-->

# Description

<!--
A concise explanation of the change. You may include:
- **Motivation:** why this change is needed
- **What changed:** key implementation details
- **Related issues:** e.g., `Fixes #123`
-->

The deployments API had mixed identity models (name/version vs ID),
outdated update semantics, and duplicated client/server code paths. This
refactor aligns deployments on a single provider-based, ID-first model
and removes legacy flows.


# Change Type

<!--
Select one or more of the following by including the corresponding
slash-command:
```
/kind breaking_change
/kind bump
/kind cleanup
/kind design
/kind deprecation
/kind documentation
/kind feature
/kind fix
/kind flake
/kind install
```
-->

/kind breaking_change
/kind cleanup
/kind design

# Changelog

<!--
Provide the exact line to appear in release notes for the chosen
changelog type.

If no, just write "NONE" in the release-note block below.
If yes, a release note is required:
-->

```release-note
refactor deployment apis to provider+id-based model
```

# Description

- Fix 409 Conflict error when redeploying an agent or MCP server whose
  runtime resources were removed externally but whose database record
  was not cleaned up
- Add `cleanupExistingDeployment` helper that removes stale DB records
  and attempts Kubernetes resource cleanup (non-fatal) before retrying
  the deployment insert
- Remove stray `fmt.Println` debug statement from `DeployServer`

# Change Type

```
/kind fix
```

# Changelog

```release-note
NONE
```

# Additional Notes

## Root cause
The `deployments` table uses `PRIMARY KEY (server_name, version)`. When
runtime resources (e.g. Kubernetes pods) are deleted externally—via
`kubectl`, namespace cleanup, or failed reconciliation—the corresponding
database record is not removed. Subsequent deploy attempts hit the
unique constraint, returning a 409 Conflict even though no actual
instance exists.

The error path is:
`CreateDeployment` INSERT → PG error 23505 → `ErrAlreadyExists` →
`huma.Error409Conflict`

`ReconcileAll` cannot fix this because it runs *after* the INSERT
succeeds—it never gets a chance to execute when the INSERT itself fails.

## Fix
In `DeployServer` and `DeployAgent`, when `CreateDeployment` returns
`ErrAlreadyExists`:
1. Look up the existing deployment record
2. Attempt Kubernetes resource cleanup (non-fatal, since resources may
   already be gone)
3. Remove the stale DB record
4. Retry `CreateDeployment`
5. Proceed with `ReconcileAll` to create fresh runtime resources

---------

Signed-off-by: Peter Jausovec <[email protected]>

# Description

Adding e2e CLI tests for local and kubernetes targets and fixing a
couple of issues - we were setting the Cmd in docker compose to "" when
OCI image was used (we shouldn't have been doing that); also, making
sure any errors are captured when docker compose fails.

# Change Type
```
/kind feature
/kind fix
```

# Changelog

<!--
Provide the exact line to appear in release notes for the chosen
changelog type.

If no, just write "NONE" in the release-note block below.
If yes, a release note is required:
-->

```release-note
fix: resolve OCI runtime failures for MCP servers deployed without a runtime hint
fix: capture docker compose stderr in error messages for local deployment failures
tests: add CLI e2e tests
```

---------

Signed-off-by: Peter Jausovec <[email protected]>

<!--
Thanks for opening a PR! Please delete any sections that don't apply.
-->

# Description

- finish rename config -> env
- call deployment adapters from within registry service
- add extraroutes

<!--
A concise explanation of the change. You may include:
- **Motivation:** why this change is needed
- **What changed:** key implementation details
- **Related issues:** e.g., `Fixes #123`
-->

# Change Type

<!--
Select one or more of the following by including the corresponding
slash-command:
```
/kind breaking_change
/kind bump
/kind cleanup
/kind design
/kind deprecation
/kind documentation
/kind feature
/kind fix
/kind flake
/kind install
```
-->

# Changelog
/kind cleanup
/kind design

<!--
Provide the exact line to appear in release notes for the chosen
changelog type.

If no, just write "NONE" in the release-note block below.
If yes, a release note is required:
-->

```release-note
NONE
```

<!--
Thanks for opening a PR! Please delete any sections that don't apply.
-->

# Description

<!--
A concise explanation of the change. You may include:
- **Motivation:** why this change is needed
- **What changed:** key implementation details
- **Related issues:** e.g., `Fixes #123`
-->

Prepare for enabling an MQ for this repository. Add the requisite event
triggers to the GHA workflows.


# Change Type

<!--
Select one or more of the following by including the corresponding
slash-command:
```
/kind breaking_change
/kind bump
/kind cleanup
/kind design
/kind deprecation
/kind documentation
/kind feature
/kind fix
/kind flake
/kind install
```
-->

/kind cleanup

# Changelog

<!--
Provide the exact line to appear in release notes for the chosen
changelog type.

If no, just write "NONE" in the release-note block below.
If yes, a release note is required:
-->

```release-note
NONE
```

# Additional Notes

<!--
Any extra context or edge cases for reviewers.
-->

Signed-off-by: timflannagan <[email protected]>

# Description

Replace the manually maintained UI API client (`admin-api.ts`) with an
auto-generated TypeScript client from the backend's OpenAPI spec. This
eliminates an entire class of UI-backend mismatches.

- Rewrote `cmd/tools/gen-openapi` to produce an OpenAPI spec directly
from Huma route registrations
- Added `@hey-api/openapi-ts` to auto-generate typed SDK functions +
types from the spec
- Migrated all 13 UI files from the old `adminApiClient` class to the
generated SDK
- Added `make gen-client` target and CI verification (`make verify` now
catches stale generated files)
- Removed the "Published" tab (publishing is implicit on creation) and
renamed "Admin" to "Catalog"
- Replaced tab navigation with clickable category cards (closes #157)

whenever there's a change to the APIs in the backend, you do: 

```
make gen-client        # regenerates openapi.yaml + TypeScript client
cd ui && npx tsc --noEmit  # shows any UI code that needs updating
```

The CI will run `make verify` which will fail if the files are stale. 

# Change Type

```
/kind feature
/kind cleanup
```

# Changelog

```release-note
Auto-generate TypeScript API client from OpenAPI spec, replacing the manually maintained admin-api.ts. Run `make gen-client` after API changes.
```

Signed-off-by: Peter Jausovec <[email protected]>

# Description

Skills could only be published from local folders containing a SKILL.md
file with Docker packaging. Users needed the ability to publish skills
directly from GitHub repositories — both with and without local files —
matching the pattern already established by agent publish.

Corresponding docs changes:
agentregistry-dev/website#11

Changes:

- Added `--github` flag to skill publish as an alternative to
`--docker-url`, with mutual exclusivity enforced via Cobra
- Added `--version` flag (required for `--github`, optional override for
`--docker-url`) and `--description` flag for direct registration
- Added direct registration mode: `arctl skill publish my-skill --github
<url> --version 1.0.0` registers a skill by name without needing local
files
- `skill publish` now auto-detects whether the argument is a skill
folder (with SKILL.md) or a skill name, routing to folder mode or direct
mode accordingly
- GitHub URLs support the full tree format
(`https://github.com/owner/repo/tree/branch/path`) for specifying branch
and subdirectory

# Change Type

```
/kind feature
```

# Changelog

```release-note
Add GitHub repository support for skill publish. Skills can now be published with `--github` as an alternative to `--docker-url`. A new direct registration mode allows publishing skills by name from a GitHub repository without requiring local files: `arctl skill publish my-skill --github <url> --version 1.0.0 --description "My skill"`.
```

---------

Signed-off-by: Peter Jausovec <[email protected]>

# Description
agentregistry supports agents, skills, and MCP servers as first-class
resources, but has no way to manage reusable prompt templates (system
prompts, instructions) that agents can consume. Users currently hardcode
instructions in agent code, with no versioning, sharing, or central
management.

What changed: Adds prompts as a fourth first-class resource type across
all layers of the registry.

**Registry CRUD**

- PromptJSON model — a prompt is a named, versioned text string (name,
description, version, content)
- Database migration (004_add_prompts_table.sql) with the same schema
pattern as skills/agents
- PostgreSQL implementation for all prompt CRUD operations
- Service layer with version management, duplicate prevention, latest
tracking
- REST API endpoints: `GET/POST /v0/prompts`, `GET/DELETE
/v0/prompts/{name}/versions/{version}`
- API client methods for all operations
- Auth resource type PermissionArtifactTypePrompt


**CLI commands**

- `arctl prompt publish <file> --name <name> --version <version>` —
publish from a plain text file
- `arctl prompt list / arctl prompt show <name> / arctl prompt delete
<name> --version <version>`
- `arctl agent add-prompt <local-name> --registry-prompt-name <name>` —
adds a prompt reference to agent.yaml, defaults registryURL to the
current registry

**Agent runtime integration**

- PromptRef type in AgentManifest with registryURL, registryPromptName,
registryPromptVersion
- `arctl agent run` resolves prompt refs from the registry REST API,
writes prompts.json to the agent config directory
- `prompts_loader.py` (autogenerated, refreshed on every run) loads
prompts and exposes `build_instruction(default)` — returns registry
prompt content if available, falls back to the default
- Agent template uses `instruction=build_instruction("default
instruction here")`

**MCP server**

- Adds user-facing MCP prompts (search_registry, deploy_mcp_server,
registry_overview) that guide users through the registry's own tools —
following the MCP spec's intent for prompts as user-controlled slash
commands
- Registry prompts are NOT forwarded via the MCP prompts protocol
(they're agent-consumed data, not user-facing slash commands)


# Change Type
```
/kind feature
```

# Changelog

```release-note
Add prompts as a first-class registry resource with full CRUD support (REST API, CLI, database), agent manifest integration (`arctl agent add-prompt`), and runtime resolution during `arctl agent run`. Prompts are versioned text templates that agents use as instructions, resolved from the registry at launch time.
```

**Additional Notes**

- Existing agents scaffolded before this change need a one-line update
to `agent.py`: replace the hardcoded instruction="..." with
instruction=build_instruction("...") and add `from .prompts_loader
import build_instruction`. New agents get this automatically from the
updated template.

- The database migration (`004`) creates the `prompts` table. Existing
databases will auto-migrate on server restart.
- Prompt content is stored as a plain string in the registry's JSONB
value column. The PromptJSON model intentionally avoids MCP-specific
fields (arguments, messages) since prompts are consumed as agent
instructions, not as MCP protocol prompts.

---------

Signed-off-by: Peter Jausovec <[email protected]>
Co-authored-by: Claude Opus 4.6 (1M context) <[email protected]>