Skip to content

Consider renaming the project (outgrown 'ost-tools') #55

@mindsocket

Description

@mindsocket

Background

The project has outgrown its name. "ost-tools" implied a narrow focus on Opportunity Solution Trees specifically, but the tooling now supports general context tree / strategy framework modeling across arbitrary schemas. The name is a misnomer and may limit discoverability and positioning.

This issue tracks the question of what to rename it to.

Why now

Working through the implications of John Cutler's framing of "context trees" as a distinct category of organizational entity (see #48), it became clear that this project has a precise and useful identity: infrastructure for building and validating context trees — the durable structures through which individuals and organizations map their opportunity landscape, strategy, and domain.

"ost-tools" doesn't communicate that. A rename would help the project better describe itself.

Options to explore

context-tree-tools

Directly adopts Cutler's third-category framing. Precise and accurate for the current scope.

  • Pro: clear, descriptive, aligns with emerging vocabulary in the product strategy space
  • Pro: "context tree" as a term is specific enough to select the right audience without being impenetrable
  • Con: "tree" may not age well if the data model moves further toward graphs/networks (the tool already models DAGs, not strict trees)
  • Con: three-word names are a bit long for a CLI tool

context-graph-tools / cxt

Acknowledges the graph/DAG reality more honestly.

  • Pro: technically more accurate
  • Con: "graph" is more technical and less relatable to the product/strategy audience

context-tools

Shorter, but loses precision — "context" alone is very broad.

Something else entirely

The project could move away from describing the data shape (tree/graph) and lean into the use case: strategy modeling, framework tooling, or similar. Open for suggestions.

Considerations

  • The rename touches: repo name, npm package name, CLI binary name, env vars (OST_TOOLS_CONFIG), docs, schemas ($schema URLs), and any downstream configs
  • Since this is pre-1.0 and no backward compatibility is required, a clean cut is fine
  • Related: any private extension repos should probably follow the same naming convention

Relates to

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions