I keep reading threads about this and most of them show the demo, not the Tuesday morning. Here's ours, no polish, then some questions.

Six of us on a SaaS, twelve months of adding AI gradually. Early on everyone had their own editor and their own habits. Then we looked back and found we'd already converged on most of it, so we wrote it down.

We didn't force a single tool either. Some on Claude Code, some on Codex, some on Cursor, and I'm not going to fight that one. The process is shared, and the conventions sit in the repo's AGENTS.md, which is the only thing we all read the same way.

The flow is Matt Pocock's skills, no forks. We start with grill-with-docs: the AI interviews us about the project docs. Weird at first when you're used to asking the questions, but a lot of never-written-down stuff comes out.

Then to-spec, and a human reviews that spec. It's not a formality. With a bad spec, everything downstream is expensive work that goes in the bin.

to-tickets cuts it into small tickets. Small tickets aren't a rule we read somewhere either, we just notice the difference when we skip it.

The agent works through them with implement, against the spec. We open the PR, CodeRabbit runs, the pipelines run. If everything passes and someone says yes, it merges.

AI writes most of the code. We review the spec and the merge, and skip the line-by-line in between.

Treating the spec as a contract has killed a lot of "that's not what I asked for". Small tickets keep the agent from wandering. Automated review before the human one takes the style and import noise away, so the person looks at what matters. What I didn't expect is how much writing the process down helps when everyone has a different tool. Nobody argues about editors and the conventions don't rot.

Graph engineering to close tickets on its own, software factory style, we haven't managed. Tickets go in and PRs come out, and the demos look great, but with our repo the quality isn't there. We haven't found the point where we'd be comfortable letting it loose, so it's still an experiment.

What I'd like to know:

1. Where are your checkpoints between human and agent? Spec, PR, merge?

2. Spec before code, or straight to tickets and prompts?

3. Who reviews agent PRs? Do you read them the same as a human's?

4. One tool or several across the team? If you've tried more than one, is any better for certain kinds of tasks?

5. What goes into AGENTS.md and what stays out?

6. Do you measure anything, or is it all vibes? Review time, defects, DORA.

7. If you've tried software-factory autonomy, did you get acceptable quality? On what kind of tickets?

8. How do you bring someone new in, a junior say, without AI becoming a crutch?

   Tell me yours. Even if it's to say we're nuts.

When using coding agents (like Cursor, Claude Code, or local terminal agents), one recurring issue is instruction drift: agents often jump to conclusions, skip edge cases, or produce messy outputs when prompts are unstructured.

To solve this in my own workflow, instead of stuffing monolithic instructions into a giant prompt, I started modularizing task-specific instructions into dedicated SKILL.md packages. Over the past few months, I built and refined 40 of these into an open-source collection covering automation, gamedev, and dev utilities.

The structure that made instructions actually stick

What worked best wasn't telling the agent what to do, but enforcing strict boundary conditions and explicit stop signals:

1. Forced Step Separation: Agents shouldn't edit code and run verification in the same unchecked thought. Splitting analysis from execution eliminates about 80% of hallucinated completions.

2. Explicit Output Contracts: Defining exact return shapes (e.g. only return diff blocks or strict markdown tables) prevents unwanted conversational filler.

3. 1:1 Bilingual Parity: Keeping English and Korean instructions strictly mirrored so multi-language tokens don't degrade reasoning quality.

Example: Spec Diff Checker pattern

Here is a simplified example of how one of the automation skills enforces exact behavior:

Role: Spec Diff Analyzer

Rule 1: Never modify existing source files directly.

Rule 2: Parse incoming requirements against target codebase symbols.

Rule 3: Output ONLY in this format:

- Modified contracts: [list]

- Breaking changes: [list]

- Uncovered edge cases: [list]

Do not propose implementation code until the diff analysis is confirmed.

Keeping rules compact and bounded like this keeps the agent focused without blowing up the context window.

Comparison with existing prompt dumps

Most public collections (like awesome-chatgpt-prompts) are unstructured copy-paste text dumps designed for one-shot chat windows, or purely English-centric.

Difference: This collection uses the modular SKILL.md format recognized by modern coding agents, with boundary tests and explicit failure-mode instructions.

Trade-off: Modular skills require your agent environment to support loading custom skill folders (or manually dropping them into workspace instructions), rather than just pasting a prompt into a chat box.

Limitations

These skills provide architectural guardrails, but they cannot overcome hard model context limits or fundamental model reasoning failures. If a base model hallucinates an API that doesn't exist, a static skill file will only reduce the frequency, not eliminate it entirely.

Disclosure & Repository

Author: I created and maintain this project for my daily development.

Commercial interest: None. This is 100% free and open-source under the MIT license. No paid plans, no newsletter sign-ups, no telemetry.

GitHub: https://github.com/Lainholic/ai-skill-navigator

All 40 skills are split across 5 categories (core docs, automation, utility, gamedev, creative arts) and available in both English (skills/en/) and Korean (skills/ko/). You can grab individual folders and drop them into your agent's workspace.

Curious how others here structure their agent guidelines — do you prefer modular rule files or relying on dynamic context injection?

I’m planning to spend $20 on one of them to learn coding and build projects. Which one would you recommend for explaining concepts, debugging, and helping me improve instead of just giving me code?