HIG Driven

Human-driven interfaces, inspired by Apple.

HIG Driven is an unofficial Codex skill for planning, building, refactoring, and auditing web or app interfaces with principles distilled from Apple's public Human Interface Guidelines and design sessions.

It turns a large design corpus into a practical decision system: clarify the purpose, organize the experience, choose familiar patterns, protect user agency, design complete states, implement accessibly, and verify the result.

HIG Driven is not an iOS skin, a Liquid Glass generator, a component library, a complete Apple API reference, or a claim of Apple certification.

Status: release candidate [email protected]; the repository includes the upgraded runtime bundle and end-to-end package checks.

Table of contents

• Why HIG Driven
• What it does
• How it works
• Modes
• Installation
• Quick start
• Step-by-step workflows
• With and without HIG Driven
• Portfolio screenshot head-to-head
• Knowledge architecture
• Corpus and curation
• Repository structure
• CLI reference
• Validation and testing
• Limitations
• FAQ
• Contributing
• License
• Disclaimer

Why HIG Driven

Requests such as "make this feel like Apple" often produce shallow visual imitation: translucent cards, large corner radii, monochrome surfaces, or unnecessary product-page animation.

Apple's design philosophy is broader than appearance. It emphasizes:

• a meaningful purpose;
• user control and recoverability;
• responsible handling of data and risk;
• familiar concepts and platform conventions;
• flexibility across people, devices, languages, and inputs;
• clarity without removing useful capability;
• careful execution and iteration;
• delight that emerges from the whole experience.

HIG Driven gives an agent a repeatable workflow for applying those principles without blindly copying iOS styling.

What it does

HIG Driven can help an agent:

• turn a product idea into a concrete design contract;
• define information architecture and navigation;
• distinguish destinations, actions, selection, and disclosure;
• establish visual hierarchy before decoration;
• select components by semantic purpose;
• define loading, empty, success, error, offline, permission, and recovery states;
• translate Apple design principles into semantic web implementation;
• adapt a shared product experience for Apple platforms;
• improve labels, instructions, empty states, errors, voice, and tone;
• inspect accessibility, focus, alternate input, contrast, motion, and localization;
• implement or refactor within an existing codebase;
• audit a design or implementation using severity-ranked findings;
• connect important recommendations to official Apple sources.
• reason about AI, account, payment, identity, system-surface, collaboration, media, spatial, health, and other risk-sensitive flows only when relevant;
• distinguish verified facts, assumptions, unknowns, and evidence limits before making a recommendation.

How it works

User request or existing artifact
            |
            v
Infer platform, product goal, user goal, and scope
            |
            v
Choose Guide, Build/Refactor, Audit, or a combined flow
            |
            v
Load the core principles plus only relevant references
            |
            v
Purpose -> Structure -> Orientation -> Patterns -> Hierarchy
            |
            v
States -> Agency -> Accessibility -> Personality -> Validation
            |
            v
Evidence-backed result with acceptance criteria

The skill always loads its compact core principles. It then uses progressive disclosure to load only the references relevant to the request. A web audit does not need watchOS guidance; a writing task does not need every component document.

The three orientation questions

Every important surface should quickly answer:

1. Where am I?
2. What can I do?
3. Where can I go next?

If one of these is unclear, HIG Driven treats it as a structural problem before treating it as a styling problem.

The eight-principle lens

| Principle | Practical question | | --- | --- | | Purpose | What meaningful human outcome does this experience serve? | | Agency | Can people act, change their mind, and recover safely? | | Responsibility | What could cause harm, confusion, coercion, or loss of trust? | | Familiarity | Which existing concepts and platform behaviors should transfer? | | Flexibility | Does the experience adapt to real people and contexts? | | Simplicity | What can disappear, combine, default, or move behind disclosure? | | Craft | Which unfinished detail could make the product feel unreliable? | | Delight | Does the personality reinforce the task and intended emotion? |

Modes

Guide

Use Guide mode before implementation. It produces a design contract rather than a vague mood board.

Expected output:

• product purpose and primary user job;
• information architecture;
• navigation model;
• primary, secondary, and destructive actions;
• content hierarchy and component choices;
• state and recovery matrix;
• responsive or platform behavior;
• accessibility and writing requirements;
• testable acceptance criteria.

Example:

$hig-driven Design a responsive personal-finance dashboard before coding.
The user should understand monthly spending, review unusual transactions,
and create a budget.

Build/Refactor

Use Build/Refactor mode when an implementation already exists or the user asks the agent to create one.

The skill instructs the agent to:

1. inspect the current stack and conventions;
2. preserve user-owned changes and existing product identity;
3. implement the requested scope;
4. use native platform semantics before custom simulation;
5. verify every link, button, route, handler, and state;
6. test responsive/adaptive and alternate-input behavior;
7. run an audit quality gate after implementation.

It explicitly rejects placeholder href="#" values, missing fragment targets, inert buttons, undefined handlers, and unsupported claims that an interaction was tested.

Example:

$hig-driven Refactor the settings page in this project. Preserve the current
framework and brand, implement the changes, and audit the final result.

Audit

Use Audit mode for a screenshot, design, running interface, user flow, or source code.

Findings use four levels:

| Severity | Meaning | | --- | --- | | Blocker | Prevents completion, access, understanding, safety, or recovery | | High impact | Creates recurring confusion, weak hierarchy, loss of agency, or major inconsistency | | Medium | Adds friction but leaves the task usable | | Polish | Improves craft after structural issues are fixed |

Each finding contains:

1. an evidence-based observation;
2. the user impact;
3. the relevant design principle;
4. a concrete recommendation;
5. testable acceptance criteria;
6. an official source when Apple guidance materially supports it.

Example:

$hig-driven Audit this checkout flow. Prioritize only the issues that materially
affect completion, trust, accessibility, or recovery.

Installation

Install from GitHub today

git clone https://github.com/dzakwanfadhlullah/HIG-Driven.git
cd HIG-Driven
npm install
node bin/hig-driven.mjs install

The installer copies the bundled skill to:

$CODEX_HOME/skills/hig-driven

If CODEX_HOME is not configured, it uses:

~/.codex/skills/hig-driven

On Windows this normally resolves to:

C:\Users\<username>\.codex\skills\hig-driven

Open a new Codex session after installation so the skill can be discovered.

Install to a custom skills directory

node bin/hig-driven.mjs install --target /path/to/skills

The CLI always creates a hig-driven directory inside the target skills directory.

Replace an existing installation

The installer refuses to overwrite an existing skill by default.

node bin/hig-driven.mjs install --force

--force replaces only the resolved hig-driven skill directory.

npm registry installation

The package is available from the public npm registry. The intended user flow is:

npm install hig-driven
npx hig-driven install

The second command activates the skill in the user's Codex skills directory. Keeping activation explicit avoids an npm dependency install unexpectedly modifying a user's home directory.

Maintainer publish

For future releases, a maintainer with access to the npm account can publish a new version with:

npm login
npm publish --access public

Future releases only require bumping the version and running npm publish again.

Quick start

Invoke the skill explicitly with $hig-driven:

$hig-driven Help me define the information architecture for this SaaS dashboard.

$hig-driven Refactor this React onboarding flow and audit the implementation.

$hig-driven Audit this iOS settings screen for hierarchy, component choice,
Dynamic Type, VoiceOver, and recovery.

The metadata also supports implicit invocation when a request clearly involves UI/UX planning, interface implementation, component semantics, accessibility, motion, UX writing, Apple-platform adaptation, or design auditing.

Step-by-step workflows

Plan a new interface

1. Describe the product, intended audience, platform, and primary job.
2. State important constraints such as financial risk, privacy, localization, or supported inputs.
3. Ask for Guide mode or a design contract.
4. Review the proposed information architecture and action hierarchy.
5. Confirm assumptions the agent could not verify.
6. Use the acceptance criteria as the implementation checklist.

Suggested prompt:

$hig-driven Create a design contract for a mobile medication reminder.
Separate verified requirements from assumptions. Include safety, notification,
permission, missed-dose, offline, and recovery states.

Refactor an existing website or application

1. Run Codex from the project workspace.
2. Identify the page, flow, or component to change.
3. State what must remain unchanged.
4. Ask HIG Driven to implement, not only recommend.
5. Require the available tests and a final audit.
6. Review any limitation the agent could not verify at runtime.

Suggested prompt:

$hig-driven Refactor the billing page in this repository. Preserve the framework,
API contracts, and brand tokens. Fix navigation/action semantics, complete all
states, test keyboard behavior, and audit the result.

Audit an existing experience

1. Provide a screenshot, source path, local URL, or clearly described flow.
2. State the target platform and primary user task.
3. Ask for evidence-backed findings rather than a generic score.
4. Fix Blockers and High-impact findings first.
5. Re-run the audit after implementation.

Suggested prompt:

$hig-driven Audit this checkout screen. Do not invent hidden runtime behavior.
Label anything that cannot be observed as "verify". Give acceptance criteria
for every Blocker and High-impact finding.

Translate Apple principles to the web

1. Identify the product goal and established web conventions.
2. Ask HIG Driven to use semantic HTML, native controls, URLs, browser history, keyboard interaction, and preference queries.
3. Do not ask it to recreate an iOS screen literally.
4. Verify responsive reflow, zoom, focus, reduced motion, and error routes.

Suggested prompt:

$hig-driven Apply Apple design thinking to this web app without making it look
like an iOS clone. Preserve web conventions and explain every platform translation.

With and without HIG Driven

The comparison below describes the workflow HIG Driven is designed to encourage. It is not a claim that every model response without the skill will behave identically.

| Concern | Generic UI request without the skill | Request using HIG Driven | | --- | --- | --- | | Starting point | May begin with layout or visual style | Begins with product purpose and the person's primary outcome | | Apple influence | May imitate rounded cards, glass, or typography | Applies principles while preserving platform conventions | | Information architecture | Often implicit | Explicitly inventories, groups, and prioritizes tasks/content | | Navigation | May mix important actions with destinations | Separates navigation, actions, selection, and disclosure | | Action hierarchy | May style several actions as equally primary | Identifies primary, secondary, contextual, and destructive actions | | States | May cover only the happy path | Inventories applicable loading, empty, partial, success, error, offline, permission, and recovery states | | Agency | May add confirmation dialogs indiscriminately | Prefers cancellation, undo, preserved work, and proportionate safeguards | | Accessibility | May appear as a final checklist | Influences structure, component choice, labels, focus, input, contrast, and motion | | Web behavior | May simulate native-app patterns | Preserves semantic HTML, URLs, browser history, keyboard, and focus behavior | | Audit output | May provide broad aesthetic opinions | Uses evidence, severity, user impact, concrete fixes, and acceptance criteria | | Sources | Recommendations may be unattributed | Links narrow, relevant official Apple sources when applicable | | Verification | May say a page is complete after source edits | Distinguishes source, rendered, and runtime verification |

HIG Driven is deliberately evidence-aware: a screenshot cannot prove keyboard behavior, route resolution, focus management, or recovery. Those items are reported as Verify until the relevant artifact or runtime state is exercised.

Illustrative difference

Without a structured design skill, a response to "make this dashboard feel like Apple" might concentrate on:

• a gray background;
• rounded cards;
• an Apple-like blue accent;
• blur and shadows;
• large typography.

HIG Driven instead asks:

• What is the dashboard's primary human outcome?
• Which content deserves immediate attention?
• Are actions presented as actions rather than navigation?
• Can a person understand the current state and next step?
• What happens when data is loading, missing, stale, offline, or wrong?
• Can the task be completed with alternate inputs and assistive technology?
• Does visual personality support the product rather than imitate Apple?

Portfolio screenshot head-to-head

This is a visual comparison using the same portfolio brief and three implementations:

1. HIG Driven.
2. ai-ui-design-skills:ui-ux-design-system.
3. GPT-5.6, medium reasoning, without a design skill.

The screenshots are evidence of layout, content hierarchy, visual language, and visible form states. They do not by themselves prove keyboard behavior, semantic HTML, focus management, reduced motion, responsive reflow, link destinations, or runtime form behavior. Those require source and runtime verification.

Visible strengths: the page connects problem, product, process, and contact; primary and secondary actions are differentiated; unavailable project and testimonial details are marked as placeholders; and the contact form visibly includes an error state.

Tradeoff: the large headlines and strong white–black–purple section changes create personality, but several sections compete to be the visual anchor. The process section may receive more attention than the selected work.

Visible strengths: the most systematic result of the three; spacing, card treatment, blue accent, form styling, and project rows are highly consistent and easy to scan. The contact area includes a visible success message.

Tradeoff: the system is polished but leans toward a familiar premium SaaS pattern. Its consistency reduces visual risk, while also making the portfolio feel less distinctive than the other two results.

Visible strengths: the strongest editorial personality; serif typography, warm surfaces, and the writing create a memorable point of view. The page still has a clear project, process, proof, and contact sequence.

Tradeoff: the editorial treatment makes the large headlines the dominant experience. Supporting copy and metadata are comparatively quiet, and the screenshot does not show the explicit state coverage visible in the first two results.

Head-to-head reading

| Dimension | HIG Driven | UI/UX Design System | No design skill | | --- | --- | --- | --- | | Primary contribution | Human outcome and product narrative | System consistency and scanability | Editorial personality and craft | | Information architecture | Problem → work → thinking → process → proof → contact | Work → about → process → proof → contact | Work → about → process → proof → contact | | Content integrity | Explicit placeholder and unverified-content treatment | Explicit placeholder treatment | Mostly restrained, but fewer visible state cues | | Action hierarchy | Clear work and conversation paths | Clear and consistently styled | Clear, with more editorial emphasis | | State evidence in screenshot | Contact error state | Contact success state | No visible form state | | Visual cohesion | Intentional but more segmented | Strongest system cohesion | Strongest distinctive art direction | | Main risk | Competing anchors and high section contrast | Generic premium-SaaS feel | Oversized editorial type and quiet supporting text |

What this says about HIG Driven

The first result represents the corpus as a reasoning system, not as an Apple visual skin. The visible signals are purpose-first copy, meaningful sequence, differentiated actions, honest placeholders, and attention to a non-happy form state. It deliberately avoids defaulting to Liquid Glass, iOS controls, or Apple-like decoration.

The comparison does not establish that HIG Driven always produces the most attractive screenshot. The other two results are strong because the underlying model is capable and because the portfolio brief itself already requested responsive behavior, semantic HTML, accessibility, states, and no invented facts. That means the original prompt reduced the visible difference between conditions.

For a fairer follow-up benchmark, keep the model, viewport, codebase, and brief constant, but remove implementation checklists such as accessibility, reduced motion, and state requirements from the baseline prompt. Then compare both screenshots and source/runtime evidence for:

• purpose and orientation;
• heading and reading order;
• real link and button behavior;
• keyboard and focus behavior;
• loading, empty, error, and success states;
• responsive reflow and text enlargement;
• reduced-motion behavior;
• content integrity and placeholder handling.

The intended conclusion is not that HIG Driven wins a beauty contest. Its value is that it makes the agent explain and validate the decisions that make an interface understandable, adaptable, recoverable, and trustworthy.

Knowledge architecture

The runtime skill is intentionally small and uses progressive disclosure.

| Reference | Used for | | --- | --- | | core-principles.md | Purpose, agency, responsibility, familiarity, flexibility, simplicity, craft, delight | | design-process.md | Framing, information architecture, state modeling, implementation order | | visual-design.md | Hierarchy, layout, typography, color, imagery, materials | | navigation-components.md | Navigation, action semantics, forms, menus, sheets, disclosure | | accessibility-inclusion.md | Inclusive behavior, alternate input, privacy, safety, recovery | | motion-feedback.md | Loading, status, errors, progress, motion, haptics | | content-ux-writing.md | Voice, tone, labels, empty states, errors, permissions | | web-translation.md | Semantic HTML, focus, responsive behavior, browser conventions | | apple-platforms.md | iOS, iPadOS, macOS, watchOS, tvOS, visionOS adaptation | | platform-touch-desktop.md | iOS, iPadOS, and macOS differences in input, windowing, navigation, and density | | platform-wearable-spatial.md | watchOS, tvOS, and visionOS focus, glanceability, comfort, and exit behavior | | ai-intelligent-features.md | AI value, transparency, uncertainty, privacy, agency, and model failure | | accounts-commerce-trust.md | Account lifecycle, sign-in, purchase, payment, identity, and recovery | | input-and-adaptation.md | Touch, keyboard, pointer, stylus, voice, gaze, remote, controller, and alternate input | | system-surfaces.md | Widgets, Live Activities, notifications, shortcuts, App Clips, and glanceable status | | collaboration-sharing.md | Shared context, roles, permissions, conflicts, and synchronized state | | media-spatial.md | Audio, video, capture, AR, immersive, spatial, and comfort behavior | | sensitive-domains.md | Health, research, home, location, identity, and safety-sensitive integrations | | specialized-components.md | Less-common controls, panels, selection patterns, status, and data display | | use-case-playbooks.md | Marketing, SaaS, commerce, AI, and creation-tool lenses | | verification-protocol.md | Evidence ladder, interaction checks, state applicability, adaptation, and verification receipt | | audit-playbook.md | Evidence collection, severity, findings, quality gates | | source-index.md | Provenance and links to official Apple sources |

The main SKILL.md contains routing and workflow instructions. Detailed knowledge remains in references/ and is loaded only when relevant.

Corpus and curation

HIG Driven was created from a local research corpus of 197 documents, including Human Interface Guidelines pages, official design pages, and selected WWDC design transcripts.

Every document was processed through a curation ledger:

| Disposition | Documents | Treatment | | --- | ---: | --- | | Core | 24 | Used across the primary distilled references | | Supporting | 61 | Used for navigation, interaction, visual guidance, or examples | | Conditional | 91 | Retained for relevant Apple platforms, technologies, or specialized components | | Index/tool entry | 8 | Kept as official entry points, not loaded as reasoning material | | Excluded from reasoning | 13 | Removed because they were taxonomy-only, duplicated catalogs, or broad news noise |

The full audit trail is available in:

• maintainer/curation-summary.md
• maintainer/curation.json
• maintainer/source-coverage.md

Why the raw corpus is not published

The raw and normalized Apple corpus is intentionally excluded from Git and the npm package because:

• large volumes of source text would create context noise;
• most requests need only a small subset of the guidance;
• publishing copied source material creates avoidable copyright and maintenance concerns;
• a stable skill should contain concise, original paraphrases and source links;
• maintainer data and user runtime data have different purposes.

The repository contains the scraper and curation tooling so maintainers can refresh the private research corpus and regenerate its audit ledger.

Repository structure

HIG-Driven/
├── bin/
│   └── hig-driven.mjs              # Installer and doctor CLI
├── maintainer/
│   ├── curation.json               # Per-document curation ledger
│   └── curation-summary.md         # Human-readable corpus summary
├── scripts/
│   ├── sync-apple-sources.mjs      # Source synchronization
│   ├── curate-corpus.mjs           # Classification and curation
│   ├── verify-corpus.mjs           # Corpus integrity checks
│   └── verify-skill.mjs            # Skill, link, and provenance checks
├── skills/
│   └── hig-driven/
│       ├── agents/openai.yaml      # Codex-facing metadata
│       ├── references/             # Progressively loaded knowledge
│       └── SKILL.md                # Runtime workflow and routing
├── LICENSE
├── package.json
└── README.md

The repository also contains maintainer-only evals/ cases, tests/verify-evals.mjs, and tests/package-e2e.mjs. The ignored corpus/ directory exists only in the maintainer workspace after synchronization. It is not included in source control or package output.

CLI reference

Show help

node bin/hig-driven.mjs --help

Validate the bundled skill

node bin/hig-driven.mjs doctor

doctor validates every bundled reference, internal link, Unicode marker, and bundle digest. To verify that the active Codex installation has not drifted from the package:

node bin/hig-driven.mjs doctor --installed

Print the bundled skill path

node bin/hig-driven.mjs path

Install

node bin/hig-driven.mjs install

Options:

--target <skills-directory>   Install under a custom skills directory
--force                       Replace an existing hig-driven installation

After installation, doctor --installed compares the active skill's content digest with the bundled package and reports drift instead of silently accepting a partial or stale copy.

The CLI has zero runtime dependencies in the packed package.

Validation and testing

Run the public repository test suite

npm test

This runs:

1. skill structure and internal-link verification;
2. the maintainer forward-test matrix and known broken-interface regression fixture;
3. bundled-skill health checks;
4. the provenance guard when a local corpus is available.

This command works from a normal public clone without the private research corpus.

Run maintainer corpus tests

After synchronizing the ignored local corpus, run:

npm run test:corpus

This performs corpus integrity and hash verification, then rebuilds the curation ledger for all 197 documents.

Run every public and corpus test with:

npm run test:all

The full command also performs an npm pack → consumer install → skill activation → installed doctor test. The forward-test cases are prompts and rubrics for model evaluation; they are intentionally kept out of the runtime package.

Validate only the skill

npm run verify:skill

Check the freshness of official links when network access is available:

npm run verify:links
npm run verify:links -- --strict

HTTP failures fail the command. Temporary network failures are reported as warnings unless --strict is used.

Inspect the npm package

npm pack --dry-run

Current package characteristics:

• zero runtime dependencies;
• runtime dependencies are not required by the installed skill;
• raw corpus excluded;
• installer overwrite protection;
• full reference reachability and curation coverage checks;
• installed-bundle digest verification.

Forward testing performed

The skill was exercised with independent prompts for:

• a Guide-mode personal-finance dashboard;
• an Audit-mode billing interface;
• a Build/Refactor-mode static project dashboard.

The first Build/Refactor test exposed dead fragment links. The skill was tightened to reject placeholder destinations, inert controls, missing targets, and undefined handlers. A second source/DOM pass completed with no dead fragments or undefined handlers.

Rendered browser verification depends on an available browser surface and must be reported separately from source/DOM verification.

Limitations

• HIG Driven does not guarantee App Store acceptance or formal standards compliance.
• It does not replace user research, usability testing, accessibility testing with real users, legal review, security review, or domain experts.
• It is not a complete SwiftUI, UIKit, AppKit, watchOS, tvOS, or visionOS API reference.
• Web-specific guidance is an explicit HIG Driven translation of Apple principles, not official Apple web documentation.
• Results still depend on the model, available tools, quality of the supplied context, and whether rendered/runtime verification is possible.
• Apple guidelines and platform behavior evolve; maintainers must periodically refresh and review the corpus.
• The skill does not bundle Apple artwork, fonts, SF Symbols, templates, or copyrighted screenshots.

FAQ

Is HIG Driven an official Apple project?

No. HIG Driven is an independent, unofficial project and is not affiliated with or endorsed by Apple Inc.

Does it make every website look like an Apple website?

No. The skill explicitly discourages visual imitation without product justification. A high-quality web interface should preserve web conventions, the product's identity, and the needs of its users.

Is this a UI kit or component library?

No. HIG Driven is a reasoning and workflow skill. It can guide component selection or help an agent implement components in an existing project, but it does not ship a visual component library.

Can it write or modify code?

Yes. Build/Refactor mode instructs the agent to inspect the existing project, implement the requested scope, verify controls and states, and perform an audit. Actual capabilities depend on the coding agent and tools available in the session.

Can I use it only for audits?

No. Audit is one of three modes. Guide mode supports work before coding, and Build/Refactor mode supports implementation followed by an audit quality gate.

Does it work for websites?

Yes. The web adapter translates the underlying principles into semantic HTML, native controls, keyboard and focus behavior, responsive reflow, browser history, URL semantics, preference queries, and complete application states.

Does it work for Apple-platform apps?

Yes, for design direction and platform adaptation. Use current official SDK documentation for implementation APIs.

Does it guarantee that a design is HIG compliant?

No. HIG Driven avoids the phrase "HIG compliant." It reports which principles and checks a design satisfies and which areas still need verification.

Why does the audit avoid a numeric score?

A single score can hide the difference between a blocked task and minor visual polish. The default severity model makes prioritization and remediation clearer. A numeric score can still be produced if explicitly requested.

Why are Apple source pages not bundled into the package?

The runtime skill needs distilled guidance, not a multi-megabyte source archive. Excluding the corpus reduces noise, package size, legal risk, and maintenance cost.

Are recommendations copied directly from Apple?

The skill references are original paraphrases with official source links. The verifier also checks for accidental long verbatim overlap with the maintainer corpus.

Does the skill require network access at runtime?

The installed skill references are local. Network access may still be necessary when the agent needs current SDK documentation, external project dependencies, a remote application, or official sources beyond the bundled distillation.

How do I update an installed copy?

Pull the latest repository version, install dependencies, validate it, and reinstall with --force:

git pull
npm install
npm test
node bin/hig-driven.mjs install --force

How do I install it from npm?

Install the published package and activate the skill with:

npm install hig-driven
npx hig-driven install

Contributing

Contributions should preserve the project's core boundaries:

• prioritize human outcomes over visual imitation;
• keep SKILL.md concise and route detail through references;
• distinguish Apple guidance, HIG Driven interpretation, and project-specific judgment;
• paraphrase source material and link to official sources;
• avoid bundling Apple artwork or the raw research corpus;
• add testable acceptance criteria to new audit rules;
• run npm test before submitting changes.

Suggested contribution workflow:

git clone https://github.com/dzakwanfadhlullah/HIG-Driven.git
cd HIG-Driven
npm install
npm test

For changes to the source corpus or curation logic:

npm run sync
npm run test:all

License

HIG Driven's original source code and distilled skill content are available under the MIT License.

The MIT License allows use, copying, modification, distribution, sublicensing, and commercial use, provided that the copyright and permission notice are retained.

The license applies only to this project's original work. It does not grant rights to Apple trademarks, copyrighted source material, artwork, fonts, SF Symbols, templates, or other third-party assets.

Disclaimer

HIG Driven is not affiliated with, endorsed by, sponsored by, or certified by Apple Inc.

Apple, Human Interface Guidelines, Apple platform names, SF Symbols, SwiftUI, and related marks or materials belong to their respective owners. References to Apple resources are provided for attribution and educational context.