alpoxdev/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.

<output_language>

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.

</output_language>

<request_routing>

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.

</request_routing>

<argument_validation>

• 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.

</argument_validation>

<scripts>

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:

| Script | Purpose | |------|------| | skills/pre-deploy/scripts/stack-detect.sh | Detect project stacks (node, rust, python) | | skills/pre-deploy/scripts/deploy-check.sh | Full verification (lint/type checks + build) | | skills/pre-deploy/scripts/lint-check.sh | Run stack-specific quality checks | | skills/pre-deploy/scripts/build-run.sh | Run stack-specific build phase | | skills/pre-deploy/scripts/pm-detect.sh | Node package manager detection (npm/yarn/pnpm/bun) |

Notes:

• Helper scripts detect stacks and package managers relative to the current working directory.
• lint-check.sh already runs independent Node typecheck and lint commands concurrently when both are configured; do not duplicate that internal parallelism with extra agents.
• Treat skipped checks as "not configured" or "tool unavailable," not as passed.

</scripts>

<mandatory_reasoning>

Adaptive Structured Reasoning

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

| Complexity | Reasoning depth | Signals | |------|------|------| | Simple | 3 steps | One stack, one failing command, clear root cause, low-risk fix | | Medium | 5 steps | Multiple related failures in one stack, moderate config/dependency impact | | Complex | 7+ steps | Multiple stacks/workspaces, ambiguous fix strategy, shared config, dependency chain, or CI/deploy boundary |

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

</mandatory_reasoning>

<complexity_classification>

Classify after the first full deploy check fails:

| Complexity | Signals | Path | |------|------|------| | Simple | Single failing check, one stack, clear file/config owner, one safe fix path | Fix-now | | Medium | Several failures in one stack or one workspace, independent enough for targeted fixes | Fix-now with TodoWrite tracking | | Complex | Multi-stack failures, shared configs, monorepo/build graph issues, uncertain repair options, or likely cross-cutting side effects | Tracked remediation; use rules/parallel-remediation.md before subagents |

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

</complexity_classification>

<execution_modes>

• Validate-only: run detection and deploy-check.sh, 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 .hypercore/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.

</execution_modes>

<workflow>

Full validation proof

From the repository root:

skills/pre-deploy/scripts/deploy-check.sh

Do not skip this initial command unless the target root has no supported stack. It establishes the baseline and captures exact blockers.

Step-by-step validation

From the repository root:

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

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

Use step-by-step commands for targeted rechecks after a fix, but the final readiness claim still requires a full deploy-check.sh 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

</workflow>

<implementation_rules>

• 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.

</implementation_rules>

<completion_report>

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.sh`: [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.sh run passed.

</completion_report>

<validation>

Execution checklist:

• [ ] Target root or workspace validated
• [ ] Supported stack detected, or unsupported stack reported and stopped
• [ ] Full skills/pre-deploy/scripts/deploy-check.sh 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

</validation>