Tool development note
Human-Systems Engineering Agent
Reusable human-systems guidance for AI-assisted product work
Chris Durgin · Version 1.9 · Updated · About 10 min for the main article
Original article text: CC BY 4.0 · Reuse and attribution
Abstract
The Human-Systems Engineering Agent (HSE Agent) is a human-led toolkit I developed to help AI assistants turn field insight into product decisions. Its reusable Human-Systems Engineering (HSE) skills support evidence synthesis, workflow analysis, product definition, requirements, and validation. Teams supply the research, context, and judgment; the toolkit helps organize that knowledge, examine options, surface gaps and risks, and prepare artifacts for AI-assisted development and team delivery. This article explains how the skills work together, demonstrates output review, and shows how to adapt the public edition to your own field.
Product design, augmented
Human-Systems Engineering brings people, technology, tasks, information, and working conditions into the same product discussion. I organized HSE Agent to help teams apply that perspective across research, product strategy, design, implementation, and validation. The team supplies field inquiry, observations, interviews, subject-matter knowledge, requirements, constraints, and business context.
HSE Agent augments your ability to synthesize evidence, examine options, and carry reasoning into product decisions. It helps with analysis and artifact preparation while you direct the inquiry, judge the recommendations, and decide what happens next. Use it to connect patterns, surface gaps and risks, and consider priorities for a minimum viable product (MVP) and validation.
A skill is a reusable set of task instructions, including when it applies, the context it needs, and how to review the output. My contribution is how these practices are organized into 22 complementary skills, context profiles, and review expectations. The AI assistant uses the selected instructions and available source material; the toolkit itself does not connect to research or operational systems.
From evidence to artifacts a team can use
Outputs include research synthesis, product strategy, workflow analyses, Product Experience Blueprints, prototype direction, experiments, validation plans, requirements, backlog stories, and executive narratives. Their value depends on whether they help the team make and explain the next decision, with evidence, assumptions, recommendations, risks, and validation needs kept distinct.
Reviewed artifacts give a delivery team or AI development tool a rationale to build from. As prototype review and field validation produce new evidence, update the product direction and its linked requirements so later work retains the reasoning behind earlier decisions.
The aim is to spend less effort reconstructing context and assembling documents, leaving more attention for investigation, design, and validation. I designed the toolkit to make human-centered practices easier to apply across teams and preserve reasoning through handoffs. Assess those intended benefits in your context: examine time and review effort, source accuracy, decision usefulness, and continuity between artifacts.
How HSE Agent, PEB, and BDX fit together
Behavior-Driven Experience (BDX) provides a way to investigate behavior and identify experience improvements. The Product Experience Blueprint (PEB) connects evidence about people and work to coherent product decisions, scope, implementation, and validation. HSE Agent contains skills that help an AI assistant apply these approaches and produce related artifacts.
PEB and BDX can be used directly with a team. The toolkit supplies reusable instructions for applying them with an AI assistant; each method remains useful independently.
Replace my mining context with your own
My experiments are grounded in mining and operational technology. My workplace toolkit therefore includes a context-adaptation skill for roles, shift handoffs, field conditions, site variation, operational risk, and subject-matter review. That context helps in my work; it should not become an assumption about yours.
Replace that layer with a description of your own users, tasks, decisions, vocabulary, working conditions, data definitions, and authority. Identify the domain experts who can resolve gaps. Keep research synthesis, workflow analysis, blueprinting, backlog development, and validation skills available alongside it.
My workplace edition also includes guidance for Freeport’s Mineral Design System (MDS) 2.0 and Flutter application development. The public edition replaces that company-specific layer with a profile for your approved components, tokens, accessibility requirements, and delivery conventions. Check examples in the other skills for assumptions that may also need adaptation.
A practical workflow
- Choose the task. State whether you need research synthesis, a workflow analysis, a blueprint, a backlog, or a validation plan, and name the decision the output should support.
- Supply context. Provide relevant source material, users, goals, constraints, data availability, and any existing decisions. Identify which sources are authoritative and where information is incomplete.
- Ask for traceable reasoning. Request separate observations, interpretations, assumptions, and recommendations. Require source references where available and explicit labels for unknowns.
- Review the result. Check claims against the inputs, test whether the workflow makes sense, and resolve disagreements with the relevant practitioners or specialists.
- Carry learning forward. Update the artifact and its linked requirements or backlog as prototype review, data investigation, and user research change the direction.
Inspect a skill in use
This example follows a volunteer handling an equipment-loan request at a library. The scenario is fictional and included in the public kit. The sample response and review show how to check an assistant’s reasoning; they do not report an actual model test.
1. Supply source notes
- S1: Volunteers check a shared tablet-loan list. Some records lack a recent return confirmation.
- S2: A coordinator can confirm availability. Volunteers cannot change inventory records. Escalation timing is undecided.
- S3: The desk sometimes loses connectivity. Questions must be preserved without exposing borrower details. No live data source or reservation integration is provided.
2. Apply the relevant instruction
Excerpt from the public Workflow & Task Analysis skill:
Separate evidence from assumptions. Do not invent research findings, user quotes, metrics, business rules, technical constraints, data availability, or validation results.
Task prompt: “Map the volunteer’s clarification workflow. Reference S1–S3 for each finding; distinguish proposed behavior from confirmed rules and identify who must resolve each unknown.”
3. Inspect a sample response
Proposed workflow, based on S1–S3. Confirm the sequence with the workflow owner:
- Volunteer checks the record: inspect the loan and return information (S1).
- Return is unconfirmed: keep availability unresolved rather than promise a device (interpretation of S1).
- Volunteer prepares a question: identify the loan and missing confirmation; confirm what may be retained during connectivity loss (proposed response to S3).
- Coordinator confirms availability: preserve the coordinator’s authority (S2); the handoff channel and timing remain open.
- Volunteer communicates the result: report the confirmed status, or explain what is still unresolved (proposed final step).
- Supported finding
- Missing return confirmation leaves availability uncertain (S1). The next confirmation belongs with the coordinator (S2).
- Proposed behavior
- Show “Availability unconfirmed” and let the volunteer prepare a question containing the loan ID. Confirm which fields may be retained under the privacy requirement (S3).
- Unsupported suggestion to catch
- “Automatically reserve the tablet and escalate after 15 minutes.” The supplied notes provide neither a reservation integration nor an escalation timing rule.
4. Make the review decision
I would retain the uncertainty finding, keep the clarification action as a proposal, and remove automatic reservation and the invented deadline. I would ask the workflow owner to confirm escalation timing and permissible offline storage before implementation.
The next test would ask a volunteer to recognize an unconfirmed record, identify the coordinator as the next owner, and prepare a question without promising a device. Record the actual response and any unsupported assumptions when you run this exercise in your own environment.
What to inspect in an output
Check evidence: can a claim be traced to supplied material, or has an assumption been presented as a finding? Check context: does the recommendation match users, authority, environment, and actual work? Check feasibility: does it depend on unavailable data or an unconfirmed capability?
Check behavior: are failure paths, recovery, accessibility, permissions, and human review addressed where relevant? Check usefulness: does the artifact help someone make a decision, or merely restate a framework? Record unsupported recommendations and correct the instructions or inputs as appropriate.
Connecting skills across a product workflow
Use skills together when the next decision needs a different kind of analysis. Research synthesis can organize observations into needs and opportunities; workflow analysis can clarify tasks, decisions, and handoffs. A Product Experience Blueprint then connects the supported findings to capabilities, scope, dependencies, and validation.
A Product Lifecycle Progress Map summarizes current progress, key artifacts, decisions, risks and next steps for stakeholders, linking to the blueprint for deeper intent. It remains a living overview as work advances. With that blueprint reviewed, the backlog skill can help define delivery work while preserving the user need and rationale. Carry source references, open questions, and review decisions forward so an assumption does not become a confirmed requirement simply because it appears in the next artifact.
Use the smallest combination that answers the current question, and add a skill when a new analysis is needed. As implementation or research changes the evidence, update the blueprint and linked backlog together. The environment guidance below explains how skill selection works in different tools.
Human responsibility and known limits
I treat generated artifacts as drafts to inspect against the source material. AI can omit context or invent a connection even when the instructions ask for evidence. Review recommendations with practitioners and specialists who understand the work and its consequences.
The public edition received bounded behavioral smoke tests in Codex, Copilot and Claude, including lifecycle-map creation and updates. For v1.0.19, hosted Codex installation and update checks passed; the Copilot app and both tested VS Code harnesses loaded the hosted package. Public Claude v1.0.18 was behaviorally tested; the v1.0.19 branding package has not been separately uploaded and retested in Claude. These checks do not validate every skill or possible output, general reliability, or time savings. Evaluate representative tasks in your own environment, retain failures as well as successes, and record the human decisions that shaped the final artifact.
Using the guidance across tools
I developed and tested private editions of this guidance for Claude, Codex, the Snowflake-based Prospector CoWork environment used at Freeport-McMoRan, and GitHub Copilot. Public v1.0.19 provides installable Codex, GitHub Copilot and Claude editions, plus a portable Markdown library. Codex and Copilot users can add the CD-UX/hse-agent repository as a marketplace; Claude users can upload the Claude plugin ZIP. A repository-hosted marketplace is distinct from a vendor’s central directory listing.
Once installed and discovered in Codex, skills can be selected automatically when a request matches their descriptions. Use “HSE Agent,” “hse-agent,” or “hse agent” as the short name in chat: for example, “Use HSE Agent to synthesize these interview notes and identify the next research question.” These are natural-language requests, not guaranteed commands; the plugin must be installed, enabled and available to that chat. You can also name a skill when you want a particular method. Verify both approaches during setup; automatic selection depends on the request and available skills. Other environments may require choosing an agent or supplying the instructions explicitly.
Models, permissions, connected sources, and tool access differ across environments. The toolkit supplies instructions; your environment supplies those capabilities. Follow the adapter guide to check setup before using the instructions on project work.
Try a bounded task
Use examples/try-it.md in the portable library with its source notes, then compare the response with examples/review-guide.md. The library example above demonstrates the kind of review to perform. Once you can identify supported claims, proposed behavior, and unresolved questions, repeat the exercise with a small set of notes from your own work.
A useful first result is an artifact you can explain and check: what the sources support, what remains uncertain, and what decision comes next. Carry that reviewed artifact into a blueprint or backlog when the task calls for it.
What the public edition contains
The public library contains 20 general-practice skills and two replaceable context skills, along with a task router, adapter guides, a fictional exercise, and review criteria. The router helps select the smallest relevant set of skills for the task. Platform editions package that guidance for their respective clients; your research and project context remain outside the installed package.
The public edition adapts my workplace toolkit for reuse: company-specific context and design-system guidance are replaced with resources you can customize. The catalog below retains the individual skill descriptions so you can choose by the decision or task you need to support.
Explore the public skill library
Browse the three skill groups below and expand a skill to see when it applies. The groups are entry points, not a required sequence: BDX, data feasibility, human factors, and validation can contribute throughout the work.
Discover + frame
What is happening, whose needs matter, and what opportunity should we investigate?
Human-Systems Framing Skill
Frame complex systems around users, roles, workflows, tasks, decisions, information needs, constraints, outcomes, and human-system boundaries.
Reference ID: human-systems-framing
Human-Centered Systems Discovery + Prototyping Skill
Guide a broad discovery-to-prototype engagement spanning human systems, product strategy, workflows, requirements, prototype direction, validation, and delivery implications. Use when the request crosses several phases rather than asking for one specialized artifact.
Reference ID: human-centered-systems-discovery-prototyping
Human-Centered Product Strategy Skill
Frame product opportunity, user and business value, outcomes, prioritization, MVP scope, principles, tradeoffs, assumptions, and roadmap direction. Use when the primary need is product direction rather than an end-to-end discovery engagement or blueprint artifact.
Reference ID: human-centered-product-strategy
UX Research Synthesis Skill
Synthesize research notes, interviews, observations, survey findings, and discovery inputs into themes, needs, insights, and opportunities.
Reference ID: ux-research-synthesis
Workflow & Task Analysis Skill
Analyze workflows, tasks, roles, handoffs, decisions, friction, cognitive load, failure modes, and improvement opportunities.
Reference ID: workflow-task-analysis
BDX Method: Behavior-Driven Experience Skill
Apply BDX to support discovery and inquiry, investigate adoption and interaction concerns, and identify and prioritize evidence-informed improvements to systems and human-computer interactions.
Reference ID: bdx-behavior-driven-experience
Domain Context AdaptationReplaceable context
Adapt analysis to a practitioner-supplied domain profile when industry, roles, operating conditions, terminology, or specialist constraints affect the work.
Reference ID: domain-context-adaptation
Data Availability & Feasibility Skill
Assess data availability, quality, semantic definitions, technical feasibility, gaps, risks, and MVP impact for product experiences.
Reference ID: data-availability-feasibility
Design + decide
What experience should we create, and what reasoning supports it?
Product Experience Blueprinting Skill
Create a Product Experience Blueprint that links users, workflows, value, MVP scope, information needs, risks, assumptions, and validation. Use when the requested outcome is the integrated blueprint artifact.
Reference ID: product-experience-blueprinting
Prototype Direction Skill
Define prototype scope, screens, flows, interaction model, assumptions, fidelity, validation focus, and product decisions to inform.
Reference ID: prototype-direction
Information Design & Decision Support Skill
Design and critique dashboards, KPI displays, status views, information hierarchy, alerts, and decision-support experiences.
Reference ID: information-design-decision-support
Human-System Decision Modeling Skill
Model human-system decisions, inputs, thresholds, uncertainty, accountability, escalation, feedback loops, and decision-support needs.
Reference ID: human-system-decision-modeling
Human Factors Review Skill
Evaluate a product or operational system when workload, error risk, safety, environment, accessibility, trust, recovery, or human performance is central. Use for contextual human-factors analysis rather than a checklist-style interface heuristic review.
Reference ID: human-factors-review
Heuristic Evaluation & Usability Review Skill
Review an existing interface, prototype, dashboard, or workflow against usability heuristics; identify and severity-rank concrete interaction and comprehension issues. Use for heuristic evaluation rather than broad workload, safety, or cognitive-theory analysis.
Reference ID: heuristic-evaluation-usability-review
UX Principles & Cognitive Laws Review Skill
Explain or review a design through selected cognitive and UX principles involving attention, perception, memory, choice, effort, hierarchy, and workload. Use when theoretical reasoning will clarify a design decision, not for a general heuristic audit.
Reference ID: ux-principles-cognitive-laws-review
Deliver + validate
How do we implement, evaluate, and refine the direction?
Product Lifecycle Progress Map
Create and update a Product Lifecycle Progress Map for stakeholder and executive communication, linking lifecycle progress to evidence, ownership, risks and next decisions. Use for living project overviews and lifecycle status reporting, including requests loosely called a project charter; distinguish formal project authorization when needed.
Reference ID: product-lifecycle-progress-map
Requirements Definition Skill
Translate product intent, research, workflow evidence, and constraints into structured product, UX, data, and acceptance requirements. Use when defining what the solution must do; use backlog-story development for delivery-ready Agile or ADO work items.
Reference ID: requirements-definition
Backlog Story Origination & Development Skill
Originate, refine, split, and communicate delivery-ready Agile or Azure DevOps backlog stories with human-centered rationale, implementation notes, and Gherkin acceptance criteria. Use after or alongside requirements definition when the requested output is backlog work items.
Reference ID: backlog-story-origination-development
Validation Planning Skill
Plan validation for usability, comprehension, workflow fit, trust, decision quality, adoption, product value, and implementation risk.
Reference ID: validation-planning
Human-AI Interaction Design Skill
Design human-AI interaction models with roles, review points, confidence, uncertainty, overrides, escalation, governance, and validation.
Reference ID: human-ai-interaction-design
Executive & Team Narrative Skill
Create leadership-ready narratives, strategic summaries, decision framing, status updates, and team alignment communications.
Reference ID: executive-team-narrative
Design System ContextReplaceable context
Apply a practitioner-supplied design system and delivery conventions when defining prototype or UI implementation guidance.
Reference ID: design-system-context
Try the public edition
Install the Human-Systems Engineering Agent for your client, enable it, and start a new chat. Then ask, “Use HSE Agent to…” followed by your task and source material. HSE Agent, hse-agent and hse agent are short names for the same skill set; discovery depends on your client and configuration.
Public v1.0.19 · 22 capabilities · Independent public edition
Codex
Add CD-UX/hse-agent as a plugin marketplace, then install Human-Systems Engineering (plugin ID hse-agent-public).
Download Codex plugin (.zip)158 KiB · SHA-256 checksum
Copilot + VS Code
Add CD-UX/hse-agent as a marketplace and install hse-agent-public@cd-ux-hse-public. In VS Code, enable it for the intended workspace and verify discovery in your selected harness.
Download Copilot + VS Code plugin (.zip)160 KiB · SHA-256 checksum
Claude
Download the Claude ZIP. Open Customize → Plugins → Upload, select the ZIP and enable it. Choose Replace when updating an existing public edition.
Download Claude plugin (.zip)270 KiB · SHA-256 checksum
Full installation instructions · Versioned release and notes
Client availability, permissions and organization policy may differ. Adding our repository marketplace does not imply listing in a vendor’s central directory. No MCP connection or account access is bundled.
Prefer the portable Markdown library?
Use the library for manual adaptation and reference. It is a different archive from the installable platform plugins.
Download portable library (.zip)About 157 KiB · Library checksum
Hosted v1.0.19 installation and payload checks passed in Codex, Copilot and VS Code. Earlier bounded public behavioral tests include Claude v1.0.18; its v1.0.19 branding ZIP has not been separately uploaded and retested. These checks do not cover every capability or possible output. Validation scope and limits.
Written materials: CC BY 4.0. Utility scripts: MIT. Credit Christopher Durgin and indicate changes.
Define your own context
Fill in this editable brief with your users, environment, evidence, vocabulary, constraints and review responsibilities. Save it in your project outside the installed plugin, then attach it to the chat or tell the assistant its path. Ask “Use HSE Agent with this context brief” and confirm which sources it could read.
Download the context brief (.md)Your brief stays separate from plugin updates. Blank fields remain unknowns; supplying a design system does not automatically restyle the HTML renderer. This is project context, not an installable agent.
Foundations & references
My contribution is the toolkit’s selection, orchestration, prompts, and applied methods. The underlying research and frameworks belong to their respective authors. Expand a group to see the sources and limits behind the skills.
I distinguish research findings, design heuristics, and delivery practices in this reference map. Its scope is selected bibliographic records, abstracts, author pages, and accessible texts, checked with AI assistance on October 19, 2026. It is not a systematic review of the literature. Some papers require publisher access. The download includes the map in FOUNDATIONS.md.
Cognitive laws and UX principles
Used by UX Principles & Cognitive Laws Review; also relevant to information design and human-factors reviews.
Hick–Hyman law
Experimental finding
Choice time depends on information and task conditions; fewer options alone does not guarantee a better decision.
Hick (1952), On the Rate of Gain of InformationFitts’s law
Experimental model
Target distance and size inform pointing effort. Check the actual device, users, and task.
Fitts (1954), The information capacity of the human motor systemJakob’s law
Design heuristic
Familiar conventions can help transfer learning; validate conventions against the people and context.
Nielsen (2000), End of Web DesignMiller’s law
Memory research
Support meaningful grouping and recognition. Seven plus or minus two is not a universal menu or screen-item limit.
Miller (1956), The Magical Number Seven, Plus or Minus TwoTesler’s law
Design heuristic
Consider who carries unavoidable complexity. This is a design principle, not a quantified conservation law.
Tesler, The Law of Conservation of ComplexityPeak-end rule
Experimental finding
Review remembered experience as well as task performance. Findings about retrospective ratings do not justify poor experiences elsewhere.
Kahneman et al. (1993), When More Pain Is Preferred to LessVon Restorff effect
Memory research
Distinctiveness can affect recall. Visual salience alone does not ensure attention, comprehension, or correct action.
Hunt (1995), The subtlety of distinctiveness: What von Restorff really didSerial position effect
Memory research
Consider order when recall matters; free-recall results do not establish a universal page-layout rule.
Murdock (1962), The serial position effect of free recallGoal-gradient effect
Behavioral research
Show honest progress toward a user-valued goal. Effects depend on the task and incentive structure.
Kivetz, Urminsky & Zheng (2006), The Goal-Gradient Hypothesis ResurrectedCognitive load
Learning research
Reduce unnecessary processing while preserving information needed for the task; density alone is not a workload measure.
Sweller (1988), Cognitive Load During Problem SolvingSignal detection
Decision theory
Distinguish sensitivity from response criteria and consider misses and false alarms. Operational thresholds require local evidence.
Tanner & Swets (1954), A decision-making theory of visual detection
Usability and interaction foundations
Named in Heuristic Evaluation & Usability Review; mental models also inform cognitive and workflow reviews.
Nielsen’s usability heuristics
Evaluation heuristics
Use the ten heuristics to structure findings, then validate consequential issues with users. A heuristic review does not prove usability or accessibility.
Nielsen, 10 Usability Heuristics for User Interface DesignNorman’s design principles
Design framework
Use conceptual models, signifiers, feedback, mappings, constraints, and error recovery. This credits Norman’s design treatment, not invention of every underlying concept.
Norman, The Design of Everyday Things, revised editionDon’t Make Me Think
Practitioner guidance
Support self-evident navigation, scanning, and clear choices. This is practical guidance rather than a formal cognitive law.
Krug, Don’t Make Me Think, Revisited
Behavior and adoption lenses
Named in BDX; these sources inform individual lenses, not validation of the BDX method or its scoring.
Fogg Behavior Model
Behavior model
Examine motivation, ability, and prompts together. Non-use alone does not reveal which factor is responsible.
Fogg, Fogg Behavior ModelHooked model
Practitioner framework
Consider triggers, action, variable reward, and investment only where they support an ethical, user-valued outcome.
Eyal, Hooked resourcesStatus quo bias
Decision research
Investigate switching costs and preference for existing practice; do not label all resistance irrational.
Samuelson & Zeckhauser (1988), Status quo bias in decision makingLoss aversion
Decision research
Consider reference points and perceived losses. Do not assume a fixed multiplier or use loss framing to pressure users.
Tversky & Kahneman (1991), Loss Aversion in Riskless ChoiceAmbiguity aversion
Decision research
Explore responses to uncertain information rather than assuming everyone avoids every uncertain choice.
Ellsberg (1961), Risk, Ambiguity, and the Savage AxiomsConfirmation bias
Research review
Seek disconfirming evidence and alternative explanations in research and reviews. A suspected bias is a hypothesis, not a diagnosis.
Nickerson (1998), Confirmation Bias: A Ubiquitous Phenomenon in Many Guises
Delivery practices and related reference guidance
Agile and Gherkin are named delivery practices. Human-AI and accessibility references below are supporting guidance, not claims that the toolkit implements a standard in full.
Agile development
Delivery principles
Connect small increments and feedback to intended value. The toolkit does not prescribe a complete Agile framework.
Principles behind the Agile ManifestoGherkin
Specification language
Use Given/When/Then for observable acceptance scenarios; writing scenarios does not mean they have been executed.
Cucumber, Gherkin referenceHuman-AI interaction
Related research guidance
Use capabilities, uncertainty, correction, and control as review topics. This is supporting reading for Human-AI Interaction Design.
Amershi et al. (2019), Guidelines for Human-AI InteractionAccessibility
Related technical standard
Use applicable success criteria and direct testing. Naming WCAG or running an agent review does not establish conformance.
W3C, Web Content Accessibility Guidelines 2.2
Attention, perception, habit, trust, and decision fatigue are broad topics, not single laws. Treat explanations as hypotheses to test in context. PEB and BDX are my applied methods; citing their ingredients does not independently validate the combined methods. Linked works retain their own rights and licenses.
Citation, reuse & author note
This practitioner article draws on my project experience and the sources identified in the text. It has not undergone independent scholarly peer review.
I used AI assistance for drafting, organization, and editorial review. The methods, project accounts, and interpretations reflect my practice, and I retain responsibility for the text. The views expressed are my own.
Durgin, C. (2026). Human-Systems Engineering Agent. Version 1.9, updated 2026-10-29. https://www.chrisdurgin.com/publications/hse-agent
License and reuse
My original article text is licensed under Creative Commons Attribution 4.0 International (CC BY 4.0). You may share and adapt it, including for commercial use, with appropriate credit, a link to the license, and an indication of any changes. Retain supplied attribution and notices, and do not imply my endorsement. Do not add legal or technical restrictions that prevent uses the license permits.
Third-party quotations, images, trademarks, and referenced works retain their own rights and are outside this license unless explicitly stated otherwise. Downloads carry their own license notices; utility scripts use MIT where indicated.
Example attribution
“Human-Systems Engineering Agent” by Christopher Durgin, version 1.9, licensed under CC BY 4.0. Source: original article. If adapted, add a description of your changes.
Revision history
- v1.9 · — Named the Human-Systems Engineering Agent, clarified HSE Agent invocation, and linked public v1.0.19 platform packages, hosted installation guidance, checksums and validation scope.
- v1.8 · — Added the Product Lifecycle Progress Map to the 22-skill public kit, neutral HTML presentation, portable Claude guidance and edition-specific testing notes.
- v1.7 · — Added consistent CC BY 4.0 licensing, reuse scope, attribution guidance, and machine-readable license metadata for the original article text; refined contextual links to related methods.
- v1.6 · — Clarified the library example, reduced repeated setup and review guidance, explained terminology, and corrected article revision metadata.
- v1.5 · — Clarified the human-led insight-to-decision purpose and practitioner augmentation; grouped the public skill catalog around discovery, design, and delivery.
- v1.4 · — Refined reader flow, context adaptation, skill handoffs, and public-resource guidance.
- v1.3 · — Recorded Google Sheets and HSE environment smoke tests and updated compatibility guidance.
- v1.2 · — Aligned navigation and reading order, streamlined application guidance, and clarified evidence language.
- v1.1 · — Synchronized public resources and refined article flow and references.
- v1.0 · — First reader edition, with field accounts, practical examples, and reusable resources.