Run any Skill in Manus with one click

speed-it

Stars1

Forks0

UpdatedJuly 17, 2026 at 02:45

Bring declared user journeys within pre-declared performance budgets, proven by measurement. Controlled baseline (measure to a metric contract, not once) → profile the real bottleneck → fix PR-per-hotspot with a mandatory before/after → re-benchmark to the metric's statistical contract → add CI regression guards, looping until every journey is within budget or parked. Use when "the app is slow", "perf sweep", "Core Web Vitals", "get under budget", or an unattended perf-hardening run. Not for a per-diff perf opinion (review-it) or post-deploy watch alone (observe via ship-it).

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

ravidsrk

ravidsrk/orca-fleet

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

File Explorer

2 files

SKILL.md

readonly

name	speed-it
description	Bring declared user journeys within pre-declared performance budgets, proven by measurement. Controlled baseline (measure to a metric contract, not once) → profile the real bottleneck → fix PR-per-hotspot with a mandatory before/after → re-benchmark to the metric's statistical contract → add CI regression guards, looping until every journey is within budget or parked. Use when "the app is slow", "perf sweep", "Core Web Vitals", "get under budget", or an unattended perf-hardening run. Not for a per-diff perf opinion (review-it) or post-deploy watch alone (observe via ship-it).
license	MIT
proof	doctrine-only
compatibility	HARD dependency: Orca runtime + orchestration skill (Orca CLI). git + gh. A real MEASUREMENT path (Lighthouse/DevTools for web CWV, or a load/profiler harness). A perf worker playbook (addyosmani performance-optimization or gstack benchmark) — one router per worker.

speed-it — every journey within budget, proven by a number

You are the COORDINATOR. Unlike a findings mission, here BASELINE MEASUREMENT PRECEDES inventory, fixes interact systemically, measurements are noisy, and DONE is a STATISTICALLY-DEFINED BUDGET over journeys — not closure of a finding list. Composes risk-review (perf lens), remediate-finding, acceptance-review, runtime-prove; rides merge-serialization, reviewed-sha-freshness, dispatch-lifecycle, liveness-resume, evidence-manifest, ledger-contract. Worker TASK pack: one of addy | gstack.

Two terminal outcomes

WITHIN-BUDGET — every critical journey meets its budget on its metric contract's confirmation.
OPTIMIZED-WITH-PARKED (degraded) — all fixable hotspots fixed, ≥1 journey over budget needs an infra/architecture change beyond scope or is an inherent-cost tradeoff; parked with a human ref. Never reported as WITHIN-BUDGET.

The measurement contract (declare per metric BEFORE baselining)

Two runs is a smoke minimum, not proof. Field CWV = the metric's percentile (p75) over a window + sample count. Lab CWV = median of ≥5 runs (e.g. 5–10; report spread) at a pinned throttle/cache/device. Server p95/p99 = the percentile over ≥N requests (e.g. 1k–10k) at stated concurrency, two independent load runs agree. Baseline and candidate MUST share source, sample size, and pinned conditions — a lab-vs-field or warm-vs-cold comparison is not a delta. A number you can't measure to its contract is unmeasured (human-flagged), never a downgraded proxy; never fabricate a metric.

Pipeline

HUMAN SCOPE CONFIRM: freeze the critical-journey list + per-journey budgets (unbounded journeys
  unbounded mission) → declare metric contracts → BASELINE every journey (to contract) → rank
  breaches by gap×traffic
  → DIAGNOSE the bottleneck (profile; symptom→cause tree; name the one dominant cause)
  → BOOTSTRAP integration BASE (runtime/scripts/preflight.py --base <BASE> --fork-point <sha
    recorded in the ledger header at BASE creation>; BASE ≠ default — dispatch-lifecycle.md)
  → FIX PR-per-hotspot (before→after mandatory; GUARD: add a CI budget) → build-blind REVIEW
    (acceptance-review) → RUNTIME-PROVE (drive the journey at its real entry point — fast but
    behaviorally wrong is a bug, not a win) → LAND
  → RE-BENCHMARK to the contract (a lucky single run is not confirmation). Lab/load contracts
    complete in-mission. Field CWV contracts need the same field source/sample/conditions as baseline
    — that requires deploy; hand off a brief (measurement contract + ship-it release plan) to ship-it
    and do not claim WITHIN-BUDGET on a lab-only delta (OPTIMIZED-WITH-PARKED until field confirms).
  → loop → outcome

Convergence proof

Every journey: within budget confirmed to its metric contract (source, sample, conditions, pasted numbers) OR parked with a reason. Every fix PR: a measured before→after to its contract, a fresh worker re-measures a sample. No fabricated metrics (spot-checked). CI budgets added so wins don't rot. A fix that changes behavior is a bug the review must catch. Manifest names WITHIN-BUDGET or OPTIMIZED-WITH-PARKED.

Ledger + supervision

Header per liveness-resume.md: RUN · COORDINATOR · BASE · FORK_POINT · T0 · SOURCE · WIP (- if N/A; SOURCE = journey-list + metric-contract digests). Rows include Orca task id + hotspot/journey fields. Stalls → WATCH; death → RESUME scoped to header coordinator + ledger task ids, git-verified.

Anti-patterns

Optimizing without a baseline (can't prove a win). One fast run = "fixed" (perf is noisy). Confirming below the metric's contract. Scattershot micro-opts instead of the profiled bottleneck. Unbounded journey list (needs the human-confirmed set).

clean-sweep (general findings), review-it (per-diff perf lens), observe (post-deploy perf watch via ship-it), ship-it (owns deploy + canary when field confirmation is required).

More from this repository

same repository

oss-contribute

ravidsrk/orca-fleet

Turn a bounded set of issues on a repo you do NOT control into landed open-source contributions. Each actionable issue is skeptic-triaged (including a search of the upstream repo's OPEN PRs, not just its code), built on a fork with a failing-first test, reviewed build-blind, and opened as an etiquette-correct PR against the upstream default branch — or, where a maintainer PR already exists, shared as a quoted review-assist comment (an alternative PR only if maintainers invite one). The loop re-enumerates until the actionable set is dry. Merge is the maintainer's; the fleet never merges. Use when "contribute to this project", "open PRs for these upstream issues", "help out this OSS repo", "send fixes upstream", "we only have a fork". Not for a repo you own and can merge (that is clean-sweep — merged-SHA closure) and not for building a net-new project (ship-it).

2026-07-171

clean-sweep

ravidsrk/orca-fleet

Exhaust a finite backlog of findings to zero, PR-per-finding, on Orca. Sources: an audit/adversarial-review document, the issue tracker, or verified false documentation claims. Each finding is skeptic-triaged (reproduced or refuted with evidence), fixed on an integration branch with a failing-first test, build-blind reviewed, merge-verified, and closed with a linked SHA; the loop re-enumerates until dry. Use when "clean sweep", "close every issue", "drain the backlog", "fix everything in this audit", "the README lies — verify and fix it", or a broken test that fails deterministically (N/N, cause findable — deflake-it routes those here). Not for security/perf/deps/coverage-gaps/flakes (those are harden-it / speed-it / modernize-it / prove-it / deflake-it — different convergence proofs) and not for building new work (ship-it).

2026-07-171

ship-it

ravidsrk/orca-fleet

Turn intent or a frozen spec into a released, verified outcome on Orca. Entry is either a frozen spec (validate → decompose) or raw intent (grill → freeze → decompose); after freeze both enter one canonical pipeline: decompose → build (tested slices) → acceptance review → runtime-prove → land → release → observe, stopping at the highest release state you're authorized to reach (BUILT / PROMOTION_READY / RELEASED / DEPLOYED_AND_VERIFIED). Use when "build and ship this", "spec to shipped product", "ship this feature", or an autonomous build-to-release run. Not for closing an existing backlog (that's clean-sweep) or a foggy goal that needs charting first (that's map-it).

2026-07-171

prove-it

ravidsrk/orca-fleet

Give every critical path a test that dies under a semantics-preserving mutation. Map the untested critical surface (coverage × call-graph of the money/auth/data paths), write characterization tests that assert real behavior, prove each earns its keep by failing at its assertion under a mutation (harness still runnable — a compile break is not proof), and route surfaced bugs to a fix or backlog, looping until every confirmed critical path is mutation-audited. Use when "close the test gap", "cover the critical paths", "test debt", characterization/mutation testing — it owns missing coverage, not broken tests. Not for flake eradication (deflake-it), a deterministically failing test (clean-sweep), or building features with tests from the start (ship-it).

2026-07-171

harden-it

ravidsrk/orca-fleet

Establish a threat model and close it: audit → prove exploits → fix → RE-ATTACK the fix and audit the whole vulnerability class → re-audit, looping until a fresh full audit finds zero unrefuted P0/P1. STRIDE + OWASP Top 10 + OWASP LLM Top 10 + supply-chain. Use when "harden this", "security sweep", "red team", "close the security loop", or an unattended audit-fix-verify security run. The full adversarial loop — for a bounded per-diff security check use review-it's risk lens. Not for general backlog drain (clean-sweep) or a single PR verdict (review-it).

2026-07-171

map-it

ravidsrk/orca-fleet

Resolve a foggy, multi-session goal into a frozen execution map that ship-it can consume — decisions, not deliverables. Chart a fog-of-war map of decision-tickets (only ticket what you can phrase sharply now), clear the research/decision frontier in parallel with HITL at each decision, and produce a frozen plan + a prepared DAG. Use when the goal is too big/foggy for one session, "chart this", "plan this epic", "I don't know the shape yet", or you can't yet authorize implementation. Its outcome is a decided plan; building is ship-it. Not for a foggy BUG (root-cause) or ready-to-build intent (ship-it).

2026-07-171

name	speed-it
description	Bring declared user journeys within pre-declared performance budgets, proven by measurement. Controlled baseline (measure to a metric contract, not once) → profile the real bottleneck → fix PR-per-hotspot with a mandatory before/after → re-benchmark to the metric's statistical contract → add CI regression guards, looping until every journey is within budget or parked. Use when "the app is slow", "perf sweep", "Core Web Vitals", "get under budget", or an unattended perf-hardening run. Not for a per-diff perf opinion (review-it) or post-deploy watch alone (observe via ship-it).
license	MIT
proof	doctrine-only
compatibility	HARD dependency: Orca runtime + orchestration skill (Orca CLI). git + gh. A real MEASUREMENT path (Lighthouse/DevTools for web CWV, or a load/profiler harness). A perf worker playbook (addyosmani performance-optimization or gstack benchmark) — one router per worker.

speed-it — every journey within budget, proven by a number

Two terminal outcomes

WITHIN-BUDGET — every critical journey meets its budget on its metric contract's confirmation.
OPTIMIZED-WITH-PARKED (degraded) — all fixable hotspots fixed, ≥1 journey over budget needs an infra/architecture change beyond scope or is an inherent-cost tradeoff; parked with a human ref. Never reported as WITHIN-BUDGET.

The measurement contract (declare per metric BEFORE baselining)

Pipeline

HUMAN SCOPE CONFIRM: freeze the critical-journey list + per-journey budgets (unbounded journeys
  unbounded mission) → declare metric contracts → BASELINE every journey (to contract) → rank
  breaches by gap×traffic
  → DIAGNOSE the bottleneck (profile; symptom→cause tree; name the one dominant cause)
  → BOOTSTRAP integration BASE (runtime/scripts/preflight.py --base <BASE> --fork-point <sha
    recorded in the ledger header at BASE creation>; BASE ≠ default — dispatch-lifecycle.md)
  → FIX PR-per-hotspot (before→after mandatory; GUARD: add a CI budget) → build-blind REVIEW
    (acceptance-review) → RUNTIME-PROVE (drive the journey at its real entry point — fast but
    behaviorally wrong is a bug, not a win) → LAND
  → RE-BENCHMARK to the contract (a lucky single run is not confirmation). Lab/load contracts
    complete in-mission. Field CWV contracts need the same field source/sample/conditions as baseline
    — that requires deploy; hand off a brief (measurement contract + ship-it release plan) to ship-it
    and do not claim WITHIN-BUDGET on a lab-only delta (OPTIMIZED-WITH-PARKED until field confirms).
  → loop → outcome

Convergence proof

Ledger + supervision

Anti-patterns

clean-sweep (general findings), review-it (per-diff perf lens), observe (post-deploy perf watch via ship-it), ship-it (owns deploy + canary when field confirmation is required).