agentsclimarketplace

Manage idp

Skill harness/harness-skills/skills/manage-idp

Manage Harness Internal Developer Portal (IDP) resources via MCP. Create service catalog templates, configure self-service environment provisioning workflows, generate service documentation, create Architecture Decision Records (ADRs), and design developer onboarding workflows. Use when asked to set up a service catalog, create self-service workflows, generate service docs, write ADRs, or onboard new developers. Do NOT use for service scorecards (use scorecard-review instead). Trigger phrases: service catalog, self-service, developer portal, IDP, onboarding workflow, ADR, architecture decision, service documentation, catalog template, developer experience, backstage.From its SKILL.md

Install
npx -y skills add harness/harness-skills --skill manage-idp

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

What its file declares

Copied from the file, not written here

The file declares its own license as Apache-2.0. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

6.8 KB, ~1.3k tokens by cl100k_base, as published. Nobody here has run it

Manage IDP

Create service catalog templates, self-service workflows, documentation, ADRs, and developer onboarding flows in Harness Internal Developer Portal.

Instructions

Step 1: Establish Scope

Confirm the user's org and project context.

Call MCP tool: harness_list
Parameters:
  resource_type: "project"
  org_id: "<organization>"

Step 2: Identify the IDP Task

Determine which IDP workflow the user needs:

  1. Service Catalog Template -- Standardized microservice template with scaffolding, CI/CD, and observability
  2. Self-Service Environment Provisioning -- On-demand environment creation with IaC and RBAC controls
  3. Service Documentation -- Generate catalog-info.yaml, API docs, and architecture overviews
  4. Architecture Decision Record (ADR) -- Structured decision documentation
  5. Developer Onboarding -- Automated Day 1 onboarding workflow

Step 3: Create Service Catalog Template

Gather from the user:

  • Technology stack (Node.js, Java, Python, Go, etc.)
  • Service pattern (REST API, gRPC, event-driven, etc.)
  • Container registry for Docker images
  • Observability stack (Datadog, Prometheus, etc.)

Template components to generate:

  1. Application scaffolding with standard dependencies
  2. CI pipeline: build, test, security scan, Docker build and push
  3. CD pipeline: deploy to dev, staging, production with approvals
  4. Observability: health endpoints, metrics, structured logging, dashboards
  5. catalog-info.yaml with ownership metadata and SLO links
Call MCP tool: harness_create
Parameters:
  resource_type: "template"
  org_id: "<organization>"
  project_id: "<project>"
  body:
    name: "<stack>-microservice-template"
    identifier: "<stack>_microservice_template"
    versionLabel: "1.0.0"
    type: "Pipeline"
    yaml: |
      template:
        name: <stack>-microservice-template
        identifier: <stack>_microservice_template
        versionLabel: "1.0.0"
        type: Pipeline
        spec:
          stages:
            - stage:
                name: Build
                type: CI
                spec:
                  # Build, test, scan, push
            - stage:
                name: Deploy Dev
                type: Deployment
                spec:
                  # Deploy to dev environment

Step 4: Create Self-Service Environment Provisioning

Gather from the user:

  • Environment type (dev, staging, QA, ephemeral)
  • Cloud provider and IaC tool (Terraform, Pulumi, CloudFormation)
  • Max concurrent environments per developer
  • TTL for ephemeral environments

Design the workflow with:

  • Pre-approved infrastructure modules
  • Database provisioning with test data seeding
  • Secret injection from Harness Secrets or Vault
  • RBAC: developer can create/destroy own environments
  • Cost controls: TTL-based auto-cleanup, budget caps

Step 5: Generate Service Documentation

When asked to create documentation, gather:

  • Service name, team, type (backend, frontend, data pipeline)
  • Tech stack, repo URL, environments
  • API endpoints and dependencies

Generate:

  1. catalog-info.yaml -- Backstage-compatible service registration
  2. API documentation -- Endpoint inventory with request/response schemas
  3. Architecture overview -- Component diagram, data flow, dependencies
  4. Operational guide -- Deployment, monitoring, incident response links

Step 6: Create Architecture Decision Record (ADR)

Gather from the user:

  • Decision title and context
  • Options considered with pros/cons
  • Decision made and rationale
  • Consequences and follow-up actions

Format as standard ADR:

  • Status (Proposed, Accepted, Deprecated, Superseded)
  • Context, Decision, Consequences sections
  • Link to related ADRs if applicable

Step 7: Design Developer Onboarding Workflow

Gather from the user:

  • New engineer's role, team, and tech stack
  • Required access (repos, environments, tools)
  • Mentorship and buddy program details

Design a self-service onboarding workflow with:

  • Access provisioning (GitHub org, Harness project, cloud accounts)
  • CDE setup with pre-configured workspace
  • First task assignment with guided walkthrough
  • Week 1 and Week 2 milestone checklists

Examples

  • "Create a microservice template for our Node.js services" -- Generate service catalog template with CI/CD, observability, and catalog-info.yaml
  • "Set up self-service environments for developers" -- Create IDP workflow for on-demand environment provisioning
  • "Generate documentation for the checkout-service" -- Create catalog-info.yaml, API docs, and architecture overview
  • "Write an ADR for our migration from REST to gRPC" -- Create structured ADR with context, decision, and consequences
  • "Design an onboarding workflow for new backend engineers" -- Create Day 1 self-service workflow with access, CDE, and milestones

Performance Notes

  • Service catalog templates should be tested end-to-end before publishing -- a broken template degrades developer trust.
  • Self-service environments need cost guardrails (TTL, budget caps) to prevent cloud spend overruns.
  • catalog-info.yaml must conform to Backstage entity schema -- validate before registering.
  • ADRs should reference the IDP portal URL so they are discoverable alongside the service catalog.
  • Onboarding workflows should be idempotent -- re-running should not create duplicate resources.

Troubleshooting

Template Not Appearing in Catalog

  • Verify the template YAML is valid and the identifier matches the directory name
  • Check that the template is published (not draft) and the version label is set
  • Confirm the user has read access to the org/project where the template lives

Self-Service Workflow Failing

  • Check IaC module permissions -- the service account needs create/destroy access in the target cloud
  • Verify secret references are resolvable in the target project scope
  • Check TTL cleanup jobs are not conflicting with active environments

Documentation Out of Date

  • Regenerate catalog-info.yaml when ownership or dependencies change
  • Link API docs to the CI pipeline so they auto-update on merge

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Keep looking

Skills are one crate of 326,871. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.