Skip to main content

Build Artifact Chain

Use when starting a new build. Enforce artifact gates. For every new product, service, major feature, build system, or independently deliverable capability, create and version these artifacts in order:

  1. intent.md — confirmed outcome, users, why now, measurable success, constraints, authority, and explicit non-goals. Interview until the owner explicitly confirms it.
  2. capability-map.md — stable kebab-case capability IDs, one owner per decision/state, boundaries, dependencies, and executable build order. Obtain explicit owner approval.
  3. Detailed specification — derive only from the approved intent and capability map. Include master architecture, one bounded module spec per capability, normative schemas/contracts, acceptance IDs, migration, reliability, security, operations, backup/recovery, and deterministic validation. Obtain explicit owner approval.
  4. Implementation plan — derive only from the approved specification. Every task names files, interfaces, RED/GREEN evidence, verification commands, dependency order, rollback, and review gate. Obtain explicit owner approval before implementation.

Do not write the plan in parallel with the specification. Do not implement from intent or the capability map alone. Changes discovered later update the upstream artifact first and then regenerate downstream impacts.

Keep all four artifact classes in the product repository and reference their exact revision from tasks, PRs, and receipts. Attach every available document directly to the Slack message sent to the owner; a filesystem path alone is not delivery.

Use role names only for workflow actors. Provider/model bindings remain configuration and machine-readable receipt data.

For Implementer work involving an external library, framework, SDK, package, or API, require the context7-mcp skill and connected Context7 tools before coding. Record the resolved library ID, relevant version, and queried topic in the handoff; if coverage is inadequate, record the gap and use the official current source.

Apply ponytail: reuse existing platform capabilities before adding infrastructure, and stop at the smallest architecture that satisfies the approved contracts. Never simplify away trust-boundary validation, durability, recovery, review independence, or human-only gates.

Source: jknash/hermes-shared-skills · branch hermes-jkdev001 @ 1d0d545c3970 · skills/engineering/build-artifact-chain/ · view source · Imported 2026-10-04. Supporting files (references, scripts) remain in the source repository.

version 1.0.0.

Published by Muse · 2026-10-04.