[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71SYNM9BHMZGR0PTR4Y7CPT":3,"skill-same:01M71SYNM9BHMZGR0PTR4Y7CPT":66},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":17,"publishedAt":37,"linkOnly":38,"markdownContent":39,"markdownBody":40,"frontMatter":41,"refName":44,"commitSha":45,"skillDirectory":46,"forksCount":47,"repositoryHtmlUrl":48,"repositoryHomepageUrl":6,"ownerHtmlUrl":49,"ownerBlogUrl":50,"ownerDescription":51,"updatedAt":52,"install":53,"resources":65},"01M71SYNM9BHMZGR0PTR4Y7CPT","forge",null,"Use when planning a workstream that spans multiple PRs, involves decision forks, or needs structured phasing before implementation — a technical spec, design document, initiative roadmap, or pre-implementation proposal. Not for single-PR changes with an obvious path; plain plan mode covers those.","Claudfather\u002FclauDNA","Claudfather","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F281278891?v=4","01M71SX82K0TBGQ394AB2G1T5Z","01M71SX83CE1S8YC06K9P3P962",0,"Apache-2.0","https:\u002F\u002Fgithub.com\u002FClaudfather\u002FclauDNA\u002Fblob\u002Fmain\u002Fskills\u002Fforge\u002FSKILL.md",[],[5,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36],"needs","prs","session","for","planning","pr","path","issue","plan mode","plan","URL","when","roadmap","auto","design","decision","mode","phasing","proposal","2026-11-10 13:02:02",false,"---\nname: forge\nuser-invocable: true\ndescription: \"Use when planning a workstream that spans multiple PRs, involves decision forks, or needs structured phasing before implementation — a technical spec, design document, initiative roadmap, or pre-implementation proposal. Not for single-PR changes with an obvious path; plain plan mode covers those.\"\nargument-hint: \"[topic-or-issue-url] [--output artifacts|github|docs|session] [--auto]\"\n---\n\n# Forge\n\n> **Codex:** Read `..\u002F_shared\u002Fcodex-tools.md` before following this skill. Apply its tool, root and dispatch mappings throughout.\n\nYou are a plan architect. Your job is to produce a structured planning document that can survive multi-lens review, iterative hardening, and decision-fork ratification. A good plan is a contract between the humans who ratify it and the engineers who implement it. A vague plan wastes more time than no plan — it creates false alignment.\n\nForge is the *general-purpose* planning lens — reach for it when the lens is \"build this specific thing,\" as opposed to the targeted audit lenses (`\u002Fclaudna:audit tech-debt`, `\u002Fclaudna:audit security`, …). Like them, forge **authors** a plan in the shared §4.1 publishable-doc contract and hands it to `\u002Fclaudna:publish` to persist; it never writes output itself. The published artifact is the substrate the `\u002Fironclad` hardening loop iterates on.\n\n**Enter Plan Mode.** Call `EnterPlanMode`. All analysis is read-only during research phases. If declined, proceed by convention.\n\n## Arguments\n\nParse `$ARGUMENTS` at invocation:\n- **First positional arg:** Topic description, issue URL, or path to an existing rough plan. If omitted, prompt for it.\n- `--auto`: Non-interactive mode. Suppresses Plan Mode and all interactive gates. Requires topic in `$ARGUMENTS`. Emits structured-result JSON and stops.\n- `--output github`: Publish the plan as a §4.1 GitHub Issue via `\u002Fclaudna:publish --to github-issue` — the shared, build-ready contract. The Issue body is a revision-bound edition of the retained canonical plan; an explicitly selected existing issue may instead be the declared source authority under source-guide §4.\n- `--output docs`: Publish to the repo's `documentation\u002F` tree via `\u002Fclaudna:publish --to docs` — a PR-reviewable plan directory; choose this when git diffs matter (large or contentious plans).\n- `--output artifacts`: Default to current-native-session canonical artifacts via `\u002Fclaudna:publish --to artifacts`. Use the ownership and permission contract in orchestration guide §1; no operation-ID or OS-temp fallback. Native qualification remains required before merge\u002Frelease.\n- `--output session`: Present the plan in chat only, with no files.\n\nDefault (no flag): Interactive mode, artifacts output.\n\n## When to Use\n\nYou are about to start a workstream that is:\n- Multi-phase (more than a single PR)\n- Multi-person (needs coordination across engineers\u002Freviewers)\n- Decision-heavy (has forks where reasonable people disagree)\n- High-stakes (wrong direction creates weeks of rework)\n\nThis is for **workstream-level planning** — initiatives that span multiple PRs and weeks. Not for single-PR task scoping (use `\u002Fweigh-development-paths` for that) or implementation details (use `\u002Fbuild` after the plan is ratified).\n\n### Why forge over plain plan mode\n\nPlan mode is the *mechanism* — read-only research, then propose. Forge adds the *methodology and artifact* on top: the §4.1 contract that forces completeness, ratifiable **decision forks**, a durable Issue the team iterates, and a direct path into the `\u002Fironclad` hardening loop and `\u002Fbuild`. If none of that gets used — single session, single implementer, no real forks — plain plan mode is the better, lighter choice. Forge earns its overhead only when the plan must survive review, coordinate people, and persist.\n\n## Phase 0: Right-Size Gate\n\nOver-applying forge is the fastest way to make it feel like ceremony. Before researching, score the topic against the four criteria above (multi-phase, multi-person, decision-heavy, high-stakes):\n\n- **0–1 met** → forge is likely the wrong tool. Recommend plain **plan mode** (a single-session task) or **`\u002Fweigh-development-paths`** (a single-PR architecture choice). In interactive mode, confirm with the user before continuing; in `--auto`, proceed but set `\"right_size\": \"marginal\"` in the result JSON.\n- **2+ met** → forge earns its weight. Proceed.\n\n**Advisory, never a hard block** — a user who knows they want a forge plan always continues. The gate exists only to stop forge from manufacturing false ceremony around work a lighter tool handles better.\n\n## Phase 1: Research\n\n### Step 1: Understand the Scope\n\nRead everything relevant:\n- **Topic input** — the user's description, issue body, or rough plan\n- **PROJECT_MISSION.md** — if it exists in the repo, read it. The plan must align with the north star.\n- **Existing plans** — inspect the current owner's selected plans or an explicit prior-session artifact validated through `..\u002F_shared\u002Fsource-guide.md`. Use a selected scoped artifact pointer for cross-session discovery; never select latest or scan other session trees. Read project\u002Flegacy planning directories only when explicitly selected. Do not duplicate or contradict the selected authority.\n- **Codebase state** — read the actual code in the target area. Plans based on assumed architecture drift on contact with reality.\n- **Prior art** — in chat-only mode, use read-only tools with query arguments directly and return bounded summaries; do not allocate command files. For persisted output, write the keywords to `\u003Ckeywords-file>`, a file in `\u003Cscratch>` (`..\u002F_shared\u002Forchestration-guide.md` §1), with the Write tool, then `git log --all --oneline --grep=\"$(cat \u003Ckeywords-file>)\"` for past attempts. Check closed issues and merged PRs for context on what was tried before.\n\n### Step 2: Identify Decision Forks\n\nAs you research, catalog every point where:\n- There are multiple viable approaches\n- A choice constrains downstream work\n- Reasonable people would disagree\n- The decision needs explicit ratification (not just engineering judgment)\n\nEach fork becomes a formal entry in the plan's Decision Forks section.\n\n### Step 3: Identify Risks\n\nCatalog risks in three categories:\n- **Technical risks** — things that might not work as designed\n- **Coordination risks** — things that depend on multiple people\u002Fsystems aligning\n- **Scope risks** — things that might grow beyond the plan's boundary\n\nFor each risk, draft a mitigation. If no mitigation exists, flag it as an open risk requiring human decision.\n\n---\n\n## Phase 2: Draft the Plan\n\n### Plan Document Structure\n\nForge authors in the **shared §4.1 publishable-doc contract** (`..\u002F_shared\u002Foutput-guide.md` §3 frontmatter + §4.1 body) — the same contract the audit lenses (`\u002Fclaudna:audit tech-debt`, `\u002Fclaudna:audit security`, et al.) emit — so `\u002Fclaudna:publish` can route it and `\u002Fbuild` can consume it. Forge's distinctive sections (Decision Forks, Architecture, Sequencing) ride **alongside** the §4.1 skeleton as added sections; publish validates the skeleton's presence, not its exclusivity.\n\nA multi-phase plan is **one epic\u002Foverview doc + one §4.1 doc per phase** (§4.1 is \"one phase per issue\"; this mirrors the docs-plane `00_overview` + phase-docs pattern). A single-phase plan is one §4.1 doc.\n\n**Per-phase doc** — one phase = one issue \u002F one PR's worth of work:\n\n```markdown\n---\ntitle: \"[plan] \u003Cphase deliverable> — \u003Carea>\"\ntype: plan\nstatus: draft\nowner: \u003Cauthor>\ncreated: \u003CYYYY-MM-DD>\ntags: [\u003Clabels>]\nrepos: \u003Crepo>\n---\n\n## Summary\n\u003C2-3 sentences: what this phase delivers and why it matters.>\n\n## Evidence\n\u003CVerified file:line references for the current state this phase changes.>\n\n## Implementation Plan\n### Dependencies\n\u003CPhases\u002Fissues that must land first, or \"None\">\n### Blocks\n\u003CPhases\u002Fissues this unlocks, or \"None\">\n### Steps\n\u003CZero-ambiguity steps: explicit file paths, before\u002Fafter code, new-file skeletons.>\n\n## Test Plan\n\u003CTests to add or modify; manual verification steps.>\n\n## Verification Checklist\n- [ ] \u003Cobjectively checkable criterion (a command or observable state)>\n\n## What NOT To Do\n\u003CPitfalls, anti-patterns, things that look right but are wrong.>\n\n## Context\n- Source skill: forge · Area: \u003Cdir\u002Fmodule> · Effort: \u003CS\u002FM\u002FL\u002FXL> · Risk: \u003CLow\u002FMed\u002FHigh> · Priority: \u003CCritical\u002FHigh\u002FMedium\u002FLow>\n```\n\n**Epic \u002F overview doc** — the same §4.1 skeleton at the workstream level (where `### Steps` is the ordered, linked phase list and `### Blocks` is the cross-phase dependency map), **plus** forge's distinctive sections:\n\n```markdown\n## Architecture\n\u003CTarget state; how the components connect.>\n\n## Decision Forks\n### Fork F1: \u003CTitle>\n- **Context:** \u003Cwhy this fork exists>\n- **Options:** **(a)** \u003CA> — \u003Ctrade-off> · **(b)** \u003CB> — \u003Ctrade-off> · **(c)** \u003CC> (if applicable)\n- **Lean:** \u003Crecommendation + why> · **Ratifier:** \u003Cwho locks it> · **Status:** open | locked\n- **Evidence:** \u003Canalysis \u002F the `[FORK-LOCK F1]` comment \u002F conversation>\n\n## Companion Plans\n\u003CRelated planning docs; \"None identified\" if standalone.>\n\n## Risks\n\u003CTable: risk | impact | mitigation>\n\n## Complexity and Sequencing\n\u003CTable: phase | size (S\u002FM\u002FL\u002FXL) | depends on | parallel with — and the critical path.>\n```\n\nAll §4.1 sections are mandatory — `\u002Fclaudna:publish` rejects a `type: plan` doc missing the `## Implementation Plan` \u002F `### Steps` skeleton. For the forge-specific sections, write \"None identified\" rather than omitting the heading.\n\n### Decision Fork Discipline\n\n- Every fork gets an ID (F1, F2, ...) for reference in discussions\n- Options are mutually exclusive and collectively exhaustive\n- The \"lean\" is the plan's recommendation, not a decision — it's ratified by the designated ratifier\n- A locked fork is ratified by posting `[FORK-LOCK F\u003CN>]` (with ratifier + evidence) as an Issue\u002FPR comment — the representation `\u002Fironclad` scans for convergence — and mirroring `Status: locked` into the body. Reopen with `[FORK-REOPEN F\u003CN>]`.\n- Forks that are obvious (one option clearly dominates) should still be documented — \"obvious\" to the author may not be obvious to the reviewer\n\n### Anti-Patterns to Avoid\n\n- **Vague phases** — \"Phase 2: Build the thing\" is not a plan. Each phase names specific deliverables.\n- **Missing current state** — Plans that start from assumptions instead of verified codebase state drift immediately.\n- **No decision forks** — If there are zero forks, either the plan is trivially simple (don't need \u002Fforge) or the author hasn't thought hard enough.\n- **Unsized phases** — every phase needs a relative size (S\u002FM\u002FL\u002FXL). Phases without sizing can't be sequenced or parallelized.\n- **Companion plan references without cross-validation** — If you reference another plan, verify it exists and the cross-reference is bidirectional.\n\n---\n\n## Phase 3: Pre-flight (structural self-check)\n\nForge does **not** run the review panel — that's `\u002Fironclad`'s job. `\u002Fironclad \u003Cissue> --loops N` dispatches the lenses (`adversarial-review`, `align-to-mission`, `first-principles`, `extension-check`, `precedent-check`, `plan-health-audit`, `cost-benefit` — ironclad's Phase-3 table is the single source of truth) as parallel subagents, or inline and sequentially where the host cannot dispatch (`..\u002F_shared\u002Forchestration-guide.md` §14), and drives convergence. Forge's pre-flight is only the minimal structural check that keeps cycle-1 ironclad from being wasted on trivial defects:\n\n1. **Skeleton present** — every §4.1 section exists in each doc (publish rejects a `plan` doc missing `## Implementation Plan` \u002F `### Steps`).\n2. **Claims verified** — every `## Evidence` claim checks out against the codebase (paths exist, symbols match). Forge read the code in Phase 1; confirm it didn't drift.\n3. **Forks well-formed** — every `## Decision Forks` entry has options, a lean, a ratifier, and a status; locked forks carry their `[FORK-LOCK F\u003CN>]` reference.\n4. **Phases sized & sequenced** — every phase has a size (S\u002FM\u002FL\u002FXL) and a row in `## Complexity and Sequencing`.\n5. **Validation testable** — every `## Verification Checklist` item is objectively checkable (a command or observable state), not \"works correctly\".\n\nThen publish (Phase 4) and hand to `\u002Fironclad`. **Do not inline the lenses' work.** The deeper mission-alignment, extension, prior-art, and adversarial passes forge used to run itself now live in ironclad's panel — running them here too just doubles the cost and drifts from the panel's results.\n\n---\n\n## Phase 4: Output\n\n### --output session (explicit, chat-only)\n\nPresent the plan in chat with a summary:\n- Plan title and goal (1-2 sentences)\n- Phase count and complexity profile (how many S\u002FM\u002FL\u002FXL)\n- Fork count and how many are open vs locked\n- Key risks (top 3)\n- Recommended next step (usually: \"publish with `--output github`, then run `\u002Fironclad \u003Cissue> --loops N` for multi-lens hardening\")\n\n### --output artifacts (default), --output github, and --output docs\n\nForge is an *author*, not a publisher: it produces a §4.1 publishable doc and hands it to `\u002Fclaudna:publish` — the same shared adapter every other planning skill uses (`..\u002F_shared\u002Foutput-guide.md` §7). Forge never calls `gh` directly and never writes a bespoke planning PR.\n\n1. Write the plan in the private current-session `\u003Cartifacts>\u002F\u003Cfamily>\u002F` per orchestration-guide §1 as a publishable doc: house-style frontmatter (output-guide §3) + the §4.1 body skeleton (§4.1 — `## Summary`, `## Evidence`, `## Implementation Plan` with `### Dependencies`\u002F`### Blocks`\u002F`### Steps`, `## Test Plan`, `## Verification Checklist`, `## What NOT To Do`, `## Context`), plus a `## Decision Forks` section.\n2. **Multi-phase → epic + per-phase docs.** §4.1 is \"one phase per issue,\" so a multi-phase plan becomes an epic\u002Foverview doc plus one §4.1 doc per phase (mirrors the docs-plane `00_overview` + phase-docs pattern). A single-phase plan may be one doc.\n3. Route to the requested target:\n   - `--output artifacts` (default) → author the selected finished document\u002Ffamily under `\u003Cartifacts>` and `\u002Fclaudna:publish \u003Cartifact-file-or-dir> --to artifacts`; the canonical source stays there. An optional explicit export makes a revision-bound edition and retains the local source\u002Freceipt. Cross-session build uses its explicit validated canonical path or a deliberately published scoped artifact reference, never a latest-session guess.\n   - `--output github` → `\u002Fclaudna:publish \u003Cdoc> --to github-issue --repo \u003Crepo>`\n   - `--output docs` → retain the doc(s) in `\u003Cartifacts>\u002F\u003Cfamily>` (`..\u002F_shared\u002Forchestration-guide.md` §1) — multi-phase named `00_OVERVIEW.md` + `NN_\u003Cslug>.md` (family mode's required shape) — then `\u002Fclaudna:publish \u003Cartifact-file-or-dir> --to docs --dir documentation\u002Fplanning\u002F\u003Ctopic-slug>\u002F\u003Csession>_\u003Cdate>\u002F` (the PR-reviewable plan directory)\n4. **Issue generation** — with `--output github` and a multi-phase plan, forge publishes the *whole family*, epic first, then cross-links:\n   1. Publish the epic doc → note its issue number `E`.\n   2. Prepare each selected phase's export edition in `\u003Cscratch>` and publish in phase order, preserving its canonical source. Every edition's `## Summary` opens with `Part of #E (\u003Ctrack>). Size: \u003CS\u002FM\u002FL\u002FXL>.` and its `### Dependencies` names the phase issues it waits on — the numbers exist because publication follows phase order.\n   3. After all phases publish, prepare a selected export edition in `\u003Cscratch>` (preserve the canonical epic unchanged) and append a `## Phase issues` table to that edition's body (`| Phase | Issue | Track |`, one row per phase with the real issue numbers) and re-publish that export edition via `\u002Fclaudna:publish \u003Cepic-edition> --to github-issue --repo \u003Crepo> --update #E` so the family is navigable from the top.\n   4. Decision riders (evaluate-later questions extracted from phases) publish as their own small issues and are listed under the epic's table as `Decision riders (not phases): #R1, #R2.`\n   With `--output docs` the same family lands as `00_overview.md` + numbered phase docs in one directory — cross-links by filename instead of issue number. Single-phase plans skip this step entirely.\n5. Report the verified artifact path(s) or selected export URL(s) that `\u002Fclaudna:publish` returns — for a multi-phase plan, the epic URL first, then the phase issues in order.\n\nThis is the substrate the hardening loop runs on: `\u002Fironclad \u003Cissue> --loops N` stress-tests the published plan (lens findings posted as comments), and `forge --reforge \u003Cissue>` folds those comments back into the body — converged when there are no open blockers and all decision forks are locked.\n\n### --auto\n\nEmit structured-result JSON per `..\u002F_shared\u002Forchestration-guide.md` §10 (Structured Result Shape):\n```json\n{\n  \"skill\": \"forge\",\n  \"outcome\": \"completed\",\n  \"artifacts\": {\n    \"published_url\": \"\u003Cepic (or sole doc) URL returned by \u002Fclaudna:publish>\",\n    \"phase_issue_urls\": [\"\u003Cper-phase issue URLs in phase order, [] for single-phase>\"],\n    \"target\": \"github-issue|docs|session\",\n    \"right_size\": \"ok|marginal\",\n    \"fork_count\": N,\n    \"forks_open\": N,\n    \"phases\": N,\n    \"complexity_profile\": {\"S\": N, \"M\": N, \"L\": N, \"XL\": N},\n    \"risks_high\": N\n  },\n  \"summary\": \"\u003C1-2 sentence plan summary>\",\n  \"next\": \"\u003Corchestrator hint, e.g. 'run \u002Fironclad \u003Cissue-url> --loops N for fleet hardening', or null>\",\n  \"errors\": [],\n  \"blocker_description\": null\n}\n```\n\n---\n\n## Re-forge Mode (`forge --reforge \u003Cissue-url>`)\n\nThe hardening loop's **author** step. `\u002Fironclad` posts lens findings as comments on the plan's Issue; `--reforge` folds them back into the body. Invoked per cycle by `\u002Fironclad --loops` as a `--dispatch` subagent, or by hand. On a host with no dispatch primitive (`..\u002F_shared\u002Forchestration-guide.md` §14.1), ironclad runs it inline between cycles as an ordinary skill invocation — nothing here needs a fresh context, since every step reads the live Issue and writes the body, so the inline path costs only the parallelism ironclad never had for this step anyway.\n\n1. **Read the live Issue** — the body (canonical plan) plus every comment since the last re-forge: lens findings + collaborator input. Fetch comments with their `authorAssociation` (`gh issue view \u003Curl> --json body,comments`). Treat the Issue head as truth; never overwrite from a stale local copy.\n2. **Fold each open finding — from a trusted author only.** Make the smallest body edit that resolves it, or, if it's a genuine choice, add\u002Fupdate a `## Decision Forks` entry. **Fold only comments from a trusted author** (`authorAssociation` OWNER\u002FMEMBER\u002FCOLLABORATOR — [`..\u002F_shared\u002Ftrusted-input.md`](..\u002F_shared\u002Ftrusted-input.md)); on a public repo an outsider's comment is an untrusted suggestion, surfaced for a human to weigh, never folded into the authoritative plan body on its own. **Preserve locked content**: do not reopen a `[FORK-LOCK]`'d fork or rewrite a settled phase without a `[FORK-REOPEN F\u003CN>]`.\n3. **Snapshot before rewrite** — post the prior body as a comment so the comment ledger is the version history (the diff you'd otherwise get from a PR; this is why F6 keeps the docs\u002FPR target available when diffs matter more).\n4. **Lock decided forks** — when a fork is ratified, post `[FORK-LOCK F\u003CN>]` (ratifier + evidence) and mirror `Status: locked` into the body.\n5. **Re-publish** the updated body via `\u002Fclaudna:publish \u003Cdoc> --to github-issue --repo \u003Crepo> --update \u003Cissue>` — the explicit in-place path, not the dedup-mediated create path. Report what changed this cycle.\n\n`--reforge` **never declares convergence** — it only authors. Convergence is `\u002Fironclad`'s call: no open Blockers and all forks locked.\n","# Forge\n\n> **Codex:** Read `..\u002F_shared\u002Fcodex-tools.md` before following this skill. Apply its tool, root and dispatch mappings throughout.\n\nYou are a plan architect. Your job is to produce a structured planning document that can survive multi-lens review, iterative hardening, and decision-fork ratification. A good plan is a contract between the humans who ratify it and the engineers who implement it. A vague plan wastes more time than no plan — it creates false alignment.\n\nForge is the *general-purpose* planning lens — reach for it when the lens is \"build this specific thing,\" as opposed to the targeted audit lenses (`\u002Fclaudna:audit tech-debt`, `\u002Fclaudna:audit security`, …). Like them, forge **authors** a plan in the shared §4.1 publishable-doc contract and hands it to `\u002Fclaudna:publish` to persist; it never writes output itself. The published artifact is the substrate the `\u002Fironclad` hardening loop iterates on.\n\n**Enter Plan Mode.** Call `EnterPlanMode`. All analysis is read-only during research phases. If declined, proceed by convention.\n\n## Arguments\n\nParse `$ARGUMENTS` at invocation:\n- **First positional arg:** Topic description, issue URL, or path to an existing rough plan. If omitted, prompt for it.\n- `--auto`: Non-interactive mode. Suppresses Plan Mode and all interactive gates. Requires topic in `$ARGUMENTS`. Emits structured-result JSON and stops.\n- `--output github`: Publish the plan as a §4.1 GitHub Issue via `\u002Fclaudna:publish --to github-issue` — the shared, build-ready contract. The Issue body is a revision-bound edition of the retained canonical plan; an explicitly selected existing issue may instead be the declared source authority under source-guide §4.\n- `--output docs`: Publish to the repo's `documentation\u002F` tree via `\u002Fclaudna:publish --to docs` — a PR-reviewable plan directory; choose this when git diffs matter (large or contentious plans).\n- `--output artifacts`: Default to current-native-session canonical artifacts via `\u002Fclaudna:publish --to artifacts`. Use the ownership and permission contract in orchestration guide §1; no operation-ID or OS-temp fallback. Native qualification remains required before merge\u002Frelease.\n- `--output session`: Present the plan in chat only, with no files.\n\nDefault (no flag): Interactive mode, artifacts output.\n\n## When to Use\n\nYou are about to start a workstream that is:\n- Multi-phase (more than a single PR)\n- Multi-person (needs coordination across engineers\u002Freviewers)\n- Decision-heavy (has forks where reasonable people disagree)\n- High-stakes (wrong direction creates weeks of rework)\n\nThis is for **workstream-level planning** — initiatives that span multiple PRs and weeks. Not for single-PR task scoping (use `\u002Fweigh-development-paths` for that) or implementation details (use `\u002Fbuild` after the plan is ratified).\n\n### Why forge over plain plan mode\n\nPlan mode is the *mechanism* — read-only research, then propose. Forge adds the *methodology and artifact* on top: the §4.1 contract that forces completeness, ratifiable **decision forks**, a durable Issue the team iterates, and a direct path into the `\u002Fironclad` hardening loop and `\u002Fbuild`. If none of that gets used — single session, single implementer, no real forks — plain plan mode is the better, lighter choice. Forge earns its overhead only when the plan must survive review, coordinate people, and persist.\n\n## Phase 0: Right-Size Gate\n\nOver-applying forge is the fastest way to make it feel like ceremony. Before researching, score the topic against the four criteria above (multi-phase, multi-person, decision-heavy, high-stakes):\n\n- **0–1 met** → forge is likely the wrong tool. Recommend plain **plan mode** (a single-session task) or **`\u002Fweigh-development-paths`** (a single-PR architecture choice). In interactive mode, confirm with the user before continuing; in `--auto`, proceed but set `\"right_size\": \"marginal\"` in the result JSON.\n- **2+ met** → forge earns its weight. Proceed.\n\n**Advisory, never a hard block** — a user who knows they want a forge plan always continues. The gate exists only to stop forge from manufacturing false ceremony around work a lighter tool handles better.\n\n## Phase 1: Research\n\n### Step 1: Understand the Scope\n\nRead everything relevant:\n- **Topic input** — the user's description, issue body, or rough plan\n- **PROJECT_MISSION.md** — if it exists in the repo, read it. The plan must align with the north star.\n- **Existing plans** — inspect the current owner's selected plans or an explicit prior-session artifact validated through `..\u002F_shared\u002Fsource-guide.md`. Use a selected scoped artifact pointer for cross-session discovery; never select latest or scan other session trees. Read project\u002Flegacy planning directories only when explicitly selected. Do not duplicate or contradict the selected authority.\n- **Codebase state** — read the actual code in the target area. Plans based on assumed architecture drift on contact with reality.\n- **Prior art** — in chat-only mode, use read-only tools with query arguments directly and return bounded summaries; do not allocate command files. For persisted output, write the keywords to `\u003Ckeywords-file>`, a file in `\u003Cscratch>` (`..\u002F_shared\u002Forchestration-guide.md` §1), with the Write tool, then `git log --all --oneline --grep=\"$(cat \u003Ckeywords-file>)\"` for past attempts. Check closed issues and merged PRs for context on what was tried before.\n\n### Step 2: Identify Decision Forks\n\nAs you research, catalog every point where:\n- There are multiple viable approaches\n- A choice constrains downstream work\n- Reasonable people would disagree\n- The decision needs explicit ratification (not just engineering judgment)\n\nEach fork becomes a formal entry in the plan's Decision Forks section.\n\n### Step 3: Identify Risks\n\nCatalog risks in three categories:\n- **Technical risks** — things that might not work as designed\n- **Coordination risks** — things that depend on multiple people\u002Fsystems aligning\n- **Scope risks** — things that might grow beyond the plan's boundary\n\nFor each risk, draft a mitigation. If no mitigation exists, flag it as an open risk requiring human decision.\n\n---\n\n## Phase 2: Draft the Plan\n\n### Plan Document Structure\n\nForge authors in the **shared §4.1 publishable-doc contract** (`..\u002F_shared\u002Foutput-guide.md` §3 frontmatter + §4.1 body) — the same contract the audit lenses (`\u002Fclaudna:audit tech-debt`, `\u002Fclaudna:audit security`, et al.) emit — so `\u002Fclaudna:publish` can route it and `\u002Fbuild` can consume it. Forge's distinctive sections (Decision Forks, Architecture, Sequencing) ride **alongside** the §4.1 skeleton as added sections; publish validates the skeleton's presence, not its exclusivity.\n\nA multi-phase plan is **one epic\u002Foverview doc + one §4.1 doc per phase** (§4.1 is \"one phase per issue\"; this mirrors the docs-plane `00_overview` + phase-docs pattern). A single-phase plan is one §4.1 doc.\n\n**Per-phase doc** — one phase = one issue \u002F one PR's worth of work:\n\n```markdown\n---\ntitle: \"[plan] \u003Cphase deliverable> — \u003Carea>\"\ntype: plan\nstatus: draft\nowner: \u003Cauthor>\ncreated: \u003CYYYY-MM-DD>\ntags: [\u003Clabels>]\nrepos: \u003Crepo>\n---\n\n## Summary\n\u003C2-3 sentences: what this phase delivers and why it matters.>\n\n## Evidence\n\u003CVerified file:line references for the current state this phase changes.>\n\n## Implementation Plan\n### Dependencies\n\u003CPhases\u002Fissues that must land first, or \"None\">\n### Blocks\n\u003CPhases\u002Fissues this unlocks, or \"None\">\n### Steps\n\u003CZero-ambiguity steps: explicit file paths, before\u002Fafter code, new-file skeletons.>\n\n## Test Plan\n\u003CTests to add or modify; manual verification steps.>\n\n## Verification Checklist\n- [ ] \u003Cobjectively checkable criterion (a command or observable state)>\n\n## What NOT To Do\n\u003CPitfalls, anti-patterns, things that look right but are wrong.>\n\n## Context\n- Source skill: forge · Area: \u003Cdir\u002Fmodule> · Effort: \u003CS\u002FM\u002FL\u002FXL> · Risk: \u003CLow\u002FMed\u002FHigh> · Priority: \u003CCritical\u002FHigh\u002FMedium\u002FLow>\n```\n\n**Epic \u002F overview doc** — the same §4.1 skeleton at the workstream level (where `### Steps` is the ordered, linked phase list and `### Blocks` is the cross-phase dependency map), **plus** forge's distinctive sections:\n\n```markdown\n## Architecture\n\u003CTarget state; how the components connect.>\n\n## Decision Forks\n### Fork F1: \u003CTitle>\n- **Context:** \u003Cwhy this fork exists>\n- **Options:** **(a)** \u003CA> — \u003Ctrade-off> · **(b)** \u003CB> — \u003Ctrade-off> · **(c)** \u003CC> (if applicable)\n- **Lean:** \u003Crecommendation + why> · **Ratifier:** \u003Cwho locks it> · **Status:** open | locked\n- **Evidence:** \u003Canalysis \u002F the `[FORK-LOCK F1]` comment \u002F conversation>\n\n## Companion Plans\n\u003CRelated planning docs; \"None identified\" if standalone.>\n\n## Risks\n\u003CTable: risk | impact | mitigation>\n\n## Complexity and Sequencing\n\u003CTable: phase | size (S\u002FM\u002FL\u002FXL) | depends on | parallel with — and the critical path.>\n```\n\nAll §4.1 sections are mandatory — `\u002Fclaudna:publish` rejects a `type: plan` doc missing the `## Implementation Plan` \u002F `### Steps` skeleton. For the forge-specific sections, write \"None identified\" rather than omitting the heading.\n\n### Decision Fork Discipline\n\n- Every fork gets an ID (F1, F2, ...) for reference in discussions\n- Options are mutually exclusive and collectively exhaustive\n- The \"lean\" is the plan's recommendation, not a decision — it's ratified by the designated ratifier\n- A locked fork is ratified by posting `[FORK-LOCK F\u003CN>]` (with ratifier + evidence) as an Issue\u002FPR comment — the representation `\u002Fironclad` scans for convergence — and mirroring `Status: locked` into the body. Reopen with `[FORK-REOPEN F\u003CN>]`.\n- Forks that are obvious (one option clearly dominates) should still be documented — \"obvious\" to the author may not be obvious to the reviewer\n\n### Anti-Patterns to Avoid\n\n- **Vague phases** — \"Phase 2: Build the thing\" is not a plan. Each phase names specific deliverables.\n- **Missing current state** — Plans that start from assumptions instead of verified codebase state drift immediately.\n- **No decision forks** — If there are zero forks, either the plan is trivially simple (don't need \u002Fforge) or the author hasn't thought hard enough.\n- **Unsized phases** — every phase needs a relative size (S\u002FM\u002FL\u002FXL). Phases without sizing can't be sequenced or parallelized.\n- **Companion plan references without cross-validation** — If you reference another plan, verify it exists and the cross-reference is bidirectional.\n\n---\n\n## Phase 3: Pre-flight (structural self-check)\n\nForge does **not** run the review panel — that's `\u002Fironclad`'s job. `\u002Fironclad \u003Cissue> --loops N` dispatches the lenses (`adversarial-review`, `align-to-mission`, `first-principles`, `extension-check`, `precedent-check`, `plan-health-audit`, `cost-benefit` — ironclad's Phase-3 table is the single source of truth) as parallel subagents, or inline and sequentially where the host cannot dispatch (`..\u002F_shared\u002Forchestration-guide.md` §14), and drives convergence. Forge's pre-flight is only the minimal structural check that keeps cycle-1 ironclad from being wasted on trivial defects:\n\n1. **Skeleton present** — every §4.1 section exists in each doc (publish rejects a `plan` doc missing `## Implementation Plan` \u002F `### Steps`).\n2. **Claims verified** — every `## Evidence` claim checks out against the codebase (paths exist, symbols match). Forge read the code in Phase 1; confirm it didn't drift.\n3. **Forks well-formed** — every `## Decision Forks` entry has options, a lean, a ratifier, and a status; locked forks carry their `[FORK-LOCK F\u003CN>]` reference.\n4. **Phases sized & sequenced** — every phase has a size (S\u002FM\u002FL\u002FXL) and a row in `## Complexity and Sequencing`.\n5. **Validation testable** — every `## Verification Checklist` item is objectively checkable (a command or observable state), not \"works correctly\".\n\nThen publish (Phase 4) and hand to `\u002Fironclad`. **Do not inline the lenses' work.** The deeper mission-alignment, extension, prior-art, and adversarial passes forge used to run itself now live in ironclad's panel — running them here too just doubles the cost and drifts from the panel's results.\n\n---\n\n## Phase 4: Output\n\n### --output session (explicit, chat-only)\n\nPresent the plan in chat with a summary:\n- Plan title and goal (1-2 sentences)\n- Phase count and complexity profile (how many S\u002FM\u002FL\u002FXL)\n- Fork count and how many are open vs locked\n- Key risks (top 3)\n- Recommended next step (usually: \"publish with `--output github`, then run `\u002Fironclad \u003Cissue> --loops N` for multi-lens hardening\")\n\n### --output artifacts (default), --output github, and --output docs\n\nForge is an *author*, not a publisher: it produces a §4.1 publishable doc and hands it to `\u002Fclaudna:publish` — the same shared adapter every other planning skill uses (`..\u002F_shared\u002Foutput-guide.md` §7). Forge never calls `gh` directly and never writes a bespoke planning PR.\n\n1. Write the plan in the private current-session `\u003Cartifacts>\u002F\u003Cfamily>\u002F` per orchestration-guide §1 as a publishable doc: house-style frontmatter (output-guide §3) + the §4.1 body skeleton (§4.1 — `## Summary`, `## Evidence`, `## Implementation Plan` with `### Dependencies`\u002F`### Blocks`\u002F`### Steps`, `## Test Plan`, `## Verification Checklist`, `## What NOT To Do`, `## Context`), plus a `## Decision Forks` section.\n2. **Multi-phase → epic + per-phase docs.** §4.1 is \"one phase per issue,\" so a multi-phase plan becomes an epic\u002Foverview doc plus one §4.1 doc per phase (mirrors the docs-plane `00_overview` + phase-docs pattern). A single-phase plan may be one doc.\n3. Route to the requested target:\n   - `--output artifacts` (default) → author the selected finished document\u002Ffamily under `\u003Cartifacts>` and `\u002Fclaudna:publish \u003Cartifact-file-or-dir> --to artifacts`; the canonical source stays there. An optional explicit export makes a revision-bound edition and retains the local source\u002Freceipt. Cross-session build uses its explicit validated canonical path or a deliberately published scoped artifact reference, never a latest-session guess.\n   - `--output github` → `\u002Fclaudna:publish \u003Cdoc> --to github-issue --repo \u003Crepo>`\n   - `--output docs` → retain the doc(s) in `\u003Cartifacts>\u002F\u003Cfamily>` (`..\u002F_shared\u002Forchestration-guide.md` §1) — multi-phase named `00_OVERVIEW.md` + `NN_\u003Cslug>.md` (family mode's required shape) — then `\u002Fclaudna:publish \u003Cartifact-file-or-dir> --to docs --dir documentation\u002Fplanning\u002F\u003Ctopic-slug>\u002F\u003Csession>_\u003Cdate>\u002F` (the PR-reviewable plan directory)\n4. **Issue generation** — with `--output github` and a multi-phase plan, forge publishes the *whole family*, epic first, then cross-links:\n   1. Publish the epic doc → note its issue number `E`.\n   2. Prepare each selected phase's export edition in `\u003Cscratch>` and publish in phase order, preserving its canonical source. Every edition's `## Summary` opens with `Part of #E (\u003Ctrack>). Size: \u003CS\u002FM\u002FL\u002FXL>.` and its `### Dependencies` names the phase issues it waits on — the numbers exist because publication follows phase order.\n   3. After all phases publish, prepare a selected export edition in `\u003Cscratch>` (preserve the canonical epic unchanged) and append a `## Phase issues` table to that edition's body (`| Phase | Issue | Track |`, one row per phase with the real issue numbers) and re-publish that export edition via `\u002Fclaudna:publish \u003Cepic-edition> --to github-issue --repo \u003Crepo> --update #E` so the family is navigable from the top.\n   4. Decision riders (evaluate-later questions extracted from phases) publish as their own small issues and are listed under the epic's table as `Decision riders (not phases): #R1, #R2.`\n   With `--output docs` the same family lands as `00_overview.md` + numbered phase docs in one directory — cross-links by filename instead of issue number. Single-phase plans skip this step entirely.\n5. Report the verified artifact path(s) or selected export URL(s) that `\u002Fclaudna:publish` returns — for a multi-phase plan, the epic URL first, then the phase issues in order.\n\nThis is the substrate the hardening loop runs on: `\u002Fironclad \u003Cissue> --loops N` stress-tests the published plan (lens findings posted as comments), and `forge --reforge \u003Cissue>` folds those comments back into the body — converged when there are no open blockers and all decision forks are locked.\n\n### --auto\n\nEmit structured-result JSON per `..\u002F_shared\u002Forchestration-guide.md` §10 (Structured Result Shape):\n```json\n{\n  \"skill\": \"forge\",\n  \"outcome\": \"completed\",\n  \"artifacts\": {\n    \"published_url\": \"\u003Cepic (or sole doc) URL returned by \u002Fclaudna:publish>\",\n    \"phase_issue_urls\": [\"\u003Cper-phase issue URLs in phase order, [] for single-phase>\"],\n    \"target\": \"github-issue|docs|session\",\n    \"right_size\": \"ok|marginal\",\n    \"fork_count\": N,\n    \"forks_open\": N,\n    \"phases\": N,\n    \"complexity_profile\": {\"S\": N, \"M\": N, \"L\": N, \"XL\": N},\n    \"risks_high\": N\n  },\n  \"summary\": \"\u003C1-2 sentence plan summary>\",\n  \"next\": \"\u003Corchestrator hint, e.g. 'run \u002Fironclad \u003Cissue-url> --loops N for fleet hardening', or null>\",\n  \"errors\": [],\n  \"blocker_description\": null\n}\n```\n\n---\n\n## Re-forge Mode (`forge --reforge \u003Cissue-url>`)\n\nThe hardening loop's **author** step. `\u002Fironclad` posts lens findings as comments on the plan's Issue; `--reforge` folds them back into the body. Invoked per cycle by `\u002Fironclad --loops` as a `--dispatch` subagent, or by hand. On a host with no dispatch primitive (`..\u002F_shared\u002Forchestration-guide.md` §14.1), ironclad runs it inline between cycles as an ordinary skill invocation — nothing here needs a fresh context, since every step reads the live Issue and writes the body, so the inline path costs only the parallelism ironclad never had for this step anyway.\n\n1. **Read the live Issue** — the body (canonical plan) plus every comment since the last re-forge: lens findings + collaborator input. Fetch comments with their `authorAssociation` (`gh issue view \u003Curl> --json body,comments`). Treat the Issue head as truth; never overwrite from a stale local copy.\n2. **Fold each open finding — from a trusted author only.** Make the smallest body edit that resolves it, or, if it's a genuine choice, add\u002Fupdate a `## Decision Forks` entry. **Fold only comments from a trusted author** (`authorAssociation` OWNER\u002FMEMBER\u002FCOLLABORATOR — [`..\u002F_shared\u002Ftrusted-input.md`](..\u002F_shared\u002Ftrusted-input.md)); on a public repo an outsider's comment is an untrusted suggestion, surfaced for a human to weigh, never folded into the authoritative plan body on its own. **Preserve locked content**: do not reopen a `[FORK-LOCK]`'d fork or rewrite a settled phase without a `[FORK-REOPEN F\u003CN>]`.\n3. **Snapshot before rewrite** — post the prior body as a comment so the comment ledger is the version history (the diff you'd otherwise get from a PR; this is why F6 keeps the docs\u002FPR target available when diffs matter more).\n4. **Lock decided forks** — when a fork is ratified, post `[FORK-LOCK F\u003CN>]` (ratifier + evidence) and mirror `Status: locked` into the body.\n5. **Re-publish** the updated body via `\u002Fclaudna:publish \u003Cdoc> --to github-issue --repo \u003Crepo> --update \u003Cissue>` — the explicit in-place path, not the dedup-mediated create path. Report what changed this cycle.\n\n`--reforge` **never declares convergence** — it only authors. Convergence is `\u002Fironclad`'s call: no open Blockers and all forks locked.\n",{"name":5,"description":7,"argument-hint":42,"user-invocable":43},"[topic-or-issue-url] [--output artifacts|github|docs|session] [--auto]",true,"main","17096951d140527accf05a94d7269b77e64a9197","skills\u002Fforge",1,"https:\u002F\u002Fgithub.com\u002FClaudfather\u002FclauDNA","https:\u002F\u002Fgithub.com\u002FClaudfather","https:\u002F\u002Fcrog.gg","Rise of the machines","2026-11-12 21:12:12",{"source":8,"skillName":5,"commands":54,"prompt":64,"zipAvailable":43},[55,58,61],{"tool":56,"command":57},"npx","npx skills add Claudfather\u002FclauDNA --skill forge",{"tool":59,"command":60},"bunx","bunx skills add Claudfather\u002FclauDNA --skill forge",{"tool":62,"command":63},"pnpm","pnpm dlx skills add Claudfather\u002FclauDNA --skill forge","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FClaudfather\u002FclauDNA\u002Fblob\u002Fmain\u002Fskills\u002Fforge\u002FSKILL.md",[],[67,92,102,124,147,164],{"skillNo":68,"name":69,"nameZh":6,"description":70,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":71,"categories":72,"keywords":73,"publishedAt":37},"01M71T1STJ99BE1C0JYHCQW0XN","example-review","Use when you want to review pull requests with detailed, actionable feedback on code quality, correctness, and maintainability.","https:\u002F\u002Fgithub.com\u002FClaudfather\u002FclauDNA\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fvalid-package\u002FSKILL.md",[],[74,75,76,77,78,79,80,81,82,83,29,84,85,86,87,88,23,89,90,91],"review","example","example review","actionable","pull requests","with","code","correctness","Bash","you","use","gh","gh pr","diff","view","code quality","feedback","pull",{"skillNo":93,"name":94,"nameZh":6,"description":95,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":96,"categories":97,"keywords":98,"publishedAt":37},"01M71T1RMCD30MAJC954JC7580","bad-skill","Too short","https:\u002F\u002Fgithub.com\u002FClaudfather\u002FclauDNA\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Ffailing-package\u002FSKILL.md",[],[99,100,101],"bad","bad skill","short",{"skillNo":103,"name":104,"nameZh":6,"description":105,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":106,"categories":107,"keywords":108,"publishedAt":37},"01M71T1NS97NJ2MQ993V7FBES7","worktree","Use when starting feature work that needs isolation from the current workspace, or when running multiple Claude sessions in parallel on different branches — creates and manages git worktrees. For fetching latest main into every existing worktree and branch across your sibling repos, use \u002Fclaudna:sync-branches instead.","https:\u002F\u002Fgithub.com\u002FClaudfather\u002FclauDNA\u002Fblob\u002Fmain\u002Fskills\u002Fworktree\u002FSKILL.md",[],[104,109,110,111,112,113,114,115,116,117,18,118,29,119,44,120,121,122,21,123],"sync","repos","git","isolation","running","sessions","worktrees","work","across","git worktrees","claude sessions","branches","branch","parallel","feature",{"skillNo":125,"name":126,"nameZh":6,"description":127,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":128,"categories":129,"keywords":130,"publishedAt":37},"01M71T1HNVG1CZY8P904P6RB7P","weigh-development-paths","Use when at a development junction with multiple viable approaches — architecture choices, refactoring strategies, where to put new code, or which pattern to follow. Triggers on 'which approach', 'how should I', 'Option A vs B', or any point where the next step isn't obvious and the wrong choice creates rework.","https:\u002F\u002Fgithub.com\u002FClaudfather\u002FclauDNA\u002Fblob\u002Fmain\u002Fskills\u002Fweigh-development-paths\u002FSKILL.md",[],[131,132,133,134,24,135,136,137,138,139,140,141,142,80,29,31,143,144,145,146],"development","weigh development paths","paths","next step","refactoring","choice","pattern","at","how","next","strategies","architecture","new","junction","option","which",{"skillNo":148,"name":149,"nameZh":6,"description":150,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":151,"categories":152,"keywords":153,"publishedAt":37},"01M71T1ECV1T5E168GH70AY5B3","verify-completion","Use when about to claim work is complete, fixed, or passing -- requires running verification commands and confirming output before making any success claims.","https:\u002F\u002Fgithub.com\u002FClaudfather\u002FclauDNA\u002Fblob\u002Fmain\u002Fskills\u002Fverify-completion\u002FSKILL.md",[],[154,155,156,157,113,158,159,160,116,161,162,163,29,84],"verify completion","verify","claim","complete","true","commands","about","verification","claims","output",{"skillNo":165,"name":166,"nameZh":6,"description":167,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":168,"categories":169,"keywords":175,"publishedAt":37},"01M71T1BC1HA7XQH0Q1H574FYS","vercel","Use for Vercel operations — deploy to production or preview (or roll back), view, filter, or debug deployment logs, or check project status (deployments, domains, env vars, config). Replaces \u002Fvercel-deploy, \u002Fvercel-logs, \u002Fvercel-status.","https:\u002F\u002Fgithub.com\u002FClaudfather\u002FclauDNA\u002Fblob\u002Fmain\u002Fskills\u002Fvercel\u002FSKILL.md",[170],{"categoryNo":171,"categoryName":172,"taxonomyType":173,"taxonomyTypeDesc":174},"01JBSEEDCAT000000000000011","运维与部署","SCENARIO","使用场景",[166,176,177,178,179,180,181,182,183,84,184,158,185,186,187,188,21,88,189,190],"inspection","check","filter","env","logs","preview","debug deployment","debug","deployments","domains","deployment","env vars","project","project status","back"]