change-council

Routes repository changes through research, architecture, implementation, validation, and human review gates.

Updated Dec 12, 2025
One-click install
npx skills add https://github.com/ricardojjulia/ESACompanion --skill change-council-ricardojjulia
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: change-council
Source: https://github.com/ricardojjulia/ESACompanion/tree/main/.github/skills/change-council
Command: npx skills add https://github.com/ricardojjulia/ESACompanion --skill change-council-ricardojjulia

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Unstructured code changes often skip research, exceed scope, or ship without validation. This Skill enforces a mandatory council workflow so every feature, fix, dependency update, or refactor passes through defined review gates with human approval before delivery. ## Core Features & Use Cases - Five council seats: Researcher, Architect, Implementer, Validator, and Reviewer roles with strict read-only or edit permissions to separate concerns. - Gated workflow: A required sequence of intake, research, architecture approval, implementation, validation, review, and delivery, with explicit approve/revise/reject rules. - Decision records: Non-trivial changes are captured as structured council records in .github/council/ documenting scope, non-goals, validation plans, and findings. - Use Case: Before refactoring a Dynatrace app's data layer, run the council to map affected files, get architecture approval, implement within the approved scope, and validate against the recorded decision. ## Quick Start Ask the AI to run the change council for your next planned change, starting with an intake statement of the request, motivation, and non-goals.

Frequently Asked Questions about change-council

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

FAQPage Schema
How do I enforce a review process before making code changes?▼

Run every change through the council sequence: intake, research, architecture gate, implementation, validation, and review. Each gate requires explicit human approval, changes-requested, or rejection before proceeding to the next stage.

What roles are involved in a structured code change workflow?▼

The council defines five seats: Researcher and Architect (read-only analysis and scoping), Implementer (the only role allowed to edit product files), and Validator and Reviewer (read-only verification and release-readiness checks).

Does the change council apply to small fixes and documentation updates?▼

Yes, the workflow is mandatory for every change including fixes, docs, configuration, and dependency updates. Small changes still follow the sequence, but the decision record can be summarized in the final response instead of a repository file.

What happens when validation finds critical issues in a change?▼

Critical findings trigger a repair loop: the implementer fixes the issue within the approved scope, then validation runs again. The validator never fixes its own findings, and the change cannot proceed until validation passes.

When should a council decision record be created?▼

Create a record in `.github/council/<change-id>.md` for non-trivial changes, capturing the request, research findings, approved scope, non-goals, validation plan, decision, review findings, and delivery summary.