Industrial Design Portfolio

Industrial Design Portfolio

Build a portfolio that proves design judgment, not merely visual taste. Treat every page as part of an evidence chain from problem to decision to result.

Cross-agent runtime contract

Use SKILL.md as the canonical instruction source. Do not assume a specific vendor, model, tool name, shell, home directory, or interactive-question API.

At activation, detect capabilities rather than platform branding:

• If an interactive question tool exists, use it only for decisions that materially change the portfolio; otherwise ask in plain chat.
• If file tools exist, copy and edit the bundled template with native read/write/patch operations.
• If shell execution exists, run the validator with an available Python 3 command.
• If browser or computer-use tools exist, visually preview the deck; otherwise complete structural validation and state that visual preview remains pending.
• If image generation exists, use it only under references/image-policy.md; otherwise preserve image slots and continue with supplied assets or placeholders.
• If web access exists, verify time-sensitive market, material, manufacturing, patent, and cost claims; otherwise label them unverified.
• If a capability is unavailable, continue with the highest-value safe subset instead of failing the whole workflow.

Resolve bundled paths relative to the directory containing this SKILL.md. Never rely on $CLAUDE_PLUGIN_ROOT, $CODEX_HOME, or another platform-specific variable during portfolio creation. Read [references/platform-compatibility.md](references/platform-compatibility.md) when installing, packaging, debugging discovery, or choosing fallbacks.

Operating contract

• Preserve user-provided facts, images, measurements, brands, and authorship.
• Never invent interviews, test participants, dimensions, costs, patents, CAD validation, manufacturing feasibility, or project outcomes.
• Mark unverified content as Assumption, Concept estimate, or To validate.
• Mark AI-generated imagery visibly as AI-assisted concept visualization; never present it as a prototype, CAD model, test record, or production evidence.
• Separate design intent from engineering proof. A generated exploded image is explanatory artwork, not a manufacturable drawing.
• Prefer one clear decision per page. Remove decorative content that does not support the case.

Select the task mode

| User intent | Mode | Default result | |---|---|---| | Build one case study | Single project | 12-18 pages | | Build a complete portfolio | Multi-project | 20-36 pages, 2-4 projects | | Improve an existing portfolio | Audit and rebuild | Findings + revised deck | | Prepare for an interview/review | Presentation cut | 8-15 pages | | Organize incomplete materials | Evidence planning | Asset inventory + gap plan |

If the user has not specified audience or format, make reasonable assumptions and state them. Ask only when the choice materially changes the result.

Read references selectively

• Read [references/story-architecture.md](references/story-architecture.md) when planning page order, project selection, or narrative.
• Read [references/industrial-design-evidence.md](references/industrial-design-evidence.md) before making research, engineering, manufacturing, test, or impact claims.
• Read [references/layouts.md](references/layouts.md) before writing HTML. Use only registered layout IDs. For ID01, ID03, ID08, ID10, ID13, ID14, and ID16, prefer the selected system's fragment under assets/compositions//; otherwise start from assets/layouts/.
• Read [references/style-presets.md](references/style-presets.md) when offering, selecting, or customizing a portfolio visual system.
• Read [references/visual-system.md](references/visual-system.md) when selecting theme, typography, color, image treatment, or page rhythm.
• Read [references/image-policy.md](references/image-policy.md) before generating or substantially editing any visual.
• Read [references/checklist.md](references/checklist.md) for the final review and severity model.
• Read [schemas/portfolio-manifest.schema.json](schemas/portfolio-manifest.schema.json) before creating or substantially editing portfolio_manifest.json.
• Read [references/platform-compatibility.md](references/platform-compatibility.md) for platform discovery paths, installation, adapter files, and capability fallbacks.

Workflow

1. Establish the review target

Capture or infer:

• audience: employer, school, client, jury, or internal review;
• discipline emphasis: form/CMF, research, interaction, engineering, manufacturing, or strategy;
• presentation context: self-read, live talk, PDF export, or web review;
• page/time constraint;
• confidentiality and redaction rules;
• authorship: individual responsibilities versus team contributions;
• visual direction: one registered visual system, inferred from the flagship evidence when the user has no preference.

Copy assets/portfolio_manifest.example.json to the project output as portfolio_manifest.json, then write these decisions into it. Preserve its schema version and record uncertainty rather than deleting required fields.

Choose one system from references/style-presets.md for the full deck. Recommend it in designer-facing language—Workshop, Instrument, Material, or Gallery—based on what the reviewer should believe first. Do not force the user to interpret raw preset IDs. Treat the system as a composition decision, not a substitute for story or evidence. Record its backward-compatible style_preset ID and one-sentence rationale in the manifest.

2. Audit source material before designing pages

Inventory every supplied artifact with:

{
  "file": "images/prototype-02.jpg",
  "type": "prototype_photo",
  "project": "Project Name",
  "evidence_level": "E2",
  "authorship": "Designed and photographed by applicant",
  "caption": "Second foam prototype used for grip testing",
  "allowed_edits": "crop_color_only",
  "status": "ready"
}

Classify evidence using E0-E3 from industrial-design-evidence.md. Do not start visual production until essential gaps are recorded. Missing evidence may become an honest placeholder or omission, never a fabricated result.

3. Choose projects and define each case thesis

For every project, write one sentence:

> For [user/context], I changed [product behavior/form/system] by [key design decision], demonstrated through [strongest evidence].

Keep projects only when they add a distinct capability. In a multi-project portfolio, avoid three projects that all prove the same skill.

4. Build three planning tables

Create these before HTML:

1. Evidence map: claim -> supporting artifact -> confidence -> gap.
2. Story table: page -> question answered -> key message -> evidence.
3. Layout plan: page -> registered IDxx layout -> theme -> image slots -> reason.

Do not choose layouts merely for variety. Match the layout to the shape of the evidence.

5. Synthesize five design lenses

Cover only lenses supported by the project:

1. User and context: need, behavior, environment, accessibility.
2. Industrial design and CMF: form language, proportions, touchpoints, materials, finish.
3. Product architecture: mechanism, assembly, serviceability, hardware/software boundary.
4. Manufacturing and viability: process, tooling, tolerance intent, cost assumptions, lifecycle.
5. Differentiation and learning: alternatives, trade-offs, testing, iteration, result.

These are analysis lenses, not fictional specialist opinions. Tie every conclusion to evidence or label it as an assumption.

6. Create the HTML deck

Resolve the skill root from the current SKILL.md, then copy /assets/portfolio-template.html to the project output as index.html. Create an adjacent images/ directory. Replace:

• [PORTFOLIO_TITLE]
• [DESIGNER_NAME]
• [PORTFOLIO_META]
• [STYLE_PRESET]
• ``

Every slide must include:

  ...

For ID01, ID03, ID08, ID10, ID13, ID14, and ID16, copy the matching /assets/compositions//IDxx.html recipe when it exists. These recipes share the same evidence fields but intentionally use different page skeletons. For every other page, copy /assets/layouts/IDxx.html. Replace placeholders and adapt content without changing the evidence contract. Do not mix composition recipes from different systems in one portfolio. Add local classes only when the registered fragments cannot express a required evidence type; document the reason in the manifest.

7. Handle imagery conservatively

Use original research, sketch, CAD, prototype, and test imagery before generated visuals.

Before placing an image, decide:

• what claim it supports;
• whether it must be shown with contain rather than cropped;
• its target slot and ratio;
• its caption, source, authorship, and evidence level.

Place local raster images with data-src rather than src so the template can defer decoding outside the active page window:

Generated imagery is optional. If used, follow references/image-policy.md, save it under images/generated/, and add an adjacent disclosure.

8. Preserve visual rhythm

• Alternate dense evidence pages with quiet synthesis or hero pages.
• Do not use more than three pages with the same dominant structure in sequence.
• Give sketches, prototypes, and final product imagery different visual roles.
• Reserve the strongest image for the project opening or resolution, not both.
• Keep captions close to the evidence they describe.
• Use real numbers only; do not add decorative KPIs.
• Keep the template's adjacent-page mounting, ?page=N, and ?render=all behavior intact.

9. Validate and preview

Run from the installed skill root, choosing the available Python 3 executable:

python /scripts/validate_portfolio.py path/to/index.html
# or: python3 /scripts/validate_portfolio.py path/to/index.html

Validate the manifest before validating HTML:

python /scripts/validate_manifest.py path/to/portfolio/portfolio_manifest.json
python /scripts/validate_layout_library.py

Then preview in a browser at desktop and narrow widths when browser access exists. Without browser access, report the missing visual QA step instead of claiming it passed. Check at least:

• first view and navigation;
• overflow and bottom safe area;
• image cropping and legibility;
• project transitions;
• captions, sources, disclosures, and authorship;
• slide rhythm and repeated layouts.

Resolve every P0 and P1 issue from references/checklist.md before delivery.

Required deliverables

For a complete build, deliver:

portfolio/
├── index.html
├── images/
├── portfolio_manifest.json
└── source_notes.md

portfolio_manifest.json records audience, projects, page plan, layout IDs, sources, evidence levels, assumptions, generated assets, and unresolved gaps. Validate it with scripts/validate_manifest.py before delivery. source_notes.md provides human-readable citations, authorship, and caveats.

If the user requests PDF, export only after browser review. Treat PDF as a derivative of the approved HTML deck, not a separate unreviewed design.

Review output

When auditing rather than building, report:

1. the portfolio thesis and intended audience;
2. the strongest proof already present;
3. P0/P1 issues blocking credibility or comprehension;
4. page-level cuts, merges, and reorder recommendations;
5. evidence gaps and how to collect them;
6. a revised story table and layout plan.

Completion standard

A portfolio is complete only when a reviewer can answer:

• What problem mattered?
• What did the designer personally do?
• Which alternatives were considered?
• Why was the final direction chosen?
• What changed after testing or constraint discovery?
• Which claims are proven, estimated, or still hypothetical?
• What is memorable about this designer's judgment?

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: truman-t3
• Source: truman-t3/industrial-design-portfolio-skill
• License: MIT
• Homepage: https://truman-t3.github.io/industrial-design-portfolio-skill/

Install and usage instructions live in the source repository linked above.