forge-codelisted

# Forge Code The coding step in the issue pipeline: `approved → developed`. Implements code, validates it locally (build + test), then pushes. An independent review step follows. When a plan exists (from forge-plan), this skill should be fast and focused — the plan already identified the files, the approach, and the patterns. Don't re-explore. Follow the plan, edit the files, test, commit. ## Usage ``` /forge-code <documentId> /forge-code <documentId1> <documentId2> ``` ## Tools `forge_issues`, `forge_comments`, `forge_coolify_deploy`, plus codebase tools (Read, Edit, Write, Glob, Grep, Bash). ## Deploy Mode Detection (do this FIRST, once per run) Before following the workflow below, call `forge_config → get` and `forge_coolify_deploy → list`. Decide **deployMode** for this project: - **local-only** — `previewDeploy` is null/missing OR has no `stagingUrl`, AND `forge_coolify_deploy → list` returns empty. Project builds only locally; no staging, no production deploy infrastructure. - **deploy** — Coolify resources are configured OR `previewDeploy.stagingUrl` is set. Deploy mode has two **topology** sub-modes — read `baseBranch` and `productionBranch` from that same `forge_config → get` call (never assume, never hardcode which one is "safe to merge to"): - **deploy · distinct-branch** (`baseBranch !== productionBranch`) — `baseBranch` is a non-production integration branch; merging there is safe for every complexity because it only reaches a pre-prod environment. -