abyss-sanitized-share

# abyss-sanitized-share

## Intent
Use this skill to adapt `aoa-sanitized-share` to an `abyss-*` repository when the base sanitization workflow is right but the local repo still needs repo-relative sharing surfaces, thresholds, and review posture.

## Trigger boundary
Use this skill when:
- the base `aoa-sanitized-share` workflow is already correct, but an `abyss-*` repo needs local sharing surfaces, repo-relative paths, or explicit sanitization thresholds
- raw logs, diagnostics, config snippets, or incident notes from one `abyss-*` repo need a bounded public-safe or wider-shareable form
- the local repo needs a canonical place or review posture for the sanitized output
- the material mixes durable lessons with raw paths, hostnames, account names, environment values, stack traces, timing traces, local commands, or unpublished operational context
- the share target needs an explicit audience, retention posture, and raw-vs-sanitized separation before publication or handoff
- the family review doc and bundle-local checklist still need to stay aligned

Do not use this skill when:
- the real task is the underlying operational or configuration mutation itself; use `abyss-safe-infra-change`
- no `abyss-*` repo adaptation is needed and the base `aoa-sanitized-share` skill is sufficient
- the overlay would only restate the base sanitization workflow without adding a real local sharing surface
- the main question is whether the underlying action should be allowed at all; use `aoa-approval-gate-check`
- the material is already clearly public-safe and no local sharing surface or threshold needs clarification
- the request asks to preserve raw operational data for an owner-local diagnosis rather than produce a shareable artifact
- the repo route says the destination belongs to another owner and no owner-facing handoff has been named
- the work would widen into broader project doctrine instead of a thin local overlay

## Inputs
- raw material to sanitize
- intended audience or sharing context
- repo-relative destination or canonical sharing surface
- local sensitivity thresholds, review posture, and retention expectation
- redaction map for what is removed, generalized, summarized, or retained
- raw-source location and sanitized-output location, kept distinct
- owner or audience constraints for public, wider-project, maintainer-only, or private handoff
- base skill reference

## Outputs
- sanitized local shareable artifact
- note on what was generalized, removed, summarized, or retained
- repo-relative placement or reference
- raw-vs-sanitized separation note
- explicit audience and remaining-review posture
- pointer to the family review surface
- concise warning about any remaining sensitive edge

## Procedure
1. start from `aoa-sanitized-share` rather than inventing a new family-specific sharing workflow
2. name the audience and destination before deciding what can remain visible
3. separate the raw source from the sanitized output and avoid making the raw source part of the shareable artifact
4. map each sensitive class to an action: remove, generalize, summarize, replace with a repo-relative stand-in, or keep with rationale
5. preserve the operational lesson, evidence shape, and owner route without preserving unnecessary local identifiers
6. keep the adaptation bounded to one local repo family surface
7. make explicit what still requires downstream human review or unpublished local judgment

## Contracts
- preserve the base skill meaning
- keep local paths and output placement repo-relative and explicit
- keep local review posture visible rather than implied
- keep raw material, private host or account details, credentials, exact tokens, environment values, and unpublished incident context out of the shareable artifact
- do not let a sanitized artifact become the canonical source for raw operational truth
- do not erase the lesson so aggressively that the artifact becomes unactionable
- keep the overlay explicit-only, public-safe, and reviewable

## Risks and anti-patterns
- hiding local sharing thresholds in vague prose
- collapsing a thin overlay into project doctrine or incident policy
- naming a repo-relative destination without enough sanitization or audience context
- preserving exact raw paths, hostnames, account names, environment values, or timing traces when a generalized reference would carry the lesson
- deleting all evidence shape and leaving only a harmless but useless summary
- mixing raw and sanitized material in the same destination without a clear owner-local reason
- silently replacing the base workflow instead of adapting the local repo surface

## Verification
- confirm the base skill is still the correct workflow
- confirm the repo-relative sharing surface is named explicitly
- confirm audience, thresholds, retention, and review posture are visible rather than implied
- confirm raw-source and sanitized-output placement remain distinct
- confirm the redaction map preserves the useful lesson while removing unsafe detail
- confirm no owner-local raw data was promoted into public or wider-shareable truth
- confirm the adaptation stays bounded to one local repo family surface
- confirm the family review doc and bundle-local checklist stay aligned

## Technique traceability
Manifest-backed techniques:
- AOA-T-0034 from `8Dionysus/aoa-techniques` at `cd276f040d55d490bd015b8698c7a5d594b9f875` using path `techniques/instruction/docs-boundary/public-safe-artifact-sanitization/TECHNIQUE.md` and sections: Intent, When to use, When not to use, Inputs, Outputs, Core procedure, Contracts, Risks, Validation
- AOA-T-0002 from `8Dionysus/aoa-techniques` at `cd276f040d55d490bd015b8698c7a5d594b9f875` using path `techniques/instruction/docs-boundary/source-of-truth-layout/TECHNIQUE.md` and sections: Intent, When to use, Inputs, Outputs, Core procedure, Contracts, Risks, Validation

## Adaptation points
- repo-relative sharing surfaces
- local sanitization thresholds
- local review posture for sharing
- project-specific output placement examples
- family review doc and bundle-local review checklist