Portable, vendor-neutral engineering agent skills (SKILL.md) for AI coding agents: architecture, OWASP…
Engineering Standards: Portable Agent Skills
以下摘录自该仓库的 README(片段) · 在 GitHub 读完整 README →
Made and kept up by **Tech Fleet**.
This repo holds 16 **skills**. A skill is a short, expert checklist. An AI coding
tool, or a person, reads it while doing the work. Each skill holds the know-how a
good senior engineer uses on a change: how to make it safe, how to test it, how
to ship it, and why a choice was made. With these skills, every change can meet
the same bar. Not just the changes an expert happens to look at.
The 16 skills come in two groups, all under .claude/skills/ so a clone
loads them automatically:
- **13 engineering skills.** They cover security, testing, architecture, releases,
running in production, data rules, decision records, code review, rule-writing,
provable checks, honest self-review, and picking a design pattern.
- **3 requirements skills.** They make what you build work for everyone: every
browser and device, every ability, and anyone no matter their background.
The skills never name a specific AI model, company, or product. So they work with
any AI tool. They also read fine as plain notes for a person.
> **New here?** Think of a skill as a short checklist your AI coding tool reads on
> its own when it fits the task. For example: "You are changing the login code, so
> here is how to keep it safe." You do not have to remember to ask for it. Each
> skill says when it should load.
A few words used here
- **Agent / AI coding tool:** an AI assistant that writes code for you.
- **LLM:** the AI model behind the tool.
- **BDD:** a way to write tests as plain sentences.
- **ADR:** a short note that records why a decision was made.
- **SRE:** the work of keeping a system healthy in production.
- **CI:** the automatic checks that run when you push code.
- **PR:** a pull request, the way you propose a change.
- **Gate:** a check that must pass before a change can merge.
---
Table of contents
- Why this exists
- The skills
- Requirements skills (works for everyone)
- What is a "skill"?
- Install and use
- Always-on: run every skill on every task
- How a skill gets chosen and enforced
- Set it up and keep it current: the bootstrap
- Adopt the architecture gate, step by step
- How the skills fit together
- Design principles
- Contributing
- Repository layout
- License
- Acknowledgements
---
Why this exists
The thing that makes software production-ready is often **knowledge stuck in
people's heads**. The security engineer knows the lockout check must run before
the delete. The SRE wants a reliability target set before launch. The architect
knows why they picked one database over another. Not everyone has this knowledge.
It is easy to forget when a deadline is close. And it is almost never used on
every single change.
These skills take that knowledge and put it where the tool can read it. When
someone, or an AI tool, works on a feature, it pulls in the right skill and uses
it while doing the work. It checks the input for threats, writes the tests,
records the decision, and plans a safe database change. You do not have to hope a
reviewer catches the gap later.
Two kinds of people get value from the same files:
- **Engineers and AI-tool users** get a ready-made standard for security,
testing, architecture, safe releases, and running the system.
- **Learners** get a clear, real picture of what careful, senior-level work looks
like: the checklists, the trade-offs, and the "do not ship until..." rules.
---
The skills
Each folder is one skill that stands on its own. The **When it kicks in** column
is a short version of the skill's description. That text is what the AI tool
uses to decide when to load the skill on its own.
| Skill | What it does | When it kicks in | Extra files |
|---|---|---|---|
| enterprise-architecture-standards | Designs the system and its data with real trade-offs: structure, resilience, and scale. | You design, build, or rework a service, database, API, or system. | 9 refs |
| pattern-selector | Picks the software pattern that fits, or none, with the pros, cons, and trade-offs. | You design or rework any feature, class, module, or data flow; "which pattern?" | 5 refs, 1 script |
| architectural-decision-records | Writes down why a big choice was made. | You make an important choice: database, framework, contract, or login model. | 5 refs, 2 scripts |
| owasp-secure-coding-bdd | Turns OWASP threat-modeling into runnable @security tests. | You touch login, input, sessions, files, APIs, permissions, dependencies, or AI code. | 15 refs |
| bdd-comprehensive-testing | Writes every use case and audience as plain-sentence tests, checked on every push. | Any behavior change: build, add, fix, or push. | 4 refs, 5 scripts |