agentsclimarketplace

Statewright

Skill knowledgeco/airworthiness/skills/statewright

Fidelity and granularity controls for AI coding agents — the judgment a seasoned engineering team would apply, made explicit. Execution control + surface control. Model-agnostic. MIT.

Install
npx -y skills add knowledgeco/airworthiness --skill statewright

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • 27 days oldThe repository was created 27 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Design, implement, and audit workflows across their relevant real states, including missing, empty, loading, partial, stale, offline, failed, interrupted, recovery, and success behavior. Use when implementing a workflow, declaring a component complete, moving a demonstration toward production, reviewing errors, adding asynchronous or offline behavior, preparing state fixtures or tests, or auditing product completeness, accessibility, and responsive recovery.

SKILL.md

4.4 KB, as published. Nobody here has run it

Statewright

Judge product completeness across the real state space, not only the ideal populated demonstration.

Govern the failure seam

Prevent a happy-path implementation from being called complete while failure destroys input, stale data looks current, empty and failed data look identical, recovery disappears on narrow screens, or assistive technology cannot perceive the state change.

Use this completion rule:

A workflow is complete only when its relevant states are designed, recoverable where recovery is possible, accessible, responsive, and connected to implementation evidence.

Work in this order

  1. Discover local authority. Read the workflow contract, current implementation, surface and voice rules, tests, stories, and any existing state inventory. Preserve the repository's format. If none exists, use state-matrix-format.md. When the Airworthiness repository assets are available, validate the portable form with its shared schema; a skill-only install still retains the complete behavioral format without claiming schema validation.
  2. Define the workflow boundary. Name the user goal and success condition before enumerating states. Split workflows when one manifest would hide materially different recovery or data-safety rules.
  3. Select relevant states. Include every condition that changes visible status, available actions, data trust, or recovery. Consider first run, empty, loading, partial, stale, syncing, offline, degraded, denied, expired, validation, recoverable and terminal failure, interruption, conflict, success, undo, and resumed work. Do not fill an irrelevant checklist; mark an expected-but-inapplicable state with a reason.
  4. Write the state matrix. For each applicable state, capture trigger, visible condition, data preserved, actions, blocked actions, recovery, implementation status, evidence, copy source, human-verdict status, accessibility, and responsive transformation. Use state-matrix-format.md.
  5. Protect data and recovery. Preserve user input after recoverable failure, distinguish no data from failed data, expose stale and offline status, and provide an actionable recovery path whenever recovery exists. Follow workflow-state-protocol.md.
  6. Make access and narrow-screen behavior real. Specify focus, announcements, keyboard reachability, reduced motion, non-color signaling, contrast, transformation, and the location of recovery actions. Follow responsive-and-accessible-states.md.
  7. Connect evidence. Bind states to the repository's acceptance tests, component stories, visual fixtures, integration tests, or manual worksheets. Record only observed evidence; not_run is a valid fact, not a passing result.
  8. Audit the completion claim. Treat every required state that is missing, partial, planned, unknown, or unsupported by required evidence as a blocker. Keep the overall status incomplete or unknown until resolved.

Hold these boundaries

  • Do not fabricate skeleton content that could be mistaken for real data.
  • Do not hide unsupported or destructive actions until after the user attempts them.
  • Do not call an error recoverable without a concrete recovery action.
  • Do not remove recovery, status, or preserved input merely to fit a narrow screen.
  • Do not treat a machine proposal or self-review as an operator's perceptual verdict; leave human verdicts pending.
  • Do not require a particular framework, component library, test runner, model, or companion skill.

Compose optionally

Use this skill alone for state completeness. It may also consume a local surface constitution or voice inventory, emit state-specific genealogy residue, and provide fixtures to an independent audit. These inputs improve continuity but are not prerequisites; local product behavior remains authoritative.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.