# Skill Authoring Edho Ferdian > >- - **Type:** Skill - **Install:** `agentstack add skill-edhoferdian-eef-skill-authoring-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/skill-authoring-edho-ferdian ## Install ```sh agentstack add skill-edhoferdian-eef-skill-authoring-edho-ferdian ``` Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent. ## About # Skill Authoring — Edho Ferdian Mode ## Boundary with `skill-audit-edho-ferdian` | Moment | Skill | |---|---| | Before a skill exists — should it? does one already? | **this skill** §1 | | While writing it — quality bar, description that triggers | **this skill** §2 | | After it ships — is it actually obeyed? | **this skill** §3 | | Periodically across all skills — stale, redundant, broken links | `skill-audit-edho-ferdian` | | Principles recurring across many skills → rules | **this skill** §4 | | Packaging a finished skill into `dist/*.skill` | **this skill** §6 | Neither skill runs the other's checks. If you find yourself grading description quality across the whole `skills/` tree, you are running the audit, not this. Also distinct from `opensource-release-edho-ferdian`: that skill packages *someone else's project* for public open-source release. §6 below packages *this ecosystem's own* skill folders for distribution. Same verb ("package"), different object — don't route a "package this skill" request there. ## §1 — Search before you build The failure mode is building the twelfth variant of something that already exists. Search in cost order, cheapest first: 1. **This ecosystem** — `skills/*/SKILL.md` in this repo. A near-match here is usually a FOLD (a new `references/*.md` under an existing skill), not a new top-level skill. This is the same consolidation rule D-009 set for this ecosystem's earlier porting work, applied to original work. 2. **Installed and marketplace skills** — name match first, then frontmatter descriptions. 3. **GitHub** — `gh search repos`, `gh search code --filename SKILL.md`. 4. **Web** — at most three targeted queries. **Vet anything external before adopting it.** Read the full SKILL.md and every reference. Look for unexpected shell commands, file writes outside the working tree, network calls, credential handling, or package installs. Check whether the repo is maintained. Copy into a fresh branch and review the diff rather than editing a marketplace original in place. An external skill is untrusted content until read — the same standard this ecosystem holds for any other fetched file. If the user explicitly says to skip the search, acknowledge it and proceed. **Choosing the right artifact form.** A repeated pattern becomes a **command** when a human decides to invoke it at a known moment; a **skill** when it should fire on its own from a description-level trigger; an **agent/subagent** when it needs its own context window or an isolated write surface. Choosing "skill" for something that is really an on-demand checklist is what produces trigger collisions later — see `skill-audit- edho-ferdian`'s redundancy category. ## §2 — The quality bar A skill in this ecosystem is not done until: - **The description triggers.** It names concrete phrases the user actually says (including Indonesian ones), and it says what the skill is *not* for when a neighbouring skill exists. A description that is merely accurate but never fires is a dead skill. - **Its boundary is stated.** If it overlaps another skill, the overlap is named and adjudicated in the text — the audit skill treats a stated boundary as intentional architecture, not redundancy. - **Provenance is recorded** when adapted from an external source: what it was adapted from, the fetch date, and what was deliberately changed. - **References are split by lens, not by chapter.** Many small `references/*.md` loaded on demand beats one long SKILL.md. - **No live dependency on an external harness** (D-005), and no Claude-Code-only construct that breaks portability (D-008). ## §3 — Compliance: does anyone actually obey it? The unexamined assumption behind every skill collection is that written instructions are followed. They frequently are not, and nobody notices because nobody looks. Test one skill by running the same task at three prompt strictness levels and classifying what the agent actually did: | Level | Prompt shape | What a pass looks like | |---|---|---| | Supportive | Names the skill explicitly | The skill's steps appear in order | | Neutral | Describes the task using the skill's own trigger phrases, without naming it | The skill still fires | | Competing | Describes the task while nudging toward a shortcut the skill forbids | The skill's constraint holds | The neutral level tests the description; the competing level tests whether the rules are load-bearing or decorative. Report the compliance rate and the tool-call sequence, not an impression. A skill that only passes at the supportive level has a description problem; one that fails at the competing level has a rules problem. ## §4 — Distilling rules from skills When the same principle appears in three or more skills, it belongs in a rule, not repeated in each. This is the same promotion rule Stage 6 of `dev-kickoff-edho-ferdian` applies to instincts ("three or more related instincts pointing the same way → propose promoting them into PDR §3"), applied one level up. Method: collect exhaustively and mechanically (grep for the repeated phrasing across all `skills/**/*.md`), then judge with full context — scripts gather facts, the model decides. Output is one of: append to an existing rule file, revise an outdated one, or create a new one. Replace the now-duplicated passages with a cross-reference rather than leaving both. ## §5 — Incremental audit handoff A full pass over every skill is expensive and mostly re-reads unchanged files. Prefer a **quick scan**: compare each `SKILL.md` and `references/*.md` mtime against the last audit run, re-evaluate only what changed, and carry forward previous findings for the rest. Report the diff. Fall back to a full pass when no previous run exists, or on explicit request. The findings format and the four audit categories belong to `skill-audit-edho-ferdian` — this section only governs *which files* that audit needs to look at. ## §6 — Packaging for distribution (`dist/*.skill`) Adapted per D-023 (R8) — this ecosystem produces `.skill` archives in `dist/` for manual upload (Claude.ai / Claude Desktop / Claude Code Skills UI), and until now no skill in this ecosystem covered that step. This is not `opensource-release-edho-ferdian`'s job — that skill packages *someone else's project* for public release; this section packages *this ecosystem's own* skill folders for distribution. ### When to package Package a skill into `dist/*.skill` whenever `skills//` changes and the change is going to be committed — CI (`.github/workflows/ci.yml`, `dist-sync` job) fails the build if `dist/` drifts from `skills/`, so "stale and unpublished" is no longer just a convention to remember, it's an enforced gate. Packaging is not automatic on every keystroke — run it as the last step before committing, same as running a formatter. ### Pre-package validation `scripts/validate_skills.py` runs this automatically (also enforced in CI as the `validate` job) — run it yourself before packaging rather than waiting for CI to catch it: ```bash python scripts/validate_skills.py ``` It checks: valid frontmatter with non-empty `name`/`description`, description length ≤1024 chars (the harness display limit this ecosystem was bitten by twice), no "ECC" mentions outside the one deliberate exception (`config-hygiene-edho-ferdian`), and no reference to a `references/*.md` file that doesn't exist anywhere in the repo. It does **not** check absolute local paths (`C:\Users\...`, `/home/...`) or leaked secrets — those need human judgment to avoid false positives in CI, so they stay part of a manual `skill-audit-edho-ferdian` pass, not this automated gate. ### Packaging ```bash python scripts/package_skills.py # all 38 skills python scripts/package_skills.py # just one python scripts/package_skills.py --check # dry run — exit 1 if stale, same check CI runs ``` This is the only way `dist/*.skill` should be produced now — it writes forward-slash paths (a `.skill` zipped with Windows-style backslash paths can fail to install correctly on non-Windows systems) and a fixed internal timestamp, so re-running it produces byte-identical output and CI's `--check` diff is meaningful. Don't hand-zip a skill folder; the archive root must be the skill's own files with no wrapping folder, which the script already guarantees. ### Drift check CI enforces this now (`dist-sync` job runs `package_skills.py --check` on every push/PR) — a PR that changes `skills/` without repackaging `dist/` fails CI rather than silently shipping a stale archive. ### What this section does not cover Publishing the packaged skill anywhere (a marketplace, a shared drive, a repo release) is a separate, explicit-permission action — this section only covers producing a correct local archive. ## §7 — Language routing (canonical contract — all skills point here) Promoted per R3/D-023 (this is §4 applied to itself): 14 skills carried 5+ mutually inconsistent headings/wordings for the same convention — plain `## Language routing`, `(fixed — never ask)`, `(fixed — matches code-review-edho-ferdian's contract)`, `(fixed — matches the rest of this ecosystem)`, and `dev-kickoff-edho-ferdian`'s richer `(v2.0 — inherited, not hardcoded)` — one skill (`security-review-edho-ferdian`) buried it as a numbered item inside "Global rules" instead of its own heading, and roughly half the ecosystem had no statement at all. This section is now the single source of truth; every other skill states it in one line and points here. **Scope — what this governs, and what it does not.** This is which human language a *shipped, installed* skill uses wherever it runs — any project, not just this one. It is a different document from this repo's own `CLAUDE.md` §F, which governs communication during curation work *inside this repo* and is never distributed with an individual skill. The two happen to agree in value (Bahasa Indonesia narration, English artifacts) — that is a coincidence of both being written by the same person for the same habits, not one inheriting from the other. Do not merge them or delete either one thinking it is a duplicate. **The base rule (fixed, never ask):** 1. Narration, explanations, questions, and reports to the user → **Bahasa Indonesia**. 2. Code, diffs, commit messages, filenames, folder names, and any other machine-facing generated artifact → **English**. 3. Never ask the user which language to use — this is fixed, not a preference to elicit. **When a skill's own source material carries a language** (e.g. a spec, document, or dataset already written in a specific language it must mirror back), detect that source language and follow it for content that mirrors the source, while the base rule above still governs narration and artifacts. `dev-kickoff-edho-ferdian`'s "Language routing" section is the fullest worked example of this split (`doc_lang` vs `artifact_lang`, because it ingests specs that may already be Indonesian or English) — read it before writing a new multi-language exception rather than re-deriving one from scratch. **Standard form for every other skill** (one heading, 1-2 sentences, no inline restatement of the full contract): `## Language routing (fixed — see skill-authoring-edho-ferdian's canonical contract)` followed by a sentence naming the base rule and pointing here. ## §8 — Development loop convention (canonical contract — orchestrating skills point here) Every skill in this ecosystem that drives multi-step implementation work — not a single-purpose lens like `code-review-edho-ferdian`, but a skill that plans, writes, and closes out a task — follows the same seven-stage loop: ``` PLAN → TEST → IMPLEMENT → REVIEW → VERIFY → REMEMBER → IMPROVE ``` `dev-kickoff-edho-ferdian` is the canonical, fully-specified implementation of this loop (`references/execution-loop.md` there has the complete per-stage protocol, gate list, and the auto-invocation contract that wires each stage to the matching specialist skill in this ecosystem — read it before re-deriving any part of this cycle elsewhere). Two rules apply to any other skill that adopts this loop: 1. **Point, don't restate.** State the loop in one line and point to `dev-kickoff-edho-ferdian`'s `references/execution-loop.md`, the same way every skill states Language routing in one line and points to §7. A second full copy of the per-stage protocol is a duplicate that will drift. 2. **The last two stages are not optional decoration.** REMEMBER without IMPROVE records a lesson that never changes anything; a skill that implements PLAN through REMEMBER but drops IMPROVE has built a diary, not a feedback loop. If a skill's scope genuinely has no instincts/debt/ dead-code surface to check (rare — most implementation work does), say so explicitly rather than silently truncating the cycle to six stages. **Auto-invocation is the same idea as the "search before you build" (§1) discipline, applied mid-task instead of pre-build.** A skill mid-loop that hits a stage matching another skill's specialty (writing a test → consult `test-authoring-edho-ferdian`; reviewing code → consult `code-review-edho-ferdian`; a build breaks → consult `build-fix-edho-ferdian`) invokes that skill rather than reproducing its judgment from general knowledge. This is what makes the ecosystem behave as one system instead of 33 isolated documents that happen to share a naming suffix. ## §9 — External docs lookup (Context7) (canonical contract — authoring skills point here) Context7 (`mcp__context7__resolve-library-id` → `query-docs`) is a third live external dependency for this ecosystem, alongside ECC (D-005) and Salak (D-004) — consumed, never rebuilt (D-044). It fetches current documentation for a library/framework/SDK/API/CLI directly from source, correcting for training-data staleness on version-specific API surfaces. **When to call it (authoring-time only, not every line of code):** 1. Adding a new dependency or integration. 2. Upgrading or migrating a dependency's major/minor version. 3. Using an API surface that changes fast, or is used rarely enough that a memorized signature is unreliable. 4. Diagnosing a build/compile error that is actually a signature or version-drift issue (`build-fix-edho-ferdian`'s narrow use case). Do not call it for refactoring, business-logic debugging, code review, or general programming concepts that don't hinge on a specific library's current API — this matches the boundary the Context7 MCP server itself declares. **Session discipline:** - Resolve a library's ID once per session and reuse it across every `query-docs` call for that library — don't re-resolve on every question. - On rate-limit or failure: fall back to `WebFetch` against the library's official docs directly; if that also fails, answer from training knowledge but say explicitly it is unverified and may be stale. Never silently answer as if it were confirmed current. - **No local caching of fetched docs.** Caching would recreate exactly the maintenance burden this ecosystem already rejected for ECC and Salak — a local copy that quietly goes stale. Query live, every time it's needed. **Rate limits.** The anonymous/no-key MCP connection is rate-limited. A free API key from context7.com/dashboard raises the limit substantially. Add it by reconfiguring the existing registration: `claude mcp remove context7` then `claude mcp add context7 -- npx -y @upstash/context7-mcp@latest --api-key ` (or set the `CONTEXT7_API_KEY` env var on the same command instead of the flag). Key issuance and MCP reconfiguration is a manual user action — the executor never stores or performs this unattended. **Standard form for every other skill** (one heading, one sentence, pointing here — same convention as §7/§8): `## External docs (fixed — see skill-authoring-edho-ferdian's canonical contract)` followed by a sentence naming when this skill calls Context7 and pointing he … ## 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:** no - **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-skill-authoring-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%.