메뉴
Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | parallel-agents |
| description | Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies. |
| available | coding |
When you have multiple unrelated failures (different test files, different subsystems, different bugs), investigating them sequentially wastes time. Each investigation is independent and can happen in parallel.
Core principle: Dispatch one agent per independent problem domain. Let them work concurrently.
digraph when_to_use {
"Multiple failures?" [shape=diamond];
"Are they independent?" [shape=diamond];
"Single agent investigates all" [shape=box];
"One agent per problem domain" [shape=box];
"Can they work in parallel?" [shape=diamond];
"Sequential agents" [shape=box];
"Parallel dispatch" [shape=box];
"Multiple failures?" -> "Are they independent?" [label="yes"];
"Are they independent?" -> "Single agent investigates all" [label="no - related"];
"Are they independent?" -> "Can they work in parallel?" [label="yes"];
"Can they work in parallel?" -> "Parallel dispatch" [label="yes"];
"Can they work in parallel?" -> "Sequential agents" [label="no - shared state"];
}
Use when:
Don't use when:
Group failures by what's broken:
Each domain is independent - fixing tool approval doesn't affect abort tests.
Each agent gets:
agent(action: "start", name: "fix-abort-tests", prompt: "Fix agent-tool-abort test failures")
agent(action: "start", name: "fix-batch-tests", prompt: "Fix batch-completion-behavior test failures")
agent(action: "start", name: "fix-race-tests", prompt: "Fix tool-approval-race-conditions test failures")
// All three run concurrently
When agents return:
Good agent prompts are:
Fix the 3 failing tests in src/agents/agent-tool-abort.test.ts:
1. "should abort tool with partial output capture" - expects 'interrupted at' in message
2. "should handle mixed completed and aborted tools" - fast tool aborted instead of
completed
3. "should properly track pendingToolCount" - expects 3 results but gets 0
These are timing/race condition issues. Your task:
1. Read the test file and understand what each test verifies
2. Identify root cause - timing issues or actual bugs?
3. Fix by:
- Replacing arbitrary timeouts with event-based waiting
- Fixing bugs in abort implementation if found
- Adjusting test expectations if testing changed behavior
Do NOT just increase timeouts - find the real issue.
Return: Summary of what you found and what you fixed.
Too broad: "Fix all the tests" - agent gets lost Specific: "Fix agent-tool-abort.test.ts" - focused scope
No context: "Fix the race condition" - agent doesn't know where Context: Paste the error messages and test names
No constraints: Agent might refactor everything Constraints: "Do NOT change production code" or "Fix tests only"
Vague output: "Fix it" - you don't know what changed Specific: "Return summary of root cause and changes"
Related failures: Fixing one might fix others - investigate together first Need full context: Understanding requires seeing entire system Exploratory debugging: You don't know what's broken yet Shared state: Agents would interfere (editing same files, using same resources)
Scenario: 6 test failures across 3 files after major refactoring
Failures:
Decision: Independent domains - abort logic separate from batch completion separate from race conditions
Dispatch:
Agent 1 -> Fix agent-tool-abort.test.ts
Agent 2 -> Fix batch-completion-behavior.test.ts
Agent 3 -> Fix tool-approval-race-conditions.test.ts
Results:
Integration: All fixes independent, no conflicts, full suite green
Time saved: 3 problems solved in parallel vs sequentially
After agents return:
From debugging session (2025-10-03):
SQLite migration rules for the Ghost codebase. MUST READ before writing or modifying any file in migrations/. Covers: table recreation patterns, column ordering, CHECK constraint changes, NOT NULL safety, and the validation checklist. A faulty migration that ships breaks the production daemon on startup with no recovery path short of manual DB surgery — these rules are non-negotiable.
Read when you need to browse, traverse, or query the knowledge system beyond basic knowledge_search — graph traversal, tag exploration, orphan detection, reference browsing, topic listing, or direct SQL access.
Import and update external content in the knowledge base — git repos, web crawls, documents (PDF, DOCX), and books (EPUB). Use when the OPERATOR wants persistent, searchable reference material from a git repository, website, document, or book, or when existing references may be stale and need refreshing.
Ghost's Lua scripting layer internals. MUST READ before modifying anything in src/scripting/, prompts/stdlib/, prompts/agents/*/agent.lua, or agent hook logic. Covers: ScriptHost VM lifecycle, sandbox, host globals, ctx bindings, nudge library, template module, custom tools, type stubs, and the PreTurnState contract.
Use when reading or changing GHOST configuration (providers, models, timing, compaction, services, any config.toml key), adding or switching LLM providers, answering questions about GHOST's own features or capabilities, a CLI tool is missing or "not found", services need starting/stopping/debugging, updating GHOST to a newer version, managing the Nix shell environment, or troubleshooting GHOST setup.
Triage and fix issues reported via Ghost's /feedback command. MUST READ when the user points you to a feedback folder, mentions a feedback report, or asks you to investigate a bug that happened during a GHOST session. Covers: retrieving feedback from remote servers, reading transcripts and debug request dumps, root-cause categorization, and the fix workflow.