The common questions, without the soft-focus version.

Both. It handles real server-delivery work while giving agents a stronger execution frame through context, contracts, and verification.

No. Some skills treat the argument as plain task text, but others use it as a mode switch or a structured input. That is why reading the skill contract matters.

Yes. ShipGlows maintains skill metadata for both discovery models: Codex starts from each skill name, description, and path, while Claude Code relies on description and optional when_to_use metadata with a 1536-character per-skill listing cap. ShipGlows treats the stricter shared budget as the rule: descriptions are front-loaded, audited, and kept within the roughly 2% or 8000-character Codex baseline. The current audit target is zero hard violations and zero warnings while keeping discovery text under the shared budget.

Codex skills documentation · Claude Code skills documentation

Add the ShipGlows marketplace source with `codex plugin marketplace add dianedef/ShipGlows --ref main --sparse .agents/plugins --sparse plugins/shipglows`, restart Codex, open the plugin directory, install `shipglows` from the ShipGlows marketplace, then start with `$shipglows help me choose the right workflow`.

A skill mode is a specialized workflow triggered by a specific argument pattern or keyword. For example, a docs skill may switch into metadata migration mode instead of normal documentation-writing mode.

Use sf-browser for one narrow non-auth browser check: visible state, layout, screenshot, console, or network evidence. Use sf-auth-debug for login, OAuth, cookies, sessions, callbacks, tenants, providers, or protected routes. Use sf-test for guided manual QA, checklist-first manual proof, and durable test or bug records. Use sf-prod first when the deployment URL, runtime logs, or live deploy state are still uncertain.

sf-browser · sf-auth-debug · sf-test · sf-prod

Because stronger prompting does not remove weak handoffs, stale docs, ambiguous task framing, or drift between product intent and implementation.

No. ShipGlows is designed to choose the smallest professional path, not the shortest fragile path. Speed, cost, and convenience only decide when the options are already equivalent on correctness, security, maintainability, relevant performance, and proof.

No. The framework still helps on smaller work. But the more expensive or ambiguous the work becomes, the more the context layer and decision contracts start to pay off.

No. ShipGlows targets explicit active artifacts, not every Markdown file in a repo. Some files can be officialized later, but that should be a conscious doctrine decision.

No. sf-migrate is for framework or dependency upgrades. Metadata and frontmatter migration belongs to the documentation workflow instead.

Open the spec. For spec-first work, the spec carries Skill Run History and Current Chantier Flow, including the lifecycle skills that ran, their result, and the next command.

Usually yes. A direct fix can stay fast, but if it changes real behavior it should create or reuse a BUG-ID, keep a compact shipglows_data/workflow/BUGS.md pointer, and record the detail in shipglows_data/workflow/bugs/BUG-ID.md. Only narrow copy-only, cosmetic-only, or duplicate cases should skip that, and the exception has to be stated.

No. Those files stay operational trackers. The durable per-chantier flow belongs in the relevant spec so the workstream can be understood without reading chat history.