instar-dev

Coordinate safe, audited changes to the instar source tree.

75|18|Updated Feb 19, 2026
One-click install
npx skills add https://github.com/JKHeadley/instar --skill instar-dev
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: instar-dev
Source: https://github.com/JKHeadley/instar/tree/main/skills/instar-dev
Command: npx skills add https://github.com/JKHeadley/instar --skill instar-dev

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes scripts (resource) components.

What problem does it solve?

This Skill gives the instar-developing agent a safe, enforced workflow for changing the instar repository without skipping the reviews, traces, and gates that protect every downstream agent.

Core Features & Use Cases

  • Structured change process: It wraps development in required phases for principle checking, planning, build execution, side-effects review, trace writing, and commit verification.
  • Repository-level enforcement: It is designed for changes to runtime code, hooks, skills, jobs, templates, scaffolds, routes, and other behavior that ships with instar.
  • Risk controls: It adds spec prerequisites, signal-vs-authority checks, second-pass review for high-risk changes, and no-deferrals enforcement so partial fixes do not slip through.
  • Use case: An agent updating a gate, recovery path, or remediation runbook uses this Skill to make the change, prove the side effects were reviewed, and produce the artifacts required for commit and push.

Quick Start

Use the instar-dev skill to make a compliant change to the instar source tree, then complete the required review artifact and trace before committing.

Frequently Asked Questions about instar-dev

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

FAQPage Schema
How do I enforce a safe development workflow for repository updates that affect runtime behavior?

To enforce safe repository updates, you need a structured change process that wraps development in required phases for principle checking, planning, build execution, side-effects review, and trace writing. This ensures runtime behavior changes are fully audited.

What is side-effects review and when is it needed for commit gating?

Side-effects review is a mandatory validation phase needed when modifying runtime code, hooks, or templates to prove downstream impacts were analyzed. It acts as a commit gate to prevent unreviewed behavior changes from slipping through.

How do I add trace logging to source tree changes before pushing?

You add trace logging by completing the required trace writing phase after build execution and side-effects review. This produces the necessary audit artifacts that verify hook-compliant commit and push behavior for repository changes.

Can I apply spec validation and no-deferrals enforcement to partial fixes?

No, no-deferrals enforcement explicitly prevents partial fixes from passing. Spec prerequisites and signal-vs-authority checks must be fully satisfied, requiring second-pass review for any high-risk changes before commit gating allows the update.

Does this structured change process work for updating remediation runbooks and recovery paths?

Yes, the process is designed for changes to runtime code, hooks, jobs, templates, and remediation runbooks. An agent updating a recovery path uses it to make the change, prove side effects were reviewed, and produce required commit artifacts.

Why do repository enforcement workflows require second-pass review for high-risk changes?

Repository enforcement requires second-pass review because high-risk changes to runtime behavior and hooks impact every downstream agent. Signal-vs-authority checks and spec validation ensure changes are verified and no partial fixes slip through.