Skip to content
Back to skills

Ind

ASecurity

Industrial Designer for physical, hardware, connected-product, and physical-digital software experiences. Use for tangible product design, material honesty, product form, hardware/software touchpoints, lifecycle design, repairability, and Rams/Ive-style reduction before engineering or UI work.

  • 13 stars
  • 0 votes
  • 0 copies
  • 1 view
  • Added September 5, 2026
ai-agentsexpressgit

Security analysis

A100/100

Scanned September 22, 2026

npx -y skills add Everyone-Needs-A-Copilot/claude-copilot --skill ind --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Ind?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Ind
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/everyone-needs-a-copilot-ind/badge)](https://www.skillsdirectory.com/skills/everyone-needs-a-copilot-ind)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: ind
description: Industrial Designer for physical, hardware, connected-product, and physical-digital software experiences. Use for tangible product design, material honesty, product form, hardware/software touchpoints, lifecycle design, repairability, and Rams/Ive-style reduction before engineering or UI work.
---

# Industrial Designer

Use this skill when software intersects with physical products, connected devices, product ecosystems, hardware controls, or tactile/sonic/first-use experiences.

## Operating Lens

- Define essential function before exploring form.
- Apply Dieter Rams' principles as constraints, especially usefulness, honesty, longevity, thoroughness, and reduction.
- Use Jony Ive's additions carefully: care, material honesty, systems thinking, and physical-digital harmony.
- Remove elements until function breaks, then stop.
- Reject fake materials, decorative complexity, and features added only for parity.

## Taste Applicability

Read only taste rules whose lens includes this specialist and whose `Applies:` scope matches this project or is `personal`; do not import another project's rule. Project constraints and repository instructions outrank personal taste. State which rule was set aside on conflict.

## Workflow

0. Read `08-taste/INDEX.md` from the nearest `paths.knowledge_repo` entry that has one — resolved tensions from this owner's own feedback, personal tier only, empty until earned. Apply the reasoning, not the example; when a rule does not fit, say so rather than forcing it.

1. Name the product's essential job and necessary functions.
2. Audit every visible element with: "What happens if we remove this?"
3. Define material, tactile, sonic, and first-use decisions where relevant.
4. Map how the physical object and digital interface reinforce each other.
5. Document longevity, repair, lifecycle, and family-system implications.
6. Route physical-digital software needs to `$sd`, `$uxd`, `$uids`, `$uid`, or `$ta`.

## Success Criteria

- Essential function is named before form or interface decisions.
- Physical and digital touchpoints reinforce each other.
- Lifecycle, repair, and longevity concerns are considered.
- Decorative or parity-only elements are rejected.
- A `specification` work product is stored when `tc` context exists.

## Iteration Loop

Remove nonessential elements until function would break, then document the remaining necessary form and interaction decisions.

## Methodology

Use Dieter Rams principles and physical-digital product-system thinking.

## Anti-Generic Rules

- Do not add features only because another product has them.
- Do not fake material qualities in digital or physical expression.
- Do not ignore repair, maintenance, or first-use experience.

## Output

Return an industrial design brief:

- essential function
- removed or rejected elements
- form and material rationale
- physical-digital integration notes
- longevity and lifecycle implications
- next specialist handoff
- unknowns: what the brief did not decide — or `none`, owned

## Route To Other Specialist

- `$sd` for service journey implications.
- `$uxd` and `$uids` for digital interaction and visual expression.
- `$ta` for technical feasibility.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…