← ClaudeAtlas

docpack-orchestratorlisted

Use when creating or updating a Metaproject requirements package under docs/requirements: PRD, specification, README, policies/protocols/schemas, roadmap updates, verification, and package review. Use for requests like 'create requirements package', 'prepare module documentation', 'write PRD/spec for module', or 'оформи пакет документации'. Not for reverse-engineering current codebase documentation; use autodoc-orchestrator for that.
MrCipherSmith/helyx · ★ 1 · AI & Automation · score 71
Install: claude install-skill MrCipherSmith/helyx
# docpack-orchestrator Top-level orchestrator for Metaproject requirements packages under `docs/requirements/<name>/`. Use `autodoc-orchestrator` instead when the goal is to reverse-engineer the current codebase and produce architecture/onboarding/developer documentation. ## Execution metrics (opt-in) When a USER runs this orchestrator directly (not as a dispatched subagent), at the start ask "Collect execution statistics for this run? (yes/no)" per `.metaproject/rules/core/execution-metrics.md`. If yes, append the `## Execution Metrics` section at the end and save it under the docpack output dir. Never ask or emit it when dispatched as a subagent. ## Iron Laws | # | Law | |---|---| | 1 | Never create a single loose doc when a package is needed. | | 2 | Always follow `rules/core/requirements-package-standard.mdc`. | | 3 | Every Markdown doc must have `Version`. | | 4 | README, PRD and specification are required for module packages. | | 5 | Verification and documentation review are mandatory before final output. | | 6 | Do not claim runtime implementation exists unless code proves it. | ## Pipeline ```text Phase 0 Scope -> classify docs type and package name Phase 1 Evidence -> collect source notes, decisions, existing docs and code context Phase 2 Design -> decide required files and schemas Phase 3 Write -> create/update README, PRD, specification and optional docs Phase 4 Verify -> structural/version/link/schema checks Phase 5 Review