Skip to content

Commit 703be95

Browse files
authored
doc: add all enhancements for skill instructions sharing and scripts to CONTRIBUTING best practices (#160)
1 parent 2674b29 commit 703be95

2 files changed

Lines changed: 91 additions & 1 deletion

File tree

CONTRIBUTING.md

Lines changed: 89 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -64,6 +64,95 @@ Add a row to the skills table in `README.md`:
6464
- **Provide complete, copy-pasteable snippets** — not fragments.
6565
- **Reference packages by full name** (e.g., `package:mocktail`, not just "mocktail").
6666
- **Show anti-patterns alongside correct patterns** when helpful, so readers understand both what to do and what to avoid.
67+
- **Keep prose tight** — every word in a SKILL.md consumes tokens in the model's context window. Verbose instructions reduce the space available for the user's actual work. Apply these techniques:
68+
- **Decision tables over prose chains** — replace long if/else narratives with a table or compact bulleted list.
69+
- **One sentence per rule** — if a guideline needs a paragraph to explain, it may be too complex or doing too much.
70+
- **Cut redundancy** — don't restate in an "Important" footer what the body already says.
71+
- **Collapse conditional blocks** — when multiple branches share structure, describe the shared part once and list only what differs.
72+
73+
## Shared Resources & Skill Boundaries
74+
75+
### The skill directory boundary
76+
77+
A skill can only reference files inside its own directory. Paths that escape the skill folder (e.g., `../shared/references/foo.md`) will fail validation with a `reference-exists` error. This applies to both markdown reference links and script paths in `!` blocks.
78+
79+
### Sharing content across skills
80+
81+
When multiple skills need the same content (templates, instructions, procedures), store the canonical file in `skills/shared/` and create a **symlink** inside each skill that needs it.
82+
83+
**Directory layout:**
84+
85+
```text
86+
skills/
87+
shared/
88+
references/
89+
validate-and-fix.md # canonical file
90+
scripts/
91+
detect-base-branch.sh # canonical file
92+
build/
93+
references/
94+
validate-and-fix.md -> ../../shared/references/validate-and-fix.md
95+
SKILL.md
96+
hotfix/
97+
references/
98+
validate-and-fix.md -> ../../shared/references/validate-and-fix.md
99+
SKILL.md
100+
```
101+
102+
**Creating a symlink:**
103+
104+
```bash
105+
# From the repo root
106+
ln -s ../../shared/references/validate-and-fix.md skills/build/references/validate-and-fix.md
107+
```
108+
109+
**Referencing in SKILL.md** — always use the local path:
110+
111+
```markdown
112+
Follow the [validation and fix procedure](references/validate-and-fix.md).
113+
```
114+
115+
Never reference `../shared/` directly in a SKILL.md — the symlink makes the shared file appear local.
116+
117+
### Shared scripts
118+
119+
The same boundary rule applies to scripts. Store canonical scripts in `skills/shared/scripts/`, symlink into each skill's `scripts/` directory, and reference them locally.
120+
121+
**Example — adding a shared script to a skill:**
122+
123+
```bash
124+
mkdir -p skills/my-skill/scripts
125+
ln -s ../../shared/scripts/detect-base-branch.sh skills/my-skill/scripts/detect-base-branch.sh
126+
```
127+
128+
**Referencing in SKILL.md:**
129+
130+
````markdown
131+
```!
132+
bash scripts/detect-base-branch.sh
133+
```
134+
````
135+
136+
### When to use scripts vs inline bash
137+
138+
Use a script when the operation is:
139+
140+
- **Deterministic** — no LLM judgment needed, just structured output
141+
- **Reusable** — the same logic appears in 2+ skills
142+
- **Multi-step** — combines several commands with conditional logic
143+
144+
Keep inline bash when:
145+
146+
- It's a single, simple command (e.g., `git rev-parse --abbrev-ref HEAD`)
147+
- The model needs to see the raw output to make a decision
148+
- The command is skill-specific and unlikely to be reused
149+
150+
**Script conventions:**
151+
152+
- Use `#!/usr/bin/env bash` and `set -euo pipefail` — this exits on any error (`-e`), treats unset variables as errors (`-u`), and fails the whole pipeline if any command in a pipe fails (`-o pipefail`). Without it, scripts can silently swallow failures.
153+
- Output structured, parseable text (e.g., `KEY=value` lines)
154+
- Write errors to stderr, data to stdout
155+
- Exit 1 on failure with a descriptive message
67156

68157
## CI Checks
69158

config/cspell.json

Lines changed: 2 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -19,7 +19,8 @@
1919
"pasteable",
2020
"pubspec",
2121
"worktrees",
22-
"undiscussed"
22+
"undiscussed",
23+
"pipefail"
2324
],
2425
"flagWords": []
2526
}

0 commit comments

Comments
 (0)