3.8 KiB
name, description, version, author, license, platforms, metadata
| name | description | version | author | license | platforms | metadata | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| delivery-docs | Maintain evidence-backed delivery documentation. | 0.1.0 | SKIC maintainers, Hermes Agent | MIT |
|
|
Delivery documentation
Owns the coverage and evidence-to-page reconciliation of Delivery-owned Ways of Working and Engineering. Documentation-platform mechanics and canonical term definitions remain with their named owners.
When to use
Before changing delivery process documentation or recording a durable engineering lesson. Do not use this to approve requirements or make planned practice operational.
Procedure
- Obtain the consumer's documentation repository, current default revision, authoring skill and glossary binding. Stop the affected edit if a binding is absent or its source identity cannot be verified.
- Load the bound documentation-platform skill before authoring, navigation, Markdown/MDX, configuration or build work. Load the bound glossary before defining reusable terms. A same-name unrelated installation does not satisfy a source-qualified load.
- Compare changed implementation/decision evidence with the coverage below. For each affected area, record the existing page, evidence source, exact change and owner. Leave unaffected areas alone; report a missing source rather than inventing content.
- Reconcile actual practice in the owning page, link shared definitions, and distinguish proposed practice from verified operation. Never copy the same procedure into several channel pages.
- Run the repository's documented validation/build in that repository; review the changed pages against the evidence, publish under its workflow and read back the exact published content. Local build success is not publication.
Bind the following coverage vocabulary to the consumer's lifecycle, verification owners and artifact responsibilities; it does not impose SKIC authorization on other projects. For AeroSim, the authoring binding must be documentation-docusaurus-skic-aerosim and shared terms must load glossary-skic, as supplied by its Delivery reference.
Domain coverage
Ways of Working — five sections
- Delivery workflow — intake, prioritization, implementation states, and definition of done.
- Branching and reviews — branch conventions, pull requests, approvals, and merge expectations.
- Planning and ownership — backlog, sequencing, owners, dependencies, blockers, and escalation.
- Quality practices — review standards, test strategy, defect handling, and evidence expectations.
- Collaboration and decisions — channel routing, handoffs, decision references, and communication norms.
Engineering — five sections
- Repository and workspace — monorepo/application/package structure and local prerequisites.
- Development and unit testing — commands, unit-test fixtures, debugging, Delivery artifact validation, and the handoff to UAT for every functional non-unit suite.
- Build and continuous integration — pipelines, checks, artifacts, runners, and failure diagnosis.
- Packaging and deployment preparation — containers, Helm/GitOps interfaces, configuration, and release inputs.
- Operations and troubleshooting — observability, known failure modes, recovery checks, and evidence collection.
Update these pages from verified project practice. Do not document a planned process as already operational.
Pitfalls and verification
A planned policy is not operational evidence. Do not turn a merged planning page into implementation approval. Before handing back, verify every changed domain statement has a current source, both required owner loads succeeded, links resolve and publication identity is retained. Delivery retains approval and lifecycle decisions.