config

Inspect, validate, change, and reload layered Shipyard configuration values with provenance.

1|1|Updated Jul 23, 2026
One-click install
npx skills add https://github.com/nearmap/shipyard --skill config-nearmap
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: config
Source: https://github.com/nearmap/shipyard/tree/main/skills/config
Command: npx skills add https://github.com/nearmap/shipyard --skill config-nearmap

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Shipyard behavior is controlled by a layered JSON configuration spread across user, repo, and local files, and it is hard to know which layer a value came from or why a change did not take effect. This Skill shows every resolved value with its source layer, validates the whole chain, and reloads settings mid-session without a restart. ## Core Features & Use Cases - Show resolved config with provenance: Reports the three layers (user, repo, local), which exist, and where each value resolves from, including derived defaults computed from the repo. - Validate and diagnose failures: Names every configuration error with its key and layer, covering unset required keys, retired SY_* environment variables, model floor refusals, and CLAUDE_CODE_SUBAGENT_MODEL conflicts. - Set values at the right scope: Guides direct JSON edits to the correct layer file (user, repo, or gitignored local), then validates and confirms the change landed. - Reload mid-session: Re-resolves the layer chain so edits apply to the next dispatch, while refusing to silently absorb config changes during an active /sy:ship run. - Use Case: You changed a model tier but agents still run the old model. Run the config skill to see the value is overridden by the gitignored local layer, fix the right file, and reload so the next dispatch picks it up. ## Quick Start Ask the AI to show the current Shipyard configuration and explain which layer each resolved value comes from.

Frequently Asked Questions about config

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I see where a Shipyard config value comes from?▼

Run the config skill's show command, which reports every resolved value alongside the layer it came from: user, repo, local, or derived-default. It leads with which of the three layers exist, since most 'my change did nothing' issues are layer override problems.

Why did my Shipyard config change not take effect?▼

The value is likely overridden by a higher-precedence layer, such as the gitignored local layer overriding the committed repo layer. Use show to check provenance, then run reload_config so the resolver re-resolves from disk for the next dispatch.

Can I store API keys or secrets in the Shipyard config file?▼

No. The resolver refuses credential-shaped keys in both directions, and secrets must stay in the environment. Config files are greppable, and printing one would burn the secret into permanent transcript history.

What does a model floor refusal error mean in config validation?▼

A floor refusal means a config layer tried to set an agent below the minimum model defined in the plugin-shipped floors.json. The fix is to accept the floor, not edit the floors file, which is deliberately not locally negotiable.

Does reloading config change a running agent's model or effort?▼

No. Workers already dispatched keep what they were given; the reload boundary is the next dispatch. During /sy:ship, a changed config fingerprint stops the run rather than silently continuing on changed settings.