rigorloop

Orchestrate the full spec-driven, test-driven agentic development lifecycle. Use when starting, resuming, auditing, or routing work through the standard RigorLoop workflow. This skill assesses workflow state, enforces artifact order, and keeps exploration, specification, architecture, planning, tests, implementation, review, rationale, verification, PR, and learning connected.

Implement one approved milestone or isolated implementation request with tests or proof first, then hand it to code-review with validation evidence and plan state updated. Use when requirements, scope, and validation commands are clear enough to code. Use bugfix for defect reproduction/fix loops, code-review to review implementation, verify for final readiness, and pr for PR handoff.

Review an implementation slice against the actual diff, governing artifacts, tests, and validation evidence, then record findings or a clean first-pass review. Use after implement hands off a milestone or when implementation review is requested. Use plan-review, spec-review, architecture-review, verify, or pr for those gates instead.

Explain why the agent made each meaningful change by linking the actual diff to the problem, proposal, requirements, architecture decisions, plan milestones, tests, review outcomes, and available validation evidence. Use after implementation and review-resolution, before final verify and PR, or whenever the user asks why code changed.

Create or revise a living execution plan after proposal, spec, and architecture are stable enough to implement. Use for multi-file, multi-component, risky, migration-heavy, or milestone-based work that needs reviewable implementation slices, validation commands, recovery paths, dependencies, and current handoff state. Use spec, test-spec, implement, code-review, verify, or pr for those stages; do not use plan to choose product direction, write code, review diffs, verify branch readiness, or open PRs.

Create a decision-oriented change proposal before spec or plan. Use when the user has a selected direction, explored options, problem statement, or issue that needs problem, goals, non-goals, options, recommendation, risks, rollout, and readiness recorded. Use proposal-review to review an existing proposal; use spec, plan, implement, or verify for downstream work.

Write or amend a contract-level feature spec before architecture, planning, test planning, or implementation. Use when accepted direction or requested behavior must become requirements for observable behavior, APIs, UI, config, data contracts, errors, compatibility, security, privacy, accessibility, performance, or safety-sensitive logic. Use spec-review to review a spec; use proposal, architecture, plan, test-spec, implement, verify, or pr for those stages.

Generate a traceable test specification from an approved feature spec and execution plan before writing test code or production code. Use to map requirements, examples, edge cases, architecture boundaries, and milestones into concrete tests.

Run final verification after durable change rationale exists and before PR handoff. Use to verify artifact-code-test coherence, requirement coverage, validation commands, CI readiness, drift, release safety, and scoped direct validation checks.

Independently review an active test specification before implementation. Use to assess proof-map alignment, requirement and edge-case coverage, milestone mapping, validation commands, fixtures, automation versus manual evidence, and implementation handoff readiness. Use test-spec to author or revise the proof map; use code-review and verify for implemented tests and final evidence.

Review a proposed architecture/design before execution planning. Use for cross-component, hard-to-reverse, data, security, performance, migration, or long-lived design decisions.

Review a concrete execution plan before implementation. Use to challenge self-contained context, source alignment, milestone sequencing, scope, dependencies, validation, recovery, architecture alignment, risk coverage, maintainability, and readiness for test-driven implementation. Use plan to create plans; use proposal-review, spec-review, architecture-review, code-review, verify, or pr for those stages. Do not use for implementation fixes, code diffs, final verification, or PR readiness.

Review a feature spec before architecture, test planning, planning, or implementation. Use when the user asks to challenge requirement clarity, normative language, completeness, testability, examples, compatibility, observability, security/privacy, non-goals, acceptance criteria, or readiness. Use spec to write specs; use proposal-review, architecture-review, plan-review, code-review, verify, or pr for those stages.

Create or update the technical architecture/design artifact after the spec is stable and before execution planning. Use when a change touches multiple components, data flow, persistence, APIs, deployment, performance, security, or long-lived design decisions.

Review a change proposal before spec. Use when the user asks to challenge problem framing, option quality, strategic value, scope boundaries, risks, vision fit, decision rationale, or readiness for spec. Use proposal to write proposals; use spec-review, plan-review, code-review, verify, or pr for later-stage review and readiness work.

Prepare a completed, verified change for pull request review. Use when the branch is ready or nearly ready and the agent should summarize the real diff, validation evidence, spec compliance, risks, and reviewer notes.

Build, refresh, or audit a current-state repository orientation map. Use when architecture, module boundaries, runtime flow, data flow, test layout, CI, ownership, or change placement is unclear. This skill records observed repository structure and bounded inferences; it does not invent future architecture or act as a backlog.

Build, refresh, or audit a current-state repository orientation map with cited evidence, bounded inference, known gaps, and durable root or area scope.

Author or review CI infrastructure such as GitHub Actions workflows, validation automation, and related platform configuration. Use when CI workflow coverage is missing, stale, too slow, too broad, too narrow, or needs least-privilege, cache-aware, risk-scoped maintenance.

Use this fixture when validating generated output asset presence.

Use this fixture when validating generated output asset presence.

Use this fixture when validating generated output asset presence.

Invalid skill readability fixture.

Invalid skill readability fixture.

Invalid skill readability fixture.

Invalid skill readability fixture.

Use a packaged asset while remaining portable across adapter roots.

Use this fixture for the plan asset pilot missing resource-map entry check.

Use this fixture when validating structural fingerprint drift.

Use this fixture when validating exact plan asset inventory.

Use this fixture when validating fields-to-fill requirements.

Use this fixture when validating asset metadata.

Use this fixture when validating placeholder requirements.

Use this fixture when validating literal COPY asset verbs.

Use this fixture when validating normative asset status.

Use this fixture when validating forbidden root dependencies inside assets.

Use this fixture when validating plan skeleton section-set parity.

Use this fixture when validating the assets-first plan pilot resource map.

Use this fixture to prove mapped skill-local packaged scripts are allowed.

Use this fixture to prove root script command dependencies are blocked.