Skill detail

skill-deconstruction

Six-step framework to analyze and reverse-engineer an existing WorkBuddy skill or agent workflow, covering delivery, actions, order, division of labor, constraints, and principle.

MatchDirectRecommended for WorkBuddy
Sourceleonfrank/​skill-deconstructionExternal source
Reported installs1Popularity signal only

Inspect before use

Read the source instructions and check the requirements before you install this skill.

Saved source preview

SKILL.md

The saved excerpt is a snapshot from when this skill was listed. The external source remains the complete and most current version.

---
name: skill-deconstruction
description: This skill should be used when the user wants to analyze, reverse-engineer, or "拆解" an existing WorkBuddy skill (or any agent/prompt/workflow) to understand what it actually delivers, how it works, and the constraints and principles behind it. Provides a six-step framework (delivery → actions → order → division of labor → constraints → principle) that turns a vague "this skill does X" impression into a precise, defensible analysis. Trigger on requests like "拆一下这个 skill", "analyze how this skill works", "拆解 photo-abstract-editorial", or "what does this skill really do".
agent_created: true
---

# Skill Deconstruction (六步拆 skill)

## Purpose

Turn "I tried a skill and it seems useful" into a precise answer to: *what does it deliver, how does it work, and why is it built that way*. The method deliberately ignores feature labels ("可以做 PPT", "能写文案") and instead establishes the endpoint first, then reverse-engineers the work, the ordering, the responsibility split, the guardrails, and the underlying principle.

Use this skill when the user asks to deconstruct, analyze, or reverse-engineer any skill, agent, or prompt-based workflow — especially after running it once.

## When to Run

1. The user names a skill (installed, marketplace, or just pasted) and asks to understand it.
2. The user says "拆"/"拆解"/"deconstruct"/"analyze" about a skill.
3. The user wants to judge a skill's reliability, reuse it, or adapt it.

Prefer running the target skill once (or reading its SKILL.md + bundled references) before deconstructing, so the analysis is grounded in real behavior.

## The Six Steps

Work through the steps **in order**. Each step has a strict output format — do not skip the format, because the format is the analysis.

### Step 1 — Delivery (终点)

Skip feature descriptions. Establish the endpoint so every later step has an evaluation standard.

- Identify the **final deliverable type**: a conversation, a file, an executable judgment, or (as here) a generated artifact.
- Identify the **input** it receives and the **channel** it uses to hand the result to the user (returned image, written file, printed conclusion, etc.).
- Write the completion condition.

**Output — one sentence:** "This skill turns `<input>` into `<result>`, and is complete when `<condition>`."

### Step 2 — Actions (做了什么)

Reverse-engineer the concrete operations. Never summarize as "进行了全面分析". Make each step observable.

- List what it **reads**, what it **judges/decides**, what it **generates**, and what it **checks**.
- Strip tool names if needed but keep the operation concrete.

**Output — an observable action chain:** 读取 A → 判断 B → 生成 C → 渲染 D → 检查 E.

### Step 3 — Order (因果链)

Walk the action chain and question every sequence: why this before that; what breaks if the two swap or one is deleted.

- For each ordering, state the problem it prevents. Example: "先明确受众再生成内容" exists because the result depends on an evaluation standard, so the standard must be locked before production begins.

**Output — a causal chain:** "为了解决 `<problem>`, 所以必须先 `<action X>` 再 `<action Y>`."

### Step 4 — Division of Labor (责任图)

Assign an executor to every action. Typical split:

- **AI model**: understanding, comparison, trade-offs.
- **Scripts/tools**: computation, formatting, repeated execution.
- **External sources**: supply new facts.
- **Human**: final judgment on goals/acceptance.

Flag whether the skill has any script/tool boundary or human-in-the-loop checkpoint. The *absence* of these is itself a finding (e.g., a prompt-only skill where the only enforcer of constraints is the model's self-compliance).

**Output — a responsibility map:** who does what, on what basis, and who owns the final result.

### Step 5 — Constraints (风险 ↔ 规则)

Extract every "必须 / 不要 / 只能 / 失败就停止" rule. For each, ask: what goes wrong if this rule is missing? Steps tell you how the author makes it work; constraints tell you what they are defending against — the dense
Read the full source on GitHub (opens external page)
Context

Related work