Dev Breakfast · 2026-09-07

Alex Pliutau from packagemain.tech uses 6 lines of configuration to write .gitignore in reverse: first * to ignore all, then ! to allow .go, go.mod, etc. in the whitelist. This counterintuitive approach, my first reaction was 'finally, no need to deal with that long blacklist anymore', but missing one file in the whitelist can make you cry.

Write .gitignore in Reverse: Ignore Everything by Default, Only Allow Needed Files

Have you ever had this moment: after committing code, you suddenly find the repository mixed with .DS_Store, node_modules, IDE configuration files, or even worse—environment variable files. Then a series of fixes: patching the .gitignore, cleaning up history, praying no one noticed that embarrassing commit. Alex Pliutau from packagemain.tech proposed a counterintuitive approach on September 5: instead of allowing everything by default and then struggling to ignore, reverse it—ignore everything by default, only explicitly allow files you truly want to track.

How to do it? A simple Go project only needs 6 lines:

*
!.gitignore
!*.go
!README.md
!go.mod
!go.sum

The first line * ignores all files, each subsequent line uses ! to bring back what you want to track: .gitignore itself, Go source files, README, module files. Everything else—locally generated temporary files, documentation directories produced by Agents, IDE configurations—none of it will enter Git's view. You no longer need to maintain a growing blacklist; you only need to maintain a very short whitelist.

The appeal of this approach becomes clear when you look at the typescript-go project's .gitignore—a full 207 lines. I suspect half of them are scar tissue from 'some tool suddenly generated a bunch of files one day, and you added them'. The whitelist mode deletes all that: new tools, new Agents, new IDEs generating whatever junk? Doesn't matter, everything is ignored by default.

However, this approach isn't without trade-offs. It works best for projects with clear structure and limited file types—like compiled languages such as Go or Rust, where source file extensions are few. But if you're working on a frontend project, with dozens of file types under src/, various configuration files, static assets, test fixtures... the whitelist becomes a 'VIP list' you must carefully maintain, and missing one file that should be committed can be disastrous. Plus, new team members must first understand the logic of this whitelist; otherwise, after git add ., they find a bunch of files missing and have to run git check-ignore -v for debugging.

The author also provides a debugging tool: git check-ignore -v internal/server/server.go, which directly tells you why a path is ignored and which rule it matches. This command can save many head-scratching moments of 'I definitely added it, why didn't it commit?'

Thinking deeper, this approach actually reflects a shift in development workflows: local directories are getting more cluttered—documentation from various Agents, cache directories, temporary scripts. Previously, .gitignore was a filter for Git, but now it's more like a 'boundary declaration for the project': what's part of the project, and what's just your local temporary output. When Agents start leaving files like CLAUDE.md, .cursor/, etc., in projects, the whitelist mode becomes the cleanest boundary—instead of patching every new type of file generated by new tools, declare from the source: if it's not named, it's not part of this project.

This trick isn't a silver bullet, and the author admits it might not suit every repository. But next time you face a 200-line .gitignore, consider: if you write it in reverse, wouldn't it be less hassle? At least, those 'committed files that shouldn't be committed' social death moments can be reduced one by one.

💡 Chef's take: The article mentions that typescript-go's .gitignore has 207 lines. This project is Microsoft's attempt to rewrite the TypeScript compiler in Go—even it has accumulated so many rules, indicating that the blacklist approach can indeed get out of hand in large projects.

Sources:

• hackernews · der_gopher

OpenAI Open-Sources Codex Skills Catalog: A Reusable Skills Library with 25.6k Stars

OpenAI has released the official Skills Catalog for Codex on GitHub. This repository has already accumulated 25.6k Stars and 1.7k Forks, with 114 commits showing active iteration. Simply put, this is a collection of 'skill' definitions for Codex—encapsulating common coding tasks into reusable instruction templates so the Agent doesn't need to understand requirements from scratch each time.

For coders, the practical value lies here: previously, when you let Codex work, you had to re-explain the context, constraints, and output format every time. Now, you can directly reference a skill file to define the specification for 'how to handle this type of task' once. The repository already has 19 branches maintaining different versions of skill definitions, and the latest commit is still adjusting the post-installation guidance logic for the skill installer, indicating that OpenAI itself is exploring best practices for this system.

My first reaction: this is similar to MCP, but with a different focus. MCP solves 'how Agents call external tools', while skills solve 'how Agents complete tasks according to your specifications'. If you're already using Codex for repetitive coding tasks, it's worth browsing this catalog to see if there are definitions you can use directly—the prompt debugging time saved could be enough for you to drink two more cups of coffee.

But don't rush to migrate all workflows. These skill libraries are still in a rapid evolution phase; the format defined now might change in a few months, just like plugin specifications for various Agent frameworks back in the day. Try one or two high-frequency tasks first, and wait for the ecosystem to stabilize before large-scale integration—that might be a more pragmatic approach.

Sources:

• github_trending · openai

Ladybird August: Memory Reduced from 17.8 GiB to 61 MiB

Ladybird browser has released its August 2026 development summary. The biggest change this month is that performance has become a continuous focus: a new style engine, layout caching, CSS animations moved off the main thread, and CSS parsing and painting pipelines migrated to Rust. For coders, the most intuitive comparison is that a Strava activity page used to grow to consume 17.8 GiB of memory; after the fix, it only takes 61 MiB—a 99.7% reduction. I checked this number twice to confirm I read it correctly.

Feature rollouts this month were also dense. In video, Media Source Extensions support fragmented MP4 and AVC, HEVC, AV1, AAC encodings; Twitch and Plex can now play adaptive bitrate videos; and on YouTube, old videos with only AVC and 8K AV1 streams can now play. CSS scroll snap has arrived, supporting wheel, keyboard, trackpad fling, and scrollTo(), but scrollIntoView() isn't supported yet. DevTools can now set breakpoints, step through debugging, and watch expressions, using the Firefox DevTools frontend as a transition. Downloads support pause and resume, can restart across browsers, and handle up to four parallel streams. Ctrl+Shift+T now restores not just URLs but full session history, including back-and-forward states.

Notably, site-compatibility rules have been changed to runtime-loaded declarative JSON, no longer hardcoding site policies into the browser. Currently, nytimes.com and cnn.com render normally by hiding 'Ladybird' from the User-Agent. Additionally, alert(), confirm(), and prompt() have been changed to in-page overlays instead of system modals, so while (true) alert("lol") no longer locks the entire browser—I know this pain, who hasn't been bitten by such code. The project is fully funded by sponsors, with a new sponsor this month donating $5,000. Ladybird is still in its early stages; don't expect it as a daily driver, but if you want to see what a browser looks like without being hijacked by ads and commercial interests, it's worth running now.

Sources:

• hackernews · exploraz

Chrome Gives Another 'Data Exemption' Backdoor to Its Own Sites

Chrome has once again allowed Google's own sites to bypass your site data settings, leaving third-party developers with nothing but a bitter smile—same rules, but Google's products always have a VIP channel. What does this mean for coders? Your carefully tuned privacy settings might not work at all on Google sites. Although not a new vulnerability, this 'rule double standard' is worth noting: don't assume all sites obey your browser settings; cookies that need manual cleanup still require periodic attention.

Sources:

• hackernews · ExMachina73

qBittorrent Sandbox Escape: Downloader Crosses Boundaries to Execute Operations

News about a qBittorrent sandbox escape has spread on Hacker News, with a headline that's bluntly scary: 'QBittorrent breaks out of sandbox to commit crimes'. Currently, only this sentence is available; specific vulnerability details, affected versions, and exploitation methods haven't been disclosed. But for you using qBittorrent, this is at least a reminder: don't rush to open download directory permissions to the maximum, and don't run naked in a sandbox environment. When the vulnerability details come out, remember to check immediately if your version is affected; upgrade if needed, and isolate if necessary.

Sources:

• hackernews · mraniki

humanlayer/skills on GitHub Trending: A 'New Solution' or 'Another Layer of Wrapping' for Agent Skill Libraries?

humanlayer/skills has hit GitHub Trending today, with the repository under the humanlayer account. Just by the name, you might think it's another wheel for adding skill packs to AI Agents—but click in, and you'll find it's more about managing the 'skill invocation' for Agents itself. The repository hasn't released specific use cases or performance data yet, so don't jump to conclusions. If you're tinkering with Agent tool-use workflows, it's worth spending ten minutes to read its README and figure out how it differs from the function-calling approach you're currently using. Things on trending lists are half skill, half luck; don't rush to change your architecture.

Sources:

• humanlayer/skills - GitHub

GPT-6 Astra on Robot Arms: The 'Code Review' for the Physical World Has Just Begun

Remember our previous episodes on code review? The conclusion was improved performance but high costs and privacy concerns. Today, GPT-6 Astra runs on robot arms, and these issues haven't disappeared—they're even more glaring. In code review, you can still use private deployment as a fallback, but robot arms working with cloud APIs mean every frame of video and every movement command goes over the network; can those workshop secrets still be hidden? Cost calculations also need more detail: APIs charge per token, and a single grab action by a robot arm might require dozens of inference calls, with latency and bills rising together. 'AI entering the factory' sounds great in promotions, but before actual deployment, you must first think clearly: which actions can tolerate network round-trips, and which must rely on local inference. Don't be fooled by demo videos; after running a month in production, the bill will tell.

Sources:

• GPT-6 Astra on robot arms

Asahi Linux Officially Supports M3, But Don't Rush to Make M3 Your Main Machine Yet

Asahi Linux has announced official support for Apple M3 chip Macs. This is solid good news for you wanting to run Linux on Apple Silicon. However, the 'Caveats' in the title isn't just politeness—current support still has obvious limitations, like GPU drivers and power management, which likely aren't fully sorted out yet. Anyone who has tinkered with Apple Silicon Linux knows that being able to boot and being able to use it daily are two different things. My first reaction: M3 users can now start experimenting, but don't expect to immediately replace macOS for production environments. If you want to try, it's recommended to first check your specific model and peripheral compatibility before proceeding.

Sources:

• Asahi Linux Now Officially Supports Apple M3 Macs – With Caveats

---

Do you dare to flip the .gitignore of your current project and keep only those few lines of whitelist? If you dare, comment 'flip'; if not, comment 'stable'. See you tomorrow at 8 AM.

This issue selected 8 items from a total of 49 pieces of information over the past 24 hours on X / Hacker News / GitHub Trending (collected hourly throughout the day, fact-checked, and compiled in the morning). Content generated with LLM assistance, each item includes original source links; please cross-verify important decisions.