One saved skill turns a 300-page U.S. government security checklist into a reviewed Excel tracker from a single instruction. This is the complete walkthrough: the code, the real outputs, and the failures along the way.The problem I actually haveI have spent my career inside security compliance. I was part of the team that developed the Security Technical Implementation Guide (STIG) for VxRail, a hyperconverged infrastructure product, and today, as an escalation engineer, I resolve STIG-related problems for customers in banking, retail, logistics, and the federal space, including defense and aerospace. A STIG is a hardening checklist published by the Defense Information Systems Agency (DISA); there are more than 500 of them, one per technology, and a single operating-system STIG carries 250 to 300 rules.The repetitive part of that work is not the security judgment. It is the translation: converting a large XCCDF (Extensible Configuration Checklist Description Format) XML file into something a team can track in a spreadsheet. When I began using AI assistants for this, I hit the problem most engineering teams hit: every session, I re-explained the same workflow. Which file to read, which parser to run, which columns the tracker needs, what to do with odd rules. The output varied with the quality of my re-explanation. This is prompt fatigue, and the fix is not a better prompt. The fix is to stop prompting the workflow and teach it once.An earlier version of this article described that idea conceptually. The editors asked a fair question: show it actually happening. Therefore, this version walks through one real skill end to end, with the repository, the exact inputs and outputs, and the things that went wrong.What an AI skill isAn AI skill is a version-controlled Markdown file with YAML frontmatter that packages one workflow: what to do, in what order, with which tools, and what the output must look like. The assistant loads it on demand, so the instructions live with the AI rather than in my memory or my chat history. Three properties matter in practice: consistency (the workflow runs the same way every time), context economy (the skill is fetched when triggered instead of being pasted into every conversation), and shareability (a skill committed to a repository upgrades every teammate's assistant at once).The skill, created and storedThe skill is called stig-to-tracker. It lives in my open-source repository, stig-ai-pipeline, under skills/stig-to-tracker/, next to the parser it drives. Here is the structure, abbreviated:---name: stig-to-trackerdescription: Convert a DISA STIG into a formatted Excel implementation tracker in one step. Use whenever the user asks to parse a STIG, mentions a STIG or XCCDF file (U_*_STIG.zip, *-xccdf.xml), or wants a compliance tracker — even if they do not name the tool.---## Step 1 — Locate the inputs(the STIG zip or XML; the stig-prep parser; ask rather than guess when several files match)## Step 2 — Parsepython3 -m stigprep parse --format json## Step 3 — Validate before building(a real OS STIG has roughly 150–400 rules; a count near zero means the wrong file — stop and say so)## Step 4 — Build the trackerpython3 scripts/make_tracker.py ## Step 5 — Report and deliver(surface every flagged anomaly; never present a tracker with warnings as clean)Two design choices are worth pointing out. First, the description field is the trigger: the assistant matches incoming requests against it, so it is written to catch the ways people actually phrase this task. Second, Step 3 exists because of a failure described later in this article; the skill is a living document, and its git history shows what was learned when.The exact trigger, and what context is passedThe user query that starts everything is ordinary language: "parse the STIG file." No tool names, no paths, no format flags. The assistant matches that request against the skill's description, loads the SKILL.md body into its context, and now holds the full procedure: where to look for STIG files, the exact parser invocation, the validation thresholds, the tracker script path, and the reporting rules. That is the entire context transfer. Nothing else about the workflow needs to be in the conversation.The tools the agent accessedExecuting the skill, the agent touched three things. First, the filesystem, in order to locate the STIG package. Second, the parser: stigprep, a zero-dependency Python module (Python 3.9+) that reads XCCDF, either a bare XML file or the zip exactly as DISA ships it, and emits Markdown, JSON, and CSV. Third, the tracker builder: make_tracker.py, which converts the parser's JSON into a three-sheet Excel workbook using openpyxl, the one third-party library in the chain. No network access is required at any point; the whole pipeline runs locally, which matters in the environments where STIGs are relevant.What the agent producedI ran the skill against real, current DISA STIGs, unmodified. The terminal output below is copied from the actual runs.The results across three genuinely different technologies:STIG (official DISA release)RulesCAT ICAT IICAT IIIFlagsWindows Server 2019, V3R8 (Apr 2026)28234234140SQL Server 2022 Instance, V1R480146600Apple macOS 26 (Tahoe), V1R31601314520The same skill handled a server operating system, a database, and a desktop platform, 522 rules in total, because every STIG uses the same XCCDF schema. That is the quiet power of teaching the workflow once: the taught procedure generalizes across all 500+ STIGs without modification.The workbook itself has three sheets. Summary holds the STIG metadata and severity counts. Tracker is the working sheet: one row per rule, sorted CAT I first, severity color-coded, with a status dropdown (Open, In progress, Implemented, Not applicable, Risk accepted) and empty owner, target-date, and notes columns. Details carries every rule's full discussion, check, and fix text, so nobody returns to the raw XML in order to understand a requirement.The same request, without the skillIn order to make the comparison concrete, consider what a capable generic chatbot returns for "parse the STIG file": a correct, well-organized list of suggestions. Download the STIG from DISA, review the severities, consider a spreadsheet, prioritize CAT I. Every item is true, and every item is still my work to do. The skill-driven agent returns the artifact itself, plus a flag count telling me whether a human needs to look at anything.What worked, what failed, and what I changedThis section exists because real systems earn their guardrails. Four items from the build log:The interpreter trap. My first run failed immediately: my shell defaulted to an Anaconda Python 3.8, and the parser targets 3.9+. The fix was trivial (invoke the system /usr/bin/python3, which is 3.9.6), but the lesson went into the skill: the setup step now names the version requirement explicitly, because an assistant that silently retries interpreters wastes exactly the time the skill is meant to save.The wrong-file hazard. My repository ships a 6-rule sample STIG for testing. During development, the pipeline once parsed that sample when a real STIG was intended, and it produced a perfectly formatted, perfectly useless 6-row tracker without complaint. That is why Step 3 of the skill exists: a real OS STIG has roughly 150 to 400 rules, so a count far outside that range now stops the workflow with a question instead of shipping a plausible-looking artifact. Plausible-but-wrong is the most dangerous failure mode AI systems have, and the defense is a validation step, not hope.The dropdown quirk. In openpyxl, making Excel's in-cell status dropdown appear requires setting showDropDown=False, which reads exactly backwards. Twenty minutes went to that. It is in the script now, commented, so nobody pays those twenty minutes again; a bundled, tested script is precisely how a skill amortizes small pain.The triage guardrail. The parser's optional AI layer classifies each rule into buckets such as quick-win or risky-change. Its unit tests feed the classifier a deliberately invalid bucket ("banana") and assert that the system downgrades it to needs-judgment rather than trusting it. As such, invalid model output degrades toward more human review, never less. The same principle drives the tracker's flag count: anomalies are surfaced, not silently repaired.Where the human staysNothing in this pipeline applies a fix to a system. The skill reads, converts, validates, and reports; the decisions, which rules to implement, which risks to accept, remain with the engineer, recorded in the tracker's status column. I hold the position, borrowed from my own project's README, that AI output is an aid, not an authority. The skill's job is to eliminate the two hours of translation between a DISA release and a working tracker, and it does: the Windows Server run above, 282 rules from raw XML to reviewed workbook, completes in seconds.ConclusionThe future of AI in engineering work is not a smarter chat window. It is captured expertise: workflows written down once, version-controlled next to the code they operate, triggered by plain language, and bounded by validation steps that route anything unusual back to a human. The skill shown here is small, open source (MIT), and reproducible from its repository in a few minutes: github.com/himanshusaxenagithub/stig-ai-pipeline. Module 2 of the pipeline, a scanner that executes STIG check procedures and records pass/fail results, is under development, and it will ship the same way: as code, with a skill, and with its failures documented.