Skip to content

How did you handle two tools shipping different behaviour under one open format name? #187

Description

@olijboyd

More of a design question rather than a bug or a proposal, so I can move it if a maintainer would rather it went somewhere else.

We are drafting a manifest format called tome.yaml that sits one layer above AGENTS.md, in the sense that AGENTS.md is one instruction file for one tool while tome.yaml just declares a bundle of those files plus the formats to render the bundle into. So this is not a competing spec, it consumes AGENTS.md as one of the things a bundle can contain for greater composability. The manifest declares each render target by a format string, and we deliberately left that an open enum rather than a closed list, because the moment a new agent tool ships a new instruction file convention we do not want to be a bottleneck.

I need advice on dealing with two different renderers, or two different tools, both shipping under the same format name while quietly meaning different things by it. The AGENTS.md name itself has been picked up and interpreted by a lot of independent implementers, so this is a problem this community has already encountered.

So I'd appreciate hearing whether a divergent-semantics-under-one-name collision actually happened to you, when in the lifecycle it first bit, and what it cost to deal with after the fact, compared with what reserving or namespacing the name early would have cost.

The full request for comment with three other open questions is collected here: tomevault-io/companyos#1, and the spec is at https://tomevault.io/docs/tome-yaml.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions