You are familiar with the core skills: Coach, Workflow, Inspector. But one day you encounter a legacy project migration—no documentation, no tests, no blueprint. You realize that Coach and Workflow don't quite fit—they are designed for "building from scratch," not for "migrating a legacy project." What you need is Legacy Recon.
Among the 14 skills, the four most easily confused are Coach, Workflow, Orchestrator, and Job. They all perform "development," but at different levels of automation. Understanding their differences is the key to using the skill system correctly.
Coach is the most fundamental. It guides you through the six-step process, but every step requires your personal confirmation—the decomposition plan needs your approval, the inspection results need your judgment, and the branch decision needs your call. It is like a patient coach standing beside you, saying "do this first, then that, now check it." Its value lies in "process guidance," not "efficiency gains." When you are not yet familiar with the AI coding process, Coach is the best entry point.
Workflow is the automated version of Coach. It turns "steps that require human judgment" into "steps that judge by rules." Because the acceptance criteria are explicit, branch decisions can be automated. Because instructions are templated, you no longer have to write them by hand every time. Workflow collapses the "six-step process" into "a single command"—you say "fully implement this feature," and it automatically works through every step. When your requirements are clear and the technical approach is settled, Workflow is far more efficient than Coach.
Orchestrator manages multiple Workflows. When you need to work on several features at once, Orchestrator adds a layer of management on top of Workflow—it sequences feature development, manages dependencies, and ensures that cross-feature integration is correct.
Job sits at the highest level. It does not merely "build features"—it "builds the entire project," automating all seven stages from scaffolding to deployment configuration. Job invokes Requirements, Architect, Frontend Architect, Orchestrator, and Inspector in sequence.
Which one you choose depends on your level of need:
- Single feature + not yet familiar with the process → Coach
- Single feature + clear requirements → Workflow
- Multiple features → Orchestrator
- A complete project from scratch to deployment → Job
This selection logic can be drawn as a "beginner to expert" path: beginners use Coach → once familiar, use Workflow → for multiple projects, use Orchestrator → for repetitive projects, use Job. Each stage corresponds to a different degree of automation, and you can upgrade progressively as your experience grows.
8.2 Trigger Logic for Special-Scenario Skills
Beyond the four core process skills, there are five skills that address scenarios that are "not from scratch." Knowing when to use them is just as important as knowing when to use the core skills.
Code Cloner — when you need to implement a new feature by referencing existing code. Scenario: you have a feature whose implementation pattern is exactly the same as another feature in the project, only the business logic differs. Cloner lets you "implement that feature following this pattern" rather than writing from scratch. Its core method is analyzing the patterns in existing code and implementing new features in the same style and structure.
Legacy Reconnaissance (Legacy Recon) — when you need to migrate from a legacy system to a new one. Scenario: you take over a legacy project with no documentation, no tests, and no blueprint. Legacy Recon first scans the code, reconstructs the architecture, and distills a blueprint, and only then begins the transformation. Its advanced usage is "field-level comparison"—comparing the old and new system implementations field by field to ensure nothing is missed.
Project Handover (Next) — when you take over a half-finished project. Scenario: someone else has built half a project and handed it to you. Next first analyzes the current state, identifies unfinished work, and establishes context. Its advanced usage is to first assess the project's "code volume"—number of source files, lines of code, test coverage—and then decide whether to continue development or rebuild.
High-Fidelity Prototype (POC) — when you are unsure whether a solution is feasible. Scenario: you want to confirm the frontend effect before formal development. POC generates pure-frontend high-fidelity pages using mock data, with no backend involvement needed. POC can also serve as a "requirements confirmation tool"—letting stakeholders see a real interface before confirming requirements, thereby reducing requirement changes.
Quality Assurance (QA) — when the project needs comprehensive testing. Scenario: after the project is complete, systematic test coverage is required. QA is not "writing tests"—it is "designing a test strategy + generating test cases + executing tests + reporting results."
To summarize the trigger logic:
- Existing code can be reused → Cloner (don't write from scratch)
- A legacy system needs migration → Legacy Recon (don't design from scratch)
- Someone else's half-finished project → Next (don't re-understand everything)
- Unsure whether a solution is feasible → POC (validate first, then develop)
- The project needs comprehensive testing → QA (don't rely on manual testing alone)
8.3 Advanced Usage of Other Skills
The advanced usage and best practices of the following skills are provided for reference as needed.
Requirements Analysis (Requirements)
Design principle: The underlying method of the Requirements skill is Event Storming—a technique for understanding a business through "events." Rather than first discussing "what features the system has," it discusses "what events occur in the business."
The benefit of this approach is that business people do not need to understand technology to participate. They only need to describe "what happened," and the technical team derives the data model and system structure from the events.
Advanced usage:
Usage 1: Divergence-driven. Not all requirements can be aligned in one pass. When divergences arise during requirements analysis, do not try to resolve them immediately—record them instead. The divergence itself exposes ambiguities in the requirements, and if these ambiguities remain unresolved, they will cause rework later in development.
Usage 2: Scenario enumeration. For complex features, enumerating every possible scenario is more effective than an abstract description. Take an order-cancellation feature: listing the four scenarios "cancel immediately after ordering," "cancel after payment," "cancel after shipment," and "cancel after receipt" is far clearer than a single phrase like "support order cancellation."
Best practices: The output of requirements analysis is not merely a feature list—more importantly, it is a record of divergences and an enumeration of scenarios. Let the AI play the role of a "demanding questioner," relentlessly probing edge cases. Do not pursue "one-time alignment"; accept "progressive convergence."
Architecture Design (Architect)
Design principle: The core idea of architecture design is "no blueprint, no coding." But a blueprint is not fixed—it needs to be updated as the project advances.
Advanced usage:
Usage 1: Bidirectional reasoning. For projects with existing code, begin with bottom-up analysis—scan files, identify patterns, abstract the structure—then adjust and optimize top-down.
Usage 2: ADR-driven. Significant architecture decisions are recorded in ADRs. The value of an ADR is not "recording the decision," but "recording the reasons and context behind the decision." A good ADR enables future developers to understand: why A was chosen over B, what factors were considered at the time, and what was given up.
Best practices: Glossary before data model—align terminology before discussing table structure. Skeleton first—produce a complete skeleton, then fill in the details. Every design decision needs a "why"—do not let the AI choose by default; have it explain the reason for its choice.
Process Coach (Coach)
Design principle: Coach is "guiding"—it does not make decisions for the user, but guides the user to make decisions for themselves. Its core value is cultivating habits, not completing tasks.
Advanced Usage
Usage 1: Habit formation. Coach's primary role is not "helping you complete this feature"—it is "helping you build the right coding habits."
- Before each start, it reminds you to check the blueprint
- After each completion, it reminds you to inspect
- When inspection fails, it guides you in deciding whether to fix or rebuild
Usage 2: Gradual letting go. As the user becomes familiar with the process, Coach can progressively reduce its guidance:
- The first time: explain every step in detail
- The fifth time: only prompt at key milestones
- The tenth time: only alert when it detects anomalies
Best Practices
- Coach suits beginners and complex scenarios, not developers already familiar with the process
- Trigger Coach when the user says "start development," but trigger Workflow when the user says "fully implement"
Automated Workflow (Workflow)
Design Principle
Workflow's core is the "three-step iteration loop": issue instructions → inspect → branch decision. It leaves "decomposition" and "blueprint updates" to higher-level skills (Orchestrator or Job), focusing on automation at the execution layer.
Advanced Usage
Usage 1: Context reset strategy. Workflow must manage context resets in long processes. The key strategy:
- After each milestone, record the current state to a file
- Reset the context and clear the conversation history
- In the new context, load the blueprint + the current milestone's instructions
- Continue execution
Why is a reset needed? An AI's conversational context is limited. Once a conversation grows long, the AI's retention of early agreements degrades noticeably. Resetting the context is like letting the AI "take a breath and refocus." ("Significant degradation beyond roughly 100 turns" is an indicative empirical value; the actual inflection point varies by model and task.)
Usage 2: The evolution of acceptance criteria. Acceptance criteria are not set in stone. As a project progresses, they should become stricter:
- Early milestones: primarily check functional completeness
- Mid milestones: add architecture-compliance checks
- Late milestones: add security reviews and performance checks
Best Practices
- Use auto mode when requirements are clear, normal mode when they are vague
- Define acceptance criteria when issuing instructions, not after coding is done
- After a context reset, confirm that the AI has correctly loaded the blueprint before continuing
Inspector (Inspector)
Design Principle
Inspector's core is "comparison"—comparing AI-generated code against the blueprint to identify discrepancies. It does not judge whether the code is "good" or "bad"; it only judges whether the code "conforms to the blueprint."
Advanced Usage
Usage 1: Three-dimensional detection of architecture drift. Inspector detects architecture drift along three dimensions:
- What files were modified? Unexpected modification of core files → tampering with the foundation
- How much code was added? An individual file over-inflated → loss of size control
- What dependencies were added? Unnecessary dependencies → over-engineering
Usage 2: Automating security review. Inspector can integrate security review rules:
- Check that parameterized queries are used (preventing SQL injection)
- Check that user input is escaped (preventing XSS)
- Check that sensitive endpoints have access control
- Check that fields that should not be exposed are not returned
Best Practices
- Define acceptance criteria before coding begins, rather than improvising them afterward
- A structured inspection-report template (function/code/architecture/security) improves the completeness of the check
- When architecture drift is found, prioritize REBUILD over NEEDS_FIX—fixing the foundation is riskier than continuing to build on a crooked one
Project Orchestrator (Orchestrator)
Design Principle
Orchestrator's design philosophy is "divide and conquer"—breaking a large project into small features, completing each feature independently, and then ensuring the overall correctness through integration inspection.
Advanced Usage
Usage 1: Parallel execution. When multiple features have no dependencies, Orchestrator can schedule them in parallel:
Phase 1: Foundation (serial, has dependencies)
1.1 Project init → 1.2 Database → 1.3 User authentication
Phase 2: Core features (parallelizable, no dependencies)
2.1 Order list ─┐
2.2 Create order ─┤ ← these features can run in parallel
2.3 User management ─┘
2.4 Product management ─┘
The core constraint of parallel execution: each feature executes in an independent context to avoid shared-state conflicts.
Usage 2: Incremental development. Orchestrator supports incremental development—when a project is already partially complete and merely needs new features added:
- Read the existing blueprint and state files
- Analyze the dependencies between the new features and the existing ones
- Schedule development of the new features in dependency order
- Perform incremental integration inspection
Best Practices
- Feature granularity should be moderate: too large (cannot finish in a day) → split; too small (finishes in ten minutes) → merge
- Dependency ordering must be accurate: a wrong order leads to rework
- Integration inspection cannot be skipped: a single feature passing inspection does not mean the whole system is correct
Full Build Automation (Job)
Design Principle
Job's design philosophy is "stage as sub-agent"—each stage executes as an independent subtask, and the main session does only two things: read the state file to determine the current stage, and dispatch the subtasks.
Advanced Usage
Usage 1: Checkpoint resume. Job writes its progress state to the file system, supporting checkpoint resume:
- Conversation interrupted → restart Job
- Read
job.state.json→ locate the current stage - Resume execution from the checkpoint
Usage 2: Custom stages. Job supports inserting custom stages into the standard flow:
Standard flow: Scaffold → Requirements → Architect → Develop → ...
Custom insertion: insert a Security Review stage after Architect
Best Practices
- Job suits projects with clear requirements and standard technology stacks
- Highly customized projects are better served by a more flexible Orchestrator + Workflow combination
- After a conversation interruption, using Job's recovery feature is more efficient than starting over
Supporting Skills
Advisor (Advisor)
When to use: when you are confronted with a difficult technical decision.
Core method: offer options, analyze them, and recommend; let the user make the decision.
Advanced usage: have Advisor play "devil's advocate"—use the AI to argue against its own recommendation, exposing the weaknesses of a solution.
Code Cloner (Cloner)
When to use: when you need to implement a new feature by referencing existing code.
Core method: analyze the patterns in existing code and implement the new feature in the same style and structure.
Advanced usage: analyze several existing features at once, extract common pattern templates, and then apply them in batch.
High-Fidelity Prototype (POC)
When to use: to confirm the frontend effect before formal development.
Core method: generate pure-frontend high-fidelity pages using mock data, with no backend required.
Advanced usage: POC can serve as a "requirements confirmation tool"—letting stakeholders see a real interface before confirming requirements, thereby reducing requirement changes.
Legacy Reconnaissance (Legacy Recon)
When to use: when you need to migrate from a legacy system to a new one.
Core method: analyze the legacy system's interfaces and functionality, and generate the new system's plan and code.
Advanced usage: begin with "field-level comparison"—compare the old and new system implementations field by field to ensure nothing is missed.
Project Handover (Next)
When to use: when you take over a half-finished project.
Core method: analyze the structure and state of the existing code, and find the most suitable entry point for continuing development.
Advanced usage: first assess the project's "code volume" (number of source files, lines of code, test coverage), then decide whether to continue development or rebuild.
Chapter Summary
Among the 14 skills, Coach, Workflow, Orchestrator, and Job form an automation ladder from manual to fully automatic—which one you choose depends on your level of need and your automation requirements. The special-scenario skills (Cloner, Legacy Recon, Next, POC, QA) cover situations that are "not from scratch"; knowing when to use them is just as important as knowing when to use the core skills. The advanced usage and best practices of the other skills can be consulted as a reference manual as needed. In the next chapter, we will review how all the skills work together through a complete project case study.