harness

Harness v2 — Agent team and skill design

Design a harness suited to the project. Define each agent's role, and create the skills the agent will follow when working.

Core principles

1. Agent definitions are created in 프로젝트/.claude/agents/, and skills in 프로젝트/.claude/skills/. Agents describe who works, and skills describe how that work is done.
2. Choose the execution mode according to the work flow. If the order and repetition conditions can be determined in code, coordinate with a workflow. If you need to exchange feedback with the same expert, use a persistent agent. For tasks where you only need the result once, delegate to a subagent. Detailed selection criteria are covered in Step 2.
3. Choose the model according to the complexity, work duration, autonomy, and response speed of the task. Use fable for the highest-difficulty tasks that require planning and long-term autonomous execution, opus for design, code generation, complex analysis, and cross-validation, and sonnet for daily tasks such as log analysis, format conversion, and simple collection. Detailed criteria are covered in Step 3.
4. So that the orchestrator skill can be invoked even in a new session, CLAUDE.mdrecord only the invocation conditions and change history in .
5. Continuously reflect what is learned from execution results into agents, skills, andCLAUDE.mdThe task of retrospecting and identifying changes is handled by the harness:evolve skill.
6. The agent definitions, skills, orchestrator, and CLAUDE.md records to be created are written in the language the user uses in the conversation. Do not write the output in Korean just because this skill document and the references/templates are written in Korean. Also translate the template titles and example phrases into that language. If the user specifies a language separately, follow that language; if extending an existing harness without specifying one, follow the language of the existing files.

Procedure

Step 0: Check the current state

When you invoke the harness skill, first check the existing configuration.

1. 프로젝트/.claude/agents/, 프로젝트/.claude/skills/, 프로젝트/CLAUDE.mdRead .

2. Choose the procedure to proceed with according to the current state.

   • New build: If the agent or skill directory does not exist or is empty, run everything from Step 1.
   • Extend existing configuration: If you need to add agents or skills to an existing harness, run only the necessary steps from the table below.
   • Operations and maintenance: If you need to inspect, modify, or synchronize an existing harness, move to the operations procedure in Step 7.

   Changes	Step 1	Step 2	Step 3	Step 4	Step 5	Step 6
   Add agent	Skip and use the Step 0 result	Decide only which team and step to place it in for which execution mode	Required	When a dedicated skill is needed	Modify orchestrator	Required
   Add/modify skill	Skip	Skip	Skip	Required	When connections change	Required
   Change structure/execution mode	Skip	Required	Only affected agents	Only affected skills	Required	Required

3. If the existing orchestrator has TeamCreate, TeamDelete, CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS, it is a v1 artifact. Since it does not work in the current execution environment, propose migrating to v2. For detailed methods, follow references/execution-modes.md's "Migrating from v1 to v2".

4. Compare the actual agent/skill list with the CLAUDE.md records to find discrepancies.

5. Notify the user of the inspection results and execution plan and get confirmation.

Step 1: Analyze the domain and task

1. Identify the project's domain and goal from the user's request.
2. Divide the necessary types of work, such as generation, verification, editing, and analysis.
3. Check the work flow so an execution mode can be chosen.
   • Can the list to be processed be enumerated in advance? Example: work that moves N files or reviews M perspectives
   • Is an iterative procedure needed to verify and revise the output?
   • Would the result improve if agents exchanged opinions with each other?
   • Do you need to keep talking with the same expert within one session?
4. Find parts that overlap or conflict with the existing agents/skills identified in Step 0.
5. Examine the codebase to identify the tech stack, data model, and major modules.
6. Match the difficulty of explanations to the terminology and question level the user uses. Do not use terms such as assertion or JSON Schema without explanation for users with little coding experience.

Step 2: Design execution mode and team structure

2-1. Choose execution mode

Harness v2 uses three of Claude Code's multi-agent features. Choose one of the following modes according to the work flow.

Execution mode	Features used	Suitable work
Workflow orchestration	Workflow script's agent(), pipeline(), parallel(), phase()	Work where the processing list, verification procedure, and number of iterations can be determined in code. Work that requires results matching a schema or requires calling Agentdozens of times or more
Persistent agent collaboration	Agent(name:), SendMessage, TaskCreate, TaskUpdate	Work that requires named experts to maintain conversation context while repeatedly giving feedback, negotiating, and co-editing
Subagent delegation	Agent Single call. Runs in the background by default, and parallel calls are possible	Work that does not require agents to converse with each other and only needs the result received once

Decide in the following order.

1. If the processing list, validation criteria, and repetition conditions can be expressed in code in advance, use a workflow. By not leaving a fixed flow to the model's moment-to-moment judgment, it can be executed again in the same way.
2. If it is difficult to define in code and agents need to converse with each other or remember previous context, use a persistent agent.
3. If it does not meet either condition and only the result is needed, delegate it to a subagent.
4. If the nature of the work differs at each stage, configure a hybrid mode. Write the execution mode of each stage in the orchestrator.

Workflow To use the tool, the user must explicitly consent. If the user directly requested workflow execution, or Workflow if the user invoked an orchestrator skill that instructs the call, consent is considered given. Limit default execution to a few agents, and scale up to a large scale only when the user requests a broad investigation such as "thoroughly" or "exhaustively".

For the execution mode comparison, concurrency limit, schema, token budget, and resumption conditions, see references/execution-modes.md.

2-2. Choosing a team composition method

1. Divide the work by area of expertise.
2. Among the six methods below, choose the composition that fits the task. Detailed criteria are in references/team-patterns.md.
   • Pipeline: Processes in order by receiving the result of the previous stage. It is suitable for pipeline().
   • Distribution·Integration (Fan-out/Fan-in): Processes independent tasks in parallel and then combines the results. Use pipeline()and only when necessary parallel().
   • Expert pool: Calls only the experts suited to the input. It is suitable for subagents or persistent agents.
   • Generation·Validation: One agent creates and another agent reviews. Use adversarial validation in a workflow or a pair of persistent agents.
   • Supervisor: A central agent observes progress and redistributes work. Use persistent agents and a shared task list.
   • Hierarchical delegation: A higher-level agent delegates again to lower-level agents. Use it within only two levels, and limit workflow nesting to one level.
3. If the accuracy of the output is important, combine the following validation methods.
   • Adversarial validation: Attach N adversarial validation agents to each found item, and if a majority say the evidence is sufficient confirmedOnly items judged as passing are allowed through. refuted나 uncertain A judgment of pass is not counted as passing.
   • Judging panel: Create N drafts separately, review them in parallel, and build the final version based on the best draft.
   • Repeat until no new items (Loop-until-dry): Search until newly found items reach 0 for K consecutive times.
   • Search by multiple criteria: Investigate in parallel using different criteria such as container, content, entity, and time.
   • Omission reviewer: Have the last agent find only what is missing.

2-3. Criteria for dividing agents

Divide agents based on the required expertise, whether parallel processing is possible, the conversation context that must be maintained, and the likelihood of reuse. For the detailed table, see references/team-patterns.md's "Agent Separation Criteria".

Step 3: Writing agent definitions

Specialized agents to be reused across multiple sessions are defined as 프로젝트/.claude/agents/{name}.md files. Do not put roles that will be used repeatedly directly only into Agent of the prompttool.

• They must be defined as files so they can be reused in the next session. Agent In the tool, subagent_type: "{name}", Workflowin agentType: "{name}"is called
• You must decide in advance what the agents will exchange so that collaboration results are stable.
• Write who works in the agent and how to do the work in the skill so that they do not get mixed up.

Create reusable expert roles as user-defined types in a file, and when calling them, specify the file name in subagent_typeor agentType. general-purpose, Explore, Plan For one-off tasks that use built-in types such as these as-is, do not create a separate definition file.

Check whether it overlaps with existing agents

Before creating a new agent file, check whether its role overlaps with existing agents in 프로젝트/.claude/agents/. Even when skipping Step 1 and adding only an agent, do not skip this check. This is because if you build or extend the harness multiple times, agents with the same role can accumulate under different names. If they overlap, do not create one under a new name; use or extend the existing agent as-is. For the criteria and exceptions (cases where a domain is intentionally specialized), see references/team-patterns.md's "Agent Reuse Design".

Model selection criteria

Choose a model for each agent based on the complexity of the work, task duration, autonomy, and response speed. Specify it in model:of the YAML frontmatter or in model, opts.model, which is a call argument, and leave the reason for the choice as a comment in the agent definition or orchestrator.

Model	Selection criteria	Representative tasks
fable	The highest-difficulty work that requires planning on its own, connecting multiple steps, and executing autonomously over a long period	Agent coordination, planning and long-term execution, integration of vast amounts of material, fleshing out vague ideas
opus	Specialized work with a clear scope but requiring deep reasoning and analysis	Design and architecture, code generation, complex analysis, cross-validation, critique of research methods, creative writing
sonnet	Routine work with clear procedures where fast processing matters	Log analysis, format conversion, static file checks, running deployment scripts, simple collection, general writing and summarization

• Use fable when the next plan must change based on the results of the previous step and the agent must execute autonomously over a long period. Use opus when deeply analyzing a single problem with a defined scope. For example, opus is suitable for deeply critiquing one paper, while fable is suitable for reviewing dozens of papers and producing a strategy and report.
• Use sonnet as the default for general work where the judgment is ambiguous.
• Do not assign everything to fable or opus just because the agent is important. Choose the model based on the nature of the actual work, not the agent's status.
• Even if fable is used for the higher-level agent that handles planning and coordination, the lower-level workers each choose the model that fits their task.

Detailed criteria for each model are in references/model-selection-guide.md.

Content to put in the definition file

In the YAML frontmatter, always include name과 description. If needed, add toolsto restrict the tools to use and modelto change the model. In a read-only review/analysis agent's tools, remove Edit and Write so it cannot modify files.

Conversely, for agents that modify deliverables, give Edit along with Write. Without Edit, even fixing one line requires rewriting the entire file, so if the deliverable is large, the agent gives up on making the fix and works around it. Also, toolsthere are cases where tools listed in it are not provided at execution time, so have persistent agents report the list of tools they can actually use in their first report.

In the body, be sure to write the core role, work principles, input/output rules, error handling, and collaboration methods. For persistent agents, add ## 통신 규칙and define SendMessagethe targets to exchange with and how to use the shared task list.

For the definition template, full examples, and toolscautions when restricting it, see references/team-patterns.mdin "Agent Definition Structure".

When setting up a QA agent

• For the QA agent, specify a type that can use all verification tools. Exploreis read-only and cannot run verification scripts.
• Do not check only whether files exist. Compare the API response with the response structure of the frontend hook.
• Do not inspect only once after the entire task is finished. Inspect immediately each time a module is completed.
• For detailed methods, follow references/qa-agent-guide.md.

Step 4: Writing skills

The skills each agent will follow 프로젝트/.claude/skills/{name}/SKILL.mdIt is created in. For detailed instructions on how to write it, follow references/skill-writing-guide.md.

4-0. Check for overlap with existing skills

Before creating a new skill, 프로젝트/.claude/skills/check whether its function overlaps with the existing skills of. If it overlaps, do not create it under a new name; instead, connect or extend the existing skill to the agent. The criteria for judgment, exceptions (cases where the domain is intentionally specialized), and how far to generalize are found in references/skill-writing-guide.md's "Skill Reuse Design."

4-1. Directory structure

skill-name/
├── SKILL.md              # 필수
│   ├── YAML 프론트매터   # name과 description 필수
│   └── Markdown 본문
├── scripts/              # 선택: 반복하거나 결과가 항상 같아야 하는 작업의 실행 코드
├── references/           # 선택: 필요할 때만 읽는 참조 문서
└── assets/               # 선택: 템플릿, 이미지처럼 산출물에 쓰는 파일

4-2. Writing invocation conditions in description

Claude looks at the skill's name과 descriptionto decide which skill to invoke. Among these, descriptionshould specifically state what the skill does and the situations in which it should be used, and should also distinguish cases that look similar but should not be used.

Bad example: "PDF 문서를 처리하는 스킬"

Good example: "PDF 파일 읽기, 텍스트·표 추출, 병합, 분할, 회전, 워터마크, 암호화, OCR 등 PDF 작업을 수행한다. 사용자가 .pdf 파일을 언급하거나 PDF 산출물을 요청하면 반드시 사용한다."

4-3. Principles for writing the body

Principle	How to apply
Explain the reason first	ALWAYS, NEVERDo not just list ; state why the rule is necessary. Only by knowing the reason can correct judgments be made even in exceptional situations.
Write concisely	SKILL.mdKeep it under 500 lines. Delete content that does not help with judgment or move it to references/.
Generalize into principles	Do not make rules that fit only specific examples. Write judgment criteria that can be applied to many inputs.
Put repeated code in advance	If multiple agents rewrite the same script when testing, put it in scripts/.
Write as directives	~한다나 ~하라 Among , choose one ending suitable for the document and use it consistently. The action to be taken must be clearly evident.

4-4. Loading only necessary information step by step

A skill loads necessary information and executable code at the following points.

Information	Loading point	Recommended amount
Metadata(name, description)	Always	About 100 words
SKILL.md body	When loading the skill	Under 500 lines
references/	When the relevant material is needed	No limit
scripts/	When executing repetitive tasks or tasks whose results must always be the same	No limit. Can be executed immediately without reading the content

• SKILL.mdWhen approaches 500 lines, move the details to references/, and state in the body when to read which files.
• If a reference document exceeds 300 lines, put a table of contents at the top of the document.
• If guidelines differ by field or framework, split the reference documents so that only the necessary files are read.

4-5. Connecting agents and skills

• One agent can use one or more skills.
• Multiple agents can share the same skill.
• Skills describe how to work, and agents describe the role that takes on that work.

Step 5: Integrate and determine the execution order

The orchestrator is also a skill. It binds individual agents and skills into a single workflow and determines who collaborates when and in what order. The full template for each mode is in references/orchestrator-template.md, and workflow script examples are in references/workflow-recipes.md.

When extending an existing harness, do not create a new orchestrator; modify the existing file. When adding an agent, reflect it in the configuration, task assignment, and data transfer order, and descriptionalso add new invocation conditions.

5-0. Orchestrator by execution mode

A. Workflow orchestration

In the orchestrator skill, Workflow define a script. The script consists of meta, phase(), pipeline(), parallel(), agent(). Specify custom types as agentType, and receive schema-conformant results as schema.

[오케스트레이터 스킬] → Workflow(script)
    ├── phase('수집'): pipeline(items, ...)   ← 미리 정한 목록을 분산 처리
    ├── phase('검증'): 적대적 검증 또는 심사위원단
    └── return 구조화된 결과 → 메인이 종합 보고서 작성

B. Persistent agent collaboration

Run a named agent and then coordinate via the shared task list and SendMessage. TeamCreate와 TeamDeleteno longer exists. Do not create an explicit team object; agents run with names assigned in the session automatically belong to a single collaboration group that is formed automatically. You can send messages again to that agent while retaining the previous conversation context.

[메인 에이전트(리더)]
    ├── Agent(name: "researcher", ...) / Agent(name: "critic", ...)  ← 병렬 실행
    ├── TaskCreate(작업 + 의존 관계)
    ├── SendMessage({to: "critic"}, "researcher의 초안을 검토하라")
    └── 결과 수집 및 종합

C. Subagent delegation

In a single message, Agent call the tool N times in parallel and collect the results from completion notifications. The calling agent runs in the background by default.

If the nature of the work differs at each step, you can configure a mixed mode. For example, you can gather data via a workflow and then have persistent agents reach consensus and integrate it, or you can adversarially verify the results created by persistent agents via a workflow. Above each step, **실행 모드:**write .

5-1. Data transfer methods

Method	Implementation	Appropriate execution mode	When to use
Structured return value	Workflow의 agent(prompt, {schema})verified JSON return	Workflow orchestration	When the next step needs to process the result in code
General return value	Agent tool return message	Subagent	When the main agent collects summary results directly
Message	SendMessagedirectly between agents via	Persistent agent	When real-time coordination and feedback are needed
Shared task list	TaskCreate, TaskUpdateshare status via	Persistent agent	When managing progress, dependencies, and dynamic assignment
File	Write to and read from a predetermined path	All modes	When the data is large or the work process needs to be checked later

When delivering as a file, follow these rules.

• Under the working directory _workspace/store intermediate artifacts in.
• The file name uses the {phase}_{agent}_{artifact}.{ext} format. Example: 01_analyst_requirements.md
• Store only the final artifact in the path specified by the user. _workspace/is kept for post-verification.

5-2. Error Handling

Put the error handling policy in the orchestrator.

• Retry once, and if it fails again, proceed without that result, but note the omission in the final report. Do not delete conflicting data; keep it along with its source.
• However, do not retry failures whose result would be the same even if retried, such as exhausting the usage limit, expired authentication, or permission denied. Retrying only consumes the remaining quota. Open the partial artifacts directly to check how far it actually progressed, record the missing content in a file, and report to the user. If it is a usage limit, also inform them of the time when the limit is lifted.
• When the orchestrator fills in the blanks left by a stopped agent, it reflects only directly verified facts in its place. Do not fill in the agent's judgments (e.g., which data was excluded and why) by guessing. Filling in with guesses amounts to falsifying the records to be used for post-verification.
• In the workflow, failed or skipped agent()는 nullis returned and parallel()does not throw failures as exceptions. Apply .filter(Boolean)to the result array and report the number of missing items with log().
• If a persistent agent does not respond, check the status with SendMessageand instruct it again. If it still fails, run the same user-defined type under a new name and pass the necessary task context as a prompt.

For response methods by error type, check the "Error Handling" of the corresponding execution mode template in references/orchestrator-template.md.

5-3. Task Scale

Task Scale	Number of Persistent Agents	The scale of Agent calls in the workflow
Small scale: fewer than 10 tasks	2~3명	2~5건
Medium scale: 10-20 tasks	3~5명	About 10 cases. If the concurrent execution limit is exceeded, automatically wait
Large scale: more than 20 tasks	Supervisor + 3-5 workers	Tens to hundreds of cases. Overall limit of 1,000 cases

• The more agents there are, the greater the management cost. Keep the default scale small.
• If the user specifies a token budget like +500k, check budget.remaining()in the workflow script and adjust the execution scale.

5-4. CLAUDE.mdRecord harness connection information in

When configuration is complete, in the project's CLAUDE.mdrecord the fact that the harness exists and the invocation conditions. CLAUDE.mdis read on every new session, so do not repeatedly include detailed execution rules.

## 하네스: {도메인명}

**목표:** {하네스의 핵심 목표 한 줄}

**호출 조건:** {도메인} 관련 작업을 요청받으면 `{orchestrator-skill-name}` 스킬을 사용한다. 단순 질문에는 직접 답해도 된다.

**변경 이력:**
| 날짜 | 변경 내용 | 대상 | 사유 |
| --- | --- | --- | --- |
| {YYYY-MM-DD} | Harness v2로 처음 구성 | 전체 | - |

Do not include the agent/skill list, directory structure, or detailed execution rules. This information is managed by the orchestrator skill and .claude/agents/, .claude/skills/. CLAUDE.mdcontains only the invocation conditions and change history.

5-5. Handling follow-up requests

The orchestrator must work not only on the first run but also when revising the results again.

1. description에 다시 실행, 재실행, 업데이트, 수정, 보완, {도메인}의 {부분 작업}만 다시, 이전 결과를 바탕으로, 결과 개선 include an expression such as
2. In step 0 of the orchestrator, check the existing task context.
   • _workspace/is present and only part of it needs to be fixed, re-run only that step or agent.
   • _workspace/is present and new input has been received, move the existing directory to a directory with a timestamp appended, then run anew.
   • _workspace/is not present, run from the beginning.
   • If the workflow's immediately preceding runIdis present, resumeFromRunIdcan be resumed from. Unchanged agent() calls use cached results.
3. Write the re-invocation method in the agent definition. If a previous result file exists, read it; if there is user feedback, fix only the relevant part.

Step 6: Validation and testing

Validate the generated harness. For detailed methods, follow references/skill-testing-guide.md.

6-1. File and reference validation

• Check that all agent files are in the correct locations.
• Check that the skill's YAML frontmatter has name과 description.
• Check that the names by which agents reference each other match.
• .claude/commands/Check that no command files were created in
• Check that the v1-style TeamCreate, TeamDelete, team_nameand experimental feature flags do not remain in the deliverables.

6-2. Validation by execution mode

• Workflow orchestration: metacheck that Date.now()와 Math.random()is a literal containing only a value, that parallel()was not used, that .filter(Boolean)was used only when it is necessary to wait for the entire result, that phase() was not omitted, and that the meta.phasesheading matches
• Persistent agent collaboration: SendMessagecheck the send/receive paths, task dependencies, and number of agents of
• Subagent delegation: check that each agent's input and output connect, that parallel calls are bundled into a single message, and that results are collected without omission.
• Mixed mode: check that the execution mode is written for each step and that data is not broken when steps change.

6-3. Skill execution testing

1. For each skill, create 2-3 concrete test requests that a real user might input.
2. Run the skill-applied execution (With-skill) and the baseline execution (Baseline) in parallel to compare how much the skill improves the results. If repetition is needed, the A/B comparison itself can be made into a workflow.
3. Use a qualitative evaluation that the user directly reviews together with a quantitative evaluation that uses verification conditions (assertions). If objective conditions cannot be created, follow the user's judgment.
4. When a problem arises, do not add a rule that blocks only a specific example; fix it as a principle that can be applied to multiple situations. Test again, and repeat until further fixes yield little benefit.
5. If multiple agents repeatedly create the same code, scripts/put it in.

6-4. Call Condition Verification

1. Create 10 requests that should load the skill, in different tones and levels of explicitness.
2. Also create 10 boundary cases where the wording is similar but a different skill or tool should be used.

Clearly unrelated requests cannot verify the boundary. For example, when testing an image generation skill, 피보나치 함수 작성than 이 엑셀 파일의 차트를 PNG로 추출해 줘is a better boundary case. This is because the result is an image, but in reality a spreadsheet tool is more appropriate. Also check whether call conditions overlap with existing skills.

6-5. Mock Execution

• Check whether the orchestrator's step order is logical.
• Check whether the data transfer path is not broken in the middle.
• Check whether every agent's input matches the output of the previous step.
• Check whether the fallback procedure can actually be executed when an error occurs.

6-6. Test Scenario Recording

In the orchestrator skill, ## 테스트 시나리오create , and write one normal flow and at least one error flow.

Step 7: Operations, Maintenance, and Improvement

The harness is not an artifact that is finished once it is built.

The task of reflecting on execution results and incorporating feedback is harness:evolve handled by the skill. When the user 하네스 회고, 하네스 진화, 피드백 반영해줘requests, harness:evolveuse . This skill analyzes the difference between the initial configuration and the current state, organizes feedback so it can be applied to multiple situations, and reflects it in agents, skills, and the orchestrator. CLAUDE.md Also update the change history.

이 harness The skill directly handles the following procedures for operating and maintaining an existing harness.

1. Check current state: .claude/agents/, .claude/skills/, compare the orchestrator configuration, create a list of mismatches, and notify the user.
2. Add and modify little by little: Change only one item at a time and immediately run the next verification.
3. Record change history: CLAUDE.mdWrite the date, change details, target, and reason in .
4. Verify changes: Check the file structure. If call conditions are affected, also run call tests. If the scope of change is large, run execution tests and mock execution as well, then CLAUDE.mdfinally check whether and the actual files match.

In the following situations, harness:evolvepropose improving with .

• The same type of feedback has come out two or more times.
• The agent repeatedly fails for the same reason.
• The user keeps handling the same task manually without going through the orchestrator.

Deliverable checklist

• 프로젝트/.claude/agents/I created files for all custom types to be reused in. I excluded cases where built-in types are used as-is for one-off tasks.
• 프로젝트/.claude/skills/the necessary SKILL.mdand created the reference document.
• In one orchestrator skill, I included the data passing method, error handling, and test scenarios.
• I wrote the execution mode to use among workflow orchestration, persistent agents, and subagents. For mixed modes, I indicated it for each step.
• per-agent model:was selected based on complexity, task duration, autonomy, and response speed, and the reason was left as a comment. I did not uniformly assign the same high-performance model to all agents.
• In the deliverable, TeamCreate, TeamDelete, v1-style elements such as experimental feature flags no longer remained.
• In the workflow script, .filter(Boolean)and in metaonly literals were used. Only when absolutely necessary parallel()and wait for the entire result.
• .claude/commands/I did not create files in.
• Before creating new agents/skills, I checked whether their roles overlapped with existing ones. Unless the domain was intentionally specialized, for overlapping cases I used or extended the existing one, and names or roles do not conflict.
• Agent definitions, skills, orchestrator, CLAUDE.md I wrote the records in the language the user uses in the conversation. If the user specified a separate language or there is a language in the existing harness files, I followed that language.
• In the skill description, I concretely wrote what to do and the invocation conditions, and also included follow-up request expressions. descriptionthe contents to do and invocation conditions were written in detail, and follow-up request expressions were also included.
• SKILL.md The body is under 500 lines. If it is 500 lines or more, move the details to references/moved to.
• I ran it with 2–3 test sentences similar to actual requests.
• I verified the invocation conditions with boundary cases of requests that should invoke the skill and requests that should not.
• CLAUDE.mdI recorded only the invocation conditions and change history in.
• In step 0 of the orchestrator, distinguish first execution, subsequent execution, and partial re-execution. The workflow also handles resume options.

Reference document

• Execution mode details: references/execution-modes.md
• Model selection guide: references/model-selection-guide.md
• Team composition method and agent definitions: references/team-patterns.md
• Practical team composition examples: references/team-examples.md
• Workflow script examples and cautions: references/workflow-recipes.md
• Orchestrator template: references/orchestrator-template.md
• Skill authoring guide: references/skill-writing-guide.md
• Skill testing guide: references/skill-testing-guide.md
• QA agent guide: references/qa-agent-guide.md