Named in the 2026-07-05 README
Superpowers
Requirement clarification, executable plans, verification and review discipline. A historical influence — rd-skills does not enforce the same fixed chain today.
Story
From a skill collection to on-demand collaboration.
AI can generate code. The harder part is finding the owner of a rule, choosing the right expertise, understanding the real business boundary, and ending with validation someone can trust. Telling a model to “be more professional” does not say how to locate, how to judge, or when to stop. This page is about the attempts to say that.
Everything below is history. Older process names appear only to explain the evolution — they are not instructions for today.
Why it exists
Three questions every version kept asking.
- Is the expertise deep enough?
- Does it cover the business and technical mechanisms that actually fail?
- Is the selection accurate?
- Does the right knowledge reach the right role — rather than a keyword triggering a whole bundle?
- Is the process worth it?
- Does each extra step reduce real errors, or only add waiting, forms and tokens?
Milestones
Five dates you can check.
Beijing time (UTC+8). Repository metadata and the traceable commit history are different records: the repository existed before the root snapshot visible on master today.
2026-05-16
Repository created
The GitHub record of when the repository was created — not the date the idea first appeared.
Repository metadata2026-07-05
First traceable snapshot: ChangeForge Skill Mesh
The root commit on master, "first version". Professional skills, compiled Foundation delivery, several install profiles, hook-based expert guidance and a Superpowers-style plan–execute–verify–review flow.
fec0c9352026-08-05
Control plane and four-role boundary
One primary professional per task, Main that only dispatches, and Analysis, Task and Review separated. Default review and Direct/Analyzed rules then differed from today's.
PR #132026-09-11
Task-first, with depth on demand
Ordinary work became local inspection, edit and fresh validation. Analysis and independent review are triggered by a request or an important question; a single runtime and selective knowledge delivery were settled here.
PR #17 · #182026-09-15
Reference delivery, all the way to the host
Directly readable knowledge paths, owner-partitioned reference rules, and separate handling of exact versus unresolved references. The question moved from what was selected to what the worker can actually read.
PR #22
Read this as recalibration, not as “the old was wrong and the new is right”. Each step kept the useful professional constraints and evidence, and moved where they load, what they cost, and who is responsible for them.
What drove the changes
Three tensions, and where each one landed.
| Tension | What iteration taught | Mechanism today |
|---|---|---|
| Professional depth vs context cost | Depth is not loading everything every time — and saving tokens cannot mean dropping knowledge a decision needs. | Short, complete root files · Layer 3 chosen per task · references read on their own conditions. |
| Reliable process vs over-engineering | Analysis, planning and review are valuable, but repeating them by task count does not raise correctness. | Implementation first; analysis and review only when an important question calls for them. |
| Precise selection vs actual availability | Choosing the right name is not enough if the worker cannot read the body, or does not know references are still unresolved. | Host-resolved body paths · owner-partitioned references · unresolved kept distinct from an exact empty list. |
Professional depth vs context cost
Depth is not loading everything every time — and saving tokens cannot mean dropping knowledge a decision needs.
Short, complete root files · Layer 3 chosen per task · references read on their own conditions.
Reliable process vs over-engineering
Analysis, planning and review are valuable, but repeating them by task count does not raise correctness.
Implementation first; analysis and review only when an important question calls for them.
Precise selection vs actual availability
Choosing the right name is not enough if the worker cannot read the body, or does not know references are still unresolved.
Host-resolved body paths · owner-partitioned references · unresolved kept distinct from an exact empty list.
What stayed
Four judgments that carry through every version.
- 01
Current source comes first
Paths, search rank, old summaries and model confidence cannot stand in for real behaviour and owner evidence.
- 02
Choosing expertise is not escalating process
Knowledge deepens judgment. It does not add requirements, abstractions, agents or review.
- 03
Validation and review each do their own job
Tests prove the selected behaviour; review gives a specific independent judgment. Both state what they cover.
- 04
Extra cost has to serve the result
Longer prompts, more skills and more loops are not success metrics. A correct, maintainable, explainable change is.
Influences
Only what has a documented source.
Separation of duties, a single source of truth, dependency-driven planning, minimal correct change and evidence freshness all have counterparts in general engineering practice. Beyond the two below, similar ideas are not claimed as code inheritance, dependencies, official compatibility or performance leadership.
Format and progressive disclosure
Agent Skills
SKILL.md packages metadata, instructions and on-demand resources. rd-skills uses that portable carrier and adds its own Professional, Foundation and Domain routing.