Pre Deploy

@rules/parallel-remediation.md @rules/tracked-remediation.md

Pre-Deploy Skill

Prove a repository is deploy-ready, or fix only the reproduced quality/build blockers that prevent that proof.

Default all user-facing deliverables, saved artifacts, reports, plans, generated docs, summaries, handoff notes, commit/message drafts, and validation notes to Korean, even when this canonical skill file is written in English.

Preserve source code identifiers, CLI commands, file paths, schema keys, JSON/YAML field names, API names, package names, proper nouns, and quoted source excerpts in their required or original language.

Use a different language only when the user explicitly requests it, an existing target artifact must stay in another language for consistency, or a machine-readable contract requires exact English tokens. If a localized template or reference exists (for example *.ko.md or *.ko.json), prefer it for user-facing artifacts.

Positive triggers

• "Run a pre-deploy check" or "check if this is ready to deploy."
• "Make this repo deploy-ready" or "fix blockers before deploying."
• "Run final lint/typecheck/build validation before release."
• "Validate this Node/Rust/Python workspace before deployment."

Out-of-scope

• A concrete failed deployment log, platform build failure, CI-only environment mismatch, or production deploy issue. Route to deploy-fix.
• A runtime bug with reproduction steps or wrong application behavior. Route to bug-fix.
• New feature work, broad refactors, or speculative cleanup not tied to a reproduced pre-deploy blocker. Route to execute or the relevant implementation skill.
• Unsupported repositories with no root marker for package.json, Cargo.toml, pyproject.toml, requirements.txt, setup.py, Pipfile, or poetry.lock.

Boundary cases

• If the user asks for validation only, run checks and report blockers without editing.
• If the initial check exposes one obvious low-risk blocker, use Fix-now.
• If failures span multiple stacks, workspaces, or ambiguous dependency/config chains, use tracked remediation and parallel lanes where available.
• If a failure is actually a deploy-platform or runtime app issue, stop pre-deploy remediation and hand off instead of absorbing the wrong problem.

• If no argument is provided, default to the current repository root.
• If the user names a subdirectory or workspace, verify it exists, switch commands to that directory, and restart stack detection there.
• If the user says validate-only, report-only, audit-only, or similar, do not edit files.
• Always run stack detection from the target root before claiming the skill applies.
• If no supported stack is detected, stop immediately and report that pre-deploy does not apply; do not enter a fake fix loop.

Available scripts

Run scripts with the current working directory set to the target root so detection is accurate. If the target root is the repository root, use these repository-relative paths; if the target is a subdirectory/workspace, invoke the same scripts by absolute path or by the correct relative path back to the repository root:

Notes:

• Helper scripts detect stacks and package managers relative to the current working directory.
• lint-check.mjs already runs independent Node typecheck and lint commands concurrently when both are configured; do not duplicate that internal parallelism with extra agents.
• deploy-check.mjs defaults to --parallel to reduce wall time while preserving both command logs and failures. Use --sequential or PRE_DEPLOY_MODE=sequential for resource-constrained runners or tools that cannot safely share caches.
• Node package scripts are read once per quality run, and Python compileall fallbacks exclude generated, dependency, VCS, and virtual-environment directories.
• Treat skipped checks as "not configured" or "tool unavailable," not as passed.

Adaptive Structured Reasoning

Before implementation, perform an internal structured reasoning pass and scale depth to the failure shape:

Recommended sequence: classify -> read exact failure output -> identify root cause -> choose targeted validation -> decide direct fix, parallel lanes, tracked remediation, or handoff.

Classify after the first full deploy check fails:

When uncertain, classify upward. It is better to preserve evidence and ownership than to silently make broad changes.

• Validate-only: run detection and deploy-check.mjs, report detected stacks, passed/failed/skipped checks, and blockers. No edits.
• Fix-now: for simple/medium reproduced blockers, create TodoWrite items, fix narrowly, re-run targeted checks, then re-run full deploy check.
• Parallel remediation: after failure grouping, use bounded subagents/background agents only for independent diagnosis or disjoint edit lanes. The leader owns integration and final verification. Load rules/parallel-remediation.md first.
• Tracked remediation: for complex cases, load rules/tracked-remediation.md, then create or resume .hyper/pre-deploy/flow.json with phases detect, baseline, triage, fix, verify, report.
• Handoff: route platform deployment failures to deploy-fix, runtime application bugs to bug-fix, and unrelated implementation requests to execute.

Full validation proof

From the repository root:

skills/pre-deploy/scripts/deploy-check.mjs --parallel

Do not skip this initial command unless the target root has no supported stack. It establishes the baseline and captures exact blockers. The parallel mode is the default fast path. It waits for both phases and fails if either fails; it never treats one successful phase as readiness proof. Use --sequential when concurrent toolchains contend for memory, CPU, or shared build caches.

Step-by-step validation

From the repository root:

# 1) quality checks
skills/pre-deploy/scripts/lint-check.mjs

# 2) build phase
skills/pre-deploy/scripts/build-run.mjs

Use step-by-step commands for targeted rechecks after a fix, but the final readiness claim still requires a full deploy-check.mjs run.

Stack behavior summary

• Node.js: typecheck/lint (if configured) + build script (if configured)
• Rust: cargo fmt --check + cargo clippy + cargo check + cargo build --release
• Python: lint (ruff/flake8 if available) + type/syntax check (mypy or compileall) + build (poetry build or python -m build, fallback compileall)
• Unsupported repository: stop with the detected unsupported-stack error and do not continue into remediation

• Read the exact command output before editing; do not guess failures.
• Convert failures into TodoWrite items by stack, command, and priority.
• Fix the first/root failure before chasing cascading errors unless failures are demonstrably independent.
• Keep each edit scoped to the reproduced blocker and its direct dependency.
• Re-run the narrowest relevant check after each edit.
• If using subagents, give each lane objective, scope, ownership, output, and stop condition; never let two lanes edit the same file or shared config concurrently.
• The leader must synthesize subagent results, inspect the final diff, and run the final proof command directly.

Use this report shape:

## Done

**Scope**: [repo root or workspace]
**Stacks detected**: [node/rust/python]
**Mode**: [validate-only/fix-now/parallel remediation/tracked remediation/handoff]
**Initial blockers**: [none or summarized failures]
**Fixes applied**: [changed files or none]
**Validation**:
- `skills/pre-deploy/scripts/deploy-check.mjs`: [passed/failed/not run with reason]
- Skipped/not configured checks: [list]
**Remaining risks**: [none or explicit caveats]

Only say "ready to deploy" when the final full deploy-check.mjs run passed.

Execution checklist:

• Target root or workspace validated
• Supported stack detected, or unsupported stack reported and stopped
• Full skills/pre-deploy/scripts/deploy-check.mjs run first for supported stacks
• Failures tracked by stack/command/priority
• Root-cause evidence collected before edits
• Structured reasoning pass completed at the right depth
• Parallel lanes, if used, were independent and bounded
• Targeted validation run after each fix
• Full deploy check passed before readiness claim
• Skipped checks reported separately from passed checks

Forbidden:

• Claiming deploy readiness without a passing full deploy check
• Editing without a reproduced failure unless the user explicitly requested implementation work outside this skill
• Treating skipped checks as passed
• Continuing after unsupported-stack detection
• Requiring product-specific subagent syntax as if every runtime supports it
• Letting subagents edit overlapping files or own the final readiness decision