# Chapter 16: Core and Auxiliary Execution Skills

## Lesson objectives

- **O1** Can assign owners and interfaces to core execution, supporting execution and human authorization (artifact: skill responsibility swimlane)
  - Evidence: The skill responsibility swimlane names an owner for each of core execution, supporting execution and human authorization
- **O2** Can construct a skill responsibility swimlane showing how information, authority and evidence cross interfaces (artifact: skill responsibility swimlane)
  - Evidence: The skill responsibility swimlane defines at least two interfaces with inputs, outputs and authority limits
- **O3** Can divide core execution, supporting execution and human authorization into lanes (artifact: skill responsibility swimlane)
  - Evidence: The artifact marks inputs, outputs and authorization points for every lane in one workflow

## Learning paths

- **Novice**: Chapter transfer task: Can divide core execution, supporting execution and human authorization into lanes. Use the diagram's network relationship to complete the first evidence item in the skill responsibility swimlane, then check each owner and decision rule.
- **Experienced**: Apply this task to a current project before reading the explanation: Can divide core execution, supporting execution and human authorization into lanes. Submit the skill responsibility swimlane, then check the relationship type, missing evidence and authority boundary.

## Teaching diagram

- **Required artifact**: skill responsibility swimlane
- **Diagram kind**: execution-lanes
- **Relationship semantics**: The side roles collaborate through a central interface, while the lower band constrains owners, interfaces and evidence; a connection does not transfer authority by itself.
- **Core concepts**: core execution · supporting execution · human authorization

![Chapter 16 teaching diagram for the skill responsibility swimlane](/learning/diagrams/en/chapter-16.svg)

Use the skill responsibility swimlane to trace cross-role interfaces and make responsibility, authority and evidence transfers explicit.

The diagram places core execution and human authorization on opposite sides with supporting execution at the central interface. Arrows show information or work handoffs. The lower band requires an owner, interface and evidence for each link; connectivity alone does not transfer authority.

> **Adapted public course.** Concepts, procedures and examples are adapted from the internal textbook. Case sizes, timings, improvement figures and target thresholds are illustrative, not site delivery results or universal standards. Verify tools, platforms and skills in your environment. Prompts do not grant permissions and retry counts do not authorize recovery. Preserve work and verify targets, sharing and external-state effects first.

## Lesson explanation

Chapter positioning: Coach is a process-support skill for day-to-day delivery; Workflow and Inspector belong to the core execution layer; Advisor is an auxiliary decision-support skill. This classification describes their roles in the workflow, not their adoption priority: Advisor can merit early investment because decision blockage is common, but it does not take over requirements, implementation, or verification.

### 16.1 Process Coach: The Guide That Builds Habits

Design rationale: Coach is "guidance-oriented" -- it does not make decisions for the user; instead, it guides the user to make their own decisions. Its core value is building habits, not completing tasks.

Why it matters most for beginners: As a beginner, what you need most is "the right habits." The process coach exists to help you build habits -- it walks you through the six-step method and reminds you what to do at every step. You do not have to memorize the process; it guides you step by step at your side. With enough use, the six-step method becomes your "muscle memory."

How to use it:

> Start implementing the note-editing feature. Requirement: users can modify a note's title and content on the edit page, and after saving, return to the list page.

The AI will guide you through the entire six-step method -- helping you break down milestones, confirm the approach, and verify the code.

Advanced usage:

- Habit formation: Before each start, it reminds you to check the blueprint; after each completion, it reminds you to verify; whenever verification fails, it guides you to decide between fixing or rebuilding.
- Progressive release of control: As you grow familiar with the process, Coach can gradually reduce its guidance -- the first time, it explains each step in detail; the fifth time, it only prompts at key checkpoints; the tenth time, it only alerts when it detects anomalies.

Best practice: Coach suits beginners and complex scenarios, not developers already familiar with the process. Saying "start development" triggers Coach, but saying "fully implement" should trigger Workflow.

### 16.2 Automated Workflow: From Manual Guidance to Automated Execution

Design rationale: The core of Workflow is not "automated coding" but "automated process control." It replaces the human-judgment steps in the six-step method with rule-based judgment, achieving a fully automated closed loop from requirement description to code delivery.

Think about what you do in the six-step process: when breaking down work you confirm the approach; when issuing instructions you write the prompt; when verifying you review code; when making a branch decision you decide whether to commit or rebuild; after solidification you still have to update the blueprint. Every step drains your attention. Workflow's idea is simple: turn steps that "need your judgment" into steps that "use rule-based judgment" -- acceptance criteria are explicit, so branch decisions can be handled by rules instead of humans; instruction issuance is templated (technical constraints are read from the blueprint), so you do not need to handwrite them every time.

Core mechanism: three-step iterative loop:

<!-- code-example:chapter-16-E1 mode:pseudocode -->
> **Example type: pseudocode.** Pseudocode; it is not executable. It expresses decision order only, so implementation must supply real interfaces, authority and error handling.
```text
Issue Instruction → Milestone Inspection → Branch Decision
                             │
              ┌──────────────┼──────────────┐
              ▼              ▼              ▼
           PASS           NEEDS_FIX       REBUILD
      Next milestone    Re-verify after   Roll back &
                          fix             rebuild
```

- Step one: issue instruction -- Workflow automatically generates, based on the blueprint and requirement description, an instruction for the current milestone, covering what to do, the technical constraints (read from the blueprint), and the acceptance criteria;
- Step two: milestone verification -- after the AI finishes coding, it automatically invokes the verification mechanism to check: is the feature implemented? Does it deviate from the blueprint? Is code quality up to standard? Are edge cases handled?
- Step three: branch decision -- on PASS, commit the code and proceed to the next milestone; on NEEDS_FIX, automatically issue a fix instruction (up to twice); on REBUILD, automatically roll back, generate a more precise instruction, and start over.

Three modes:

| Mode | Behavior | When to use |
|------|------|-----------|
| normal | After showing the plan for each milestone, wait for confirmation; when verification finds a problem, wait for a decision | Unsure whether the AI understood correctly; human gatekeeping needed |
| auto | After the milestone plan is confirmed, execute directly; verification performs branch decisions automatically | Functional requirements are clear; you trust the AI's capability |
| silent | Fully automatic, silent execution, logging only | Batch execution, or inside a CI/CD pipeline |

Context-reset management: A feature spanning multiple milestones keeps growing the conversation during implementation. Once the conversation grows long, the AI's performance degrades. Workflow solves this with context resets: after each milestone completes, record the current state → reset the context and clear the conversation history → reload the blueprint and the current milestone's instruction in a fresh context → continue execution. This is like a shift handover on a construction site: at the start of every shift, you first read the drawings and progress log, then begin work -- rather than relying on the previous shift's verbal handoff.

Exception handling: Verification repeatedly fails (3 NEEDS_FIX) → automatically escalate to REBUILD; the AI drifts away from the current milestone → gently remind it to return to the current task; project structure changes → pause the current milestone, update the blueprint first, then restart.

### 16.3 Inspector Verification: Compare Against the Blueprint, Find the Differences

Design rationale: The core of Inspector is "comparison" -- compare the AI-generated code against the blueprint and find the differences. It does not judge whether the code is "good or bad," only whether the code "matches the blueprint."

Why independent verification is needed: In conventional AI coding practice, "verification" often amounts to a developer glancing at the code and approving it as "close enough." The problem is: AI-generated code is almost always syntactically correct, and the genuine problems hide in the logic and architecture layers -- you cannot see them at a glance, running it may look fine, until some edge condition triggers a bug.

Three-dimensional detection of architectural drift:

1. Tampering with the foundation -- unexpectedly modifying core files (database connection config, authentication logic, global middleware)? → immediate REBUILD;
2. Over-engineering -- adding unnecessary dependencies or abstractions? → remove after review;
3. Size out of control -- a single file exceeding 300 lines? → split and refactor.

Detection methods:

1. Use `git diff` to inspect the changed-file list -- unexpected file modifications may indicate foundation tampering;
2. Check the length of newly added files -- exceeding 300 lines may indicate size out of control;
3. Check newly added dependencies -- unexpected entries in package.json may indicate over-engineering;
4. Compare against the blueprint's directory structure -- code placed in locations not agreed upon in the blueprint may indicate architectural drift.

Automating security review: Inspector can integrate security-review rules -- check whether parameterized queries are used (to prevent SQL injection), whether user input is escaped (to prevent XSS), whether sensitive endpoints have access control, and whether fields that should not be exposed are being returned.

Best practice: Acceptance criteria must be defined before coding begins, not improvised after coding is done; verification reports use a structured template (function / code / architecture / security); when architectural drift is detected, prefer REBUILD over NEEDS_FIX -- repairing a crooked foundation is riskier than continuing to build on one.

### 16.4 Auxiliary Decision-Support Skill: Advisor Consultation -- AI Gives Suggestions, Humans Make Decisions

Design rationale: The core of Advisor is "provide options, analysis, and recommendations, and let the user make the decision." The AI advises; you decide.

When to use it: When you hit a difficult technical decision -- "SQLite or PostgreSQL?" "This library or that one?" Advisor consultation can help you analyze the pros and cons of each option, but remember: the final decision is always yours.

Advanced usage: Have Advisor play "devil's advocate" -- use the AI to rebut its own recommendation and expose the weaknesses of the proposal. For example:

> Please analyze the pros and cons of option A vs option B and give your recommendation. Then, playing "devil's advocate," rebut your own recommendation and explain under what circumstances option A (or B) would fail.

Best practice: In technical discussions, treat the AI as "the most knowledgeable consultant," not as "the decision-maker." When you notice yourself adopting the AI's suggestions without analysis -- especially on architecture choices -- that is an early warning sign of "AI dependency."

---

## Independent exercise

Use fictional or authorized deidentified material. Answer independently before revealing the reference. Save `chapter-16.md` with versions, decisions, evidence and gaps.

Design a coach → implementer → reviewer handoff for a beginner investigating unknown-input errors, with instructions and artifacts.

<!-- chapter-artifact-requirement -->
### Required chapter artifact: skill responsibility swimlane

The submission for this independent exercise must contain the evidence below. The existing prompts supply content but do not replace these acceptance items.

- O1: The skill responsibility swimlane names an owner for each of core execution, supporting execution and human authorization
- O2: The skill responsibility swimlane defines at least two interfaces with inputs, outputs and authority limits
- O3: The artifact marks inputs, outputs and authorization points for every lane in one workflow

<details>
<summary>Reveal reference feedback (answer first)</summary>

## Reference feedback

The coach asks the learner to run and explain the failure instead of supplying all answers. Implementation stays within scope; review compares fixed expectations and the diff. Advisors propose hypotheses; authorized humans decide actions. Self-review does not replace independent inspection.

### Self-review and next steps

Check whether your decision is explicit, evidence reproducible and unknowns honestly recorded. The reference illustrates one defensible approach, not a unique answer. Seek peer review for alternatives with equivalent evidence. Mark unsupported parts unfinished and revisit the corresponding step.

</details>

## Sources and boundaries

Registered sources support only the external claims used here. The skill responsibility swimlane, example numbers and exercise scenario are internal instructional design and require project-specific validation.

- [Git reference](https://git-scm.com/docs) — Git project, 2026-09-17. Versions, branches, commits and recovery operations must be verified against repository state.