# Create Manifest

Create a Trellis migration manifest and matching docs-site changelogs for a target...

- Repository: https://github.com/mindfold-ai/Trellis (15078 stars)
- Category: Engineering
- License: AGPL-3.0
- Last updated: 2026-09-29
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add mindfold-ai/Trellis --skill create-manifest -g -a claude-code -y`
Codex: `npx skills add mindfold-ai/Trellis --skill create-manifest -g -a codex -y`
Cursor: `npx skills add mindfold-ai/Trellis --skill create-manifest -g -a cursor -y`
Gemini CLI: `npx skills add mindfold-ai/Trellis --skill create-manifest -g -a gemini-cli -y`

## Description

Create a Trellis migration manifest and matching docs-site changelogs for a target release by analyzing commits since the previous release. Use when preparing a patch, beta, rc, or minor release manifest.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# Create Migration Manifest

Create a migration manifest for a new patch, beta, rc, or minor release based on commits since the previous release.

## Arguments

- `$ARGUMENTS` - Target version, for example `0.5.15` or `0.6.0-beta.14`. If omitted, ask the user.

## Package release model

Trellis currently publishes two npm packages from the same git tag:

- `@mindfoldhq/trellis`
- `@mindfoldhq/trellis-core`

Both packages must always share the exact same version and npm dist-tag. Source uses `workspace:*`; the packed CLI must depend on the exact published core version.

Official npm publishing is CI-only. Never use local `npm publish` or `pnpm publish` to compensate for a failed or partial release. Local verification may use `pnpm pack`, `release-preflight`, tests, lint, typecheck, and `npm view`.

## Step 1: Identify Last Release

```bash
git tag --sort=-v:refname | head -5
```

Pick the most recent release tag on the current release line, for example `v0.5.14` or `v0.6.0-beta.13`.

## Step 2: Gather Changes

```bash
git log <last-release-tag>..HEAD --oneline
git log <last-release-tag>..HEAD --oneline -- packages/cli/src/ packages/core/src/
git log <last-release-tag>..HEAD --oneline -- packages/cli/scripts/ .github/workflows/ package.json packages/*/package.json pnpm-lock.yaml
```

User-facing changelog coverage should focus on source behavior under `packages/cli/src/` and `packages/core/src/`. Release wiring, workflow, or package dependency changes belong in `Internal` only when users can observe the behavior, for example install/update reliability or multi-package availability.

## Step 3: Analyze Each Relevant Commit

For each commit that touches relevant source or release behavior:

The rest: https://github.com/mindfold-ai/Trellis/blob/HEAD/.codex/skills/create-manifest/SKILL.md