seaworthy
Skill2 starsChanged 31 days agoApache-2.0View on GitHub
Harden a selected frontend journey across async states, recovery, accessibility, and performance constraints. Use for implementation readiness, not a universal visual-style audit.
In this repository37 other files it gives its agents.
- canonSkill
- colorSkill
- formSkill
- graphicsSkill
- layoutSkill
- motionSkill
- pilotSkill
- systemsSkill
- typeSkill
- holdfastSkill
- aegisSkill
- assaySkill
- flightlineSkill
- gaugeSkill
- groundworkSkill
- gungnirSkill
- husbandrySkill
- load-bearingSkill
- pilotSkill
- plumbSkill
- stationkeepingSkill
- crucibleSkill
- envoySkill
- forgeSkill
- ledgerSkill
- prospectSkill
- reckoningSkill
- forageSkill
- touchstoneSkill
- bearingsSkill
- bulwarkSkill
- keelSkill
- liverySkill
- lookoutSkill
- pilotSkill
- trialsSkill
- wellspringSkill
The file
We split this skill into the rules it gives an agent
4 rules. About 0 are common, 1 is distinctive, and 3 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 41
When this stage is fulfilled: checklist advance states --run "$RUN".
- Distinctive: line 71
Not every product needs offline operation or optimistic updates.
- Very specific: line 73
If an input or permission is missing, name the blocker and leave the relevant item pending.
- Very specific: line 79
After all required work and stage closures is recorded, use checklist done --run "$RUN".
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
<!--
Copyright 2026 IamK77 — Licensed under the Apache License, Version 2.0.
See ./LICENSE and ./NOTICE · https://www.apache.org/licenses/LICENSE-2.0
-->seaworthy
Harden a selected frontend journey across async states, recovery, accessibility, and performance constraints. Use for implementation readiness, not a universal visual-style audit.
Inputs
Existing journey; target users/devices; important failure modes; agreed accessibility and performance requirements.
Run record
Use checklist 0.5 or newer for this SOP. Reading or reloading the skill must not reset work. For a new task, run checklist init "${CLAUDE_SKILL_DIR}" --new --path "/absolute/project"; retain its returned ID as RUN. For existing work, use checklist resume "$RUN", then checklist show --run "$RUN". Outside Claude, replace the skill-directory variable with this directory’s actual path.
Commands below record work after it is done. Replace evidence placeholders with concise artifact locations and observations. Manual confirmations are not independent proof; a sensor pass covers only the command and inputs it observed. verify does not close a stage; advance checks that its required readings are fulfilled. Use report --run "$RUN" for the retained history.
Procedure
states
Map loading, empty, success, error, retry, and cancellation where applicable. Define what the user should perceive and retain when requests fail or arrive out of order.
Record these artifacts after doing the work:
- Relevant async and failure states have expected visible outcomes.
checklist check states states --run "$RUN" --evidence "<artifact and observation>" - Supported input modes, devices, and performance requirements are explicit.
checklist check states constraints --run "$RUN" --evidence "<artifact and observation>"
When this stage is fulfilled: checklist advance states --run "$RUN".
harden
Implement the missing state and recovery behaviours. Exercise keyboard/focus paths and semantic accessibility; test race cases and slow/failing requests. Measure relevant performance on a representative path.
Record these artifacts after doing the work:
- State transitions and recovery paths were exercised.
checklist check harden behaviour --run "$RUN" --evidence "<artifact and observation>" - Keyboard, semantic accessibility, and relevant performance checks are recorded.
checklist check harden access --run "$RUN" --evidence "<artifact and observation>"
When this stage is fulfilled: checklist advance harden --run "$RUN".
handoff
Retain regression coverage for the risky paths and document any unsupported conditions or measured limits. Report exactly which accessibility checks ran, not blanket compliance.
Record these artifacts after doing the work:
- Risky interaction and failure paths have retained tests.
checklist check handoff regressions --run "$RUN" --evidence "<artifact and observation>" - Measured results and unsupported or unverified conditions are explicit.
checklist check handoff limits --run "$RUN" --evidence "<artifact and observation>"
When this stage is fulfilled: checklist advance handoff --run "$RUN".
Branches
Not every product needs offline operation or optimistic updates; define the actual behaviour instead of adding features to satisfy a list. Use applicable accessibility requirements, not a generic claim about legal compliance.
If an input or permission is missing, name the blocker and leave the relevant item pending. A changed requirement may need a new run; an accepted checklist edit uses resume "$RUN" --refresh and requires fresh readings. To abandon work, use checklist reset --run "$RUN" --reason "<reason>"; history is retained.
Completion
A more robust journey with reproducible checks and named gaps. Trials can deepen behavioural coverage.
After all required work and stage closures is recorded, use checklist done --run "$RUN". This archives the result without deleting its history; it does not authorise any external action.
Reference shelf
Open the technique relevant to the current step. These notes provide concrete methods and examples, not additional phases; this entrypoint defines the run's completion conditions.
- Check the selected journey under its actual constraints
- Follow meaning and interaction beyond appearance
- Preserve user intent across form and connectivity states
- Model the states that matter to the actual task
- Make asynchronous behaviour match the promise
- Robustness around a selected journey
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

