원클릭으로 Manus에서 모든 스킬 실행

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 저장소 열기 Creator 저장소 보기

다운로드

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.