DEV Community: JustineDevs

This is why interview repos should be treated as untrusted software until inspected.

JustineDevs — Wed, 01 Jul 2026 13:39:33 +0000

The malware was not in the app. It was in .git/hooks.

My first job hunt taught me to inspect the repo before trusting the task

I am currently looking for my first job So when a recruiter messaged me on LinkedIn and sent over a take-home repository, I treated it seriously. This was one of the first real task-based opportunities I had received, so I wanted to do everything properly.

I reviewed a take-home repository that came through recruiter outreach.

It was a web3 front end with WalletConnect, Transak, Uniswap widgets, Infura, Etherscan, and configuration driven REACT_APP_* env vars. The kind of stack you would expect from a real production app. That was exactly why I almost missed the part that mattered. Before running anything, I started checking the repo structure, package scripts, and Git metadata. I did not run install commands. I did not start the app. I did not assume the repository was safe just because it came through a recruiter.

At first glance, it looked normal enough for a production web3 front end. WalletConnect. Transak. Uniswap widgets. Infura. Etherscan. Vercel Analytics. Env-driven config for chain IDs, contract addresses, fees, and backend URLs.

That part did not bother me.

The red flag was lower level.

Inside the repo-local .git/hooks directory, I found executable pre-commit, pre-push, and post-checkout scripts. They did not validate code. They did not format files. They did not run tests.

They fetched remote content from a hardcoded IP address and piped it into a shell or command interpreter.

That is not a build step.

Actual Screenshot of post-checkout, pre-commit, pre-push file

That is a downloader.

Git hooks matter because Git runs them automatically on specific events. pre-commit runs before commits. pre-push runs before pushes. post-checkout runs after a checkout. Git also allows

hooks to live in .git/hooks or in a configured core.hooksPath, and git init can copy hook templates into a repo.

So if a malicious hook sits in the repo, the attack surface is not just the app. It is the developer workflow.

That is the part people miss.

The workflow pattern Here is the basic flow I observed:

The candidate is approached like a normal hire The conversation starts like a standard recruiter or hiring process. The task is framed as a practical engineering evaluation, not a public challenge.

This lowers suspicion because it feels like a legitimate private assessment.

The Person or Profile that blocks me after I confirmed it;https://www.linkedin.com/in/paula-andrea-d%C3%ADaz-loaiza-481ba9232/

The time I get blocked or they delete?

2. The project is shared as a zip file Instead of a clean private GitHub repository, the project is delivered as a Dropbox package.

https://www.dropbox.com/scl/fi/3bb255hoju2sxh9k7ml2h/datalake-token-app.zip?dl=0&e=2&file_subpath=%2Fdatalake-token-app&rlkey=jpk7vaw2n8kqrbzk8u3e8otcj&st=cmh3zbzg

That matters because:

it removes the normal protections and visibility of a repo,

it makes the workflow feel “local and manual,”

and it encourages the candidate to unpack and inspect the code on their own machine.

The codebase looks real The project itself is not empty or fake-looking. It contains a real frontend app, real Web3 integrations, real environment-driven configuration, and even sensitive-looking .env material.

That is important because a believable app builds trust.

1. The assignment asks for Git-based work The candidate is told to:

create a new branch,add a review file,push the project, and return the GitHub URL.

This is where the workflow becomes interesting.

It makes the candidate behave like a normal developer:

clone or unpack,inspect,branch,commit,push.

That is exactly the behavior malicious hooks are waiting for.

2. Malicious hook files sit in .git/hooks Hidden in the repo are hook files like:

pre-commit,pre-push,post-checkout.

Minimize image Edit image Delete image

Add a caption (optional) These are not ordinary project files. They are execution points Git can trigger automatically.

The scripts I found were not harmless automation. They used a pattern like:

detect the OS, fetch a remote payload from an IP address,pipe it directly into sh or cmd,hide output, and run in the background.

Minimize image Edit image Delete image

Add a caption (optional) That is a classic downloader-style execution chain.

The payload is triggered by normal Git actions The dangerous part is not just that the scripts exist. It is that they can fire during ordinary Git operations:

commit,push,checkout.

So the candidate does not need to do anything unusual.

A normal workflow action can become the trigger.

Why this scheme works This workflow is effective because it mixes trust and routine.

It succeeds when:

the task looks professional,the app looks real, the instructions sound standard,

and the candidate follows normal Git behavior without checking hook files first.

The candidate thinks they are doing an interview task. In reality, they may be executing a hidden payload.

What makes it dangerous The risk is not just “bad code.”

The actual danger is the combination of:

social engineering, believable delivery, hidden Git execution points, and remote code download.

That means the workflow itself is the attack.

They inspect src/, package.json, and the dependencies. They forget that Git metadata can execute code before the app ever starts.

I did not treat this lightly. I checked the package scripts first. I did not run install commands, startup commands, or any Git action that could trigger hooks. The application itself did not show obvious preinstall or postinstall trickery. The dangerous behavior lived in the Git layer. That distinction matters.

What made this worse is that Git hooks are not decorative files. Git runs them automatically at specific events. A developer can trigger them just by committing, pushing, or checking out code. So if a malicious hook is sitting inside the repo, it does not matter that the app code looks clean. The attack path is already in place.

This was the first time I had to think about a job task in two layers at once.

The visible layer was the app.

The hidden layer was the repository itself.

And that changed how I now review any take-home assignment. I no longer start by asking, “Does the app work?” I start by asking, “What executes before the app even opens?”

This repo contained hook-based remote code execution behavior. And that pattern is not hypothetical. Security writeups have documented Git-hook abuse in fake interview and recruiter-style campaigns, especially where the target is a developer working in crypto or web3. Detection content from security vendors also treats Git-hook execution and hook-origin network egress as suspicious.

So the practical lesson is not "never trust web3 projects."

The lesson is "never trust a repo until you inspect the parts outside the app."

If you receive an interview task or a code sample from a stranger, check these before you run anything:

.git/hooks
.git/config
core.hooksPath
package.json scripts
lockfile install scripts
any shell, PowerShell, or Python files that run during setup

If a hook reaches out to the network and executes what it gets back, stop there. That is not a hook anymore. It is a launcher.

I now treat interview repos as hostile until proven otherwise.

Not every repo with hooks is malicious. Normal hooks exist. But normal hooks do not phone home and execute remote payloads.

That is the line.

I am publishing this because the defensive habit matters more than the story itself. Read the metadata. Check the hooks. Do not assume the dangerous code will be in src/.

If you review take-home repos, have you ever looked past the app code and found something in Git metadata?

Sources I checked included Git's hook documentation, recent threat-intel reporting on Git-hook abuse, and vendor detection guidance for hook-based persistence and egress.

Core incident pattern SocPrime — Git hooks used to hide malware in fake interview workflows: https://socprime.com/active-threats/lazarus-group-uses-git-hooks-to-hide-malware-dprks-contagious-interview-and-taskjacker-campaigns/socprime

OpenSourceMalware — Lazarus / Contagious Interview using Git hooks: https://opensourcemalware.com/blog/lazarus-group-uses-git-hooks-to-hide-malwareopensourcemalware

Andrii.ro — Investigating malware spreading through Git repositories: https://andrii.ro/blog/investigating-malwareandrii

Microsoft Security Blog — Contagious Interview fake developer job malware: https://www.microsoft.com/en-us/security/blog/2026/03/11/contagious-interview-malware-delivered-through-fake-developer-job-interviews/microsoft

Detection and security references Elastic detection rule — Git Hook Command Execution: https://www.elastic.co/docs/reference/security/prebuilt-rules/rules/linux/persistence\_git\_hook\_executionelastic

Elastic / Detection FYI — Git Hook Egress Network Connection: https://detection.fyi/elastic/detection-rules/linux/persistence\_git\_hook\_netcon/detection

Elastic hunting query repo reference: https://github.com/elastic/detection-rules/blob/main/hunting/linux/queries/persistence\_via\_git\_hook\_pager.tomlgithub

SonarSource — Securing developer tools / Git integrations: https://www.sonarsource.com/blog/securing-developer-tools-git-integrations/sonarsource

Fake recruiter / fake interview campaign coverage BleepingComputer — Fake job recruiters hide malware in developer coding challenges: https://www.bleepingcomputer.com/news/security/fake-job-recruiters-hide-malware-in-developer-coding-challenges/bleepingcomputer

BleepingComputer — New wave of fake interviews use npm packages to spread malware: https://www.bleepingcomputer.com/news/security/new-wave-of-fake-interviews-use-35-npm-packages-to-spread-malware/bleepingcomputer

The Hacker News — Fake Next.js job repos targeting developers: https://thehackernews.com/2026/02/fake-nextjs-repos-target-developers.htmlthehackernews

CSO Online — North Korean cyberspies trick developers via fake job interviews: https://www.csoonline.com/article/3479795/north-korean-cyberspies-trick-developers-into-installing-malware-with-fake-job-interviews.htmlcsoonline

CyberSecurityDive — State-linked hackers deploy malware in fake job interviews: https://www.cybersecuritydive.com/news/north-korean-hackers--fake-interview/739165/cybersecuritydive

CybersecurityNews — Beware of fake job interview challenges attacking developers: https://cybersecuritynews.com/beware-of-fake-job-interview-challenges/cybersecuritynews

Economic Times Tech / Graphalgo coverage: https://techmonk.economictimes.indiatimes.com/news/cybersecurity/graphalgo-security-alert-fake-job-interviews-are-dropping-rat-malware-on-developer-machines/118188688techmonk.economictimes.indiatimes

Dev Popper / Bluegrid — Social engineering via fake job offers: https://bluegrid.io/blog/dev-popper-how-social-engineering-exploits-developers-with-fake-job-offers/bluegrid

Git hook hardening / disabling Stack Overflow — Disable Git hooks for security reasons: https://stackoverflow.com/questions/35997624/how-to-disable-git-hooks-for-security-reasonstackoverflow

Stack Overflow — How to globally disable Git hooks: https://stackoverflow.com/questions/48135161/how-to-globally-disable-git-hooks

The gap between AI demo hype and real user onboarding is bigger than most teams admit. Meta Architect v0.1.13 is our step toward closing it.

JustineDevs — Sat, 06 Jun 2026 01:12:06 +0000

Most AI tools look impressive in demos. Very few feel usable when you actually install them. Meta Architect v0.1.13 changes that — 33 plugins, a live demo, and a cleaner path from install to first skill.

I've just shipped the most complete release of the Codex skills bundle yet, with a real demo, a restructured onboarding story, and 33 documented plugins and features across the full skill surface.

🔗 Repository: https://github.com/JustineDevs/meta-architect

Why this release matters v0.1.6 was about coherence getting the packaging, identity, and install story right. v0.1.13 is about showing the product clearly and making it easier to trust.

The gated lane sequence hasn't changed. But everything around it has: the manager is smarter, there are more skills to reach for, the install surface covers more platforms, and the README now leads with a live demo and a capability table instead of release-maintainer details.

If v0.1.6 was "ready enough for people who want to use it in anger", v0.1.13 is "ready enough for people who want to understand it in 30 seconds and then use it in anger".

What v0.1.13 focuses on A real demo, not static copy

The README now opens with a live demo GIF that shows install, $maestro orchestration, Obsidian brain context, learning reliability, environment awareness, Ralph handoff, and release verification — with real runtime functions, not screenshots of documentation.

The README now leads with:

Install command
Demo media
Capability summary table
Grouped feature inventory (expandable)
Long-form release-maintainer details are collapsed into blocks. A first-time viewer can follow the product story without wading through packaging rules.

"What You Get" capability table

A new top-level table makes the full surface scannable at a glance:

An expandable section now lists every plugin and feature across six categories: Core & Orchestration, Memory & Knowledge, Intelligence & Learning, Code Quality & Testing, Security & Compliance, Architecture & Methodology, DevOps & Observability, and Extensibility.

How you use it

Visit Setup Guide

Who this helps For developers

The demo shows the full workflow end-to-end before you install anything
The helper skills give you targeted tools between gates — alignment, diagnosis, test scaffolding, cleanup — without disrupting release state
ma setup / ma bootstrap / ma doctor remove the manual setup friction that tripped people up in earlier versions

For new architects

$maestro as a bounded autonomous manager means you can ask it to choose the next step rather than tracking the sequence yourself
The "What You Get" table and 33-plugin inventory give you a map of the surface before you start

For experienced architects

The gate model is explicit: CLEAR, APPROVED, VERIFIED, PARTIAL, GREEN, RED, WAIVED, LOCKED, READY — each status has a defined meaning and a defined effect on what is allowed next

Evidence must come from repository-form GitMCP endpoints. A generic docs endpoint does not count as VERIFIED for build unlocking

The Redaction Gateway, MCP policy, and exposure catalog give you explicit control over what context crosses trust boundaries

I'm especially interested in feedback from people who:

are running the gated sequence on real projects and hitting edge cases
want to use the helper skills ($align, $diagnose, $tdd, $cleanup) and have opinions on where they fall short
are on Linux and trying the native package install path for the first time
watched the demo and found something that didn't match what the runtime actually does

If that's you, the repo is here: 👉 https://github.com/JustineDevs/meta-architect

roblox-ai-os: Roblox AI OS (Creator) Skills for Codex, Claude, Cursor, and more IDE

JustineDevs — Mon, 11 May 2026 06:48:53 +0000

How I stopped "fighting" my code and started designing: My shift to an Agentic Workflow I got tired of AI Roblox tools fighting my project, so I built an open source.

RCS, a Roblox Studio workflow layer for AI coding tools
I built RCS because Roblox AI coding tools are great for rapid prototyping, but they get much harder to trust as projects grow.

A lot of current Roblox AI tools are useful for getting a mechanic working quickly, but the failure mode is usually not syntax. It is workflow drift: lost context, subtle logic bugs,

repeated fixes that create new problems, weak verification, and code that becomes hard to maintain later.

RCS is a workflow/runtime layer around Codex for Roblox creators. It does not try to be “another magic code generator”. The goal is to make AI-assisted Roblox work more structured and easier to trust.

What it does today:

gives a Roblox-first workflow from brief -> plan -> execution -> verification
adds stricter planning before code generation for Roblox-specific work like remotes, DataStore, UI, plugins, and workspace structure
keeps project state, plans, logs, and workflow context in one place
supports multi-agent and adapter-style lanes instead of assuming every AI tool works the same way
treats official Roblox references and grounded docs as part of the default workflow, to reduce hallucination
The project is for advanced Roblox creators and technical tool/plugin builders, not for beginners looking for a single prompt-to-game button.

I’d especially love feedback on:

whether this is the right abstraction layer for Roblox AI tooling
whether the platform compatibility model makes sense
where the boundary should be between code generation, workflow control, and live Studio integration.

Full source

What is Meta-Architect?

JustineDevs — Sat, 02 May 2026 16:53:44 +0000

When we talk about AI coding agents, most tools are great at “fill in this function” and pretty weak at “is this system actually well-designed?”.

Meta-Architect is live on GitHub.
Repo link: https://github.com/JustineDevs/meta-architect

What Meta-Architect is (and isn’t)
Meta-Architect:
runs as skills inside Codex
ships as a package/plugin, not a new shell
tries to help with architecture, not just local code edits
It’s designed to plug into the Codex ecosystem rather than competing with it.

Here is what you get.

What Meta-Architect is
Meta-Architect gives your AI agents a real architecture workflow, not loose prompts.

You get six named roles with strict responsibilities.

\$arch designs the system and explains the stack
\$sage pulls proven OSS patterns and libraries
\$flow maps user flows, state, and edge cases
\$vet reviews security and stops unsafe builds
\$vibe reviews developer experience and user experience
\$build turns the approved plan into an execution roadmap

Each role is a skill with a clear contract.

How it fits into your workflow

The idea is not to replace your existing tools.
Instead, Meta-Architect gives you a set of skills you can call when you need to:
understand the shape of a system
explore alternative designs
identify weak boundaries and risky assumptions
turn requirements into more structured plans
You stay inside Codex; Meta-Architect just adds a set of focused capabilities on top.

Why this exists
Most AI dev tools feel helpful at first, then fall apart when you try to ship.

They hallucinate stacks that never reach production
They ignore architecture, security, and release gates
They treat your repo as plain text instead of a system with rules and states

Meta-Architect goes the other way.
You treat the repo as the source of truth for skills, prompts, gates, packaging, and CI from v0.1.0 onward.

What lives in the repo
You are not downloading a bag of prompts.
You are getting a shaped repository.

Skills

skills/meta-architect-*.md holds the core skills for Arch, Sage, Flow, Vet, Vibe, Build
each skill defines a trigger, responsibilities, expected outputs, and gate impact

Prompts

stable role prompts for Architect, Sage, Flow, Security Reviewer, Builder, and others
written as contracts so your agents keep the same behavior across sessions

Templates

templates/AGENTS.md defines how triggers, gates, and evidence should behave together
templates/catalog-manifest.json is the catalog for skills and prompts

Missions

scenario folders like collaborative whiteboard, fintech app, SaaS dashboard
each mission describes constraints, expected gate changes, and what artifacts you should see

Plugin and publishing

plugins/meta-architect provides a bundle you can install as a plugin in compatible runtimes
scripts and npm commands handle skills:manifest, skills:validate, skills:pack, skills:install

Repo discipline

CONTRIBUTING plus issue forms keep contributions aligned with release safety
CI workflows run skills manifest, validate, pack, and install on each change
release and npm publish workflows treat your skills as versioned artifacts
checks prevent .omx runtime state from leaking into git

How you use this on a real project
Say your idea is:
“I want an AI powered smart contract security review workspace for solo founders.”

You run the skills in this order.

\$arch gives you system boundaries, stack choices, and clear risks
\$sage finds frameworks, auth, and infra from curated OSS lists
\$flow maps user journeys, data flow, and failure paths
\$vet reviews security and stops the build if status is not GREEN
\$vibe reviews onboarding, complexity, and usability
\$build turns the approved plan into repo layout, environment setup, and v0.1.0 milestones

You move from idea to gated plan in a repeatable way.

Who this helps
For developers

You keep control of architecture while offloading repetitive design work
You get a build plan that respects security and release practice

For new architects

You see how decisions, patterns, trade offs, and gates connect
You get concrete examples instead of vague theory

For experienced architects

Why share this now?
This release is “ready enough” for people who actually want to use it in anger and tell me where it breaks:
architecture folks who want more structure around design discussions
engineers experimenting with AI-assisted reviews or design sessions
anyone tired of manually repeating “here’s how our system works…” to an LLM
If you want to kick the tires:
👉 https://github.com/JustineDevs/meta-architect

You get a checklist that encodes your process into skills and CI
You can standardize how teams and agents reason about architecture

For maintainers and tool builders

You start from a repo pattern that already has skills, prompts, missions, MCP config, CI, and plugin bundling
You can adapt this pattern for your own skills library

What comes next
Near term work

Make the Architect skill behave like a small architecture handbook
Expand missions with deeper real world scenarios
Improve docs for skills publishing and MCP setup
Wire this into Codex style workflows so agents help maintain the repo under gates

Longer term work

Turn Meta-Architect into a base template for new repos that want AI aware architecture from day one

If this is the type of discipline you want around your AI workflows, review the repo, open an issue, or start a fork.
Repo link again: https://github.com/JustineDevs/meta-architect

Go-MiroFish, lightweight and local-first

JustineDevs — Sat, 25 Apr 2026 15:01:30 +0000

Go-Mirofish Fast local Go AI swarm engine – predict anything with agents

I needed a fast offline tool to test reactions to documents. I upload an earnings report or trading thesis or product announcement. I want to see how hundreds of different AI agents respond in a social simulation. No data leaves my machine. No slow cloud delays.So I built go-mirofish.You feed the tool any document. It builds a knowledge graph. It creates hundreds of AI agents. Each agent has its own personality. The agents run a full social simulation. You get a prediction report. You can chat with any agent to ask more questions.I rewrote the control plane in pure Go. Python no longer runs the hot path. The system now delivers sub 2 ms p50 latency. It handles 198 requests per second with zero errors. It runs on a standard laptop. It also runs on a Raspberry Pi 5.

Here is how you start in minutes: https://go-mirofish.vercel.app/docs

Home / entry	Simulation run
Report generation	Report timeline / tools
Simulation history	Deep interaction
Split: graph, workbench & system terminal	Graph view & node details

Thanks to these projects. MiroFish created the original swarm engine. MiroFish-Offline added the local English version. OASIS powers the multi-agent simulation. Neo4j manages the graph memory. Ollama runs the local models.I built go-mirofish for real work. Traders test market reactions and liquidation forecasts. Product teams run PR war rooms.
Teams practice cyber drills.

Writers explore alternate story endings.
Try the demo here.
https://go-mirofish.vercel.app

See the full source here.
https://github.com/go-mirofish/go-mirofishWhat
document will you test first. Tell me in the comments.