Sb Configure

Configure SpecBind for this project

Apply project language style

Before authoring any artifact or user-facing prose, read:

specbind rule read language-style --for consume

Apply returned policy only to natural-language prose. NO_CHANGE RULE_ABSENT means no additional project preference; any ERROR line stops the workflow.

Own the whole configuration run. Translate the maintainer's outcome into the supported configuration surface, use the owning CLI command or product Skill, validate the result, and finish authorized aftercare. Delegating one step does not delegate this responsibility.

1. Read the mechanical summary

Start every run with:

specbind configuration show

Any ERROR stops configuration until its named surface is repaired. The summary reports mechanically provable state, not whether the project's choices are good. Inspect only the repository evidence needed to make that judgment.

2. Classify the request and load only its procedure

Read every directly applicable reference completely before proposing or making that part of the change. Do not load unrelated procedures.

• Agent selection, language, project instructions, or role capability: installation and Agents
• Artifact, Steering, or Roadmap template; Design-template selection; or existing-artifact alignment: templates and reconciliation
• Shared authoring or judgment policy: Rules
• Release, Git, deferred-finding, or final implementation-validation procedure: adapters
• Durable project knowledge: Steering
• Explicit SpecBind binary update, mise-selected version change, or update-coupled product-asset refresh: update
• Pending or resumed description migration after an update: description reconciliation

Read aftercare after every mutation and before reporting completion.

When one request spans several surfaces, state the dependency order and complete one coherent surface at a time. Re-read configuration show after each change that affects the inputs of the next.

Recommended starting order for project shaping

For an initial post-install review, or when a template decision depends on unknown project-wide characteristics, recommend this order:

1. Establish or synchronize durable Steering through sb-steering.
2. Compare that Steering and repository facts with the current Requirements and Design templates and their shared Rules.
3. Update an existing template or Rule when the responsibility and its structure are common to its current scope. Add a Design template only when a distinct responsibility needs its own recurring design decisions and traceability across multiple Specs.

An empty Steering collection is valid. Do not bootstrap it merely because it is empty, and do not delay an explicit, narrow template edit that does not depend on missing project guidance. When Steering is needed, ask whether bootstrap, synchronization, or an addition is intended; sb-steering owns that choice.

Technology labels alone are not a template boundary. For example, Web or mobile work first uses the existing UI candidate when user-visible behavior changes; API or infrastructure conventions usually belong in Steering and Design or Contract Rules first. A platform-specific Design candidate is justified only when its independent responsibility would otherwise be repeatedly obscured in the main Design. Steering records durable project facts; it does not replace the per-Spec applicability decision in design-template-selection.

When a request names a future technical category but Steering and repository facts do not establish that independent recurring responsibility, do not infer one. Explain the existing-template or Rule option and the conditional-candidate option, then ask which outcome is intended before changing the candidate set or its selection Rule.

3. Preserve ownership and authority

• Edit only project-owned configuration and durable knowledge through their accepted paths and owning workflows.
• Never edit installed product-managed Skills, generated Agent roles, protocols, schemas, root managed blocks, or CLI-owned lifecycle state by hand.
• A mutating configuration request follows the active Git adapter for its narrow eligible local checkpoint. The adapter alone grants no push, branch, tag, publication, removal, or history-rewrite authority.
• Configuration, existing-artifact reconciliation, lifecycle reapproval, Git operations beyond that eligible checkpoint, and external publication are separate authorization boundaries.
• Unsupported specDir movement, product-policy changes, semantic artifact changes, and lifecycle mutations route to their ordinary owning workflow. Never approximate them through file edits.

4. Propose and perform the change

Show the current state, intended state, exact owned surfaces, validation, and expected aftercare. Ask only when the request leaves a material choice or a separate authority boundary unresolved. A direct request to make an ordinary, reversible project-owned configuration edit authorizes that edit and its mechanical validation.

Use the applicable reference. When it routes to another product Skill, follow that Skill's current contract rather than copying or weakening it here. Resume this workflow after it finishes, inspect what actually changed, and continue through aftercare.

5. Verify and report

Run specbind configuration show again. Run every surface-specific read or check named by the applicable reference. Do not call a change complete because the file exists or a delegated Skill said it succeeded.

Report in the configured project language:

• what configuration changed;
• what verification passed;
• required aftercare completed;
• recommended or optional aftercare completed or declined; and
• remaining lifecycle or external-action boundaries.

Keep it concise. The files and CLI state are the evidence.