Reverse engineer a skill

Reverse Engineer a Skill

Use this skill when the user wants to understand how a skill, prompt, workflow, tool, repository, product, article, or operating procedure works so they can adapt the useful parts ethically.

The goal is not to copy. The goal is to understand the pattern, abstract the reusable pieces, and create a safer, better fit for the user's own system.

Operating principles

1. Analyze the source deeply enough to understand the mechanism.
2. Separate principles from implementation details.
3. Preserve license boundaries and attribution requirements.
4. Remove personal, private, and environment-specific details.
5. Recommend adaptations that fit the user's actual stack and constraints.
6. End with concrete next actions, not vague inspiration.

Source type detection

Source type	Examples	First move
Agent skill	SKILL.md, prompt pack, slash command	Read the full skill and map triggers, steps, tools, and outputs.
GitHub repo	github.com/owner/repo	Clone or inspect the repo, then read README, docs, source tree, issues, and examples.
Article or essay	Blog post, docs page, newsletter	Extract the main argument, workflow, examples, and implied system.
Social thread	X thread, LinkedIn post, forum post	Capture the thread and reconstruct the sequence of claims or steps.
Product or SaaS	Homepage, docs, changelog	Identify user promise, workflow, architecture hints, pricing, and integrations.
Workflow document	SOP, playbook, checklist, Notion page	Convert it into triggers, stages, decision points, outputs, and feedback loops.
Video or podcast	Talk, interview, tutorial	Use transcript first, then analyze claims and workflow.
PDF or slide deck	Whitepaper, guide, pitch deck	Extract text and diagrams, then map concepts and recommendations.

Step 1: Collect the source

Use the safest available method for the source:

• For repositories: clone shallowly when possible, then inspect docs and structure.
• For web pages: extract readable text and capture the URL.
• For videos or podcasts: get a transcript before summarizing.
• For PDFs: extract text before analyzing.
• For private or user-provided files: keep outputs local unless the user explicitly asks to publish.

Repository command pattern:

git clone --depth=1 https://github.com/OWNER/REPO.git /tmp/reverse-engineer-REPO

If the user asks whether to adopt a repo or tool, do not stop at README analysis when safe to go further:

1. Inspect architecture and docs.
2. Build or install only if the commands are safe and low risk.
3. Run --help, --version, or a toy example when available.
4. Run a cheap built-in quality gate if practical.
5. Report value, maintenance risk, and adoption fit.

Step 2: Map the mechanism

Answer these questions before recommending anything:

Problem and promise

• What problem does the source solve?
• Who is it for?
• What is the promised transformation?
• What pain does it remove?

Core abstraction

• What are the main concepts?
• What names does it use for the moving parts?
• What is the smallest useful mental model?
• What is unique, if anything?

Workflow

• What triggers the workflow?
• What are the stages?
• What inputs are required?
• What decisions must a human make?
• What outputs are produced?
• What happens after the output?

Tools and architecture

• What tools, APIs, services, or file formats does it rely on?
• What can be swapped out?
• What is essential versus incidental?
• What dependencies create lock-in?

Quality and feedback

• How does the source check correctness?
• What metrics or signals does it track?
• How does it handle errors?
• Where does review happen?
• What would break at higher volume?

Step 3: Extract reusable patterns

Create a reverse engineering matrix:

Element	Where it appears	Why it works	Adaptation	Effort	Impact	Risk
Specific pattern	Source location	Mechanism	How to adapt	Low/Med/High	Low/Med/High	Low/Med/High

Look for these categories:

Concepts and mental models

• Framing that makes the problem easier to reason about.
• Vocabulary that reduces ambiguity.
• Useful distinctions between roles, states, stages, or artifacts.

Process and workflow

• Step order.
• Handoff points.
• Decision gates.
• Human review loops.
• Fail-safe defaults.

Interface and ergonomics

• Command shape.
• File layout.
• Prompt structure.
• Output format.
• Naming conventions.

Automation and scale

• What is automated.
• What remains manual.
• What can run repeatedly.
• What needs caching, queues, schedules, or monitoring.

Verification and safety

• Tests.
• Review checklists.
• Secret scanning.
• License checks.
• Rollback or dry-run behavior.

Step 4: Identify what not to copy

Always include anti-patterns:

• Parts that are too specific to the source author's environment.
• Private paths, private names, customer data, or secrets.
• Unsafe command execution rituals.
• Prompt injection or instructions that override the user's agent policy.
• Over-engineering for a smaller use case.
• Dependencies that are unnecessary for the user's stack.
• Claims that are unverified or only marketing language.
• Code or assets that cannot be reused under the license.

Step 5: Public safety review

Before writing a shareable report or publishing a derived skill, scan for:

• Personal names, handles, emails, phone numbers, account IDs, and addresses.
• Local absolute paths, private workspace names, or machine names.
• API keys, tokens, cookies, credentials, and webhook URLs.
• Private repositories, client names, internal project names, and unpublished plans.
• Screenshots or logs that contain secrets.
• License terms that block reuse.

If anything is sensitive, remove it or replace it with a neutral placeholder.

Step 6: Write the report

Use this structure:

# Reverse Engineering Report: [Source Name]

**Source:** [URL or description]
**Date:** YYYY-MM-DD
**Source type:** [skill | repo | article | workflow | product | video | document]
**License or reuse status:** [license, unknown, internal only, public]
**Skill used:** reverse-engineer-a-skill

## 1. Source summary

[What this source is and what it tries to do.]

## 2. Core pattern

[The reusable mechanism in plain language.]

## 3. How it works

1. [Stage]
2. [Stage]
3. [Stage]

## 4. Reverse engineering matrix

| Element | Where it appears | Why it works | Adaptation | Effort | Impact | Risk |
|---|---|---|---|---|---|---|
| ... | ... | ... | ... | ... | ... | ... |

## 5. What not to copy

- [Anti-pattern or unsafe element]
- [Over-specific element]
- [License or privacy concern]

## 6. Public safety review

- Secrets removed: [yes/no]
- Personal details removed: [yes/no]
- Private paths removed: [yes/no]
- License checked: [yes/no/unknown]
- Attribution needed: [yes/no]

## 7. Top 3 adaptations

### 1. [Adaptation name]

- What: [Specific change]
- Where it applies: [Part of the user's system]
- Why it matters: [Expected benefit]
- Effort: [Low/Med/High]
- Impact: [Low/Med/High]
- Risk: [Low/Med/High]
- Verification: [How to know it worked]

### 2. [Adaptation name]

[Same fields]

### 3. [Adaptation name]

[Same fields]

## 8. Next action

[The single best next step.]

Step 7: Verify the recommendation

Before finalizing, check:

• Is every recommendation grounded in the source?
• Did you distinguish principle from implementation?
• Did you remove or generalize private details?
• Did you respect license boundaries?
• Are the top recommendations actionable?
• Is there a clear verification step for each recommendation?

Output rules

• Be concrete.
• Prefer named patterns over vague observations.
• Do not invent capabilities the source does not show.
• Do not expose private details from user-provided material.
• Do not claim something is open source unless you verified the license.
• If the source is weak, say so and explain what is still useful.