Public source for RelayView-maintained instruction-only role skills and an illustrative author starter. The proprietary RelayView owner controls workflow stages, role tools, verification, and Human acceptance. A skill guides one assigned role during one step; it does not add tools, credentials, network access, or workflow authority.
Only named releases of maintained packages receive RelayView compatibility testing and maintenance. Optional guidance requires explicit role assignment; the two original defaults remain available. User forks are maintained by their publishers. This release uses the instruction package schema version 1 admitted by RelayView's Community MVP. It contains only `SKILL.md`, declared `.md`/`.txt` resources, and `relayview-skill.json` within each package. Scripts, executable files, undeclared files, and requested permissions fail checks and owner admission. There is no fixed release calendar: maintained packages are versioned when their content or compatibility changes. A breaking owner contract requires a new compatible maintained release before the product depends on it.
A named set groups admitted packages for one role and workflow step. In **Settings → Skills**, the Reviewer has **Reviewer inspection on request** selected as its manual set. Its saved and effective choices match, so future Reviewer sessions capture these two skills for manual invocation. The automatic selector remains at its configured default, which is empty in this example.
The screenshot's ordered manual members come from this excerpt under `trustedSkills.sets` in the owner configuration. Both member IDs must also be admitted in `trustedSkills.catalog`; defining a set makes it available, while selecting and saving it makes it effective for future sessions.
```yaml
- id:reviewer-inspection
name:Reviewer inspection on request
role:reviewer
step:review
invocationMode:manual
members:[code-review, c4-diff]
```
The two maintained defaults are original RelayView packages. Some optional guidance adapts earlier MIT-licensed skills; see the [third-party notices](NOTICE.md).
Clone this repository, copy `examples/starter-planner` to a new directory named for your skill, and edit its `SKILL.md` and `local-guidance.md`. Set the frontmatter `name` to the directory name and give it a distinct version. Keep `source.kind` as `user` and set `source.reference` to your fork's release identifier. Update each `files[].sha256` with the SHA-256 of the exact file bytes. Then run:
Replace `examples/starter-planner` in the last two commands with your package directory. The `pack` command writes a reproducible ZIP containing the package, `LICENSE`, and `NOTICE.md`, then prints its SHA-256. The check returns the owner's package identity digest. Both use only Python 3's standard library and this repository's source. Preserve the license and notice when redistributing the package or fork.
To use a user fork, place its closed package directory under the owner's configured trusted root and use Settings → Skills to import the relative `SKILL.md` path under a new unique ID. Import validates and records the package; it does not assign it. Add that ID to a role-compatible named set in the owner configuration and restart the owner to load the set. Then select the set for the matching role in Settings → Skills and save. That selection takes effect for future sessions immediately; existing sessions retain their captured bytes. The Settings catalog displays source, version, digest, role, step, and pending versus effective assignment. The owner's admission remains authoritative even when these local checks pass.
To use a maintained default, copy its release package under the same trusted root, admit its `SKILL.md` through the owner catalog, then select it for its declared role in Settings. Settings import accepts user-source packages; configure first-party packages in the owner catalog. Select a fork with `source.kind: user` and a distinct ID to replace that role's future assignment. Planner guidance uses existing read and planning tools; Implementer guidance uses existing implementation and reporting tools. Neither selection changes a role's tools, credentials, lifecycle stages, validation requirements, Gitea effects, review, merge, or Human acceptance. The owner keeps the existing Gitea task workflow.
A release tag pins public source. CI runs package checks and archives from that source. RelayView's bundled copy records the source tag and commit plus each package identity and file hash, then verifies the bytes in its own focused test. A bundled update creates a new release identity; it does not overwrite a user fork.
The MIT license covers this repository only. The contribution policy is in [CONTRIBUTING.md](CONTRIBUTING.md); dependency notices are in [NOTICE.md](NOTICE.md).
