القائمة
Run the full hands-off engineering pipeline from planning through a green PR.
يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.
اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
يتجاوز الأمر المباشر Prompt المخصّص للمراجعة. افحص المصدر قبل تشغيله.
npx skills add https://github.com/nota-america/forgecat-agent-profiles --skill lfgيبقى الأمر في سطر واحد. مرّر أفقيًا لمراجعته كاملًا قبل النسخ.
تفضّل نسخة محلية؟ نزّل الملفات المتاحة حاليًا لدى SkillsMP.
AI(ChatGPT·Claude·Gemini 등)가 쓴 한글 텍스트를 "사람이 쓴 글처럼" 윤문해주는 오케스트레이터 스킬. 번역투·영어 인용 과다·기계적 병렬·관용구·피동태 남용·접속사 남발·리듬 균일성·이모지/불릿 과다 등 10대 카테고리 70개 AI 티 패턴을 탐지·분류해 내용은 한 글자도 건드리지 않고 문체·리듬·표현만 자연스러운 한국어로 재작성한다. shim의 route_hint(light|standard|heavy)로 경로를 정해 잘 쓴 글은 1콜, 표준은 2콜, 중증·장문만 3+콜(진단→겨냥 윤문→finalize)로 처리한다. 트리거 — "AI 티 없애줘", "AI 같은 글 자연스럽게", "GPT/ChatGPT 문체", "AI 번역투 고쳐", "사람이 쓴 것처럼 윤문", "AI 윤문", "ChatGPT 티 제거", "한글 AI 탐지·윤문", "AI 글 사람처럼", "번역투 제거", "영어 인용 많은 글 윤문", "AI 글 티 안 나게", "휴머나이저", "humanize Korean", "AI detector bypass 한글". 후속 작업 — "특정 카테고리만 다시", "윤문 강도 조정", "장르 바꿔서", "이 문단만", "2차 윤문" 도 모두 이 스킬. 단순 맞춤법·오탈자 교정은 직접 처리, 번역은 번역 스킬, 내용 추가·삭제를 동반한 재작성은 별도 집필 스킬.
가장 최근 윤문 결과를 2차로 다시 다듬는다 — 특정 카테고리·문단·강도 조정도 가능. humanize-korean strict 윤문(Phase B)을 기존 run_id에 재실행해 잔존 finding을 처리한다. 트리거 — "/humanize-redo".
AI가 쓴 한글 텍스트를 자연스럽게 윤문하는 진입 명령. humanize-korean 파이프라인을 Fast 모드(기본)로 실행하고 `--strict`면 정밀 3콜(진단→겨냥 윤문→finalize). 트리거 — "/humanize".
استنادا إلى تصنيف SOC المهني
عرض SKILL.md
| name | lfg |
| description | Run the full hands-off engineering pipeline from planning through a green PR. |
| disable-model-invocation | true |
| argument-hint | [feature description] |
CRITICAL: You MUST execute every step below IN ORDER. Do NOT skip any required step. Do NOT jump ahead to coding or implementation. The plan phase (step 1) MUST be completed and verified BEFORE any work begins. Violating this order produces bad output.
When invoking any skill referenced below, resolve its name against the available-skills list the host platform provides and use that exact entry. Some platforms list skills under a plugin namespace (e.g., compound-engineering:ce-plan); others list the bare name. Invoking a short-form guess that isn't in the list will fail — always match a listed entry verbatim before calling the Skill/Task tool.
Invoke the ce-plan skill with $ARGUMENTS.
GATE: STOP. If ce-plan reported the task is non-software and cannot be processed in pipeline mode, stop the pipeline and inform the user that LFG requires software tasks. Otherwise, verify that the ce-plan workflow produced a plan file in docs/plans/. If no plan file was created, invoke ce-plan again with $ARGUMENTS. Do NOT proceed to step 2 until a written plan exists. Record the plan file path — it will be passed to ce-work in step 2 and ce-code-review in step 4.
Read the plan metadata before continuing. If the plan has artifact_contract: ce-unified-plan/v1, proceed only when it has artifact_readiness: implementation-ready and execution: code. Stop the pipeline for artifact_readiness: requirements-only, any unrecognized readiness value, execution: knowledge-work, approach-plan outputs, answer-seeking/universal outputs, or invalid progress-like readiness values. LFG never launches /goal directly; when goal-mode or dynamic workflows are appropriate, ce-work owns that implementation engine choice and must return control to LFG afterward.
Invoke the ce-work skill with mode:return-to-caller <plan-path-from-step-1>.
GATE: STOP. Verify that implementation work was performed - files were created or modified beyond the plan. Read the structured return and require status: complete, the same plan path, changed files, U-IDs attempted/completed when present, verification results, blocker list, behavior-change signal, and standalone_shipping_skipped: true. Do NOT proceed to step 3 if no code changes were made or if ce-work did not return control in return-to-caller mode.
Invoke the ce-simplify-code skill on the branch diff.
This runs before review so the code-review in step 4 covers the simplified code. Skip this step when the change is docs-only (only markdown/docs paths changed) or trivial (roughly under 10 changed lines). Otherwise let ce-simplify-code resolve the branch-diff scope itself; it preserves behavior and runs the test suite.
Do not commit in this step. ce-simplify-code leaves its changes in the working tree; step 4's review scopes the working tree (uncommitted changes included), and step 8's ce-commit-push-pr commits whatever remains. Committing here would sweep any still-uncommitted ce-work edits into a misleading refactor commit and could stall on a tree that never goes clean.
Invoke the ce-code-review skill with mode:agent plan:<plan-path-from-step-1>.
Pass the plan file path from step 1 so ce-code-review can verify requirements completeness. Read the Actionable Findings summary the skill emits.
mode:agent is report-only by design — it surfaces findings but never edits the tree; LFG applies the eligible ones in step 5. When narrating progress to the user, frame this as "review found X → applied X in step 5," not as "code review did not auto-fix." A report-only review followed by an LFG-applied fix is the intended contract, not a gap.
Shipping precondition (steps 5–9). Run git remote once before the shipping steps. If it lists no remote (e.g. a sandbox/throwaway checkout that has git init but no origin), shipping is local-only: make every commit the steps below call for, but skip every push, PR create/edit, and CI-watch action — the pushes in steps 5 and 6, the push and PR creation in step 8, and step 9 in full. A missing remote is a terminal local-only state, not an error: never retry a push or hunt for a remote — make the local commits and proceed to step 10. Run steps 5–9 normally when a remote exists.
Apply and persist review fixes (REQUIRED after step 4, before residual handoff)
Load references/review-followup.md and execute its apply step (mechanical apply + commit/push when changes exist). Do not proceed to the residual handoff, run browser tests, or output DONE while eligible review fixes remain only in the working tree uncommitted.
Autonomous residual handoff (only when step 4 reported one or more actionable downstream-resolver findings not applied in step 5; skip when it reported Actionable findings: none.)
Do not prompt the user. This step embraces the autopilot contract: residuals must become durable before DONE, but the agent never stops to ask.
Load references/tracker-defer.md in non-interactive mode. Pass the residual actionable findings from step 4/5 (or the run artifact when the summary was truncated).
Collect the structured return: { filed: [...], failed: [...], no_sink: [...] }.
Compose a ## Residual Review Findings markdown section from the structured return:
filed: a bullet with severity, file:line, title, and a link to the tracker ticket URL.failed: a bullet with severity, file:line, title, and the failure reason (e.g., Defer failed: gh returned 401 — tracker unavailable).no_sink: a bullet with severity, file:line, and title inlined verbatim so the PR body or fallback file is the durable record.Detect the current branch's open PR without prompting:
gh pr view --json number,url,body,state
If an open PR exists, update it directly with gh; do not load any confirmation-driven PR update skill. Append or replace the ## Residual Review Findings section in the current PR body, write the new body to an OS temp file, then run:
gh pr edit PR_NUMBER --body-file BODY_FILE
If no open PR exists, create a tracked fallback file at docs/residual-review-findings/<branch-or-head-sha>.md containing the composed section and the source PR-review run context. Stage only that file, commit it with , and push the current branch (per the shipping precondition). If an upstream exists, run . If no upstream exists but a remote is configured, resolve a writable remote dynamically: prefer when present, otherwise use and choose the first configured remote. Then run . If there is no remote at all, do not push — the committed fallback file is the durable sink. This is the durable no-PR sink. Do not output DONE until the residual findings are durable: either the existing PR body has been updated, or this fallback file commit has been made (pushed when a remote exists, committed locally when none). A push that fails when a remote exists is a stop-and-report; never retry a push, or block DONE, when no remote exists.
Start with step 1 now. Remember: plan FIRST, then work. Never skip the plan.
docs(review): record residual review findingsgit pushorigingit remotegit push --set-upstream <remote> HEADNever block DONE on tracker filing failures once residuals have been durably recorded. A no_sink outcome is success only when the findings are present in the PR body or in the pushed fallback file.
Invoke the ce-test-browser skill with mode:pipeline.
Invoke the ce-commit-push-pr skill.
This commits any remaining changes, pushes the branch, and opens a pull request. If step 6 already opened a PR (check with gh pr view --json number,url,state 2>/dev/null), skip PR creation but still commit and push any uncommitted changes. Per the shipping precondition, when no remote is configured, do NOT invoke ce-commit-push-pr — its commit step pushes unconditionally (git push -u origin HEAD), so a literal invocation would still hit the impossible push. Instead commit any remaining changes locally yourself (git add -A && git commit) and skip the push and PR creation entirely.
CI watch and autofix loop (only when an open PR exists for the current branch)
Detect the PR; if none exists or gh is unavailable, skip this step entirely and proceed to step 10.
gh pr view --json number,url,state
For up to 3 fix iterations, repeat:
Wait for CI to complete:
gh pr checks --watch
If the command exits 0, all checks passed. Break out of the loop and proceed to step 10.
If it exits non-zero, one or more checks failed. Continue to (2).
Identify failing checks and pull their failure logs. Use gh pr checks --json name,state,conclusion,workflow,link to enumerate failures, then for each failing check read the run logs:
gh run view <run-id> --log-failed
where <run-id> is parsed from the check's details URL or workflow run.
Read the failure logs, identify the root cause, and apply a fix in the working tree. Do NOT weaken, skip, or mock the failing assertion to make it pass — repair the actual issue. If the failure is a flaky test that has no fix path, document that as the residual outcome below rather than retrying without a code change.
Stage only the files you changed, commit, and push:
git add <changed-files>
git commit -m "fix(ci): <one-line summary of the failure repaired>"
git push
Return to iteration (1) with the next attempt counter.
GATE: STOP iterating after 3 failed attempts. If CI is still red after 3 fix cycles:
Compose a ## CI Failures Unresolved markdown section listing each remaining failing check, the failure summary, and the run/check URL.
Append or replace this section in the PR body, write the new body to an OS temp file, then run:
gh pr edit PR_NUMBER --body-file BODY_FILE
Do NOT continue looping. The autopilot contract is "make residuals durable, then exit." Proceed to step 10.
Output <promise>DONE</promise> when complete