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