product-engineering-ops

name	product-engineering-ops
description	Build and audit engineering-ready product intelligence around services, local runtime, CI/CD, deployments, support-to-code workflows, and scale-readiness. Use when a user wants a product second brain that engineers can actually ship, debug, deploy, and support from.

Product Engineering Ops

Use this skill when the vault must become a real engineering operating surface rather than only a knowledge repository.

Read references/readiness-model.md before building or auditing the engineering layer.

This skill is designed to work with:

• $CODEX_HOME/skills/product-intelligence-factory/SKILL.md
• $CODEX_HOME/skills/obsidian-intelligence-system/SKILL.md

Workflow

1. Start from the manifest

Validate the manifest first:

python3 $CODEX_HOME/skills/product-intelligence-factory/scripts/validate_product_manifest.py \
  --manifest "/absolute/path/to/product.yaml" \
  --check-paths

2. Make engineering readiness explicit

Every product should be scored across at least these areas:

• reusable import factory readiness
• source ingestion and authenticated capture
• Product BASB alignment across CODE, PARA, progressive summarization, archives, and output conversion
• Product BASB quality metrics such as packet count, output-candidate count, conversion rate, weekly reviews, archive records, and BASB issue counts
• code and repo intelligence
• safe repo sync
• local runtime and feature work support
• bug/support-to-code workflow
• CI/CD and deployment intelligence
• automation coverage

Do not leave these as implicit tribal knowledge.

3. Generate a recurring readiness report

Use the report generator to render the current status from the manifest:

python3 scripts/generate_engineering_readiness.py \
  --manifest "/absolute/path/to/product.yaml" \
  --write "/absolute/path/to/report.md"

The output should clearly separate:

• what is done
• what is partial
• what is missing
• the next implementation steps

4. Drive the next implementation from the gaps

The report is not an archive. Use it to choose the next highest-leverage system work:

• if repo sync is missing, build mirror sync
• if CI/CD intelligence is missing, ingest workflows, environments, releases, and deploy runbooks
• if support-to-code is weak, connect support notes to code paths, tests, and repro flows
• if the workflow is still product-specific, move logic into the generic factory layer

5. Install a weekly readiness audit

Every product should have a recurring audit automation so scale blockers stay visible instead of being rediscovered manually.