v0.1.3

Changed

• Plugins released with this version:
  • prompt-engineering 0.3.0: improving-prompts has notes for GPT-6 Astra and GPT-6.1 Sol, and covers the whole GPT-6 family in one section.

v0.1.2

Added

• Evaluation scenarios for the release-process option that releases the root with every component release, with a script that builds a throwaway marketplace to run them in and a script that runs the release workflow's checks on a tag locally.

Changed

• Plugins released with this version:
  • foundations 0.2.0: release-process can release the root with every component release, so a marketplace's Latest release always names the newest plugin versions, and its components workflow template can enforce that.

v0.1.1

Changed

• Plugins released with this version:
  • foundations 0.1.1: release-process explains correctly why a plugin's release can show as Latest before the first marketplace release.
  • prompt-engineering 0.2.0: improving-prompts has notes for Grok 4.7, GPT-6 Sol and Luna, and Claude Opus 5.5 and Sonnet 5.5.
• Every plugin release now also releases the marketplace, with at least a patch bump, so the Latest release on GitHub always names the newest plugin versions. Its notes list each plugin released with its new version and a link to that plugin's release. Decision 0011 records the rule.
• scripts/validate.py requires this changelog to link every plugin release made after the first marketplace release, and refuses a link to a plugin release that does not exist.
• The release workflow refuses a plugin tag unless the marketplace release at the same commit lists that plugin release.

prompt-engineering v0.3.0

Added

• improving-prompts has notes for GPT-6 Astra. OpenAI's GPT-6 prompts were written from Astra's behaviour, so the notes apply them to Astra directly and add its API settings: no none effort, no sampling or log-probability parameters, and tool calling only through the Responses API. They also add OpenAI's advice on having the model name the skill instruction that made it pause, keeping skill descriptions short and AGENTS.md pointers tied to when each doc applies, and granting standing permission for workflows known to be safe. Where OpenAI's pages call Astra's clarifying questions a strength while its prompting guidance treats them as a cause of early stops, the notes say which page says what.
• improving-prompts has notes for GPT-6.1 Sol: effort from low to max with medium as the default and no none or minimal, tool calling only through the Responses API, and multi-agent delegation in beta. They add what its system card reports against GPT-6 Astra, such as pressing on past warnings more often, and say that no source shows whether a prompt changes it. OpenAI has published no prompting guidance specific to GPT-6.1 Sol, so the family's Astra-derived prompts are a starting point and the rest is listed as unconfirmed.

Changed

• improving-prompts covers the GPT-6 family in one section. The GPT-6 Sol and Luna notes now list the log-probability parameters to remove when effort is above none, and describe Luna's intended use in the words OpenAI's pages now use: extraction, classification, transformation, and structured summaries.

prompt-engineering v0.2.0

Added

• improving-prompts has notes for Grok 4.7. xAI publishes no prompting guide for it, so the notes cover what its documentation states (always-on reasoning with an effort setting, parameters that return errors, parallel calls, schema guarantees, citations, cache-friendly ordering) and mark the rest as unconfirmed. The model notes and the source list now show a review date on each section or entry checked after the file's own date.
• improving-prompts has notes for GPT-6 Sol: its effort levels and API constraints, and what OpenAI's GPT-6 guide changes from GPT-5.x, namely more clarifying questions and earlier stops, sensitivity to conflicting instruction files, heavier formatting, unprompted testing, and less delegation. The guide's prompts were written from GPT-6 Astra, so the notes present them as a starting point for Sol and list what stays unconfirmed.
• improving-prompts has notes for GPT-6 Luna. Luna shares GPT-6 Sol's effort levels, API constraints, and family guidance, and the notes add what OpenAI says Luna is for: focused, high-volume work such as summarization, extraction, and focused coding. OpenAI has published no Luna-specific prompting guidance, so its behaviour stays unconfirmed.
• improving-prompts has notes for Claude Opus 5.5, from Anthropic's Opus 5.5 guide, migration guide, and system card. They cover always-on thinking with medium as the default effort; removing thinking and reasoning-in-the-response instructions; the rejected forced tool choice; progress updates that arrive as thinking blocks; early stops on unattended runs; exploring before acting in multi-app work; time signals for agent teams; marking pasted text; and frontend and visual inputs. They also list which Opus 5 adjustments no source confirms for Opus 5.5. The reasoning reference now rejects manual chain of thought for models that can decline requests to write out their reasoning, and prefers a lower effort setting over prompt text where the provider says effort is the more reliable control.
• improving-prompts has notes for Claude Sonnet 5.5, from Anthropic's Sonnet 5.5 guide, migration guide, and system card, published at launch on 2026-09-28. They cover recalibrated effort with a high API default; the between_tools setting; a think-first line for JSON answers on reasoning tasks; early check-ins and skipped checks at low effort, unrequested additions at every level, and self-started review rounds at the top levels; progress updates that arrive as thinking blocks; under-used search in chat; mid-turn user messages misread as injections; and the loss of the context awareness that the Sonnet 5 notes relied on. The reasoning reference now allows a measured think-first line and treats the self-check as depending on effort where the provider says so.

foundations v0.2.0

Added

• release-process can release the root with every component release, so the Latest release of a plugin marketplace or another catalog always names the newest component versions and links to their releases. A new reference covers when the option fits, the root bump (at least a patch), the notes format, the order to push tags in, catching up releases that skipped the root, and a check to add to a project's own validator. Setting up independent versions now asks whether to adopt it.
• The components workflow template can refuse a component tag unless the root release in the same commit lists it. Set ROOT_FOLLOWS_COMPONENTS to "true" to turn the check on; it is off by default, and component pre-releases are exempt.

foundations v0.1.1

Fixed

• release-process explains why a component release shows as Latest before the first root release: GitHub falls back to the newest tag date until a release is marked Latest. It no longer blames a missing --latest=false for that.

v0.1.0

Added

• Plugin marketplace with four plugins, one per category: foundations, product-design, product-engineering, and prompt-engineering. Claude Code and Copilot CLI install a category as one plugin, and each plugin carries its own version and changelog.
• Product-engineering evaluation guide with lifecycle diagrams, a runnable fixture and grader, and behavioral scenarios for interviews, real app verification, per-lens review recall, PR categorization, merge safety, and stacked PRs.
• Decision log in decisions/ recording why the repository and its release process are shaped the way they are.
• scripts/validate.py and a CI workflow that enforce the repository rules on every push and pull request, including a changelog per plugin whose newest release matches the plugin's version.
• Release workflow for tags on main:
  • A vX.Y.Z tag publishes a marketplace release, with that version's section of this changelog as notes. It is marked Latest.
  • A <plugin>--vX.Y.Z tag publishes that plugin's release: the section from its changelog, one archive per skill in the plugin, and checksums.
  • Either tag is refused unless marketplace.json declares the tag's version.
  • A tag that GitHub did not act on can be released by hand from the Actions tab.

Security

• Published releases are immutable: their archives, checksums.txt and tag cannot change after publication.
• The CI and release workflows run actions/checkout pinned to a full commit SHA, and Dependabot proposes updates to it weekly.

prompt-engineering v0.1.0

Added

• improving-prompts skill: rewrites a rough prompt into an engineered one by classifying where it will run, diagnosing its gaps, and applying only the prompt and context engineering techniques that close them. Returns the techniques applied and rejected with reasons, placeholders for facts it could not infer, settings that belong outside the prompt, and the enhanced prompt in a copy-paste-ready tag. Ships a technique catalog split by group, dated model-family notes, worked examples, and templates.

product-engineering v0.1.0

Added

• Nine skills built around one implementation loop. running-implementation-loops picks the track for the work item (quick fix, bugfix, small change, feature, new app, refactor, spike) and runs the stages it needs.
• Four stages where you take part:
  • specifying-work-items interviews you and writes spec.md.
  • brainstorming-solutions lays out distinct approaches for you to pick from.
  • defining-verification agrees how the agent will prove the work runs.
  • planning-implementation turns it into a roadmap of PR slices with an autonomy contract you approve.
• Four stages the agent runs alone:
  • implementing-plans builds each slice.
  • verifying-implementation starts the app and drives it (browser, API, CLI) to observe every acceptance criterion.
  • reviewing-code-changes runs a quick intent review before the PR and a five-lens review (architecture, security, conventions and idioms, efficiency, intent) on it.
  • shipping-pull-requests opens one PR per slice, marks it for human or agent review, and merges agent-reviewed PRs only when checks pass on the reviewed head and you authorized it.