blueprint-os 1.0.0 → 1.0.2
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/.agent/skills/brainstorming/SKILL.md +157 -157
- package/.agent/skills/creating-skills/SKILL.md +1 -1
- package/.agent/skills/deploying-standards/SKILL.md +85 -85
- package/.agent/skills/discovering-standards/SKILL.md +107 -107
- package/README.md +2 -2
- package/adapters/antigravity.md +1 -1
- package/adapters/skills-sh.md +1 -1
- package/package.json +1 -1
- package/references/agent-workflow/Skills.md +155 -155
- package/references/agent-workflow/blast.md +155 -155
- package/standards/README.md +123 -123
|
@@ -1,107 +1,107 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: discovering-standards
|
|
3
|
-
description: Extracts coding patterns, conventions, and architectural decisions from an existing codebase and saves them as standards files. Use when the user asks to document standards, capture patterns, extract conventions, or onboard an AI agent to an existing project.
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# Discovering Standards
|
|
7
|
-
|
|
8
|
-
## When to use this skill
|
|
9
|
-
|
|
10
|
-
- User asks to "document my standards", "capture my conventions", or "extract patterns from my code"
|
|
11
|
-
- Onboarding Blueprint OS to an existing project for the first time
|
|
12
|
-
- A recurring pattern has emerged that should be formalized
|
|
13
|
-
- Tribal knowledge exists in the code but not in writing
|
|
14
|
-
- Before brainstorming a new feature in an existing codebase — discover constraints first, then brainstorm within them
|
|
15
|
-
|
|
16
|
-
## Workflow
|
|
17
|
-
|
|
18
|
-
- [ ] Identify which area to document (ask user if unclear)
|
|
19
|
-
- [ ] Scan relevant files in that area
|
|
20
|
-
- [ ] Identify recurring patterns, naming conventions, and architectural decisions
|
|
21
|
-
- [ ] Draft a standards file and confirm with the user
|
|
22
|
-
- [ ] Save to `standards/<category>.md`
|
|
23
|
-
- [ ] Update `standards/README.md` index if the file is new
|
|
24
|
-
|
|
25
|
-
## Instructions
|
|
26
|
-
|
|
27
|
-
### Discovery areas
|
|
28
|
-
|
|
29
|
-
Approach one area at a time. Common areas to document:
|
|
30
|
-
|
|
31
|
-
- **Tech stack** — languages, frameworks, libraries, versions
|
|
32
|
-
- **Folder structure** — how the project is organized and why
|
|
33
|
-
- **Naming conventions** — files, variables, components, routes, database columns
|
|
34
|
-
- **Component patterns** — how UI components are structured and composed
|
|
35
|
-
- **API design** — endpoint naming, request/response shapes, error handling
|
|
36
|
-
- **Data models** — schema conventions, relationships, field naming
|
|
37
|
-
- **Testing approach** — test file location, naming, tooling, coverage expectations
|
|
38
|
-
- **Error handling** — how errors surface, are logged, and returned to clients
|
|
39
|
-
- **State management** — how application state is structured and updated
|
|
40
|
-
- **Authentication** — how auth is implemented and enforced
|
|
41
|
-
|
|
42
|
-
### Extraction process
|
|
43
|
-
|
|
44
|
-
For each area:
|
|
45
|
-
|
|
46
|
-
1. Read 3–5 representative files
|
|
47
|
-
2. Identify what is consistent across them (naming, structure, patterns)
|
|
48
|
-
3. Note any exceptions — are they intentional or accidental?
|
|
49
|
-
4. Write only what the agent needs to replicate the pattern, not what is obvious
|
|
50
|
-
|
|
51
|
-
### Standards file format
|
|
52
|
-
|
|
53
|
-
Save to `standards/<category>.md`:
|
|
54
|
-
|
|
55
|
-
```markdown
|
|
56
|
-
# [Category] Standards
|
|
57
|
-
|
|
58
|
-
**Last updated:** [YYYY-MM-DD]
|
|
59
|
-
|
|
60
|
-
## Overview
|
|
61
|
-
[One paragraph: what this standard covers and why it exists]
|
|
62
|
-
|
|
63
|
-
## Conventions
|
|
64
|
-
|
|
65
|
-
### [Convention name]
|
|
66
|
-
[Description of the pattern]
|
|
67
|
-
|
|
68
|
-
**Example:**
|
|
69
|
-
[code example or file path showing the pattern]
|
|
70
|
-
|
|
71
|
-
**Avoid:**
|
|
72
|
-
[counter-example if useful]
|
|
73
|
-
|
|
74
|
-
## Exceptions
|
|
75
|
-
[Known deviations and why they exist]
|
|
76
|
-
```
|
|
77
|
-
|
|
78
|
-
### What to capture vs. skip
|
|
79
|
-
|
|
80
|
-
**Capture:**
|
|
81
|
-
- Decisions that aren't obvious from reading a single file
|
|
82
|
-
- Patterns that repeat across the codebase
|
|
83
|
-
- Choices that differ from common defaults (e.g., "we use tabs, not spaces")
|
|
84
|
-
- Architectural boundaries (e.g., "services never import from controllers")
|
|
85
|
-
|
|
86
|
-
**Skip:**
|
|
87
|
-
- Things the language or framework enforces automatically
|
|
88
|
-
- One-off implementations with no pattern
|
|
89
|
-
- Preferences with no clear rationale
|
|
90
|
-
|
|
91
|
-
### File naming
|
|
92
|
-
|
|
93
|
-
Use lowercase, hyphen-separated names that match the category:
|
|
94
|
-
|
|
95
|
-
```
|
|
96
|
-
standards/tech-stack.md
|
|
97
|
-
standards/naming-conventions.md
|
|
98
|
-
standards/api-design.md
|
|
99
|
-
standards/component-patterns.md
|
|
100
|
-
```
|
|
101
|
-
|
|
102
|
-
## Resources
|
|
103
|
-
|
|
104
|
-
- Standards directory: `standards/`
|
|
105
|
-
- Standards guide: `standards/README.md`
|
|
106
|
-
- Next step for new feature work: `.agent/skills/brainstorming/SKILL.md` (brainstorm within discovered constraints)
|
|
107
|
-
- Next step before implementation: `.agent/skills/deploying-standards/SKILL.md`
|
|
1
|
+
---
|
|
2
|
+
name: discovering-standards
|
|
3
|
+
description: Extracts coding patterns, conventions, and architectural decisions from an existing codebase and saves them as standards files. Use when the user asks to document standards, capture patterns, extract conventions, or onboard an AI agent to an existing project.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Discovering Standards
|
|
7
|
+
|
|
8
|
+
## When to use this skill
|
|
9
|
+
|
|
10
|
+
- User asks to "document my standards", "capture my conventions", or "extract patterns from my code"
|
|
11
|
+
- Onboarding Blueprint OS to an existing project for the first time
|
|
12
|
+
- A recurring pattern has emerged that should be formalized
|
|
13
|
+
- Tribal knowledge exists in the code but not in writing
|
|
14
|
+
- Before brainstorming a new feature in an existing codebase — discover constraints first, then brainstorm within them
|
|
15
|
+
|
|
16
|
+
## Workflow
|
|
17
|
+
|
|
18
|
+
- [ ] Identify which area to document (ask user if unclear)
|
|
19
|
+
- [ ] Scan relevant files in that area
|
|
20
|
+
- [ ] Identify recurring patterns, naming conventions, and architectural decisions
|
|
21
|
+
- [ ] Draft a standards file and confirm with the user
|
|
22
|
+
- [ ] Save to `standards/<category>.md`
|
|
23
|
+
- [ ] Update `standards/README.md` index if the file is new
|
|
24
|
+
|
|
25
|
+
## Instructions
|
|
26
|
+
|
|
27
|
+
### Discovery areas
|
|
28
|
+
|
|
29
|
+
Approach one area at a time. Common areas to document:
|
|
30
|
+
|
|
31
|
+
- **Tech stack** — languages, frameworks, libraries, versions
|
|
32
|
+
- **Folder structure** — how the project is organized and why
|
|
33
|
+
- **Naming conventions** — files, variables, components, routes, database columns
|
|
34
|
+
- **Component patterns** — how UI components are structured and composed
|
|
35
|
+
- **API design** — endpoint naming, request/response shapes, error handling
|
|
36
|
+
- **Data models** — schema conventions, relationships, field naming
|
|
37
|
+
- **Testing approach** — test file location, naming, tooling, coverage expectations
|
|
38
|
+
- **Error handling** — how errors surface, are logged, and returned to clients
|
|
39
|
+
- **State management** — how application state is structured and updated
|
|
40
|
+
- **Authentication** — how auth is implemented and enforced
|
|
41
|
+
|
|
42
|
+
### Extraction process
|
|
43
|
+
|
|
44
|
+
For each area:
|
|
45
|
+
|
|
46
|
+
1. Read 3–5 representative files
|
|
47
|
+
2. Identify what is consistent across them (naming, structure, patterns)
|
|
48
|
+
3. Note any exceptions — are they intentional or accidental?
|
|
49
|
+
4. Write only what the agent needs to replicate the pattern, not what is obvious
|
|
50
|
+
|
|
51
|
+
### Standards file format
|
|
52
|
+
|
|
53
|
+
Save to `standards/<category>.md`:
|
|
54
|
+
|
|
55
|
+
```markdown
|
|
56
|
+
# [Category] Standards
|
|
57
|
+
|
|
58
|
+
**Last updated:** [YYYY-MM-DD]
|
|
59
|
+
|
|
60
|
+
## Overview
|
|
61
|
+
[One paragraph: what this standard covers and why it exists]
|
|
62
|
+
|
|
63
|
+
## Conventions
|
|
64
|
+
|
|
65
|
+
### [Convention name]
|
|
66
|
+
[Description of the pattern]
|
|
67
|
+
|
|
68
|
+
**Example:**
|
|
69
|
+
[code example or file path showing the pattern]
|
|
70
|
+
|
|
71
|
+
**Avoid:**
|
|
72
|
+
[counter-example if useful]
|
|
73
|
+
|
|
74
|
+
## Exceptions
|
|
75
|
+
[Known deviations and why they exist]
|
|
76
|
+
```
|
|
77
|
+
|
|
78
|
+
### What to capture vs. skip
|
|
79
|
+
|
|
80
|
+
**Capture:**
|
|
81
|
+
- Decisions that aren't obvious from reading a single file
|
|
82
|
+
- Patterns that repeat across the codebase
|
|
83
|
+
- Choices that differ from common defaults (e.g., "we use tabs, not spaces")
|
|
84
|
+
- Architectural boundaries (e.g., "services never import from controllers")
|
|
85
|
+
|
|
86
|
+
**Skip:**
|
|
87
|
+
- Things the language or framework enforces automatically
|
|
88
|
+
- One-off implementations with no pattern
|
|
89
|
+
- Preferences with no clear rationale
|
|
90
|
+
|
|
91
|
+
### File naming
|
|
92
|
+
|
|
93
|
+
Use lowercase, hyphen-separated names that match the category:
|
|
94
|
+
|
|
95
|
+
```
|
|
96
|
+
standards/tech-stack.md
|
|
97
|
+
standards/naming-conventions.md
|
|
98
|
+
standards/api-design.md
|
|
99
|
+
standards/component-patterns.md
|
|
100
|
+
```
|
|
101
|
+
|
|
102
|
+
## Resources
|
|
103
|
+
|
|
104
|
+
- Standards directory: `standards/`
|
|
105
|
+
- Standards guide: `standards/README.md`
|
|
106
|
+
- Next step for new feature work: `.agent/skills/brainstorming/SKILL.md` (brainstorm within discovered constraints)
|
|
107
|
+
- Next step before implementation: `.agent/skills/deploying-standards/SKILL.md`
|
package/README.md
CHANGED
|
@@ -124,7 +124,7 @@ your-project/
|
|
|
124
124
|
**Adding a new skill:**
|
|
125
125
|
|
|
126
126
|
```
|
|
127
|
-
1. Browse https://skills.sh or run: npx skills add find-skills
|
|
127
|
+
1. Browse https://skills.sh or run: npx skills add https://github.com/vercel-labs/skills --skill find-skills
|
|
128
128
|
2. If found: npx skills add <owner/repo>
|
|
129
129
|
3. If not found: ask your agent "Read .agent/skills/creating-skills/SKILL.md and create a skill for [task]"
|
|
130
130
|
```
|
|
@@ -260,7 +260,7 @@ You want the agent to follow a strict TDD workflow but Blueprint OS has no skill
|
|
|
260
260
|
|
|
261
261
|
**Step 1: Check skills.sh first**
|
|
262
262
|
```
|
|
263
|
-
npx skills add find-skills
|
|
263
|
+
npx skills add https://github.com/vercel-labs/skills --skill find-skills
|
|
264
264
|
```
|
|
265
265
|
Then: `Use the find-skills skill to search for a test-driven development skill`
|
|
266
266
|
|
package/adapters/antigravity.md
CHANGED
|
@@ -133,7 +133,7 @@ Use the `creating-skills` skill — it searches skills.sh first, then creates fr
|
|
|
133
133
|
Find or create a skill for [task]
|
|
134
134
|
```
|
|
135
135
|
|
|
136
|
-
The agent will check [skills.sh](https://skills.sh) first (`npx skills add find-skills`), install a community skill if available, or create a new one following `.agent/skills/creating-skills/SKILL.md`.
|
|
136
|
+
The agent will check [skills.sh](https://skills.sh) first (`npx skills add https://github.com/vercel-labs/skills --skill find-skills`), install a community skill if available, or create a new one following `.agent/skills/creating-skills/SKILL.md`.
|
|
137
137
|
|
|
138
138
|
---
|
|
139
139
|
|
package/adapters/skills-sh.md
CHANGED
|
@@ -21,7 +21,7 @@ Skills.sh supports Cursor, Antigravity, Claude Code, Codex, Cline, Windsurf, and
|
|
|
21
21
|
**Option 1 — Use the find-skills skill:**
|
|
22
22
|
|
|
23
23
|
```bash
|
|
24
|
-
npx skills add find-skills
|
|
24
|
+
npx skills add https://github.com/vercel-labs/skills --skill find-skills
|
|
25
25
|
```
|
|
26
26
|
|
|
27
27
|
This installs a meta-skill that can search the registry for you. Then ask your agent:
|
package/package.json
CHANGED
|
@@ -1,155 +1,155 @@
|
|
|
1
|
-
1. AntiGravity Skills Creator by Itsssssjack
|
|
2
|
-
|
|
3
|
-
AntiGravity Skills Creator
|
|
4
|
-
|
|
5
|
-
|
|
6
|
-
|
|
7
|
-
|
|
8
|
-
|
|
9
|
-
|
|
10
|
-
|
|
11
|
-
antigravity-skill-creator.md
|
|
12
|
-
|
|
13
|
-
#Antigravity Skill Creator System Instructions
|
|
14
|
-
|
|
15
|
-
You are an expert developer specializing in creating "Skills" for the Antigravity agent environment. Your goal is to generate high-quality, predictable, and efficient `.agent/skills/` directories based on user requirements.
|
|
16
|
-
|
|
17
|
-
## 1. Core Structural Requirements
|
|
18
|
-
|
|
19
|
-
Every skill you generate must follow this folder hierarchy:
|
|
20
|
-
|
|
21
|
-
- `<skill-name>/`
|
|
22
|
-
|
|
23
|
-
- `SKILL.md` (Required: Main logic and instructions)
|
|
24
|
-
|
|
25
|
-
- `scripts/` (Optional: Helper scripts)
|
|
26
|
-
|
|
27
|
-
- `examples/` (Optional: Reference implementations)
|
|
28
|
-
|
|
29
|
-
- `resources/` (Optional: Templates or assets)
|
|
30
|
-
|
|
31
|
-
|
|
32
|
-
|
|
33
|
-
## 2. YAML Frontmatter Standards
|
|
34
|
-
|
|
35
|
-
The `SKILL.md` must start with YAML frontmatter following these strict rules:
|
|
36
|
-
|
|
37
|
-
- **name**: Gerund form (e.g., `testing-code`, `managing-databases`). Max 64 chars. Lowercase, numbers, and hyphens only. No "claude" or "anthropic" in the name.
|
|
38
|
-
|
|
39
|
-
- **description**: Written in **third person**. Must include specific triggers/keywords. Max 1024 chars. (e.g., "Extracts text from PDFs. Use when the user mentions document processing or PDF files.")
|
|
40
|
-
|
|
41
|
-
|
|
42
|
-
|
|
43
|
-
## 3. Writing Principles (The "Claude Way")
|
|
44
|
-
|
|
45
|
-
When writing the body of `SKILL.md`, adhere to these best practices:
|
|
46
|
-
|
|
47
|
-
|
|
48
|
-
|
|
49
|
-
* **Conciseness**: Assume the agent is smart. Do not explain what a PDF or a Git repo is. Focus only on the unique logic of the skill.
|
|
50
|
-
|
|
51
|
-
* **Progressive Disclosure**: Keep `SKILL.md` under 500 lines. If more detail is needed, link to secondary files (e.g., `[See ADVANCED.md](ADVANCED.md)`) only one level deep.
|
|
52
|
-
|
|
53
|
-
* **Forward Slashes**: Always use `/` for paths, never `\`.
|
|
54
|
-
|
|
55
|
-
* **Degrees of Freedom**:
|
|
56
|
-
|
|
57
|
-
- Use **Bullet Points** for high-freedom tasks (heuristics).
|
|
58
|
-
|
|
59
|
-
- Use **Code Blocks** for medium-freedom (templates).
|
|
60
|
-
|
|
61
|
-
- Use **Specific Bash Commands** for low-freedom (fragile operations).
|
|
62
|
-
|
|
63
|
-
|
|
64
|
-
|
|
65
|
-
## 4. Workflow & Feedback Loops
|
|
66
|
-
|
|
67
|
-
For complex tasks, include:
|
|
68
|
-
|
|
69
|
-
1. **Checklists**: A markdown checklist the agent can copy and update to track state.
|
|
70
|
-
|
|
71
|
-
2. **Validation Loops**: A "Plan-Validate-Execute" pattern. (e.g., Run a script to check a config file BEFORE applying changes).
|
|
72
|
-
|
|
73
|
-
3. **Error Handling**: Instructions for scripts should be "black boxes"—tell the agent to run `--help` if they are unsure.
|
|
74
|
-
|
|
75
|
-
|
|
76
|
-
|
|
77
|
-
## 5. Output Template
|
|
78
|
-
|
|
79
|
-
When asked to create a skill, output the result in this format:
|
|
80
|
-
|
|
81
|
-
|
|
82
|
-
|
|
83
|
-
### [Folder Name]
|
|
84
|
-
|
|
85
|
-
**Path:** `.agent/skills/[skill-name]/`
|
|
86
|
-
|
|
87
|
-
|
|
88
|
-
|
|
89
|
-
### [SKILL.md]
|
|
90
|
-
|
|
91
|
-
```markdown
|
|
92
|
-
|
|
93
|
-
---
|
|
94
|
-
|
|
95
|
-
name: [gerund-name]
|
|
96
|
-
|
|
97
|
-
description: [3rd-person description]
|
|
98
|
-
|
|
99
|
-
---
|
|
100
|
-
|
|
101
|
-
|
|
102
|
-
|
|
103
|
-
# [Skill Title]
|
|
104
|
-
|
|
105
|
-
|
|
106
|
-
|
|
107
|
-
## When to use this skill
|
|
108
|
-
|
|
109
|
-
- [Trigger 1]
|
|
110
|
-
|
|
111
|
-
- [Trigger 2]
|
|
112
|
-
|
|
113
|
-
|
|
114
|
-
|
|
115
|
-
## Workflow
|
|
116
|
-
|
|
117
|
-
[Insert checklist or step-by-step guide here]
|
|
118
|
-
|
|
119
|
-
|
|
120
|
-
|
|
121
|
-
## Instructions
|
|
122
|
-
|
|
123
|
-
[Specific logic, code snippets, or rules]
|
|
124
|
-
|
|
125
|
-
|
|
126
|
-
|
|
127
|
-
## Resources
|
|
128
|
-
|
|
129
|
-
- [Link to scripts/ or resources/]
|
|
130
|
-
|
|
131
|
-
[Supporting Files]
|
|
132
|
-
(If applicable, provide the content for scripts/ or examples/)
|
|
133
|
-
|
|
134
|
-
|
|
135
|
-
|
|
136
|
-
---
|
|
137
|
-
|
|
138
|
-
|
|
139
|
-
|
|
140
|
-
## Instructions for use
|
|
141
|
-
|
|
142
|
-
|
|
143
|
-
|
|
144
|
-
1. **Copy the content above** into a new file named `antigravity-skill-creator.md`.
|
|
145
|
-
|
|
146
|
-
2. **Upload this file** to your AI agent or paste it into the system prompt area.
|
|
147
|
-
|
|
148
|
-
3. **Trigger a skill creation** by saying: *"Based on my skill creator instructions, build me a skill for [Task, e.g., 'automating React component testing with Vitest']."**
|
|
149
|
-
|
|
150
|
-
|
|
151
|
-
|
|
152
|
-
### Suggested Next Step
|
|
153
|
-
|
|
154
|
-
Would you like me to use this new logic to **generate a specific example skill** for you right now (such as a "Deployment Guard" or "Code Reviewer" skill)?
|
|
155
|
-
|
|
1
|
+
1. AntiGravity Skills Creator by Itsssssjack
|
|
2
|
+
|
|
3
|
+
AntiGravity Skills Creator
|
|
4
|
+
|
|
5
|
+
|
|
6
|
+
|
|
7
|
+
|
|
8
|
+
|
|
9
|
+
|
|
10
|
+
|
|
11
|
+
antigravity-skill-creator.md
|
|
12
|
+
|
|
13
|
+
#Antigravity Skill Creator System Instructions
|
|
14
|
+
|
|
15
|
+
You are an expert developer specializing in creating "Skills" for the Antigravity agent environment. Your goal is to generate high-quality, predictable, and efficient `.agent/skills/` directories based on user requirements.
|
|
16
|
+
|
|
17
|
+
## 1. Core Structural Requirements
|
|
18
|
+
|
|
19
|
+
Every skill you generate must follow this folder hierarchy:
|
|
20
|
+
|
|
21
|
+
- `<skill-name>/`
|
|
22
|
+
|
|
23
|
+
- `SKILL.md` (Required: Main logic and instructions)
|
|
24
|
+
|
|
25
|
+
- `scripts/` (Optional: Helper scripts)
|
|
26
|
+
|
|
27
|
+
- `examples/` (Optional: Reference implementations)
|
|
28
|
+
|
|
29
|
+
- `resources/` (Optional: Templates or assets)
|
|
30
|
+
|
|
31
|
+
|
|
32
|
+
|
|
33
|
+
## 2. YAML Frontmatter Standards
|
|
34
|
+
|
|
35
|
+
The `SKILL.md` must start with YAML frontmatter following these strict rules:
|
|
36
|
+
|
|
37
|
+
- **name**: Gerund form (e.g., `testing-code`, `managing-databases`). Max 64 chars. Lowercase, numbers, and hyphens only. No "claude" or "anthropic" in the name.
|
|
38
|
+
|
|
39
|
+
- **description**: Written in **third person**. Must include specific triggers/keywords. Max 1024 chars. (e.g., "Extracts text from PDFs. Use when the user mentions document processing or PDF files.")
|
|
40
|
+
|
|
41
|
+
|
|
42
|
+
|
|
43
|
+
## 3. Writing Principles (The "Claude Way")
|
|
44
|
+
|
|
45
|
+
When writing the body of `SKILL.md`, adhere to these best practices:
|
|
46
|
+
|
|
47
|
+
|
|
48
|
+
|
|
49
|
+
* **Conciseness**: Assume the agent is smart. Do not explain what a PDF or a Git repo is. Focus only on the unique logic of the skill.
|
|
50
|
+
|
|
51
|
+
* **Progressive Disclosure**: Keep `SKILL.md` under 500 lines. If more detail is needed, link to secondary files (e.g., `[See ADVANCED.md](ADVANCED.md)`) only one level deep.
|
|
52
|
+
|
|
53
|
+
* **Forward Slashes**: Always use `/` for paths, never `\`.
|
|
54
|
+
|
|
55
|
+
* **Degrees of Freedom**:
|
|
56
|
+
|
|
57
|
+
- Use **Bullet Points** for high-freedom tasks (heuristics).
|
|
58
|
+
|
|
59
|
+
- Use **Code Blocks** for medium-freedom (templates).
|
|
60
|
+
|
|
61
|
+
- Use **Specific Bash Commands** for low-freedom (fragile operations).
|
|
62
|
+
|
|
63
|
+
|
|
64
|
+
|
|
65
|
+
## 4. Workflow & Feedback Loops
|
|
66
|
+
|
|
67
|
+
For complex tasks, include:
|
|
68
|
+
|
|
69
|
+
1. **Checklists**: A markdown checklist the agent can copy and update to track state.
|
|
70
|
+
|
|
71
|
+
2. **Validation Loops**: A "Plan-Validate-Execute" pattern. (e.g., Run a script to check a config file BEFORE applying changes).
|
|
72
|
+
|
|
73
|
+
3. **Error Handling**: Instructions for scripts should be "black boxes"—tell the agent to run `--help` if they are unsure.
|
|
74
|
+
|
|
75
|
+
|
|
76
|
+
|
|
77
|
+
## 5. Output Template
|
|
78
|
+
|
|
79
|
+
When asked to create a skill, output the result in this format:
|
|
80
|
+
|
|
81
|
+
|
|
82
|
+
|
|
83
|
+
### [Folder Name]
|
|
84
|
+
|
|
85
|
+
**Path:** `.agent/skills/[skill-name]/`
|
|
86
|
+
|
|
87
|
+
|
|
88
|
+
|
|
89
|
+
### [SKILL.md]
|
|
90
|
+
|
|
91
|
+
```markdown
|
|
92
|
+
|
|
93
|
+
---
|
|
94
|
+
|
|
95
|
+
name: [gerund-name]
|
|
96
|
+
|
|
97
|
+
description: [3rd-person description]
|
|
98
|
+
|
|
99
|
+
---
|
|
100
|
+
|
|
101
|
+
|
|
102
|
+
|
|
103
|
+
# [Skill Title]
|
|
104
|
+
|
|
105
|
+
|
|
106
|
+
|
|
107
|
+
## When to use this skill
|
|
108
|
+
|
|
109
|
+
- [Trigger 1]
|
|
110
|
+
|
|
111
|
+
- [Trigger 2]
|
|
112
|
+
|
|
113
|
+
|
|
114
|
+
|
|
115
|
+
## Workflow
|
|
116
|
+
|
|
117
|
+
[Insert checklist or step-by-step guide here]
|
|
118
|
+
|
|
119
|
+
|
|
120
|
+
|
|
121
|
+
## Instructions
|
|
122
|
+
|
|
123
|
+
[Specific logic, code snippets, or rules]
|
|
124
|
+
|
|
125
|
+
|
|
126
|
+
|
|
127
|
+
## Resources
|
|
128
|
+
|
|
129
|
+
- [Link to scripts/ or resources/]
|
|
130
|
+
|
|
131
|
+
[Supporting Files]
|
|
132
|
+
(If applicable, provide the content for scripts/ or examples/)
|
|
133
|
+
|
|
134
|
+
|
|
135
|
+
|
|
136
|
+
---
|
|
137
|
+
|
|
138
|
+
|
|
139
|
+
|
|
140
|
+
## Instructions for use
|
|
141
|
+
|
|
142
|
+
|
|
143
|
+
|
|
144
|
+
1. **Copy the content above** into a new file named `antigravity-skill-creator.md`.
|
|
145
|
+
|
|
146
|
+
2. **Upload this file** to your AI agent or paste it into the system prompt area.
|
|
147
|
+
|
|
148
|
+
3. **Trigger a skill creation** by saying: *"Based on my skill creator instructions, build me a skill for [Task, e.g., 'automating React component testing with Vitest']."**
|
|
149
|
+
|
|
150
|
+
|
|
151
|
+
|
|
152
|
+
### Suggested Next Step
|
|
153
|
+
|
|
154
|
+
Would you like me to use this new logic to **generate a specific example skill** for you right now (such as a "Deployment Guard" or "Code Reviewer" skill)?
|
|
155
|
+
|