writing-skills

Name: writing-skills
Author: alexei-led

35stars5forks

How to install writing-skills?

alexei-led/cc-thingz/writing-skills

$npx -y skills add alexei-led/cc-thingz --skill writing-skills

Installs into the current project.

Summary

Create or reshape a skill so it triggers at the right time, stays lean, and matches this repo's source and build rules.

Files · 1

View on GitHub

SKILL.md

1	# Writing Skills
2
3	Create or reshape a skill so it triggers at the right time, stays lean, and
4	matches this repo's source and build rules.
5
6	## Read first
7
8	- `AGENTS.md` section `## Writing Agent/Skill Instructions` for markdown signal rules.
9	- `references/skill-principles.md` for invocation, description, disclosure, split,
10	and pruning rules.
11	- `references/repo-conventions.md` for `src/skills/`, plugin manifests, overlays,
12	generated outputs, and verification.
13	- `src/skills/reviewing-instructions/references/scoring-rubric.md` only after the
14	draft exists and quality needs a final check.
15
16	## Use this skill for
17
18	- creating a new skill
19	- rewriting a skill body or description
20	- splitting one skill into a skill plus references
21	- splitting one skill into two skills when the trigger or workflow boundary is real
22	- merging or extending overlapping skills after checking the neighboring skills
23	- pruning bloated skill prose, duplicate rules, or weak trigger phrasing
24	- adding target overlays or support files to a skill
25
26	## Do not use this skill for
27
28	- scoring or linting prompt files without editing them; use `reviewing-instructions`
29	- broad agent, hook, extension, MCP, or package audits outside skill authoring;
30	use `evolving-config`
31	- ordinary docs, READMEs, or code comments; use `documenting-code`
32	- external library or API lookup; use `looking-up-docs`
33	- broad design debate before a concrete skill change exists; use
34	`brainstorming-ideas`
35
36	## Workflow
37
38	1. Find the source of truth under `src/skills/<name>/`. Read the owning
39	`src/.agentbundler/packages/*.json` and the closest neighboring skills before
40	editing. Treat `dist/` as generated.
41	2. State the smallest correct shape:
42	- edit the current skill
43	- move conditional detail to `references/`
44	- add a `.agentbundler/targets/<target>.json` overlay
45	- split into two skills
46	- merge or fold into a neighboring skill
47	3. Decide invocation mode and trigger surface.
48	- Model-invoked: use when the agent or another skill must discover it on its
49	own.
50	- User-invoked: use when it is mostly a manual expert tool or reference.
51	- Keep one trigger per branch. Name real neighboring skills when overlap is
52	possible. Put the NOT-clause in the description, not as an afterthought.
53	4. Split content per the information hierarchy in
54	`references/skill-principles.md`. Keep only common-path rules in the main
55	body. Move conditional detail to `references/`. Use Agent Bundler JSON
56	overlays only when the base cannot stay vendor-neutral: `frontmatterPatch`,
57	`bodyPatch`, `files`, and `deletedFiles`.
58	5. Tighten wording until each line changes behavior. Delete generic agent advice,
59	duplicated rules, and pretty prose.
60	6. When adding or removing a public skill, update the owning package JSON in
61	`src/.agentbundler/packages/`. Update `AGENTS.md` and `README.md` when they
62	expose the public skill surface or counts.
63	7. Before claiming done, run the narrowest verification that proves the new skill
64	compiles and reads well.
65	8. If quality is still uncertain, run `reviewing-instructions` on the new or
66	changed skill and apply the highest-value fixes.
67
68	## Writing rules
69
70	- Bias toward predictability over style.
71	- Prefer headers, bullets, numbered steps, and short imperative lines.
72	- Keep each meaning in one place.
73	- Inline only what every trigger path needs.
74	- Use references for detail that only some branches need.
75	- Add an output contract when the skill produces findings, plans, edits, or
76	artifacts.
77	- Add failure handling for ambiguous scope, missing inputs, generated files,
78	unavailable tools, and verification gaps.
79	- Do not create a new skill just to rename an existing trigger.
80	- Do not add a target overlay when a vendor-neutral base already works.
81
82	## Output
83
84	Write-capable role:
85
86	```markdown
87	## Skill Update
88
89	Updated:
90
91	- `path` — <created or changed>
92
93	Plugin:
94
95	- <plugin name or unchanged>
96
97	Routing:
98
99	- Invocation: model-invoked \| user-invoked
100	- Trigger surface: <main trigger terms>
101	- Excludes: <neighbor skills or none>
102
103	Verified:
104
105	- <check>: passed \| skipped (<reason>)
106
107	Follow-up:
108
109	- <reviewing-instructions run, docs update, or none>
110	```
111
112	Read-only role:
113
114	```markdown
115	## Proposed Skill Change
116
117	Files:
118
119	- `path`
120
121	Why:
122
123	- <routing, disclosure, or repo-convention reason>
124
125	Proposed shape:
126
127	- Invocation: model-invoked \| user-invoked
128	- Plugin: <plugin>
129	- References or overlays: <list or none>
130
131	Patch summary:
132
133	- <small bullet list of edits>
134
135	Verification:
136
137	- <checks the applier should run, or not r

People who liked this also viewed

6 picks

Type

lark-drive飞书云空间（云盘/云存储）：管理 Drive 文件和文件夹，包含上传/下载、创建文件夹、复制/移动/删除、查看元数据、评论/权限/订阅、标题、版本、飞书文档密级标签（secure labels）和本地文件导入。用户需要整理云盘目录、处理云空间资源 URL/token、判断链接类型/真实 token/标题，或导入 Word/Markdown/Excel/CSV/PPTX/.base 为 docx/sSkillsJul 2026382k16k
lark-sharedUse for lark-cli setup/auth tasks: auth login/status/logout, user vs bot identity, business-domain permissions (--domain, including all/docs/drive), missing scopes, revoking authorization, or handlingSkillsJul 2026382k16k
lark-whiteboard飞书画板：查询和编辑飞书云文档中的画板。支持导出画板为预览图片、导出原始节点结构、使用多种格式更新画板内容。当用户需要查看画板内容、导出画板图片、编辑画板时使用此 skill。不负责：飞书云文档内容编辑（lark-doc）、文档内嵌电子表格/Base（lark-sheets / lark-base）。SkillsJul 2026380k16k
lark-task飞书任务：管理任务、清单和任务智能体。创建待办任务、查看和更新任务状态、拆分子任务、组织任务清单、分配协作成员、上传任务附件、注册或注销任务智能体、更新任务智能体的主页数据、写入智能体任务记录。当用户需要创建待办事项、查看任务列表、跟踪任务进度、管理项目清单或给他人分配任务、为任务上传附件文件、注册注销任务智能体、更新智能体主页数据、写入任务记录时使用。SkillsJul 2026380k16k
lark-attendance飞书考勤打卡：查询自己的考勤打卡记录SkillsJul 2026330k16k
lark-apps妙搭（Spark/Miaoda）应用开发与托管：应用创建、本地全栈开发、云端生成迭代、创意设计（UI mockup / 可交互原型 / 线框图 / 落地页 / 仪表盘 / 幻灯片 deck / 视觉探索）、AI相关能力和飞书平台能力或者其他外部能力集成、日志/Trace/监控指标/PV/UV 查询、环境变量管理、应用角色与成员管理、自动化触发器（定时/记录变更/Webhook/飞书审批）。当用户要SkillsJul 2026227k16k

writing-skills

35stars5forks

View on GitHub

How to install writing-skills?

alexei-led/cc-thingz/writing-skills

$npx -y skills add alexei-led/cc-thingz --skill writing-skills

Installs into the current project.

Summary

Create or reshape a skill so it triggers at the right time, stays lean, and matches this repo's source and build rules.

Files · 1

View on GitHub

SKILL.md

1	# Writing Skills
2
3	Create or reshape a skill so it triggers at the right time, stays lean, and
4	matches this repo's source and build rules.
5
6	## Read first
7
8	- `AGENTS.md` section `## Writing Agent/Skill Instructions` for markdown signal rules.
9	- `references/skill-principles.md` for invocation, description, disclosure, split,
10	and pruning rules.
11	- `references/repo-conventions.md` for `src/skills/`, plugin manifests, overlays,
12	generated outputs, and verification.
13	- `src/skills/reviewing-instructions/references/scoring-rubric.md` only after the
14	draft exists and quality needs a final check.
15
16	## Use this skill for
17
18	- creating a new skill
19	- rewriting a skill body or description
20	- splitting one skill into a skill plus references
21	- splitting one skill into two skills when the trigger or workflow boundary is real
22	- merging or extending overlapping skills after checking the neighboring skills
23	- pruning bloated skill prose, duplicate rules, or weak trigger phrasing
24	- adding target overlays or support files to a skill
25
26	## Do not use this skill for
27
28	- scoring or linting prompt files without editing them; use `reviewing-instructions`
29	- broad agent, hook, extension, MCP, or package audits outside skill authoring;
30	use `evolving-config`
31	- ordinary docs, READMEs, or code comments; use `documenting-code`
32	- external library or API lookup; use `looking-up-docs`
33	- broad design debate before a concrete skill change exists; use
34	`brainstorming-ideas`
35
36	## Workflow
37
38	1. Find the source of truth under `src/skills/<name>/`. Read the owning
39	`src/.agentbundler/packages/*.json` and the closest neighboring skills before
40	editing. Treat `dist/` as generated.
41	2. State the smallest correct shape:
42	- edit the current skill
43	- move conditional detail to `references/`
44	- add a `.agentbundler/targets/<target>.json` overlay
45	- split into two skills
46	- merge or fold into a neighboring skill
47	3. Decide invocation mode and trigger surface.
48	- Model-invoked: use when the agent or another skill must discover it on its
49	own.
50	- User-invoked: use when it is mostly a manual expert tool or reference.
51	- Keep one trigger per branch. Name real neighboring skills when overlap is
52	possible. Put the NOT-clause in the description, not as an afterthought.
53	4. Split content per the information hierarchy in
54	`references/skill-principles.md`. Keep only common-path rules in the main
55	body. Move conditional detail to `references/`. Use Agent Bundler JSON
56	overlays only when the base cannot stay vendor-neutral: `frontmatterPatch`,
57	`bodyPatch`, `files`, and `deletedFiles`.
58	5. Tighten wording until each line changes behavior. Delete generic agent advice,
59	duplicated rules, and pretty prose.
60	6. When adding or removing a public skill, update the owning package JSON in
61	`src/.agentbundler/packages/`. Update `AGENTS.md` and `README.md` when they
62	expose the public skill surface or counts.
63	7. Before claiming done, run the narrowest verification that proves the new skill
64	compiles and reads well.
65	8. If quality is still uncertain, run `reviewing-instructions` on the new or
66	changed skill and apply the highest-value fixes.
67
68	## Writing rules
69
70	- Bias toward predictability over style.
71	- Prefer headers, bullets, numbered steps, and short imperative lines.
72	- Keep each meaning in one place.
73	- Inline only what every trigger path needs.
74	- Use references for detail that only some branches need.
75	- Add an output contract when the skill produces findings, plans, edits, or
76	artifacts.
77	- Add failure handling for ambiguous scope, missing inputs, generated files,
78	unavailable tools, and verification gaps.
79	- Do not create a new skill just to rename an existing trigger.
80	- Do not add a target overlay when a vendor-neutral base already works.
81
82	## Output
83
84	Write-capable role:
85
86	```markdown
87	## Skill Update
88
89	Updated:
90
91	- `path` — <created or changed>
92
93	Plugin:
94
95	- <plugin name or unchanged>
96
97	Routing:
98
99	- Invocation: model-invoked \| user-invoked
100	- Trigger surface: <main trigger terms>
101	- Excludes: <neighbor skills or none>
102
103	Verified:
104
105	- <check>: passed \| skipped (<reason>)
106
107	Follow-up:
108
109	- <reviewing-instructions run, docs update, or none>
110	```
111
112	Read-only role:
113
114	```markdown
115	## Proposed Skill Change
116
117	Files:
118
119	- `path`
120
121	Why:
122
123	- <routing, disclosure, or repo-convention reason>
124
125	Proposed shape:
126
127	- Invocation: model-invoked \| user-invoked
128	- Plugin: <plugin>
129	- References or overlays: <list or none>
130
131	Patch summary:
132
133	- <small bullet list of edits>
134
135	Verification:
136
137	- <checks the applier should run, or not r

People who liked this also viewed

6 picks

Type