Project rename. ost-tools -> structured-context, and cli/plugin prefix is sctx

Author: mindsocket

.claude-plugin/marketplace.json

@@ -1,14 +1,14 @@
 {
-  "name": "ost-tools",
-  "description": "Plugins for working with structured Obsidian markdown content using ost-tools.",
+  "name": "structured-context",
+  "description": "Plugins for working with structured Obsidian markdown content using structured-context.",
   "owner": {
     "name": "Roger Barnes",
     "email": "roger@mindsocket.com.au"
   },
   "plugins": [
     {
-      "name": "ost-tools",
-      "source": "./plugin/ost-tools"
+      "name": "structured-context",
+      "source": "./plugin/structured-context"
     }
   ]
 }

.claude/skills/release/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: release
-description: Cut an npm release for the ost-tools project. Use when the user asks to cut a release, publish a new version, or run /release <major|minor|patch>.
+description: Cut an npm release for the structured-context project. Use when the user asks to cut a release, publish a new version, or run /release <major|minor|patch>.
 ---
 
 ## Task
@@ -22,7 +22,7 @@ Cut a **$ARGUMENTS** release (major, minor, or patch).
 
 4. Once the user confirms publish succeeded, verify it's live by running:
    ```
-   npm view ost-tools version
-   bunx ost-tools@latest --version
+   npm view structured-context version
+   bunx structured-context@latest --version
    ```
    The first confirms the registry has the new version. The second confirms the published package runs correctly. Report both results to the user.

AGENTS.md

@@ -1,11 +1,11 @@
-# OST Tools
+# Structured Context
 
 Tools for working with Opportunity Solution Tree structures and other product management and strategy frameworks
 
 ## Development
 
 Get a list of commands: `bun run src/index.ts --help`
-Space names (e.g. `personal`, `politics`) are resolved via a config file - `$OST_TOOLS_CONFIG`, `$XDG_CONFIG_HOME/ost-tools/config.json`, `--config <file>` param, or `./config.json`
+Space names (e.g. `personal`, `politics`) are resolved via a config file - `$SCTX_CONFIG`, `$XDG_CONFIG_HOME/structured-context/config.json`, `--config <file>` param, or `./config.json`
 
 ## Claude Code Plugin
 
@@ -15,7 +15,7 @@ A Claude Code plugin lives at `plugin/`. It includes skills, commands and hooks
 
 There are several places that need reviewing and updating with any new feature or change added:
 
-- README.md - documentation, also displayed with `ost-tools readme` command
+- README.md - documentation, also displayed with `sctx readme` command
 - AGENTS.md - this file
 - docs/* - includes architecture, concepts etc
 - plugin/* - skills, commands, hooks, and scripts; update any affected parts
@@ -29,9 +29,9 @@ Before starting new work, review [docs/concepts.md](docs/concepts.md) for canoni
 ## Key Files
 
 - config — JSON5 file with spaces registered
-- `schemas/` — Bundled default schema files (JSON5) using the ost-tools schema dialect and top-level `$metadata`. Files starting with `_` are "partials" (fragments for `$ref`).
+- `schemas/` — Bundled default schema files (JSON5) using the structured-context schema dialect and top-level `$metadata`. Files starting with `_` are "partials" (fragments for `$ref`).
 - `src/metadata-contract.ts` — Single source of truth for the `$metadata` contract
-- `schemas/generated/_ost_tools_schema_meta.json` — Generated metaschema (generated on build or with `bun run generate:schema-meta`)
+- `schemas/generated/_structured_context_schema_meta.json` — Generated metaschema (generated on build or with `bun run generate:schema-meta`)
 
 ## Testing
 For most development only the main unit tests need re-running regularly.

README.md

@@ -1,4 +1,4 @@
-# ost-tools
+# structured-context
 
 Tools for working with Opportunity Solution Tree structures and other product management and strategy frameworks
 
@@ -7,27 +7,27 @@ Tools for working with Opportunity Solution Tree structures and other product ma
 Requires [Bun](https://bun.sh) runtime.
 
 ```bash
-bun install -g ost-tools
+bun install -g structured-context
 ```
 
 Or use directly via `bunx`:
 
 ```bash
-bunx ost-tools validate <space>
+bunx structured-context validate <space>
 ```
 
 ## Setup for AI Agents
 
 A Claude Code plugin is included at `plugin/`. It provides validation hooks, slash commands, and agent skills. Install it with:
 
 ```
-claude plugin install mindsocket/ost-tools
+claude plugin install mindsocket/structured-context
 ```
 
 Skills can also be installed standalone without the plugin:
 
 ```
-npx skills add https://github.com/mindsocket/ost-tools/tree/main/plugin/skills/ost-tools
+npx skills add https://github.com/mindsocket/structured-context/tree/main/plugin/skills/structured-context
 ```
 
 ## Concepts
@@ -36,24 +36,24 @@ See [docs/concepts.md](docs/concepts.md) for the full terminology reference, inc
 
 ## Configuration
 
-`ost-tools` looks for its config file in this order:
+`structured-context` looks for its config file in this order:
 
-1. `$OST_TOOLS_CONFIG` — explicit path override
-2. `~/.config/ost-tools/config.json` (or `$XDG_CONFIG_HOME/ost-tools/config.json`)
+1. `$SCTX_CONFIG` — explicit path override
+2. `~/.config/structured-context/config.json` (or `$XDG_CONFIG_HOME/structured-context/config.json`)
 3. `./config.json` in the current working directory
 
 See `config.example.json` for the full structure. The config maps space names to paths, with optional Miro integration fields and global defaults. Paths in config files are resolved relative to the config file.
 
 **Including spaces from other configs:** Use `includeSpacesFrom` to import space definitions from other config files. This is useful for aggregating spaces from multiple projects into a central config, reducing the need to specify `--config` on CLI commands. Duplicate space names are not allowed.
 
-**Plugins and markdown plugin config:** See `ost-tools docs config` for the full reference including `fieldMap`, `typeInference`, `templateDir`, filter views, and plugin loading rules.
+**Plugins and markdown plugin config:** See `sctx docs config` for the full reference including `fieldMap`, `typeInference`, `templateDir`, filter views, and plugin loading rules.
 
 ### Spaces
 
 A space is a named directory or single file registered in the config. Spaces let you reference content by name instead of path:
 
 ```bash
-ost-tools validate ProductX
+sctx validate ProductX
 ```
 
 ### Schemas
@@ -62,7 +62,7 @@ Schemas define the structure and rules for the entities in a space, allowing cus
 
 Two schemas (`general` and `strict_ost`) are included. The general schema combines a basic vision/mission/goals hierarchy with a hierarchy loosely based on Opportunity Solution Trees. It is intentionally flexible to support rapid initial adoption. The strict OST schema has a narrower scope, and reflects Teresa Torres' specific recommendations for Opportunity Solution Trees more closely.
 
-ost-tools schemas use a metaschema based on JSON Schema Draft-07 that adds a top-level `$metadata` block:
+sctx schemas use a metaschema based on JSON Schema Draft-07 that adds a top-level `$metadata` block:
 
 ```json5
 "$metadata": {
@@ -148,7 +148,7 @@ Metadata is composable across `$ref` graphs:
 If no provider defines `hierarchy`, hierarchy-specific checks are skipped. Reading a `space_on_a_page` file still requires `hierarchy.levels`.
 
 **Customizing Schemas:**
-- **Partial schemas**: Files starting with an underscore (like `_ost_tools_base.json`) are loaded and used to resolve references (using `$ref`).
+- **Partial schemas**: Files starting with an underscore (like `_sctx_base.json`) are loaded and used to resolve references (using `$ref`).
 - **No-metadata partials**: If a partial has no `$metadata`, prefer `$schema: "http://json-schema.org/draft-07/schema#"` so it validates standalone as plain JSON Schema.
 - **Loading priority**: Partial schemas are loaded from both the default schema directory and the directory of your specified target schema.
 - **Transitive resolution**: `$ref` chains are resolved recursively across files/schemas (including nested `allOf` usage in partials).
@@ -165,7 +165,7 @@ The tool executes JSONata expressions defined in schema files for rule validatio
 ### Validate nodes
 
 ```bash
-ost-tools validate <space> [--watch]
+sctx validate <space> [--watch]
 ```
 
 Validates markdown files against the JSON schema:
@@ -176,7 +176,7 @@ Validates markdown files against the JSON schema:
 ### Show space tree
 
 ```bash
-ost-tools show <space> [--filter <view-or-expression>]
+sctx show <space> [--filter <view-or-expression>]
 ```
 
 Prints the space as an indented hierarchy tree. Hierarchy roots are listed first, followed by orphans (nodes in the hierarchy but with no resolved parent) and non-hierarchy nodes.
@@ -187,10 +187,10 @@ When a node appears under multiple parents (DAG hierarchy), it is printed in ful
 
 ```bash
 # Inline expression
-ost-tools show <space> --filter "WHERE resolvedType='solution' and status='active'"
+sctx show <space> --filter "WHERE resolvedType='solution' and status='active'"
 
 # Named view from config
-ost-tools show <space> --filter active-solutions
+sctx show <space> --filter active-solutions
 ```
 
 See [Filter expressions](#filter-expressions) below for expression syntax.
@@ -261,7 +261,7 @@ SELECT relationships(assumption) WHERE resolvedType='opportunity'
 ### Generate Mermaid diagram
 
 ```bash
-ost-tools diagram <space> [--output path/to/output.mmd]
+sctx diagram <space> [--output path/to/output.mmd]
 ```
 
 Generates a Mermaid `graph TD` diagram from validated space nodes:
@@ -273,7 +273,7 @@ Generates a Mermaid `graph TD` diagram from validated space nodes:
 ### Show schema ERD
 
 ```bash
-ost-tools schemas show <schema-file> [--mermaid-erd] [--space <name>]
+sctx schemas show <schema-file> [--mermaid-erd] [--space <name>]
 ```
 
 Generates a Mermaid Entity Relationship Diagram from a schema:
@@ -283,13 +283,13 @@ Generates a Mermaid Entity Relationship Diagram from a schema:
 
 Example:
 ```bash
-ost-tools schemas show general --mermaid-erd
+sctx schemas show general --mermaid-erd
 ```
 
 ### Sync space to Miro
 
 ```bash
-ost-tools miro-sync <space> [--new-frame <title>] [--dry-run] [--verbose]
+sctx miro-sync <space> [--new-frame <title>] [--dry-run] [--verbose]
 ```
 
 Syncs space nodes to a Miro board as cards with connectors. Requires `MIRO_TOKEN` env var and `miroBoardId` set in the space's config entry.
@@ -305,7 +305,7 @@ Sync is one-way (OST → Miro) and scoped to a single frame. Only cards and conn
 ### Sync templates with schema
 
 ```bash
-ost-tools template-sync <space> [--create-missing] [--dry-run]
+sctx template-sync <space> [--create-missing] [--dry-run]
 ```
 
 Keeps Obsidian template files in sync with schema examples:
@@ -332,7 +332,7 @@ bun run test:smoke
 # Build compiled output
 bun run build
 
-# Link built package locally so `bunx ost-tools` picks up changes
+# Link built package locally so `bunx structured-context` picks up changes
 bun link
 ```
 

docs/architecture.md

@@ -1,6 +1,6 @@
-# OST Tools: Architecture
+# Structured Context: Architecture
 
-This document describes the architecture of ost-tools — how data flows through the system, and how key concepts map to code. It complements [concepts.md](concepts.md), which defines the canonical terminology.
+This document describes the architecture of structured-context — how data flows through the system, and how key concepts map to code. It complements [concepts.md](concepts.md), which defines the canonical terminology.
 
 ---
 

docs/concepts.md

@@ -1,4 +1,4 @@
-# OST Tools: Concepts and Terminology
+# Structured Context: Concepts and Terminology
 
 This document is the canonical reference for concepts and terminology used in this project. It focuses on the meta-concepts the project supports, not the content of specific frameworks modelled in schemas. Before naming things in code, tests, comments, or documentation, check definitions here for consistency, and update them here when the project's "world view" changes, avoiding blurry terms as much as possible.
 
@@ -353,7 +353,7 @@ Views are defined in the space config under the `views` key:
 }
 ```
 
-Use a view by name with `ost-tools show <space> --filter <view-name>`. If no matching view name is found in the config, the value is treated as an inline filter expression.
+Use a view by name with `sctx show <space> --filter <view-name>`. If no matching view name is found in the config, the value is treated as an inline filter expression.
 
 ---
 
@@ -374,10 +374,10 @@ A **plugin** is a module that extends the tool's capabilities.
 
 Plugins that support parsing produce raw `SpaceNode[]` results given a suitable configuration. Graph edge resolution (`resolveGraphEdges`) is called by the core afterwards.
 
-The `plugins` field in config is a **map** from plugin name to plugin config object. All plugin names must start with `ost-tools-`, but the prefix is optional in config and normalised on load. Built-in plugins take precedence and all are loaded by default. External plugin names specified in config are then resolved in order:
+The `plugins` field in config is a **map** from plugin name to plugin config object. All plugin names must start with `sctx-`, but the prefix is optional in config and normalised on load. Built-in plugins take precedence and all are loaded by default. External plugin names specified in config are then resolved in order:
 
-1. Config-adjacent: `{configDir}/plugins/{ost-tools-name}`
-2. npm: a package matching `ost-tools-*`
+1. Config-adjacent: `{configDir}/plugins/{sctx-name}`
+2. npm: a package matching `sctx-*`
 
 Each plugin declares a `configSchema` JSON Schema; the loader validates the config block against it before invoking the plugin. Config fields annotated with `format: 'path'` are resolved relative to `configDir` by the loader.
 

docs/config.md

@@ -1,11 +1,11 @@
-# ost-tools Configuration Reference
+# structured-context Configuration Reference
 
 ## Config file location
 
-ost-tools looks for its config file in this order:
+structured-context looks for its config file in this order:
 
-1. `$OST_TOOLS_CONFIG` — explicit path override
-2. `~/.config/ost-tools/config.json` (or `$XDG_CONFIG_HOME/ost-tools/config.json`)
+1. `$SCTX_CONFIG` — explicit path override
+2. `~/.config/structured-context/config.json` (or `$XDG_CONFIG_HOME/structured-context/config.json`)
 3. `./config.json` in the current working directory
 
 See `config.example.json` for the full structure. Paths in config files are resolved relative to the config file.
@@ -44,12 +44,12 @@ Use `plugins` to load parse plugins that read spaces from non-markdown sources.
     }
   ],
   "plugins": {
-    "ost-tools-confluence": { "baseUrl": "https://example.atlassian.net" }
+    "sctx-confluence": { "baseUrl": "https://example.atlassian.net" }
   }
 }
 ```
 
-All plugin names must start with `ost-tools-` (the prefix is optional in config and normalised on load). The special name `markdown` refers to the built-in markdown plugin. External plugins are resolved in order: config-adjacent (`{configDir}/plugins/{name}`), then npm. Each plugin must export a `configSchema` JSON Schema; config is validated against it on load. Fields annotated `format: 'path'` in a plugin's `configSchema` are resolved relative to the config file directory.
+All plugin names must start with `sctx-` (the prefix is optional in config and normalised on load). The special name `markdown` refers to the built-in markdown plugin. External plugins are resolved in order: config-adjacent (`{configDir}/plugins/{name}`), then npm. Each plugin must export a `configSchema` JSON Schema; config is validated against it on load. Fields annotated `format: 'path'` in a plugin's `configSchema` are resolved relative to the config file directory.
 
 ## Markdown plugin config
 
@@ -129,9 +129,9 @@ Named filter expressions can be defined per space under `views`. Each view has a
 }
 ```
 
-Use a view name with `ost-tools show <space> --filter <view-name>`.
+Use a view name with `sctx show <space> --filter <view-name>`.
 
-See `ost-tools docs concepts` for full filter expression syntax.
+See `sctx docs concepts` for full filter expression syntax.
 
 ## Security notice
 

docs/rules.md

@@ -83,8 +83,8 @@ Example:
 
 ```json5
 "rules": [
-  { "$ref": "ost-tools://rule-pack#/$defs/workflowRule" },
-  { "$ref": "ost-tools://rule-pack#/$defs/coreRuleSet" }
+  { "$ref": "sctx://rule-pack#/$defs/workflowRule" },
+  { "$ref": "sctx://rule-pack#/$defs/coreRuleSet" }
 ]
 ```