[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6MKYDX8ZP45N4V24X35V4B9":3,"skill-same:01M6MKYDX8ZP45N4V24X35V4B9":84},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":40,"linkOnly":41,"markdownContent":42,"markdownBody":43,"frontMatter":44,"refName":47,"commitSha":48,"skillDirectory":49,"forksCount":50,"repositoryHtmlUrl":51,"repositoryHomepageUrl":52,"ownerHtmlUrl":53,"ownerBlogUrl":54,"ownerDescription":55,"updatedAt":56,"install":57,"resources":69},"01M6MKYDX8ZP45N4V24X35V4B9","migration",null,"Bring an existing codebase into Dryforge, once. Reads the code, asks what code cannot show — business rules, security policy, what is intentional — and writes the project docs at the entry points agents already read. Use when the user invokes the `migration` skill on an existing project. Requires git.","hashgraph-online\u002Fawesome-codex-plugins","hashgraph-online","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F160371962?v=4","01M6CNB6NRJVNNGN14TR01Q6D3","HOL (Hashgraph Online)","01M6JT1HSKKG9V68KQAQGBA7XP",1559,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fprekuter\u002Fdryforge\u002Fskills\u002Fmigration\u002FSKILL.md",[],[5,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39],"show","project docs","when","entry","Existing","codebase","at","true","bring","security policy","project","docs","use","business","user","read","Rules","git","code","policy","security","2026-11-10 10:12:30",false,"---\nname: migration\ndescription: >\n  Bring an existing codebase into Dryforge, once. Reads the code, asks what code cannot show —\n  business rules, security policy, what is intentional — and writes the project docs at the entry\n  points agents already read. Use when the user invokes the `migration` skill on an existing\n  project. Requires git.\ndisable-model-invocation: true\n---\n\n# migration\n\n> **Reply in the user's language, and hold it continuously from your very first line** — the opening,\n> every grounding\u002Fprogress note, the questions, and the harness, not only some of them. Write natively\n> (never translationese). You are reading a codebase (and these instructions) that may be in another\n> language; **neither sets your output language — only the user's does.** Full rule in Core principles below.\n\nConvert an existing project into the dryforge **project harness** — the durable documentation layer\nthat every later agent (dryforge or not) works inside. migration reads the codebase, elicits the\nintent\u002Fconstraints\u002Fdecisions that code cannot express, and generates the whole harness:\n`CLAUDE.md` \u002F `AGENTS.md`, the `docs\u002F` set, and a per-module `AGENTS.md`. The harness spec is in\n`references\u002Fharness-format.md`.\n\nmigration is a **one-time conversion**, not a task runner. It writes documentation only — it does\n**not** create a 3-doc (that is `ready`'s job) and does **not** execute code (that is `go`'s).\nAfter it finishes, commit the harness and clear the session before running `ready` → `go`:\nmigration is an independent piece of work, and a fresh session keeps the task-level dialogue clean.\n\n## Core principles (apply throughout)\n\n- **The harness is durable project memory, not ground truth.** It is the project's discipline and\n  constraint — written so the next agent works the project without going off the rails. A hollow\n  harness (structure present, content empty) is worse than none.\n- **Content density is the whole point.** Every file must clear the quality bar in\n  `references\u002Fharness-format.md` (five principles, four techniques). Filling sections is not the\n  goal; informing the next agent is.\n- **Knowledge asymmetry drives elicitation.** Domain knowledge lives with the user — *extract* it\n  (don't fabricate). Technical knowledge lives with you — *present* options + trade-offs and let the\n  user decide. Don't accept the user's generalities as-is, and don't concretize them alone.\n- **Subagents only at the final REVIEW.** SCAN, ELICIT, and GENERATE run inline in the main session —\n  generation needs the live conversation's *raw* grounding, not a summary. **REVIEW is the exception:**\n  the finished harness is verified by **one independent subagent that did not author it.** Self-judging\n  your own harness is the weakest move (A=A), and the harness is the **most\n  durable artifact in the system** (every later agent works inside it), so it earns the one fresh-eye\n  check — the same relaxation `ready` made (generate inline, verify independently). This is the *only*\n  dispatch.\n- **Stack-agnostic.** No stack\u002Fframework\u002Flibrary name in this skill. Discover all specifics\n  (conventions, module boundaries, build\u002Fverify commands, external deps) at runtime from the project.\n- **escalate-don't-guess.** What the code can't settle and you can't derive, ask the user — never\n  invent a domain rule, a policy, or a rationale.\n- **Match the user's language (language-agnostic).** Like stack-agnosticism, the *method* is fixed\n  and the *specific language* is discovered at runtime, never assumed: produce every user-facing\n  output — the dialogue **and the whole harness** (CLAUDE.md \u002F AGENTS.md, docs\u002F, module AGENTS.md) —\n  in the language the user communicates in, written **natively** (as a fluent speaker of that language\n  would, never translationese). The language these instructions are written in does not constrain the\n  output; if the user's language shifts, follow. **Hold it from the very first line, continuously** —\n  never open in the codebase's or these instructions' language and switch later. The language of the\n  code you read does **not** constrain your output; only the user's does.\n- **Talk to the user only when needed — between beats, say nothing.** You speak at **exactly** these\n  moments: (a) a question you genuinely need answered, (b) the final walk-through \u002F result, (c) a real\n  blocker — **these are the only times user-facing text exists.** SCAN, GENERATE, REVIEW, and any fix\n  loop are **silent phases**: the UI already shows the file\u002Fcommand activity, so narrating it is pure\n  leak. If what you are about to emit is none of (a)\u002F(b)\u002F(c), the correct output is **nothing**.\n  **Between those beats, stay silent** — reading references, reading code, and internal\n  operations are not narrated. **No transition lines** (\"now I'll...\", \"먼저 ...\", \"let me read...\", \"Now the ...\" announcing each write) — at\n  those plumbing moments your voice slips into the instructions' language (English) or internal tokens;\n  emit *nothing* there, don't translate it. When you *do* speak (a\u002Fb\u002Fc), use a **plain, non-technical\n  register** in the user's language — the words a non-engineer would understand. This is your default\n  voice, not a per-line check, so it costs nothing. **Never surface internal tokens:** dryforge mechanism \u002F coined terms (harness,\n  ledger, decision surface, grounding, lens, invariant, `.dryforge`), phase \u002F step labels (SCAN \u002F\n  ELICIT \u002F GENERATE \u002F REVIEW), or project-internal jargon a non-engineer wouldn't recognize\n  (library\u002Ftool names, config flags, test-framework internals). **Don't soften internal logic into\n  user-ish words — just omit it.** E.g. \"Starting a git repo here.\" — not \"Initializing git and adding\n  the marker directory to `.gitignore` so the harness state isn't committed.\"\n\n## Input & preconditions\n\n- Invocation: the user invokes the `migration` skill, no arguments — migration reads the **current\n  project**.\n- **Existing codebase expected.** migration converts a project that already has code. For a\n  greenfield project (no code yet), there is nothing to migrate — direct the user to `ready` (which\n  designs the project's first cycle and lets `go` create the harness from scratch).\n- **git required.** If the project is not a git repo, offer to run `git init` **and make an initial\n  commit** (later `go` needs a HEAD for worktrees). If git is not installed, stop and say so.\n- **git posture — migration writes files, it does not commit.** migration creates the harness files,\n  backs up any existing entry file to `.dryforge\u002Fbackup\u002F`, adds `.dryforge\u002F` to `.gitignore` (so the\n  local marker and backups aren't accidentally committed), and writes the `.dryforge\u002Fstatus.json`\n  marker on completion. It performs **no commits and no branch operations** — whether and when to\n  commit the harness is the user's choice. (This differs from `ready`, which never touches\n  `.gitignore`: migration may not be immediately followed by `go`, so it sets up the ignore itself.)\n\n## Phase 1 — SCAN (build the technical map)\n\nRead the project inline (file reads, shell, search — no subagent dispatch). Start with the cheapest map and\nstop once you can ground ELICIT's questions; deep-read only where you must.\n\nCover:\n- **Directory structure** → identify the tech stack and the module\u002Fservice boundaries.\n- **Code patterns** → conventions, naming, test structure, build system.\n- **Existing docs** (CLAUDE.md, README, docs\u002F, AGENTS.md, ...) → list them and **demote to reference\n  material** (not authority — they may be stale or wrong).\n- **External dependencies** → auth, data storage, cache, external APIs.\n- **git history** → activity scope, the major change patterns.\n\nResult: a **manifest** of the project — every module\u002Fentity, pattern, security surface, external\ndependency, and gap. This is the **ledger** ELICIT works from (`references\u002Fmigration-elicit.md`): each\nitem must close as `confirmed` \u002F `asked-answered` \u002F `N\u002FA — reason`, so coverage is *observable*, not\nasserted.\n\n## Phase 2 — ELICIT (collect what code can't reveal) — `references\u002Fmigration-elicit.md`\n\n**Force-load `references\u002Fmigration-elicit.md`.** Using the SCAN map, ask the user for the\ninformation code alone cannot extract — project-wide (not task-focused). The guiding frame:\n*self-infer first, ask deeply only where being wrong is dangerous* (business model, domain\ninvariants, security policy must be user-confirmed even when code-inferable; technical WHY and\nconventions need only a light confirm when the code answers them).\n\n**Existing-docs handling.** Read existing docs (reference status). Review any existing\nCLAUDE.md\u002FAGENTS.md **critically** — decide what to fold into the dryforge system, what to drop, and\nwhat to improve — then present the review to the user, explain it, and get approval.\n\n## Phase 3 — GENERATE (write the harness) — `references\u002Fharness-format.md`\n\n**Force-load `references\u002Fharness-format.md`** and generate the whole harness to its spec, in order:\n\n1. Create the `.dryforge\u002F` directory if absent.\n2. If a CLAUDE.md or AGENTS.md exists, back each one up to `.dryforge\u002Fbackup\u002F` (entry-point handling\n   in harness-format).\n3. Create `docs\u002F` and every file in it (harness-format spec).\n4. Create CLAUDE.md \u002F AGENTS.md (identical content).\n5. Create a module AGENTS.md per module identified in SCAN.\n6. Record the current state in `docs\u002Ftracking\u002Fstatus.md` (done vs. remaining, against full scope).\n\nExplore sources fully before writing; verify each file against the code both ways (omission \u002F\nhallucination) as you go — this self-check is separate from Phase 4.\n\n**Write every file silently** — do not announce each file or section as you go (\"Now the docs...\",\n\"이제 모듈 AGENTS.md를...\", \"Now the entry point\"); the UI already shows each write. This multi-file\nwriting sequence is where narration leaks most — emit nothing between writes.\n\n## Phase 4 — REVIEW (verify quality) — `references\u002Fharness-review.md`\n\n**Force-load `references\u002Fharness-review.md`** (the rubric) and **dispatch a fresh general-purpose subagent\nthat did NOT author the harness** to verify it independently. Use a **general-purpose** agent with full\nread\u002Finspect tools (not a plan-only or search-only agent type) so it can cross-check every claim against\nthe actual code; give it the harness files + the rubric + **the user's language** (so it judges native\nfidelity) + **the Phase-2 ledger with every disposition, inline in the dispatch prompt** (the ledger\nis session state — the subagent cannot see it any other way, and the shared rubric does not carry\nit), **read-only**, returning a **structured list** (no raw dump). It checks the four dimensions: content (substantive\ndensity + quality principles), format (self-containment, altitude, no references), completeness\n(required files present **+ every SCAN-ledger item dispositioned** — judged against the inline\nledger), source-cross-check\n(omission vs. hallucination, future-scope exempt). The subagent is a fresh session and **cannot ask the\nuser** — so the orchestrator relays each finding: internally resolvable → fix directly; needs user\nintent → carry to Phase 5. **A surviving blocker → escalate to the user, do not loop** (the\n`3-doc-gate` discipline). This independent pass is distinct from the author's own omission\u002Fhallucination\nself-check during GENERATE (that catches what *you* can see; this catches what you can't — A=A).\n\n## Phase 5 — USER GATE\n\nPresent the whole harness to the user — not a raw document dump, but a walk-through of the key\ndecisions captured (what SCAN\u002FELICIT found, what each doc records, what was dropped from old docs and\nwhy). Resolve any Phase-4 questions that need user intent. On approval:\n\n- Write `.dryforge\u002Fstatus.json` with the initialized marker — `{ \"initialized\": true }`. This is a\n  **local-only** marker (inside the gitignored `.dryforge\u002F`): its presence tells a later `go` that\n  the harness already exists, so every change is a **delta**; its absence means first-cycle creation.\n- Confirm `.dryforge\u002F` is in `.gitignore`.\n\nThen migration is complete. Remind the user to **commit the harness** (migration itself does not\ncommit — and a later `go` treats uncommitted files other than `.dryforge\u002F` as foreign work and\nstops), then clear the session before running `ready` → `go`.\n\n## Completion gate (avoid self-judgment A=A)\n\nDone only when ALL hold:\n- Every `docs\u002F` file exists (7 core docs + tracking: status.md, decisions\u002Findex.md **+ an ADR\n  (`NNNN-*.md`) for each trade-off decision the ledger confirmed**, findings.md).\n- CLAUDE.md and AGENTS.md both exist, with identical content.\n- An AGENTS.md exists for every identified module.\n- The **independent** REVIEW passes (no blocking finding under `references\u002Fharness-review.md`; any\n  surviving blocker was escalated to the user, not looped).\n- The user has approved.\n- `.dryforge\u002Fstatus.json` written (initialized) and `.dryforge\u002F` is gitignored.\n","# migration\n\n> **Reply in the user's language, and hold it continuously from your very first line** — the opening,\n> every grounding\u002Fprogress note, the questions, and the harness, not only some of them. Write natively\n> (never translationese). You are reading a codebase (and these instructions) that may be in another\n> language; **neither sets your output language — only the user's does.** Full rule in Core principles below.\n\nConvert an existing project into the dryforge **project harness** — the durable documentation layer\nthat every later agent (dryforge or not) works inside. migration reads the codebase, elicits the\nintent\u002Fconstraints\u002Fdecisions that code cannot express, and generates the whole harness:\n`CLAUDE.md` \u002F `AGENTS.md`, the `docs\u002F` set, and a per-module `AGENTS.md`. The harness spec is in\n`references\u002Fharness-format.md`.\n\nmigration is a **one-time conversion**, not a task runner. It writes documentation only — it does\n**not** create a 3-doc (that is `ready`'s job) and does **not** execute code (that is `go`'s).\nAfter it finishes, commit the harness and clear the session before running `ready` → `go`:\nmigration is an independent piece of work, and a fresh session keeps the task-level dialogue clean.\n\n## Core principles (apply throughout)\n\n- **The harness is durable project memory, not ground truth.** It is the project's discipline and\n  constraint — written so the next agent works the project without going off the rails. A hollow\n  harness (structure present, content empty) is worse than none.\n- **Content density is the whole point.** Every file must clear the quality bar in\n  `references\u002Fharness-format.md` (five principles, four techniques). Filling sections is not the\n  goal; informing the next agent is.\n- **Knowledge asymmetry drives elicitation.** Domain knowledge lives with the user — *extract* it\n  (don't fabricate). Technical knowledge lives with you — *present* options + trade-offs and let the\n  user decide. Don't accept the user's generalities as-is, and don't concretize them alone.\n- **Subagents only at the final REVIEW.** SCAN, ELICIT, and GENERATE run inline in the main session —\n  generation needs the live conversation's *raw* grounding, not a summary. **REVIEW is the exception:**\n  the finished harness is verified by **one independent subagent that did not author it.** Self-judging\n  your own harness is the weakest move (A=A), and the harness is the **most\n  durable artifact in the system** (every later agent works inside it), so it earns the one fresh-eye\n  check — the same relaxation `ready` made (generate inline, verify independently). This is the *only*\n  dispatch.\n- **Stack-agnostic.** No stack\u002Fframework\u002Flibrary name in this skill. Discover all specifics\n  (conventions, module boundaries, build\u002Fverify commands, external deps) at runtime from the project.\n- **escalate-don't-guess.** What the code can't settle and you can't derive, ask the user — never\n  invent a domain rule, a policy, or a rationale.\n- **Match the user's language (language-agnostic).** Like stack-agnosticism, the *method* is fixed\n  and the *specific language* is discovered at runtime, never assumed: produce every user-facing\n  output — the dialogue **and the whole harness** (CLAUDE.md \u002F AGENTS.md, docs\u002F, module AGENTS.md) —\n  in the language the user communicates in, written **natively** (as a fluent speaker of that language\n  would, never translationese). The language these instructions are written in does not constrain the\n  output; if the user's language shifts, follow. **Hold it from the very first line, continuously** —\n  never open in the codebase's or these instructions' language and switch later. The language of the\n  code you read does **not** constrain your output; only the user's does.\n- **Talk to the user only when needed — between beats, say nothing.** You speak at **exactly** these\n  moments: (a) a question you genuinely need answered, (b) the final walk-through \u002F result, (c) a real\n  blocker — **these are the only times user-facing text exists.** SCAN, GENERATE, REVIEW, and any fix\n  loop are **silent phases**: the UI already shows the file\u002Fcommand activity, so narrating it is pure\n  leak. If what you are about to emit is none of (a)\u002F(b)\u002F(c), the correct output is **nothing**.\n  **Between those beats, stay silent** — reading references, reading code, and internal\n  operations are not narrated. **No transition lines** (\"now I'll...\", \"먼저 ...\", \"let me read...\", \"Now the ...\" announcing each write) — at\n  those plumbing moments your voice slips into the instructions' language (English) or internal tokens;\n  emit *nothing* there, don't translate it. When you *do* speak (a\u002Fb\u002Fc), use a **plain, non-technical\n  register** in the user's language — the words a non-engineer would understand. This is your default\n  voice, not a per-line check, so it costs nothing. **Never surface internal tokens:** dryforge mechanism \u002F coined terms (harness,\n  ledger, decision surface, grounding, lens, invariant, `.dryforge`), phase \u002F step labels (SCAN \u002F\n  ELICIT \u002F GENERATE \u002F REVIEW), or project-internal jargon a non-engineer wouldn't recognize\n  (library\u002Ftool names, config flags, test-framework internals). **Don't soften internal logic into\n  user-ish words — just omit it.** E.g. \"Starting a git repo here.\" — not \"Initializing git and adding\n  the marker directory to `.gitignore` so the harness state isn't committed.\"\n\n## Input & preconditions\n\n- Invocation: the user invokes the `migration` skill, no arguments — migration reads the **current\n  project**.\n- **Existing codebase expected.** migration converts a project that already has code. For a\n  greenfield project (no code yet), there is nothing to migrate — direct the user to `ready` (which\n  designs the project's first cycle and lets `go` create the harness from scratch).\n- **git required.** If the project is not a git repo, offer to run `git init` **and make an initial\n  commit** (later `go` needs a HEAD for worktrees). If git is not installed, stop and say so.\n- **git posture — migration writes files, it does not commit.** migration creates the harness files,\n  backs up any existing entry file to `.dryforge\u002Fbackup\u002F`, adds `.dryforge\u002F` to `.gitignore` (so the\n  local marker and backups aren't accidentally committed), and writes the `.dryforge\u002Fstatus.json`\n  marker on completion. It performs **no commits and no branch operations** — whether and when to\n  commit the harness is the user's choice. (This differs from `ready`, which never touches\n  `.gitignore`: migration may not be immediately followed by `go`, so it sets up the ignore itself.)\n\n## Phase 1 — SCAN (build the technical map)\n\nRead the project inline (file reads, shell, search — no subagent dispatch). Start with the cheapest map and\nstop once you can ground ELICIT's questions; deep-read only where you must.\n\nCover:\n- **Directory structure** → identify the tech stack and the module\u002Fservice boundaries.\n- **Code patterns** → conventions, naming, test structure, build system.\n- **Existing docs** (CLAUDE.md, README, docs\u002F, AGENTS.md, ...) → list them and **demote to reference\n  material** (not authority — they may be stale or wrong).\n- **External dependencies** → auth, data storage, cache, external APIs.\n- **git history** → activity scope, the major change patterns.\n\nResult: a **manifest** of the project — every module\u002Fentity, pattern, security surface, external\ndependency, and gap. This is the **ledger** ELICIT works from (`references\u002Fmigration-elicit.md`): each\nitem must close as `confirmed` \u002F `asked-answered` \u002F `N\u002FA — reason`, so coverage is *observable*, not\nasserted.\n\n## Phase 2 — ELICIT (collect what code can't reveal) — `references\u002Fmigration-elicit.md`\n\n**Force-load `references\u002Fmigration-elicit.md`.** Using the SCAN map, ask the user for the\ninformation code alone cannot extract — project-wide (not task-focused). The guiding frame:\n*self-infer first, ask deeply only where being wrong is dangerous* (business model, domain\ninvariants, security policy must be user-confirmed even when code-inferable; technical WHY and\nconventions need only a light confirm when the code answers them).\n\n**Existing-docs handling.** Read existing docs (reference status). Review any existing\nCLAUDE.md\u002FAGENTS.md **critically** — decide what to fold into the dryforge system, what to drop, and\nwhat to improve — then present the review to the user, explain it, and get approval.\n\n## Phase 3 — GENERATE (write the harness) — `references\u002Fharness-format.md`\n\n**Force-load `references\u002Fharness-format.md`** and generate the whole harness to its spec, in order:\n\n1. Create the `.dryforge\u002F` directory if absent.\n2. If a CLAUDE.md or AGENTS.md exists, back each one up to `.dryforge\u002Fbackup\u002F` (entry-point handling\n   in harness-format).\n3. Create `docs\u002F` and every file in it (harness-format spec).\n4. Create CLAUDE.md \u002F AGENTS.md (identical content).\n5. Create a module AGENTS.md per module identified in SCAN.\n6. Record the current state in `docs\u002Ftracking\u002Fstatus.md` (done vs. remaining, against full scope).\n\nExplore sources fully before writing; verify each file against the code both ways (omission \u002F\nhallucination) as you go — this self-check is separate from Phase 4.\n\n**Write every file silently** — do not announce each file or section as you go (\"Now the docs...\",\n\"이제 모듈 AGENTS.md를...\", \"Now the entry point\"); the UI already shows each write. This multi-file\nwriting sequence is where narration leaks most — emit nothing between writes.\n\n## Phase 4 — REVIEW (verify quality) — `references\u002Fharness-review.md`\n\n**Force-load `references\u002Fharness-review.md`** (the rubric) and **dispatch a fresh general-purpose subagent\nthat did NOT author the harness** to verify it independently. Use a **general-purpose** agent with full\nread\u002Finspect tools (not a plan-only or search-only agent type) so it can cross-check every claim against\nthe actual code; give it the harness files + the rubric + **the user's language** (so it judges native\nfidelity) + **the Phase-2 ledger with every disposition, inline in the dispatch prompt** (the ledger\nis session state — the subagent cannot see it any other way, and the shared rubric does not carry\nit), **read-only**, returning a **structured list** (no raw dump). It checks the four dimensions: content (substantive\ndensity + quality principles), format (self-containment, altitude, no references), completeness\n(required files present **+ every SCAN-ledger item dispositioned** — judged against the inline\nledger), source-cross-check\n(omission vs. hallucination, future-scope exempt). The subagent is a fresh session and **cannot ask the\nuser** — so the orchestrator relays each finding: internally resolvable → fix directly; needs user\nintent → carry to Phase 5. **A surviving blocker → escalate to the user, do not loop** (the\n`3-doc-gate` discipline). This independent pass is distinct from the author's own omission\u002Fhallucination\nself-check during GENERATE (that catches what *you* can see; this catches what you can't — A=A).\n\n## Phase 5 — USER GATE\n\nPresent the whole harness to the user — not a raw document dump, but a walk-through of the key\ndecisions captured (what SCAN\u002FELICIT found, what each doc records, what was dropped from old docs and\nwhy). Resolve any Phase-4 questions that need user intent. On approval:\n\n- Write `.dryforge\u002Fstatus.json` with the initialized marker — `{ \"initialized\": true }`. This is a\n  **local-only** marker (inside the gitignored `.dryforge\u002F`): its presence tells a later `go` that\n  the harness already exists, so every change is a **delta**; its absence means first-cycle creation.\n- Confirm `.dryforge\u002F` is in `.gitignore`.\n\nThen migration is complete. Remind the user to **commit the harness** (migration itself does not\ncommit — and a later `go` treats uncommitted files other than `.dryforge\u002F` as foreign work and\nstops), then clear the session before running `ready` → `go`.\n\n## Completion gate (avoid self-judgment A=A)\n\nDone only when ALL hold:\n- Every `docs\u002F` file exists (7 core docs + tracking: status.md, decisions\u002Findex.md **+ an ADR\n  (`NNNN-*.md`) for each trade-off decision the ledger confirmed**, findings.md).\n- CLAUDE.md and AGENTS.md both exist, with identical content.\n- An AGENTS.md exists for every identified module.\n- The **independent** REVIEW passes (no blocking finding under `references\u002Fharness-review.md`; any\n  surviving blocker was escalated to the user, not looped).\n- The user has approved.\n- `.dryforge\u002Fstatus.json` written (initialized) and `.dryforge\u002F` is gitignored.\n",{"name":5,"description":45,"disable-model-invocation":46},"Bring an existing codebase into Dryforge, once. Reads the code, asks what code cannot show — business rules, security policy, what is intentional — and writes the project docs at the entry points agents already read. Use when the user invokes the `migration` skill on an existing project. Requires git.\n",true,"main","f620abaff09061f8c8b1f1559dca3fdd031a32e5","plugins\u002Fprekuter\u002Fdryforge\u002Fskills\u002Fmigration",474,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins","https:\u002F\u002Fhol.org\u002Fplugins\u002Fbest-codex-plugins","https:\u002F\u002Fgithub.com\u002Fhashgraph-online","https:\u002F\u002Fhol.org","Open-source standards and developer tools for interoperable AI agents: discovery, identity, communication, payments, privacy and security.","2026-11-11 14:40:14",{"source":8,"skillName":5,"commands":58,"prompt":68,"zipAvailable":46},[59,62,65],{"tool":60,"command":61},"npx","npx skills add hashgraph-online\u002Fawesome-codex-plugins --skill migration",{"tool":63,"command":64},"bunx","bunx skills add hashgraph-online\u002Fawesome-codex-plugins --skill migration",{"tool":66,"command":67},"pnpm","pnpm dlx skills add hashgraph-online\u002Fawesome-codex-plugins --skill migration","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fprekuter\u002Fdryforge\u002Fskills\u002Fmigration\u002FSKILL.md",[70,76,80],{"path":71,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":74,"sourceHtmlUrl":75},"references\u002Fharness-format.md","REFERENCE","参考文档",29474,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fprekuter\u002Fdryforge\u002Fskills\u002Fmigration\u002Freferences\u002Fharness-format.md",{"path":77,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":78,"sourceHtmlUrl":79},"references\u002Fharness-review.md",7444,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fprekuter\u002Fdryforge\u002Fskills\u002Fmigration\u002Freferences\u002Fharness-review.md",{"path":81,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":82,"sourceHtmlUrl":83},"references\u002Fmigration-elicit.md",8169,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fprekuter\u002Fdryforge\u002Fskills\u002Fmigration\u002Freferences\u002Fmigration-elicit.md",[85,93,100,107,133,156],{"skillNo":86,"name":87,"nameZh":6,"description":88,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":89,"categories":90,"keywords":91,"publishedAt":92},"01M746ZWACVKMZ1BJXJZHYJSSX","migrate-to-e2e","Moves an existing Playwright, Cypress, Selenium, Appium, Detox, Maestro, or TesterArmy suite to e2e one slice at a time, with the old suite running beside the new one until each ported test is proven. Keeps a MIGRATION.md progress file so any later session resumes where the last stopped. Optionally plants a defect to show both suites catch it. Use for \u002Fmigrate-to-e2e, \"migrate our tests to e2e\", \"port these Maestro flows\", \"move our TesterArmy tests\", or when a project has an e2e config and an older suite still running.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftester-army\u002Fe2e\u002Fskills\u002Fmigrate-to-e2e\u002FSKILL.md",[],[],"2026-11-11 15:11:14",{"skillNo":94,"name":95,"nameZh":6,"description":96,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":97,"categories":98,"keywords":99,"publishedAt":92},"01M746ZPTAX1Q0FBKAB1CYND7E","e2e","Writes, runs, and debugs end-to-end tests for web and mobile apps with e2e, the agentic test runner, which mixes agent.act goals with exact locator assertions on a Playwright browser or an iOS or Android device. Also drives a project's running app live over the e2e MCP server to look at a screen, check a UI change, take a screenshot or record a video, and try a locator; and runs bug bashes, parallel e2e explore runs with each bug proven by a repro test. Use when a project depends on e2e or has an e2e.config.ts, when asked for end-to-end, browser, mobile, or agentic UI tests, to check a change in the running app, to QA or bug bash an app or branch, or when an e2e run fails.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftester-army\u002Fe2e\u002Fskills\u002Fe2e\u002FSKILL.md",[],[],{"skillNo":101,"name":102,"nameZh":6,"description":103,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":104,"categories":105,"keywords":106,"publishedAt":92},"01M746ZJN784HVHMDP9MQGCSGG","create-verification-skill","Generate a project-local verify-\u003Capp> skill on top of e2e, so any coding agent can launch the app, check it is worth driving, exercise a feature the way a user does, keep evidence, and bug bash it. Writes the skill, a feature map with one explore charter per feature, and proves it once. Use for \u002Fcreate-verification-skill, \"make a verification skill for this repo\", or when a project has no scripted way to prove UI behavior.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftester-army\u002Fe2e\u002Fskills\u002Fcreate-verification-skill\u002FSKILL.md",[],[],{"skillNo":108,"name":109,"nameZh":6,"description":110,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":111,"categories":112,"keywords":113,"publishedAt":40},"01M716A6ETNB9B1SQ3GXZC75VR","deja-search","deja-vu memory — search the user's past AI coding sessions with the deja CLI. Holds what they already settled and never wrote into the repo (naming rules, banned or already-tried tools, required checks before merge, preferred values, who owns what). Use before your first edit in a task, before you call a change done or ready to merge, before you recommend a tool, library, design or reviewer, before re-debugging an error that may already be solved, when they say 'didn't we fix this before', 'what did we decide about X' or 'I already have that', and before telling them something on this machine does not exist.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fvshulcz\u002Fdeja-vu\u002Fskills\u002Fdeja-search\u002FSKILL.md",[],[114,115,116,117,118,119,120,121,122,123,124,21,125,126,127,128,129,130,131,132],"search","deja search","never","error","ready","memory","re","decide","fix","design","debugging","you","done","reviewer","io","change","cli","merge","past",{"skillNo":134,"name":135,"nameZh":6,"description":136,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":137,"categories":138,"keywords":139,"publishedAt":40},"01M716A3J2W5SENSE9VGMXB375","deja-reflect","End-of-session reflection and memory curation with deja-vu. Review what was decided, what commands broke and what repaired them, and record durable project rules or decisions with deja remember so the next session starts with them.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fvshulcz\u002Fdeja-vu\u002Fskills\u002Fdeja-reflect\u002FSKILL.md",[],[140,141,142,128,143,144,145,146,147,148,35,149,150,151,119,152,29,153,154,155],"deja reflect","reflect","review","with","record","github","next","https","node","decisions","brew","remember","project rules","session","end","reflection",{"skillNo":157,"name":158,"nameZh":6,"description":159,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":160,"categories":161,"keywords":173,"publishedAt":40},"01M715T3RR4BAYSR57HPPTJ0PF","revid","Make, edit, export and post AI videos with Revid (revid.ai) through the Revid MCP server. Use whenever the user wants a short-form or long-form video made (from an idea, a script, a URL, an article, a PDF, a tweet, a product page, their own clips, or a song), wants to find what is going viral on TikTok, YouTube, Instagram or X before making something, wants to edit or re-export an existing Revid project, generate a standalone AI image or clip, make a series episode, or publish and schedule a finished video to connected social accounts. Covers setup (hosted MCP with OAuth, or an API key), the 36 tools, credits, polling and the rules for publishing. Routes to the more specific revid-* skills when one fits.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftmakersas\u002Frevid-skills\u002Fskills\u002Frevid\u002FSKILL.md",[162,167,170],{"categoryNo":163,"categoryName":164,"taxonomyType":165,"taxonomyTypeDesc":166},"01JBSEEDCAT000000000000016","图像与多媒体","SCENARIO","使用场景",{"categoryNo":168,"categoryName":169,"taxonomyType":165,"taxonomyTypeDesc":166},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":171,"categoryName":172,"taxonomyType":165,"taxonomyTypeDesc":166},"01JBSEEDCAT000000000000010","后端与接口",[158,174,175,176,177,178,179,29,180,120,181,182,183,184,21,185,186,187,188,189],"URL","Video","short-form","standalone","PDF","viral","tiktok","short","social","MCP","song","image","mcp server","schedule","api","publish"]