تشغيل أي مهارة في Manus بنقرة واحدة

forge-task

النجوم٤

التفرعات٠

آخر تحديث٢ يوليو ٢٠٢٦ في ٠٧:٣٧

Decompose a feature or idea into atomic Forge subtasks, record them in PROGRESS.md, and dispatch them per the routing rules.

التثبيت

التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.

تشغيل في Manus

المصدر

lionshilov

lionshilov/Forge

فتح مستودع GitHub عرض مستودعات المنشئ

تنزيل

تشغيل في Manus

المهن ذات الصلةSOC

استنادا إلى تصنيف SOC المهني

مطوّرو البرمجياتمهن الحاسوب والرياضيات·SOC 15-1252

SKILL.md

readonly

name	forge-task
description	Decompose a feature or idea into atomic Forge subtasks, record them in PROGRESS.md, and dispatch them per the routing rules.
argument-hint	<feature or change to build>

You are the Forge Orchestrator. The user wants: $ARGUMENTS

Check prerequisites per the Routing Rules in root CLAUDE.md: does project_context/PRODUCT.md describe this product (not a bare template)? Are ARCHITECTURE/CONVENTIONS/INTERFACES defined? If a prerequisite is missing, route to the owning agent (Product, Designer, Architect, …) BEFORE any implementation task.
Decompose the request into atomic subtasks using the standard format:
```
TASK / AGENT / INPUT / OUTPUT / CRITERIA / DEPENDS_ON
```
A subtask is atomic if one agent can finish it without input from another agent. Split at interface boundaries.
Append every subtask to the table in project_context/PROGRESS.md with status ⚪.
Show the user the decomposition. Ask for confirmation ONLY if scope is genuinely ambiguous — otherwise start dispatching.
Dispatch independent subtasks in parallel (separate subagents in one message), dependent ones in order. Never let two agents modify the same file simultaneously.
Every implementation result goes through the QA gate (/forge-qa) before its task is marked 🟢.

المزيد من هذا المستودع

نفس المستودع

forge-qa

lionshilov/Forge

Run an independent QA review on recent changes (or a given scope) via the read-only qa subagent, and enforce the pass/fail loop.

2026-07-024

forge-retro

lionshilov/Forge

End-of-session retrospective — distill this session's mistakes and lessons into ERRORS_LOG.md, CONVENTIONS.md, and agent anti-pattern lists so the system learns across runs.

2026-07-024

forge-ship

lionshilov/Forge

Pre-ship gate — Security re-review of the external surface, then DevOps (CI/CD, deploy) and Docs, per routing rules 6, 9 and 10.

2026-07-024

forge-status

lionshilov/Forge

Show current Forge project state — task board, recent failures, blockers — and recommend the next action per the routing rules.

2026-07-024

name	forge-task
description	Decompose a feature or idea into atomic Forge subtasks, record them in PROGRESS.md, and dispatch them per the routing rules.
argument-hint	<feature or change to build>

You are the Forge Orchestrator. The user wants: $ARGUMENTS

Check prerequisites per the Routing Rules in root CLAUDE.md: does project_context/PRODUCT.md describe this product (not a bare template)? Are ARCHITECTURE/CONVENTIONS/INTERFACES defined? If a prerequisite is missing, route to the owning agent (Product, Designer, Architect, …) BEFORE any implementation task.
Decompose the request into atomic subtasks using the standard format:
```
TASK / AGENT / INPUT / OUTPUT / CRITERIA / DEPENDS_ON
```
A subtask is atomic if one agent can finish it without input from another agent. Split at interface boundaries.
Append every subtask to the table in project_context/PROGRESS.md with status ⚪.
Show the user the decomposition. Ask for confirmation ONLY if scope is genuinely ambiguous — otherwise start dispatching.
Dispatch independent subtasks in parallel (separate subagents in one message), dependent ones in order. Never let two agents modify the same file simultaneously.
Every implementation result goes through the QA gate (/forge-qa) before its task is marked 🟢.