Vspawn
vlinx-io/VelaTerm
Explicitly spawn a standalone child session under the current vlx-term session, passing the task in as its first message (mirrors spawntask).
Full-power feature implementation using parallel subagents for backend, frontend, testing, and security, with worktree isolation and quality verification in one workflow.
$ npx skills add yonatangross/orchestkit --skill implement -a claude-codeProject install by default; add -g for ~/.claude/skills/.
$ gh skill install yonatangross/orchestkit implement --agent claude-codeProject scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).
$ git clone --depth 1 https://github.com/yonatangross/orchestkit.git skills-src && mkdir -p .claude/skills && cp -r skills-src/src/skills/implement .claude/skills/implement && rm -rf skills-srcUse ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.
Claude Code skills documentation · loads skills from .claude/skills/
Install the "implement" agent skill from https://github.com/yonatangross/orchestkit/tree/main/src/skills/implement into .claude/skills/implement/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "implement", then confirm the skill loads.Claude Code copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$skill-installer install https://github.com/yonatangross/orchestkit/tree/main/src/skills/implementType this inside Codex. $skill-installer <name> installs a curated skill from openai/skills. The installer writes to $CODEX_HOME/skills (default ~/.codex/skills). Restart Codex if the skill does not show up.
$ npx skills add yonatangross/orchestkit --skill implement -a codexProject install goes to .agents/skills/; add -g for ~/.codex/skills/.
$ gh skill install yonatangross/orchestkit implement --agent codexProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/yonatangross/orchestkit.git skills-src && mkdir -p .agents/skills && cp -r skills-src/src/skills/implement .agents/skills/implement && rm -rf skills-srcUse ~/.agents/skills/ instead of .agents/skills for a personal install.
Codex skills documentation · loads skills from .agents/skills/
Install the "implement" agent skill from https://github.com/yonatangross/orchestkit/tree/main/src/skills/implement into .agents/skills/implement/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "implement", then confirm the skill loads.Codex copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add yonatangross/orchestkit --skill implement -a cursorProject install goes to .agents/skills/; add -g for ~/.cursor/skills/.
$ gh skill install yonatangross/orchestkit implement --agent cursorProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/yonatangross/orchestkit.git skills-src && mkdir -p .cursor/skills && cp -r skills-src/src/skills/implement .cursor/skills/implement && rm -rf skills-srcUse ~/.cursor/skills/ instead of .cursor/skills for a personal install.
Cursor skills documentation · loads skills from .cursor/skills/, .agents/skills/, .claude/skills/, .codex/skills/
Install the "implement" agent skill from https://github.com/yonatangross/orchestkit/tree/main/src/skills/implement into .cursor/skills/implement/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "implement", then confirm the skill loads.Cursor copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gemini skills install https://github.com/yonatangross/orchestkit.git --path src/skills/implement--scope user (default) or --scope workspace; --path is the subfolder of the repo that holds the skill; --consent skips the security confirmation prompt.
$ npx skills add yonatangross/orchestkit --skill implement -a gemini-cliProject install goes to .agents/skills/; add -g for ~/.gemini/skills/.
$ gh skill install yonatangross/orchestkit implement --agent gemini-cliProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/yonatangross/orchestkit.git skills-src && mkdir -p .gemini/skills && cp -r skills-src/src/skills/implement .gemini/skills/implement && rm -rf skills-srcUse ~/.gemini/skills/ instead of .gemini/skills for a personal install, then run /skills reload.
Gemini CLI skills documentation · loads skills from .gemini/skills/, .agents/skills/
Install the "implement" agent skill from https://github.com/yonatangross/orchestkit/tree/main/src/skills/implement into .gemini/skills/implement/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "implement", then confirm the skill loads.Gemini CLI copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gh skill install yonatangross/orchestkit implementInstalls for Copilot at project scope by default; add --scope user for a personal install. Preview a skill first with gh skill preview. Needs GitHub CLI 2.90.0 or later (public preview).
$ npx skills add yonatangross/orchestkit --skill implement -a github-copilotProject install goes to .agents/skills/; add -g for ~/.copilot/skills/.
$ git clone --depth 1 https://github.com/yonatangross/orchestkit.git skills-src && mkdir -p .github/skills && cp -r skills-src/src/skills/implement .github/skills/implement && rm -rf skills-srcUse ~/.copilot/skills/ instead of .github/skills for a personal install. Commit .github/skills so cloud agent and code review can use it.
GitHub Copilot skills documentation · loads skills from .github/skills/, .claude/skills/, .agents/skills/
Install the "implement" agent skill from https://github.com/yonatangross/orchestkit/tree/main/src/skills/implement into .github/skills/implement/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "implement", then confirm the skill loads.GitHub Copilot copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add yonatangross/orchestkit --skill implement -a opencodeOpenCode documents no install command of its own. Project install goes to .agents/skills/; add -g for ~/.config/opencode/skills/.
$ gh skill install yonatangross/orchestkit implement --agent opencodeProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/yonatangross/orchestkit.git skills-src && mkdir -p .opencode/skills && cp -r skills-src/src/skills/implement .opencode/skills/implement && rm -rf skills-srcUse ~/.config/opencode/skills/ instead of .opencode/skills for a personal install.
OpenCode skills documentation · loads skills from .opencode/skills/, .claude/skills/, .agents/skills/
Install the "implement" agent skill from https://github.com/yonatangross/orchestkit/tree/main/src/skills/implement into .opencode/skills/implement/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "implement", then confirm the skill loads.OpenCode copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
implementFull-power feature implementation using parallel subagents for backend, frontend, testing, and security, with worktree isolation and quality verification in one workflow.
Implement is an agent skill from yonatangross/orchestkit. Full-power feature implementation using parallel subagents for backend, frontend, testing, and security, with worktree isolation and quality verification in one workflow. Chains with /ork:cover for tests and /ork:verify for validation. Use when asked to build, add, create, scaffold, or set up a new feature, endpoint, component, or UI capability. Not for fixing a bug, reviewing, explaining, testing, or comparing existing code.
Its SKILL.md is about 6.7k tokens, which your agent loads only when the skill is triggered. The skill folder holds 37 other files, including scripts, reference files and assets (for example `assets/micro-plan-template.md`, `assets/reflection-template.md` and `checklists/implementation-review.md`). Compatibility notes: Claude Code 2.1.277+. Requires memory MCP server, context7 MCP server, network access.
It sits in Agent Workflows, covering Git worktrees and Subagents. The repository describes itself as: The Complete AI Development Toolkit for Claude Code. 106 skills, 36 agents, 171 hooks. Install ork for stable (v9.x), or ork-alpha for the v10 line, which ships daily. The licence is MIT.
2 steps, taken from the first numbered list in SKILL.md.
Read from SKILL.md and the folder at commit 0ef71d2. It shows what the files ask for, not the result of running them.
Pre-approves these tools, so the agent can use them without asking each time:
SendMessageAskUserQuestionBashReadWriteEditGrepGlobAgentTaskCreate…and 13 more on the same allowed-tools line.
From allowed-tools in the SKILL.md frontmatter.
Ships 1 file in scripts/, which the agent can run.
Shell commands in SKILL.md call:
claudegitFrom the folder's file list and the shell code blocks in SKILL.md.
No URLs in SKILL.md. Its commands use git, which can reach the network depending on how they are called.
From URLs in SKILL.md, links to its own repository left out.
Names no API keys, tokens, secrets or passwords.
From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.
Claude Code 2.1.277+. Requires memory MCP server, context7 MCP server, network access.
From compatibility in the SKILL.md frontmatter.
Implement loads about 6.7k tokens when it runs, and up to ~27k if it reads all its reference files. Until then it costs about 110 tokens; SKILL.md has 2,095 words of instructions outside code blocks.
Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.
The automated check noted patterns worth knowing about, such as sudo or a known installer.
allowed-tools: SendMessage, AskUserQuestion, Bash, Read, Write, Edit, Grep, Glob, Agent, TaskCreate, TaskUpdate, TaAutomated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); the scripts in this folder are not scanned.
The full file from yonatangross/orchestkit at commit 0ef71d2, republished under its MIT licence (© yonatangross). 2,095 words, ~6,685 tokens.
.claude/skills/implement/SKILL.md (or your agent's skills folder). This skill also uses 34 other files; get the full folder from GitHub.Host-neutral workflow. Invoke by skill name (implement). Claude Code slash routing, YAML hook loaders, and .claude/chain live in references/claude-code.md.
Parallel subagent execution for feature implementation with scope control and reflection.
implement user authentication
implement --model=opus real-time notifications
implement dashboard analyticsFEATURE_DESC = "$ARGUMENTS" # Full argument string, e.g., "user authentication"
# $ARGUMENTS[0] is the first token, $ARGUMENTS[1] second, etc. (CC 2.1.59)
# Model override detection (CC 2.1.72)
MODEL_OVERRIDE = None
for token in "$ARGUMENTS".split():
if token.startswith("--model="):
MODEL_OVERRIDE = token.split("=", 1)[1] # "opus", "sonnet", "haiku", "fable"
FEATURE_DESC = FEATURE_DESC.replace(token, "").strip()Pass MODEL_OVERRIDE to all Agent() calls via model=MODEL_OVERRIDE when set. Accepts symbolic names (opus, sonnet, haiku, fable on harnesses whose Agent tool lists it; note fable is premium API spend after 2026-07-12) or full IDs (claude-opus-5-5) per CC 2.1.74.
Run BEFORE any other step. Detect available MCP servers and check for resumable state.
# Probe MCPs (parallel — all in ONE message):
# memory is alwaysLoad in .mcp.json (CC 2.1.121+, #1541) — probe below kept as fallback for older CC:
ToolSearch(query="select:mcp__memory__search_nodes")
ToolSearch(query="select:mcp__context7__resolve-library-id")
Write(".claude/chain/capabilities.json", JSON.stringify({
"memory": <true if found>,
"context7": <true if found>,
"timestamp": now()
}))
# Resume check:
Read(".claude/chain/state.json")
# If exists and skill == "implement":
# Read last handoff (e.g., 04-architecture.json)
# Skip to current_phase
# "Resuming from Phase {N} — architecture decided in previous session"
# If not: write initial state
Write(".claude/chain/state.json", JSON.stringify({
"skill": "implement", "feature": FEATURE_DESC,
"current_phase": 1, "completed_phases": [],
"capabilities": capabilities,
"budget_remaining_pct": 100 // advisory; see Budget Awareness below
}))For implementations touching >10 files, enforce max 5 files per agent batch, run tests between batches, commit green batches immediately, stop on red. Override via --batch-size N. Full rule: Read("rules/batch-governance.md").
Opus 5.5 exposes per-task token budgets. Until the CC side is GA, OrchestKit tracks an advisory budget_remaining_pct in state.json so long runs self-throttle. Update after each phase:
# At end of every phase, estimate remaining budget:
pct = tokensAsContextPct(tokensUsedSoFar) # from lib/context-window.ts
remaining = max(0, 100 - pct)
state["budget_remaining_pct"] = remaining
Write(".claude/chain/state.json", JSON.stringify(state))Thresholds influence behavior:
| Remaining | Behavior |
|---|---|
> 50% | Normal — all optional depth (devil's advocate, visual capture, deep exploration). |
20-50% | Efficient — skip optional depth; keep core phases. Warn user once. |
< 20% | Conservation — finish current phase, emit a handoff with next steps, do not start new work. |
When CC's native task-budget API ships GA, replace the estimate with the real signal; the thresholds and behavior stay the same.
Load:
Read("../chain-patterns/references/checkpoint-resume.md")
If .claude/chain/assess-verdict.json exists with a feature matching this run and verdict == "fail" (composite < the 5.5 min_pass in ../assess/rubric.json, or any dimension below its min_blocker), BLOCK Phase 1. Present each blockers[] entry (dimension, score, reason), then AskUserQuestion with plain label+description options (no preview):
assess, then return here."assess_gate": "overridden" in state.json and carry the blockers into Phase 1 context.Missing file or verdict == "pass" → no gate; continue to Step 0.
xhigh added in 2.1.111)Read the /effort setting to scale implementation depth. The effort-aware context budgeting hook detects effort level automatically — adapt the phase plan accordingly:
| Effort Level | Phases Run | Agents | Token Budget |
|---|---|---|---|
| low | 1 (Discovery) → 5 (Implement) → 10 (Reflect) | 2 max | ~50K |
| medium | 1 → 2 → 5 → 7 (Scope Creep) → 10 | 3 max | ~150K |
| high | All 10 phases | 4-7 | ~400K |
| xhigh (Opus 5, CC 2.1.111+) | All 10 phases + one additional healing iteration on test failures before escalating | 4-7 | ~550K |
Override: Explicit user selection in Step 0 (e.g., "Plan first" or "Worktree") overrides
/effortdownscaling. If user requests full exploration, respect that regardless of effort level.lowis right only for spec-complete, mechanical work, and a low run always hands off to/ork:verifyat high:Read("references/effort-ladder.md").
BEFORE any work, detect the project tier. This becomes the complexity ceiling for all patterns.
Scan codebase signals and classify into tiers 1-6 (Interview through Open Source). Each tier sets an architecture ceiling and determines which phases/agents to use.
Load tier details, workflow mapping, and orchestration mode: Read("references/tier-classification.md")
For features touching 5+ files, offer worktree isolation to prevent conflicts with the main working tree:
AskUserQuestion(questions=[{
"question": "Isolate this feature in a git worktree?",
"header": "Isolation",
"options": [
{"label": "Yes — worktree (Recommended)", "description": "Creates isolated branch via EnterWorktree, merges back on completion"},
{"label": "No — work in-place", "description": "Edit files directly in current branch"},
{"label": "Plan first", "description": "Research and design in plan mode before writing code"}
],
"multiSelect": false
}])If 'Plan first' selected:
# 1. Enter read-only plan mode
EnterPlanMode("Research and design: $ARGUMENTS")
# 2. Research phase — Read/Grep/Glob ONLY, no Write/Edit
# - Read existing code in the target area
# - Grep for related patterns, imports, dependencies
# - Check tests, configs, and integration points
# - If context7 available: query library docs
# 3. Design the plan — produce:
# - File map: which files to create/modify
# - Architecture decisions with rationale
# - Task breakdown with acceptance criteria
# - Risk assessment and edge cases
# 4. Exit plan mode — returns plan to user for approval
ExitPlanMode()
# 5. User reviews plan. If approved → continue to Phase 1 (Discovery)
# with the plan as input. If rejected → revise or stop.If worktree selected:
EnterWorktree(name: "feat-{slug}") to create isolated branchgit checkout {original-branch} && git merge feat-{slug}AskUserQuestionLoad worktree details: Read("references/worktree-isolation-mode.md")
Before Phase 1, resolve the unknowns whose answers would change the architecture, in blast-radius order — schema/migration → auth → API contract → perf/scale → cosmetics (last). Grep first, then AskUserQuestion one at a time (highest first, cap ~5, skip the obvious). Each answer becomes a row in a Decisions table written to .claude/chain/decisions.json and the PR body, feeding Phase 4 (Architecture) as constraints. Do NOT start Phase 1 with an unresolved schema/auth question; skip in low effort. Full protocol: Read("references/blast-radius-clarification.md").
Finish line. Done means: every planned file is written, the new and existing tests pass, the scope-creep check found nothing unplanned, and E2E verification ran. Follow Read("../../shared/rules/long-run-protocol.md"): keep going when a step needs no input from the user, stop and ask only when you can't continue without them or before anything destructive, check each subagent's evidence before accepting it, and mark anything you couldn't confirm with where you looked.
BEFORE doing ANYTHING else, create tasks to track progress:
# 1. Create main task IMMEDIATELY
TaskCreate(
subject="Implement: {feature}",
description="Feature implementation with parallel subagents",
activeForm="Implementing {feature}"
)
# 2. Create subtasks for each phase
TaskCreate(subject="Research best practices and docs", activeForm="Researching best practices") # id=2
TaskCreate(subject="Micro-plan: scope, files, criteria", activeForm="Micro-planning") # id=3
TaskCreate(subject="Architecture design (parallel agents)", activeForm="Designing architecture") # id=4
TaskCreate(subject="Implement and write tests", activeForm="Implementing code") # id=5
TaskCreate(subject="Integration verification", activeForm="Verifying integration") # id=6
TaskCreate(subject="Scope creep check", activeForm="Checking scope creep") # id=7
TaskCreate(subject="E2E verification", activeForm="Running E2E verification") # id=8
TaskCreate(subject="Document and reflect", activeForm="Documenting decisions") # id=9
# 3. Set dependencies for sequential phases
TaskUpdate(taskId="3", addBlockedBy=["2"]) # Plan needs research
TaskUpdate(taskId="4", addBlockedBy=["3"]) # Architecture needs plan
TaskUpdate(taskId="5", addBlockedBy=["4"]) # Implementation needs architecture
TaskUpdate(taskId="6", addBlockedBy=["5"]) # Integration needs implementation
TaskUpdate(taskId="7", addBlockedBy=["6"]) # Scope creep needs integration
TaskUpdate(taskId="8", addBlockedBy=["7"]) # E2E needs scope check
TaskUpdate(taskId="9", addBlockedBy=["8"]) # Docs need E2E
# 4. Update status as you progress
TaskUpdate(taskId="2", status="in_progress") # When starting
TaskUpdate(taskId="2", status="completed") # When done — repeat for each subtask| Phase | Activities | Agents |
|---|---|---|
| 1. Discovery | Research best practices, Context7 docs, break into tasks | — |
| 2. Micro-Planning | Detailed plan per task (load references/micro-planning-guide.md) | — |
| 3. Worktree | Isolate in git worktree for 5+ file features (load references/worktree-workflow.md) | — |
| 4. Architecture | 4 parallel background agents (+ event-driven-architect when event/CQRS/queue-shaped) | workflow-architect, backend-system-architect, frontend-ui-developer, llm-integrator |
| 5. Implementation + Tests | Parallel agents, single-pass artifacts with mandatory tests | backend-system-architect, frontend-ui-developer, llm-integrator, test-generator |
| 6. Integration Verification | Code review + real-service integration tests | backend, frontend, code-quality-reviewer, security-auditor |
| 7. Scope Creep | Compare planned vs actual (load references/scope-creep-detection.md) | workflow-architect |
| 8. E2E Verification | Browser + API E2E testing (load references/e2e-verification.md) | — |
| 9. Documentation | Save decisions to memory graph | — |
| 10. Reflection | Lessons learned, estimation accuracy | workflow-architect |
Load agent prompts: Read("references/agent-phases.md")
For Agent Teams mode: Read("references/agent-teams-phases.md")
Nested delegation (CC 2.1.172+): Phase 4-6 specialist agents MAY be instructed to delegate a bounded sub-problem to their own declared sub-agents (e.g. backend-system-architect → database-engineer for schema design) instead of doing everything inline. Keep chains ≤ 3 levels deep; when sub-tasks are independent, flatten to parallel dispatch from this orchestrator. See chain-patterns Pattern 9 (CC 2.1.172+).
Write handoff JSON after major phases. See chain-patterns skill for schema.
| After Phase | Handoff File | Key Outputs |
|---|---|---|
| 1. Discovery | 01-discovery.json | Best practices, library docs, task breakdown |
| 2. Micro-Plan | 02-plan.json | File map, acceptance criteria per task |
| 4. Architecture | 04-architecture.json | Decisions, patterns chosen, agent results |
| 5. Implementation | 05-implementation.json | Files created/modified, test results |
| 7. Scope Creep | 07-scope.json | Planned vs actual, PR split recommendation |
Output results incrementally after each phase — don't batch everything until the end.
Focus mode (CC 2.1.101): In focus mode (
/focus), the user only sees your final message. Include a self-contained summary with all key results — don't assume they saw incremental outputs.
| After Phase | Show User |
|---|---|
| 1. Discovery | Key findings, library recommendations, task breakdown |
| 4. Architecture | Each agent's design decisions as they return |
| 5. Implementation | Files created/modified per agent, test results |
| 7. Scope Creep | Planned vs actual delta, PR split recommendation |
When agents run with run_in_background=true, output each agent's findings as soon as it returns — don't wait for all agents to finish. This gives users ~60% faster perceived feedback and enables early intervention if an agent's approach diverges from the plan.
Teammate background tasks survive turn-end (CC 2.1.183): A
run_in_backgroundtask started by a teammate is no longer killed when that teammate finishes its turn. A parallel architecture/test teammate can launch a long build and let it outlive its own turn; the lead collects the result later. Pre-2.1.183 the lead had to own every background task to keep it alive.
Use Monitor to stream real-time events from background build/test scripts instead of polling output files:
# Start a long-running build in background
Bash(command="npm run build 2>&1", run_in_background=true)
# Stream its output line-by-line as notifications (no polling)
Monitor(pid=build_task_id)
# For background agents with test suites:
Agent(subagent_type="ork:test-generator", run_in_background=true, ...)
# Monitor agent progress via task notifications (CC 2.1.98 partial progress)Full pattern reference (when to use vs. TaskOutput, until-condition gates, partial-result salvage, anti-patterns): Read("../chain-patterns/references/monitor-patterns.md").
Partial results (CC 2.1.98): if a worktree-isolated agent crashes mid-implementation, salvage its partial output — git diff --name-only in its worktree, commit what's usable, flag incomplete items — instead of re-spawning; escalate a BLOCKED agent to the user. Full salvage logic: the monitor-patterns reference above.
Spawn parallel implementation agents with Agent(isolation="worktree"). The
subagent bypass of the worktree-isolation guard was fixed in CC 2.1.154 and
completed in 2.1.203; ork's floor is >= 2.1.220, so every supported session gets
real isolation. Full pattern, plus the 2.1.206 caveat that EnterWorktree
now prompts for confirmation on ork's out-of-tree ../<repo>-<task> convention:
Read("../chain-patterns/references/worktree-agent-pattern.md")
Historical (CC <= 2.1.153 only): the param thrashed the primary worktree's HEAD
and cut agents off at ~60 tool uses (Yonatan-HQ/platform#3224). The manual
pre-create workaround that fixed it is superseded and kept only as a record:
references/manual-worktree-pattern.md.
After final PR, schedule health monitoring:
# Guard: Skip cron in headless/CI (CLAUDE_CODE_DISABLE_CRON)
# if env CLAUDE_CODE_DISABLE_CRON is set, run a single check instead
CronCreate(
schedule="0 */6 * * *",
prompt="Health check for {feature} in PR #{pr}:
gh pr checks {pr} --repo {repo}.
If healthy 24h → CronDelete. If errors → alert."
)if capabilities.context7:
mcp__context7__resolve-library-id({ libraryName: "next-auth" })
mcp__context7__query-docs({ libraryId: "...", query: "..." })
else:
WebFetch("https://docs.example.com/api") # T1 fallbackIf working on a GitHub issue, run the Start Work ceremony from issue-progress-tracking and post progress comments after major phases.
Maintain checkpoints after each task. Load triggers: Read("references/feedback-loop.md")
Phase 5 test-generator MUST produce tests matching the change type. Each change type maps to specific required tests and testing rules.
Load test matrix, real-service detection, and phase 9 gate: Read("references/test-requirements-matrix.md")
Read("../../shared/rules/verification-gate.md") and satisfy EVERY check: every changed file verified, tests green, scope-creep scored. A partial pass is NOT done; "should work now" is not evidence.Read("../../shared/status-protocol.md")run_in_background: true, launch all agents in ONE messageCtrl+F twice to stop lingering background agents. Note: /clear (CC 2.1.72+) preserves background agentsExitWorktree(action: "keep") in Phase 10 if worktree was entered in Step 0; never leave orphaned worktreesverify {FEATURE} # Grade the implementation
cover {FEATURE} # Generate test suite
commit # Commit changes
/loop 10m npm test # Watch tests while iterating
/loop 30m verify {FEATURE} # Periodic quality gateimplement runs commonly take 10–30 min with parallel agents. At the final synthesis step, after the PR is opened and tests are green, call PushNotification — the user has almost certainly context-switched.
PushNotification(
message=f"ork:implement complete — {FEATURE}: {tests_passing}/{tests_total} tests · PR #{pr_num} opened · ready for verify",
status="proactive"
)Full rule (when to fire, body content limits, graceful fallback for users without Remote Control): load Read("../chain-patterns/rules/push-notification-on-completion.md").
When dispatching subagents — whether via the in-session Agent tool or a headless claude -p --bare from a wrapper script — set explicit --permission-mode and --effort per agent role so behaviour is deterministic across interactive vs CI runs:
| Agent role | --permission-mode | --effort | Rationale |
|---|---|---|---|
Read-only analysis (Explore, code-quality-reviewer, debug-investigator) | dontAsk | low | No writes, no risk; minimise cost. |
Test generation (test-generator) | acceptEdits | medium | Writes test files; permission prompts would block the parallel sweep. |
Production code (frontend-ui-developer, backend-system-architect) | default or acceptEdits | medium to high | Set per-feature complexity. default keeps the user in the loop. |
| Never | bypassPermissions | — | Skip the audit trail — only acceptable in throwaway sandboxes. |
In-session Agent tool calls inherit the parent session's permission mode; the table is the policy for what those defaults should be. For genuinely headless invocations (cron, CI), pass the flags explicitly to claude -p --bare:
claude -p --bare \
--permission-mode dontAsk \
--effort low \
--max-turns 8 \
"<prompt>"All spawned agents receive: changed files list, project tier, architectural constraints, and decisions from prior phases (discovery, plan). Pass via the agent prompt, not just "implement X".
Cross-session replies land in the parent (CC 2.1.248): when a subagent sends
SendMessageto another session, the reply is delivered to the parent session's conversation, never to the subagent; a subagent sends and moves on, the parent reads the answer. Cross-sessionSendMessage/ListAgentsalso work on Bedrock, Vertex and Foundry and with telemetry disabled (CC 2.1.248).
When backend and frontend agents need to align on API contracts:
SendMessage(to="frontend-ui-developer", message="API endpoint is POST /api/auth with {token, refreshToken} response shape")
SendMessage(to="test-generator", message="Backend uses JWT — mock auth middleware in test fixtures")After implementation completes, chain to verification:
TaskCreate(subject="Verify implementation", activeForm="Verifying changes")
TaskUpdate(taskId=verify_id, addBlockedBy=[impl_task_id])
# Then: verify {feature}Done means all of these hold:
ork:explore: Explore codebase before implementingork:verify: Verify implementations work correctlyork:issue-progress-tracking: Auto-updates GitHub issues with commit progressLoad on demand with Read("references/<file>"):
| File | Content |
|---|---|
agent-phases.md | Agent prompts and spawn templates |
agent-teams-phases.md | Agent Teams mode phases |
interview-mode.md | Interview/take-home constraints |
blast-radius-clarification.md | Step 0b: ask-what-before-how blast-radius interview + decisions table |
orchestration-modes.md | Agent tool vs Agent Teams selection |
feedback-loop.md | Checkpoint triggers and actions |
cc-enhancements.md | CC version-specific features |
agent-teams-full-stack.md | Full-stack pipeline for teams |
team-worktree-setup.md | Team worktree configuration |
micro-planning-guide.md | Detailed micro-planning guide |
scope-creep-detection.md | Planned vs actual comparison |
worktree-workflow.md | Git worktree workflow |
e2e-verification.md | Browser + API E2E testing guide |
worktree-isolation-mode.md | Worktree isolation details |
tier-classification.md | Tier classification, workflow mapping, orchestration mode |
test-requirements-matrix.md | Test matrix by change type, real-service detection, phase 9 gate |
© yonatangross, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file
SKILL.md and 34 other files (scripts, references, assets) in src/skills/implement of yonatangross/orchestkit.
Open the folder on GitHubat commit 0ef71d2
Implement next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.
| Skill | Stars | Used in | Tokens | Auto-check | Licence | Repo updated |
|---|---|---|---|---|---|---|
| Implement this skillyonatangross/orchestkit | 289 | — | ~6.7k | Automated safety check: Notes | MIT | |
| Vspawnvlinx-io/VelaTerm | 270 | — | ~2.5k | Automated safety check: Pass | MIT | |
| Spec-Driven Development v2LichAmnesia/lich-skills | 234 | — | ~3.1k | Automated safety check: Pass | MIT | |
| Subagent Coordinatorflyxl/datazen | 114 | — | ~908 | Automated safety check: Pass | GPL-3.0 | |
| PmApra-Labs/apra-fleet | 101 | — | ~5.4k | Automated safety check: Pass | Custom licence | |
| Batch Orchestrationrohitg00/pro-workflow | 2.9k | — | ~1.2k | Automated safety check: Pass | None |
vlinx-io/VelaTerm
Explicitly spawn a standalone child session under the current vlx-term session, passing the task in as its first message (mirrors spawntask).
LichAmnesia/lich-skills
Organizes long-running agent work into a Project, Sprint and Task hierarchy with per-task state files, isolated worktrees, review loops and script-checked rules.
flyxl/datazen
Orchestrate multi-track parallel feature development with subagents and git worktrees.
Apra-Labs/apra-fleet
Project Manager skill. An agent skill from Apra-Labs/apra-fleet.
rohitg00/pro-workflow
Decompose large-scale changes into independent units and spawn parallel agents in isolated worktrees.
kortix-ai/suna
Drive OpenAI's Codex CLI (codex exec) as a non-interactive coding sub-agent from inside Claude Code.
yonatangross/orchestkit
API contract design for REST and GraphQL, covering resource shape, URL and header versioning with deprecation windows, RFC 9457 Problem Details error handling, and OpenAPI specs.
yonatangross/orchestkit
ADR templates in the Nygard format with context, decision, consequences, and alternatives.
yonatangross/orchestkit
Single-pass codebase analysis leveraging a 1M-token context window for comprehensive security scanning, architecture review, and dependency auditing.
yonatangross/orchestkit
Structured review processes, conventional comments, language-specific checklists, and feedback templates.
yonatangross/orchestkit
Creates GitHub pull requests with pre-flight validation, conventional title formatting, and structured summary generation.
yonatangross/orchestkit
Multi-angle codebase exploration spawning 3-5 parallel agents for code structure, data flow, architecture patterns, and health assessment.
Categories
Full-power feature implementation using parallel subagents for backend, frontend, testing, and security, with worktree isolation and quality verification in one workflow. Implement is an agent skill from yonatangross/orchestkit. Full-power feature implementation using parallel subagents for backend, frontend, testing, and security, with worktree isolation and quality verification in one workflow.
Implement fits situations like: set up a new feature; tasks that involve Git worktrees; tasks that involve Subagents.
Run `npx skills add yonatangross/orchestkit --skill implement -a claude-code`. Or copy the skill folder (src/skills/implement in yonatangross/orchestkit) into .claude/skills/implement in your project. Claude Code loads it when a task matches its description.
Run `npx skills add yonatangross/orchestkit --skill implement -a codex`. Or copy the skill folder (src/skills/implement in yonatangross/orchestkit) into .agents/skills/implement in your project. Codex loads it when a task matches its description.
Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add yonatangross/orchestkit --skill implement -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/implement, .gemini/skills/implement, .github/skills/implement and .opencode/skills/implement in your project.
Going by SKILL.md and its folder, Implement needs the command-line tools its instructions call (claude and git). Our summary lists: Python 3. Its frontmatter pre-approves these tools: SendMessage, AskUserQuestion, Bash, Read, Write, Edit, Grep, Glob, Agent, TaskCreate, TaskUpdate, TaskStop, ToolSearch, WebFetch, EnterWorktree, ExitWorktree, CronCreate, CronDelete, Monitor, PushNotification, mcp__context7__resolve-library-id, mcp__context7__query-docs, mcp__memory__search_nodes. Compatibility (from SKILL.md): Claude Code 2.1.277+. Requires memory MCP server, context7 MCP server, network access..
SKILL.md contains no URLs. Its commands use git, which can reach the network depending on how they are called. This is read from the text; nothing was executed.
Our automated static check of SKILL.md found notes only (pre-approves every shell command (allowed-tools: bash)), nothing it rates as a warning. It is not a guarantee. The check reads SKILL.md only: the scripts in the folder are not scanned, so read them before running anything.
Implement is published under the MIT licence (declared in SKILL.md). It allows redistribution, so the full SKILL.md is shown on this page.
About 6.7k tokens (SKILL.md is roughly 27k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full. Its references folder adds about 20k tokens, read only when the agent opens those files.
Skills that share tags, products or a category with Implement: Vspawn (vlinx-io/VelaTerm, 270 stars), Spec-Driven Development v2 (LichAmnesia/lich-skills, 234 stars), Subagent Coordinator (flyxl/datazen, 114 stars) and Pm (Apra-Labs/apra-fleet, 101 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.
yonatangross (a GitHub user) maintains it in yonatangross/orchestkit, which has 289 GitHub stars. The repository holds 108 skills in this directory. The repository was last updated on October 7, 2026.
Source: yonatangross/orchestkit on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.