From Personal Prompts to a Team Production Line: A 0‑to‑1 Guide for Skill Engineering

Introduction

The author explains that merely writing many prompts does not constitute a robust Skill; the real goal is to turn team experience into a stable, auditable, reusable AI asset.

Goal: Make team experience readable, executable, and iteratable by AI agents.

1. Re‑thinking Skills

A Skill is not just a collection of prompts. It is an interface that exposes team knowledge to an AI agent and must be versioned, verifiable, and shareable.

Engineering Skill = versioned rule file + verifiable examples + iterative record + shared team conventions

From Prompt to Team Production Line

The following maturity levels illustrate the progression:

Prompt: ad‑hoc chat entry – not reusable.

Single Skill: stored locally – unstable trigger, unclear boundaries.

Skill Library: multiple Skills together – naming chaos, overlapping responsibilities.

Team Production Line: shared, version‑controlled Skills with review and Bad‑Case feedback.

2. Invocation Methods

2.1 Automatic Matching (standard tasks)

Write a concrete description so the tool can match the Skill automatically.

帮我基于本周 commit 和 PR 生成一份团队周报。

Bad description example: 提升团队效率的 Skill。 Good description example:

当用户需要基于项目进展、PR、Commit、Issue 或会议记录生成团队周报时使用。输出结构化 Markdown 周报，突出成果、风险和下周计划。

More specific descriptions reduce mis‑fires.

2.2 Explicit Specification (critical tasks)

When boundaries are complex or the automatic match fails, manually name the Skill:

请使用 team-weekly-report 这个 Skill，基于以下信息生成周报。

Or use slash commands in tools that support them:

/team-weekly-report 生成本周研发周报，重点突出发布风险和下周计划

Cursor uses @rulename while Claude Code uses / – do not mix the two.

3. Design Principle: One Skill, One Clear Problem

Avoid “big‑and‑all” Skills that try to do many things at once; they become hard to trigger, test, and maintain.

spec-writer          负责把需求写成规格
task-planner         负责拆任务
code-reviewer        负责代码审查
release-checklist    负责发布检查
team-weekly-report   负责生成周报

Complex workflows should be composed of small, single‑purpose Skills.

4. Practical Example: Team Weekly Report Skill

The author builds a real Skill that generates a structured weekly report.

Step 1 – Create Directory

mkdir -p .cursor/rules/team-weekly-report
touch .cursor/rules/team-weekly-report/SKILL.md

For Claude Code the path is .claude/agents/team-weekly-report.

Step 2 – Write First Version

---
description: "当用户需要基于项目进展、PR、Commit、Issue 或会议记录生成团队周报时使用。输出结构化 Markdown 周报，突出成果、风险和下周计划。"
---

# Team Weekly Report Skill

## 使用场景
当用户要求生成团队周报、研发周报、项目进展汇报、管理层同步材料时，使用本 Skill。

## 输入要求
- 本周完成的功能、修复、文档或发布事项
- 关键 PR、Commit、Issue、需求单或项目链接
- 本周数据变化（交付数量、缺陷数量、上线次数）
- 当前风险、阻塞、外部协同事项
- 下周计划和负责人

如果信息不足，不要编造，先输出缺失信息清单并询问。

## 工作流程
1. 识别输入材料中的事实信息。
2. 将事实归类为：本周完成、关键数据、风险阻塞、下周计划、需要协同。
3. 合并重复事项，删除无关闲聊。
4. 将技术细节翻译为管理者可读的表达。
5. 输出 Markdown 周报。

## 输出格式
# 团队周报：YYYY-MM-DD 至 YYYY-MM-DD
## 一、本周完成
- ...
## 二、关键数据
- ...
## 三、风险与阻塞
- ...
## 四、下周计划
- ...
## 五、需要协同
- ...

## 质量要求
- 不夸大成果
- 不编造不存在的数据
- 风险要写清影响和建议动作
- 每条内容尽量包含负责人、项目或可追踪对象
- 管理层汇报时优先写结果和影响

This version works but is not yet engineered.

5. Adding Tests

Testing should include fixed inputs and expected outputs, not just a single manual run.

team-weekly-report/
├── SKILL.md
├── examples/
│   ├── input-good.md
│   ├── input-missing-info.md
│   └── input-too-technical.md
└── tests/
    └── checklist.md

Examples illustrate normal input, missing information, and overly technical input, together with the expected behaviours (e.g., ask for missing data, translate technical details into business language).

6. Bad‑Case Feedback Loop

When a Skill produces an incorrect or exaggerated output, record the Bad Case in SKILL.md and add a rule to prevent recurrence.

## 禁止行为
- 不得使用“显著提升”“大幅增长”等无数据支撑的判断。
- 如果输入没有量化数据，应该写成“已完成某项优化，待后续数据观察效果”。
- 不得把计划中的事项写成本周已完成。

For vague risk statements, add a concrete risk‑writing template:

风险必须包含三部分：
1. 风险事实：现在卡在哪里；
2. 可能影响：会影响什么交付或指标；
3. 建议动作：需要谁在什么时候做什么。

7. Version Control with Git

All Skills must live in a Git repository, with PR‑based changes, owner attribution, and test verification.

.cursor/
└── rules/
    └── team-weekly-report/
        ├── SKILL.md
        ├── examples/
        │   ├── input-good.md
        │   ├── input-missing-info.md
        │   └── input-too-technical.md
        └── tests/
            └── checklist.md

A PR description should cover why the change is needed, which trigger rules are modified, which Bad Case is fixed, impact on existing output, and which examples were used for verification.

8. Team Sharing Mechanism

Maintain a central skill library (e.g., ai-skills/) organized by domain (engineering, product, operation) and map it to tool‑specific directories.

Enforce naming conventions, trigger description style, output format, test examples, and review responsibility.

Provide a short onboarding path for newcomers: use three high‑frequency Skills, fix one Bad Case, then create a personal small Skill.

Assign a Skill Owner to keep the Skill valid, merge duplicates, resolve trigger conflicts, clean stale rules, and collect Bad Cases.

9. Skill Chains

When many Skills are needed for a full workflow, chain them via higher‑level task descriptions rather than relying on a strict execution engine.

需求澄清 → 任务拆解 → 代码实现 → 测试设计 → 代码审查 → 发布检查 → 周报沉淀

Each Skill should have a clear boundary; avoid overlapping responsibilities.

10. 30‑Day Roadmap

Week 1: Choose three high‑frequency scenarios (weekly report, code review, release checklist).

Week 2: Create a minimal Skill for each scenario with description, input, output, and prohibited behavior.

Week 3: Collect Bad Cases, add examples, and record them in a structured template.

Week 4: Establish review rules, assign owners, require PR‑based changes, run at least two examples per change, and schedule monthly cleanup.

11. Pre‑Release Checklist

Is the description concrete?

Does it specify how to ask for missing information?

Is the output format stable?

Are prohibited behaviors listed?

Are there at least two input examples?

Is there a Bad‑Case recording mechanism?

Is the Skill version‑controlled?

Is there an owner?

Does it avoid overlapping existing Skills?

Are tool and directory locations documented?

12. Final Call to Action

Start today by picking a repetitive task you do at least three times a week, write a SKILL.md for it, add two examples, commit to Git, and have a teammate try it.

Team success comes from turning scattered experience into auditable, reusable AI workflow assets.