Public-ready repository skill

Locator-boundary stewardship

Produces locator-safe public collaboration records while exact gated lineage remains recoverable through stable semantic keys and an authorized resolver. Applies when Issues, pull requests, Threadkeeping, handoffs, or public-history preparation cross publication boundaries.

Source and version

Repository path
.agents/skills/locator-boundary-stewardship/SKILL.md
Source revision
341bceb719a28be760775b6322021d78abaa919b
Source SHA-256
9a71f2512756ddb1163ef1694effa5ec5b159783b8b8cf46e7aa166884f10723
Publication standing
Public ready

Included source files

Complete skill source

The Markdown below matches the exact source text. The format link above opens the file on its own.

---
name: locator-boundary-stewardship
description: Produces locator-safe public collaboration records while exact gated lineage remains recoverable through stable semantic keys and an authorized resolver. Applies when Issues, pull requests, Threadkeeping, handoffs, or public-history preparation cross publication boundaries.
---

# Locator-boundary stewardship

## Contract

- **What:** A publication-boundary projection that keeps collaboration meaning complete in a public record while exact gated coordinates remain recoverable through an authorized resolver.
- **When:** A durable Issue, pull request, review, comment, commit message, Threadkeeping record, handoff, or public-history packet carries locators whose retrieval standing differs from the receiving surface.
- **Boundaries:** Current user intent, source standing, repository evidence, and granted tool authority govern every placement decision. The skill's scope is record placement. Privacy assurance, publication choice, history operations, and permission changes retain their separate owners. Exact gated coordinates stay within their authorized resolver.
- **Result:** A locator-safe public record with semantic receivers, stable source keys where needed, complete rationale, an explicit cutoff, and a workable re-entry route.

## Fit and attention

- **Useful when:** A repository may become public, source and delivery identities are changing, or private lineage still needs authorized recovery after public projection.
- **Poor fit when:** Every referenced source is already public in the same durable repository and ordinary relative links provide the complete reader job.
- **Smallest useful dose:** One reference classification, one semantic replacement, and one scoped receipt.
- **Foregrounds:** Reader job, publication standing, semantic identity, re-entry, and the difference between public comprehension and exact private resolution.
- **Interactions:** `source-authority-mapping` selects source standing and receiver topology; `issue-chain-stewardship` owns transitions; evidence-calibrated writing shapes the register; `repository-reentry` establishes current truth.
- **Rest or release when:** The receiving artifact contains only fitting public routes, local explanations, repository-local sources, or stable keys whose private mappings are complete.

## Rules

### Rule: Start with the receiving reader

Name the audience, publication boundary, and decision the record must support. Classify references by the reader job they perform; URL shape remains a secondary signal.

### Rule: Separate semantic identity from retrieval

Keep the public-safe title, role, relation, evidence standing, contribution, and re-entry condition available when a retrieval route changes. A stable identifier can survive a host, repository, branch, or publication transition.

### Rule: Use four receiving forms

Classify each decision-bearing reference as one of:

1. **Accepted public receiver** — a public route performs the same reader job.
2. **Private lineage** — an operator-blind source key pairs with the exact coordinate in the authorized resolver.
3. **Local explanation** — the receiving record carries the useful meaning directly.
4. **Repository-local source** — a relative path reaches the complete local artifact.

### Rule: Public keys reveal no gated coordinate

Derive a source key from a stable public family and sequence or another operator-blind convention. Its value encodes only that public convention. Private identifiers, locators, titles, paths, branch names, commit hashes, and people remain outside the key.

### Rule: Preserve collaboration residue

A retired locator leaves behind the decision, rationale, relationship, evidence limit, contribution, and next workable move that made it useful. This semantic residue supplies comprehension and re-entry; a redaction marker alone is incomplete.

### Rule: Durable prose follows the public boundary

Treat Issue bodies, pull-request descriptions, comments, reviews, commit prose, Threadkeeping, and public handoffs as durable collaboration surfaces when their repository can become public. Tool output, quoted source fragments, and screenshots follow the same receiving boundary.

### Rule: Resolver and public record stay paired

Create or confirm the private mapping before, or atomically with, the public replacement. Repeated references to one source in one role reuse a key; a materially different role can receive a distinct relation key.

### Rule: Paired-receiver settlement preserves distinct information diets

One operator-blind key can coordinate a public record and an authorized resolver while each receiver carries the representation its reader needs. The public record carries semantic identity, relation, contribution, evidence standing, and re-entry. The resolver carries the exact coordinate, access boundary, observation date, and mapping state. Record acceptance for each receiver separately; when either receiver still awaits acceptance, the aggregate receipt remains partial and names the next re-entry move. Settlement here means evidenced collaboration closure rather than distributed-transaction atomicity.

### Rule: Receipts close the projection

Record the cutoff, affected surfaces, disposition totals, remaining boundary, resolver standing, and next receiver. A focused before-and-after count is sufficient evidence for the bounded projection. A standing scanner or validation service needs its own receiving use.

### Rule: Adjacent authority remains intact

Repository settings, publication state, remote refs, history operations, credentials, and destructive changes retain their existing owners and cue boundaries.

## Operating sequence

1. **Resolve current truth:** Read the receiving artifact, source standing, current repository identity, and authorized resolver contract.
2. **Bind the cutoff:** Name the source revision or observation date and count the bounded locator family once.
3. **Classify relations:** Select an accepted public receiver, private lineage key, local explanation, or repository-local source for each decision-bearing reference.
4. **Prepare paired receivers:** Confirm the public semantic record and the authorized private mapping share one stable key, then name the evidence each receiver accepts.
5. **Project the artifact:** Replace the locator while preserving source order, titles, roles, rationale, evidence limits, and re-entry.
6. **Return a receipt:** State what changed, what remains, the acceptance state of both receivers, which resolver rows exist, and where the next collaboration continues.

## Representative scenarios

### Scenario: A private source remains materially useful

- Given a public Threadkeeping record cites a gated working source
- And the source materially changes the rationale or re-entry path
- When the record crosses the publication boundary
- Then the public record keeps a stable source key, title, role, contribution, standing, and re-entry condition
- And the authorized resolver keeps the exact coordinate

### Scenario: A private coordinate reaches a public draft

- Given a draft Issue, review, or handoff contains an exact gated coordinate
- When the public packet is prepared
- Then the intended relation receives a semantic title, local source, accepted public route, or stable key
- And the exact coordinate returns to the authorized resolver before collaboration continues

### Scenario: Complementary receivers settle at different times

- Given one source projection needs a locator-safe public artifact and an exact authorized resolver mapping
- And both records share one operator-blind key while carrying different reader information
- When the public artifact is accepted before the resolver mapping, or the resolver mapping is accepted before the public artifact
- Then the completed receiver stays legible
- And the aggregate receipt remains partial with the awaiting receiver and re-entry move named
- And settlement follows when both receiver-specific acceptance records are present

## Conditional context

The skill loads:

- [references/issue-and-pull-request-practice.md](references/issue-and-pull-request-practice.md) when Issue, pull-request, review, comment, commit, or issue-chain prose is the receiving surface;
- [references/public-safe-threadkeeping.md](references/public-safe-threadkeeping.md) when durable rationale, source roles, supersession, or cross-session re-entry is the receiving surface.

## Completion

The projection is complete when a public collaborator can understand and continue the work from the public record, an authorized collaborator can recover exact gated lineage through the paired resolver, every bounded reference has a receiving form, and publication or repository operations remain with their existing owners. A materially different surface, missed reader job, or resolver mismatch can reopen the contract.