Copy one prompt into Cursor, Copilot, Kilo, or any agent with web access.
Install the Neexo skill "product-changelog" (product-changelog) in this repository.
Manifest: https://awesome.neexo.dk/api/install-manifest?ids=skills%2Fproduct-changelog
Catalog: https://awesome.neexo.dk/skills/product-changelog
Steps:
1. Fetch https://awesome.neexo.dk/api/install-manifest?ids=skills%2Fproduct-changelog and read the file list.
2. Fetch https://awesome.neexo.dk/api/skills/product-changelog/bundle and write every file to the correct project skill folder.
3. Detect IDE from this repo (.cursor → Cursor, .kilo → Kilo).
4. Preserve subdirectory structure (references/, agents/, scripts/, assets/).
5. Confirm which files you wrote.
Copilot — full plugincopilot plugin install neexo-developer@awesome-neexo
Bundle API (JSON)https://awesome.neexo.dk/api/skills/product-changelog/bundle
Overview
Use this skill when the repository maintains a fragment-first product changelog (user-visible “what's new”), not the hub website changelog under a docs site.
Paths, npm script names, and domain keys are repo-defined. Discover them from package.json, AGENTS.md, or docs before writing files.
When to write a fragment
Add or update a fragment for changes users will notice: new capabilities, visible fixes, UX changes, workflow improvements.
Skip for pure infra, CI, docs-only, tests, dependency bumps with no user-visible effect, and schema-only work unless the product surface changes.
Workflow
Inspect recent commits and the repo's changelog docs/scripts
Run the repo's catchup command if present (often changelog:catchup) — advisory, lists missing fragments
Prefer updating an existing recent fragment for the same domain/topic over duplicating
Scaffold with the repo's new-fragment script when available (often changelog:new)
Fill required fields; match the app's UI language(s)
Build generated output (often changelog:build) — never hand-edit the generated aggregate file
Run check (often changelog:check) and fix errors before commit
Stage fragments + generated file with the product code
Fragment contract (typical)
Exact schema is repo-defined. Common fields:
Field
Notes
id
Must match filename stem
date
YYYY-MM-DD (verify with node -e "console.log(new Date().toISOString().slice(0,10))")
createdAt
ISO UTC timestamp for intra-day ordering when used
domain
Key from the repo's changelog domain map (examples: auth, billing, documents, ui, infra)
type
e.g. feature, fix, improvement
Title / description
Single-locale (title, description) or bilingual parallel fields (e.g. titleEn/titleLocal, …) per repo
Optional: link a fixed GitHub feedback issue via an integer field such as fixesGithubIssue when the repo supports it (see in-app feedback cookbook).
Locale
Write user-facing copy in the language(s) the product UI uses. Use correct locale characters — never ASCII substitutes for accented letters.
Do not
Invent a changelog pipeline if the repo has none — ask before adding infrastructure
Commit generated output without rebuilding after fragment edits
Put secrets, internal customer names, or PII in fragments
Raw content
Copy into your project — e.g. .instructions.md, .agent.md, or SKILL.md
## Overview
Use this skill when the repository maintains a **fragment-first product changelog** (user-visible “what's new”), not the hub website changelog under a docs site.
Paths, npm script names, and domain keys are **repo-defined**. Discover them from `package.json`, AGENTS.md, or docs before writing files.
## When to write a fragment
Add or update a fragment for changes **users will notice**: new capabilities, visible fixes, UX changes, workflow improvements.
Skip for pure infra, CI, docs-only, tests, dependency bumps with no user-visible effect, and schema-only work unless the product surface changes.
## Workflow
1. Inspect recent commits and the repo's changelog docs/scripts
2. Run the repo's catchup command if present (often `changelog:catchup`) — advisory, lists missing fragments
3. Prefer updating an existing recent fragment for the same domain/topic over duplicating
4. Scaffold with the repo's new-fragment script when available (often `changelog:new`)
5. Fill required fields; match the app's UI language(s)
6. Build generated output (often `changelog:build`) — never hand-edit the generated aggregate file
7. Run check (often `changelog:check`) and fix errors before commit
8. Stage fragments + generated file with the product code
## Fragment contract (typical)
Exact schema is repo-defined. Common fields:
| Field | Notes |
|-------|--------|
| `id` | Must match filename stem |
| `date` | `YYYY-MM-DD` (verify with `node -e "console.log(new Date().toISOString().slice(0,10))"`) |
| `createdAt` | ISO UTC timestamp for intra-day ordering when used |
| `domain` | Key from the repo's changelog domain map (examples: `auth`, `billing`, `documents`, `ui`, `infra`) |
| `type` | e.g. `feature`, `fix`, `improvement` |
| Title / description | Single-locale (`title`, `description`) **or** bilingual parallel fields (e.g. `titleEn`/`titleLocal`, …) per repo |
Optional: link a fixed GitHub feedback issue via an integer field such as `fixesGithubIssue` when the repo supports it (see in-app feedback cookbook).
## Locale
Write user-facing copy in the language(s) the product UI uses. Use correct locale characters — never ASCII substitutes for accented letters.
## Do not
- Invent a changelog pipeline if the repo has none — ask before adding infrastructure
- Commit generated output without rebuilding after fragment edits
- Put secrets, internal customer names, or PII in fragments