4. Projects and reusable tools

4. Projects and reusable tools

4.1 How the projects connect

My projects address different parts of the same documentation process. Product-writing examples establish the technical facts and explain the feature. Help-improvement work changes how readers find and follow the content. Review and validation tools make changes easier to inspect. Migration and export utilities preserve the content through a platform change. AI workflows connect research and authoring tasks, while practical authoring tools explore ways for more people to participate in the process.

The selected project catalogue below follows the same order as the Projects page. Its numbers are a reading order. Stable P-identifiers are retained in the reference archive for source tracing; they are not original Jira or repository names. Other work, including rendered comparisons, knowledge-base contributions, and online help improvements, is covered in the relevant story chapters and Writing.

4.2 Custom DITA and XML Authoring Tool

Oxygen licensing limited who could work directly with structured documentation. I developed a custom DITA and XML authoring tool as a stopgap for authoring and review, and team managers used the runnable package while broader authoring options were explored.

The practical problem was access: writers and reviewers needed to work with XML/DITA content without always having the same licensed authoring software. The package offered a useful interim route for that work.

I used AI-assisted development to build the tool, translating an authoring need into a runnable utility used by my team.

For a visitor-facing guide, the demonstration should start with a small, sanitized documentation example and show the actual supported journey from opening content to reviewing or editing it and saving or exporting the result. Each step must be tested against the real package. A sample task and screenshots can make the tool understandable, but they should not stand in for proof that validation, round-trip editing, or lossless saving works.

The master currently records the purpose, context, contribution, and evidence. A download, repository, or hosted demonstration should be attached only after the package, dependencies, licence, ownership, and data handling are checked. The tool should be presented as supporting particular tasks, with clear limitations, rather than as a universal replacement for an established authoring suite.

4.3 AI Documentation Authoring Workflow

The AI Help workflow addresses the amount of context a writer must gather before drafting a feature update. My workflow connects the Jira feature with comments, attachments, related issues, design evidence, and the existing help source. It then identifies affected topics, prepares changes, and runs review and validation checks. I used this process to prepare a complete AI-generated starting version of the SOTI MobiControl 2027.0 online help so other writers could work from a comparable draft instead of a blank page; each writer retained responsibility for the final content.

The reusable element is the captured process. The training guide shared on July 3, 2026 describes setup, repository synchronization, invoking the skill with a Jira identifier, impact analysis, file and TOC changes, and validation. It was written for Michael and Ammar so the method could be transferred to other writers.

For a future public resource, a sanitized worked example could demonstrate the reasoning from requirement to documentation impact without relying on corporate Jira access. A reusable package would need a clear list of integrations, repository assumptions, credentials supplied by the user, and human review obligations. The original internal workflow remains part of the master; public portability is a separate verification step.

4.4 Peer reviewing with AI

The peer-review project captures recurring editorial judgement in a reusable skill. I mined approximately 2,500 peer-review comments from Git commit history to identify recurring patterns, then refined the skill against differences between automated suggestions and my final edits. A 40-commit sample helped me test that feedback. The detailed guidance includes grammar, direct topic openings, UI terminology, wintitle and uicontrol treatment, and comment-only Oxygen-style review.

The practical audience is a writer or reviewer who wants consistent feedback on structured help content. A useful demonstration would show a small topic before review, explain the reason for each suggestion, and compare the result with a human-reviewed version. This would make the judgement visible rather than asking visitors to trust a list of tool names.

I applied and refined the approach across review work associated with DOC-5130, DOC-5354, DOC-5318, DOC-5319, DOC-5472, DOC-5140, DOC-5350, and DOC-5377.

I have also prepared a separate technical-docs peer review skill for other writers to customize. Its company-neutral checks preserve the useful workflow—verify the claim, inspect the reader route, then give concrete editorial feedback—without exporting the original review examples or internal paths. DITA and Oxygen guidance is optional within that copy. The download page explains its scope and installation.

4.5 Umbraco Migration Tooling

The team wanted to move structured help from Oxygen XML into Umbraco so more contributors could participate without the same authoring licence. Manual re-entry was too slow for that scale. I developed AI-assisted conversion, reconciliation, and export workflows to carry existing content into Umbraco-compatible HTML and then into a static help package. The work had to preserve notes and tips, tables and merged cells, images and icons, local links, context-help identifiers, navigation, and search. I also worked on a graphical Umbraco Publishing Tool and product/version configuration as the input pipeline evolved.

A future visitor should be able to see a sanitized input, inspect the resulting package, and understand the validation checks. A generic sample export may be more accessible than an internal environment-dependent tool. Management API access, compatible Umbraco versions, source content models, package layout, and supported export operations must be verified before providing setup instructions. Section 7 retains the technical history and the distinction between evolving requirements and verified implementation.

4.6 Figma Retrieval and Export

The Jira/Figma tool grew from a repeated need to locate design evidence associated with a feature. I designed it around Jira epics, Figma links across related tickets, multiple frames or images, image export, and a local browser interface. I also examined Figma account/API limits and the case for a Dev seat.

A public example can show the discovery and export process using accessible sample material, with the resulting image set and source links. A setup guide can explain inputs, access requirements, and the handling of designs with multiple frames.

4.7 Documentation Quality and Validation

The problem began with defects that were difficult to repair without a reliable inventory: broken links, missing or misdirected images, table rendering issues, and differences introduced by migration. I used AI-assisted checks and structured trackers to identify affected pages, record symptoms, and give reviewers a reproducible route to each issue.

The broader quality chapter explains the validation practice. The Writing collection shows exact before-and-after revisions where source-level change can be verified. A direct link from an inventory item to its final validated fix should be added only when both records are available.

4.8 Editorial Workflow and Content Integrity

As more people contribute to documentation, a review process needs clear ownership and a way to prevent one person's stale browser session from overwriting another's changes. I documented the editorial review path, circulated the workflow, proposed safeguards for content integrity in Umbraco, and reported a related defect.

The operations chapter explains the process and the difference between proposed and verified behavior.

4.9 Reusable Jira Issue Workflow

I developed Jira and peer-review workflows as part of my broader effort to make technical knowledge and editorial judgement reusable. The internal skills support my own environment; the shareable copies are separate, generic adaptations for others to install and customize. My original installed skills are unchanged.

The Jira issue workflow ZIP includes an installable skill, a portable PowerShell helper, and an example configuration. A user supplies their own site, project, authentication method, and token outside the package. It can search, read, and create a specifically requested issue, then read that issue back. The helper passed local fixture tests for these operations; it has not been exercised against every Jira installation. Its REST API v2 shape must match the destination site.

4.10 Reusable Documentation Peer Review

The technical-docs peer review ZIP includes an installable skill and focused references for evidence-led review, DITA tasks, Oxygen comments, and issue context. It asks reviewers to check product claims, reader flow, links, publishing risks, and language while distinguishing verified findings from questions. Teams can change the references to match their own style guide and publishing system. Skill structure was validated; no review-accuracy score is claimed. The public copy generalizes the method from Project 3 without exporting internal examples.

These downloads give visitors a usable project artifact alongside the documentation before-and-after examples. The package manifest and test record are retained in the audit. A company-specific connection, private source file, manager feedback, or customer data is not included in either ZIP.

4.11 Project files and related work

The project files include two generalized Agent Skills copies with installation guidance for Codex and Claude. My other work on rendered comparisons, SME review interfaces, DITA transformations, knowledge-base writing, and online help improvements appears in the relevant Story chapters and .