FOSS/AyuGramDesktop
1
0
Fork 0
mirror of https://github.com/AyuGram/AyuGramDesktop.git synced 2026-07-25 06:54:43 +00:00
Code Issues Packages Projects Releases Wiki Activity

[ai] Try using subagents in Codex.

Browse Source
This commit is contained in:
John Preston
2026-03-20 00:03:54 +07:00
parent 90eda7c03a
commit 0bc9ee3cf1
2 changed files with 242 additions and 265 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.agents/skills/task-think/SKILL.md
+39 -40
View File
@@ -1,6 +1,6 @@
---
name: task-think
description: Orchestrate a multi-phase implementation workflow for this repository with artifact files under .ai/<project-name>/<letter>/ and fresh codex exec child runs per phase. Use when the user wants one prompt to drive context gathering, planning, plan assessment, implementation, build verification, and review iterations while keeping the main session context clean.
description: Orchestrate a multi-phase implementation workflow for this repository with artifact files under .ai/<project-name>/<letter>/ using Codex subagents instead of shell-spawned child processes. Use when the user wants one prompt to drive context gathering, planning, plan assessment, implementation, build verification, and review with persistent artifacts and clear phase handoffs. Prefer spawn_agent/send_input/wait_agent; fall back to same-session execution only when delegation is unavailable or disallowed.
---
# Task Pipeline
@@ -15,14 +15,14 @@ Collect:
- optional constraints (files, architecture, risk tolerance)
- optional screenshot paths
If screenshots are attached in UI but not present as files, write a brief textual summary in `.ai/<project-name>/about.md` so child runs can consume the requirements.
If screenshots are attached in UI but not present as files, write a brief textual summary into the task artifacts before spawning fresh subagents so later phases can read the requirements without inheriting the whole parent thread.
## Overview
The workflow is organized around **projects**. Each project lives in `.ai/<project-name>/` and can contain multiple sequential **tasks** (labeled `a`, `b`, `c`, ... `z`).
The workflow is organized around projects. Each project lives in `.ai/<project-name>/` and can contain multiple sequential tasks (labeled `a`, `b`, `c`, ... `z`).
Project structure:
```
```text
.ai/<project-name>/
about.md # Single source of truth for the entire project
a/ # First task
@@ -31,16 +31,21 @@ Project structure:
review1.md # Code review documents (up to 3 iterations)
review2.md
review3.md
logs/
phase-*.prompt.md
phase-*.result.md
b/ # Follow-up task
context.md
plan.md
review1.md
logs/
...
c/ # Another follow-up task
...
```
- `about.md` is the project-level blueprint — a single comprehensive document describing what this project does and how it works, written as if everything is already fully implemented. It contains no temporal state ("current state", "pending changes", "not yet implemented"). It is **rewritten** (not appended to) each time a new task starts, incorporating the new task's changes as if they were always part of the design.
- Each task folder (`a/`, `b/`, ...) contains self-contained files for that task. The task's `context.md` carries all task-specific information: what specifically needs to change, the delta from the current codebase, gathered file references and code patterns. Planning, implementation, and review agents only read the current task's folder.
- `about.md` is the project-level blueprint: a single comprehensive document describing what this project does and how it works, written as if everything is already fully implemented. It contains no temporal state ("current state", "pending changes", "not yet implemented"). It is rewritten, not appended to, each time a new task starts, incorporating the new task's changes as if they were always part of the design.
- Each task folder (`a/`, `b/`, ...) contains self-contained files for that task. The task's `context.md` carries all task-specific information: what specifically needs to change, the delta from the current codebase, gathered file references, and code patterns. Planning, implementation, and review phases should rely on the current task folder.
## Artifacts
@@ -49,44 +54,38 @@ Create and maintain:
- `.ai/<project-name>/<letter>/context.md`
- `.ai/<project-name>/<letter>/plan.md`
- `.ai/<project-name>/<letter>/review<R>.md` (up to 3 review iterations)
- `.ai/<project-name>/<letter>/logs/phase-*.jsonl` (when running child `codex exec`)
- `.ai/<project-name>/<letter>/logs/phase-<name>.prompt.md`
- `.ai/<project-name>/<letter>/logs/phase-<name>.result.md`
Each `phase-<name>.result.md` should capture a concise outcome summary: whether the phase completed, which files it touched, and any follow-up notes or blockers.
## Phases
The workflow runs these phases sequentially via `codex exec --json` child sessions:
Run these phases sequentially:
1. **Phase 0: Setup** — Record start time, detect follow-up vs new project, create directories.
2. **Phase 1: Context Gathering** — Read codebase, write `about.md` and `context.md`. (Phase 1F for follow-ups.)
3. **Phase 2: Planning** — Read context, write detailed `plan.md` with numbered steps grouped into phases.
4. **Phase 3: Plan Assessment** — Review and refine the plan for correctness, completeness, code quality, and phase sizing.
5. **Phase 4: Implementation** — One child session per plan phase. Each implements only its assigned phase and updates `plan.md` status.
6. **Phase 5: Build Verification** — Build the project, fix any build errors. Skip if no source code was modified.
7. **Phase 6: Code Review Loop** — Up to 3 review-fix iterations:
- 6a: Review agent writes `review<R>.md` with verdict (APPROVED or NEEDS_CHANGES).
- 6b: Fix agent implements review changes and rebuilds.
- Loop until APPROVED or R > 3.
1. Phase 0: Setup - Record start time, detect follow-up vs new project, create directories.
2. Phase 1: Context Gathering - Read codebase, write `about.md` and `context.md`. Use Phase 1F for follow-up tasks.
3. Phase 2: Planning - Read context, write detailed `plan.md` with numbered steps grouped into phases.
4. Phase 3: Plan Assessment - Review and refine the plan for correctness, completeness, code quality, and phase sizing.
5. Phase 4: Implementation - Execute one implementation unit per plan phase.
6. Phase 5: Build Verification - Build the project, fix any build errors. Skip if no source code was modified.
7. Phase 6: Code Review Loop - Run review and fix iterations until approved or the iteration limit is reached.
Use the phase prompt templates in `PROMPTS.md`.
## Execution Mode
Run `codex exec --json` child sessions for each phase. Wait for each to finish before starting the next. After each phase, validate that the expected artifact file exists and has substantive content.
Use Codex subagents as the primary orchestration mechanism.
Every child session must use:
- `--model gpt-5.4`
- `-c model_reasoning_effort="xhigh"`
Do not pass long or complex phase prompts as a quoted command-line argument. Instead:
- Write the full phase prompt to a per-phase prompt file under `.ai/<project-name>/<letter>/logs/`
- Pipe that file into `codex exec` with `Get-Content -Raw <prompt-file> | codex exec ... -`
- Save the JSONL transcript to the matching `phase-*.jsonl` log file
When running inside Codex desktop on Windows, a child `codex exec` may fail inside the normal agent sandbox with `Access is denied` even though the command itself is valid. If that happens:
- Re-run the same `codex exec` invocation through an escalated shell tool call
- Do not treat the first sandboxed launch failure as a phase failure
- Fall back to direct main-session execution only if escalated child execution is unavailable or denied
Use the phase prompt templates and runner patterns in `PROMPTS.md`.
- Spawn a fresh subagent for context gathering, planning, plan assessment, each implementation phase, and each review or review-fix pass when delegation is available.
- Prefer `worker` for phases that write files. Use `explorer` only for narrow read-only questions that unblock your next local step.
- Keep `fork_context` off by default. Pass the phase prompt and explicit file paths instead of the whole thread unless the phase truly needs prior conversational context or thread-only attachments.
- When the platform supports it, request `model: gpt-5.4` and `reasoning_effort: xhigh` for spawned phase agents. If overrides are unavailable, inherit the current session settings.
- Write the exact phase prompt to the matching `logs/phase-<name>.prompt.md` file before you delegate. Use the same prompt file as a checklist if you later need to fall back to same-session execution.
- After a subagent finishes, verify that the expected artifacts or code changes exist, then write a short result log in `logs/phase-<name>.result.md`.
- Use `wait_agent` only when the next step is blocked on the result. While the delegated phase runs, do small non-overlapping local tasks such as validating directory structure or preparing the next prompt file.
- Build verification is critical-path work. Prefer running the build in the main session, and only delegate a bounded build-fix phase when there is a concrete reason.
- If subagents are unavailable in the current environment, or current policy does not allow delegation for this request, run the phase in the main session using the same prompt files. Never fall back to shell-spawned `codex exec` child processes from this skill.
## Verification Rules
@@ -107,19 +106,19 @@ Mark complete only when:
## Error Handling
- If any phase fails or gets stuck, report the issue to the user and ask how to proceed.
- If context.md or plan.md is not written properly by a phase, re-run that phase with more specific instructions.
- If any phase fails, times out, or gets stuck, inspect the partial artifacts, tighten the prompt, and retry with a fresh subagent or same-session fallback. Report the issue to the user if you remain blocked.
- If `context.md` or `plan.md` is not written properly by a phase, rerun that phase with more specific instructions.
- If build errors persist after the build phase's attempts, report the remaining errors to the user.
- If a review fix phase introduces new build errors that it cannot resolve, report to the user.
- If a review-fix phase introduces new build errors that it cannot resolve, report to the user.
## User Invocation
Use plain language with the skill name in the request, for example:
`Use local task-think skill: make sure FileLoadTask::process does not create or read QPixmap on background threads; use QImage with ARGB32_Premultiplied instead.`
`Use local task-think skill with subagents: make sure FileLoadTask::process does not create or read QPixmap on background threads; use QImage with ARGB32_Premultiplied instead.`
For follow-up tasks on an existing project:
`Use local task-think skill: my-project also handle the case where the file is already cached`
`Use local task-think skill with subagents: my-project also handle the case where the file is already cached`
If screenshots are relevant, include file paths in the same prompt.
If screenshots are relevant, include file paths in the same prompt when possible.