Open-Source Release — Edho Ferdian Mode

You are running a three-phase release pipeline: fork/prep, then an independent adversarial sanitization audit, then packaging. The three phases are separated on purpose — a project is not safe to publish because the person who sanitized it says so; it's safe because someone who didn't do the sanitizing re-checked it from scratch and found nothing.

Language routing (fixed — see skill-authoring-edho-ferdian's canonical contract)

• Communication to the user → Bahasa Indonesia.
• Report files (FORK_REPORT.md, SANITIZATION_REPORT.md, generated CLAUDE.md/README.md/etc.) → English, matching the base rule's artifact clause.
• The Phase 2 PASS-WITH-WARNINGS confirmation prompt to the user is always in Bahasa Indonesia (see below) — this is a deliberate exception spelled out in references/sanitize-audit.md, not an inconsistency. Full contract: skill-authoring-edho-ferdian §7.

Phase flow

Phase 1  Fork / Prep         → references/fork-prep.md
                                 Copy to staging, detect + extract secrets
                                 into .env.example, replace internal refs,
                                 fresh git history, write FORK_REPORT.md.

Phase 2  Sanitize / Audit    → references/sanitize-audit.md
                                 Independent adversarial re-scan. Does not
                                 trust FORK_REPORT.md. Verdict: PASS / FAIL /
                                 PASS-WITH-WARNINGS. Writes
                                 SANITIZATION_REPORT.md.

Phase 3  Package             → references/packaging-templates.md
                                 CLAUDE.md (this ecosystem's Execution
                                 Context Pack format, <100 lines),
                                 setup.sh, README.md, LICENSE, CONTRIBUTING.md,
                                 GitHub issue templates.

Shared reference used by both Phase 1 and Phase 2: references/secret-patterns.md — the single source of truth for every secret/PII regex and the internal-reference replacement map. Neither phase keeps its own inline copy; both read this file. If you ever find yourself about to write a regex pattern inline in Phase 1 or Phase 2's instructions, stop — it belongs in secret-patterns.md instead, edited once.

The hard gate — read this before starting Phase 3

Phase 3 cannot start while Phase 2's verdict is FAIL. This is not a recommendation, it's a hard stop: no CLAUDE.md, no README.md, nothing gets generated for a project Phase 2 rejected. Send the project back to Phase 1 with the specific findings, let Phase 1 fix them, then re-run Phase 2 in full, from Step 1 — a partial re-audit against only the previously failing items is not sufficient, because a fix to one file can introduce or reveal something a full re-scan would catch and a targeted one wouldn't.

PASS-WITH-WARNINGS requires an explicit user decision before Phase 3 proceeds. Do not silently treat a WARNING verdict as good enough to move on. Present the warning list in Bahasa Indonesia (template and full reasoning in references/sanitize-audit.md) and get an explicit yes/no — either "lanjut dengan status ini" or "perbaiki dulu." Record whichever answer you get:

• If this release is happening inside a dev-kickoff-edho-ferdian-managed project (a /project-memory/ directory exists), write the decision to that project's project-memory/01-decision-register.md — source: this conversation, date, and the specific warnings accepted or the fix requested.
• Otherwise (a standalone, one-off release with no dev-kickoff project context), record the decision inline in SANITIZATION_REPORT.md's own verdict section instead. Never proceed on a WARNING without some durable record of who accepted the risk and why — a chat message alone disappears; a file doesn't.

PASS needs no confirmation — proceed straight to Phase 3.

This skill's Critique-Correction Loop instance

Phase 1 → Phase 2 is this ecosystem's Critique-Correction Loop pattern (the same shape code-review-edho-ferdian uses between its Reviewer and Critic roles — see that skill's references/reflection-critique.md), applied to a release pipeline instead of a code review:

• Phase 1 is the Producer — it claims what it stripped and extracted, and writes FORK_REPORT.md as its own account.
• Phase 2 is the adversarial Verifier — it never opens FORK_REPORT.md to decide what to scan. It re-derives every finding from the filesystem and git history directly, then optionally compares its independent findings against Phase 1's claims (a mismatch is itself a finding, not a contradiction to paper over).

On a harness with sub-agent delegation (Claude Code, OpenCode, Hermes via its delegate_task template, ZCode's own Subagents), Phase 2 runs as the opensource-sanitizer-edho-ferdian agent, delegated fresh after Phase 1 completes — a real separate context, not just an instruction to disregard what's already in view. "Never trust FORK_REPORT.md" is much easier to actually honor when the verifier genuinely never saw it, versus asking the same context that wrote it to pretend otherwise. On a harness with no delegation primitive, run Phase 2 inline per references/sanitize-audit.md, and note in SANITIZATION_REPORT.md that the independence guarantee is weaker in that mode — still re-derive every finding from scratch, just without hard context isolation backing it.

• A FAIL sends the actual file/history issue back to Phase 1's method, never a patch applied directly by Phase 2 — Phase 2 stays read-only, full stop, per its own rules in references/sanitize-audit.md.

Full framing and the reasoning behind treating this as the same pattern lives at the top of references/sanitize-audit.md — read it there rather than duplicating it here.

Workflow

1. Confirm scope with the user: source project path, target directory for the sanitized copy, intended license (don't default silently — see references/packaging-templates.md Step 5), and whether a GitHub repo already exists (affects whether .github/ISSUE_TEMPLATE/ gets created).
2. Run Phase 1 per references/fork-prep.md. Report file counts, secrets extracted, and internal references replaced. State plainly that this report is not the release gate.
3. Run Phase 2 — delegate to opensource-sanitizer-edho-ferdian on a harness that supports it, else run references/sanitize-audit.md inline — unconditionally, on the staged copy, regardless of how confident Phase 1's own report sounded. Get a verdict.
4. Apply the hard gate above based on the verdict.
5. Run Phase 3 per references/packaging-templates.md once cleared. Report every file generated or enhanced, with setup.sh confirmed executable.
6. Final summary to the user (Bahasa Indonesia): what was done in each phase, the Phase 2 verdict and any recorded warning decision, and where every report/generated file landed.

Notes

• references/secret-patterns.md consolidates what used to be two independently-drifting inline pattern lists into one shared source of truth.

Rules

• Never sanitize in place — always stage to a separate TARGET_DIR (Phase 1, Step 2).
• Never let Phase 3 start on a FAIL verdict, no exceptions, no "package it anyway, fix later" path.
• Never silently proceed past PASS-WITH-WARNINGS — get and record an explicit decision first.
• Never trust FORK_REPORT.md's claims as evidence in Phase 2 — re-derive everything.
• Keep secret/PII patterns in secret-patterns.md only — no inline copies in Phase 1 or Phase 2's own reference files.
• Generated CLAUDE.md reuses this ecosystem's Execution Context Pack format and stays under 100 lines — see references/packaging-templates.md.