1. find-skills — discovery without blind installation
The first role is not execution; it is finding a narrower tool for the job. find-skills helps search the ecosystem, but a discovery result is only a candidate. Open the source, compare the requested access, and avoid installing a package merely because it appears in a result list.
Once the stack is stable, this Skill may be used less often. That is acceptable: its value is preventing a rushed first choice, not staying active in every workflow.
2. create-implementation-plan — make the change boundary visible
Before code changes, create-implementation-plan turns repository context into a written sequence of files, dependencies, checks, and open questions. A plan is valuable because it can be reviewed before write access expands.
Do not treat the plan as proof that the architecture is correct. The acceptance test is whether another developer can identify the intended change, likely blast radius, and first verification step without guessing.
3. skill-creator — encode only the workflow worth repeating
skill-creator earns a slot because a good local or team Skill can remove repeated prompting and preserve checks, references, and boundaries. Use it after a workflow has worked manually—not before the process is understood.
A generated Skill still needs trigger tests, negative examples, minimal references, and a review of every bundled script. The output is a maintainable instruction package, not an automatic quality or safety certificate.
4. differential-review — review the change, not the whole universe
differential-review gives the stack a change-focused review role. It is useful when the question is what this diff alters, what sensitive paths it touches, and where the blast radius may extend. Its scope is narrower and more auditable than a vague request to find every problem.
It does not replace repository knowledge, static analysis, or final approval. If the project needs rule-based or data-flow scanning, replace or supplement this role with Semgrep or CodeQL only when the team can triage the findings.
5. webapp-testing — preserve evidence of the user flow
webapp-testing completes the loop with observable browser evidence for a specific local flow. Define the route, state, expected result, and failure condition before the run; then keep the steps and artifacts a reviewer can reproduce.
Replace this fifth role when the product is not a web application. A CLI project may need TDD or reproduction tooling; a document workflow may need conversion and validation; a data pipeline may need query and cost checks. Preserve the evidence role, not the brand name.
Install order and the rule for keeping all five
Do not install all five on day one. Start with the Skill that owns the immediate bottleneck, run a small controlled task, and record what it read, changed, executed, and produced. Add the next role only after the first output passes its acceptance check.
Keep a Skill only when it has a distinct job, a source you can reopen, an output you actually inspect, and a failure condition you understand. If two Skills own the same decision, remove one before adding a sixth.
- Each Skill owns one role and one inspectable output.
- Project scope is the default; personal scope requires a cross-project reason.
- No Skill receives credentials or write access that its first test does not need.
- Every source revision and install path can be reconstructed.
- A named person still owns approval, deployment, and destructive actions.