From harness-sdlc-suite
Software delivery lifecycle domain skill suite for the harness framework. Index skill that provides domain profile routing, delivery pipeline phases, and references to all SDLC domain skills. Activated when any SDLC suite domain profile is selected (software, architecture, business_analysis, solution_architecture, ops).
How this skill is triggered — by the user, by Claude, or both
Slash command
/harness-sdlc-suite:harness-sdlc-suiteThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
> **Domain registry for software delivery.** This index skill routes to the correct domain skill based on the `domain_profile` declared in `state.json` or `spec.md`. It also defines the end-to-end delivery pipeline that connects all domain skills.
Domain registry for software delivery. This index skill routes to the correct domain skill based on the
domain_profiledeclared instate.jsonorspec.md. It also defines the end-to-end delivery pipeline that connects all domain skills.
Each domain declares 4 primary evaluation criteria, artifact taxonomy, verification methods, and stakeholder lens.
| Profile | Criteria | Artifact Types | Stakeholder Lens |
|---|---|---|---|
software (default) | product_depth, functionality, visual_design, code_quality | Code, tests, configs, UI | End users, developers |
enterprise_architecture | coherence, standards_compliance, stakeholder_coverage, feasibility | ADRs, capability maps, diagrams | Enterprise architects, CTO |
business_analysis | completeness, traceability, stakeholder_alignment, feasibility | BRDs, use cases, process maps | Business owners, PMs |
solution_architecture | design_coherence, technical_depth, integration_clarity, implementability | HLDs, API specs, data models, C4 diagrams | Solution architects, tech leads |
ops | operational_readiness, automation_coverage, reliability_design, security_posture | IaC configs, pipelines, runbooks, dashboards | SREs, platform engineers, DevOps |
Based on domain_profile in state.json or spec.md, load the matching domain skill:
domain_profile | Skill Name | Relative Path |
|---|---|---|
software | harness-sdlc | ../harness-sdlc/SKILL.md |
enterprise_architecture | harness-ea | ../harness-ea/SKILL.md |
business_analysis | harness-ba | ../harness-ba/SKILL.md |
solution_architecture | harness-sa | ../harness-sa/SKILL.md |
ops | harness-ops | ../harness-ops/SKILL.md |
If domain_profile is custom, do not load any domain skill from this suite -- the project defines its own criteria inline in spec.md.
Domain skills map to phases in a delivery workflow. Not every project needs every phase -- the planner routes based on project type.
Customer Request
|
+- Phase 1: Discovery & Intake (harness core -- /start + planner)
+- Phase 2: Business Analysis (harness-ba)
+- Phase 3: Enterprise Architecture (harness-ea)
+- Phase 4: Solution Architecture (harness-sa)
+- Phase 5: Project Planning (harness core -- planner + coordinator)
+- Phase 6: Software Development (harness-sdlc)
+- Phase 7: Testing & QA (harness-sdlc evaluator)
+- Phase 8: Deployment & Handover (harness-ops)
|
v
Delivered Product
| Project Type | Phases | Example |
|---|---|---|
| Quick prototype | 1 -> 6 | "Build me a CLI tool" |
| Internal tool | 1 -> 2 -> 4 -> 6 | "Automate our docket submissions" |
| Enterprise system | 1 -> 2 -> 3 -> 4 -> 6 -> 8 | "Modernize our claims platform" |
| Architecture only | 1 -> 2 -> 3 | "Design our target-state EA" |
Each phase is a separate harness run (/start -> /run -> /release). Each run's output becomes the next run's input context.
| Skill | Domain | Profile | What it provides |
|---|---|---|---|
harness-sdlc | Software Development | software | Methodology selection, testing strategy, build/runtime verification, evaluation criteria anchors |
harness-ea | Enterprise Architecture | enterprise_architecture | Architecture methodology (TOGAF/Zachman/FEAF), deliverable verification, TOGAF phase gates, evaluation criteria anchors |
harness-ba | Business Analysis | business_analysis | BA methodology (Waterfall/Agile/Lean/Design Thinking/Six Sigma), requirements traceability, BRD verification, evaluation criteria anchors |
harness-sa | Solution Architecture | solution_architecture | SA methodology (C4/Arc42/4+1/DDD/Microservices), API design verification, NFR compliance, evaluation criteria anchors |
harness-ops | Deployment & Ops | ops | Ops methodology (GitOps/Platform Engineering/SRE/DevOps/IaC), deployment readiness, runbook verification, evaluation criteria anchors |
Domain skills are loaded automatically when the matching domain profile is selected during /harness:start.
A project can declare a primary profile + optional secondary profile. The evaluator scores both sets of criteria. For example, a project with primary: software and secondary: ops would score product_depth, functionality, visual_design, code_quality (from software) AND operational_readiness, automation_coverage, reliability_design, security_posture (from ops).
The source_requirement field in features.json links features to original business needs. This is particularly relevant for business_analysis, enterprise_architecture, and solution_architecture profiles where requirements traceability is a core evaluation criterion. Deliverables are classified as: primary, supporting, governance. The stakeholder lens influences how the evaluator grades quality.
When a project spans multiple delivery phases, each phase must produce defined outputs before the next phase can start. This protocol governs what crosses phase boundaries.
| Phase | Owning Skill | Required Output Artifacts | Format |
|---|---|---|---|
| 1. Discovery & Intake | harness core (planner) | features.json, spec.md, state.json | JSON + Markdown in .harness/ |
| 2. Business Analysis | harness-ba | BRD, use case catalog, requirements traceability matrix | Markdown deliverables + updated features.json |
| 3. Enterprise Architecture | harness-ea | Capability map, target-state architecture, ADRs | Markdown deliverables + updated features.json |
| 4. Solution Architecture | harness-sa | HLD, API specs, data model, C4 diagrams | Markdown deliverables + updated features.json |
| 5. Project Planning | harness core (coordinator) | Decomposition, sprint plan, state.json with round targets | JSON + Markdown in .harness/ |
| 6. Software Development | harness-sdlc | Working code, tests, build artifacts | Code + .harness/sprints/ artifacts |
| 7. Testing & QA | harness-sdlc (evaluator) | Evaluation reports, test results, NN-evaluation.json | JSON + Markdown in .harness/sprints/ |
| 8. Deployment & Handover | harness-ops | Deployment configs, runbooks, release artifacts | IaC configs + Markdown + release.json |
Phases are sequential by default. The output of each phase is the input context for the next.
| Dependency | Relationship | Notes |
|---|---|---|
| Phase 1 -> Phase 2 | Sequential | spec.md and features.json feed BA analysis |
| Phase 2 -> Phase 3 | Sequential | BRD and requirements feed EA design |
| Phase 3 -> Phase 4 | Sequential | Target-state architecture constrains solution design |
| Phase 2 -> Phase 4 | Parallel-eligible | SA can start from BRD if EA is not needed (e.g., internal tools) |
| Phase 4 -> Phase 5 | Sequential | HLD informs sprint decomposition and feature ordering |
| Phase 5 -> Phase 6 | Sequential | Sprint plan drives development rounds |
| Phase 6 -> Phase 7 | Sequential | Code must exist before evaluation |
| Phase 7 -> Phase 8 | Sequential | Passing evaluation required before deployment |
The Phase Routing table (above) shows which phases are included per project type. Skipped phases do not produce artifacts, and downstream phases accept the most recent upstream output as input.
Phase handoff uses the existing .harness/ artifact layout:
features.json carries forward across all phases, with each phase updating feature status and evidence.spec.md is the cross-phase contract -- downstream phases read it but do not modify it.sprints/ directory with contracts, evaluations, and builder reports.progress.md as input context.When a downstream phase discovers that an upstream phase's outputs are insufficient:
NN-evaluation.md.progress.md referencing the upstream phase and the specific missing artifact or content.The primary_scores object in NN-evaluation.json uses 4 keys determined by the active domain profile. Replace the <criterion_N> placeholders from patterns.md with the exact keys below.
| Profile | criterion_1 | criterion_2 | criterion_3 | criterion_4 |
|---|---|---|---|---|
software | product_depth | functionality | visual_design | code_quality |
enterprise_architecture | coherence | standards_compliance | stakeholder_coverage | feasibility |
business_analysis | completeness | traceability | stakeholder_alignment | feasibility |
solution_architecture | design_coherence | technical_depth | integration_clarity | implementability |
ops | operational_readiness | automation_coverage | reliability_design | security_posture |
The custom profile defines its own 4 keys inline in the spec.md Domain Profile section. The evaluator reads those keys at evaluation time and uses them as primary_scores keys in NN-evaluation.json.
Each domain profile defines what constitutes "runtime verification" for its artifact types. The evaluator uses the method below matching the active domain_profile.
| Profile | Verification Method | What to Check | Tooling |
|---|---|---|---|
software | Build + runtime + browser | App compiles, starts, responds to HTTP, UI renders correctly | Build tools, curl/HTTP, Playwright/browser |
enterprise_architecture | Deliverable completeness + cross-reference integrity | Required docs exist per phase, internal references resolve, no dangling IDs | Grep, file existence checks |
business_analysis | Deliverable completeness + scenario walkthrough | Required sections present, requirement IDs trace end-to-end, no orphaned requirements | Grep, traceability matrix validation |
solution_architecture | Deliverable completeness + contract validation | Design docs exist, API specs parse, cross-references resolve, ADRs cover key decisions | Grep, schema validation (OpenAPI/AsyncAPI) |
ops | Config validation + dry-run + completeness | IaC configs lint-clean, pipeline definitions parse, runbooks have required sections | Linters (terraform validate, kubeval), file checks |
The custom profile defines its own verification method in spec.md. When no domain-specific tooling is available, the evaluator falls back to deliverable completeness checks: file existence and required section presence.
npx claudepluginhub xuzhijie-ownself/harness --plugin harness-sdlc-suiteCreates, edits, and optimizes skills for Claude Code, including drafting, evaluating with test prompts, iterating on performance, and improving skill descriptions for better triggering accuracy.