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.

🔗 Explore the Project

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

⚠️ 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.

Workflow Overview

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.

🚀 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.