DOCUMENTATION TOOLS / RELEASE WORK
Release and content tools
I built AI workflows that automated recurring work around Intune documentation releases. The assistant gathered product context, prepared announcements, staged approved article changes, and coordinated status updates. Supporting scripts scanned work items, checked readiness, and updated release dashboards and queries.
MY CONTRIBUTION
I designed and configured the workflows, built and adapted their supporting tools with AI coding assistance, reviewed release changes, and refined the process from its results.
TOOL TYPE
AI workflows connected to work items and documentation, with reusable instructions and Python and PowerShell helpers in Prompts and Agents.
THE WORK
What I needed to manage
My release work involved product work items, linked specifications, draft announcements, review decisions, article changes, and publication status. I needed to keep track of those steps for both upcoming features and features that had shipped.
I built the workflow so the assistant could gather context, draft content, carry out approved changes, and keep the records current. Scripts handled repeatable operations such as scanning eligible work and updating release queries. I defined the process and reviewed the editorial and release decisions.
COMPONENTS
What the toolkit handled
| Component | Input and work performed | Output |
|---|---|---|
| Draft discovery | Scan scoped work items for source material, existing drafts, review status, and published work. | A list of draft candidates and items that need attention. |
| Release drafting | Read linked context and prepare either an upcoming-feature or shipped-feature announcement. | A reviewable draft with unresolved details identified. |
| Article staging | Place approved content under the correct headings and remove internal editing annotations. | Article changes prepared for pull-request review. |
| Readiness reporting | Classify each required deliverable separately. | Status such as source available, drafted, approved, staged, or published. |
| Release maintenance | Prepare matching pre-release cleanup during staging, check publication, maintain the archive, and roll dashboard queries forward. | Updated articles and operational views. |
The readiness report kept staged content distinct from published content. The staging workflow separately reported items held from publication.
WORKFLOW
How the AI workflow handled a release
I started with a release and a scope of work. The assistant loaded the relevant workflow, called connected tools, and ran supporting scripts. It brought drafts and proposed changes back for review, then carried out the approved next steps.
- 01AI + scriptsScan and gatherFind eligible work, classify its state, and collect the product context.
- 02AI + reviewersDraft and reviewPrepare the announcement, flag missing details, and review it with the product team.
- 03AI + reviewersStage and inspectPrepare approved article changes and matching cleanup. Keep held items out.
- 04AI + scriptsVerify and updateCheck publication and update its status. Run the release dashboard and query maintenance.
AI carried out the workflow; editorial and release decisions remained explicit review points. A staged change became published only after the publication check.
The rollover helpers included preview modes, repeat-run guards, and reverse operations. I also maintained the instructions when the repository’s branch process changed, so the staging workflow continued to target the right starting branch.
EXAMPLE
Following two items through a release
Illustrative reconstruction · fictional feature descriptions
A configuration option and a held update
For a new configuration option, discovery finds source material but no draft. Drafting produces an announcement and flags an unverified platform detail. Once that detail is resolved and the draft approved, staging puts the text into the appropriate article.
Staging also prepares the matching pre-release entry for removal. After the article changes publish, the publication check confirms the update’s status. A second update that is still on hold stays out of those changes.
| Item | Next action |
|---|---|
| Configuration option | Stage the announcement and matching cleanup, then verify publication. |
| Held update | Keep the hold visible and wait for its release decision. |
DEVELOPMENT & USE
What the saved records show
- Draft evaluation against published materialA saved evaluation found that a generated announcement treated broad planning information as though all of it had shipped. It documented the missing checks and the narrower scope supported by the published version.
- Changes to the implementationMy commit history records additions to post-action verification, consolidation of the drafting workflow, and updates to staging when the branch process changed.
- Use during release workSaved working-session records contain readiness requests, follow-up checks on skipped items, and use of staging and rollover entry points.
Those records document development and use. A recorded request alone does not establish that every remote operation completed, and I have not treated it as proof of publication.
The supporting work records are private. This page describes their relevant findings; the example above is a reconstruction, not an original release record.
SCOPE & CREDIT
What this implementation depended on
The tools were configured for a documentation team’s work-item fields, article conventions, and account access. Readiness reporting distinguished staged content from published content, and staging separately identified held items.
I developed and maintained the workflow with AI coding assistance. My work combined original tools with configured and adapted upstream components. The broader Prompts and Agents toolkit followed the Agency Playground pattern.
The assistant also captured completed work for Weekly Reports. The release tools tracked the deliverables; reporting used the captured activity to explain the work behind them.