Stop Babysitting Symlinks: Designing a Safer, Faster TUI Workflow

📝 From 'ln -s' to Intentional Workflows: Building an Interactive Symlink Creator in Go

Managing symlinks should be trivial. In practice, it’s anything but.

If you’ve worked with symlinks long enough — especially while managing dotfiles, configs, or multi-environment setups — you’ve likely fallen into the same repetitive loop:

• Double-check source and destination paths
• Worry about overwriting something important
• Manually resolve conflicts
• Repeat the process, carefully, every single time

The problem isn’t that symlinks are complex. The problem is that the workflow around them is fragile.

⚠️ The Real Issue: Workflow, Not Command

The ln -s command itself is simple. But the moment you scale beyond a single link, things start breaking down:

• No structured navigation → long, error-prone paths
• No safety layer → easy to overwrite unintentionally
• No batch operations → repetitive, manual work
• No feedback loop → you don’t know what went wrong until it’s too late

This isn’t a tooling problem. It’s a workflow design problem.

💡 The Shift: From Commands → Experience

Instead of asking:

“How do I create symlinks faster?”

I reframed the problem:

“How do I make symlink creation intentional, safe, and repeatable?”

That shift led to building Interactive Symlink Creator (ISC).

🚀 What is ISC?

ISC is a full-screen terminal application that guides you through the entire symlink creation process — from selecting directories to resolving conflicts — without dropping back into raw shell commands.

It’s built using Go and a TUI framework to create a structured, keyboard-first experience.

At a high level, the flow looks like this:

1. Choose a source directory
2. Choose a destination directory
3. Select files/folders to link (bulk supported)
4. Handle conflicts interactively
5. Review results and restart if needed

Everything happens inside a single, continuous interface.

⚙️ Key Capabilities

1. Interactive Directory Navigation

Instead of typing long paths manually, ISC provides a two-column navigator for selecting source and destination directories.

This reduces both cognitive load and error probability.

2. Bulk Selection Before Execution

You don’t execute commands one by one.

You:

• Select multiple files/folders
• Review your selection
• Execute in a single pass

This shifts the workflow from reactive → planned.

3. Conflict Resolution That Doesn’t Break Flow

When conflicts occur, you’re not thrown back into the shell.

You get structured options:

• Overwrite
• Skip
• Rename

All handled inline, without losing context.

4. Dry-Run Mode (Critical for Safety)

Before making any changes, you can simulate the entire operation.

go run . --dry-run create

This lets you validate decisions without touching the filesystem.

A small feature — but high leverage in preventing mistakes.

5. Cleanup for Broken Symlinks

Symlink-heavy environments tend to accumulate broken links over time.

ISC includes a cleanup command:

go run . cleanup /path/to/search

This scans and removes broken symlinks recursively.

🧠 Design Philosophy

This project wasn’t about building another CLI tool. It was about eliminating friction from a recurring workflow.

Key principles:

1. Full-Screen TUI Over Prompt-Based CLI

Prompts interrupt flow. A TUI maintains continuity.

2. Restartable Workflows

No abrupt exits. You can restart the entire process seamlessly after completion.

3. Keyboard-First Interaction

Every action is optimized for speed without leaving the keyboard.

4. Structured State Over Stateless Commands

Traditional CLI usage is stateless — you issue commands and hope for correctness.

ISC maintains state across steps:

• What you selected
• What conflicts exist
• What actions you chose

This drastically reduces mental overhead.

🛠️ Why Go + TUI?

The initial version was a Bash script.

It worked — but hit limits quickly:

• Hard to scale cleanly
• Poor UX for multi-step workflows
• Difficult to maintain or extend

Rewriting in Go enabled:

• Better structure (modular architecture)
• Clear separation of concerns
• Predictable behavior across environments

The TUI layer allowed transforming a command into an experience.

📂 Under the Hood

The project follows a layered structure:

internal/
├── domain/
├── fs/
├── services/
└── ui/
    ├── components/
    ├── manager/
    └── styles/

This separation ensures:

• Filesystem logic is isolated
• UI remains independent
• Business logic is reusable

It’s not just a tool — it’s designed to be extendable.

🎯 Who Is This For?

ISC is built for:

• Developers managing dotfiles
• Linux users working heavily in terminals
• Anyone tired of manually handling symlinks
• People who care about safe, repeatable workflows

📌 What This Project Really Represents

This wasn’t about symlinks.

It was about taking a small, annoying, everyday task — and treating it like a real engineering problem.

The outcome isn’t just a tool. It’s a pattern:

Identify friction → redesign the workflow → build around safety and intent

That pattern scales far beyond this project.

🔗 Explore the Project

You can check out the full project and implementation details here: https://github.com/KanishkMishra143/Interactive-Symlink-Creator

🚀 Final Thought

The best projects aren’t always flashy.

Sometimes, they’re the ones that:

• Remove friction
• Reduce mistakes
• And quietly make your daily workflow 10x smoother

And those are often the ones worth building.