relusion

ce-auto-build

Build a plan through a bounded, sequential spec-to-implementation pipeline with independent review, deterministic gates, and one final human review. Triggers: auto-build/autopilot/batch spec and implement a plan in ship order.

ce-doc-audit

Audit an existing document for accuracy and usability by impersonating a named reader role, executing its steps in a local sandbox, and reporting inline, evidence-bound findings — never editing the doc. Executable-doc mode (the doc has runnable steps): run each step exactly as written as the role, observe reality, and flag where it is inaccurate / incomplete / unclear / hard-to-follow. Conceptual-doc mode (no runnable steps): a role-comprehension walk instead of execution. Findings, not verdicts; the human triages; a separate skill addresses approved feedback. Triggers: validate/QA/test-drive whether a role can actually follow a doc, runbook, quickstart, README, or setup guide. To WRITE docs use /core-engineering:ce-ship-document; to teach a maintainer the code use /core-engineering:ce-onboard; to walk a running app's UI use /core-engineering:ce-ux-audit.

ce-patch

Make one low-risk change on a bounded lane that touches at most two candidate files, proves it with behavior red→green or a deterministic content/config before→after check, and ends at one human acceptance gate. Any uncertain, sensitive, dependency, durable-state, schema, public-contract, destructive, colliding, or wider change routes to /core-engineering:ce-plan; this skill never commits, pushes, opens a PR, or merges. Triggers: a typo, localized bug fix, or small behavior change with a known test. Multi-file, contract, schema, dependency, security-sensitive, or exploratory work → /core-engineering:ce-plan.

ce-probe-perf

Profile a running target's performance — latency, throughput, resource use, hotspots — observe tier by default, load/soak behind opt-in. Refuses production; the only tool that can prove a numeric NFR breach (records, doesn't block). Triggers: performance-test/profile/load-test/measure latency or throughput. For vulnerabilities use /core-engineering:ce-probe-sec.

ce-probe-sec

Security-probe a running target — web/API apps or CLI binaries — passive recon by default; smell-test and active-exploit tiers behind explicit opt-in. Twice-attested consent; refuses production; sandboxes binaries; findings, not verdicts. Triggers: security-test/sec-scan/probe a running app for vulnerabilities. Never production. For performance use /core-engineering:ce-probe-perf.

ce-ship-release

Prepare the final human-owned release decision for a verified, reviewed, documented plan range. Derives version and changelog, checks fresh implementation evidence, documentation/doc-audit readiness, rollback, and supply-chain evidence, then writes a decision package on approval. Never tags, pushes, deploys, or claims compliance. Triggers: cut a release, decide a version, draft release notes, or make a release go/no-go decision. /core-engineering:ce-ship-document owns product docs; /core-engineering:ce-doc-audit validates reader workflows.

ce-ask

Answer questions about any code repository — locate code, trace flow, explain rationale, find callers — with structured, file-cited answers that stage the relevant files into the conversation. Ephemeral; writes nothing. Triggers: ask how/where/why about a codebase. For a misbehaving running component use /core-engineering:ce-debug — ask answers questions, it does not investigate symptoms.

ce-brief

Turn an ambiguous idea into an optional, approved intent brief for /core-engineering:ce-plan. Use when problem, users, scope, outcomes, or constraints need discovery; skip it when those are already clear. Records product intent only—no codebase profile, solution design, architecture selection, or decomposition.

ce-debug

Diagnose a FAILING target and route one fix — auto-detecting whether a plan/spec owns it. Planned mode (a plan/spec owns the failing feature): reproduce → file:line root cause → classify (bug/spec-gap/structural) → route one targeted fix to /core-engineering:ce-implement, /core-engineering:ce-spec, or /core-engineering:ce-plan. Plan-free mode (a misbehaving component with no plan/spec — a stuck consumer, silent worker, or job that stopped): ranked, evidence-bound root-cause hypotheses + a discrimination plan (the cheapest observation that settles each). Read-only on code; never patches. Triggers: debug/root-cause/find why a feature, test, or journey fails; or investigate/troubleshoot why a service/worker/queue is stuck or silently failing. Auto-detects planned vs plan-free mode from plan state — you need not know which.

ce-decide

Weigh two or more TECHNICAL/architecture options for one decision and render an evidence-tagged Adopt/Adopt-with-mitigations/Spike-first/Reject recommendation plus a proposed ADR — situation-derived weights, knockout gates, a falsifiable DEAD-IF. Engineering-side verdict (unlike /product-discovery:ce-idea-score, which scores PRODUCT ideas). Triggers: choose between, compare, or weigh supplied technical/architecture/fix options for one bounded decision. For generation and scoring of complete solution directions or a cross-feature baseline, use /core-engineering:ce-architecture.

ce-domain

Onboard a person into the business domain a codebase encodes — the product's context, the actors and roles it serves, the domain nouns and their lifecycles, the processes and journeys it supports, the business rules and invariants it enforces, and the ubiquitous language it is built around — as a paced, evidence-grounded interactive walkthrough. Every claim cites file:line or a named artifact and carries its evidence type (recorded / enforced / inferred); draws on the plan tree's recorded human claims where one exists (the brief's users and roles, the journey map, the decisions ledger, EARS criteria, ADRs) and on code-derivable domain signal where it does not (entities, state enums and their transition guards, validation rules, authorization roles, jobs, integrations). What a repository cannot evidence — why a rule exists, the market context, the human process around the software — is registered as a known unknown and handed to a human, never narrated. Read-only on code; teaches, never patches. Triggers: onbo

ce-go

The front door — take a plain-language request ("why does export fail", "score this idea", "is the code good"), inspect repo state (a plan on disk? a spec for the named feature? a running target?), and route to the one right `/ce-*` skill with its reasoning shown first. Routes, never executes: it starts one model-invocable skill or returns the exact command for a direct-only skill, and writes nothing itself. Triggers: you know what you want but not which of the ~29 `/ce-*` skills runs it. ce-go picks; the routed skill does the work (and auto-detects any plan-existence mode itself, so you never have to).

ce-humanize

Rewrite AI-generated, generic, or over-polished prose into natural, credible, human-sounding text while preserving meaning, facts, structure, and required terminology — for emails, PR descriptions, READMEs, docs, proposals, commit messages, and other prose. Ephemeral by default (returns the rewrite); edits a named file only on explicit consent, format preserved. Never claims human authorship, fabricates experience or data, or optimizes to defeat AI-detection. Triggers: humanize, naturalize, de-robot, de-AI, make less AI-like, make more conversational or authentic, polish or rewrite prose/copy/tone. For generating user-facing docs from a plan's verified behavior use /core-engineering:ce-ship-document; this rewrites the tone of prose that already exists.

ce-impact

Analyze the codebase impact of a proposed change described in plain text (e.g. an Azure DevOps work item pasted in) — affected components, blast radius, an approximate sizing hint, similar prior work, and the open questions a thin description leaves — as file:line-cited FINDINGS, never a verdict. Refuses loudly when the description is too thin to ground. Read-only on code; ephemeral; one-way (renders a paste-ready summary the human posts back themselves — no tracker API, no write-back). Triggers: estimate/assess the impact or blast radius of a proposed change or work item before building it. For a question about existing code use /core-engineering:ce-ask; to decompose a whole project use /core-engineering:ce-plan; to investigate a failure use /core-engineering:ce-debug.

ce-implement

Implement a specified feature by working its task list to done — test-first, task by task, verified against acceptance criteria; resumable; never redesigns or widens the spec (Scope Lock). Triggers: implement/build/execute the task list of a specified feature. For a genuinely small change, use /core-engineering:ce-patch.

ce-init

Bootstrap core-engineering in a repository: profile languages, package managers, build/test commands, CI, API/data/security surfaces, then write starter repo SDLC artifacts under docs/plans without overwriting human policy silently. Triggers: first-run setup, initialize this framework in a repo, generate vc-policy/review-policy/patterns/repo profile before planning.

ce-onboard

Interactively teach a developer the implementation that was built — a paced, evidence-grounded walkthrough of a plan's as-built code (architecture, the decisions behind it, the gotchas, the verified behavior) with comprehension checks, for the maintainer who now owns code they (or /core-engineering:ce-auto-build) didn't hand-write. Reads the plan's own artifacts when present; degrades to code + git grounding when absent. Read-only on code; teaches, never patches. Triggers: onboard/walk me through/teach me/explain how this was built so I can maintain it. For the business domain the code encodes (actors, domain nouns, business rules, vocabulary) use /core-engineering:ce-domain; for a one-off question use /core-engineering:ce-ask; for user-facing docs use /core-engineering:ce-ship-document; for process metrics use /core-engineering:ce-retro.

ce-plan-audit

Independently audit a written canonical plan for structural integrity, architecture-decision quality, repository fit, decomposition, reachability, and post-write drift. Produces evidence-backed findings and never rewrites the plan. Use before specification or automated delivery when an independent plan check is warranted.

ce-plan

Turn a repository-grounded outcome into an approved, dependency-ordered feature plan, using an evidence-rich architecture comparison only when architecture changes the delivery cut. Triggers: plan, decompose, scope, or revise a project/feature. Composes /core-engineering:ce-architecture for load-bearing direction work; use /core-engineering:ce-spec only when a feature needs a separate detailed contract.

ce-probe-deps

Statically scan a repository's pinned dependency manifests against the OSV.dev advisory database — known-vulnerable versions (CVE/GHSA advisories) per exactly-pinned package, with loud offline degradation, never a silent pass. Deterministic stdlib floor (sca-guard.py over requirements.txt / npm lockfiles) enriched by model triage; only package name+version coordinates ever leave the machine (disclosed; --offline honored). Read-only on code; findings, not verdicts. Triggers: scan/audit/check dependencies for known CVEs or vulnerable versions, SCA, software composition analysis. For manifest *misconfiguration* (IaC/k8s/Dockerfile) use /core-engineering:ce-probe-infra; undeclared/typosquat NEW dependencies in a change are dep-guard's job inside the implement lane.

DevOps & Infrastructure Listed

ce-probe-infra

Statically audit Infrastructure-as-Code / Kubernetes / cloud manifests across a repo — least-privilege, workload hardening, secrets, exposure, hygiene, cross-manifest consistency. Orchestrates installed scanners (tfsec/checkov/kube-score/kube-linter/hadolint/trivy) and falls back to a stdlib infra-lint.py floor. Read-only on code; redacts secrets, never exfiltrates; findings, not verdicts. Triggers: audit/lint/review IaC, k8s, Helm, Dockerfile, compose, or cloud manifests for misconfig. Static & plan-free. For a live running target use /core-engineering:ce-probe-sec; for application-code review use /core-engineering:ce-review; for known-vulnerable dependency versions (SCA) use /core-engineering:ce-probe-deps.

Data & Documents Listed

ce-retro

Read-only retrospective over a plan's pipeline — aggregate the .metrics.jsonl stream and existing artifacts into descriptive signals (testability, escalation, park/retry/circuit-break rates, review disposition, complexity drift). Scope-boxed by plan, and optionally time-boxed by a --since/--until window for a sprint retro; renders for a chosen audience (standup, sprint-review, on-call handoff) without ever computing a number the artifacts do not carry. Mutates nothing. Triggers: retrospective/metrics/health-report/how-did-this-plan-go, sprint retro, standup summary, on-call handoff brief. Dynamic counterpart of the static /core-engineering:ce-plan-audit.

ce-review

Independently code-review implemented code — auto-detecting which direction the review runs. Outbound mode (the default): walk six lenses (correctness, security, performance, maintainability, conformance, simplicity) over a feature's diff with an adversarial verification pass. Inbound mode (PR review comments pasted in): treat each human comment as a CLAIMED finding, verify it against the code (substantiated / refuted / unverifiable), and draft paste-ready replies. Findings, never patches; escalates. Posts to no forge, edits no code. Triggers: code-review/audit the quality or security of a built feature, or triage/answer pasted human PR review comments. Asks HOW IT'S WRITTEN; for DOES IT BEHAVE use /core-engineering:ce-verify. Auto-detects outbound vs inbound from the pasted payload — you need not say which.

Data & Documents Listed

ce-ship-backlog

Generate paste-ready or importable backlog items from a feature spec — one Story plus one Task per tasks.json item, parent-linked, EARS as the Story's acceptance criteria, linked back to the spec. The model maps the spec into a neutral backlog.json; a stdlib emitter renders it to ADO paste-markdown (default), ADO CSV, Jira CSV, or GitHub-Issues JSONL. One-way only; no API, no sync. Triggers: convert a feature spec into ADO / Jira / GitHub backlog tickets or work items — paste-markdown or bulk-import CSV/JSONL emitters.

ce-ship-document

Generate user-facing documentation — README, getting-started/usage guide, API/interface reference, configuration — grounded in the plan's VERIFIED behavior, every example run not narrated. Never writes the versioned CHANGELOG.md (that is /core-engineering:ce-ship-release's). Triggers: write or regenerate user-facing docs, a README, or API/usage reference. To VALIDATE that a reader can follow an existing doc (not write one), use /core-engineering:ce-doc-audit.

ce-spec

Turn ONE planned feature into an implementation-ready spec — resolve unknowns, EARS acceptance criteria → tagged test cases, design against the real codebase, an ordered tasks.json — without widening the planned boundary (Scope Lock). Triggers: spec/specify/detail one planned feature for implementation. /core-engineering:ce-plan owns decomposition and the architecture disposition; /core-engineering:ce-architecture owns the conditionally required cross-feature solution baseline; /core-engineering:ce-spec owns feature-local design.

ce-ux-audit

Audit a running app's UX and report evidence-bound findings — auto-detecting whether a plan owns the surface. Journey-walk mode (a plan's traced journeys): walk each planned journey against the running app and report mechanical findings — dead ends, plan-vs-reality gaps, cross-feature inconsistencies, broken links, missing states. Adversarial-discovery mode (no plan owns the target, or a plain running app): chaos-test/fuzz/adversarially-probe the app to DISCOVER unknown UX problems — validation gaps, state loss, layout breakage, accessibility violations — on any repo. Findings, not verdicts; read-only on code; never patches. Triggers: UX-audit/smoke-test/walk the journeys of an implemented plan; or chaos-test/fuzz/adversarially-probe/UX-explore a running app plan-free. Auto-detects journey-walk vs adversarial-discovery mode from plan state — you need not know which.

ce-verify

Verify a plan's implemented features work together — whole-suite regression, journey walks, durable-noun revisits, bridge retirement, dependency-manifest integrity, stakeholder acceptance — and produce the handover report. Triggers: verify/integration-test/pre-handover-check a plan. Asks DOES IT BEHAVE (a gate); for code quality use /core-engineering:ce-review.

ce-idea-score

Score ONE software/startup idea on a seven-axis decision rubric and render an opinionated, evidence-tagged Pursue/Pursue-with-changes/Park/Drop verdict — knockout gates, a falsifiable DEAD-IF, the human owns the call. Verdict-rendering (unlike /product-discovery:ce-market-scan, which renders none). Triggers: score/grade/rate/go-no-go ONE idea. Many ideas → /product-discovery:ce-idea-scout.

ce-idea-scout

Generate, triage, and rank a shortlist of software/startup ideas — a verdict-rendering funnel (generate → cheap filter → seven-axis score → ranked directions). Opinionated rankings; decision support, not validated fact. Triggers: brainstorm/scout/generate/triage MANY ideas into a ranked shortlist. For ONE idea use /product-discovery:ce-idea-score; for market validation /product-discovery:ce-market-scan.

ce-market-scan

Evidence-bound market & competitive scan to validate a raw idea before /core-engineering:ce-brief — three-state evidence, every claim sourced and dated; frames the decision space and routes a disposition but renders NO go/no-go verdict (the Scope Lock). Triggers: market/competitor/differentiation research for an idea. For an opinionated score use /product-discovery:ce-idea-score; to first brainstorm MANY raw ideas into a ranked shortlist use /product-discovery:ce-idea-scout.

ce-architecture

Design repository-grounded solution architecture in three explicit modes: explore complete directions before decomposition with explore:<draft-slug>, shape one elected planning candidate read-only with shape:<draft-slug>, or baseline a written plan with a human-approved architecture package. Explore writes only a reviewable decision workbench; shape returns planning impact without editing the draft; baseline preserves plan-owned boundaries and requires final human approval. Use /core-engineering:ce-plan for decomposition, /core-engineering:ce-decide for one bounded technical fork, and /core-engineering:ce-spec for feature-level design.