6. AI workflows and experimentation
6.1 Capturing a reusable documentation process
My AI work developed around recurring documentation tasks rather than a single drafting prompt. The work-history report records designing, invoking, revising, and packaging skills that connect Jira research with existing help source, designs, topic changes, review, and validation. It identifies six principal internal workflows: AI Help, Jira, Peer Review, Epic Content Compare, WYSIWYG Diff, and Umbraco Pulse Exporter. The linked Jira file is a separate, generalized copy; the other internal workflows are described in the project and engineering accounts, and the shareable peer-review copy is available separately.
The AI Help workflow was expected to inspect feature tickets, comments, attachments, linked implementation issues, and relevant Figma material before resolving the help impact. The history records a preference for updating existing topics narrowly and using the Testing source for 2027.0 work where instructed. It also records self-review and image checks. These are historical workflow requirements and examples of use, not new instructions to modify a repository while preparing this portfolio.
The July documentation email and training guide connect this workflow to a transferable writing process. They describe getting a complex feature into a strong draft state while retaining testing, human review, refinement, and verification. Repository synchronization and validation are part of the method because generated text still has to fit the source tree and publishing system. The AI authoring project account explains the release-help starting point and its present evidence boundary.
6.2 Learning from actual review decisions
I mined approximately 2,500 peer-review comments from Git commit history to shape this skill's review guidance. I refined it when an automated review missed something I subsequently corrected. The work included direct openings, grammar, title and UI-control treatment, and the distinction between adding review comments and improving a generated draft. The project account explains the reusable skill.
The skill makes recurring decisions easier to explain and revisit. A public case study can show a suggestion, the final human decision, and the reason for the difference.
6.3 Integrations and access boundaries
My Jira MCP business case requested read-only access for research into recurring support issues, troubleshooting patterns, product behaviour, and documentation opportunities. It distinguished that research access from create/edit/transition permissions and retained Technical Writer review before publication.
Other historical workflows explored broader capabilities, including Jira Data Center/Excel data, attachments, previews, controlled action handling, and Copilot Studio/local-terminal interactions. Those requests have different permission scopes. A read-only research proposal should not be described as permission for every later automation experiment. The work register preserves the scope stated in each historical record.
The integrations also include Figma design retrieval, API/export investigations, and packaging workflows for different AI environments. I prepared public Jira and peer-review copies with installation paths for both Codex and Claude.
6.4 Tool evaluation and governance
The September 2026 Education Services AI Committee record describes comparison of Copilot, Claude, Open Web UI, and other AI work. It records my experience using Claude for migration-related development and my judgement that it was more capable than Copilot for that work. That is a reported use-case assessment, not an independent general benchmark of the products.
The committee discussed measurable outcomes, use cases for different tools, licence costs, and consolidated business cases. We evaluated potential reductions in manual effort alongside quality and cost considerations.
I also explored embedding a custom AI worker through Open Web-based APIs, including its business case and pricing, and examined the case for a Figma Dev seat to address export/API limitations.
6.5 Pulse AI and visual context
A September 3, 2026 proof-of-concept discussion addressed better image handling in Pulse AI answers. I suggested focusing on a specific toggle or option in a workflow and asked whether UI/UX already had reusable labelled material. Darryl and I were assigned to help label and draw bounding boxes for a SOTI XSight Live View console page.
I also investigated Pulse AI responses where draft documentation appeared unexpectedly and the data-source or repository path needed review. This proof of concept examined what an AI system consumes and exposes alongside my work using AI to draft content and build tools.
6.6 What the activity counts mean
The Codex report records 147 local threads and 873 observed user prompts/messages, based on 147 session files with an approximately 330 MB footprint. Its primary categories total 147: reusable skills 33, integrations 21, online-help authoring 20, review/QA/governance 17, DITA/rendered workflows 15, environments 15, personal/admin 10, Umbraco/Pulse 9, and other work 7.
These counts describe the observed history, including exploratory and interrupted work. They are not completed-project totals, time-saved estimates, or comparisons with colleagues. The chronology shows how these workflows developed through repeated tickets and refinements.