From henkaten-council
Use this skill to run the council fan-out sequence (henkaten check, agent fan-out, decision logging, retrospective) for the next harness sprint, after the user runs `/trine-eval:harness-sprint`. Invoked as the `council-autorun` slash command under the `henkaten-council` plugin. Runs the full ten-step governance loop defined in §8.2 of the Phase-0 v2 proposal: pre-sprint henkaten check, yokoten review, trine-eval delegation, council fan-out, course correction, decision logging, halt condition evaluation, context compaction, mini retrospective, and next-sprint trigger logic.
How this skill is triggered — by the user, by Claude, or both
Slash command
/henkaten-council:council-autorunThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Outer sprint-loop skill for the henkaten-council governance plugin. Wraps
Outer sprint-loop skill for the henkaten-council governance plugin. Wraps
/trine-eval:harness-sprint with pre-sprint change-point detection, post-sprint
council review, course correction, dynamic autonomy floor management, context
compaction, and retrospective capture.
Prerequisite: .council/ must already exist in the target project (run
/henkaten-council:council-kickoff first). If .council/ is absent, this
skill halts at Step 0 and instructs the user to run council-kickoff.
Step 0 — Load State.
Read .harness/sprints.json, .harness/config.json,
.council/config.json, and .council/state/effective-autonomy.json. Determine
the current sprint number and effective autonomy level. If .council/ is
missing, halt and instruct the user to run /henkaten-council:council-kickoff
first.
Source: §8.2 Step 1A, v2.1 amendment A3
Purpose: detect and classify any change-points before handing off to trine-eval. If high-risk or blocking changes are found, halt before any sprint work begins.
When .council/ does not exist: this step is a NO-OP — the autorun
continues to Step 1A.5. The kickoff check in Step 0 will have already caught
this case; the NO-OP rule applies when .council/ is present but empty.
Compare the current .claude-plugin/plugin.json against the version recorded
in the last sprint's baseline (or the last git-committed version, whichever is
more recent):
git diff HEAD -- .claude-plugin/plugin.json
Any diff triggers an agent-capability-change Henkaten record via
scripts/append-henka.py.
Read .council/henka-register.jsonl. A record is unresolved if its
resolution_status field is anything other than "resolved" (equivalently: if
it lacks a closed_at timestamp). Surface all unresolved records to the
orchestrator's working context.
andon_signal: stop;
jump to Step 1F.For every newly detected change-point (manifest diff, state drift, user-modified files outside governance):
change_origin: active — the council or orchestrator initiated the change
(e.g., a previously-applied course correction).change_origin: passive — the change arrived from outside (user edit, CI
artifact, trine-eval output, external dependency bump).Classify on the 4M axis (Man / Machine / Method / Material) per the
schemas/henka-record.schema.json fourM_axis enum. Log via
scripts/append-henka.py.
During an active sprint, file edits to agents/, instructions/, templates/,
skills/, hooks/, scripts/, or schemas/ that fall within the active
sprint's declared scope are scheduled deliverables — NOT change-points — and
do NOT generate a Henkaten record.
henkaten-detector determines sprint scope by reading, in priority order:
.harness/contracts/sprint-{NN}.tasks.json (Phase 2 canonical machine-readable scope).harness/contracts/sprint-{NN}.md (human-readable contract; parse ## Files in Scope).harness/sprints.json (sprint-level deliverable list)If none of the above are available, the suppression rule is bypassed
(fail-safe — every edit fires as a Henkaten record) and the agent emits a
coverage warning listing which scope sources were unavailable.
Edits outside sprint scope are unscheduled and fire as
agent-capability-change Henkaten records with change_origin: passive.
Source: §8.2 Step 1A.5, v2.1 amendment A9
Purpose: surface lessons from prior sprints before starting the current sprint, so that the orchestrator has an opportunity to adapt — not blindly copy.
Read .council/henka-register.jsonl and identify all records with a non-empty
yokoten block. A yokoten block contains:
applicable_to_subsequent_sprints — list of sprint numbers (or "all")adaptation_notes — human-readable guidance for how to adapt this learningFilter to records where the current sprint number appears in
applicable_to_subsequent_sprints or where the value is "all".
For each applicable yokoten entry, surface an adaptation prompt to the orchestrator — not a copy-paste suggestion. The retrospective agent (or the user, per Q17 default) drafts the actual adaptation. The user reviews and ratifies.
Example prompt format:
"Yokoten HK-{ID} from sprint {source}: '{adaptation_notes}'. How should this be adapted for sprint {current}?"
Log the adaptation decision to the yokoten record's deployed_to[] array with
timestamp, decision_id, and a brief adaptation_taken note.
If a yokoten record names applicable_to_subsequent_sprints: ["all"] OR
names ≥3 specific sprint numbers, the user may ratify the adaptation once
with scope applies_to_remaining: true.
audit-log.jsonl as an observed action.no, which downgrades all remaining sprints back to per-sprint
ratification.The orchestrator does not execute yokoten adaptations autonomously — it surfaces them and records the user's ratification decision.
Source: ADR-0003. Audit-only at this stage; does not change dispatch fan-out or the autonomy floor.
Purpose: record a Cynefin classification of the upcoming sprint so that audit data captures the Orchestrator's prospective read of the work. The classification is informational; it does not modify any downstream council behavior at this stage.
Read at minimum:
.harness/contracts/sprint-{NN}.md — the sprint contract describing
the deliverable..council/standard-work.json — active procedures, loop-shapes, and
failure patterns.Optionally also: prior .council/sprint-prebrief/sprint-{NN-1}.json,
.council/jishuken/*.md artefacts relevant to the upcoming work.
Apply @instructions/sprint-prebrief.md to select one of clear,
complicated, complex, or chaotic. Confidence is required and may
be low; honest uncertainty is preserved as confidence: <0.5 rather
than inflated to avoid the appearance of uncertainty.
Name the expected loop-shape: either a shape_id from
standard-work.loop_shapes[] (e.g. plan-then-execute-loop,
probe-campaign) or the literal value "ad-hoc" when no named shape
fits.
Write .council/sprint-prebrief/sprint-{NN}.json per the schema in
schemas/sprint-prebrief.schema.json. Fields:
sprint_number, classified_at (ISO 8601 UTC), classified_by_agentcynefin, confidence, rationale (one paragraph citing the
specific characteristics that informed the label)expected_loop_shapeprojection_manifest (paths read for this classification),
stabilization_note (when cynefin: "chaotic"),
autonomy_floor_observed (captured for later analysis;
classification does NOT adjust the floor at this stage)The file is overwritten on re-run for the same sprint number (it is state, not an append-only log).
Present the classification to the user inline in the autorun output, e.g.:
"Sprint {NN} prebrief: cynefin =
{label}(confidence {value}). Expected loop-shape:{shape_id_or_ad-hoc}. Rationale: {one paragraph}."
If cynefin: "chaotic" with confidence ≥ 0.6, additionally surface:
"Recommendation: stabilization step before proceeding. The autorun loop does not halt automatically at this stage (ADR-0003); the user may choose to halt and address the chaotic-class conditions before trine-eval delegation."
The prebrief is frozen at sprint entry. If during execution the
Orchestrator observes that the classification was wrong, do NOT
rewrite the prebrief. Instead append a henka-record with
fourM_axis: "Method", category: "classification-mismatch",
change_origin: "passive", and evidence citing the original prebrief
file. The mismatch is then propagated through the standard yokoten
and PDCA pathways.
Source: §8.2 Step 1B
Purpose: hand off sprint execution to trine-eval. The council does not enter trine-eval's internal loop.
Invoke /trine-eval:harness-sprint {NN}. Wait for completion.
trine-eval's loop runs internally, covering:
.harness/sprint-state.json and .harness/progress.mdThe council is entirely external to this process. trine-eval is unaware of the council plugin during this step.
The autorun resumes at Step 1C ONLY after /trine-eval:harness-sprint reports
a sprint result (PASS / PARTIAL / FAIL). Do not proceed to Step 1C until a
result is available. If trine-eval does not return a result (timeout, crash),
issue andon_signal: stop and jump to Step 1F.
Source: §8.2 Step 1C, v2.1 amendments A1, A6
Purpose: convene the council, collect each agent's analysis of the completed sprint, verify observed claims, and handle any andon signals before proceeding to course correction.
Per Q6 default: dispatch agents sequentially in v0.1. Parallel dispatch
is available as a config knob (dispatch_mode: parallel in .council/config.json).
Agent dispatch order:
agents/architect.md — structural / contract alignment reviewagents/scope-guardian.md — scope drift detectionagents/henkaten-detector.md — change-point classificationagents/retrospective.md — in mini mode (capture-only for per-sprint pass)Each agent is dispatched as an isolated subagent via Task, using the
templates/dispatch-envelope.md envelope. Pass ONLY file paths and structured
constraints — never pass orchestrator reasoning into the subagent context.
Andon-Swarm Dispatch is unconditionally parallel (v2.1 A6): when an andon
signal triggers a swarm (see §1C.3), swarm agents are dispatched via parallel
Task calls regardless of dispatch_mode setting. Rationale: swarming is the
latency-sensitive case where the takt budget (andon_takt_seconds) makes
parallel dispatch necessary.
Each agent's output is written by the orchestrator to
.council/course-corrections/after-sprint-{NN}.md under that agent's section.
Before accepting an agent's output, verify that it includes:
evidence_class (one of observed, inferred, speculative)confidence (integer 1–5)coverage (list of files/paths the agent was able to examine vs. unavailable)observed claims: a verification field with a re-runnable commandIf an agent returned status: error → log the failure, skip that agent's
section, note the gap in the course-corrections file.
Every agent output is scanned for an andon_signal field. The orchestrator
MUST refer to instructions/andon-protocol.md for full protocol details.
On andon_signal: stop:
instructions/andon-protocol.md:
"Thank you for stopping the line. Your signal has been received and will be honored. No further sprint steps will proceed until this is resolved."
On andon_signal: alert:
swarm_requestandon_takt_seconds from .council/config.json
(default: 600 seconds / 10 minutes per v2.1 A6)andon_resolution: {originator, swarm, resolution, duration_seconds}.alert automatically
escalates to stop. Jump to Step 1F.Pull-rate per agent is tracked in audit-log.jsonl (weight 2 for stop,
weight 1 for alert). See instructions/andon-protocol.md for anomaly
thresholds and the distinct-originator corroboration rule.
For every agent output, identify all claims with evidence_class: "observed".
From those claims, randomly sample one and re-run its verification command.
Invoke:
python scripts/run-verification.py "<verification_string>"
scripts/run-verification.py enforces the §7.0.2 syntax allowlist (read-only
git/grep/cat/jq/test/validation helpers) with a 10-second execution timeout and
project-root CWD. Use --check-only to check the allowlist without executing
(used in test isolation).
If the verification string is NOT on the allowlist (pre-execution check):
agent-capability-change Henkaten record via scripts/append-henka.py:
{
"fourM_axis": "Machine",
"change_origin": "active",
"change_type": "agent-capability-change",
"description": "Non-conformant verification string rejected",
"rejected_string": "<the offending string>",
"agent_id": "<agent>"
}
verification string.If the verification command runs but the result diverges from the agent's
report: log a quality-defect-anomaly Henkaten with change_origin: passive
and high impact.
Log all spot-check results (pass or fail) to audit-log.jsonl.
Source: §8.2 Step 1D, v2.1 amendment R9
Purpose: classify each proposed correction as minor (auto-apply) or major (nemawashi walkthrough), with reversibility as the primary gate.
Before classifying a correction as minor or major, determine its reversibility:
| Action | Reversibility |
|---|---|
File writes to .council/ working dirs, course-corrections/, proposed/, retrospectives/, sessions/ | reversible (git revert) |
Appends to *.jsonl append-only logs | reversible-with-caveat (entry persists; counter-entry can supersede) |
File writes to .harness/features.json, spec.md, sprints.json | reversible per git, but Level 5 by Rule 3/7 |
git push, git push --force | irreversible |
git reset --hard | irreversible |
git rebase -i, deleted pushed tags | irreversible (shared repos) |
| Public release / deployment | irreversible |
Irreversible actions auto-escalate to MAJOR regardless of nominal class.
Minor AND reversible corrections may be auto-applied after a single prompt: "Apply minor correction X? (yes/no)"
Minor correction examples:
.council/ state file updatesprogress.mdpending → doneMajor corrections OR any irreversible action require the four-stage nemawashi walkthrough (§8.2 Step 1D, R5). The walkthrough is defined in full below.
Irreversible-action auto-escalation (§2.4.2, R9): The reversibility check
(Step 1D.1) precedes the minor/major classification. If the proposed action's
reversibility is irreversible, the orchestrator MUST initiate the 4-stage
mandatory nemawashi walkthrough even if the nominal scope says minor. No
exception exists for truly irreversible changes — they always escalate to the
major path and require Level 5 (human) approval via Stage 4.
Single-prompt minor approval path (Q15): For a reversible minor change with effective-autonomy level ≥ 4, no position paper is created. The orchestrator prompts the user with a one-line summary: "Apply minor correction X? (yes/no)" and applies on confirmation. The DEC entry for this path has:
decision_type: course-correction-minornemawashi_walkthrough_version: nullreversibility: reversibleThe literal nemawashi_walkthrough_version: null MUST appear in the DEC entry
for the single-prompt minor path (not 0, not omitted — exactly null).
Major correction categories (any item below requires nemawashi or Level 5):
features.json modificationsspec.md amendmentsSource: §8.2 Step 1D Stage 1, R5, A4
The orchestrator writes the full position paper BEFORE presenting anything to the user. The position paper is the orchestrator's complete analysis, with every agent's perspective and evidence chain, organized so the user can form an independent judgment.
File location: .council/proposed/DEC-{NNNN}.md
DEC-0042)
matching the pattern ^DEC-[0-9]{4,}$, consistent with the decision-log
schema in schemas/decision-log-entry.schema.json.templates/nemawashi-position-paper.md as the scaffold.The position paper must include:
evidence_class, confidence, and conformant
verification commands per §7.0.2 allowlist).irreversible: explain why and note that mandatory nemawashi applies.After writing the position paper, surface to user:
"I've drafted a proposal at
.council/proposed/DEC-{NNNN}.md. May I walk you through each agent's perspective before asking for approval? (yes/no)"
If the user says no, the sprint loop halts (Step 1F halt condition 4:
user_intervention_requested) with the position paper left in place.
Source: §8.2 Step 1D Stage 2, R5
Dispatch order matches Step 1C fan-out:
.council/council-manifest.json)For each agent, the orchestrator reads the corresponding perspective from the position paper and presents it to the user with the three-handle prompt:
"[Agent Name] reviewed the sprint results and found: [brief summary of finding and evidence]. [Agent Name]'s view is that [perspective on the proposed change].
Does [Agent Name]'s framing match your understanding? (yes / refine / disagree)"
Three-handle responses:
yes — Record agreement in the position paper's Stage 2 section. Proceed
to the next agent's perspective.refine — Record the specific refinement the user offers. Re-present the
agent's perspective with the refinement incorporated. If the user accepts
the re-presented version (yes), record as "yes after refine" — no Stage 3
needed for this agent. Multiple refine handles accepted in-line in Stage 2
do NOT require Stage 3.disagree — Record the disagreement with the user's stated reason. Continue
to the next agent. Accumulate all disagreements; advance to Stage 3 after
all agents have been presented.All three-handle responses are logged to .council/audit-log.jsonl via the
log-tool-call hook (sprint 5). Each log entry records: dec_id, agent_id,
stage, handle, timestamp, and (for refine/disagree) the user's
stated reason.
Stage 2 outcome determination:
yes (or yes after refine) → skip Stage 3; advance to Stage 4.disagree → advance to Stage 3 regardless of other agents' handles.Source: §8.2 Step 1D Stage 3, R5
Skip condition: If all Stage 2 responses were yes (or yes after refine),
skip directly to Stage 4.
When Stage 3 is triggered (at least one disagree):
-rev{N} suffix:
.council/proposed/DEC-{NNNN}-rev1.md.council/proposed/DEC-{NNNN}-rev2.md.council/proposed/; the audit
chain preserves all versions.Escalation-to-halt: If alignment is not reached after 2 revision cycles
(default; configurable in .council/config.json), log status: escalated-to-user,
present remaining disagreements to the user, and HALT. Do not auto-proceed to
Stage 4.
Multiple refine handles from Stage 2 are batched into a single Stage 3
revision pass — one revision file addresses all accumulated refinements.
Track in the position paper's Stage 3 section:
disagree or refine motivated each revisionSource: §8.2 Step 1D Stage 4, R5, v2.1 amendment A4
Precondition: all agent perspectives are aligned (no outstanding
disagree handles from Stage 2 / Stage 3).
Ratification prompt (Orchestrator says):
"All perspectives are aligned on DEC-{NNNN}. To confirm:
Proposed change: {one-sentence summary} Affected files: {comma-separated list} Reversibility: {reversible / irreversible}
Apply DEC-{NNNN}? (yes/no)"
This is a Level-5 (human) step. The orchestrator blocks until the user
types yes or no.
On yes (ratified):
Apply the proposed change, routing any standard-work update by pattern_type.
Read the optional pattern_type front-matter field from the position paper.
When the change updates .council/standard-work.json, append the ratified
entry to the array named by pattern_type — defaulting to procedure when
the field is absent or unrecognized:
pattern_type | standard-work.json array | required item fields |
|---|---|---|
procedure (default) | procedures[] | procedure_id, name, steps |
failure-pattern | failure_patterns[] | pattern_id, description, mitigation |
evaluation-improvement | evaluation_improvements[] | improvement_id, description |
workflow-note | workflow_notes[] | note_id, description |
loop-shape | loop_shapes[] | shape_id, name, problem, forces, solution, consequences, evidence_sprints, status |
The appended entry MUST validate against schemas/standard-work.schema.json
for the target array; if it does not, treat it as a ratification error — do
not write a malformed entry, halt, and surface the schema violation. After a
successful append, update standard-work.json's updated_at, updated_by,
and ratified_decision_id: DEC-{NNNN}. A decision that does not touch
standard-work.json (e.g. an irreversible-action approval, with
pattern_type omitted) applies its change directly, with no array routing.
Commit using this message pattern: DEC-{NNNN}: {description}.
Move the position paper from .council/proposed/ to
.council/proposed/archive/DEC-{NNNN}.md (or the final revision filename
if Stage 3 was triggered — e.g., DEC-{NNNN}-rev{N}.md). The original
file is moved, not copied and not deleted; the archive copy is the
preserved audit record. Per v2.1 amendment A4: the decision-log.jsonl
nemawashi_walkthrough_version path must remain resolvable at the archive
location.
Append audit-log entry: "DEC-{NNNN} position paper archived at
.council/proposed/archive/DEC-{NNNN}.md" via the log-tool-call hook.
Emit DEC entry via scripts/append-decision.py with full fields:
decision_type: course-correction-majornemawashi_walkthrough_version: {N} — the number of Stage 3 revision
cycles (0 if Stage 3 was never triggered, 1 if one revision was needed,
etc.)reversibility: {reversible | irreversible}status: ratifiedapplied_at: {ISO-8601 timestamp}dec_id: DEC-{NNNN}On no (rejected):
status: rejected..council/proposed/ for reference.scripts/append-decision.py with status: rejected,
applied_automatically: false.Andon signals during the walkthrough: If any agent issues
andon_signal: stop during Stage 1–4, the orchestrator MUST honor it
unconditionally and precede its response with the verbatim thank-the-puller
acknowledgment from instructions/andon-protocol.md. The walkthrough halts
and jumps to Step 1F.
Cross-references: templates/nemawashi-position-paper.md,
.council/proposed/, .council/proposed/archive/,
scripts/append-decision.py, instructions/andon-protocol.md.
Source: §8.2 Step 1E
Purpose: record every correction, classification, and review outcome in
decision-log.jsonl so the audit trail is complete and the system can
reconstruct its own history without relying on conversation context.
For each change applied (minor or major), append a DEC entry to
.council/decision-log.jsonl via scripts/append-decision.py.
Required fields per schemas/decision-log-entry.schema.json:
| Field | Description |
|---|---|
decision_id | Sequential DEC-NNNN identifier |
timestamp | ISO 8601 UTC timestamp at time of logging |
decision_type | e.g., "minor-correction", "major-correction", "sprint-halt", "andon-resolution" |
decision_outcome | "applied", "proposed", "rejected", "deferred", "halted", "superseded" (per schemas/decision-log-entry.schema.json; use "halted" when an andon stop or harness-imposed resource cap terminates the sprint before the decision is applied) |
autonomy_level_used | The level the orchestrator was operating at when the change was applied |
effective_autonomy_at_decision | Level read from .council/state/effective-autonomy.json at the moment the decision was made |
reversibility | "reversible" or "irreversible" |
nemawashi_walkthrough_version | null for minor reversible auto-applied changes; 0 for sprint-6 stub; integer ≥1 for future full walkthrough versions |
description | Human-readable summary of what was decided and why |
council_agents_involved | List of agent IDs that contributed findings |
evidence_cited | Array of {evidence_class, verification, summary} entries |
linked_henka_id | HK-NNNN of the henkaten record(s) this decision responds to, if any |
sprint_context | Sprint number and result (PASS/PARTIAL/FAIL) |
applied_automatically | true for minor auto-applied; false for user-approved or pending |
user_approval_required | true for major/irreversible; false for minor reversible |
affected_files | Relative paths of files modified by this decision |
If the decision responds to a henkaten record, set linked_henka_id and update
that record's resolution_status to "responded" (or "resolved" if fully
closed). If closed, the retrospective agent populates the yokoten block (R6).
Source: §8.2 Step 1F, §2.4.3, v2.1 amendment A2
Purpose: enumerate all conditions that require halting the sprint loop and stopping autonomous action, including the dynamic autonomy floor drop mechanism.
The sprint loop halts if ANY of the following are true:
andon_signal: stop received from any agent → UNCONDITIONAL halt.
No filter, no deferral, no second-guessing. See instructions/andon-protocol.md.
The effective autonomy floor drops when the distinct-originator corroboration requirement is satisfied:
andon_signal: stop events within the current sprint loop,
issued by ≥2 distinct originator agents.agent_id values. The same agent stopping twice
counts as one originator, not two.reason and evidence
fields of each stop signal.Same-agent repeated stops are NOT a floor-drop trigger. They are tracked
as quality-defect-anomaly Henkaten records (change_type: agent-capability-change,
fourM_axis: Machine) — logged for pattern recognition and surfaced at the
next retrospective. A single agent cannot drop the autonomy floor alone.
Floor-drop effect:
change_origin: active Henkaten flagged high-risk → automatic drop to
L1 across all agents.When a floor drop is triggered, the orchestrator calls
scripts/update-effective-autonomy.py with the new level and the triggering
evidence.
Restoration: via /council-review --restore-autonomy flag (sprint 7 / S5
territory — document the path here; do not implement).
Any blocking or high-risk Henkaten record not resolved before sprint start
(detected in Step 1A) → issue andon_signal: stop; halt.
A major correction is pending (DEC placeholder created in Step 1D.3) and Stage 4 of the nemawashi walkthrough has not been ratified → halt pending user input.
If the percentage of observed claims failing the allowlist check across all
agents in this sprint exceeds the configured threshold (config.max_verification_failure_rate,
default 20%) → halt and surface the failure pattern to the user. This may
indicate a systemic agent-capability issue.
If scripts/append-henka.py or scripts/append-decision.py returns non-zero
exit code → halt before the record is partially written. Do not retry
automatically; surface the validation error to the user.
On any halt: write a decision-log entry with decision_type: "sprint-halt",
describe the trigger and evidence, and surface to the user. The sprint does not
auto-resume. Restart requires explicit /council-review invocation.
The nemawashi_walkthrough_version field in the halt's decision-log entry:
null if the halt was not nemawashi-related; 0 if the halt was triggered by a
pending sprint-6 nemawashi stub; ≥1 for future versions.
Source: §8.2 Step 1G
Purpose: snapshot the session's working context so that future sessions can resume without relying on conversation history (which may be compacted or lost).
Context compaction runs unconditionally after every sprint, regardless of sprint result.
Compact to ≤500 words in the session snapshot file.
Write the snapshot to:
.council/sessions/<UTC-ISO8601>.md
Example: .council/sessions/2026-05-09T14:32:00Z.md
The session file is the source of resumption for future sessions, but .harness/
and .council/ structured files (jsonl logs, state files) are always the
authoritative source of truth and are re-read on session resume.
Source: §8.2 Step 1H, v2/R7
Purpose: capture a brief retrospective immediately after every sprint, inline and without blocking the orchestrator.
Call /henkaten-council:council-retro-mini (full implementation is a sprint 8 /
S6 deliverable; in sprint 6 this is a stub).
Sprint 6 stub behavior:
.council/retrospectives/sprint-{NN}-mini.md
# Sprint {NN} Mini Retrospective
Sprint: {NN}
Result: PASS
Timestamp: 2026-05-09T14:35:00Z
Summary: (no council-retro-mini skill yet; stub entry)
Constraints:
mini mode — Learning Points and Pattern
Observations only, no Standard Work ProposalsSource: §8.2 Step 1I
Purpose: determine whether to invoke another sprint iteration, trigger a per-cycle retrospective, or surface a final summary.
| Condition | Action |
|---|---|
More sprints in sprints.json + no active halt | Prompt user: "Sprint {NN} complete. Proceed to sprint {NN+1}? (yes/no)" If yes, return to Step 1A for the next sprint. |
Sprint count divisible by cycle_length (default 5) | Invoke /henkaten-council:council-retro for the per-cycle PDCA retrospective before the next sprint (sprint 8 / S6 delivers the full skill; sprint 6 skips this invocation with a log note) |
| All sprints complete | Present final summary. Suggest /henkaten-council:council-retro (final cycle) and optionally /henkaten-council:council-jishuken |
| Active halt condition | Present halt reason and evidence. Wait for explicit user input. Do not auto-resume. |
This skill must NOT recursively invoke itself. The next-sprint loop is
operator-driven — the user explicitly initiates a new council-autorun
invocation for each sprint, or the orchestrator prompts and waits for a yes
response before proceeding to the next sprint. Automatic recursive
self-invocation would bypass human oversight and is explicitly prohibited.
The trigger logic here is documentation only; actual loop scheduling is
operator-driven.
When the cycle trigger fires (sprint count divisible by cycle_length), the
per-cycle PDCA retrospective runs before the next sprint's Step 1A. This allows
standard-work proposals to emerge from the retrospective and be incorporated into
the next sprint's contract before it is negotiated.
This skill depends on and coordinates with the following files:
| Dependency | Purpose |
|---|---|
instructions/andon-protocol.md | Full andon signal protocol: thank-the-puller acknowledgment, Rule 4 carve-out, pull-rate tracking, distinct-originator corroboration |
scripts/run-verification.py | §7.0.2 allowlist enforcement, 10s timeout, agent-capability-change Henkaten logging for non-conformant strings |
scripts/append-henka.py | Append-only writer for .council/henka-register.jsonl |
scripts/append-decision.py | Append-only writer for .council/decision-log.jsonl |
scripts/update-effective-autonomy.py | Updates .council/state/effective-autonomy.json when the autonomy floor changes |
agents/orchestrator.md | Orchestrator identity, tool grants, autonomy level (L4) |
agents/architect.md | Structural review agent (L2, fork context) |
agents/scope-guardian.md | Scope drift detection agent (L2, fork context) |
agents/henkaten-detector.md | Change-point classification agent (L1, fork context) |
agents/retrospective.md | Retrospective capture agent (L2, fork context, mini mode here) |
schemas/decision-log-entry.schema.json | Schema for decision-log entries (Step 1E) |
schemas/henka-record.schema.json | Schema for henkaten records (Steps 1A, 1C) |
templates/dispatch-envelope.md | Standardized subagent dispatch template (Step 1C) |
templates/nemawashi-position-paper.md | Position paper template for major decisions (Step 1D Stages 1–4) |
The following behaviors are documented in this skill but not implemented in sprint 7. They are stubs or references only:
/council-retro per-cycle PDCA — sprint 8 / S6. Referenced in Step 1I./council-retro-mini skill — sprint 8 / S6. Step 1H uses a stub..council/ directory — .council/ does not exist in this plugin
repo. All write-path behaviors target a consumer project's .council/
directory. This file is descriptive documentation only.The following were stubs in sprint 6 and are now fully implemented in sprint 7:
/council-review --restore-autonomy — implemented in
skills/council-review/SKILL.md (sprint 7 / S5 deliverable).npx claudepluginhub ats-kinoshita-iso/henka-council --plugin henkaten-councilProvides UI/UX resources: 50+ styles, color palettes, font pairings, guidelines, charts for web/mobile across React, Next.js, Vue, Svelte, Tailwind, React Native, Flutter. Aids planning, building, reviewing interfaces.
Fetches up-to-date documentation from Context7 for libraries and frameworks like React, Next.js, Prisma. Use for setup questions, API references, and code examples.