ultra-goal-heavy

Name: ultra-goal-heavy
Author: Azure99

31stars2forks

How to install ultra-goal-heavy?

azure99/ultra-goal/ultra-goal-heavy

$npx -y skills add Azure99/ultra-goal --skill ultra-goal-heavy

Installs into the current project.

Summary

Orchestrate complex engineering goals through multi-agent planning and cross-review. Manual invocation only. trigger only on an explicit request for this skill by name (e.g. "$ultra-goal-heavy").

Files · 1

View on GitHub

SKILL.md

1	# Ultra-Goal-Heavy Orchestrator
2
3	When this skill is active, you act as the Orchestrator Agent defined in the workflow below. The workflow is carefully designed — follow it as written, in order, without paraphrasing the steps away or skipping any of them.
4
5	Before starting this workflow, verify that the current working directory is inside a git repository. If it is not, stop immediately, clearly warn the user that Ultra-Goal requires a git repository because the workflow creates commits for accepted stages, and ask whether they want to initialize one before proceeding.
6
7	Everything below is the workflow. Follow it verbatim.
8
9	---
10
11	# Overall Goal
12
13	(Whatever the user has asked you to accomplish in this session — including any constraints or model choices they specified — is the Overall Goal.)
14
15	# Orchestrator Instructions
16
17	You are the Orchestrator Agent, responsible for coordinating the work of multiple sub-agents to ultimately achieve the Overall Goal.
18
19	- The agent workflow artifacts directory is `ultragoal/<goal-name>/` (choose a clear `goal-name` based on the Overall Goal). Put all artifacts that belong to this process but are not part of the final deliverable in this directory.
20	- Wherever `<goal-dir>` appears below, it refers specifically to `ultragoal/<goal-name>`; wherever `<stage-dir>` appears below, it refers specifically to `ultragoal/<goal-name>/<stage-name>`.
21	- By default, sub-agents use the same model as the Orchestrator Agent, unless the user explicitly specifies otherwise in the Overall Goal.
22	- Design a prompt for each sub-agent that passes in the context it needs for its work, such as: task requirements, the stage's objectives and information, relevant file paths, and so on.
23	- All reports lead with the conclusion and stay concise. Assume the context may be compacted or the session restarted at any time, and promptly persist important state to the workflow artifacts.
24	- Do not write code or documents on behalf of sub-agents yourself, unless you hit a serious blocker that requires temporarily taking over.
25	- Throughout the entire execution, do not ask the user anything. If an unresolvable blocker arises at some stage, write the cause, the approaches already attempted, and the scope of impact into `<stage-dir>/blocked.md`, then keep moving forward.
26
27	# Overall Process
28
29	## Goal Decomposition
30
31	First, centered on the Overall Goal, conduct lightweight exploration, then delegate to multiple sub-agents to carry out broad, in-depth, read-only exploration and research, each writing their findings into `<goal-dir>/exploration-*.md`. You combine the exploration reports to form a thorough understanding of the current state, then plan: list the identified stages, each stage's objectives and acceptance criteria, and write the initial roadmap into `<goal-dir>/roadmap.md`.
32
33	## Four Steps for Each Stage
34
35	### 1. Planning
36
37	Delegate to 2 new sub-agents and have them independently explore and devise plans, writing them into `<stage-dir>/plan-a.md` and `<stage-dir>/plan-b.md` respectively.
38
39	Once both plans are complete, organize a cross-review: have each sub-agent read the other's plan and offer feedback. You participate in the discussion as the lead reviewer; at the end of each round, you summarize the current disagreements and relay them to the sub-agents. The discussion runs for at most 3 rounds; if disagreements remain, you make the final ruling.
40
41	Then write your ruling into `<stage-dir>/planning-decision.md`, designate whichever of the two sub-agents is better suited to integrate the final plan, and have that sub-agent integrate both plans according to the ruling and write the final plan into `<stage-dir>/plan.md`.
42
43	### 2. Implementation
44
45	First read through `<stage-dir>/plan.md` yourself, then delegate to 1 sub-agent to complete the implementation according to the plan, perform careful self-testing, and write the change summary, self-test commands, and results into `<stage-dir>/implementation.md`.
46
47	### 3. Acceptance
48
49	Delegate to 2-3 new sub-agents to review the changes independently, including but not limited to: degree of completeness, omissions, newly introduced problems, and whether relevant documentation has been updated. Each writes their own report into `<stage-dir>/review-*.md`.
50
51	Then organize a cross-review: have each sub-agent read the others' reports and add confirmations, rebuttals, or corrections, writing their cross-review reports into `<stage-dir>/cross-review-*.md`.
52
53	As the lead reviewer, you merge everyone's input, filter out invalid and duplicate issues, and write the issue list into `<stage-dir>/issues.md`; each issue must include severity, evidence, recommended action, and whether it must be fixed. Severity is limited to: blocker/high/medium/low; blocker/hig

People who liked this also viewed

6 picks

Type

paperclip-create-agentCreate new agents in Paperclip with governance-aware hiring. Use when you need to inspect adapter configuration options, compare existing agent configs, draft a new agent prompt/config, and submit a hSkillsJul 2026157k5
subagent-driven-developmentUse when executing implementation plans with independent tasks in the current sessionSkillsJul 2026154k259k
dispatching-parallel-agentsUse when facing 2+ independent tasks that can be worked on without shared state or sequential dependenciesSkillsJul 2026143k259k
browser-act-skill-forgeForges reusable Skill packages (SKILL.md + scripts) from website exploration via browser-act — no re-exploration later. Use when: user wants a reusable Skill for any website, needs to understand a sitSkillsJul 202685k4.6k
wizardGenerate an interactive bash wizard that walks a human through a manual procedure — third-party setup, a one-off migration, an A→B state transition — opening URLs, capturing values, confirming each stSkillsJul 202675k182k
wonda-cliUsing the Wonda CLI to generate images, videos, music, and audio from the terminal — plus LinkedIn, Reddit, and X/Twitter research and automationSkillsJul 202666k137

ultra-goal-heavy

31stars2forks

View on GitHub

How to install ultra-goal-heavy?

azure99/ultra-goal/ultra-goal-heavy

$npx -y skills add Azure99/ultra-goal --skill ultra-goal-heavy

Installs into the current project.

Summary

Orchestrate complex engineering goals through multi-agent planning and cross-review. Manual invocation only. trigger only on an explicit request for this skill by name (e.g. "$ultra-goal-heavy").

Files · 1

View on GitHub

SKILL.md

1	# Ultra-Goal-Heavy Orchestrator
2
3	When this skill is active, you act as the Orchestrator Agent defined in the workflow below. The workflow is carefully designed — follow it as written, in order, without paraphrasing the steps away or skipping any of them.
4
5	Before starting this workflow, verify that the current working directory is inside a git repository. If it is not, stop immediately, clearly warn the user that Ultra-Goal requires a git repository because the workflow creates commits for accepted stages, and ask whether they want to initialize one before proceeding.
6
7	Everything below is the workflow. Follow it verbatim.
8
9	---
10
11	# Overall Goal
12
13	(Whatever the user has asked you to accomplish in this session — including any constraints or model choices they specified — is the Overall Goal.)
14
15	# Orchestrator Instructions
16
17	You are the Orchestrator Agent, responsible for coordinating the work of multiple sub-agents to ultimately achieve the Overall Goal.
18
19	- The agent workflow artifacts directory is `ultragoal/<goal-name>/` (choose a clear `goal-name` based on the Overall Goal). Put all artifacts that belong to this process but are not part of the final deliverable in this directory.
20	- Wherever `<goal-dir>` appears below, it refers specifically to `ultragoal/<goal-name>`; wherever `<stage-dir>` appears below, it refers specifically to `ultragoal/<goal-name>/<stage-name>`.
21	- By default, sub-agents use the same model as the Orchestrator Agent, unless the user explicitly specifies otherwise in the Overall Goal.
22	- Design a prompt for each sub-agent that passes in the context it needs for its work, such as: task requirements, the stage's objectives and information, relevant file paths, and so on.
23	- All reports lead with the conclusion and stay concise. Assume the context may be compacted or the session restarted at any time, and promptly persist important state to the workflow artifacts.
24	- Do not write code or documents on behalf of sub-agents yourself, unless you hit a serious blocker that requires temporarily taking over.
25	- Throughout the entire execution, do not ask the user anything. If an unresolvable blocker arises at some stage, write the cause, the approaches already attempted, and the scope of impact into `<stage-dir>/blocked.md`, then keep moving forward.
26
27	# Overall Process
28
29	## Goal Decomposition
30
31	First, centered on the Overall Goal, conduct lightweight exploration, then delegate to multiple sub-agents to carry out broad, in-depth, read-only exploration and research, each writing their findings into `<goal-dir>/exploration-*.md`. You combine the exploration reports to form a thorough understanding of the current state, then plan: list the identified stages, each stage's objectives and acceptance criteria, and write the initial roadmap into `<goal-dir>/roadmap.md`.
32
33	## Four Steps for Each Stage
34
35	### 1. Planning
36
37	Delegate to 2 new sub-agents and have them independently explore and devise plans, writing them into `<stage-dir>/plan-a.md` and `<stage-dir>/plan-b.md` respectively.
38
39	Once both plans are complete, organize a cross-review: have each sub-agent read the other's plan and offer feedback. You participate in the discussion as the lead reviewer; at the end of each round, you summarize the current disagreements and relay them to the sub-agents. The discussion runs for at most 3 rounds; if disagreements remain, you make the final ruling.
40
41	Then write your ruling into `<stage-dir>/planning-decision.md`, designate whichever of the two sub-agents is better suited to integrate the final plan, and have that sub-agent integrate both plans according to the ruling and write the final plan into `<stage-dir>/plan.md`.
42
43	### 2. Implementation
44
45	First read through `<stage-dir>/plan.md` yourself, then delegate to 1 sub-agent to complete the implementation according to the plan, perform careful self-testing, and write the change summary, self-test commands, and results into `<stage-dir>/implementation.md`.
46
47	### 3. Acceptance
48
49	Delegate to 2-3 new sub-agents to review the changes independently, including but not limited to: degree of completeness, omissions, newly introduced problems, and whether relevant documentation has been updated. Each writes their own report into `<stage-dir>/review-*.md`.
50
51	Then organize a cross-review: have each sub-agent read the others' reports and add confirmations, rebuttals, or corrections, writing their cross-review reports into `<stage-dir>/cross-review-*.md`.
52
53	As the lead reviewer, you merge everyone's input, filter out invalid and duplicate issues, and write the issue list into `<stage-dir>/issues.md`; each issue must include severity, evidence, recommended action, and whether it must be fixed. Severity is limited to: blocker/high/medium/low; blocker/hig

People who liked this also viewed

6 picks

Type