[Idea] Port Trailmark to Codex / Cursor / other agents

[bearded-illirian]

The problem or opportunity

Trailmark currently runs on Claude Code only. All 19 skills use
Claude-specific
primitives: Skill('name') invocations, .claude/skills/ conventions,
SKILL.md frontmatter, /go-fast slash-commands, PostToolUse hooks.

The concept — artifact-first, skill chain, plan-first → execute → report loop
—
is universal. But developers on Codex, Cursor, Continue, or other AI coding
agents can't use Trailmark today without significant porting effort.

Question: is there enough demand across other platforms to justify building
the port?

Rough proposal

Port skills catalog + tooling to alternate platforms in priority order based
on community signals:

1. Add [YourAgent] port label to this discussion — comment with which agent
   you're on and one sentence about your use case
2. If a specific platform hits 10+ signals, prioritise porting Trailmark's
   skill catalog to that platform's native invocation format
3. Add [YourAgent] port label to this discussion — comment with which agent
   you're on and one sentence about your use case
4. If a specific platform hits 10+ signals, prioritise porting Trailmark's
   skill catalog to that platform's native invocation format
5. Keep bin/ scripts, routing.db, and Flow UI as agent-agnostic data layer

What "port" means concretely: rewrite SKILL.md files into the target agent's
prompt format, adapt slash-commands, replace hooks with target's mechanism,
preserve artifact-first philosophy end-to-end.

Who benefits and how

• Codex users — official OpenAI coding agent, growing base, currently
  no equivalent artifact-first framework

  • Cursor users — mature editor-embedded agent with rules system that
    could host adapted Trailmark skills
  • Continue users — VSCode/JetBrains extension, similar surface to Claude
    Code
  • Multi-agent teams — some devs switch between agents, need consistent
    discipline layer regardless of runtime

  Workflow: same artifact-first pattern (every step writes a file, block closes
  with report) but on their chosen agent, without needing to reinvent skills.

Risks or downsides

• Maintenance overhead — each platform port doubles skill catalog surface
  to keep in sync when core protocols evolve
• Feature drift — different agents have different capabilities; not every
  skill maps 1:1 (e.g., dev-auto-first validation loop needs equivalent
  primitive on target agent)
• Fragmented community — three separate skill catalogs could split
  contributor attention
• Prioritisation risk — if signals stay under 10 per platform, the port
  never happens and readers feel forgotten. Mitigation: leave issue open with
  transparent counter, no false promises

[ofekron]

[Codex port] I use Codex and Claude Code against the same repositories, and the use case is keeping one artifact-first plan → execute → report discipline while choosing the native agent per task.

There is enough value to justify a Codex port, but I would avoid rewriting 19 independent skill bodies. Keep one canonical skill contract and manifest, separate the universal protocol from provider capabilities, and generate thin adapters for discovery paths, invocation syntax, and hooks. Treat PostToolUse as an optional capability: when a provider has no equivalent, route the same invariant through an explicit end-of-step verifier. A shared fixture suite should assert that each adapter produces the same artifacts and handoff state; that is what prevents feature drift.

I maintain Better Agent, a local web workspace that supervises native Claude, Codex, and Gemini sessions: https://github.com/ofekron/better-agent. I am sharing it because its provider adapters and parity requirement are a concrete implementation reference for this exact boundary, not as a replacement for Trailmark. It is source-available and free for non-commercial use; commercial use requires separate permission.

AI-assistance disclosure: this comment was drafted by Codex under the maintainer's authorization and reviewed in Better Agent.

[bearded-illirian]

Thanks — this is a strong architectural read. Canonical contract + thin per-provider adapters + shared fixture suite for parity is exactly how I'd want a port to look.

The PostToolUse-as-optional-capability framing (with an explicit end-of-step verifier fallback) is the piece I hadn't thought about — it simplifies the port surface a lot.

Trailmark v1.0-mvp launches tomorrow (2026-07-21). This week is stabilization; multi-provider port fits naturally as a v1.1+ direction. I'll write a detailed technical reply post-launch — specifically want to dig into which 2-3 skills to port first, what the fixture suite looks like in practice, and whether adapters belong in-repo or sibling.

Thanks also for the Better Agent reference — useful implementation seam.

AI-assistance disclosure: this reply was drafted by Claude (Anthropic) under my authorization and reviewed before posting.

— @bearded-illirian

[socialink]

Codex port please

[bearded-illirian]

Noted — Codex port is on the v1.1+ roadmap. Adding your voice to the request.

Detailed technical reply on the port architecture coming this week — will cover @ofekron's proposal above (canonical contract + thin per-provider adapters + shared fixture suite for parity).

[GarkushaYaroslav]

would like to see a codex port

[bearded-illirian]

Third +1 for Codex port (thanks @GarkushaYaroslav, @socialink) — that's a pattern, not noise. Multi-provider port is now a confirmed v1.1+ priority, not just a "considered" item.

Detailed technical reply on the port architecture (per @ofekron's proposal above — canonical contract + thin per-provider adapters + shared fixture suite) coming this week. Will cover which 2-3 skills to port first, fixture suite shape, and adapter placement (in-repo vs sibling).

If anyone reading has specific pain points with their Codex/Cursor workflow that the port should solve — drop them below, that will shape the priority order.