[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6GDK1R564MB4RT7EPPJQR3E":3,"skill-same:01M6GDK1R564MB4RT7EPPJQR3E":76},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":54,"commitSha":55,"skillDirectory":56,"forksCount":57,"repositoryHtmlUrl":58,"repositoryHomepageUrl":6,"ownerHtmlUrl":59,"ownerBlogUrl":6,"ownerDescription":60,"updatedAt":61,"install":62,"resources":75},"01M6GDK1R564MB4RT7EPPJQR3E","create-agent",null,"Create and update Harness AI agent instances for automated code and infrastructure tasks. Supports multi-stage execution, MCP server integration, LLM connector configuration, runtime inputs, repository cloning, and task\u002Frules-based instruction. Use when asked to create an agent, update agent spec, modify agent configuration, automate tasks, perform agentic workflows, build autonomous systems, or work with AI agents. Trigger phrases: create agent, update agent, modify agent spec, AI agent, autonomous agent, agentic pipeline, automation task, automate workflow, Harness agent, code coverage agent, review agent, agentic task.","zapabob\u002FSkills","zapabob","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F130830376?v=4","01M6DBMYZAGRTFQDSQYW3W764P","峯岸 亮","01M6DBMZ3GKDSJ01NZ9XTZD7JD",2,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fzapabob\u002FSkills\u002Fblob\u002Fmain\u002Farchive\u002Fskill-md-reviewed\u002Fsha256\u002Fbb\u002Fbb8857a56e47919d3f4dd28395823167bc209bc0c90e6717ae3a308966b3e4d0\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"create agent","create","tasks","instances","Connector","update agent","autonomous","coverage","pipeline","server","code","MCP","agentic workflows","workflows","workflow","ai agent","mcp server","ai agents","agentic","review","2026-11-10 10:12:30",false,"---\r\nname: create-agent\r\ndescription: >-\r\n  Create and update Harness AI agent instances for automated code and infrastructure tasks. Supports\r\n  multi-stage execution, MCP server integration, LLM connector configuration, runtime inputs, repository\r\n  cloning, and task\u002Frules-based instruction. Use when asked to create an agent, update agent spec,\r\n  modify agent configuration, automate tasks, perform agentic workflows, build autonomous systems, or\r\n  work with AI agents. Trigger phrases: create agent, update agent, modify agent spec, AI agent,\r\n  autonomous agent, agentic pipeline, automation task, automate workflow, Harness agent, code coverage\r\n  agent, review agent, agentic task.\r\nmetadata:\r\n  author: Harness\r\n  version: 1.0.0\r\n  mcp-server: harness-mcp-v2\r\nlicense: Apache-2.0\r\ncompatibility: Requires Harness MCP v2 server (harness-mcp-v2)\r\n---\r\n\r\n# Create Agent\r\n\r\nCreate and update Harness AI agent instances for automated code, build agentic workflows, and infrastructure tasks.\r\n\r\n## Instructions\r\n\r\nFollow this workflow to create or update an agent. **This is INTERACTIVE — show YAML for review and wait for confirmation before creating\u002Fupdating the agent.**\r\n\r\n### Phase 1: Check Existing Solutions First\r\n\r\n**IMPORTANT: Before creating a new agent, check if an existing one can solve the use case.**\r\n\r\n1. **List existing agents** — Call `harness_list` with `resource_type=\"agent\"` (include `org_id` and `project_id` if scoped to a project)\r\n   - Check if any system or custom agents already exist that can handle this task\r\n   - Ask user if they want to use\u002Fmodify an existing agent instead of creating new\r\n2. **For updating existing agents** — Use `harness_get` with `resource_type=\"agent\"` and `agent_id` to retrieve the current agent configuration\r\n   - Review the current `spec`, `name`, `description`, and other fields\r\n   - Identify what needs to be changed (spec, name, description, wiki, logo)\r\n   - Use `harness_update` (not `harness_create`) to update the agent with only the fields that need modification\r\n3. **Refer to agent schema when needed** — If you're not sure about the YAML structure, use `harness_schema` with `resource_type=\"agent-pipeline\"` to explore available fields and sections\r\n   - **Use the `path` parameter to avoid context pollution**: The full schema is 4k+ lines. Load only what you need:\r\n     - `harness_schema(resource_type=\"agent-pipeline\")` → Top-level summary (shows available sections)\r\n     - `harness_schema(resource_type=\"agent-pipeline\", path=\"Agent\")` → Agent structure only\r\n     - `harness_schema(resource_type=\"agent-pipeline\", path=\"stages\")` → Stage definitions only\r\n   - **For operations\u002FAPI metadata**: Use `harness_describe(resource_type=\"agent\")` to see supported operations, filters, and execute actions\r\n   - **CRITICAL**: The agent spec uses first-class `agent` format (version: 1, agent:, stages:, etc.), NOT `pipeline` format\r\n\r\n### Phase 2: Requirements Gathering\r\n\r\nIf creating a new agent or updating an existing one, collect the following before generating YAML:\r\n\r\n#### 1. Agent Metadata\r\n- **Name**: Display name for the agent (e.g. \"Code Coverage Agent\", \"PR Reviewer\")\r\n- **Description**: Brief description of the agent's purpose (optional)\r\n- **UID**: Unique identifier (auto-generated from name if not provided — e.g. \"Code Coverage Agent\" → \"code_coverage_agent\")\r\n\r\n#### 2. Task Details\r\n\r\n**This is an INTERACTIVE requirements gathering process. Ask clarifying questions and verify understanding with the user before proceeding.**\r\n\r\n##### Step 1: Understand the Agent's Purpose\r\n\r\nAsk and clarify the following with the user:\r\n\r\n1. **Agent's exact goal**: What specific outcome should the agent achieve?\r\n   - Examples: \"Increase code coverage to 80%\", \"Review PRs for security vulnerabilities\", \"Generate unit tests for uncovered functions\"\r\n   - Be specific — avoid vague goals like \"improve code quality\"\r\n\r\n2. **Inputs the agent needs**: What data or context does the agent require to start?\r\n   - Repository information? (repo name, branch, PR number)\r\n   - Execution context? (pipeline execution ID, previous step outputs)\r\n   - Configuration? (coverage threshold, target files, exclusion patterns)\r\n   - Secrets? (API keys, tokens for external services)\r\n\r\n3. **Outputs the agent produces**: What artifacts, reports, or actions should result?\r\n   - Files? (COVERAGE.md, test files, reports)\r\n   - External actions? (create PR, post comments, send notifications)\r\n   - Data? (metrics, logs, analysis results)\r\n\r\n4. **What the agent works on**: What files, services, or systems does it interact with?\r\n   - Specific file paths or patterns? (e.g., `pkg\u002F**\u002F*.go`, `src\u002Fservices\u002F`)\r\n   - External services? (GitHub API, Slack, monitoring systems)\r\n   - Databases or APIs? (read-only access, write operations)\r\n\r\n5. **Task workflow**: Understand the user's workflow for the task — what should happen step-by-step (do 1, then 2, then 3, etc.)\r\n\r\n6. **Constraints and preferences**: Any user preferences for completing the task — limitations, rules, or coding standards the agent should follow\r\n   - Examples: \"Use idiomatic Go code\", \"Do not modify existing tests\", \"Keep reports under 10000 characters\"\r\n\r\n7. **Definition of done**: How do you know the agent succeeded?\r\n   - Specific criteria? (\"Coverage increased by X%\", \"All files have tests\")\r\n   - Artifacts created? (\"PR created with tests\", \"COVERAGE.md updated\")\r\n   - Exit conditions? (\"No security vulnerabilities found\", \"All checks passed\")\r\n\r\n##### Step 2: Recommend Configuration\r\n\r\nBased on the requirements gathered in Step 1, recommend specific configurations and verify with the user:\r\n\r\n1. **Task instructions** (`task` field):\r\n   - Break down the goal into detailed step-by-step instructions\r\n   - Include specific commands, file paths, and expected outcomes\r\n   - Reference inputs using `\u003C+inputs.fieldName>` syntax\r\n   - Example: \"1. Run `go test -cover .\u002F...` to measure coverage\\n2. Identify functions below 80% coverage\\n3. Generate tests for uncovered functions\\n4. Create PR with new tests\"\r\n\r\n2. **Runtime inputs** (`inputs` section in spec):\r\n   - Only add if user confirms runtime parameters are needed\r\n   - Map each input to what the agent needs (repo, branch, executionId, thresholds, etc.)\r\n   - Example: `repo` (string), `coverageThreshold` (string), `llmKey` (secret)\r\n\r\n3. **User preferences** (RULES section in `task` field):\r\n   - Convert constraints and coding standards into a dedicated RULES section at the end of the task\r\n   - Format as a markdown section with bullet points\r\n   - Be specific and actionable\r\n   - Example: Add `## RULES\\n- Use idiomatic Go code\\n- Do not modify existing tests\\n- Keep COVERAGE.md under 10000 characters` at the end of the task\r\n\r\n4. **MCP servers** (`mcp_servers` in spec):\r\n   - Identify which external services the agent needs to interact with\r\n   - GitHub? → Recommend GitHub Copilot MCP: `https:\u002F\u002Fapi.githubcopilot.com\u002Fmcp\u002F`\r\n   - Harness platform? → Recommend Harness MCP URL\r\n   - Slack\u002Fnotifications? → Recommend notification MCP\r\n   - Recommend MCPs based on the user's task or workflows\r\n\r\n5. **Secrets** (via `\u003C+secrets.getValue(\"key\")`):\r\n   - List all secrets needed for authentication (GitHub PAT, API keys, tokens)\r\n   - Remind user to create these in Harness UI before running the agent\r\n   - Example: `bedrock_api_key`, `github_pat`, `slack_token`\r\n\r\n6. **Connectors**:\r\n   - GitHub\u002FGitLab\u002FBitbucket connector for repository access\r\n   - Container registry connector for custom images (if needed)\r\n   - Cloud connectors (if agent interacts with AWS\u002FGCP\u002FAzure)\r\n\r\n7. **Tools** (`with.allowed_tools`):\r\n   - Recommend tools based on what the agent needs to do\r\n   - File operations: `Read`, `Write`, `Grep`, `Glob`\r\n   - MCP tools: `mcp__github__*`, `mcp__harness__*` (use `*` for all tools from that MCP)\r\n   - Shell: `Bash`\r\n\r\n**Present this recommended configuration to the user and iterate until confirmed.**\r\n\r\n#### 3. Default Configuration\r\n\r\n**Use these defaults unless user specifies otherwise:**\r\n\r\n**Repository clone:**\r\n- Only add this section if the task depends on a repository\r\n```yaml\r\nclone:\r\n  depth: 1000\r\n  ref:\r\n    type: branch\r\n    name: main\r\n  repo: \u003Crepo>\r\n  connector: \u003Cconnector>\r\n```\r\n\r\n**Platform:**\r\n```yaml\r\nplatform:\r\n  os: linux\r\n  arch: arm64\r\n```\r\n\r\n**Container image:**\r\n- The Claude Code plugin is packaged via this image\r\n```yaml\r\ncontainer:\r\n  image: pkg.harness.io\u002Fvrvdt5ius7uwygso8s0bia\u002Fharness-agents\u002Fclaude-code-plugin:main\r\n```\r\n\r\n**Environment variables (Bedrock configuration):**\r\n```yaml\r\nenv:\r\n  ANTHROPIC_MODEL: arn:aws:bedrock:us-east-1:587817102444:application-inference-profile\u002F7p8sn93lhspw\r\n  AWS_BEARER_TOKEN_BEDROCK: \u003C+secrets.getValue(\"bedrock_api_key\")>\r\n  AWS_REGION: us-east-1\r\n  CLAUDE_CODE_USE_BEDROCK: \"1\"\r\n```\r\n\r\n**Max turns:**\r\n- Depending on task complexity, adjust this in the range from 100 to 200\r\n```yaml\r\nmax_turns: 150\r\n```\r\n\r\n#### 4. MCP Servers\r\n\r\nBased on the MCPs needed (clarified with the user), configure MCP server connections:\r\n\r\n**How to Connect MCP Servers?**\r\n\r\n**Remote MCP Server:**\r\n- If your MCP server is publicly accessible, connect it directly using a Personal Access Token (PAT)\r\n- Create a secret in Harness for the PAT and reference it in the agent YAML\r\n\r\nExample — Remote MCP Server:\r\n```yaml\r\nmcp_servers:\r\n  harness:\r\n    url: https:\u002F\u002F\u003Cyour-ngrok-url>\u002Fmcp\r\n  github:\r\n    url: https:\u002F\u002Fapi.githubcopilot.com\u002Fmcp\u002F\r\n    headers:\r\n      Authorization: Bearer \u003C+secrets.getValue(\"github_pat\")>\r\n```\r\n\r\n**Local MCP Server:**\r\n- Use ngrok to expose your local MCP server so the Harness runner can reach it\r\n\r\nExample — Single MCP Server:\r\n```yaml\r\nmcp_servers:\r\n  harness:\r\n    url: https:\u002F\u002F\u003Cyour-ngrok-url>\u002Fmcp\r\n```\r\n\r\n**Allowing MCP Tools:**\r\n- To allow the coding agent to use MCP tools, add `mcp__name__*` in `allowed_tools`\r\n- Optionally specify a `log_file` for debugging MCP interactions\r\n```yaml\r\nmcp_servers:\r\n  harness:\r\n    url: https:\u002F\u002F\u003Cyour-ngrok-url>\u002Fmcp\r\nwith:\r\n  allowed_tools: Read,Edit,Bash,Glob,Grep,Write,mcp__harness__*\r\n  log_file: .agent\u002Foutput\u002Fmcp-test-log.jsonl\r\n```\r\n\r\n**Common MCP servers:**\r\n- **GitHub\u002FCode\u002FPRs**: `https:\u002F\u002Fapi.githubcopilot.com\u002Fmcp\u002F` with `Bearer \u003C+secrets.getValue(\"github_pat\")>`\r\n- **Harness platform**: `https:\u002F\u002F\u003Cyour-harness-mcp-url>\u002Fmcp` with Bearer token\r\n- **Slack\u002FNotifications**: `https:\u002F\u002F\u003Cyour-slack-mcp-url>\u002Fmcp` with Bearer token\r\n- **Grafana**: `https:\u002F\u002F\u003Cyour-grafana-mcp-url>\u002Fmcp` (dashboards, alerts, annotations) with Bearer token\r\n- **Datadog**: `https:\u002F\u002F\u003Cyour-datadog-mcp-url>\u002Fmcp` with Bearer token\r\n- **Jira**: `https:\u002F\u002F\u003Cyour-jira-mcp-url>\u002Fmcp` with Bearer token\r\n- **PagerDuty**: `https:\u002F\u002F\u003Cyour-pagerduty-mcp-url>\u002Fmcp` with Bearer token\r\n\r\n#### 5. MCP Tool Access\r\n- **All tools**: `mcp__harness__*,mcp__github__*,Read,Edit,Bash,Glob,Grep,Write`\r\n- **Specific tools**: `mcp__github__create_pr,mcp__github__list_files,Read,Write`\r\n\r\n#### 6. Runtime Inputs (optional)\r\n**Only add `inputs` section in the agent spec if user confirms it's needed.**\r\n\r\n## Inputs\r\n\r\n```yaml\r\nagent:\r\n  inputs:\r\n    branch:\r\n      type: string\r\n      default: main\r\n    version:\r\n      type: string\r\n      required: true\r\n    deploy_env:\r\n      type: string\r\n      enum: [dev, staging, prod]\r\n    api_key:\r\n      type: secret\r\n      default: account.my_secret\r\n```\r\n\r\n**Input types:** `string`, `secret`, `boolean`\r\n\r\n**Reference inputs with:** `${{ inputs.branch }}`\r\n\r\nCommon input examples:\r\n- `repo` (string): Repository identifier\r\n- `llmKey` (secret): LLM API key\r\n- `executionId` (string): Pipeline execution ID\r\n- `branch` (string): Branch to analyze\r\n\r\n**Expression syntax:**\r\n```yaml\r\n# Input references\r\n\u003C+inputs.variableName>\r\n\r\n# Connector token\r\n\u003C+inputs.connectorName.token>\r\n\r\n# Step outputs\r\n\u003C+pipeline.stages.STAGE.steps.STEP.output.outputVariables.VAR>\r\n\r\n# Environment variables\r\n\u003C+env.HARNESS_ACCOUNT_ID>\r\n\u003C+env.HARNESS_ORG_ID>\r\n\u003C+env.HARNESS_PROJECT_ID>\r\n\r\n# Alternative syntax for inputs in env blocks\r\n${{inputs.repo}}\r\n```\r\n\r\n### Phase 3: Generate Agent Spec\r\n\r\nUsing the requirements from Phase 2 and defaults from section 3-6, assemble the complete agent YAML specification (`spec` field):\r\n\r\n1. Start with `version: 1` and `agent:` structure\r\n2. Add `clone:` section if task depends on repository\r\n3. Create `stages:` with platform (linux\u002Farm64) and steps\r\n4. For each step, include:\r\n   - Container image and connector\r\n   - Environment variables (Bedrock configuration)\r\n   - `task:` field with step-by-step instructions AND a `## RULES` section at the end containing user preferences\r\n   - `mcp_servers:` based on external services needed\r\n   - `with.allowed_tools:` and `with.log_file:`\r\n   - `max_turns:` adjusted for task complexity (100-200)\r\n5. Add `inputs:` section only if confirmed with user (reference with `${{ inputs.fieldName }}`)\r\n\r\nGenerate complete, valid YAML ready to be used as the `spec` value.\r\n\r\n### Phase 4: Present for Review\r\n\r\nPresent the complete agent configuration to the user:\r\n- Agent metadata (name, description, uid)\r\n- Full spec YAML\r\n- Required secrets and connectors\r\n\r\n**Wait for explicit confirmation before creating\u002Fupdating the agent.**\r\n\r\n### Phase 5: Create or Update Agent\r\n\r\nOnly after confirmation, use `harness_create` to create a new agent or `harness_update` to update an existing one:\r\n\r\n#### Creating a New Agent\r\n\r\n```\r\nCall MCP tool: harness_create\r\nParameters:\r\n  resource_type: \"agent\"\r\n  org_id: \"\u003Corganization>\"\r\n  project_id: \"\u003Cproject>\"\r\n  body: {\r\n    uid: \"\u003Cagent_identifier>\",\r\n    name: \"\u003CAgent Display Name>\",\r\n    description: \"\u003CBrief description of agent purpose>\",\r\n    spec: \"\u003Cagent YAML spec as a string>\",\r\n    wiki: \"\u003Coptional: markdown documentation>\"\r\n  }\r\n```\r\n\r\n**Key fields for creation:**\r\n- `uid` (required): Unique identifier. Auto-generated from `name` if not provided (e.g. \"Code Coverage Agent\" → \"code_coverage_agent\")\r\n- `name` (required): Display name for the agent\r\n- `description` (optional): Brief description\r\n- `spec` (required): The full agent YAML specification as a string (includes `version: 1`, `agent:`, `stages:`, etc.)\r\n- `wiki` (optional): Markdown documentation for the agent\r\n\r\n#### Updating an Existing Agent\r\n\r\n```\r\nCall MCP tool: harness_update\r\nParameters:\r\n  resource_type: \"agent\"\r\n  agent_id: \"\u003Cagent_identifier>\"\r\n  org_id: \"\u003Corganization>\"\r\n  project_id: \"\u003Cproject>\"\r\n  body: {\r\n    name: \"\u003CUpdated Display Name>\",           # optional\r\n    description: \"\u003CUpdated description>\",     # optional\r\n    spec: \"\u003Cupdated agent YAML spec>\",        # optional\r\n    wiki: \"\u003Cupdated markdown docs>\"           # optional\r\n  }\r\n```\r\n\r\n**Key notes for updates:**\r\n- All fields in the body are optional — only provide fields you want to update\r\n- Only custom agents (role='custom') can be updated; system agents cannot be modified\r\n- The `spec` field replaces the entire agent specification when provided\r\n- Use `harness_get` first to retrieve the current agent configuration before updating\r\n\r\n## Agent YAML Extends Pipeline Constructs\r\n\r\n**CRITICAL UNDERSTANDING: Agent YAML extends the traditional Harness pipeline schema. You can use BOTH agent-specific features AND traditional pipeline steps.**\r\n\r\n### What This Means\r\n\r\n1. **Agent-specific features** (new):\r\n   - `agent` step type with `task`, `rules`, `mcp_servers`, `max_turns`\r\n   - Claude Code plugin integration\r\n   - MCP server connections\r\n   - AI-powered autonomous execution\r\n\r\n2. **Traditional pipeline features** (still valid):\r\n   - Shell script steps (`run.shell`, `run.script`)\r\n   - Container plugin steps (`run.container`)\r\n   - Step groups\r\n   - Parallel execution\r\n   - Environment variables\r\n   - Conditional execution\r\n   - All other standard pipeline constructs\r\n   - **Only use these when the requirement needs them or user explicitly requests them — don't add unnecessarily**\r\n   - **For traditional pipeline constructs**: Reference the `\u002Fcreate-pipeline-v1` skill to look up native actions, templates, and step syntax if it's available\r\n\r\n### When to Use Traditional Steps\r\n\r\n- **Shell scripts**: For running git commands, file operations, or custom scripts\r\n- **Container plugins**: For integrating with existing Harness plugins (SonarQube, Snyk, etc.)\r\n- **Mixed workflows**: Combine agent steps with traditional steps in the same pipeline\r\n\r\n### Example: Mixed Agent and Shell Steps\r\n\r\n```yaml\r\nversion: 1\r\nagent:\r\n  stages:\r\n    - name: Build and Analyze\r\n      id: build_analyze\r\n      platform:\r\n        os: linux\r\n        arch: arm64\r\n      steps:\r\n        # Traditional shell step\r\n        - name: Run Tests\r\n          run:\r\n            shell: bash\r\n            script: |-\r\n              go test -cover .\u002F...\r\n              echo \"Tests completed\"\r\n\r\n        # Agent step (AI-powered)\r\n        - id: analyze_coverage\r\n          name: Analyze Coverage with AI\r\n          agent:\r\n            container:\r\n              image: pkg.harness.io\u002Fvrvdt5ius7uwygso8s0bia\u002Fharness-agents\u002Fclaude-code-plugin:main\r\n            env:\r\n              ANTHROPIC_MODEL: arn:aws:bedrock:us-east-1:587817102444:application-inference-profile\u002F7p8sn93lhspw\r\n              AWS_BEARER_TOKEN_BEDROCK: \u003C+secrets.getValue(\"bedrock_api_key\")>\r\n              AWS_REGION: us-east-1\r\n              CLAUDE_CODE_USE_BEDROCK: \"1\"\r\n            task: |\r\n              Analyze the test coverage output and generate improvement recommendations.\r\n\r\n              ## RULES\r\n              - Focus on actionable recommendations\r\n              - Prioritize high-impact improvements\r\n            max_turns: 100\r\n```\r\n\r\n### Schema Validation\r\n\r\nAll agent specs are validated using `harness_schema(resource_type=\"agent-pipeline\")` which supports BOTH:\r\n- Agent-specific constructs (use `path=\"Agent\"` to explore)\r\n- Traditional pipeline constructs (use `path=\"stages\"`, `path=\"steps\"` to explore)\r\n\r\n**If a user asks to add shell steps, container steps, or any traditional pipeline feature, it's perfectly valid to include them in the agent spec.**\r\n\r\n### Chaining Agents Together\r\n\r\n**⚠️ ADVANCED FEATURE: THIS IS FOR ADVANCED USERS ONLY. BUILD SINGLE-AGENT WORKFLOWS FIRST AND ONLY USE AGENT CHAINING WHEN YOU HAVE PUSHED A SINGLE AGENT TO ITS ABSOLUTE LIMIT. SINGLE AGENTS ARE EXTREMELY POWERFUL AND EFFICIENT — MOST TASKS DO NOT REQUIRE CHAINING.**\r\n\r\n**Agents can pass data to each other by writing outputs to fixed file locations and reading from those locations in subsequent steps.**\r\n\r\n#### How Agent Chaining Works\r\n\r\n1. **Agent 1** outputs its results to a fixed file location using `with.log_file`\r\n2. **Agent 2** reads from that file location in its `task` instructions\r\n3. This creates a sequential chain where each agent builds on the previous agent's work\r\n\r\n#### Key Pattern\r\n\r\n```yaml\r\nsteps:\r\n  # First agent - outputs to fixed location\r\n  - id: analyzer\r\n    name: Analyze Code\r\n    agent:\r\n      task: |\r\n        Analyze the codebase and write findings to analysis-report.md\r\n      with:\r\n        allowed_tools: Read,Write,Grep,Glob\r\n        log_file: .agent\u002Foutput\u002Fanalyzer-log.jsonl  # ← Agent 1 outputs here\r\n      max_turns: 100\r\n\r\n  # Second agent - reads from first agent's output\r\n  - id: recommender\r\n    name: Generate Recommendations\r\n    agent:\r\n      task: |\r\n        Read the analysis from .agent\u002Foutput\u002Fanalyzer-log.jsonl  # ← Agent 2 reads here\r\n        and generate actionable recommendations.\r\n      with:\r\n        allowed_tools: Read,Write\r\n        log_file: .agent\u002Foutput\u002Frecommender-log.jsonl\r\n      max_turns: 50\r\n```\r\n\r\n**Important:** The file path (`.agent\u002Foutput\u002Fanalyzer-log.jsonl`) must match exactly between the first agent's `log_file` and the second agent's `task` instructions. This creates the handoff between agents.\r\n\r\n### Adding Custom Skills to Agents\r\n\r\n**IMPORTANT: This is NOT a default feature. Only add custom skills when the user explicitly insists on it.**\r\n\r\nBy default, agents work with the task instructions provided in the `task` field. Custom skills are an advanced feature and should only be added if the user specifically requests them.\r\n\r\n**Example: Adding a Custom Skill**\r\n\r\n```yaml\r\nversion: 1\r\nagent:\r\n  stages:\r\n    - name: Setup and Execute\r\n      id: setup_execute\r\n      platform:\r\n        os: linux\r\n        arch: arm64\r\n      steps:\r\n        # Step 1: Create custom skill (runs BEFORE agent step)\r\n        - id: create_skill\r\n          name: Setup Hello World Skill\r\n          run:\r\n            shell: bash\r\n            script: |\r\n              mkdir -p \u002Fharness\u002F.claude\u002Fskills\u002Fhello-world\r\n              cat > \u002Fharness\u002F.claude\u002Fskills\u002Fhello-world\u002FSKILL.md \u003C\u003C 'EOF'\r\n              ---\r\n              name: hello-world\r\n              description: Responds to greetings with a funny joke\r\n              triggers:\r\n                - hi\r\n                - hello\r\n                - hii claude\r\n              ---\r\n\r\n              You are a greeting assistant.\r\n\r\n              When the user says \"hi\", \"hello\", or \"hii claude\":\r\n              - Respond with \"Hi!\"\r\n              - Include a short funny joke\r\n\r\n              Keep responses short and fun.\r\n              EOF\r\n\r\n        # Step 2: Agent step (can now use the custom skill)\r\n        - id: run_agent\r\n          name: Run Agent with Custom Skill\r\n          agent:\r\n            container:\r\n              image: pkg.harness.io\u002Fvrvdt5ius7uwygso8s0bia\u002Fharness-agents\u002Fclaude-code-plugin:main\r\n            env:\r\n              ANTHROPIC_MODEL: arn:aws:bedrock:us-east-1:587817102444:application-inference-profile\u002F7p8sn93lhspw\r\n              AWS_BEARER_TOKEN_BEDROCK: \u003C+secrets.getValue(\"bedrock_api_key\")>\r\n              AWS_REGION: us-east-1\r\n              CLAUDE_CODE_USE_BEDROCK: \"1\"\r\n            task: |\r\n              Execute the task using the available skills.\r\n\r\n              ## RULES\r\n              - Use the hello-world skill when appropriate\r\n            max_turns: 100\r\n```\r\n\r\n**Key Points:**\r\n- The working directory for the agent is `\u002Fharness`\r\n- Skills path format: `\u002Fharness\u002F.claude\u002Fskills\u002F\u003Cskill-name>\u002FSKILL.md`\r\n- Use heredoc (`\u003C\u003C 'EOF'`) to write multi-line skill files\r\n- The skill file must include valid frontmatter and instructions\r\n- Multiple skills can be created in the same step by repeating the mkdir\u002Fcat commands\r\n\r\n## CRITICAL GUIDELINES\r\n\r\n**These are essential rules you MUST follow when creating\u002Fupdating agents:**\r\n\r\n| Guideline                | Rule                                                                                                                                     |\r\n| --------------------------| ------------------------------------------------------------------------------------------------------------------------------------------|\r\n| **Check existing first** | Always call `harness_list(resource_type=\"agent\")` to see if an existing agent can solve the use case before creating new                 |\r\n| **Updating agents**      | Use `harness_get` to retrieve current config, then `harness_update` (not `harness_create`) to modify. Only custom agents can be updated. |\r\n| **Use schema tool**      | Use `harness_schema(resource_type=\"agent-pipeline\", path=\"...\")` for YAML structure. Use `path` parameter to load specific sections only |\r\n| **Agent spec format**    | The `spec` field contains agent YAML (version: 1, agent:, stages:, etc.) — this is NOT pipeline format                                   |\r\n| **Secrets**              | Reference as `\u003C+secrets.getValue(\"key\")>` — user must create in Harness UI                                                               |\r\n| **Connectors**           | Reference by identifier (e.g. `connector_github_id`, `account.harnessImage`) — must exist before agent execution                         |\r\n| **Multi-stage**          | Steps run sequentially — pass state between stages via files (e.g. INFO.md)                                                              |\r\n| **Quality first**        | Agent quality is paramount — verify YAML structure, validate all references, ensure complete task instructions before creating           |\r\n\r\n\r\n## Examples\r\n\r\n- \"Create an agent that reviews PRs for security issues\" - Gather requirements, generate agent spec with GitHub MCP, create via `harness_create`\r\n- \"Update my code coverage agent to use a different model\" - Fetch agent with `harness_get`, modify spec, update via `harness_update`\r\n- \"Build an agent that runs tests and reports results to Slack\" - Multi-MCP setup with GitHub and Slack servers\r\n- \"Create an autonomous agent to fix failing tests\" - Agent with repo clone, shell steps, and Claude Code plugin\r\n\r\n## Performance Notes\r\n\r\n- Use `harness_schema(resource_type=\"agent-pipeline\", path=\"...\")` with specific `path` values to avoid loading the full 4k+ line schema into context.\r\n- Always check for existing agents with `harness_list` before creating new ones to avoid duplicates.\r\n- Set `max_turns` proportional to task complexity: 100 for simple tasks, 150-200 for complex multi-step workflows.\r\n- Use `depth: 1` for branch clones and `depth: 1000` for PR clones to balance clone speed and diff history.\r\n\r\n## Troubleshooting\r\n\r\n### SCM Provider Detection Failing\r\n\r\n1. Verify `DRONE_REPO_SCM` environment variable is available\r\n2. Check that connector tokens have correct permissions\r\n3. Test with a known SCM provider before adding multi-provider logic\r\n\r\n### Output Variables Not Available\r\n\r\n1. Write outputs using `echo \"KEY=value\" >> $DRONE_OUTPUT`\r\n2. Write secret outputs using `echo \"KEY=value\" >> $HARNESS_OUTPUT_SECRET_FILE`\r\n3. Reference with full path: `\u003C+pipeline.stages.STAGE.steps.STEP.output.outputVariables.KEY>`\r\n\r\n## Best Practices\r\n\r\n- Never hardcode secrets -- use `type: secret` inputs\r\n- Use `type: connector` for authentication rather than raw tokens\r\n- Include meaningful descriptions on all inputs\r\n- Keep stages focused on single responsibilities\r\n- Always include the SCM detection pattern for multi-provider support\r\n- Store secret outputs with `$HARNESS_OUTPUT_SECRET_FILE`, not `$DRONE_OUTPUT`\r\n- Set `depth: 1000` for PR clones to ensure full diff history\r\n- Set `depth: 1` for branch clones to minimize clone time\r\n- Provide detailed step-by-step instructions in `task` field\r\n- Increase `max_turns` in the spec (default: 150) if task is complex.\r\n","# Create Agent\r\n\r\nCreate and update Harness AI agent instances for automated code, build agentic workflows, and infrastructure tasks.\r\n\r\n## Instructions\r\n\r\nFollow this workflow to create or update an agent. **This is INTERACTIVE — show YAML for review and wait for confirmation before creating\u002Fupdating the agent.**\r\n\r\n### Phase 1: Check Existing Solutions First\r\n\r\n**IMPORTANT: Before creating a new agent, check if an existing one can solve the use case.**\r\n\r\n1. **List existing agents** — Call `harness_list` with `resource_type=\"agent\"` (include `org_id` and `project_id` if scoped to a project)\r\n   - Check if any system or custom agents already exist that can handle this task\r\n   - Ask user if they want to use\u002Fmodify an existing agent instead of creating new\r\n2. **For updating existing agents** — Use `harness_get` with `resource_type=\"agent\"` and `agent_id` to retrieve the current agent configuration\r\n   - Review the current `spec`, `name`, `description`, and other fields\r\n   - Identify what needs to be changed (spec, name, description, wiki, logo)\r\n   - Use `harness_update` (not `harness_create`) to update the agent with only the fields that need modification\r\n3. **Refer to agent schema when needed** — If you're not sure about the YAML structure, use `harness_schema` with `resource_type=\"agent-pipeline\"` to explore available fields and sections\r\n   - **Use the `path` parameter to avoid context pollution**: The full schema is 4k+ lines. Load only what you need:\r\n     - `harness_schema(resource_type=\"agent-pipeline\")` → Top-level summary (shows available sections)\r\n     - `harness_schema(resource_type=\"agent-pipeline\", path=\"Agent\")` → Agent structure only\r\n     - `harness_schema(resource_type=\"agent-pipeline\", path=\"stages\")` → Stage definitions only\r\n   - **For operations\u002FAPI metadata**: Use `harness_describe(resource_type=\"agent\")` to see supported operations, filters, and execute actions\r\n   - **CRITICAL**: The agent spec uses first-class `agent` format (version: 1, agent:, stages:, etc.), NOT `pipeline` format\r\n\r\n### Phase 2: Requirements Gathering\r\n\r\nIf creating a new agent or updating an existing one, collect the following before generating YAML:\r\n\r\n#### 1. Agent Metadata\r\n- **Name**: Display name for the agent (e.g. \"Code Coverage Agent\", \"PR Reviewer\")\r\n- **Description**: Brief description of the agent's purpose (optional)\r\n- **UID**: Unique identifier (auto-generated from name if not provided — e.g. \"Code Coverage Agent\" → \"code_coverage_agent\")\r\n\r\n#### 2. Task Details\r\n\r\n**This is an INTERACTIVE requirements gathering process. Ask clarifying questions and verify understanding with the user before proceeding.**\r\n\r\n##### Step 1: Understand the Agent's Purpose\r\n\r\nAsk and clarify the following with the user:\r\n\r\n1. **Agent's exact goal**: What specific outcome should the agent achieve?\r\n   - Examples: \"Increase code coverage to 80%\", \"Review PRs for security vulnerabilities\", \"Generate unit tests for uncovered functions\"\r\n   - Be specific — avoid vague goals like \"improve code quality\"\r\n\r\n2. **Inputs the agent needs**: What data or context does the agent require to start?\r\n   - Repository information? (repo name, branch, PR number)\r\n   - Execution context? (pipeline execution ID, previous step outputs)\r\n   - Configuration? (coverage threshold, target files, exclusion patterns)\r\n   - Secrets? (API keys, tokens for external services)\r\n\r\n3. **Outputs the agent produces**: What artifacts, reports, or actions should result?\r\n   - Files? (COVERAGE.md, test files, reports)\r\n   - External actions? (create PR, post comments, send notifications)\r\n   - Data? (metrics, logs, analysis results)\r\n\r\n4. **What the agent works on**: What files, services, or systems does it interact with?\r\n   - Specific file paths or patterns? (e.g., `pkg\u002F**\u002F*.go`, `src\u002Fservices\u002F`)\r\n   - External services? (GitHub API, Slack, monitoring systems)\r\n   - Databases or APIs? (read-only access, write operations)\r\n\r\n5. **Task workflow**: Understand the user's workflow for the task — what should happen step-by-step (do 1, then 2, then 3, etc.)\r\n\r\n6. **Constraints and preferences**: Any user preferences for completing the task — limitations, rules, or coding standards the agent should follow\r\n   - Examples: \"Use idiomatic Go code\", \"Do not modify existing tests\", \"Keep reports under 10000 characters\"\r\n\r\n7. **Definition of done**: How do you know the agent succeeded?\r\n   - Specific criteria? (\"Coverage increased by X%\", \"All files have tests\")\r\n   - Artifacts created? (\"PR created with tests\", \"COVERAGE.md updated\")\r\n   - Exit conditions? (\"No security vulnerabilities found\", \"All checks passed\")\r\n\r\n##### Step 2: Recommend Configuration\r\n\r\nBased on the requirements gathered in Step 1, recommend specific configurations and verify with the user:\r\n\r\n1. **Task instructions** (`task` field):\r\n   - Break down the goal into detailed step-by-step instructions\r\n   - Include specific commands, file paths, and expected outcomes\r\n   - Reference inputs using `\u003C+inputs.fieldName>` syntax\r\n   - Example: \"1. Run `go test -cover .\u002F...` to measure coverage\\n2. Identify functions below 80% coverage\\n3. Generate tests for uncovered functions\\n4. Create PR with new tests\"\r\n\r\n2. **Runtime inputs** (`inputs` section in spec):\r\n   - Only add if user confirms runtime parameters are needed\r\n   - Map each input to what the agent needs (repo, branch, executionId, thresholds, etc.)\r\n   - Example: `repo` (string), `coverageThreshold` (string), `llmKey` (secret)\r\n\r\n3. **User preferences** (RULES section in `task` field):\r\n   - Convert constraints and coding standards into a dedicated RULES section at the end of the task\r\n   - Format as a markdown section with bullet points\r\n   - Be specific and actionable\r\n   - Example: Add `## RULES\\n- Use idiomatic Go code\\n- Do not modify existing tests\\n- Keep COVERAGE.md under 10000 characters` at the end of the task\r\n\r\n4. **MCP servers** (`mcp_servers` in spec):\r\n   - Identify which external services the agent needs to interact with\r\n   - GitHub? → Recommend GitHub Copilot MCP: `https:\u002F\u002Fapi.githubcopilot.com\u002Fmcp\u002F`\r\n   - Harness platform? → Recommend Harness MCP URL\r\n   - Slack\u002Fnotifications? → Recommend notification MCP\r\n   - Recommend MCPs based on the user's task or workflows\r\n\r\n5. **Secrets** (via `\u003C+secrets.getValue(\"key\")`):\r\n   - List all secrets needed for authentication (GitHub PAT, API keys, tokens)\r\n   - Remind user to create these in Harness UI before running the agent\r\n   - Example: `bedrock_api_key`, `github_pat`, `slack_token`\r\n\r\n6. **Connectors**:\r\n   - GitHub\u002FGitLab\u002FBitbucket connector for repository access\r\n   - Container registry connector for custom images (if needed)\r\n   - Cloud connectors (if agent interacts with AWS\u002FGCP\u002FAzure)\r\n\r\n7. **Tools** (`with.allowed_tools`):\r\n   - Recommend tools based on what the agent needs to do\r\n   - File operations: `Read`, `Write`, `Grep`, `Glob`\r\n   - MCP tools: `mcp__github__*`, `mcp__harness__*` (use `*` for all tools from that MCP)\r\n   - Shell: `Bash`\r\n\r\n**Present this recommended configuration to the user and iterate until confirmed.**\r\n\r\n#### 3. Default Configuration\r\n\r\n**Use these defaults unless user specifies otherwise:**\r\n\r\n**Repository clone:**\r\n- Only add this section if the task depends on a repository\r\n```yaml\r\nclone:\r\n  depth: 1000\r\n  ref:\r\n    type: branch\r\n    name: main\r\n  repo: \u003Crepo>\r\n  connector: \u003Cconnector>\r\n```\r\n\r\n**Platform:**\r\n```yaml\r\nplatform:\r\n  os: linux\r\n  arch: arm64\r\n```\r\n\r\n**Container image:**\r\n- The Claude Code plugin is packaged via this image\r\n```yaml\r\ncontainer:\r\n  image: pkg.harness.io\u002Fvrvdt5ius7uwygso8s0bia\u002Fharness-agents\u002Fclaude-code-plugin:main\r\n```\r\n\r\n**Environment variables (Bedrock configuration):**\r\n```yaml\r\nenv:\r\n  ANTHROPIC_MODEL: arn:aws:bedrock:us-east-1:587817102444:application-inference-profile\u002F7p8sn93lhspw\r\n  AWS_BEARER_TOKEN_BEDROCK: \u003C+secrets.getValue(\"bedrock_api_key\")>\r\n  AWS_REGION: us-east-1\r\n  CLAUDE_CODE_USE_BEDROCK: \"1\"\r\n```\r\n\r\n**Max turns:**\r\n- Depending on task complexity, adjust this in the range from 100 to 200\r\n```yaml\r\nmax_turns: 150\r\n```\r\n\r\n#### 4. MCP Servers\r\n\r\nBased on the MCPs needed (clarified with the user), configure MCP server connections:\r\n\r\n**How to Connect MCP Servers?**\r\n\r\n**Remote MCP Server:**\r\n- If your MCP server is publicly accessible, connect it directly using a Personal Access Token (PAT)\r\n- Create a secret in Harness for the PAT and reference it in the agent YAML\r\n\r\nExample — Remote MCP Server:\r\n```yaml\r\nmcp_servers:\r\n  harness:\r\n    url: https:\u002F\u002F\u003Cyour-ngrok-url>\u002Fmcp\r\n  github:\r\n    url: https:\u002F\u002Fapi.githubcopilot.com\u002Fmcp\u002F\r\n    headers:\r\n      Authorization: Bearer \u003C+secrets.getValue(\"github_pat\")>\r\n```\r\n\r\n**Local MCP Server:**\r\n- Use ngrok to expose your local MCP server so the Harness runner can reach it\r\n\r\nExample — Single MCP Server:\r\n```yaml\r\nmcp_servers:\r\n  harness:\r\n    url: https:\u002F\u002F\u003Cyour-ngrok-url>\u002Fmcp\r\n```\r\n\r\n**Allowing MCP Tools:**\r\n- To allow the coding agent to use MCP tools, add `mcp__name__*` in `allowed_tools`\r\n- Optionally specify a `log_file` for debugging MCP interactions\r\n```yaml\r\nmcp_servers:\r\n  harness:\r\n    url: https:\u002F\u002F\u003Cyour-ngrok-url>\u002Fmcp\r\nwith:\r\n  allowed_tools: Read,Edit,Bash,Glob,Grep,Write,mcp__harness__*\r\n  log_file: .agent\u002Foutput\u002Fmcp-test-log.jsonl\r\n```\r\n\r\n**Common MCP servers:**\r\n- **GitHub\u002FCode\u002FPRs**: `https:\u002F\u002Fapi.githubcopilot.com\u002Fmcp\u002F` with `Bearer \u003C+secrets.getValue(\"github_pat\")>`\r\n- **Harness platform**: `https:\u002F\u002F\u003Cyour-harness-mcp-url>\u002Fmcp` with Bearer token\r\n- **Slack\u002FNotifications**: `https:\u002F\u002F\u003Cyour-slack-mcp-url>\u002Fmcp` with Bearer token\r\n- **Grafana**: `https:\u002F\u002F\u003Cyour-grafana-mcp-url>\u002Fmcp` (dashboards, alerts, annotations) with Bearer token\r\n- **Datadog**: `https:\u002F\u002F\u003Cyour-datadog-mcp-url>\u002Fmcp` with Bearer token\r\n- **Jira**: `https:\u002F\u002F\u003Cyour-jira-mcp-url>\u002Fmcp` with Bearer token\r\n- **PagerDuty**: `https:\u002F\u002F\u003Cyour-pagerduty-mcp-url>\u002Fmcp` with Bearer token\r\n\r\n#### 5. MCP Tool Access\r\n- **All tools**: `mcp__harness__*,mcp__github__*,Read,Edit,Bash,Glob,Grep,Write`\r\n- **Specific tools**: `mcp__github__create_pr,mcp__github__list_files,Read,Write`\r\n\r\n#### 6. Runtime Inputs (optional)\r\n**Only add `inputs` section in the agent spec if user confirms it's needed.**\r\n\r\n## Inputs\r\n\r\n```yaml\r\nagent:\r\n  inputs:\r\n    branch:\r\n      type: string\r\n      default: main\r\n    version:\r\n      type: string\r\n      required: true\r\n    deploy_env:\r\n      type: string\r\n      enum: [dev, staging, prod]\r\n    api_key:\r\n      type: secret\r\n      default: account.my_secret\r\n```\r\n\r\n**Input types:** `string`, `secret`, `boolean`\r\n\r\n**Reference inputs with:** `${{ inputs.branch }}`\r\n\r\nCommon input examples:\r\n- `repo` (string): Repository identifier\r\n- `llmKey` (secret): LLM API key\r\n- `executionId` (string): Pipeline execution ID\r\n- `branch` (string): Branch to analyze\r\n\r\n**Expression syntax:**\r\n```yaml\r\n# Input references\r\n\u003C+inputs.variableName>\r\n\r\n# Connector token\r\n\u003C+inputs.connectorName.token>\r\n\r\n# Step outputs\r\n\u003C+pipeline.stages.STAGE.steps.STEP.output.outputVariables.VAR>\r\n\r\n# Environment variables\r\n\u003C+env.HARNESS_ACCOUNT_ID>\r\n\u003C+env.HARNESS_ORG_ID>\r\n\u003C+env.HARNESS_PROJECT_ID>\r\n\r\n# Alternative syntax for inputs in env blocks\r\n${{inputs.repo}}\r\n```\r\n\r\n### Phase 3: Generate Agent Spec\r\n\r\nUsing the requirements from Phase 2 and defaults from section 3-6, assemble the complete agent YAML specification (`spec` field):\r\n\r\n1. Start with `version: 1` and `agent:` structure\r\n2. Add `clone:` section if task depends on repository\r\n3. Create `stages:` with platform (linux\u002Farm64) and steps\r\n4. For each step, include:\r\n   - Container image and connector\r\n   - Environment variables (Bedrock configuration)\r\n   - `task:` field with step-by-step instructions AND a `## RULES` section at the end containing user preferences\r\n   - `mcp_servers:` based on external services needed\r\n   - `with.allowed_tools:` and `with.log_file:`\r\n   - `max_turns:` adjusted for task complexity (100-200)\r\n5. Add `inputs:` section only if confirmed with user (reference with `${{ inputs.fieldName }}`)\r\n\r\nGenerate complete, valid YAML ready to be used as the `spec` value.\r\n\r\n### Phase 4: Present for Review\r\n\r\nPresent the complete agent configuration to the user:\r\n- Agent metadata (name, description, uid)\r\n- Full spec YAML\r\n- Required secrets and connectors\r\n\r\n**Wait for explicit confirmation before creating\u002Fupdating the agent.**\r\n\r\n### Phase 5: Create or Update Agent\r\n\r\nOnly after confirmation, use `harness_create` to create a new agent or `harness_update` to update an existing one:\r\n\r\n#### Creating a New Agent\r\n\r\n```\r\nCall MCP tool: harness_create\r\nParameters:\r\n  resource_type: \"agent\"\r\n  org_id: \"\u003Corganization>\"\r\n  project_id: \"\u003Cproject>\"\r\n  body: {\r\n    uid: \"\u003Cagent_identifier>\",\r\n    name: \"\u003CAgent Display Name>\",\r\n    description: \"\u003CBrief description of agent purpose>\",\r\n    spec: \"\u003Cagent YAML spec as a string>\",\r\n    wiki: \"\u003Coptional: markdown documentation>\"\r\n  }\r\n```\r\n\r\n**Key fields for creation:**\r\n- `uid` (required): Unique identifier. Auto-generated from `name` if not provided (e.g. \"Code Coverage Agent\" → \"code_coverage_agent\")\r\n- `name` (required): Display name for the agent\r\n- `description` (optional): Brief description\r\n- `spec` (required): The full agent YAML specification as a string (includes `version: 1`, `agent:`, `stages:`, etc.)\r\n- `wiki` (optional): Markdown documentation for the agent\r\n\r\n#### Updating an Existing Agent\r\n\r\n```\r\nCall MCP tool: harness_update\r\nParameters:\r\n  resource_type: \"agent\"\r\n  agent_id: \"\u003Cagent_identifier>\"\r\n  org_id: \"\u003Corganization>\"\r\n  project_id: \"\u003Cproject>\"\r\n  body: {\r\n    name: \"\u003CUpdated Display Name>\",           # optional\r\n    description: \"\u003CUpdated description>\",     # optional\r\n    spec: \"\u003Cupdated agent YAML spec>\",        # optional\r\n    wiki: \"\u003Cupdated markdown docs>\"           # optional\r\n  }\r\n```\r\n\r\n**Key notes for updates:**\r\n- All fields in the body are optional — only provide fields you want to update\r\n- Only custom agents (role='custom') can be updated; system agents cannot be modified\r\n- The `spec` field replaces the entire agent specification when provided\r\n- Use `harness_get` first to retrieve the current agent configuration before updating\r\n\r\n## Agent YAML Extends Pipeline Constructs\r\n\r\n**CRITICAL UNDERSTANDING: Agent YAML extends the traditional Harness pipeline schema. You can use BOTH agent-specific features AND traditional pipeline steps.**\r\n\r\n### What This Means\r\n\r\n1. **Agent-specific features** (new):\r\n   - `agent` step type with `task`, `rules`, `mcp_servers`, `max_turns`\r\n   - Claude Code plugin integration\r\n   - MCP server connections\r\n   - AI-powered autonomous execution\r\n\r\n2. **Traditional pipeline features** (still valid):\r\n   - Shell script steps (`run.shell`, `run.script`)\r\n   - Container plugin steps (`run.container`)\r\n   - Step groups\r\n   - Parallel execution\r\n   - Environment variables\r\n   - Conditional execution\r\n   - All other standard pipeline constructs\r\n   - **Only use these when the requirement needs them or user explicitly requests them — don't add unnecessarily**\r\n   - **For traditional pipeline constructs**: Reference the `\u002Fcreate-pipeline-v1` skill to look up native actions, templates, and step syntax if it's available\r\n\r\n### When to Use Traditional Steps\r\n\r\n- **Shell scripts**: For running git commands, file operations, or custom scripts\r\n- **Container plugins**: For integrating with existing Harness plugins (SonarQube, Snyk, etc.)\r\n- **Mixed workflows**: Combine agent steps with traditional steps in the same pipeline\r\n\r\n### Example: Mixed Agent and Shell Steps\r\n\r\n```yaml\r\nversion: 1\r\nagent:\r\n  stages:\r\n    - name: Build and Analyze\r\n      id: build_analyze\r\n      platform:\r\n        os: linux\r\n        arch: arm64\r\n      steps:\r\n        # Traditional shell step\r\n        - name: Run Tests\r\n          run:\r\n            shell: bash\r\n            script: |-\r\n              go test -cover .\u002F...\r\n              echo \"Tests completed\"\r\n\r\n        # Agent step (AI-powered)\r\n        - id: analyze_coverage\r\n          name: Analyze Coverage with AI\r\n          agent:\r\n            container:\r\n              image: pkg.harness.io\u002Fvrvdt5ius7uwygso8s0bia\u002Fharness-agents\u002Fclaude-code-plugin:main\r\n            env:\r\n              ANTHROPIC_MODEL: arn:aws:bedrock:us-east-1:587817102444:application-inference-profile\u002F7p8sn93lhspw\r\n              AWS_BEARER_TOKEN_BEDROCK: \u003C+secrets.getValue(\"bedrock_api_key\")>\r\n              AWS_REGION: us-east-1\r\n              CLAUDE_CODE_USE_BEDROCK: \"1\"\r\n            task: |\r\n              Analyze the test coverage output and generate improvement recommendations.\r\n\r\n              ## RULES\r\n              - Focus on actionable recommendations\r\n              - Prioritize high-impact improvements\r\n            max_turns: 100\r\n```\r\n\r\n### Schema Validation\r\n\r\nAll agent specs are validated using `harness_schema(resource_type=\"agent-pipeline\")` which supports BOTH:\r\n- Agent-specific constructs (use `path=\"Agent\"` to explore)\r\n- Traditional pipeline constructs (use `path=\"stages\"`, `path=\"steps\"` to explore)\r\n\r\n**If a user asks to add shell steps, container steps, or any traditional pipeline feature, it's perfectly valid to include them in the agent spec.**\r\n\r\n### Chaining Agents Together\r\n\r\n**⚠️ ADVANCED FEATURE: THIS IS FOR ADVANCED USERS ONLY. BUILD SINGLE-AGENT WORKFLOWS FIRST AND ONLY USE AGENT CHAINING WHEN YOU HAVE PUSHED A SINGLE AGENT TO ITS ABSOLUTE LIMIT. SINGLE AGENTS ARE EXTREMELY POWERFUL AND EFFICIENT — MOST TASKS DO NOT REQUIRE CHAINING.**\r\n\r\n**Agents can pass data to each other by writing outputs to fixed file locations and reading from those locations in subsequent steps.**\r\n\r\n#### How Agent Chaining Works\r\n\r\n1. **Agent 1** outputs its results to a fixed file location using `with.log_file`\r\n2. **Agent 2** reads from that file location in its `task` instructions\r\n3. This creates a sequential chain where each agent builds on the previous agent's work\r\n\r\n#### Key Pattern\r\n\r\n```yaml\r\nsteps:\r\n  # First agent - outputs to fixed location\r\n  - id: analyzer\r\n    name: Analyze Code\r\n    agent:\r\n      task: |\r\n        Analyze the codebase and write findings to analysis-report.md\r\n      with:\r\n        allowed_tools: Read,Write,Grep,Glob\r\n        log_file: .agent\u002Foutput\u002Fanalyzer-log.jsonl  # ← Agent 1 outputs here\r\n      max_turns: 100\r\n\r\n  # Second agent - reads from first agent's output\r\n  - id: recommender\r\n    name: Generate Recommendations\r\n    agent:\r\n      task: |\r\n        Read the analysis from .agent\u002Foutput\u002Fanalyzer-log.jsonl  # ← Agent 2 reads here\r\n        and generate actionable recommendations.\r\n      with:\r\n        allowed_tools: Read,Write\r\n        log_file: .agent\u002Foutput\u002Frecommender-log.jsonl\r\n      max_turns: 50\r\n```\r\n\r\n**Important:** The file path (`.agent\u002Foutput\u002Fanalyzer-log.jsonl`) must match exactly between the first agent's `log_file` and the second agent's `task` instructions. This creates the handoff between agents.\r\n\r\n### Adding Custom Skills to Agents\r\n\r\n**IMPORTANT: This is NOT a default feature. Only add custom skills when the user explicitly insists on it.**\r\n\r\nBy default, agents work with the task instructions provided in the `task` field. Custom skills are an advanced feature and should only be added if the user specifically requests them.\r\n\r\n**Example: Adding a Custom Skill**\r\n\r\n```yaml\r\nversion: 1\r\nagent:\r\n  stages:\r\n    - name: Setup and Execute\r\n      id: setup_execute\r\n      platform:\r\n        os: linux\r\n        arch: arm64\r\n      steps:\r\n        # Step 1: Create custom skill (runs BEFORE agent step)\r\n        - id: create_skill\r\n          name: Setup Hello World Skill\r\n          run:\r\n            shell: bash\r\n            script: |\r\n              mkdir -p \u002Fharness\u002F.claude\u002Fskills\u002Fhello-world\r\n              cat > \u002Fharness\u002F.claude\u002Fskills\u002Fhello-world\u002FSKILL.md \u003C\u003C 'EOF'\r\n              ---\r\n              name: hello-world\r\n              description: Responds to greetings with a funny joke\r\n              triggers:\r\n                - hi\r\n                - hello\r\n                - hii claude\r\n              ---\r\n\r\n              You are a greeting assistant.\r\n\r\n              When the user says \"hi\", \"hello\", or \"hii claude\":\r\n              - Respond with \"Hi!\"\r\n              - Include a short funny joke\r\n\r\n              Keep responses short and fun.\r\n              EOF\r\n\r\n        # Step 2: Agent step (can now use the custom skill)\r\n        - id: run_agent\r\n          name: Run Agent with Custom Skill\r\n          agent:\r\n            container:\r\n              image: pkg.harness.io\u002Fvrvdt5ius7uwygso8s0bia\u002Fharness-agents\u002Fclaude-code-plugin:main\r\n            env:\r\n              ANTHROPIC_MODEL: arn:aws:bedrock:us-east-1:587817102444:application-inference-profile\u002F7p8sn93lhspw\r\n              AWS_BEARER_TOKEN_BEDROCK: \u003C+secrets.getValue(\"bedrock_api_key\")>\r\n              AWS_REGION: us-east-1\r\n              CLAUDE_CODE_USE_BEDROCK: \"1\"\r\n            task: |\r\n              Execute the task using the available skills.\r\n\r\n              ## RULES\r\n              - Use the hello-world skill when appropriate\r\n            max_turns: 100\r\n```\r\n\r\n**Key Points:**\r\n- The working directory for the agent is `\u002Fharness`\r\n- Skills path format: `\u002Fharness\u002F.claude\u002Fskills\u002F\u003Cskill-name>\u002FSKILL.md`\r\n- Use heredoc (`\u003C\u003C 'EOF'`) to write multi-line skill files\r\n- The skill file must include valid frontmatter and instructions\r\n- Multiple skills can be created in the same step by repeating the mkdir\u002Fcat commands\r\n\r\n## CRITICAL GUIDELINES\r\n\r\n**These are essential rules you MUST follow when creating\u002Fupdating agents:**\r\n\r\n| Guideline                | Rule                                                                                                                                     |\r\n| --------------------------| ------------------------------------------------------------------------------------------------------------------------------------------|\r\n| **Check existing first** | Always call `harness_list(resource_type=\"agent\")` to see if an existing agent can solve the use case before creating new                 |\r\n| **Updating agents**      | Use `harness_get` to retrieve current config, then `harness_update` (not `harness_create`) to modify. Only custom agents can be updated. |\r\n| **Use schema tool**      | Use `harness_schema(resource_type=\"agent-pipeline\", path=\"...\")` for YAML structure. Use `path` parameter to load specific sections only |\r\n| **Agent spec format**    | The `spec` field contains agent YAML (version: 1, agent:, stages:, etc.) — this is NOT pipeline format                                   |\r\n| **Secrets**              | Reference as `\u003C+secrets.getValue(\"key\")>` — user must create in Harness UI                                                               |\r\n| **Connectors**           | Reference by identifier (e.g. `connector_github_id`, `account.harnessImage`) — must exist before agent execution                         |\r\n| **Multi-stage**          | Steps run sequentially — pass state between stages via files (e.g. INFO.md)                                                              |\r\n| **Quality first**        | Agent quality is paramount — verify YAML structure, validate all references, ensure complete task instructions before creating           |\r\n\r\n\r\n## Examples\r\n\r\n- \"Create an agent that reviews PRs for security issues\" - Gather requirements, generate agent spec with GitHub MCP, create via `harness_create`\r\n- \"Update my code coverage agent to use a different model\" - Fetch agent with `harness_get`, modify spec, update via `harness_update`\r\n- \"Build an agent that runs tests and reports results to Slack\" - Multi-MCP setup with GitHub and Slack servers\r\n- \"Create an autonomous agent to fix failing tests\" - Agent with repo clone, shell steps, and Claude Code plugin\r\n\r\n## Performance Notes\r\n\r\n- Use `harness_schema(resource_type=\"agent-pipeline\", path=\"...\")` with specific `path` values to avoid loading the full 4k+ line schema into context.\r\n- Always check for existing agents with `harness_list` before creating new ones to avoid duplicates.\r\n- Set `max_turns` proportional to task complexity: 100 for simple tasks, 150-200 for complex multi-step workflows.\r\n- Use `depth: 1` for branch clones and `depth: 1000` for PR clones to balance clone speed and diff history.\r\n\r\n## Troubleshooting\r\n\r\n### SCM Provider Detection Failing\r\n\r\n1. Verify `DRONE_REPO_SCM` environment variable is available\r\n2. Check that connector tokens have correct permissions\r\n3. Test with a known SCM provider before adding multi-provider logic\r\n\r\n### Output Variables Not Available\r\n\r\n1. Write outputs using `echo \"KEY=value\" >> $DRONE_OUTPUT`\r\n2. Write secret outputs using `echo \"KEY=value\" >> $HARNESS_OUTPUT_SECRET_FILE`\r\n3. Reference with full path: `\u003C+pipeline.stages.STAGE.steps.STEP.output.outputVariables.KEY>`\r\n\r\n## Best Practices\r\n\r\n- Never hardcode secrets -- use `type: secret` inputs\r\n- Use `type: connector` for authentication rather than raw tokens\r\n- Include meaningful descriptions on all inputs\r\n- Keep stages focused on single responsibilities\r\n- Always include the SCM detection pattern for multi-provider support\r\n- Store secret outputs with `$HARNESS_OUTPUT_SECRET_FILE`, not `$DRONE_OUTPUT`\r\n- Set `depth: 1000` for PR clones to ensure full diff history\r\n- Set `depth: 1` for branch clones to minimize clone time\r\n- Provide detailed step-by-step instructions in `task` field\r\n- Increase `max_turns` in the spec (default: 150) if task is complex.\r\n",{"name":5,"license":15,"metadata":49,"description":7,"compatibility":53},{"author":50,"version":51,"mcp-server":52},"Harness","1.0.0","harness-mcp-v2","Requires Harness MCP v2 server (harness-mcp-v2)","main","0d1434f89f4bc6b07e9d272accd8c1013768820f","archive\u002Fskill-md-reviewed\u002Fsha256\u002Fbb\u002Fbb8857a56e47919d3f4dd28395823167bc209bc0c90e6717ae3a308966b3e4d0",0,"https:\u002F\u002Fgithub.com\u002Fzapabob\u002FSkills","https:\u002F\u002Fgithub.com\u002Fzapabob","The Open University of JAPAN　2019-now\r\n\r\nTokyo University of Science　2007-2010","2026-10-26 16:29:01",{"source":8,"skillName":5,"commands":63,"prompt":73,"zipAvailable":74},[64,67,70],{"tool":65,"command":66},"npx","npx skills add zapabob\u002FSkills --skill create-agent",{"tool":68,"command":69},"bunx","bunx skills add zapabob\u002FSkills --skill create-agent",{"tool":71,"command":72},"pnpm","pnpm dlx skills add zapabob\u002FSkills --skill create-agent","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fzapabob\u002FSkills\u002Fblob\u002Fmain\u002Farchive\u002Fskill-md-reviewed\u002Fsha256\u002Fbb\u002Fbb8857a56e47919d3f4dd28395823167bc209bc0c90e6717ae3a308966b3e4d0\u002FSKILL.md",true,[],[77,112,143,170,197,214],{"skillNo":78,"name":79,"nameZh":6,"description":80,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":81,"licenseFileUrl":6,"sourceHtmlUrl":82,"categories":83,"keywords":93,"publishedAt":44},"01M6GJTE1GESGGF9K028Y7753E","xurl","X\u002FTwitter via xurl CLI: post, search, DM, media, v2 API.","MIT","https:\u002F\u002Fgithub.com\u002Fzapabob\u002FSkills\u002Fblob\u002Fmain\u002Fregistry\u002Fskills\u002Fxurl\u002Fvariants\u002Fhermes-agent\u002FSKILL.md",[84,87,88],{"categoryNo":85,"categoryName":86,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":89,"categoryName":90,"taxonomyType":91,"taxonomyTypeDesc":92},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[79,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,54,109,110,111],"openclaw","macos","cli","github","linux","windows","official","search","https","social-media","api","Media","hermes","hermes agent","twitter","social","via","post",{"skillNo":113,"name":114,"nameZh":6,"description":115,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":81,"licenseFileUrl":6,"sourceHtmlUrl":116,"categories":117,"keywords":129,"publishedAt":44},"01M6GJT8S1PXQ8WPXT1HSNBWH2","writing-plans","Write implementation plans: bite-sized tasks, paths, code.","https:\u002F\u002Fgithub.com\u002Fzapabob\u002FSkills\u002Fblob\u002Fmain\u002Fregistry\u002Fskills\u002Fwriting-plans\u002Fvariants\u002Fhermes-agent\u002FSKILL.md",[118,121,124,125,126],{"categoryNo":119,"categoryName":120,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":122,"categoryName":123,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":89,"categoryName":90,"taxonomyType":91,"taxonomyTypeDesc":92},{"categoryNo":127,"categoryName":128,"taxonomyType":91,"taxonomyTypeDesc":92},"01JBSEEDCAT000000000000036","内容创作者",[130,131,132,133,95,43,98,38,99,134,26,135,34,136,137,138,139,140,141,142],"writing","writing plans","plans","design","documentation","development","planning","code-review","subagent","write","superpowers","paths","test-driven-development",{"skillNo":144,"name":145,"nameZh":6,"description":146,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":81,"licenseFileUrl":6,"sourceHtmlUrl":147,"categories":148,"keywords":152,"publishedAt":44},"01M6GJST0H5X7WHBJ3BZK0DVKH","whisper","OpenAI's general-purpose speech recognition model. Supports 99 languages, transcription, translation to English, and language identification. Six model sizes from tiny (39M params) to large (1550M params). Use for speech-to-text, podcast transcription, or multilingual audio processing. Best for robust, multilingual ASR.","https:\u002F\u002Fgithub.com\u002Fzapabob\u002FSkills\u002Fblob\u002Fmain\u002Fregistry\u002Fskills\u002Fwhisper\u002Fvariants\u002Fhermes-agent-optional\u002FSKILL.md",[149],{"categoryNo":150,"categoryName":151,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000016","图像与多媒体",[145,95,98,153,154,155,156,157,158,159,160,161,162,163,164,165,166,167,168,169],"openai","speech","multimodal","Transformers","ASR","Audio","text","model","speech recognition","use","general","multilingual","translation","english","identification","processing","Audio Processing",{"skillNo":171,"name":172,"nameZh":6,"description":173,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":81,"licenseFileUrl":6,"sourceHtmlUrl":174,"categories":175,"keywords":179,"publishedAt":44},"01M6GJSMRQ8EETZTYMG72P70EA","weights-and-biases","W&B: log ML experiments, sweeps, model registry, dashboards.","https:\u002F\u002Fgithub.com\u002Fzapabob\u002FSkills\u002Fblob\u002Fmain\u002Fregistry\u002Fskills\u002Fweights-and-biases\u002Fvariants\u002Fhermes-agent\u002FSKILL.md",[176],{"categoryNo":177,"categoryName":178,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000013","分析与可视化",[180,95,181,182,99,183,184,185,186,187,188,160,189,190,191,192,193,194,195,196],"weights and biases","tensorflow","experiments","pytorch","visualization","registry","real-time","tuning","dashboards","experiment","log","time","Experiment Tracking","Model Registry","Hyperparameter Tuning","WandB","Real-Time Visualization",{"skillNo":198,"name":199,"nameZh":6,"description":200,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":81,"licenseFileUrl":6,"sourceHtmlUrl":201,"categories":202,"keywords":204,"publishedAt":44},"01M6GJS19KDPRY112JTR326S06","watchers","Poll RSS, JSON APIs, and GitHub with watermark dedup.","https:\u002F\u002Fgithub.com\u002Fzapabob\u002FSkills\u002Fblob\u002Fmain\u002Fregistry\u002Fskills\u002Fwatchers\u002Fvariants\u002Fhermes-agent-optional\u002FSKILL.md",[203],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[199,95,205,97,98,206,207,208,209,210,211,106,107,212,213],"terminal","automation","http","monitoring","cron","json","rss","devops","with",{"skillNo":215,"name":216,"nameZh":6,"description":217,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":81,"licenseFileUrl":6,"sourceHtmlUrl":218,"categories":219,"keywords":222,"publishedAt":44},"01M6GJRHJD2A6Q830SWF9W48BC","serving-llms-vllm","vLLM: high-throughput LLM serving, OpenAI API, quantization.","https:\u002F\u002Fgithub.com\u002Fzapabob\u002FSkills\u002Fblob\u002Fmain\u002Fregistry\u002Fskills\u002Fvllm\u002Fvariants\u002Fhermes-agent\u002FSKILL.md",[220,221],{"categoryNo":85,"categoryName":86,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":89,"categoryName":90,"taxonomyType":91,"taxonomyTypeDesc":92},[223,224,225,98,226,153,227,228,229,156,230,104,231,232,233,234,235,236,237,238],"llms","vLLM","serving llms vllm","research","openai api","tensor","Inference Serving","Production","llm serving","High Throughput","PagedAttention","Continuous Batching","Quantization","Tensor Parallelism","high-throughput","throughput"]