一键在 Manus 中运行任何 Skill

trails-derive-from-source

星标3

分支1

更新时间2026年5月20日 03:58

Use when a Trails change derives framework facts, projections, rule data, or surface metadata. Helps agents find authoritative owner exports and avoid shadow registries, duplicated maps, and canonical-source indirection.

安装

用 Codex 或 Claude 帮你安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。

在 Manus 中运行

来源

outfitter-dev

outfitter-dev/trails

打开 GitHub 仓库查看创作者相关仓库

下载

在 Manus 中运行

Trails Derive From Source

Use this skill when a proposal adds a table, projection, metadata map, generated artifact, or Warden rule that repeats framework facts.

Workflow

Name the fact being derived: error class, error category, intent, Result accessor, detour cap, rule metadata, surface projection, package entrypoint, or schema fact.
Find the natural owner module for that fact.
Check whether the owner already exports typed data the consumer can import.
If the owner does not export it, prefer adding a narrow owner export before creating a projection-local list.
Compare consumers against owner data and remove shadow copies when possible.
File a follow-up only when the owner boundary itself is missing or unclear.

Authoritative Sources

docs/adr/0037-owner-first-authority.md
docs/contributing/warden-rules.md
Owner modules in packages/core/src, packages/topographer/src, packages/warden/src/rules, or the package that owns the primitive.
Projection consumers in CLI, MCP, HTTP/Hono, Warden, docs generation, or topo artifact compile/validation paths.

Advisory Context

Scratch audit notes, issue bodies, and PR discussions may identify suspected shadow data, but the owner module and committed doctrine decide the source of truth.

Must Not

Do not add generic canonicalSource() APIs, TSDoc registries, or topo-resident canonical tables by default.
Do not make a consumer package the authority for framework-wide facts.
Do not duplicate owner facts into a Warden rule because importing the owner export feels inconvenient.
Do not treat intentionally local policy deny lists as owner projections unless another consumer needs the same data.

Output

Return:

The owner source.
Each projection or consumer checked.
Shadow data found or ruled out.
The smallest owner export needed, if any.
Whether the change should proceed, move to the owner package first, or become a follow-up issue.

同仓库更多 Skills

同仓库

clark

outfitter-dev/trails

Trails framework co-architect & CTO persona — constitutional hierarchy, drift guard, vocabulary enforcement, and architectural judgment. Use when evaluating Trails architecture, enforcing vocabulary, reviewing framework coherence, or when Clark's judgment is needed on a Trails question.

Build with the Trails framework — define trail contracts, open CLI/MCP surfaces, test with examples, debug errors, migrate codebases, run governance. Use when creating trails, adding surfaces, testing, debugging Trails errors, migrating to Trails, running warden, or any work involving @ontrails/* packages.

2026-06-253

trails-adrs

outfitter-dev/trails

Author, update, and manage Trails ADRs. Use when creating new ADRs, promoting drafts to accepted, updating the ADR index, renaming or renumbering ADRs, or when the user mentions ADR, architecture decision, or decision record.

2026-06-153

trails-editorial

outfitter-dev/trails

Complete Trails editorial review workflow. Use when reviewing docs, ADRs, README changes, release notes, agent guidance, or docs-heavy PRs for voice, style, structure, correctness, and readiness.

2026-06-153

trails-writing-docs

outfitter-dev/trails

Trails documentation structure and maintenance guidance. Use when creating or reorganizing Trails docs, READMEs, guides, reference pages, release docs, or agent-facing documentation.

2026-06-153

name	trails-derive-from-source
description	Use when a Trails change derives framework facts, projections, rule data, or surface metadata. Helps agents find authoritative owner exports and avoid shadow registries, duplicated maps, and canonical-source indirection.

Trails Derive From Source

Use this skill when a proposal adds a table, projection, metadata map, generated artifact, or Warden rule that repeats framework facts.

Workflow

Name the fact being derived: error class, error category, intent, Result accessor, detour cap, rule metadata, surface projection, package entrypoint, or schema fact.
Find the natural owner module for that fact.
Check whether the owner already exports typed data the consumer can import.
If the owner does not export it, prefer adding a narrow owner export before creating a projection-local list.
Compare consumers against owner data and remove shadow copies when possible.
File a follow-up only when the owner boundary itself is missing or unclear.

Authoritative Sources

docs/adr/0037-owner-first-authority.md
docs/contributing/warden-rules.md
Owner modules in packages/core/src, packages/topographer/src, packages/warden/src/rules, or the package that owns the primitive.
Projection consumers in CLI, MCP, HTTP/Hono, Warden, docs generation, or topo artifact compile/validation paths.

Advisory Context

Scratch audit notes, issue bodies, and PR discussions may identify suspected shadow data, but the owner module and committed doctrine decide the source of truth.

Must Not

Do not add generic canonicalSource() APIs, TSDoc registries, or topo-resident canonical tables by default.
Do not make a consumer package the authority for framework-wide facts.
Do not duplicate owner facts into a Warden rule because importing the owner export feels inconvenient.
Do not treat intentionally local policy deny lists as owner projections unless another consumer needs the same data.

Output

Return:

The owner source.
Each projection or consumer checked.
Shadow data found or ruled out.
The smallest owner export needed, if any.
Whether the change should proceed, move to the owner package first, or become a follow-up issue.