Where this fits

You are an agent asked to cut a new OfficeIMO release. You clone the repo, see a Website/build.ps1, a shared PowerForge pipeline, and a pile of NuGet and PSGallery artifacts. Without guidance, you might improvise a local packaging script, produce a broken module, or dirty the working tree with generated docs. The officeimo-build-release skill stops that spiral: it points your agent to the repository's canonical build, packaging, and release entrypoints, so every artifact matches what maintainers expect.

Why agents benefit

• Detects dirty state and branch context first – avoids committing over unrelated changes or releasing from the wrong branch.
• Prefers repo-standard entrypoints – uses solution builds for compile evidence and Website/build.ps1 for site changes, instead of ad-hoc logic.
• Keeps generated output narrow – tells the agent to regenerate only source-of-truth docs and discard broad, accidental changes from validation commands.
• Maps release layers correctly – distinguishes local source, open PR, merged branch, release tag, package feed, and installed downstream version before answering “is this fix available?”.
• Handles PDF and conversion work with maintained tooling – avoids fragile one-off scripts when the repo already has a tested path for those artifacts.

Practical scenarios

Validating a merged PR before tagging a release

Your agent is asked whether a recently merged fix is safe to ship. The skill instructs it to verify the dirty state, inspect the branch, then run the standard solution build to confirm compilation. It also checks whether the fix exists only in the merged branch or already has a release tag – preventing a premature announcement.

Packaging PSWriteOffice for PSGallery

The task is to publish an updated module. Instead of writing a new pack script, the agent loads the shared PowerForge or PSPublishModule entrypoints defined in the repo. It regenerates any changed documentation from the source of truth and ensures the final .nupkg passes the same validation the maintainers use.

Updating officeimo.com with a new changelog

When a release note or website asset must change, the agent uses Website/build.ps1 and the site's pipeline files. It avoids touching unrelated generated HTML or CSS, and only commits files that correspond to the intended change, keeping the PR review clean.

Add it to your agent workflow

Install the skill with:

npx skills add EvotecIT/OfficeIMO --skill officeimo-build-release

Then instruct your agent to call the skill when a task mentions building, packaging, releasing, or validating OfficeIMO artifacts. For example:

Use the officeimo-build-release skill to assess the current git state, build the solution locally, and then produce a release candidate tag for the latest commit.

The skill will enforce the golden path: check the branch, pick the right entrypoint, keep output narrow, and report which release layer actually contains the change. You can also browse it on OpenAgentSkill for deeper context.

Compare before adopting

Before wiring this in, compare it with alternative approaches: a generic “build .NET project” prompt, a hand‑rolled PowerShell pack script, or separate skills for packaging and release. Look for quality signals like the repo's CI pipeline coverage, how often the maintainer updates build scripts, and whether the skill's instructions match your team's actual workflow. If you only need a one‑off build, a simpler prompt may suffice – but for repeatable releases, repo‑standard guidance beats improvisation.

Why it is worth tracking

OfficeIMO has 515 stars and an active maintainer (EvotecIT) who ships both OfficeIMO and PSWriteOffice. The skill encodes best practices that evolve alongside the repository, so tracking it keeps your agent aligned with upstream decisions. Re‑evaluate it whenever the repo's build pipeline changes or when you notice your agent producing artifacts that drift from the expected structure.