Role-aware terminal portfolio
2026 · Released CLI experiment
npm namespaces
Making a portfolio answer the role before opening a browser
I turned an npm namespace into an interactive terminal card: one canonical npx command, four audience-specific views, and a deliberately small path from first impression to relevant proof and contact.
Quick scan
TL;DR
The shortest version: what changed, what shipped, what was verified, and where the proof stops.
Overview
Problem
A general portfolio asks every evaluator to find the part that matters to them, while a package-name search can end at a placeholder with no useful next step.
Move
Made one package the canonical interactive profile and routed its content through recruiter, engineer, hiring-manager, and product views.
Outcome
The repository records a v1.3.1 release, a dependency-free Node CLI, three real terminal captures, ten package manifests, and explicit active-versus-parked naming decisions.
Scope
Independent naming strategy, terminal interaction design, Node.js implementation, package metadata, release preparation, and documentation.
Proof
- Recorded release
- v1.3.1The canonical package manifest and release commit record version 1.3.1.
- Audience routes
- 4 viewsRecruiter, engineer, hiring-manager, and product views ship in the committed CLI.
- Namespace surface
- 10 manifestsOne package is marked active, seven are marked parked, and two additional manifests are not listed in the status table.
- Source check
- 11 entry filesEvery inspected JavaScript entry file passed Node syntax validation; no regression suite was present.
01 · Context
The package name was only useful if it led somewhere meaningful.
The repository began as a collection of personal npm names: scoped and unscoped variants around Aidan Devaney. That protected a small naming surface, but a set of published placeholders was not yet a coherent product experience.
The more interesting opportunity was the context of use. Someone running an unfamiliar npx command is already in a terminal and willing to explore. The interface could meet that behavior directly, then make a relevant route visible without forcing a browser detour first.
02 · The decision
Route the story by evaluator, not by one universal biography.
Same person. Different question. Shorter path to the useful evidence.
The canonical CLI divides the profile into four audience views: recruiter, engineer, hiring manager, and product. Each view changes the summary, supporting experience, call to action, and link order while keeping the same visual and interaction system.
Slash-command autocomplete makes those routes discoverable. Arrow keys move through suggestions and links, Tab completes a command, Enter follows the selected destination, Escape returns, and a dedicated shortcut copies the contact email.
Engineering noteThe terminal is treated as a real input environment.
The interaction is a small state machine built with Node’s standard library rather than a static block of ANSI text. It adapts to TTY availability, terminal width, operating system, and recoverable clipboard behavior.
- Raw key handling is enabled only for an interactive TTY; piped execution prints the introduction and exits.
- Text wraps against a bounded 48–100 column frame so role content remains readable across terminal sizes.
- Links and clipboard actions use platform-specific executables with argument arrays and expose fallback status instead of stopping the session.
03 · What shipped
One canonical card, backed by a deliberately claimed namespace.
The `aidandevaney` manifest exposes a single executable and records version 1.3.1. The CLI includes a neofetch-inspired identity header, four role-specific pages, command suggestions, direct portfolio, LinkedIn, and GitHub links, email copying, help and version flags, and a non-interactive output path.
The inspected repository contains ten package manifests. Its documentation marks `aidandevaney` active and seven variants parked; two additional unscoped manifests exist outside that status table. That discrepancy is kept explicit here rather than rounding the package story into a cleaner claim than the source supports.
Change the story with the audience
Engineering noteNamespace breadth created a maintenance trade-off.
Nine naming variants currently contain identical 599-line CLI entry files, while the canonical package has its own implementation. The approach made each package independently executable, but it also duplicated behavior that can drift.
- SHA-256 inspection found the same source hash across nine variant entry files.
- The repository has no shared runtime package or generated source step for those copies.
- A future release should centralize the interaction core and generate or wrap the parked entry points.
04 · Evidence
The record supports a released artifact, not an adoption story.
Five commits on the inspected branch cover the initial namespace setup, the interactive profile implementation, the v1.3.1 release change, and the terminal documentation. Three checked-in screenshots show the home, autocomplete, and role-view states.
For this case study, all eleven JavaScript entry files passed `node --check`, and the canonical help path was executed successfully from the working tree. No automated test suite, download analytics, usage telemetry, referral data, or conversion evidence was found.
The sibling repository also had three pre-existing modified files. Those working-tree additions introduce proof, case-study, and sharing commands, but they are described only as work in progress—not as part of the recorded v1.3.1 release.
05 · Reflection
A novelty becomes useful when it reduces the next person’s work.
The memorable part is the terminal treatment, but the product decision is the routing. A recruiter and an engineer do not need the same opening argument; changing the first screen around their question makes the interaction more than a digital business-card gimmick.
The repository also shows where compact experiments accumulate systems debt quickly. Package status is maintained by hand, behavior is copied across entry files, and the release has no regression suite. Shared source, generated package metadata, smoke tests for key navigation, and an automated release check would make the namespace easier to extend honestly.
The next evidence gap is behavioral: whether people run the command, choose a role, follow a link, or share the profile. Until that instrumentation exists, the defensible outcome is the released and inspectable interaction itself.