Who maintains a skill
Donor Nexus owns its Claude skill instructions. An organization owner publishes reviewed versions of the separate private Skippy plugin repository. A skill can use existing Skippy read-only registry tools; a new source, action, schedule or custom tool is a separate engineering change.
This is the working-session checklist. Publication and staff installation must be verified separately. Staff setup and the user manual cover daily use.
1. Make one small change
In the private Donor Nexus plugin repository, select the relevant plugins/skippy/skills/<skill>/SKILL.md and its workflow.json or reference files. Read the existing source and acceptance notes before editing. For a first supervised exercise, clarify one instruction or support sentence without changing business rules. Keep the source procedure and human decision points intact. Do not put case evidence, credentials, messages or completed paperwork in the repository.
Record what changed, why, the plugin version and which staff workflow is affected. Version and changelog changes accompany the reviewed release.
2. Use the existing data tools
In an authorized Claude seat, start with skippy-connection-check and its read-only Skippy:data_health result. For the specific skill, request only the existing tool it needs, such as a donor profile, matching search or document availability. Check the current tool description and source citation; a tool result is not permission to invent an uncited field or change a record. If the required source is absent, keep that step explicit rather than adding a hidden fallback.
The plugin repository documents the available skills and dependencies. The application repository defines the Seat Rail tools; ask the application maintainer to review any requested tool change.
3. Test before publishing
- Run the plugin repository's documented bundle validator, release scanner and manifest verify. Review changed binary assets independently; a hash check does not inspect their meaning.
- Use an authorized, adequately anonymized real record for an engineering trial. If none is available, record that gap; do not fabricate a donor example. Keep the input and output in approved private storage.
- Compare the skill's actual output with its current source instructions and review the affected external steps. A local generated file does not prove Box save, DocuSign draft, sending or a staff-seat result.
- Have a staff reviewer use an authorized real case in their own seat for practical acceptance.
4. Publish and confirm
- Review a pull request in the plugin repository with the source change, version bump, changelog, package checks and rollback version.
- After merge, an organization owner syncs the private plugin marketplace. Required installation and automatic synchronization are separate owner choices; do not assume either is enabled.
- Open a new staff Claude task, confirm the installed plugin version, run the read-only connection check and test the changed skill. Record the observed version and output. Repeat on the intended additional staff seat before wider rollout.
If the new version fails, stop wider rollout and restore the previous reviewed version through the marketplace's approved release route. Confirm the staff seat actually shows the prior version in a new task and that the affected workflow works again. Do not change connector authorization as a plugin rollback.
Working-session record
With Lucy or Kara, record the selected skill and instruction, reviewed change, source/tool used, package result, staff-seat version, actual output and rollback version. A walkthrough is complete only when the participant makes the change and verifies the installed result. If publication or access is blocked, name the owner and next step rather than marking the session accepted.