GitHub on KnightLi Blog

What Is GitHub Spec Kit? Using Spec-Driven Development to Tame AI Coding

Mon, 25 May 2026 00:19:14 +0800

GitHub’s Spec Kit is a new toolkit for AI coding. Its goal is to help developers practice Spec-Driven Development.

The problem it tackles is straightforward: many AI coding workflows today feel too much like “chat while coding.” A human gives a rough idea, and an Agent immediately starts changing code. It looks fast in the short term, but the requirement boundaries, acceptance criteria, technical trade-offs, and task breakdown often never settle into anything durable. Once a project becomes even slightly complex, it easily turns into one-off vibe coding.

Spec Kit takes the opposite route: write the spec clearly first, then move into planning, tasks, and implementation. Code is no longer the first step. The spec is.

What Is Spec Kit?

Spec Kit is GitHub’s open-source toolkit for spec-driven development. It provides the specify CLI, templates, scripts, and commands for AI coding agents, allowing teams to advance development around the same set of structured artifacts.

Its emphasis is not “make AI ask fewer questions.” Instead, it asks AI to generate and refine these things before writing code:

Project principles: the team’s constraints around quality, testing, experience, performance, and similar concerns;
Feature specs: what to build, why to build it, user stories, and functional requirements;
Technical plans: which technology stack to use, how to implement it, and what architecture decisions are involved;
Task lists: breaking the plan into executable steps;
Implementation process: changing code step by step according to tasks, instead of making one chaotic batch of edits.

This workflow makes AI coding feel more like engineering collaboration, rather than a one-time prompt performance.

Basic Usage Flow

The official README describes a getting-started flow roughly like this:

1
2
3

uv tool install specify-cli --from git+https://github.com/github/spec-kit.git@vX.Y.Z
specify init my-project --integration copilot
cd my-project

After initialization, the project gets a .specify directory, templates, scripts, and commands for Agent integration. You then use /speckit.* commands inside a supported AI coding agent to move development forward.

A typical sequence is:

/speckit.constitution
/speckit.specify
/speckit.clarify
/speckit.plan
/speckit.tasks
/speckit.implement

Here, /speckit.constitution establishes project principles, /speckit.specify describes product requirements, /speckit.clarify fills in ambiguity, /speckit.plan generates a technical plan, /speckit.tasks breaks the work into tasks, and /speckit.implement finally performs the implementation.

This is very different from directly telling an Agent, “Help me build an app.” Spec Kit asks you to first make clear what to build and how it will be accepted, then let the Agent start working.

It Changes the Entry Point of AI Coding

Traditional AI coding often starts with code:

`1`	`I want to build a task management app. Help me write it.`

Spec Kit is closer to this:

First define the users, scenarios, feature boundaries, acceptance criteria, and non-goals for this task management app;
then choose the technical approach based on those specs;
then break it into tasks;
finally implement it step by step.

This shift matters. AI is very good at executing from context, but if the context itself is loose, faster execution can also mean faster drift. Spec Kit turns context into files and templates, so requirements, plans, and tasks can all be reviewed, revised, and version-controlled.

In other words, it is not making AI more “free.” It is giving AI clearer engineering rails on which to work freely.

How to Understand the Core Commands

`/speckit.constitution`

This is the project’s “constitution.” It creates or updates .specify/memory/constitution.md, which records long-term principles for the project, such as code quality, testing standards, user experience consistency, performance requirements, and rules for technical decisions.

This step is best for writing down team consensus, not requirements for a single feature.

`/speckit.specify`

This is the feature specification phase. You describe what you want to build, who the users are, what problem it solves, and what the core flows are.

The official guidance specifically emphasizes that this phase should not focus too early on the technology stack. First make the what and why clear, then discuss the how.

`/speckit.clarify`

This is the phase for filling gaps. Many requirements have holes the first time they are written: how should permissions work? What are the error states? Does the data need to be persisted? How should edge cases be accepted?

The value of /speckit.clarify is that it lets the Agent actively find uncertain points in the spec and write the answers back into the specification document, reducing rework later.

`/speckit.plan`

This is the technical planning phase. Only here do you start to define the framework, database, architecture, APIs, testing strategy, and constraints.

If /speckit.specify is product language, then /speckit.plan is engineering language.

`/speckit.tasks`

This step breaks the plan into executable tasks. A good task list should let the Agent advance step by step, while still letting humans understand the purpose of each step.

`/speckit.implement`

Only at the end do you enter implementation. The Agent modifies code according to the specs, plans, and tasks that have already been settled. At this point, it is no longer guessing requirements from a single large prompt; it is executing inside a set of structured documents.

Why It Fits AI Coding

Spec Kit’s value is not in any single magic command. It is in restoring the things most easily lost in AI coding:

Requirements can be reviewed;
Plans can be discussed;
Tasks can be traced;
Decisions have context;
Artifacts can enter Git history;
Teams can reuse templates and principles;
The Agent’s implementation no longer depends only on a one-time chat record.

This is especially useful for complex projects. The more a project involves multiple collaborators, long-term maintenance, or high quality requirements, the less it can rely only on temporary prompts to drive development.

Extensions and Presets

Spec Kit also provides two kinds of customization:

Extensions: add new commands, new templates, or integrations with external tools;
Presets: change the format and terminology of existing spec, plan, and task templates.

In simple terms, use an Extension when you want to add new capability; use a Preset when you want to reshape the workflow style.

For example, a team can use a Preset to require security review, compliance traceability, domain terminology, or test-first rules. It can also use an Extension to add Jira integration, code review, project health checks, and other new phases.

This means Spec Kit is not trying to lock every team into the same workflow. It provides an extensible skeleton for spec-driven development.

Who Is It For?

Spec Kit is suitable for scenarios like these:

Using an AI coding agent to prototype a new project;
Turning vibe coding into a repeatable workflow;
Standardizing the requirement and planning format before teams let AI generate code;
Projects that need clear acceptance criteria and testing requirements;
Bringing requirements, plans, tasks, and implementation history into version control;
Teams exploring GitHub Copilot, Claude Code, Codex CLI, and similar tools in a team setting.

It is not necessarily a good fit for very small one-off scripts. For problems that can be solved in a few lines of code, the full spec workflow may feel heavy. But once a task involves multiple pages, multiple modules, state management, permissions, data models, or long-term maintenance, Spec Kit’s structure starts to pay off clearly.

My Take

Spec Kit represents an important turn in AI coding tools: from “make the Agent write code faster” toward “make the Agent participate in software engineering more reliably.”

Earlier AI coding focused on prompts and model capability. Spec Kit focuses more on process, artifacts, and constraints. It reminds us that the faster AI writes code, the less we can afford to skip specs, plans, and acceptance criteria.

If you are already used to letting AI implement features directly, you can try changing the starting move with Spec Kit:

First let AI help you write the requirement as a spec, then let it write the code.

That step may look slower, but in practice it reduces the later rework of “the code is done, but it is not what I wanted.”

References

github/spec-kit

What is oh-my-pi? An AI coding assistant that connects the terminal, IDE, and debugger

Sat, 23 May 2026 19:02:20 +0800

oh-my-pi is an AI Coding Agent for the terminal and editor. It is a fork of Mario Zechner’s Pi project, extended by can1357. Its goal is not just to provide a command-line chat UI, but to connect file reading, code search, structured edits, LSP, debuggers, browsers, subagents, and multiple model providers into one coding workflow.

From the project README, it feels more like an AI coding tool layer than a simple assistant: you can use it interactively in the terminal, connect editors through ACP, or embed it in Node projects through the SDK. For people already using Claude Code, Codex CLI, Cline, Cursor, or other agent tools, the interesting part is that oh-my-pi turns many abilities that usually live in separate tools into one built-in tool surface.

What problem is it trying to solve?

For many AI coding tools, the weak point is not the model itself, but the tool interface around it. When a model wants to change code but only has rough full-file reads, fragile string replacement, and one-off shell commands, the toolchain amplifies failure.

oh-my-pi tries to reduce those common points of friction:

File reads prefer structured summaries instead of dumping whole files into context.
Search, glob, find, syntax highlighting, and token counting are implemented natively where possible, reducing dependence on external commands.
Code writes can use LSP so renames, references, and file moves behave more like IDE operations.
Debugging can use DAP tools such as lldb, dlv, and debugpy, instead of relying only on logs and guesses.
Complex tasks can be split across subagents and returned as structured results.
Edits use content anchors and previews to reduce the chance of a bad patch landing directly on disk.

These choices show that the focus is not “can the model answer?”, but “can the model reliably complete a real code change?”

Installation

The project provides several installation paths. On macOS and Linux, you can use the install script:

`1`	`curl -fsSL https://omp.sh/install \| sh`

If you use Bun, the README recommends installing the npm package globally:

`1`	`bun install -g @oh-my-pi/pi-coding-agent`

On Windows PowerShell:

`1`	`irm https://omp.sh/install.ps1 \| iex`

The README also mentions pinning versions with mise:

`1`	`mise use -g github:can1357/oh-my-pi`

Before installing, check the Bun version requirement. The README lists macOS, Linux, and Windows support, and requires bun >= 1.3.14.

Capabilities worth watching

1. Tool calling goes beyond shell commands

oh-my-pi includes tools for file reads, search, writes, edits, AST edits, browser use, task splitting, debugging, and LSP. The README mentions 32 built-in tools, 13 LSP operations, and 27 DAP operations.

That means the agent does not have to wrap everything as command-line output. Reference lookup can go through LSP, PRs and issues can be read through a unified file-like interface, and web pages or PDFs can be converted into Markdown with link structure intact before being passed to the model.

2. LSP integration is useful for real codebases

In large projects, renaming and moving files often breaks re-exports, aliased imports, barrel files, or cross-directory references. The oh-my-pi README highlights that write paths can go through LSP. For example, file renames use workspace/willRenameFiles, making edits closer to semantic IDE operations.

This is useful for everyday refactoring in TypeScript, Rust, Go, Python, and similar projects, especially in cases where manual edits are possible but easy to miss.

3. The debugger is a first-class tool

Many AI coding flows still debug by adding logs, rerunning, and reading output. oh-my-pi connects DAP debuggers to the tool surface. The README gives examples with C programs using lldb, Go services using dlv, and Python processes using debugpy.

That changes how an agent handles bugs: it can pause a process, inspect stack frames, read local variables, and then decide what to do next, instead of guessing from error text alone.

4. Hashline editing reduces patch failures

The project emphasizes Hashline, an editing approach based on content anchors. The goal is to let the model point to the content it wants to change instead of repeatedly emitting large diffs. This reduces edit failures caused by whitespace, stale context, or failed string matching.

For agent tools, this matters a lot. Even a capable model feels clumsy if the write interface keeps failing and forcing retries.

5. Subagents and workspace isolation

The README introduces a task subagent capability: a task can be split across isolated workers, and results are returned as structured objects. The project also includes workspace isolation logic for parallel tasks, branch exploration, and avoiding overlapping edits.

This fits code review, migrations, bulk fixes, and test investigation. The value is not only speed; it is also cleaner separation between different exploration paths.

6. It can inherit existing rules and configs

On first run, oh-my-pi can read rules and configuration left by other tools, including .claude, .cursor, .windsurf, .gemini, .codex, .cline, .github/copilot, and .vscode.

That is practical. Many teams have already written rules for several AI tools. Rewriting them for every new tool is expensive, so oh-my-pi tries to reuse what is already on disk.

Four entry points

The project provides four main ways to use it:

Interactive TUI: run omp directly in the terminal.
One-shot command: use omp -p to send a single prompt.
Node SDK: embed it in a Node or TypeScript project through @oh-my-pi/pi-coding-agent.
RPC / ACP: connect other programs and editors through stdio or Agent Client Protocol.

This means it is not only for individual terminal users. It also leaves room for IDEs, plugins, automation platforms, and internal tools.

Who should try it?

oh-my-pi is a good fit for:

Developers who often edit, debug, and review code in the terminal.
People already using AI Coding Agents but unhappy with file reading, patching, search, or debugging reliability.
Developers who want to connect an agent to an editor, RPC layer, or Node service.
Users who need to switch between multiple models and providers in one tool.
Tool builders interested in LSP, DAP, AST editing, and subagent workflows.

If you only want a chat-style coding assistant that works immediately, the learning curve may feel high. It is better suited to people willing to understand the toolchain and treat the agent as a configurable development environment.

What to keep in mind

First, oh-my-pi is still a fast-moving open source project. Commits are frequent, and there are many issues and pull requests, so installation and usage may change.

Second, its capabilities depend heavily on your local environment. LSP, debuggers, Bun, model-provider authentication, terminal setup, and Windows or Unix differences can all affect the experience.

Third, having many built-in tools does not mean every scenario should enable everything. In practice, it is better to enable the tools needed for the task and configure rules, permissions, and workspace boundaries clearly.

Fourth, an AI Agent can write code, but it can also change the wrong code. Even with previews and content-anchored edits, important projects still need version control, tests, and human review.

Summary

The interesting part of oh-my-pi is not that it is another AI terminal shell. It is that it reorganizes the tool layer that often holds AI coding back: file reading, search, editing, LSP, debugging, browser access, subagents, and SDK integration all sit inside one agent workflow.

It is worth watching for people who care about AI coding infrastructure, and for developers comparing different Coding Agent approaches. The competition in AI coding tools is no longer just about model answer quality. It is also about who can connect models reliably to real codebases, real debugging workflows, and real team rules. oh-my-pi is an ambitious open source attempt in that direction.

References:

GitHub project: https://github.com/can1357/oh-my-pi
Official site: https://omp.sh/
SDK documentation: https://omp.sh/docs/sdk

poc-lab Patch Verification: Confirm Whether Recent High-Severity Vulnerabilities Are Fixed, Including Chrome CSSFontFeatureValuesMap UAF, NGINX Rift, Dirty Frag, and Fragnesia

Fri, 22 May 2026 23:13:24 +0800

poc-lab is a repository of PoCs and reproduction scripts for recently disclosed high-severity vulnerabilities. It focuses on fresh and impactful CVE reproduction material across Linux kernel, Windows, macOS, containers, service components, and browser-related vulnerabilities.

From its positioning, the repository is closer to a security research knowledge base than a one-click toolkit for general users. Each vulnerability directory usually includes PoC scripts, build files, and documentation, helping researchers understand impact, reproduction conditions, and references.

Main project contents

The repository is currently organized by vulnerability identifier or public vulnerability name. The full listed vulnerability names include:

CVE-2026-2441: Chrome CSSFontFeatureValuesMap use-after-free, also listed as Chrome CSSFontFeatureValuesMap UAF.
CVE-2026-27623: Pre-Authentication Denial of Service from malformed RESP request.
CVE-2026-31429: Slab Cross-Cache, a Linux kernel slab cross-cache exploitation direction.
CVE-2026-31431: Copy Fail, a Linux kernel related vulnerability.
CVE-2026-31635: DirtyDecrypt, a system security boundary related vulnerability.
CVE-2026-42945: NGINX Rift, a high-severity NGINX related vulnerability.
CVE-2026-43284: Dirty Frag, a Linux kernel related vulnerability.
CVE-2026-43494: PinTheft, a permission or credential security boundary related vulnerability.
CVE-2026-43500: Dirty Frag, a Linux kernel related vulnerability.
CVE-2026-46300: Fragnesia, a Linux kernel related vulnerability.
CVE-2026-46333: SSH Keysign pwn, an SSH keysign security boundary related vulnerability.

These names show that the project is not limited to one platform. It spans browsers, the Linux kernel, server components, and operating system security boundaries. For people working on vulnerability analysis, patch validation, detection rule writing, and security training labs, this kind of material can be useful reference material.

Directory structure

The project README says each vulnerability directory is intended to follow a consistent structure. Common files include:

exploit.py or exploit.sh: PoC script
README.md: vulnerability information, affected versions, reproduction steps, and references
build or related build files: used to compile or prepare the reproduction environment

The repository structure roughly looks like this:

poc-lab/
├── CVE-2026-XXXXX/
│   ├── exploit
│   ├── build
│   └── README.md
├── VULN-NAME/
│   ├── exploit.sh
│   └── README.md
└── ...

If a vulnerability already has a CVE identifier, the directory usually uses that CVE name. If there is no assigned CVE yet, it may use the public vulnerability name.

Suitable use cases

This type of repository is more suitable for the following purposes:

Security researchers reproducing vulnerability trigger conditions.
Enterprise security teams verifying whether patches are effective.
Detection engineers writing IDS, EDR, WAF, or log detection rules.
Security courses or internal training that build isolated lab environments.
Researchers comparing exploitation prerequisites and defensive ideas across vulnerabilities.

It is not suitable for direct production scanning, and it should not be used against unauthorized systems. The value of a PoC is to help understand risk and verify defenses, not to expand attack surface.

What to pay attention to when using it

First, testing must happen in an isolated environment. Vulnerability reproduction may trigger crashes, privilege changes, file corruption, or service outages. It should not be run directly on office machines, production servers, or third-party systems.

Second, read the README.md inside each vulnerability directory first. Different PoCs have different dependencies, target versions, trigger conditions, and risks. Reading only the root README is not enough.

Third, confirm the authorization boundary. Even if a PoC is public, running it against a system you do not own or have explicit permission to test can create legal and compliance risk.

Fourth, after reproduction, return to the defensive workflow. That includes confirming patched versions, adding detection rules, checking exposed assets, updating asset inventories, and documenting incident response procedures.

Why this kind of repository matters

In recent years, the time between high-severity vulnerability disclosure and public reproduction details has become shorter. For defenders, advisories and CVE descriptions are often not enough. Teams also need to understand trigger conditions, exploitation limits, and detection signals in realistic environments.

The value of repositories such as poc-lab is that they organize scattered high-severity vulnerability reproduction material by directory, helping researchers complete risk validation more quickly. It does not replace official advisories, vendor patches, or security baselines, but it can serve as supporting material for patch verification and detection engineering.

There is also risk. Public PoCs lower the reproduction threshold. If an organization does not have timely patch management and asset inventory capabilities, public reproduction material can widen the exposure window. For enterprise security teams, tracking these projects matters, but building a rapid assessment and remediation process matters even more.

Summary

poc-lab is a collection of PoCs and reproduction scripts for recent high-severity vulnerabilities, covering Linux kernel, browsers, service components, and operating system security issues. It is suitable for security research, patch verification, and detection rule development, but it must be used within authorization, isolation, and responsible disclosure boundaries.

For general readers, the point is not “how to run a PoC.” The more important lesson is that after high-severity vulnerabilities become public, verification and exploitation move faster. Security teams need to complete asset identification, patch assessment, detection updates, and risk closure more quickly.

References:

GitHub project: https://github.com/Unclecheng-li/poc-lab/tree/main
Chinese README: https://github.com/Unclecheng-li/poc-lab/blob/main/README.zh-CN.md

GitHub AI Open Source Project Categories: From Coding Agent to RAG Knowledge Bases

Thu, 21 May 2026 08:53:13 +0800

This page groups GitHub AI projects by application direction, covering AI coding and Coding Agents, agent skills and workflows, RAG and knowledge bases, multimodal creation, local models and inference, vertical applications and automation, and AI application development infrastructure. New projects can be added later using the same structure.

Category Summary

Category	Projects	Who Should Start Here
AI Coding and Coding Agents	22	Users who often work with Claude Code, Codex, Cursor, terminal agents, or repository automation
Agent Skills and Workflows	7	Users who want to standardize AI coding, research, or content workflows
RAG, Knowledge Bases, and Memory	7	Users who need document retrieval, knowledge bases, long-term memory, web crawling, or structured extraction
Vertical Applications and Automation	7	Users looking at finance, trading, Xianyu monitoring, desktop control, browser automation, and other applied scenarios
Multimodal and Content Creation	5	Users working on images, video, transcription, prompt libraries, and content distribution
AI Application Development Infrastructure	5	Developers building AI apps, browser automation, or Prompt/MCP toolchains
Local Models and Inference	1	Users interested in local DeepSeek, inference engines, and hardware adaptation

The distribution shows several high-frequency directions in current AI open source projects: AI coding tools dominate, followed by agent workflows, RAG knowledge bases, and concrete application scenarios. Pure model inference projects are fewer here because much local deployment content is organized around models, GPUs, or deployment plans rather than a single GitHub project.

AI Coding and Coding Agents

This group focuses on code understanding, code modification, engineering workflows, and terminal agents. It is the largest group, with 22 projects.

Project	Article	GitHub	Core Use	Best For
Ralph	Ralph: turning Claude Code and Amp into an autonomous development loop	snarktank/ralph	Drive Claude Code / Amp through PRD, planning, execution, and review loops	Users who want a straighter agent coding process
Claude-Mem	Claude-Mem: long-term cross-session memory for Claude Code	thedotmack/claude-mem	Add cross-session memory to Claude Code	Heavy Claude Code users
Claude Code Hooks Mastery	Claude Code Hooks Mastery: getting started with 13 hooks lifecycle stages	disler/claude-code-hooks-mastery	Learn Claude Code hooks lifecycle and automation control	Users who want to customize Claude Code workflows
Compound Engineering Plugin	Compound Engineering Plugin: turning AI coding into planning, execution, and review loops	EveryInc/compound-engineering-plugin	Split AI coding into planning, execution, and review cycles	Users who care about engineering discipline in AI coding
free-claude-code	free-claude-code: connecting Claude Code to OpenRouter, DeepSeek, and local models	Alishahryar1/free-claude-code	Use a proxy to connect Claude Code to different model backends	Users who want to reduce Claude Code cost
Hermes Agent	What is Hermes Agent: overview, strengths, quick start, and OpenClaw comparison	NousResearch/hermes-agent	Local agent framework with tool calling and task execution	Users who want to run local agents
OpenHarness	What OpenHarness can do as an open source agent harness	HKUDS/OpenHarness	Agent harness and multi-agent execution framework	Users researching agent orchestration
CodexBridge	Using Codex with domestic LLMs: OpenAI-compatible APIs and CodexBridge	begonia599/CodexBridge	Connect Codex to OpenAI-compatible model APIs	Users who want Codex with domestic models
ccx	Using CCX to manage OpenAI-compatible APIs for Codex and domestic models	BenedictKing/ccx	Manage API proxies for Claude, Codex, Gemini, and more	Multi-model switching users
cc-haha	cc-haha: a desktop workspace for Claude Code	NanmiCoder/cc-haha	Desktop workspace and Computer Use entry for Claude Code	Claude Code users who prefer a GUI
DeepSeek-TUI	DeepSeek-TUI: turning DeepSeek V4 into a terminal coding agent	Hmbown/DeepSeek-TUI	Run a DeepSeek coding agent in the terminal	DeepSeek and command-line users
Open Design	Open Design: turning Claude Code and Codex into AI design tools	nexu-io/open-design	Bring Claude Code / Codex into design generation	Users who want agents for design prototypes
agentmemory	agentmemory: persistent memory for Claude Code, Codex, and Cursor	rohitg00/agentmemory	Add persistent memory to coding agents	Developers maintaining long-running projects
Graphify	Graphify: turning a codebase into an AI-queryable knowledge graph	safishamsi/graphify	Convert a codebase into a knowledge graph to reduce repeated file reads	Large-codebase users
oh-my-pi	What is oh-my-pi? An AI coding assistant that connects terminal, IDE, and debugger	can1357/oh-my-pi	Connect terminal, IDE, LSP, and debugger as a local AI coding console	Developers who want to unify CLI and IDE workflows
Claude Plugins Official	Claude Code now has a plugin directory: what to install, how to install it, and what to watch	anthropics/claude-plugins-official	Official Claude Code plugin directory and installation entry point	Users who want to extend Claude Code
CodeGraph	What is CodeGraph? A local code map for Claude Code, Codex, and Cursor	colbymchenry/codegraph	Generate local indexes and relationship graphs to help Coding Agents understand projects	Developers maintaining medium-to-large codebases
CC Switch	CC Switch: managing Claude Code, Codex, Gemini CLI, and OpenClaw in one desktop tool	farion1231/cc-switch	Manage multiple AI CLI tools and account/config switching	Users of multiple CLI tools
Warp	Warp open source: from terminal to Agentic Development Environment	warpdotdev/warp	Agentic terminal and development environment	Heavy terminal users
opencode	opencode vs Claude Code vs Codex: open source AI coding tools guide	anomalyco/opencode	Open source AI coding agent	Users looking for Claude Code / Codex alternatives
9Router	9Router: connecting Claude Code, Codex, and Cursor to one AI router	decolua/9router	AI coding model routing and token cost control	Multi-tool, multi-model users
goose	goose: an open source AI Agent across desktop, CLI, and API	aaif-goose/goose	Open source agent across desktop, CLI, and API	Users who want a general agent workspace

Agent Skills and Workflows

This group focuses on turning AI capabilities into repeatable skills, processes, and specifications. It includes 7 projects.

Project	Article	GitHub	Core Use	Best For
mattpocock/skills	Rejecting Vibe Coding: Matt Pocock’s skills repo adds engineering constraints to AI coding	mattpocock/skills	Use skills to constrain AI coding workflows	Users who want engineering discipline for agents
Superpowers	Superpowers: bringing coding agents back into engineering workflows	obra/superpowers	Agentic skills framework and software development methodology	Users who want systematic coding-agent workflows
Prompt-Vault	Prompt-Vault: a prompt specification library for testing AI coding ability	w512/Prompt-Vault	Collect prompt specs for testing AI coding ability	Model and tool evaluators
web-video-presentation	web-video-presentation: an agent skill for turning articles into recordable web videos	ConardLi/garden-skills	Turn articles into recordable web videos	Content creators and automation users
nuwa-skill	nuwa-skill: making “distilling a person” into an executable workflow	alchaincyf/nuwa-skill	Recreate a person’s expression and thinking flow with a skill	Users building style-based agents
Scientific Agent Skills	Scientific Agent Skills: giving research workflows to AI agents	K-Dense-AI/scientific-agent-skills	Skill collection for scientific workflows	Researchers, data analysts, and technical writers
easy-vibe	easy-vibe: a learning map for Vibe Coding beginners	datawhalechina/easy-vibe	Learning map for Vibe Coding	AI coding beginners

RAG, Knowledge Bases, and Memory

This group addresses document retrieval, knowledge base construction, long-term memory, and structured extraction. It includes 7 projects.

Project	Article	GitHub	Core Use	Best For
LangExtract	Google LangExtract: extracting structured data from long text with LLMs	google/langextract	Extract structured information from long text	Information extraction and data processing users
qmd	qmd: local Markdown document search for AI agents	tobi/qmd	Local Markdown document search	Users managing knowledge in Markdown
Firecrawl	Firecrawl: web search, crawling, and interaction API for AI agents	firecrawl/firecrawl	Web crawling, search, and structured data entry point	RAG and agent data-ingestion users
RAGFlow	RAGFlow: features and usage of an open source RAG engine	infiniflow/ragflow	Open source RAG engine	Enterprise knowledge base and document Q&A users
OpenHuman	OpenHuman: the desktop route for open source personal AI agents	tinyhumansai/openhuman	Local-first personal AI agent and memory layer	Users who want to integrate personal data
OpenKB	OpenKB: compiling documents into continuously updated LLM knowledge bases	VectifyAI/OpenKB	Compile documents into updatable knowledge bases	Documentation knowledge-base maintainers
PageIndex	PageIndex: reasoning-style RAG document indexing without vector databases	VectifyAI/PageIndex	Reasoning-style document indexing without vector databases	Users watching new RAG approaches

Multimodal and Content Creation

This group covers image, video, transcription, and content distribution scenarios. It includes 5 projects.

Project	Article	GitHub	Core Use	Best For
rembg	rembg: local image background removal tool	danielgatis/rembg	Local image background removal	E-commerce, design, and image-processing users
awesome-gpt-image-2-prompts	GPT-Image 2 prompt library: e-commerce, posters, portraits, and UI	EvoLinkAI/awesome-gpt-image-2-prompts	GPT-Image 2 prompts and case library	AI art and prompt users
faster-whisper	faster-whisper: a faster Whisper transcription engine	SYSTRAN/faster-whisper	High-performance speech-to-text	Subtitle, transcription, and speech-processing users
Pixelle-Video	Pixelle-Video: an open source AI engine for generating short videos from one topic	AIDC-AI/Pixelle-Video	One-topic short-video generation workflow	Short-video and AIGC creators
AiToEarn	Too many content platforms? AiToEarn uses AI agents to help creators save effort	yikart/AiToEarn	Multi-platform content distribution and creator automation	Content operators and creators

Local Models and Inference

This group focuses on local model runtime and inference experiments. It currently has fewer projects, with 1 project.

Project	Article	GitHub	Core Use	Best For
ds4	Running DeepSeek 4 locally: Antirez ds4 on Apple Silicon Mac	antirez/ds4	Experiment with running DeepSeek 4 on Apple Silicon	Local model and inference experiment users

Vertical Applications and Automation

This group applies agents or AI capabilities to finance, trading, browsers, desktops, e-commerce monitoring, and other concrete scenarios. It includes 7 projects.

Project	Article	GitHub	Core Use	Best For
TradingAgents-CN	TradingAgents-CN: a multi-agent financial trading research framework for Chinese users	hsliuping/TradingAgents-CN	Multi-agent financial trading research framework	Quant, finance, and agent researchers
FinceptTerminal	FinceptTerminal: open source financial terminal, quant research, and AI Agent workspace	Fincept-Corporation/FinceptTerminal	Financial terminal, quant research, and AI agent workspace	Financial analysis and quant users
Anthropic financial-services	Anthropic financial-services: reusable templates for financial agent scenarios	anthropics/financial-services	Financial services agent templates	Users building financial AI solutions
ai-goofish-monitor	ai-goofish-monitor: open source AI monitoring system for Xianyu products	Usagi-org/ai-goofish-monitor	AI product monitoring and Xianyu automation	Second-hand marketplace monitoring users
CloakBrowser	CloakBrowser: a more human-like browser for Playwright and Puppeteer	CloakHQ/CloakBrowser	More human-like browser automation environment	Browser automation and agent operation scenarios
UI-TARS-desktop	Let AI operate the computer? UI-TARS-desktop connects desktop, browser, and tools	bytedance/UI-TARS-desktop	Desktop, browser, and tool operation agent	Users who want AI to operate computers
AI-Trader	What is AI-Trader: a platform for AI agents to publish trading signals and run simulations	HKUDS/AI-Trader	AI agent trading signals and simulated trading platform	Financial agent and trading researchers

AI Application Development Infrastructure

This group provides foundational components for building AI applications and agent toolchains. It includes 5 projects.

Project	Article	GitHub	Core Use	Best For
Prompt Optimizer	Prompt Optimizer: open source prompt optimization, testing, and MCP tools	linshenkx/prompt-optimizer	Prompt optimization, testing, and MCP tools	Prompt engineering and app-tuning users
Playwright CLI	Playwright CLI basics: installation, skills, sessions, and common commands	microsoft/playwright-cli	Browser automation CLI for coding agents	Agent users who need browser operation
Vercel AI SDK	What is Vercel AI SDK? A unified toolkit for TypeScript AI apps	vercel/ai	TypeScript AI application SDK	Front-end and full-stack developers
CLIProxyAPI	CLIProxyAPI: wrapping Codex, Claude Code, and Gemini CLI into unified APIs	router-for-me/CLIProxyAPI	Wrap multiple AI CLIs and OAuth login states as compatible APIs	Users who want unified access to Codex, Claude Code, and Gemini CLI
CLIProxyAPI Management Center	CLIProxyAPI Management Center: a visual admin console for CLIProxyAPI	router-for-me/Cli-Proxy-API-Management-Center	Web admin UI for CLIProxyAPI configuration, accounts, logs, and OAuth	Users running CLIProxyAPI as a team gateway or account pool

Do Not Push API Keys to GitHub: A Secret-Leak Prevention Guide for AI Coding

Sat, 16 May 2026 16:26:50 +0800

AI coding lowers the barrier to building software, but it also brings many engineering security problems to beginners and non-engineering users.

One of the most common incidents is pushing API Key, Secret, Token, database connection strings, or .env files to a public repository. Locally, these files may look like ordinary configuration that keeps the app running. Once they enter a public GitHub repository, they become credentials that can be scanned, called, and abused automatically.

Secret leaks are not rare. GitGuardian’s 2026 report says public GitHub commits in 2025 contained about 28.65 million new hardcoded credentials, and AI-service credential leaks grew 81% year over year. The issue is no longer just carelessness. AI coding, rapid prototyping, and public hosting are amplifying the scale.

Why Beginners Leak Keys More Easily

Many AI agents and small tools have two “repositories”: one on the local disk, and one visible to the world on GitHub. The problem is that beginners often do not understand the boundary between the two.

During local development, config.json, .env, and settings.yaml may contain API keys. After git add ., git commit, and git push, those files may be uploaded in full. Once a repository is public, scanning bots do not need to understand your business logic. They only need to match a secret pattern.

AI coding makes this worse:

AI-generated examples may place OPENAI_API_KEY = "sk-..." directly in source code.
Beginners often hardcode secrets in frontend code, scripts, or config files just to get the project running.
Many vibe coding platforms can deploy apps directly without going through GitHub push protection.
Users may not know which files, APIs, or default permissions exist inside an AI-generated project.

In short, AI can help you build something that runs faster. It does not automatically take over the security responsibility.

`.gitignore` Is Not Decoration

Git manages version history, GitHub hosts code, and .gitignore tells Git which files should not enter that history.

A basic AI project should at least ignore these:

.env
.env.*
*.key
*.pem
config.local.*
secrets.*
credentials.*

But .gitignore alone is not enough. It only prevents untracked files from being added later. If a secret file has already been committed, adding it to .gitignore will not remove it from history.

A safer habit is:

Create .gitignore at the beginning of a project.
Store API keys only in environment variables or local config.
Provide .env.example with placeholders, not real secrets.
Run a secret scanner before committing, such as gitleaks, trufflehog, or GitHub Secret Scanning.

Deleting the File Is Not Enough

If a key has already been pushed to a public repository, the first reaction should not be “delete the file and commit again.” Revoke or rotate the key first.

Git records history. Even if the latest commit removes the file, old commits, forks, clones, caches, and scanners may still contain it. GitHub’s documentation also recommends revoking or rotating passwords, tokens, and credentials as the first step.

Recommended order:

Revoke the old key in the provider console and create a new one.
Check billing, usage logs, suspicious IPs, and unusual traffic.
Remove hardcoded secrets and switch to environment variables or a secret manager.
Clean sensitive files from repository history with git filter-repo or BFG.
Enable GitHub Secret Scanning and Push Protection.
Check CI/CD, deployment platforms, cloud functions, and frontend build artifacts for the old key.

For OpenAI, Anthropic, DeepSeek, cloud providers, payment services, email services, and databases, a leaked key can lead to more than unexpected bills. It may expose data, enable abuse, affect the supply chain, or get business accounts banned.

Real Secrets Do Not Belong in Frontend Code

Many beginners put API keys into frontend JavaScript because the page works:

`1`	`const apiKey = "sk-xxxxxxxx";`

This is effectively public. Browser code, network requests, source maps, and build artifacts can all be inspected. Any key that must remain secret should not appear on the client side.

The correct approach is to let the frontend call your own backend, and let the backend read environment variables and call the third-party API:

// frontend
await fetch("/api/chat", {
  method: "POST",
  body: JSON.stringify({ message })
});

Then the server uses the environment variable:

1
2

// server
const apiKey = process.env.OPENAI_API_KEY;

This keeps the secret in the server environment instead of exposing it to every visitor.

Vibe Coding Does Not Remove Security Responsibility

Vibe coding is not only a GitHub leak problem. Many apps are published directly from AI coding platforms to the public internet, bypassing traditional code review, repository scanning, and security testing.

Recent RedAccess research found a large number of publicly accessible assets generated or hosted by AI coding tools, some exposing corporate data, personal information, or internal files. The lesson is simple: when “can deploy” becomes too easy, people often forget to ask “should this be public?”, “should this only be internal?”, and “does it have access control?”

Before publishing an AI-generated app, ask:

Does this app really need public access?
Does it have login, authentication, and permission isolation?
Are database URLs, API keys, tokens, or webhook URLs exposed in frontend code?
Are third-party API quota, domain, permission, and expiry limits configured?
Can keys be disabled and deployments rolled back quickly after an incident?

AI-generated code still needs security review. The less code you personally wrote, the less you should assume it is safe.

Checks to Run Now

Start with your own GitHub account. Search your username together with:

API_KEY
SECRET
TOKEN
OPENAI_API_KEY
ANTHROPIC_API_KEY
DEEPSEEK_API_KEY
.env
config
credentials

If you find a real key, rotate first and clean up later. If it ever entered a public repository, treat it as leaked.

For future AI projects, use a fixed process:

Write .gitignore before writing business code.
Use .env.example to document required variables.
Put all secrets in environment variables, not source code.
Give API keys minimal permissions, quotas, and expiry dates.
Enable GitHub Secret Scanning and Push Protection.
Let AI help with a security review before publishing, but do not trust AI alone.

The danger of AI coding is not simply that it may write bad code. It gives many people the ability to publish unsafe apps to the public internet for the first time. Writing fast is not the problem. Handing out secrets, data, and permissions is.

GitHub on KnightLi Blog

What Is GitHub Spec Kit? Using Spec-Driven Development to Tame AI Coding

What Is Spec Kit?

Basic Usage Flow

It Changes the Entry Point of AI Coding

How to Understand the Core Commands

/speckit.constitution

/speckit.specify

/speckit.clarify

/speckit.plan

/speckit.tasks

/speckit.implement

Why It Fits AI Coding

Extensions and Presets

Who Is It For?

My Take

References

What is oh-my-pi? An AI coding assistant that connects the terminal, IDE, and debugger

What problem is it trying to solve?

Installation

Capabilities worth watching

1. Tool calling goes beyond shell commands

2. LSP integration is useful for real codebases

3. The debugger is a first-class tool

4. Hashline editing reduces patch failures

5. Subagents and workspace isolation

6. It can inherit existing rules and configs

Four entry points

Who should try it?

What to keep in mind

Summary

poc-lab Patch Verification: Confirm Whether Recent High-Severity Vulnerabilities Are Fixed, Including Chrome CSSFontFeatureValuesMap UAF, NGINX Rift, Dirty Frag, and Fragnesia

Main project contents

Directory structure

Suitable use cases

What to pay attention to when using it

Why this kind of repository matters

Summary

GitHub AI Open Source Project Categories: From Coding Agent to RAG Knowledge Bases

Category Summary

AI Coding and Coding Agents

Agent Skills and Workflows

RAG, Knowledge Bases, and Memory

Multimodal and Content Creation

Local Models and Inference

Vertical Applications and Automation

AI Application Development Infrastructure

Do Not Push API Keys to GitHub: A Secret-Leak Prevention Guide for AI Coding

Why Beginners Leak Keys More Easily

.gitignore Is Not Decoration

Deleting the File Is Not Enough

Real Secrets Do Not Belong in Frontend Code

Vibe Coding Does Not Remove Security Responsibility

Checks to Run Now

References

`/speckit.constitution`

`/speckit.specify`

`/speckit.clarify`

`/speckit.plan`

`/speckit.tasks`

`/speckit.implement`

`.gitignore` Is Not Decoration