coisa · Oct 20, 2026 · Oct 20, 2026 · Oct 20, 2026 · Oct 20, 2026
@@ -0,0 +1,21 @@
+{
+    "schema": 1,
+    "owner": "fast-forward/changelog",
+    "name": "fast-forward-changelog",
+    "scope": "project",
+    "target": ".agents/skills/fast-forward-changelog",
+    "source": {
+        "package": "fast-forward/changelog",
+        "version": "v0.3.0",
+        "reference": "85474de5a16bb08f83c9f30e0ed72f331a210f07"
+    },
+    "files": {
+        "LICENSE": "58bd7c00603e499c575d53a97b8b8c1d1398f584ea5f9f77d369780efb2066ab",
+        "SKILL.md": "a71cfdffae34b69e555955b6b82be858bf65e4406f954d566b651cda0f0cd952",
+        "examples/contribution.php": "46f2b30277b4f880a8fc4f5d503d2a4fd13c6802a929159b1895f55f9a97dd2e",
+        "references/automation.md": "0cb96ff6d62f44c19f514fcbb42b88fbe5f7382bcfed87c533c8ac6fd3bc95bb",
+        "references/cli.md": "787f33efcbc72d40ce5b55507f6f0a59b686bffe4d7edfcf4242c427d7db023e",
+        "references/php-api.md": "32b67728f3c4ba5870a40f5ad88946dd274f84619676d4783642780a172cade8"
+    },
+    "payload_sha256": "f1969293e2f761bfea32eb4d3e04980cf7a8f2a48313188a20d15390751eb681"
+}
@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Felipe Sayao Lobato Abreu <github@mentordosnerds.com>
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.
@@ -0,0 +1,162 @@
+---
+name: fast-forward-changelog
+description: Adopt Fast Forward Changelog's GitHub lifecycle, write and check independent fragments, review version PRs, and perform authorized release maintenance. Discover the selected release's documentation and CLI capabilities before choosing integration details.
+license: MIT
+compatibility: Requires access to the application repository and the selected release's documentation. Verify that release's runner or PHP requirements before execution. Local CLI examples use CPX; PHP integration uses the application's Composer installation. GitHub credentials are needed only for authorized remote operations.
+metadata:
+  author: php-fast-forward
+  source: original
+  repository: https://github.com/php-fast-forward/changelog
+  api-baseline: Verify the selected published release; commands and integration details are release-specific.
+---
+
+# Fast Forward Changelog
+
+Ordinary contributions add independent `.changelog/*.md` fragments. GitHub
+automation checks each contribution, maintains PR feedback and prepares a
+reviewable version PR. That PR consolidates the accepted fragments into
+`CHANGELOG.md` and deletes only the consumed files. Publication follows a
+separate approval for the exact result; a green check or prepared PR is not that
+approval.
+
+## Select the real contract
+
+1. Read application instructions, Git status and its existing changelog setup.
+   Use its reviewed version for an ordinary task; do not upgrade it incidentally.
+   If its ref is a moving channel, resolve the current commit and corresponding
+   published full tag before selecting a local runtime. `v0` is not Composer `0`.
+2. For new adoption or a requested update, discover the latest published stable
+   release in the [official repository](https://github.com/php-fast-forward/changelog/releases).
+   Confirm the complete release tag and its commit, exclude drafts/prereleases,
+   and respect any explicitly selected maintenance line. For CPX or PHP use,
+   confirm the same version is available on
+   [Packagist](https://packagist.org/packages/fast-forward/changelog).
+3. Read that tag's README and relevant documentation, not `main` or an old copy
+   of this skill. Before adding a workflow, inspect its
+   `resources/workflows/changelog.yml`, companion README and the reusable workflow
+   they reference. Copy the release's caller, review inputs/permissions and set
+   its product references to that verified full tag or immutable release commit;
+   do not retain an obsolete embedded pin blindly. After setting the final ref,
+   inspect the reusable workflow at that exact ref and confirm its inputs,
+   permissions and runner requirements before saving the application caller.
+   If that release offers a project `install` command, inspect its help and prefer
+   its guided preview for a missing integration. Explain the release branch,
+   publication default and optional skill before accepting writes.
+   The lifecycle defaults to `publish: true`; confirm this at the selected ref.
+   Its automatic route publishes a version tag and GitHub Release
+   after the reviewed managed PR is merged; it does not merge the PR. A
+   validation-only trial must choose `publish: false` explicitly. Installation must
+   not publish anything. Preserve an existing caller, its pin and settings;
+   migration or upgrades need their own task scope.
+4. For local CLI work, set `CHANGELOG_VERSION` to the verified exact numeric
+   release, without the tag's `v`. Discover commands and inspect their arguments:
+
+   ```sh
+   cpx --skip-local "fast-forward/changelog:$CHANGELOG_VERSION" list --raw
+   cpx --skip-local "fast-forward/changelog:$CHANGELOG_VERSION" help add
+   cpx --skip-local "fast-forward/changelog:$CHANGELOG_VERSION" help check
+   ```
+
+   Use [CPX's official setup](https://github.com/laravel/cpx) when installation is
+   authorized; do not pin the executor in these commands. `--skip-local` selects
+   its separate tool installation. CPX may handle `--help` or `--version` itself,
+   so use `help <command>` for changelog help. An existing reviewed project binary
+   may be used directly instead. Confirm prerequisites from the chosen release.
+
+Installing this skill installs instructions, independently of the runtime. If
+the selected CLI offers skill installation/check/update operations, inspect
+their help and use only the supported operation and requested scope. Otherwise
+follow that release's skill-installation guide; do not invent a command.
+
+Native installation can record the source package version, commit and payload
+integrity. Compare an installed copy with the selected CLI through its documented
+check operation; do not confuse that local comparison with a latest-version
+lookup. Preserve NPX or other installer ownership and its lockfile rather than
+trying to adopt the copy or rewrite metadata into a merely similar JSON format.
+
+This procedure avoids a frozen API inventory. A breaking release can still
+change the lifecycle or these entrypoints: when documentation and capabilities
+disagree, resolve the mismatch before writes rather than guessing compatibility.
+
+## Write and check a contribution
+
+Read the change and describe its observable effect. For example, create one
+unique `.changelog/preserve-markdown-spaces.md`:
+
+```markdown
+---
+category: fixed
+type: patch
+---
+
+Preserves meaningful Markdown spaces when parsing fragments.
+```
+
+Keep existing notes and Markdown intact. Use the selected release's fragment
+schema. For the established category scheme, `added`, `changed` and `deprecated`
+default to `minor`, `removed` to `major`, and `fixed`/`security` to `patch`.
+Persist the effective type explicitly; a justified override may express a
+compatible dependency change as `changed`/`patch`. Apply the application's
+versioning policy deliberately, especially during `0.x` development.
+
+After help confirms these arguments, the CLI can create and validate that note
+from the application directory instead of writing the example manually:
+
+```sh
+cpx --skip-local "fast-forward/changelog:$CHANGELOG_VERSION" add "Preserves meaningful Markdown spaces when parsing fragments." --category=fixed --no-interaction
+cpx --skip-local "fast-forward/changelog:$CHANGELOG_VERSION" check --no-interaction
+```
+
+Verify that exactly one intended fragment was created and central history stayed
+unchanged. Do not run both authoring routes for the same note. Fix diagnostics
+and rerun the check. Before a committed PR comparison, inspect `help check`,
+fetch the intended baseline under existing authority, then use its supported
+comparison option, for example:
+
+```sh
+cpx --skip-local "fast-forward/changelog:$CHANGELOG_VERSION" check --since=origin/main --no-interaction
+```
+
+That comparison requires committed contribution changes. A local uncommitted
+fragment can pass local validation without satisfying the PR comparison.
+
+Optional PR/issue/author metadata must come from verified evidence. When the
+origin PR is already known and supported, use `--pull-request=<number>` or
+`pull_request: <number>` after confirming its repository and exact head. Leave
+unknown fields absent; do not invent a number or require a second fragment
+commit after opening a PR. If the selected release resolves PR origins during
+compilation, follow its documented policy consistently across preparation and
+publication. No qualifying PR should become an invented commit or author link.
+
+Ordinary work preserves inherited fragments and published history. Do not add a
+new `Unreleased` section. Editorial replacement, history maintenance and release
+consolidation require their own task scope.
+
+## Verify the lifecycle
+
+For adoption, open a small pilot PR and inspect the exact head's required status,
+sticky comment and independent application checks. Exercise a missing or
+malformed note and any enabled bot route. Inspect the generated version PR:
+planned version/impact, exact notes, central-history changes and only the accepted
+fragment deletions. Review again after its head changes. The workflow does not
+merge its own version PR.
+
+For the selected release, verify how committed history and ancestral tags define
+the version baseline. The current lifecycle advances from the greatest stable
+version in either source: tag `v1.7.0`, committed history through `1.7.1` and a
+new patch produce `1.7.2`. Skipping publication does not block the next PR or
+authorize retroactive publication of `1.7.1`. Preserve earlier history and review
+the proposed next version; do not create missing tags as an incidental repair.
+
+Load only the reference needed for the task:
+
+- [Automation](references/automation.md): selected caller, optional settings,
+  credentials, maintenance lines and pilot verification.
+- [CLI maintenance](references/cli.md): previews, consolidation, history,
+  interrupted transactions and separately authorized publication.
+- [PHP integration](references/php-api.md): release-specific application
+  services and the bundled example, only when programmatic integration is needed.
+
+Retain authority already given, but do not infer commit, push, merge, installation
+elsewhere or publication authority from an ordinary fragment task. Report changed
+paths, executed checks and the verified version/PR/SHA relevant to the result.
@@ -0,0 +1,45 @@
+<?php
+
+declare(strict_types=1);
+
+/**
+ * Creates and validates one consumer fragment using explicit application paths.
+ *
+ * @copyright Copyright (c) 2026 Felipe Sayao Lobato Abreu <github@mentordosnerds.com>
+ * @license https://opensource.org/licenses/MIT MIT License
+ */
+
+use FastForward\Changelog\Container\ServiceProvider\ChangelogServiceProvider;
+use FastForward\Changelog\Fragment\FragmentWriterInterface;
+use FastForward\Changelog\Release\Factory\ReleaseOptionsFactoryInterface;
+use FastForward\Changelog\Validation\CheckServiceInterface;
+
+use function FastForward\Container\container;
+
+$autoload = $argv[1] ?? '';
+$directory = realpath($argv[2] ?? '');
+if ('' === $autoload || !is_file($autoload) || !isset($argv[2]) || false === $directory || !is_dir($directory)) {
+    fwrite(STDERR, "Usage: php contribution.php /consumer/vendor/autoload.php /existing/project\n");
+    exit(2);
+}
+require $autoload;
+
+$container = container(ChangelogServiceProvider::class);
+$options = $container->get(ReleaseOptionsFactoryInterface::class)->create([
+    'workingDirectory' => $directory,
+    'source' => 'tags',
+]);
+$path = $container->get(FragmentWriterInterface::class)->add(
+    $options,
+    'Preserves meaningful Markdown spaces when parsing fragments.',
+    category: 'fixed',
+    name: 'php-api-example.md',
+);
+$expected = "---\ncategory: fixed\ntype: patch\n---\n\nPreserves meaningful Markdown spaces when parsing fragments.\n";
+if ($expected !== file_get_contents($path)) {
+    throw new RuntimeException('The fragment does not match the expected application output.');
+}
+if (!$container->get(CheckServiceInterface::class)->check($options)->isValid()) {
+    throw new RuntimeException('The pending fragment inventory is invalid.');
+}
+fwrite(STDOUT, "Contribution example PASS\n");
@@ -0,0 +1,89 @@
+# GitHub lifecycle adoption
+
+Load when installing or changing workflows, configuring credentials or runners,
+selecting maintenance lines, or diagnosing feedback. Discover the latest stable
+published release for new adoption, respecting an explicitly selected release
+line. For ordinary work, retain the application's reviewed implementation.
+
+## Use the selected release's caller
+
+From the verified full tag, read `README.md`,
+`resources/workflows/changelog.yml`, its companion README, and the reusable
+workflow referenced by that caller. Consult that tag's relevant guides, including
+`docs/reusable-lifecycle.md`, `docs/github-app.md` and `docs/automation-map.md` when
+present. If paths moved, follow that release's README rather than guessing.
+Do not combine a caller from one version with settings copied from `main`.
+
+If that release lists `install`, inspect its command help and installation guide
+before choosing a route. Guided setup can ask for the release branch, publication
+choice, advanced overrides and optional project skill, then preview a missing
+caller. It must preserve an existing caller and refuse ambiguous or competing
+automation. Use read-only preview first; noninteractive application requires its
+documented confirmation option. For a new caller, select the published release
+through that command's supported release option; its installer can pin `uses`
+to the verified commit and retain the version as a readable comment. Confirm
+both identities in the preview. Preserve the selected pin of an existing caller.
+The workflow and bundled skill may have separate
+provenance: a workflow ref does not change the executing CLI's instructions.
+
+For manual setup, copy the caller into the application's `.github/workflows/`, review its events,
+inputs and effective permissions, then set its product references to the selected
+published complete tag or verified immutable release commit. Review older pins
+embedded in the copied caller. After replacing a pin, inspect the reusable
+workflow at the final selected ref and verify its actual inputs, permissions and
+runner requirements before saving the application caller.
+GitHub `uses` references the executable reusable
+workflow under `.github/workflows`; the resource caller is a copyable asset.
+Internal `repository-*` workflows belong to the library, not the consumer.
+
+Explain the selected reusable's publication default before installing its caller.
+The lifecycle defaults to `publish: true`; verify this at the final selected ref.
+The automatic route publishes the exact version tag and GitHub Release after a
+reviewed managed version PR is merged. The workflow does not merge the PR.
+Setup itself does not publish anything.
+Choose `publish: false` explicitly when the task is a validation-only trial;
+do not silently carry that override into an installation meant to publish.
+Choose base and managed branches,
+fragment/history paths, historical sources and PR-reference policy consistently
+across enabled operations. For parallel maintenance, select a separate managed
+branch per release line and verify its actual planned version; a branch's name
+does not enforce a SemVer range. Use individual workflows or Docker actions only
+when their release-specific contracts suit the application's orchestration.
+
+Full tags identify concrete releases; an immutable commit pin also keeps execution
+bound to the reviewed code if an upstream tag is changed. A moving major channel
+is an explicit update policy and must be documented by the selected product release;
+do not assume it exists. In particular `@v0` may cross breaking `0.x` minors and
+does not mean Composer `^0.1`. Changing a workflow ref is a deliberate update.
+
+## Credentials and acceptance
+
+Use the selected workflow's documented token/App route and the application's
+approved secret storage. Preserve the verified automation identity and narrow
+permissions. Never check out untrusted PR code in a privileged custom job.
+Token-generated events may behave differently from human/App events; consult
+the selected release and GitHub's current rules before promising downstream CI.
+
+For an explicitly validation-only pilot, use `publish: false`. Verify a valid
+fragment, missing or malformed notes, the exact PR head's required status and sticky-comment recovery,
+any enabled bot operation, and the generated version PR. Check the actual runner
+requirements and access when changing Linux/self-hosted selection. Test custom
+policy changes relevant to the application rather than assuming a default-branch
+green run proves its generated head.
+
+The version PR must preserve exact notes and consume only its accepted fragment
+set, with no technical plan files or new `Unreleased` section. Head changes need
+fresh review and checks. Successful preparation does not authorize merging or
+publication. Retain existing publication authority for the verified result,
+using the selected release's committed evidence and recovery procedure.
+
+## Consolidation without publication
+
+Confirm the selected release's version-baseline rule. The current lifecycle uses
+the greatest stable version in committed source history or ancestral stable
+tags. With tag `v1.7.0` and committed history through `1.7.1`, a new patch prepares
+`1.7.2` while preserving the earlier history. An explicit `publish: false`
+creates neither tag nor GitHub Release, but does not block subsequent version
+PRs. Enabling publication for a later merge does not publish older consolidated
+versions retroactively. Do not remove history or manufacture a missing tag merely
+to make another PR possible.