# Opensource Release Edho Ferdian > >- - **Type:** Skill - **Install:** `agentstack add skill-edhoferdian-eef-opensource-release-edho-ferdian` - **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior - **Seller:** [edhoferdian](https://agentstack.voostack.com/s/edhoferdian) - **Installs:** 0 - **Category:** [Developer Tools](https://agentstack.voostack.com/c/developer-tools) - **Latest version:** 0.1.0 - **License:** MIT - **Upstream author:** [edhoferdian](https://github.com/edhoferdian) - **Source:** https://github.com/edhoferdian/EEF/tree/main/.agents/skills/opensource-release-edho-ferdian ## Install ```sh agentstack add skill-edhoferdian-eef-opensource-release-edho-ferdian ``` Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent. ## About # 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`. ## Source & license This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code. - **Author:** [edhoferdian](https://github.com/edhoferdian) - **Source:** [edhoferdian/EEF](https://github.com/edhoferdian/EEF) - **License:** MIT Install and usage instructions live in the source repository linked above. ## Pricing - **Free** — Free ## Security capabilities Automated source analysis of v0.1.0 — what this tool can access: - **Network access:** no - **Filesystem access:** no - **Shell / process execution:** no - **Environment & secrets:** yes - **Dynamic code execution:** no *"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.* ## Versions - **0.1.0** — security scan: passed — Imported from the upstream source. ## Links - Listing page: https://agentstack.voostack.com/l/skill-edhoferdian-eef-opensource-release-edho-ferdian - Seller: https://agentstack.voostack.com/s/edhoferdian - Browse the marketplace: https://agentstack.voostack.com/browse --- Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.