opencode-skills-collection 3.0.44 → 3.0.46
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/bundled-skills/.antigravity-install-manifest.json +15 -1
- package/bundled-skills/agent-squad/SKILL.md +190 -0
- package/bundled-skills/agent-squad/alex/SKILL.md +129 -0
- package/bundled-skills/agent-squad/aria/SKILL.md +140 -0
- package/bundled-skills/agent-squad/dep/SKILL.md +146 -0
- package/bundled-skills/agent-squad/luna/SKILL.md +139 -0
- package/bundled-skills/agent-squad/mason/SKILL.md +124 -0
- package/bundled-skills/agent-squad/max/SKILL.md +118 -0
- package/bundled-skills/agent-squad/quinn/SKILL.md +143 -0
- package/bundled-skills/agent-squad/rex/SKILL.md +121 -0
- package/bundled-skills/atlas-contract/SKILL.md +650 -0
- package/bundled-skills/atlas-ledger/SKILL.md +248 -0
- package/bundled-skills/docs/integrations/jetski-cortex.md +3 -3
- package/bundled-skills/docs/integrations/jetski-gemini-loader/README.md +1 -1
- package/bundled-skills/docs/maintainers/repo-growth-seo.md +3 -3
- package/bundled-skills/docs/maintainers/skills-update-guide.md +1 -1
- package/bundled-skills/docs/users/bundles.md +1 -1
- package/bundled-skills/docs/users/claude-code-skills.md +1 -1
- package/bundled-skills/docs/users/gemini-cli-skills.md +1 -1
- package/bundled-skills/docs/users/getting-started.md +1 -1
- package/bundled-skills/docs/users/kiro-integration.md +1 -1
- package/bundled-skills/docs/users/usage.md +4 -4
- package/bundled-skills/docs/users/visual-guide.md +4 -4
- package/bundled-skills/fsi-compliance-checker/SKILL.md +125 -0
- package/bundled-skills/fsi-compliance-checker/mas-trm.md +99 -0
- package/bundled-skills/fsi-compliance-checker/pci-dss.md +89 -0
- package/bundled-skills/not-a-vibe-coder/SKILL.md +147 -0
- package/bundled-skills/papers-skill/SKILL.md +194 -0
- package/bundled-skills/papers-skill/scripts/papers.py +271 -0
- package/bundled-skills/polis-protocol/SKILL.md +13 -9
- package/bundled-skills/zipai-optimizer/SKILL.md +40 -68
- package/package.json +1 -1
- package/skills_index.json +309 -1
|
@@ -0,0 +1,248 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: atlas-ledger
|
|
3
|
+
description: "Companion to atlas-contract. Auto-invoked by its Final Audit on caught drift; also use after Post Reviews or user requests to record a mistake. Distills drift into WHEN/DON'T/INSTEAD clauses, writes to Atlas.md after confirmation."
|
|
4
|
+
risk: critical
|
|
5
|
+
source: community
|
|
6
|
+
source_repo: wede-wx/atlas
|
|
7
|
+
source_type: community
|
|
8
|
+
date_added: "2026-06-12"
|
|
9
|
+
license: MIT
|
|
10
|
+
license_source: "https://github.com/wede-wx/atlas/blob/main/LICENSE"
|
|
11
|
+
metadata:
|
|
12
|
+
version: "2.2.0"
|
|
13
|
+
author: wede-wx
|
|
14
|
+
repository: https://github.com/wede-wx/atlas
|
|
15
|
+
---
|
|
16
|
+
|
|
17
|
+
# Atlas Ledger v2.2
|
|
18
|
+
|
|
19
|
+
Give the Atlas series a memory.
|
|
20
|
+
|
|
21
|
+
## Contents
|
|
22
|
+
|
|
23
|
+
1. [Output Language](#1-output-language)
|
|
24
|
+
2. [When To Run](#2-when-to-run)
|
|
25
|
+
3. [Distillation (the core)](#3-distillation-the-core) — Steps 1–6
|
|
26
|
+
4. [Atlas.md format](#4-atlasmd-format)
|
|
27
|
+
5. [Clause maintenance](#5-clause-maintenance-keep-the-ledger-alive-not-ossified)
|
|
28
|
+
6. [Integration with atlas-contract](#6-integration-with-atlas-contract-the-read-back-half)
|
|
29
|
+
7. [Final Principle](#7-final-principle)
|
|
30
|
+
|
|
31
|
+
## Quick reference
|
|
32
|
+
|
|
33
|
+
```text
|
|
34
|
+
caught drift (auto handoff from Final Audit / Post Review / Phase Check / user request)
|
|
35
|
+
→ Step 1 state facts, not motive
|
|
36
|
+
→ Step 2 draft WHEN / DON'T / INSTEAD
|
|
37
|
+
→ Step 3 four gates: Actionability → Replay → Generalization → Over-reach
|
|
38
|
+
→ Step 4 first occurrence = Observation [O#]; repeat or high-severity = Clause [L#]
|
|
39
|
+
→ Step 5 propose, ATLAS_STOP, write only after user confirms
|
|
40
|
+
→ Step 6 merge-first into Atlas.md; confirmed clauses ≤ 15
|
|
41
|
+
```
|
|
42
|
+
|
|
43
|
+
`atlas-contract` defends the goal **within one conversation**, but it starts from zero every time — it does not know where this project drifted before. `atlas-ledger` closes that gap: when a drift is caught, it distills the lesson into a permanent, project-local **contract clause** and (after the user confirms) writes it to `Atlas.md`. Next time `atlas-contract` builds a Goal Contract, it loads the relevant clauses, so the defense line thickens with each catch. That is the compounding effect.
|
|
44
|
+
|
|
45
|
+
It is a **low-frequency, lightweight** companion. It runs only after a drift is caught, and it stays small on purpose. Do not turn it into a second heavy governance skill — its only hard job is distillation quality.
|
|
46
|
+
|
|
47
|
+
## Core idea
|
|
48
|
+
|
|
49
|
+
The job is **not** to keep a diary. A record of "what went wrong" is a memory; it changes nothing. The job is a translation:
|
|
50
|
+
|
|
51
|
+
> turn *this caught drift* → into *a clause that can enter a future contract and trigger a stop*.
|
|
52
|
+
|
|
53
|
+
A diary says "I hid the feature." A ledger clause says "WHEN a backend requirement is blocked, DON'T hide the feature, INSTEAD stop and disclose." Only the second one catches it next time. The entire value of this skill is the quality of that translation — and since it is run by the same model that drifted, the mechanisms below exist to keep it honest rather than trusting it to be careful.
|
|
54
|
+
|
|
55
|
+
---
|
|
56
|
+
|
|
57
|
+
# 1. Output Language
|
|
58
|
+
|
|
59
|
+
Write `Atlas.md` and all user-facing output in the language of the user's current instruction.
|
|
60
|
+
|
|
61
|
+
**Machine keys stay in English; clause content is localized.** Never translate the keys `WHEN` / `DON'T` / `INSTEAD`, the IDs (`L1`, `O1`), `seen`, `severity`, `Source`, `RETIRED`, or section headers `Confirmed Clauses` / `Provisional Observations` — atlas-contract parses these, and translating them makes the read-back unstable. The text after each key is written in the user's language. (E.g. `WHEN: 硬性 Must-Do 的后端部分受阻` — key English, content Chinese. Do **not** write `当: ...`.)
|
|
62
|
+
|
|
63
|
+
**Every process label this skill emits to the user must also be localized** (these are not machine keys — they are headings shown to the user, like the four gate names or the candidate-clause header). Only the fixed machine keys above stay English.
|
|
64
|
+
|
|
65
|
+
Chinese label mapping (process labels — localize these):
|
|
66
|
+
|
|
67
|
+
- `Atlas Event` → `Atlas 事件`; `Event ID` → `事件编号`; `Type` → `类型`; `Trigger Source` → `触发来源`; `Phase` → `阶段`; `Stop Status` → `停止状态`
|
|
68
|
+
- `Candidate Clause` / `Suggested Clause` → `候选条款`; `Proposal` → `提案`; `awaiting confirmation` → `等待确认`
|
|
69
|
+
- `Four acceptance gates` → `四道闸自检`; `Actionability` → `可执行性`; `Replay` → `回放`; `Generalization` → `泛化`; `Over-reach` → `误伤`; `Pass` → `通过`; `Fail` → `失败`
|
|
70
|
+
- `confirmed on first occurrence` → `首次出现即确认`; `merged` → `已合并`; `retired` → `已退休`; `review: stale` → `待复核:可能失效`
|
|
71
|
+
|
|
72
|
+
**Pre-output localization self-check:** Before sending any user-facing output, scan for untranslated English process labels (e.g. "Suggested Clause", "Actionability"). If any are found, translate them before sending. Do **not** translate the fixed machine keys (`WHEN`/`DON'T`/`INSTEAD`/IDs/`severity`/`Source`/`seen`/`Confirmed Clauses`/`Provisional Observations`) — those stay English even in a Chinese response.
|
|
73
|
+
|
|
74
|
+
---
|
|
75
|
+
|
|
76
|
+
## When to Use
|
|
77
|
+
|
|
78
|
+
# 2. When To Run
|
|
79
|
+
|
|
80
|
+
Run distillation only when a drift has been **caught**. Triggers, in order of how they usually arrive:
|
|
81
|
+
|
|
82
|
+
1. **Automatic handoff from atlas-contract (primary path).** When an `atlas-contract` **Final Audit** records one or more hard deviations (a hard Deviation Notice was raised, or an item is Violation / Partial / Unverified that should have been Complete), the contract skill invokes this distillation **immediately and without asking** — the candidate clause is proposed right after the audit, and the flow stops at the write-confirmation. The user should never have to remember to ask for the recording.
|
|
83
|
+
2. an `atlas-contract` **Post Review** (the user said the result was wrong / incomplete / downgraded / mocked);
|
|
84
|
+
3. a **Phase Check** catches the same class of error recurring;
|
|
85
|
+
4. the user explicitly says "record this so it doesn't happen again."
|
|
86
|
+
|
|
87
|
+
In every path, the confirm-before-write stop (Step 5) is preserved: automatic triggering changes **when distillation starts**, never **whether the user approves the write**.
|
|
88
|
+
|
|
89
|
+
Do **not** run on: clean completions; optimization requests; ordinary code review; style preferences; general takeaways. There is nothing to enforce in those.
|
|
90
|
+
|
|
91
|
+
**Honesty boundary:** it can only learn from drift that was *detected*. Drift that slipped through unnoticed leaves no entry. Do not pretend the ledger is complete.
|
|
92
|
+
|
|
93
|
+
---
|
|
94
|
+
|
|
95
|
+
# 3. Distillation (the core)
|
|
96
|
+
|
|
97
|
+
Run in order. Output at most one clause per caught drift.
|
|
98
|
+
|
|
99
|
+
## Step 1 — State the drift as observable facts, not motive
|
|
100
|
+
|
|
101
|
+
Write what was objectively true, from the contract plus the delivered artifact — not why you think you did it.
|
|
102
|
+
|
|
103
|
+
- Good (fact): "[M2] required backend persistence (hard). Delivered code shipped the frontend with hardcoded data; no API or DB write exists."
|
|
104
|
+
- Bad (motive): "I thought the backend wasn't really necessary." Self-reported reasons are unreliable; a clause built on one prevents the wrong thing. Base the clause on the observable situation → action.
|
|
105
|
+
|
|
106
|
+
## Step 2 — Draft the clause: WHEN / DON'T / INSTEAD
|
|
107
|
+
|
|
108
|
+
```text
|
|
109
|
+
WHEN <the situation that was true, generalized away from the specific subject>
|
|
110
|
+
DON'T <the concrete wrong action taken>
|
|
111
|
+
INSTEAD <the concrete correct action>
|
|
112
|
+
```
|
|
113
|
+
|
|
114
|
+
Governing principle: **abstract the situation, keep the behavior concrete, base WHEN on facts not motive.** Drop the subject (feature name, file); keep the condition. The condition makes it match a future case; the subject makes it useless.
|
|
115
|
+
|
|
116
|
+
## Step 3 — Four acceptance gates (record only if it passes ALL four)
|
|
117
|
+
|
|
118
|
+
Run cheapest first.
|
|
119
|
+
|
|
120
|
+
1. **Actionability** — can the clause answer, concretely: what condition triggers it, what it forbids, and what to do instead? If any of the three is vague ("be more careful", "don't be lazy", "implement fully"), it is not a clause — discard. This gate exists to kill un-triggerable garbage before spending effort on the rest.
|
|
121
|
+
2. **Replay** — had this clause been in the contract this time, would it have caught this drift? If no → it does not describe what happened; rewrite.
|
|
122
|
+
3. **Generalization** — would it catch a *different* instance of the same situation (different feature, same shape)? If no → WHEN is still stuck to the subject; abstract further.
|
|
123
|
+
4. **Over-reach** — would it wrongly block a *legitimate* action elsewhere (e.g. the user explicitly approved frontend-first)? If yes → too broad; narrow it, usually by tightening WHEN.
|
|
124
|
+
|
|
125
|
+
If a candidate cannot pass all four, the lesson is not ready. **Record nothing rather than record noise.**
|
|
126
|
+
|
|
127
|
+
## Step 4 — Provisional vs confirmed
|
|
128
|
+
|
|
129
|
+
A single occurrence may be a fluke; do not over-fit.
|
|
130
|
+
|
|
131
|
+
- **First time** a situation is seen → record as a provisional **Observation** `[O#]`.
|
|
132
|
+
- A later caught drift whose WHEN **matches an existing Observation** → promote to a confirmed **Clause** `[L#]`, increment seen-count, remove the Observation.
|
|
133
|
+
- Only **confirmed clauses** are auto-loaded into future contracts; Observations are watched, not enforced.
|
|
134
|
+
|
|
135
|
+
**Severity exception — confirm on first occurrence** (skip the provisional stage) when the drift is any of:
|
|
136
|
+
|
|
137
|
+
1. mock / stub / fake data passed off as a real implementation;
|
|
138
|
+
2. hiding, deleting, or disabling a feature the user explicitly required;
|
|
139
|
+
3. weakening or deleting tests to force a pass;
|
|
140
|
+
4. data loss, broken persistence, or corrupted user data;
|
|
141
|
+
5. a security / permissions / auth mis-change;
|
|
142
|
+
6. a declared Preserve item broken;
|
|
143
|
+
7. downgrading Complete / end-to-end work to frontend-only.
|
|
144
|
+
|
|
145
|
+
Mark these `severity: high` and note `confirmed on first occurrence`.
|
|
146
|
+
|
|
147
|
+
## Step 5 — Propose, then write only after confirmation
|
|
148
|
+
|
|
149
|
+
`Atlas.md` is long-term project state — a wrong clause silently shapes every future contract. So the model does **not** write it unsupervised. Default flow:
|
|
150
|
+
|
|
151
|
+
```text
|
|
152
|
+
caught drift (auto handoff from Final Audit, or other §2 trigger)
|
|
153
|
+
→ draft clause (Steps 1–2)
|
|
154
|
+
→ pass four gates (Step 3)
|
|
155
|
+
→ output the candidate clause as a proposal
|
|
156
|
+
→ ATLAS_STOP, await user confirmation
|
|
157
|
+
→ on confirmation, write to Atlas.md (Step 6)
|
|
158
|
+
```
|
|
159
|
+
|
|
160
|
+
Only skip the stop if the user has explicitly said something like "auto-update Atlas.md". The confirmation is not red tape: it puts a human on the one artifact that is permanent, and lets the user fix a mis-distilled clause before it pollutes future work.
|
|
161
|
+
|
|
162
|
+
## Step 6 — Write to Atlas.md, merging first
|
|
163
|
+
|
|
164
|
+
Before adding, scan `Atlas.md` for an existing clause/observation with an overlapping WHEN.
|
|
165
|
+
|
|
166
|
+
- If one exists → **merge** into a single, more general clause, then re-run the four gates on the merged result. No near-duplicates.
|
|
167
|
+
- If confirmed clauses already number 15, merge the two closest before adding.
|
|
168
|
+
|
|
169
|
+
**Never only append.** A ledger that only grows hits the same long-context decay atlas-contract fights. Merging two concrete instances is often what produces the correctly-general rule.
|
|
170
|
+
|
|
171
|
+
---
|
|
172
|
+
|
|
173
|
+
# 4. Atlas.md format
|
|
174
|
+
|
|
175
|
+
One file at the workspace root. Stable structure (atlas-contract reads it). Keys English, content localized, `Source` anchored to the phase / event ID that caught it (not a guessed date — the model does not reliably know the date).
|
|
176
|
+
|
|
177
|
+
```text
|
|
178
|
+
# Atlas Ledger
|
|
179
|
+
<!-- Maintained by atlas-ledger. Confirmed clauses are loaded into new Goal Contracts by atlas-contract.
|
|
180
|
+
Keys (WHEN/DON'T/INSTEAD, IDs, severity, Source) are fixed English; content is localized.
|
|
181
|
+
Keep confirmed clauses general and <= 15. -->
|
|
182
|
+
|
|
183
|
+
## Confirmed Clauses
|
|
184
|
+
- [L1] (seen 2x, severity: high)
|
|
185
|
+
WHEN: 硬性 Must-Do 的后端 / API / 持久化部分受阻或比预期更难
|
|
186
|
+
DON'T: 用前端 mock、隐藏入口、静态数据或假成功来冒充完成
|
|
187
|
+
INSTEAD: 停下来披露阻塞点,让用户决定继续原目标、批准偏离或改方案
|
|
188
|
+
Source: P3 Final Audit; P2 Post Review
|
|
189
|
+
|
|
190
|
+
## Provisional Observations
|
|
191
|
+
- [O1] (seen 1x)
|
|
192
|
+
WHEN: 某个要求的测试失败且修复不明显
|
|
193
|
+
DON'T: 削弱或跳过断言来让它通过
|
|
194
|
+
INSTEAD: 报告失败,提出真实修复或发起偏离通知
|
|
195
|
+
Source: P2 Deviation Notice
|
|
196
|
+
```
|
|
197
|
+
|
|
198
|
+
---
|
|
199
|
+
|
|
200
|
+
# 5. Clause maintenance (keep the ledger alive, not ossified)
|
|
201
|
+
|
|
202
|
+
A clause distilled early can become wrong as the project evolves. The ledger must be able to shrink and retire, not only grow.
|
|
203
|
+
|
|
204
|
+
- The user may **retire** any clause at any time; mark it `RETIRED` (or remove it) and stop loading it.
|
|
205
|
+
- If a confirmed clause is **overridden by the user twice** (carried into a contract and waved off both times), flag it `review: stale` and surface it for retirement — it likely no longer matches the project.
|
|
206
|
+
- Retiring and merging are the two ways the ledger stays small; only-append is forbidden (Step 6).
|
|
207
|
+
|
|
208
|
+
---
|
|
209
|
+
|
|
210
|
+
# 6. Integration with atlas-contract (the read-back half)
|
|
211
|
+
|
|
212
|
+
This skill owns the **write** half. The **read** half is a single hook in atlas-contract's §6. Add this to atlas-contract:
|
|
213
|
+
|
|
214
|
+
```text
|
|
215
|
+
## Project Ledger Hook (read-back)
|
|
216
|
+
|
|
217
|
+
Before building the Goal Contract, check for Atlas.md at the workspace root. If it exists:
|
|
218
|
+
1. Read only the Confirmed Clauses (ignore Provisional Observations unless one is directly
|
|
219
|
+
relevant and clearly marked advisory).
|
|
220
|
+
2. Match clauses whose WHEN is relevant to the current task.
|
|
221
|
+
3. Carry in at most 5 of the most relevant clauses — not all of them.
|
|
222
|
+
4. Convert each: DON'T -> a Must Not Do; INSTEAD -> its required response / stop rule.
|
|
223
|
+
5. Show them in the contract under "Carried-in Ledger Clauses" so the user sees the ledger working.
|
|
224
|
+
|
|
225
|
+
Precedence: ledger clauses are project DEFAULTS, not law. The user's current explicit instruction
|
|
226
|
+
always overrides a carried-in clause. If a carried-in clause conflicts with what the user is asking
|
|
227
|
+
for this time, do not silently enforce it — surface the conflict and let the user decide.
|
|
228
|
+
|
|
229
|
+
If Atlas.md is missing, malformed, stale, oversized, or ambiguous, say so in one line and continue
|
|
230
|
+
without pretending it was fully applied. Never fabricate clauses.
|
|
231
|
+
```
|
|
232
|
+
|
|
233
|
+
Without that hook the clauses are written but never enforced, and the ledger degrades into a diary. With it, every caught drift becomes a standing guardrail that routes through the mechanism that already works (the contract + the stop).
|
|
234
|
+
|
|
235
|
+
---
|
|
236
|
+
|
|
237
|
+
# 7. Final Principle
|
|
238
|
+
|
|
239
|
+
atlas-ledger turns a one-time, caught mistake into a permanent project constraint — that is the compounding. Its worth is entirely in distillation quality: too specific and it never fires, too broad and it fires constantly, built on a guessed motive and it guards the wrong thing. The four gates, confirm-before-write, merge-first, and retirement rules exist to hold that quality and keep the ledger small.
|
|
240
|
+
|
|
241
|
+
**Self-enforcement ceiling:** like atlas-contract, this skill is run by the same model it governs, so it can mis-distill or miss a drift worth recording. It raises the project's floor over time; it is not a guarantee, and the user confirming each clause is part of the design, not a formality. One more layer in the Atlas series — not a closed loop on its own.
|
|
242
|
+
|
|
243
|
+
## Limitations
|
|
244
|
+
|
|
245
|
+
- Writes to `Atlas.md` only after user confirmation; without that confirmation it produces a proposed clause, not durable project memory.
|
|
246
|
+
- Clause quality depends on the model correctly identifying the actual drift, so user review is required before accepting entries.
|
|
247
|
+
- The ledger can become stale or overbroad if clauses are not merged, retired, or reviewed as the project changes.
|
|
248
|
+
- It does not replace tests, code review, or independent validation of whether the original task was actually completed.
|
|
@@ -1,9 +1,9 @@
|
|
|
1
1
|
---
|
|
2
2
|
title: Jetski/Cortex + Gemini Integration Guide
|
|
3
|
-
description: "Use antigravity-awesome-skills with Jetski/Cortex without hitting context-window overflow with 1,
|
|
3
|
+
description: "Use antigravity-awesome-skills with Jetski/Cortex without hitting context-window overflow with 1,541+ skills."
|
|
4
4
|
---
|
|
5
5
|
|
|
6
|
-
# Jetski/Cortex + Gemini: safe integration with 1,
|
|
6
|
+
# Jetski/Cortex + Gemini: safe integration with 1,541+ skills
|
|
7
7
|
|
|
8
8
|
This guide shows how to integrate the `antigravity-awesome-skills` repository with an agent based on **Jetski/Cortex + Gemini** (or similar frameworks) **without exceeding the model context window**.
|
|
9
9
|
|
|
@@ -23,7 +23,7 @@ Never do:
|
|
|
23
23
|
- concatenate all `SKILL.md` content into a single system prompt;
|
|
24
24
|
- re-inject the entire library for **every** request.
|
|
25
25
|
|
|
26
|
-
With 1,
|
|
26
|
+
With 1,541+ skills, this approach fills the context window before user messages are even added, causing truncation.
|
|
27
27
|
|
|
28
28
|
---
|
|
29
29
|
|
|
@@ -21,7 +21,7 @@ This example shows one way to integrate **antigravity-awesome-skills** with a Je
|
|
|
21
21
|
- How to enforce a **maximum number of skills per turn** via `maxSkillsPerTurn`.
|
|
22
22
|
- How to choose whether to **truncate or error** when too many skills are requested via `overflowBehavior`.
|
|
23
23
|
|
|
24
|
-
This pattern avoids context overflow when you have 1,
|
|
24
|
+
This pattern avoids context overflow when you have 1,541+ skills installed.
|
|
25
25
|
|
|
26
26
|
Manifest contract references:
|
|
27
27
|
|
|
@@ -6,7 +6,7 @@ This document keeps the repository's GitHub-facing discovery copy aligned with t
|
|
|
6
6
|
|
|
7
7
|
Preferred positioning:
|
|
8
8
|
|
|
9
|
-
> Installable GitHub library of 1,
|
|
9
|
+
> Installable GitHub library of 1,541+ agentic skills for Claude Code, Cursor, Codex CLI, Gemini CLI, Antigravity, and other AI coding assistants.
|
|
10
10
|
|
|
11
11
|
Key framing:
|
|
12
12
|
|
|
@@ -20,7 +20,7 @@ Key framing:
|
|
|
20
20
|
|
|
21
21
|
Preferred description:
|
|
22
22
|
|
|
23
|
-
> Installable GitHub library of 1,
|
|
23
|
+
> Installable GitHub library of 1,541+ agentic skills for Claude Code, Cursor, Codex CLI, Gemini CLI, Antigravity, and more. Includes installer CLI, bundles, workflows, and official/community skill collections.
|
|
24
24
|
|
|
25
25
|
Preferred homepage:
|
|
26
26
|
|
|
@@ -28,7 +28,7 @@ Preferred homepage:
|
|
|
28
28
|
|
|
29
29
|
Preferred social preview:
|
|
30
30
|
|
|
31
|
-
- use a clean preview image that says `1,
|
|
31
|
+
- use a clean preview image that says `1,541+ Agentic Skills`;
|
|
32
32
|
- mention Claude Code, Cursor, Codex CLI, and Gemini CLI;
|
|
33
33
|
- avoid dense text and tiny logos that disappear in social cards.
|
|
34
34
|
|
|
@@ -72,7 +72,7 @@ The update process refreshes:
|
|
|
72
72
|
- Canonical skills index (`skills_index.json`)
|
|
73
73
|
- Compatibility mirror (`data/skills_index.json`)
|
|
74
74
|
- Web app skills data (`apps\web-app\public\skills.json`)
|
|
75
|
-
- All 1,
|
|
75
|
+
- All 1,541+ skills from the skills directory
|
|
76
76
|
|
|
77
77
|
## When to Update
|
|
78
78
|
|
|
@@ -12,7 +12,7 @@ Install the library into Claude Code, then invoke focused skills directly in the
|
|
|
12
12
|
|
|
13
13
|
## Why use this repo for Claude Code
|
|
14
14
|
|
|
15
|
-
- It includes 1,
|
|
15
|
+
- It includes 1,541+ skills instead of a narrow single-domain starter pack.
|
|
16
16
|
- It supports the standard `.claude/skills/` path and the Claude Code plugin marketplace flow.
|
|
17
17
|
- It also ships generated bundle plugins so teams can install focused packs like `Essentials` or `Security Developer` from the marketplace metadata.
|
|
18
18
|
- It includes onboarding docs, bundles, and workflows so new users do not need to guess where to begin.
|
|
@@ -12,7 +12,7 @@ Install into the Gemini skills path, then ask Gemini to apply one skill at a tim
|
|
|
12
12
|
|
|
13
13
|
- It installs directly into the expected Gemini skills path.
|
|
14
14
|
- It includes both core software engineering skills and deeper agent/LLM-oriented skills.
|
|
15
|
-
- It helps new users get started with bundles and workflows rather than forcing a cold start from 1,
|
|
15
|
+
- It helps new users get started with bundles and workflows rather than forcing a cold start from 1,541+ files.
|
|
16
16
|
- It is useful whether you want a broad internal skill library or a single repo to test many workflows quickly.
|
|
17
17
|
|
|
18
18
|
## Install Gemini CLI Skills
|
|
@@ -18,7 +18,7 @@ Kiro is AWS's agentic AI IDE that combines:
|
|
|
18
18
|
|
|
19
19
|
Kiro's agentic capabilities are enhanced by skills that provide:
|
|
20
20
|
|
|
21
|
-
- **Domain expertise** across 1,
|
|
21
|
+
- **Domain expertise** across 1,541+ specialized areas
|
|
22
22
|
- **Best practices** from Anthropic, OpenAI, Google, Microsoft, and AWS
|
|
23
23
|
- **Workflow automation** for common development tasks
|
|
24
24
|
- **AWS-specific patterns** for serverless, infrastructure, and cloud architecture
|
|
@@ -14,7 +14,7 @@ If you came in through a **Claude Code** or **Codex** plugin instead of a full l
|
|
|
14
14
|
|
|
15
15
|
When you ran `npx antigravity-awesome-skills` or cloned the repository, you:
|
|
16
16
|
|
|
17
|
-
✅ **Downloaded 1,
|
|
17
|
+
✅ **Downloaded 1,541+ skill files** to your computer (default: `~/.agents/skills/`; or a custom path like `~/.agent/skills/` if you used `--path`)
|
|
18
18
|
✅ **Made them available** to your AI assistant
|
|
19
19
|
❌ **Did NOT enable them all automatically** (they're just sitting there, waiting)
|
|
20
20
|
|
|
@@ -34,7 +34,7 @@ Bundles are **curated groups** of skills organized by role. They help you decide
|
|
|
34
34
|
|
|
35
35
|
**Analogy:**
|
|
36
36
|
|
|
37
|
-
- You installed a toolbox with 1,
|
|
37
|
+
- You installed a toolbox with 1,541+ tools (✅ done)
|
|
38
38
|
- Bundles are like **labeled organizer trays** saying: "If you're a carpenter, start with these 10 tools"
|
|
39
39
|
- You can either **pick skills from the tray** or install that tray as a focused marketplace bundle plugin
|
|
40
40
|
|
|
@@ -212,7 +212,7 @@ Let's actually use a skill right now. Follow these steps:
|
|
|
212
212
|
|
|
213
213
|
## Step 5: Picking Your First Skills (Practical Advice)
|
|
214
214
|
|
|
215
|
-
Don't try to use all 1,
|
|
215
|
+
Don't try to use all 1,541+ skills at once. Here's a sensible approach:
|
|
216
216
|
|
|
217
217
|
If you want a tool-specific starting point before choosing skills, use:
|
|
218
218
|
|
|
@@ -343,7 +343,7 @@ Usually no, but if your AI doesn't recognize a skill:
|
|
|
343
343
|
|
|
344
344
|
### "Can I load all skills into the model at once?"
|
|
345
345
|
|
|
346
|
-
No. Even though you have 1,
|
|
346
|
+
No. Even though you have 1,541+ skills installed locally, you should **not** concatenate every `SKILL.md` into a single system prompt or context block.
|
|
347
347
|
|
|
348
348
|
The intended pattern is:
|
|
349
349
|
|
|
@@ -34,7 +34,7 @@ antigravity-awesome-skills/
|
|
|
34
34
|
├── 📄 CONTRIBUTING.md ← Contributor workflow
|
|
35
35
|
├── 📄 CATALOG.md ← Full generated catalog
|
|
36
36
|
│
|
|
37
|
-
├── 📁 skills/ ← 1,
|
|
37
|
+
├── 📁 skills/ ← 1,541+ skills live here
|
|
38
38
|
│ │
|
|
39
39
|
│ ├── 📁 brainstorming/
|
|
40
40
|
│ │ └── 📄 SKILL.md ← Skill definition
|
|
@@ -47,7 +47,7 @@ antigravity-awesome-skills/
|
|
|
47
47
|
│ │ └── 📁 2d-games/
|
|
48
48
|
│ │ └── 📄 SKILL.md ← Nested skills also supported
|
|
49
49
|
│ │
|
|
50
|
-
│ └── ... (1,
|
|
50
|
+
│ └── ... (1,541+ total)
|
|
51
51
|
│
|
|
52
52
|
├── 📁 apps/
|
|
53
53
|
│ └── 📁 web-app/ ← Interactive browser
|
|
@@ -100,7 +100,7 @@ antigravity-awesome-skills/
|
|
|
100
100
|
|
|
101
101
|
```
|
|
102
102
|
┌─────────────────────────┐
|
|
103
|
-
│ 1,
|
|
103
|
+
│ 1,541+ SKILLS │
|
|
104
104
|
└────────────┬────────────┘
|
|
105
105
|
│
|
|
106
106
|
┌────────────────────────┼────────────────────────┐
|
|
@@ -201,7 +201,7 @@ If you want a workspace-style manual install instead, cloning into `.agent/skill
|
|
|
201
201
|
│ ├── 📁 brainstorming/ │
|
|
202
202
|
│ ├── 📁 stripe-integration/ │
|
|
203
203
|
│ ├── 📁 react-best-practices/ │
|
|
204
|
-
│ └── ... (1,
|
|
204
|
+
│ └── ... (1,541+ total) │
|
|
205
205
|
└─────────────────────────────────────────┘
|
|
206
206
|
```
|
|
207
207
|
|
|
@@ -0,0 +1,125 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: fsi-compliance-checker
|
|
3
|
+
description: "Maps code, architecture, and infrastructure changes to specific control IDs in PCI-DSS v4.0 and MAS TRM (Singapore financial regulator), producing an audit-traceable findings report with per-control remediation."
|
|
4
|
+
category: security
|
|
5
|
+
risk: safe
|
|
6
|
+
source: community
|
|
7
|
+
source_repo: timwukp/agent-skills-best-practice
|
|
8
|
+
source_type: community
|
|
9
|
+
date_added: "2026-06-12"
|
|
10
|
+
author: timwukp
|
|
11
|
+
tags: [compliance, pci-dss, mas-trm, fintech, banking, security-review, audit, financial-services]
|
|
12
|
+
tools: [claude, cursor, gemini, codex, antigravity]
|
|
13
|
+
license: "MIT"
|
|
14
|
+
license_source: "https://github.com/timwukp/agent-skills-best-practice/blob/main/LICENSE"
|
|
15
|
+
---
|
|
16
|
+
|
|
17
|
+
# FSI Compliance Checker
|
|
18
|
+
|
|
19
|
+
## Overview
|
|
20
|
+
|
|
21
|
+
Maps a concrete change (code diff, architecture design, IaC, pipeline config) to the specific controls it touches in financial services compliance frameworks — PCI-DSS v4.0 for payment card data and MAS TRM for Singapore-regulated institutions — and reports gaps with actionable remediation. This is engineering-level compliance triage: it helps teams catch violations before audit, but it does not replace a qualified assessor (QSA) or the institution's compliance function. Say so in every report.
|
|
22
|
+
|
|
23
|
+
## When to Use This Skill
|
|
24
|
+
|
|
25
|
+
- Use when a change touches payment card data (PAN, CVV, track data) and needs a PCI-DSS check
|
|
26
|
+
- Use when reviewing changes at a Singapore-regulated financial institution against MAS TRM expectations
|
|
27
|
+
- Use when someone asks "is this compliant", "does logging this violate PCI", or requests a banking-regulation review of a diff, design, or Terraform change
|
|
28
|
+
- Do NOT use for generic security review (no framework involved), GDPR/SOC2/HIPAA (out of bundled scope), or legal advice
|
|
29
|
+
|
|
30
|
+
## How It Works
|
|
31
|
+
|
|
32
|
+
### Step 1: Select the framework
|
|
33
|
+
|
|
34
|
+
Load only the reference file(s) the engagement needs:
|
|
35
|
+
|
|
36
|
+
| Situation | Load |
|
|
37
|
+
|-----------|------|
|
|
38
|
+
| Payment card data is stored, processed, or transmitted | [pci-dss.md](pci-dss.md) |
|
|
39
|
+
| Singapore-regulated financial institution (bank, insurer, capital markets, major payment institution) | [mas-trm.md](mas-trm.md) |
|
|
40
|
+
| Both apply (e.g. Singapore bank handling cards) | Both files |
|
|
41
|
+
| Other jurisdictions/frameworks (SOX, GDPR, HKMA, APRA) | State they are out of scope; offer general secure-engineering review instead |
|
|
42
|
+
|
|
43
|
+
If the user hasn't said which applies, ask one question: what data does the change touch, and is the institution Singapore-regulated?
|
|
44
|
+
|
|
45
|
+
### Step 2: Scope the change
|
|
46
|
+
|
|
47
|
+
Identify what the diff/design actually touches: data elements (card data? customer PII? credentials?), trust boundaries, environments (production? DR?), and third parties.
|
|
48
|
+
|
|
49
|
+
### Step 3: Assess applicable controls
|
|
50
|
+
|
|
51
|
+
Select the applicable controls from the loaded reference file(s) — typically 5-15 controls, not the whole framework. List what you ruled out and why (one line each) so the scoping is auditable. Assess each as `Compliant` / `Gap` / `Needs evidence` (can't tell from the artifact — name the evidence required).
|
|
52
|
+
|
|
53
|
+
### Step 4: Report
|
|
54
|
+
|
|
55
|
+
Every Gap gets: the control ID, what's wrong in this specific change, concrete remediation, and severity (Critical = violation involving live regulated data; High = control absent; Medium = control partial/undocumented).
|
|
56
|
+
|
|
57
|
+
```markdown
|
|
58
|
+
# Compliance Review: [change title]
|
|
59
|
+
**Frameworks:** [PCI-DSS v4.0 / MAS TRM 2021] · **Date:** [YYYY-MM-DD]
|
|
60
|
+
**Scope:** [what was reviewed: files, design doc, pipeline]
|
|
61
|
+
> Engineering triage only — not a substitute for QSA assessment or the compliance function.
|
|
62
|
+
|
|
63
|
+
## Data & Boundary Analysis
|
|
64
|
+
- Data elements touched: [e.g. PAN (masked), customer NRIC, none]
|
|
65
|
+
- Environments/boundaries: [e.g. CDE-adjacent service, public API]
|
|
66
|
+
|
|
67
|
+
## Findings
|
|
68
|
+
| # | Control | Status | Severity | Finding | Remediation |
|
|
69
|
+
|---|---------|--------|----------|---------|-------------|
|
|
70
|
+
| 1 | [PCI 3.5.1] | Gap | Critical | [specific issue in this change] | [specific fix] |
|
|
71
|
+
|
|
72
|
+
## Ruled Out (not applicable)
|
|
73
|
+
- [Control area] — [one-line reason]
|
|
74
|
+
|
|
75
|
+
## Evidence Needed
|
|
76
|
+
- [Control]: [what artifact would demonstrate compliance]
|
|
77
|
+
```
|
|
78
|
+
|
|
79
|
+
### Step 5: Offer story conversion
|
|
80
|
+
|
|
81
|
+
Offer to turn findings into backlog items with the control ID in each story for traceability.
|
|
82
|
+
|
|
83
|
+
## Examples
|
|
84
|
+
|
|
85
|
+
### Example 1: Logging review
|
|
86
|
+
|
|
87
|
+
**User**: "Is this PCI-DSS compliant: we log the full request body of card authorization calls for debugging?"
|
|
88
|
+
|
|
89
|
+
**Skill**: Loads pci-dss.md → Critical findings against 3.3.1 (CVV must never be stored post-authorization — logs are storage), 3.4.1 (PAN display masking), 3.5.1 (PAN unreadable at rest); remediation: remove the log line or apply a field-allowlist redaction filter; flags downstream log-pipeline scoping (10.3.x); QSA disclaimer included.
|
|
90
|
+
|
|
91
|
+
### Example 2: Cloud migration
|
|
92
|
+
|
|
93
|
+
**User**: "Our Singapore bank is moving the customer notification service to a cloud region in another country. MAS TRM implications?"
|
|
94
|
+
|
|
95
|
+
**Skill**: Loads mas-trm.md → reviews against §11.5 (cloud: due diligence, data residency, exit strategy), flags the MAS Outsourcing Guidelines as a related instrument, asks what customer data the service touches before rating severity.
|
|
96
|
+
|
|
97
|
+
## Common FSI Engineering Triggers
|
|
98
|
+
|
|
99
|
+
Changes that almost always have compliance impact — check proactively when they appear in a diff:
|
|
100
|
+
|
|
101
|
+
- Logging statements near payment or authentication flows (PAN/CVV must never be logged; MAS TRM requires security event logging — both directions matter)
|
|
102
|
+
- New data stores or caches receiving customer or card data (encryption at rest, retention, residency)
|
|
103
|
+
- Authentication/session changes (MFA requirements, session timeout, credential storage)
|
|
104
|
+
- New third-party SDKs or API integrations (outsourcing/vendor controls, data flows leaving the boundary)
|
|
105
|
+
- Infrastructure changes touching network segmentation, security groups, or public exposure
|
|
106
|
+
- CI/CD changes that alter who/what can deploy to production (change management, segregation of duties)
|
|
107
|
+
|
|
108
|
+
## Guardrails
|
|
109
|
+
|
|
110
|
+
- Cite control IDs precisely (e.g. "PCI-DSS 8.3.6", "MAS TRM 9.1.1") so findings are traceable in audit tooling; the bundled reference files carry the ID schemes.
|
|
111
|
+
- Severity discipline: don't inflate. A missing comment is not a Critical; unencrypted PAN at rest is.
|
|
112
|
+
- When the change is compliant, say so affirmatively per control — "no findings" plus the checked-control list is a useful audit artifact.
|
|
113
|
+
- Never output real card numbers, even as examples; use the standard test PANs (e.g. 4111 1111 1111 1111) when illustrating.
|
|
114
|
+
- Read-only: this skill reviews and reports; it never modifies code, infrastructure, or configuration.
|
|
115
|
+
|
|
116
|
+
## Limitations
|
|
117
|
+
|
|
118
|
+
- Covers only the bundled PCI-DSS v4.0 and MAS TRM engineering summaries; other frameworks or local policy overlays need separate review.
|
|
119
|
+
- Provides engineering triage, not legal advice, QSA assessment, or formal compliance sign-off.
|
|
120
|
+
- Requires concrete evidence such as diffs, designs, IaC, logs, or control artifacts; incomplete evidence should be marked `Needs evidence`.
|
|
121
|
+
- The bundled references are concise control maps, not substitutes for reading the official standards.
|
|
122
|
+
|
|
123
|
+
## Credits
|
|
124
|
+
|
|
125
|
+
Adapted from [timwukp/agent-skills-best-practice](https://github.com/timwukp/agent-skills-best-practice) (MIT), where the skill ships with evals and a documented 4-layer test methodology (see the repo's TESTING.md).
|