front-load

Rank capabilities by risk and value while enforcing dependency DAG.

Updated Jun 4, 2026
One-click install
npx skills add https://github.com/Kohlex/autopilot-plugin --skill front-load
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: front-load
Source: https://github.com/Kohlex/autopilot-plugin/tree/main/skills/front-load
Command: npx skills add https://github.com/Kohlex/autopilot-plugin --skill front-load

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Front-load computes a hard, risk-aware build order for capabilities by ranking items with risk_score and value_score while enforcing the DAG floor from B14 (depends_on). It ensures high-risk items cannot precede their dependencies and surfaces show-stoppers for pre-commit review.

Core Features & Use Cases

  • Deterministic ordering: orders capabilities topologically while prioritizing risk first, then value, within the constraints of dependencies.
  • Risk spike readiness: identifies items with high risk that should be de-risked before commitment.
  • Workflow alignment: outputs an ORDER consumable by B6 ROADMAP and supports /peer-review gating.

Quick Start

Analyze the product's capabilities.yaml with risk_score and value_score, then run the front-load engine to produce an order and spike list.

Frequently Asked Questions about front-load

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I compute a risk-aware build order for architecture capabilities?

Compute a risk-aware build order by topologically sorting capabilities using dependency constraints, then ranking ready items by risk_score and value_score. This surfaces high-risk items early for de-risking before commitment.

What is front-loading in architecture planning workflows?

Front-loading in architecture planning is ordering capabilities by risk and value while respecting dependency prerequisites. It ensures high-risk items are prioritized for early de-risking and cannot bypass their dependencies.

How do I identify high-risk capabilities that need spikes before commitment?

Identify high-risk capabilities by evaluating risk_score values in capabilities.yaml during the ordering process. The engine outputs a dedicated spikes list containing items that require de-risking prior to commitment.

Can I use dependency DAG constraints to prioritize high-risk items in my build sequence?

Dependency DAG constraints enforce prerequisite floors so high-risk items cannot precede their dependencies. Within those constraints, the engine prioritizes items by risk_score first, then value_score, producing a deterministic sequence.

What format does capabilities.yaml need to be in for risk-aware capability ordering?

Capabilities.yaml must include risk_score and value_score fields for each capability, plus depends_on references defining the dependency DAG. The engine uses these overlays to compute the ordered capability list and spikes output.

When should I not use risk-first ordering for my capability roadmap?

Risk-first ordering is not suitable when capabilities lack quantified risk_score or value_score data, or when dependency relationships are undefined. Without these inputs, the engine cannot compute a deterministic build order or generate a spikes list.