Opensource Release Edho Ferdian

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 delegatetask 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 FORKREPORT.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).

1. 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.

1. 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.

1. Apply the hard gate above based on the verdict.
2. Run Phase 3 per references/packaging-templates.md once cleared.

Report every file generated or enhanced, with setup.sh confirmed executable.

1. 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.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: edhoferdian
• Source: edhoferdian/EEF
• License: MIT

Install and usage instructions live in the source repository linked above.