cli-forge Description

Use this stage when the workflow needs one authoritative description contract for a generated Rust CLI Skill before later stages proceed.

When To Use This Stage

• Intake classified the work as a new generated skill.
• The requested change alters the generated skill's purpose, positioning, or user-facing contract.
• A later stage detects drift between Cargo metadata, SKILL.md, README, help text, release-facing summaries, or clone-first install guidance.

Stage Goal

Finish this stage with one approved description contract that downstream stages must reuse instead of inventing new summaries independently.

Canonical References

• ./instructions/new.md
• ./instructions/add-feature.md
• ./planning-brief.md

Read the instruction files as the detailed source of truth for how the description contract is consumed during scaffold or feature work.

Required Inputs

• classified workflow intent from intake
• current or proposed generated skill scope
• any existing description surfaces that must stay aligned
• the target next stage:
  • scaffold for new skills
  • extend for existing skills whose public contract changes
  • validate when only verification is needed after description alignment
  • publish only for final summaries after validation is current

Description Contract Outputs

• approved one-line purpose summary
• approved positioning statement
• inventory of description surfaces that must reuse the same contract
• channel-aware release summary guidance so repo-native release stays primary and any optional npm publication remains an explicit secondary CLI-only path
• explicit next-stage handoff and done criteria

Workflow

1. Confirm whether the work creates a new generated skill or changes the user-facing contract of an existing one.
2. Define or refresh the approved purpose summary and positioning statement.
3. Record which downstream surfaces must stay synchronized:
   • Cargo.toml package description
   • SKILL.md
   • README.md
   • help text / structured help summaries
   • packaging or publish-facing summaries
   • repo-native release/install guidance when publish support is in scope
   • optional npm publication guidance when the repository will expose that secondary CLI distribution path
4. Confirm the next stage that is allowed to consume the approved description contract.
5. Hand the approved contract forward without letting downstream stages invent competing wording.

Guardrails

• description is the authoritative stage for user-facing purpose and positioning.
• scaffold, extend, validate, and publish consume the approved contract; they do not redefine it.
• publish may summarize the contract for release readiness, but it must not overwrite the approved description surfaces.
• When publish support is later adopted, repo-native GitHub Release and install-helper wording must reuse the approved summary instead of inventing a different product description.
• If optional npm publication is later adopted, its coordinating-package and platform-package guidance must reuse the same approved description contract without presenting npm as the default release channel.

Done Condition

This stage is complete only when every required description surface is named, the approved summary and positioning are ready for reuse, and the next stage is explicit.

Next Step

• Continue with ../cli-forge-scaffold/SKILL.md for new generated skills.
• Continue with ../cli-forge-extend/SKILL.md when an existing skill's public contract changes alongside feature work.
• Continue with ../cli-forge-validate/SKILL.md when description alignment is ready for verification.
• Continue with ../cli-forge-publish/SKILL.md only after validation is current and the workflow needs final closure.