Implement logo

Implement

Community
yonatangross
implement

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.

Overview

Publisheryonatangross
Repositoryorchestkit
Skill nameimplement
Stars
298
Forks
35
Bundled files
33
LicenseMIT
Links
  • Markdown instructions

    A SKILL.md file the model loads on demand, so it only costs tokens when a request actually matches.

  • Works with any LLM

    AI skills are plain Markdown, not provider-specific code, so this works with GPT, Claude, Gemini, Grok, or a local model.

  • 33 bundled files

    Scripts, templates, and references the model can read while it works. Files are read-only and never executed.

  • Open source

    Published by yonatangross on GitHub. Read the source before you install it.

Installation

Install the Implement AI skill in TypingMind to use it with any LLM, or drop it into another agent that reads SKILL.md.

1

Install in TypingMind

TypingMind installs a skill straight from its GitHub folder — it reads SKILL.md, bundles the resource files, and stores the result locally.

  1. Open the app and go to Plugins → Skills.
  2. Choose "Install from GitHub".
  3. Paste the skill folder URL below and confirm.
    https://github.com/yonatangross/orchestkit/tree/main/plugins/ork/skills/implement
  4. Enable the skill in any chat where you want it available.
Plugins → Skills → Add skill → From GitHub URL, then paste the folder URL and press Continue.
2

Install in another agent

Any agent that reads the Agent Skills format can use this skill — copy the folder into that agent's skills directory.

Claude Code — .claude/skills
git clone --depth 1 https://github.com/yonatangross/orchestkit.git /tmp/orchestkit
mkdir -p .claude/skills
cp -r /tmp/orchestkit/plugins/ork/skills/implement .claude/skills/implement
Restart Claude Code after copying so it picks up the new skill.

Use it in TypingMind

Enable Implement in any TypingMind chat and the model takes it from there. Its name and description sit in the system prompt, and the moment a request matches, the model loads the full instructions itself — you never invoke it by hand, and it costs no tokens until it is actually used.

The model loads Implement on its own as soon as a request matches it.

Works with any AI model

AI skills are plain Markdown instructions rather than provider-specific code, so Implement is not tied to the model it was written for. Install it once in TypingMind and use it with GPT-5, Claude, Gemini, Grok, DeepSeek, Mistral, Llama, or a local model you run yourself — all on your own API keys.

  • Loaded only when it is needed

    The system prompt carries just the name and description. The instructions are fetched on the first matching request, so an idle skill costs nothing.

  • Switch models mid-chat

    Because the skill is instructions rather than code, changing model does not break it — the next model reads the same SKILL.md.

Skill instructions

This is the SKILL.md content the model loads. Read it before installing — a skill is instructions your model will follow.

Implement Feature

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.

Quick Start

bash
implement user authentication
implement --model=opus real-time notifications
implement dashboard analytics

Argument Resolution

Check the target first, before any other step. This skill forks and cannot see the conversation. Load Read("../../shared/rules/target-resolution.md"): if the target, flags stripped, is a bare pronoun or deictic (this, them, that one) or empty, return exactly TARGET_UNRESOLVED: <word> and stop. The caller resolves it and re-invokes.

python
FEATURE_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.


Step -1: MCP Probe + Resume Check

Run BEFORE any other step. Detect available MCP servers and check for resumable state.

python
# 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
}))

Batch Size Governance (large refactors)

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").

Budget Awareness (Opus 5.5 task budgets, public beta)

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:

python
# 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:

RemainingBehavior
> 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")


Step -0.5: Assess Verdict Gate

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):

  1. Fix blockers first (Recommended) — address the blockers, re-run assess, then return here.
  2. Override and implement — proceed anyway; record "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.


Step 0: Effort-Aware Phase Scaling (CC 2.1.76; 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 LevelPhases RunAgentsToken Budget
low1 (Discovery) → 5 (Implement) → 10 (Reflect)2 max~50K
medium1 → 2 → 5 → 7 (Scope Creep) → 103 max~150K
highAll 10 phases4-7~400K
xhigh (Opus 5, CC 2.1.111+)All 10 phases + one additional healing iteration on test failures before escalating4-7~550K

Override: Explicit user selection in Step 0 (e.g., "Plan first" or "Worktree") overrides /effort downscaling. If user requests full exploration, respect that regardless of effort level. low is right only for spec-complete, mechanical work, and a low run always hands off to /ork:verify at high: Read("references/effort-ladder.md").

Step 0a: Project Context Discovery

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")

Load project context. A fork skill never runs frontmatter hooks (#4683), so run the loader yourself and keep its additionalContext in mind:

bash
echo '{"tool_name":"Bash","tool_input":{}}' | node "${CLAUDE_PLUGIN_ROOT}/hooks/bin/run-hook.mjs" skill/project-convention-loader
echo '{"tool_name":"Bash","tool_input":{}}' | node "${CLAUDE_PLUGIN_ROOT}/hooks/bin/run-hook.mjs" skill/implement-standards-loader
git rev-parse HEAD  # note it as the start sha for the Phase 6 pattern check

Worktree Isolation (CC 2.1.49)

For features touching 5+ files, offer worktree isolation to prevent conflicts with the main working tree:

python
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:

python
# 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:

  1. Call EnterWorktree(name: "feat-{slug}") to create isolated branch
  2. All agents work in the worktree directory
  3. On completion, merge back: git checkout {original-branch} && git merge feat-{slug}
  4. If merge conflicts arise, present diff to user via AskUserQuestion

Load worktree details: Read("references/worktree-isolation-mode.md")


Step 0b: Blast-Radius Clarification (ask "what" before "how")

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.

Task Management (MANDATORY)

BEFORE doing ANYTHING else, create tasks to track progress:

python
# 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

Workflow (10 Phases)

PhaseActivitiesAgents
1. DiscoveryResearch best practices, Context7 docs, break into tasks—
2. Micro-PlanningDetailed plan per task (load references/micro-planning-guide.md)—
3. WorktreeIsolate in git worktree for 5+ file features (load references/worktree-workflow.md)—
4. Architecture4 parallel background agents (+ event-driven-architect when event/CQRS/queue-shaped)workflow-architect, backend-system-architect, frontend-ui-developer, llm-integrator
5. Implementation + TestsParallel agents, single-pass artifacts with mandatory testsbackend-system-architect, frontend-ui-developer, llm-integrator, test-generator
6. Integration VerificationCode review + real-service integration testsbackend, frontend, code-quality-reviewer, security-auditor
7. Scope CreepCompare planned vs actual (load references/scope-creep-detection.md)workflow-architect
8. E2E VerificationBrowser + API E2E testing (load references/e2e-verification.md)—
9. DocumentationSave decisions to memory graph—
10. ReflectionLessons learned, estimation accuracyworkflow-architect

Load agent prompts: Read("references/agent-phases.md")

Phase 6 pattern check. The fork cannot run the enforcer per Write/Edit (#4683); pipe each changed file into node "${CLAUDE_PLUGIN_ROOT}/hooks/bin/run-hook.mjs" skill/pattern-consistency-enforcer once, as Read("references/phase-6-pattern-check.md") shows.

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+).

Phase Handoffs (CC 2.1.71)

Write handoff JSON after major phases. See chain-patterns skill for schema.

After PhaseHandoff FileKey Outputs
1. Discovery01-discovery.jsonBest practices, library docs, task breakdown
2. Micro-Plan02-plan.jsonFile map, acceptance criteria per task
4. Architecture04-architecture.jsonDecisions, patterns chosen, agent results
5. Implementation05-implementation.jsonFiles created/modified, test results
7. Scope Creep07-scope.jsonPlanned vs actual, PR split recommendation

Progressive Output (CC 2.1.76+)

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 PhaseShow User
1. DiscoveryKey findings, library recommendations, task breakdown
4. ArchitectureEach agent's design decisions as they return
5. ImplementationFiles created/modified per agent, test results
7. Scope CreepPlanned 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_background task 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.

Monitor Tool for Background Streaming (CC 2.1.98)

Use Monitor to stream real-time events from background build/test scripts instead of polling output files:

python
# 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, isolation="worktree", ...)
# 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.

Worktree-Isolated Implementation

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.

Post-Deploy Monitoring (CC 2.1.71)

After final PR, schedule health monitoring:

python
# 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."
)

context7 with Detection

python
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 fallback

Issue Tracking

If working on a GitHub issue, run the Start Work ceremony from issue-progress-tracking and post progress comments after major phases.

Feedback Loop

Maintain checkpoints after each task. Load triggers: Read("references/feedback-loop.md")


Test Requirements Matrix

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")


Key Principles

  • Verification gate (terminal, mandatory) — before declaring ANY task done you MUST 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.
  • Agent status protocol — all subagents report DONE / DONE_WITH_CONCERNS / BLOCKED / NEEDS_CONTEXT per Read("../../shared/status-protocol.md")
  • Tests are NOT optional — each task includes its tests, matched to change type (see matrix above)
  • Parallel when independent — use run_in_background: true, launch all agents in ONE message
  • Output limits (CC 2.1.77+): the Opus tier defaults to 64k output tokens (128k upper bound). Generate complete artifacts in a single pass when possible; chunk across turns if output exceeds the limit
  • Micro-plan before implementing — scope boundaries, file list, acceptance criteria
  • Detect scope creep (phase 7) — score 0-10, split PR if significant
  • Real services when available — if docker-compose/testcontainers exist, use them in Phase 6
  • Reflect and capture lessons (phase 10) — persist to memory graph
  • Clean up agents — teammates wind down at turn end (CC 2.1.178+ implicit team); press Ctrl+F twice to stop lingering background agents. Note: /clear (CC 2.1.72+) preserves background agents
  • Exit worktrees — call ExitWorktree(action: "keep") in Phase 10 if worktree was entered in Step 0; never leave orphaned worktrees

Next Steps (suggest to user after implementation)

verify {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 gate

PushNotification on Completion (CC 2.1.110+)

implement 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.

python
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").

Agent Coordination

Dispatch envelope (CC 2.1.142+ flags — M146-6 / #1849)

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--effortRationale
Read-only analysis (Explore, code-quality-reviewer, debug-investigator)dontAsklowNo writes, no risk; minimise cost.
Test generation (test-generator)acceptEditsmediumWrites test files; permission prompts would block the parallel sweep.
Production code (frontend-ui-developer, backend-system-architect)default or acceptEditsmedium to highSet per-feature complexity. default keeps the user in the loop.
NeverbypassPermissions—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:

bash
claude -p --bare \
  --permission-mode dontAsk \
  --effort low \
  --max-turns 8 \
  "<prompt>"

Context Passing

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".

SendMessage (Active Coordination)

Cross-session replies land in the parent (CC 2.1.248): when a subagent sends SendMessage to 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-session SendMessage / ListAgents also 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:

python
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")

Skill Chain

After implementation completes, chain to verification:

python
TaskCreate(subject="Verify implementation", activeForm="Verifying changes")
TaskUpdate(taskId=verify_id, addBlockedBy=[impl_task_id])
# Then: verify {feature}

Quality Bar

Done means all of these hold:

  • every changed file verified per the terminal verification gate — never "should work"
  • each Phase 5 task ships its tests matched to change type; the suite ran green with the summary line cited
  • scope creep scored 0-10 in Phase 7; PR split when the delta is significant
  • worktrees entered in Step 0 are exited via ExitWorktree — no orphans

Related Skills

  • ork:explore: Explore codebase before implementing
  • ork:verify: Verify implementations work correctly
  • ork:issue-progress-tracking: Auto-updates GitHub issues with commit progress

References

Load on demand with Read("references/<file>"):

FileContent
agent-phases.mdAgent prompts and spawn templates
agent-teams-phases.mdAgent Teams mode phases
interview-mode.mdInterview/take-home constraints
blast-radius-clarification.mdStep 0b: ask-what-before-how blast-radius interview + decisions table
orchestration-modes.mdAgent tool vs Agent Teams selection
feedback-loop.mdCheckpoint triggers and actions
cc-enhancements.mdCC version-specific features
agent-teams-full-stack.mdFull-stack pipeline for teams
team-worktree-setup.mdTeam worktree configuration
micro-planning-guide.mdDetailed micro-planning guide
scope-creep-detection.mdPlanned vs actual comparison
worktree-workflow.mdGit worktree workflow
e2e-verification.mdBrowser + API E2E testing guide
worktree-isolation-mode.mdWorktree isolation details
tier-classification.mdTier classification, workflow mapping, orchestration mode
test-requirements-matrix.mdTest matrix by change type, real-service detection, phase 9 gate

Bundled files

The model reads these on demand while the skill is loaded. They are exposed as readable files and are never executed.

Frequently asked questions

What does the Implement AI skill do?

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.

Why use Implement on TypingMind?

Because you install it once and use it with any model. Implement is plain Markdown rather than provider-specific code, so the same skill runs on GPT-5, Claude, Gemini, Grok, or a local model — and you can switch model mid-chat without it breaking. TypingMind runs on your own API keys, so you pay providers directly instead of a per-seat subscription, and your skills and chats stay in your own storage.

How do I install Implement in TypingMind?

Open Plugins → Skills → Install from GitHub in TypingMind and paste https://github.com/yonatangross/orchestkit/tree/main/plugins/ork/skills/implement. TypingMind reads its SKILL.md and bundles its files and installs it as a skill you can enable per chat.

Which AI models can use Implement?

Any model you connect in TypingMind. AI skills are plain Markdown instructions rather than provider-specific code, so GPT, Claude, Gemini, Grok, and local models can all load this skill when a request matches it.

How many AI models can I use with Implement?

As many as you like. As long as a model supports skills, you can use Implement with it — GPT, Claude, Gemini, Grok, DeepSeek, Mistral, Llama and more — all on TypingMind with your own API keys.

Is the Implement AI skill free?

Yes. It is published on GitHub by yonatangross under the MIT license. You only pay your own AI provider for the tokens you use.

What are AI skills?

An AI skill is a reusable instruction bundle that teaches an AI model how to do one specific task. It follows the open Agent Skills format: a SKILL.md file with a name and description, plus any scripts, templates or reference files the model may need. The model reads the instructions only when your request matches the skill, so an installed skill costs nothing until it is used.

How are AI skills different from plugins or MCP servers?

A plugin or MCP server gives a model new tools to call — code that runs somewhere and returns a result. An AI skill gives the model knowledge and process instead: how to approach a task, which steps to follow, what good output looks like. Skills are plain Markdown, so they need no server, no API key and no runtime, and they work with any model.

View all

Set up your own AI workspace now

Get notified about new features and future giveaways by subscribing to our newsletter 👇