build(agent-skills): migrate skills to apm (#99)

Co-authored-by: Codex <noreply@openai.com>

Author: aoirint

.agents/skills/changelog-workflow/README.md

@@ -0,0 +1,11 @@
+# changelog-workflow
+
+## Overview
+
+Maintain canonical developer changelogs and release history.
+
+## Install
+
+```shell
+apm install aoirint/skills/.apm/skills/changelog-workflow
+```

.agents/skills/changelog-workflow/SKILL.md

@@ -1,133 +1,60 @@
----
-name: changelog-workflow
-description: >-
-  Create and update a canonical developer changelog. Use when adding
-  developer-facing release history, maintaining Keep a Changelog sections, or
-  preparing canonical version entries.
----
-
-# Changelog Workflow
-
-## When to Use
-
-- Use this skill when updating the canonical developer changelog.
-- Use this skill when preparing canonical versioned release history before a
-  release.
-- Use this skill when preserving developer-facing prerelease, compatibility,
-  migration, CI/build/package, or implementation context.
-
-## Goals
-
-- Keep the confirmed canonical changelog, often `CHANGELOG.md`, as the
-  Keep a Changelog-style release history.
-- Record notable changes for maintainers in a human-readable, newest-first
-  format.
-- Preserve prerelease and internal context in the canonical changelog even when
-  it will not appear in user-facing release notes.
-- Preserve enough rationale and history for user-facing release notes to explain
-  why each user-visible change matters.
-- Keep user-facing release-note rewriting and release-readiness checks in the
-  dedicated release-note workflow.
-
-Reference:
-
-- Keep a Changelog 1.1.0: http://keepachangelog.com/en/1.1.0/
-
-## Workflow
-
-1. Update the canonical changelog first when a release-history change is
-   needed. If the file is not clearly `CHANGELOG.md`, locate or confirm the
-   canonical changelog before editing.
-2. Keep `Unreleased` at the top.
-3. Move `Unreleased` entries into a versioned section only when the maintainer
-   has selected the release version and UTC release date.
-   - Do not create placeholder version headings with `TBD`,
-     `<maintainer-selected date>`, or similar unfinished release metadata.
-     Keep draft material under `Unreleased` until the version and date are
-     known.
-4. Use Keep a Changelog categories when applicable: `Added`, `Changed`,
-   `Deprecated`, `Removed`, `Fixed`, and `Security`.
-   - Put supplemental release metadata that is not itself a change type, such as
-     compatibility notes and test environments, under `Notes` instead of making
-     separate top-level change-category headings.
-   - Put `Notes` after all change-category sections within each release entry.
-5. Keep versioned sections newest first, with headings such as
-   `## v1.2.3 - 2026-05-03 UTC`.
-6. Record developer-facing details that help future maintainers, including:
-   - Internal migrations or architecture changes.
-   - CI, build, packaging, or dependency context.
-   - Security-sensitive or supply-chain-sensitive context from `security-check`, such as
-     maintainer-approved exceptions, residual risk, or blockers that matter for future releases.
-   - Prerelease entries and why they matter.
-   - User-impact rationale or history for each user-visible change, such as
-     the problem it solves, why behavior changed, compatibility constraints, or
-     migration reason.
-   - A sourced user impact statement may be enough when it explains why users
-     should care. Generic bullets such as documentation updates, dependency
-     updates, crash fixes, or save-format changes still need source material
-     describing the user-facing benefit, risk, security impact, compatibility
-     impact, or migration reason.
-   - Compatibility notes, test environments, known limitations, yanked
-     releases, and migration constraints.
-   - Record compatibility, support, environment, and migration claims only when
-     they are maintainer-confirmed or clearly sourced. Otherwise list them as
-     missing inputs or draft source material needing confirmation, not as final
-     compatibility facts.
-   - When compatibility notes cover several platform, runtime, dependency, or
-     companion-product versions, preserve confidence differences instead of
-     flattening them into one generic compatibility statement. For example,
-     distinguish confirmed compatibility, "appears to work" best-effort
-     compatibility, lower-confidence limited checks, and known issues.
-   - Keep related compatibility claims grouped by relationship. Put companion
-     tools, required plugins, or paired dependencies under the product/version
-     they were tested with when that relationship matters, instead of listing
-     them as another peer product version.
-   - When historical entries are backfilled with metadata such as
-     compatibility information, state that the metadata was backfilled, when it
-     was backfilled, and whether it is reference information rather than an
-     original release claim.
-   - For yanked releases, explicitly say when historical metadata was not
-     backfilled because the release was yanked, if nearby releases did receive
-     backfilled metadata.
-7. When prerelease entries are later superseded, keep enough canonical history
-   to explain what changed and what reached the stable release. If the stable
-   release is still only planned, leave the stable roll-up material under
-   `Unreleased` instead of creating an unfinished stable heading.
-   - Attach withdrawn or superseded notes to the specific entry they affect,
-     rather than only adding a broad later correction. Name the later version
-     or release timing that withdrew or superseded the earlier wording.
-   - Avoid shorthand prerelease references such as `alpha.1` or `beta.2` when
-     the base version matters. Use the full prerelease version, such as
-     `v1.2.0-alpha.1`, in durable changelog text.
-   - Split long bullets into concise parent items with indented subitems when a
-     change contains several facts, reasons, affected versions, or follow-up
-     notes.
-   - Use `document-quality-check` when splitting or rewording changelog prose.
-     Preserve changelog-specific nuance such as compatibility confidence,
-     dependency relationships, and whether a statement is original, backfilled,
-     inferred, superseded, or withdrawn.
-8. If the user asks for user-facing release notes, verify or prepare only the
-   canonical source material here, then use the appropriate release-note
-   workflow for the user-facing rewrite and release-readiness checks.
-   - Update the canonical changelog only when the source material is missing,
-     stale, or needs maintainer-facing correction.
-   - Treat missing rationale or history for a user-visible change as missing
-     canonical source material; add or request it before user-facing rewriting.
-   - If the canonical changelog already contains enough source material, stop
-     there and hand off user-facing rewriting and readiness checks.
-   - Identify the release-note workflow by name when it exists; otherwise
-     discover the relevant release-note guidance before producing user-facing
-     notes.
-   - If confirmed version, UTC release date, target audience, publication
-     channel, or release-note workflow are missing, state those as input gaps
-     and stop after canonical source preparation.
-
-## Boundaries
-
-- This skill owns the canonical developer changelog; it does not own generated
-  or user-facing release-note files.
-- Do not publish, tag, create releases, upload artifacts, or edit release
-  metadata unless another workflow and explicit user request call for those
-  side effects.
-- Keep private workspace paths, temporary worktree names, command transcripts,
-  and authentication details out of public changelog text.
+---
+name: changelog-workflow
+description:
+  Maintain a canonical developer changelog and versioned release history. Use when adding or correcting Keep a Changelog
+  entries, prerelease history, compatibility context, or release-source material; not for user-facing release notes or
+  publishing.
+---
+
+# Changelog Workflow
+
+Maintain the repository's canonical developer changelog, usually `CHANGELOG.md`. Keep it human-readable, newest first,
+and distinct from user-facing release notes.
+
+## Update a release entry
+
+1. Locate the canonical changelog and confirm its role before editing.
+2. Keep `Unreleased` first. Move entries to a versioned section only after the maintainer confirms the stable version
+   and UTC release date; never add placeholder release headings. At that promotion, move every remaining final,
+   release-ready bullet into the new versioned section and leave `Unreleased` empty. Do not duplicate promoted bullets
+   or retain implementation history that does not describe the final release state.
+3. Use Keep a Changelog categories where applicable: `Added`, `Changed`, `Deprecated`, `Removed`, `Fixed`, and
+   `Security`. Put supplemental compatibility, test, limitation, or migration context under `Notes`, after change
+   categories.
+4. Use newest-first headings such as `## v1.2.3 - 2026-05-03 UTC`.
+5. Record durable maintainer context: migrations, architecture, CI/build/package changes, prerelease history, security
+   exceptions or residual risk, compatibility confidence, limitations, and the reason a user-visible change matters.
+6. Source compatibility, support, environment, and migration claims. Mark unsourced claims as missing input or draft
+   material; distinguish confirmed, best-effort, limited-check, and known-issue evidence. Group paired tools and
+   dependencies with the product/version they qualify.
+   When compatibility appears in multiple artifacts or peer repositories,
+   inspect same-role entries before choosing wording. Preserve their hierarchy,
+   dates, and reference links, but keep each destination in its established
+   role: a README may show a target and test environment, while a changelog
+   `Notes` entry records the compatibility fact. Do not copy test environments
+   or evidence-status prose into a user-facing changelog unless it changes the
+   release's user-facing compatibility meaning. Do not infer that an incomplete
+   runtime result belongs in a package changelog or README merely because it is
+   recorded in developer evidence; add it only when the same-role convention or
+   maintainer selects it.
+7. Preserve historical accuracy. Mark backfilled metadata as backfilled, retain meaningful prerelease history, and use
+   complete prerelease versions when they matter. Treat `Unreleased` as the prospective final release state: remove
+   proposals, implementation iterations, and settings-category moves that were withdrawn or superseded within the same
+   pull request. Record only the final user- or maintainer-visible change, such as the settings that exist after the
+   change. Retain a withdrawn or superseded note only when a published artifact or a prior versioned entry makes that
+   history durable.
+8. Describe public package metadata from actual publication-channel history, not local or GitHub-only artifacts. Treat a
+   newly public compatibility label as `Changed`; use `Fixed` only for a correction already exposed publicly.
+9. Put a compatibility fact under `Notes` as `Compatibility: <product and
+   version>` when that is the repository or peer-family convention. Do not add
+   a `Changed` bullet that merely says compatibility documentation was
+   "clarified"; record the final compatibility state instead. For backfilled
+   historical entries, retain the backfill status and the historical hierarchy.
+10. Write concise factual bullets. Avoid issue or PR identifiers unless the maintainer needs the durable link. Use
+   `prose-quality-check` for prose changes that risk losing confidence, relationship, or historical-status nuance.
+
+## Handoff and boundaries
+
+Prepare or correct canonical source material before user-facing release notes. If source material is complete, hand off
+to `release-note-workflow`; if version, UTC date, target channel, or needed rationale is missing, report the gap. Do not
+publish, tag, create releases, upload artifacts, or expose private paths, transcripts, or credentials.

.agents/skills/changelog-workflow/agents/openai.yaml

@@ -1,6 +1,6 @@
-interface:
-  display_name: "Changelog Workflow"
-  short_description: "Update a canonical developer changelog."
-  default_prompt: >-
-    Update the canonical Keep a Changelog-style release history, preserving
-    developer-facing version, prerelease, compatibility, and maintainer context.
+interface:
+  display_name: "Changelog Workflow"
+  short_description: "Update a canonical developer changelog."
+  default_prompt: >-
+    Use $changelog-workflow to update the canonical Keep a Changelog-style
+    release history with developer-facing version and compatibility context.

.agents/skills/code-quality-check/README.md

@@ -0,0 +1,11 @@
+# code-quality-check
+
+## Overview
+
+Review implementation changes for readability, maintainability, and verification.
+
+## Install
+
+```shell
+apm install aoirint/skills/.apm/skills/code-quality-check
+```