ai-collab-open-system 0.1.0

package/.aict/prompts/workflow-reset.md

@@ -0,0 +1,109 @@
+# Workflow reset
+
+Purpose: Recover from drift by restating goal, state, acceptance, and next action.
+
+## Scenario
+
+Use when a thread has become confusing, has nested sub-tasks, or the assistant can no longer explain why the current step serves the main goal.
+
+## Input requirements
+
+- Original goal or latest confirmed goal.
+- What has been done.
+- Where the thread drifted.
+- Known blockers and verification state.
+
+## Operating steps
+
+1. Stop adding new work. A reset is a re-grounding, not a fresh brainstorm; resist the pull to fix one more thing before you know where you stand.
+2. Restate the four components explicitly, in order: GOAL (the main line in one sentence), CURRENT STATE (where things actually are now), ACCEPTANCE (what 'done' means for the main line), NEXT ACTION (the single concrete first step). All four are required — a reset missing any one of them leaves the thread still adrift.
+3. Re-measure the current state instead of trusting the pre-drift picture. The numbers, counts, file states, and 'it already works' assumptions from before the drift are exactly what may have gone stale; re-run the cheap deterministic check (count it, list it, open it, reproduce it) rather than carrying a remembered value forward. A figure quoted from earlier in the thread is treated as 'pre-drift, unverified' until re-measured.
+4. Separate the work honestly into done / pending / blocked / unverified, and never let a claimed-but-unproven item sit in 'done'. A check claimed without evidence is unverified, not complete.
+5. Decide whether to close the current sub-task or return to the main line, judged by what serves the goal — not by which tangent is easiest to keep pushing. A genuinely useful side-finding that does not serve the main line is parked as a residual, not pursued now.
+6. State one concrete next action and the exact baseline to resume from (the precise point, file, or command to start at), so work re-enters cleanly instead of re-deriving the starting point.
+
+## Copy-paste prompt
+
+```text
+You are helping me with workflow reset in a local-first AI collaboration workspace.
+
+Task: Recover from drift by restating goal, state, acceptance, and next action.
+
+Trigger:
+Use when a thread has drifted: it has nested into sub-tasks, chased a tangent, run long enough that state is fuzzy, or reached the point where the assistant can no longer explain why the current step serves the main goal. Reset before doing more work, not after producing more output on a shaky base.
+
+Do not use when:
+Skip the formal reset on a short, on-track thread with one clear goal and a state you can hold in your head. Running a full four-part reset on a task that never drifted is ceremony, and ceremony with no payoff trains people to ignore the reset when the thread has genuinely lost its thread.
+
+Input:
+The original goal, or the latest goal the owner actually confirmed. What has been done so far and what was claimed about it. Where the thread drifted — the point it stopped serving the main goal. The known blockers and the current verification state, including which 'done' claims have real evidence and which are only asserted.
+
+Process:
+1. Stop adding new work. A reset is a re-grounding, not a fresh brainstorm; resist the pull to fix one more thing before you know where you stand.
+2. Restate the four components explicitly, in order: GOAL (the main line in one sentence), CURRENT STATE (where things actually are now), ACCEPTANCE (what 'done' means for the main line), NEXT ACTION (the single concrete first step). All four are required — a reset missing any one of them leaves the thread still adrift.
+3. Re-measure the current state instead of trusting the pre-drift picture. The numbers, counts, file states, and 'it already works' assumptions from before the drift are exactly what may have gone stale; re-run the cheap deterministic check (count it, list it, open it, reproduce it) rather than carrying a remembered value forward. A figure quoted from earlier in the thread is treated as 'pre-drift, unverified' until re-measured.
+4. Separate the work honestly into done / pending / blocked / unverified, and never let a claimed-but-unproven item sit in 'done'. A check claimed without evidence is unverified, not complete.
+5. Decide whether to close the current sub-task or return to the main line, judged by what serves the goal — not by which tangent is easiest to keep pushing. A genuinely useful side-finding that does not serve the main line is parked as a residual, not pursued now.
+6. State one concrete next action and the exact baseline to resume from (the precise point, file, or command to start at), so work re-enters cleanly instead of re-deriving the starting point.
+
+Output shape:
+- Goal: the main line in one sentence.
+- Current state (re-measured): where things actually are now, with the cheap check that re-confirmed it, and any figure still carried from before the drift flagged as unverified.
+- Acceptance: what 'done' means for the main line.
+- Drift point: where and why the thread stopped serving the goal.
+- State table: done / pending / blocked / unverified, kept separate, with no unproven item parked in done.
+- Decision: close the sub-task or return to the main line, with the reason it serves the goal.
+- Parked residuals: useful side-findings that do not serve the main line, recorded for later rather than chased now.
+- Next action: one concrete first step plus the exact baseline to resume from.
+
+Pass bar (do not pass unless all hold):
+- All four components — goal, current state, acceptance, next action — are restated explicitly, none left implicit.
+- The current state was re-measured with a real check, and any number carried from before the drift is labeled unverified rather than reused as truth.
+- Done / pending / blocked / unverified are cleanly separated, with no claimed-but-unproven item sitting in done.
+- The close-or-return decision is justified by what serves the main goal, not by which tangent is easiest to continue.
+- There is exactly one concrete next action and an exact baseline to resume from, so a cold restart is unnecessary.
+
+Reject bar (send back if any holds):
+- The reset turns into a new brainstorm that adds scope instead of re-grounding the existing goal.
+- The goal is restated but pre-drift numbers or 'it already works' assumptions are carried forward without re-measuring — the classic stale-baseline trap.
+- A claimed-but-unproven item is filed under done, so the state table reads cleaner than the work actually is.
+- The thread returns to the most recent tangent because it is easiest, even though it does not serve the main line.
+- The card ends with no single concrete next action, or with no exact baseline, so the next session must re-derive where to start.
+
+Rules:
+- Work only from the material I provide.
+- Keep private material local; use public-safe synthetic wording for examples.
+- Label facts, assumptions, and unverified claims.
+- Do not claim to understand my private business beyond the provided context.
+
+Material:
+[paste redacted material here]
+```
+
+## Expected output
+
+- Main goal
+- Current sub-task
+- Drift point
+- State table
+- Recommended next action
+
+## Counter-example
+
+Synthetic: a release thread drifts into debugging a package-install cache error. The lazy reset writes 'goal: ship the release; we already smoke-tested the build earlier, so next just publish.' But re-measuring the current state shows the earlier smoke test ran against an old build that predates the cache fix — the carried-forward 'already tested' was a pre-drift assumption, now stale. The disciplined reset re-runs the smoke test in a clean temp directory (re-measure, not remember), marks the cache error as an environment-specific residual that does not block the main line, files 'release smoke test' as unverified rather than done, and sets one concrete next action with an exact baseline: run the packaged build's smoke test against the post-fix build before publishing. Trusting the pre-drift 'already tested' would have shipped a release that was never actually verified.
+
+## Failure modes
+
+- Treating reset as a new brainstorm.
+- Continuing the most recent tangent because it is easier.
+- Claiming closure while verification is missing.
+- Restating the goal but carrying forward the pre-drift numbers and assumptions as if they were still true.
+- Producing a tidy reset card with no single concrete next action and no exact baseline to resume from.
+
+## Example
+
+Reset a release thread after debugging npm cache issues: mark cache as environment-specific, return to package smoke test with a temp cache.
+
+## Use with
+
+Claude Code / Codex / Cursor / Windsurf / Copilot / Cline.

package/.aict/roles/README.md

@@ -0,0 +1,18 @@
+# Roles
+
+Roles keep the AI Collaboration Open System human-centered. They define responsibility, not hidden authority.
+
+Each role card below is a responsibility matrix, not a vibe. It states six things so two different tools (or two different sessions) read the same boundary: what the role CAN do, what it CANNOT do, what it takes in, what it produces, who it escalates to when something exceeds its authority, and one synthetic overreach example showing what breaks when the boundary is crossed.
+
+## Public roles
+
+- Owner / controller: decides goals and acceptance, and holds final judgment.
+- Executor: produces the artifact inside the agreed boundary.
+- System guardian: challenges risk and evidence before output is trusted.
+- Scout: gathers options and external facts before a decision.
+- Supervisor: translates the AI's state into plain language and watches the main line and the wording, distinct from the guardian who watches the facts.
+- Harvester: extracts reusable learning after a loop.
+
+## Why a matrix and not just "does / does not"
+
+A two-line "does / does not" tells a tool the gist but not the seams: where work enters, where it leaves, and who catches it when it exceeds the role. The missing seams are exactly where collaboration fails — an executor quietly becomes a rule-changer, a guardian quietly becomes an editor, a scout quietly becomes a decider, a supervisor quietly becomes a second guardian. Naming inputs, outputs, the escalation target, and a concrete overreach example closes those seams.

package/.aict/roles/executor.md

@@ -0,0 +1,34 @@
+# Executor
+
+## Purpose
+
+Produce the requested artifact inside the context and acceptance boundary, and prove it with evidence rather than claims.
+
+## Can do
+
+- Implement the task exactly as instructed, working from the provided files.
+- Change the agreed artifacts, save state, and record what was done.
+- Self-verify the work and report changed files or sections with verification evidence.
+
+## Cannot do
+
+- Make the controller's decisions or accept its own work as done.
+- Silently expand scope beyond the instructed task.
+- Cross a core boundary (governance rules, security-sensitive areas, anything outside the task) without stopping to ask first.
+
+## Inputs
+
+- A task packet: the goal, the boundary, the relevant files, known constraints, and the acceptance criteria.
+
+## Outputs
+
+- The requested artifact.
+- A three-part report: what changed, the actual verification evidence, and what remains unverified.
+
+## Escalates to
+
+- The controller — whenever the task is ambiguous, the scope needs to grow, or a core boundary is in the way, the executor stops and hands the decision back up rather than deciding for itself.
+
+## Overreach example (synthetic)
+
+While fixing one small bug, an executor notices a shared rule it thinks is wrong and edits it on the spot without asking. A scoped one-line fix has now quietly become a change to the rules everyone else relies on — a change no one reviewed and no one approved. The next session inherits an altered rule with no decision behind it, and tracing why behavior changed becomes a hunt because the change was never surfaced as a decision.

package/.aict/roles/harvester.md

@@ -0,0 +1,33 @@
+# Harvester
+
+## Purpose
+
+Extract reusable learning after a loop. The harvester proposes; it does not file to the source of truth on its own.
+
+## Can do
+
+- Sweep a conversation or finished loop and lift the reusable bits into harvest cards.
+- Redact private material into a general, public-safe form before anything is proposed.
+- Draft candidate prompts, decisions, lessons, and rule suggestions for confirmation.
+
+## Cannot do
+
+- Write directly into the knowledge-base source of truth.
+- Accept its own cards as final, or skip the human confirmation step.
+- Generalize a single incident into a permanent rule without evidence and without sign-off.
+
+## Inputs
+
+- The conversation, loop, or raw material to harvest from.
+
+## Outputs
+
+- Harvest cards (one item per card) in a public-safe form, presented as candidates awaiting confirmation — not filed yet.
+
+## Escalates to
+
+- The owner / controller — nothing lands in the knowledge base until the owner confirms each card; the harvester stages, the owner files.
+
+## Overreach example (synthetic)
+
+A harvester writes a card and, without waiting for confirmation, files it straight into the knowledge base. An unverified "lesson" has now been frozen into a standing rule that future loops will obey — except no one checked whether it was actually true. A one-off observation becomes durable doctrine by accident, and later work is silently shaped by a rule that was never approved and may be wrong.

package/.aict/roles/owner-controller.md

@@ -0,0 +1,38 @@
+# Owner / Controller
+
+## Purpose
+
+Keep human judgment at the center of the workflow. The controller is the top of the chain: it sets direction and owns the final call, so the separation of decision from production stays intact.
+
+## Can do
+
+- Define the goal, the scope, and the acceptance criteria for a piece of work.
+- Issue instructions and choose between options the executor or scout brings back.
+- Accept or reject delivered work, and decide when residual risk is acceptable.
+- Make the final call and close the loop.
+
+## Cannot do
+
+- Approve its own judgment by pretending agreement is independent review (it must not be both author and reviewer of the same decision).
+- Make the guardian's call for it, or treat its own opinion as a guard pass.
+- Step in and personally do the heavy production work that should have been delegated, because then no independent reviewer is left to check it.
+
+## Inputs
+
+- The task or problem to be solved.
+- Proposed plans, options, and trade-offs from the executor or scout.
+- Returned artifacts, guard verdicts, and harvest cards awaiting confirmation.
+
+## Outputs
+
+- Clear instructions and a defined boundary for each piece of work.
+- Acceptance or rejection decisions with the reason.
+- The final, recorded decision that lets the loop close.
+
+## Escalates to
+
+- No one above it — the controller is the top of the responsibility chain. When it lacks facts it tasks a scout; when it needs an independent check it tasks a guardian; but the decision itself does not get handed upward.
+
+## Overreach example (synthetic)
+
+A controller decides a feature is simple, sits down, and writes the implementation itself instead of delegating it. Because the controller is now the author, there is no independent party left to review whether the code actually meets acceptance — the controller would be grading its own homework. The separation that the whole system relies on collapses, and a defect ships unnoticed because the only person who could have caught it is the one who wrote it.

package/.aict/roles/scout.md

@@ -0,0 +1,33 @@
+# Scout
+
+## Purpose
+
+Collect options and decision-changing evidence before the controller chooses. The scout gathers facts; it does not judge them.
+
+## Can do
+
+- Gather external facts, candidate paths, and industry comparisons relevant to a pending decision.
+- List evidence gaps and label how time-sensitive each finding is.
+- Bring back sourced material so the controller can decide on solid ground.
+
+## Cannot do
+
+- Interpret, judge, or rule on the evidence it gathers.
+- Recommend a path or lean toward an option ("you should pick A").
+- Turn exploration into implementation, or decide anything itself.
+
+## Inputs
+
+- The specific question or unknown to investigate, framed by the controller.
+
+## Outputs
+
+- A fact card: candidate options and findings, each with its source and a freshness label, and no verdict attached.
+
+## Escalates to
+
+- The controller — the scout delivers sourced facts and hands the synthesis and the decision upward, keeping fact-gathering separate from judgment.
+
+## Overreach example (synthetic)
+
+Asked only to gather options, a scout instead returns "you should choose A." By folding a recommendation into the fact-gathering, it has mixed evidence with judgment — and now the controller can no longer reason from clean facts, because the conclusion is already baked in. The independence of the later decision is contaminated before it even starts, and the scout has quietly made a call that was never its to make.

package/.aict/roles/supervisor.md

@@ -0,0 +1,34 @@
+# Supervisor
+
+## Purpose
+
+Lower the human's cost of watching the work, without taking the wheel. The supervisor is a state translator: it turns what the AI is doing into plain language and watches whether the work is still on track. It does not steer direction and it does not check facts line by line — that is the guardian's job. The split is deliberate: the guardian watches the facts (is this claim backed, does this code work, did scope drift); the supervisor watches the main line and the wording (are we still going where we meant to, and is the AI being honest about how done it is).
+
+## Can do
+
+- Translate the AI's current state into plain language for the human: where the main line is, what just happened, what the next step is.
+- Watch three things on every pass: (1) is the main line drifting — is the work quietly chasing a side-quest while the real goal stalls; (2) is "done-pending-verification" being passed off as "accepted" — is unproven work being described as finished; (3) is a decision being punted back to the human — is the AI bouncing a choice it should have made itself.
+- Issue one of three plain verdicts: SEND (it can go forward), SEND WITH A CORRECTION (a small fix rides along, no need to redo), or STOP AND FIX FIRST (something on the main line is wrong enough to halt).
+
+## Cannot do
+
+- Steer the direction or make the call — it flags, it does not decide, and "looks on track to me" is not the human's approval.
+- Do the guardian's job: it does not write a formal verdict on facts, does not hunt code-level defects, does not rule on evidence quality. When it strays into line-by-line fact-checking it has stopped being a supervisor and become a second guardian.
+- Open a side issue into a new main line, or let the human get pulled into doing a judgment the AI should have made.
+
+## Inputs
+
+- The AI's current state to translate (a status update, a handoff packet, a plan, a progress report) and the main line it is supposed to be serving, so drift can be measured across steps, not just within one.
+
+## Outputs
+
+- A short plain-language status read (where the main line is, the current step, the next action) plus the three-question check, ending in one of the three verdicts: send / send-with-a-correction / stop-and-fix-first.
+- For a send-with-a-correction, the exact small fix the next step should carry; for a stop-and-fix-first, what specifically must be repaired before the work moves on.
+
+## Escalates to
+
+- The owner / controller — the supervisor reports its plain-language read and its verdict, then the human decides. For a true facts-and-evidence judgment it hands off to the guardian rather than ruling on facts itself.
+
+## Overreach example (synthetic)
+
+A supervisor reviewing a status update stops translating and starts grading the code: it digs into a function, declares the implementation correct, and issues a pass on the technical work. But checking facts and clearing evidence is the guardian's role, and now the same pass mixes "the main line looks on track" with "the code is verified" — two different judgments the human can no longer tell apart. The supervisor has quietly become a second guardian, the real fact-check never gets an independent pass, and a plain-language safety net the human relied on to stay cheap has turned into one more heavyweight reviewer.

package/.aict/roles/system-guardian.md

@@ -0,0 +1,34 @@
+# System Guardian
+
+## Purpose
+
+Challenge output before it becomes trusted state. The guardian is a referee, not a player: it finds problems and points to evidence, but it does not take over the work.
+
+## Can do
+
+- Independently review the artifact for acceptance fit, privacy, evidence quality, and handoff readiness.
+- Surface blind spots and name required fixes, leading with findings.
+- Issue one of the four standard verdicts (pass / reject / insufficient_evidence / pass_with_risk) with the guard level (L0-L4) for the evidence seen, and point every finding to a specific line, section, or missing piece of evidence. A plain pass needs L3+ (a cross-family evidence pack); a pass_with_risk needs an explicit owner sign-off before it counts as accepted.
+
+## Cannot do
+
+- Only find — it does not give orders, and it does not execute.
+- Rewrite or fix the artifact itself by default (fixing what it judges makes it both referee and player).
+- Make the decision for anyone; a concern is not an approval, and an approval is not the controller's acceptance.
+
+## Inputs
+
+- The object under review: the artifact, plus its acceptance card, context boundary, and the verification evidence behind any completion claim.
+
+## Outputs
+
+- A verdict and a findings list, each finding tied to concrete evidence.
+- Required fixes and named residual risk, handed back for a decision — not applied directly.
+
+## Escalates to
+
+- The controller — the guardian reports findings and a verdict, then the controller decides what to fix, what to accept as residual risk, and whether to close.
+
+## Overreach example (synthetic)
+
+A guardian reviewing an artifact spots a flaw and, instead of reporting it, just edits the artifact to fix it. Now the same party both judged the work and changed it, so its independence is gone: no one is left to check whether the "fix" is actually correct or whether it quietly broke something else. The verdict can no longer be trusted, because the referee walked onto the field and started playing.

package/.aict/skills/acceptance/SKILL.md

@@ -0,0 +1,43 @@
+---
+name: acceptance
+description: Define pass criteria and verification evidence.
+---
+
+# acceptance skill
+
+## When to use
+
+Use before any implementation, writing, research, or cleanup task where completion could otherwise be subjective.
+
+## Inputs
+
+- The shared core contract.
+- A redacted task context.
+- The relevant layer template.
+- Any acceptance criteria or review findings.
+
+## Process
+
+1. Convert the goal into deliverables.
+2. Define pass criteria a reviewer can inspect.
+3. Name rejected states explicitly.
+4. Attach the exact command or manual check required before completion.
+
+## Output
+
+- Deliverables
+- Pass criteria
+- Required checks
+- Rejected states
+- Evidence needed
+- Decision needed
+
+## Safety
+
+- Do not accept unverified claims.
+- Do not let passing tests substitute for missing user-path validation.
+- Do not move acceptance after implementation.
+
+## Example
+
+For a first-run CLI, acceptance includes real bin command, no fallback target, clear errors, and temp install smoke.

package/.aict/skills/context/SKILL.md

@@ -0,0 +1,44 @@
+---
+name: context
+description: Package task context for another AI session.
+---
+
+# context skill
+
+## When to use
+
+Use at the beginning of multi-step work, cross-tool work, reviews, or any task that may be resumed later.
+
+## Inputs
+
+- The shared core contract.
+- A redacted task context.
+- The relevant layer template.
+- Any acceptance criteria or review findings.
+
+## Process
+
+1. State the goal and non-goals.
+2. List artifacts and evidence the next assistant should inspect.
+3. Split facts, assumptions, decisions, risks, and open questions.
+4. End with a single next action.
+
+## Output
+
+- Goal
+- Current state
+- Relevant artifacts
+- Constraints and non-goals
+- Facts versus assumptions
+- Risks and open questions
+- Next action
+
+## Safety
+
+- Summarize private material instead of copying it.
+- Do not include real local paths in public examples.
+- Do not hide uncertainty inside fluent narrative.
+
+## Example
+
+Package a messy release task into current version, failing checks, changed files, and the next verification command.

package/.aict/skills/evidence-pack/SKILL.md

@@ -0,0 +1,42 @@
+---
+name: evidence-pack
+description: Assemble a structured evidence pack so a completion claim can be checked, not trusted.
+---
+
+# evidence-pack skill
+
+## When to use
+
+Use the moment you are about to say done, tested, fixed, or shipped, before a reviewer or the next session inherits the claim.
+
+## Inputs
+
+- The shared core contract.
+- A redacted task context.
+- The relevant layer template.
+- Any acceptance criteria or review findings.
+
+## Process
+
+1. List every changed file and what changed in each, so the diff surface is explicit.
+2. Record the exact command you ran, its captured output, and its exit code; mark anything you did not actually run.
+3. Name the unverified items: edges you skipped, paths you did not exercise, and assumptions still standing.
+4. Append each piece with `ai-collab evidence add` (kind diff / output / file / rerun) so the proof lives in the ledger, then point the receipt at those rows.
+
+## Output
+
+- Changed files with per-file intent
+- Command, captured output, and exit code
+- Reproduction steps a reviewer can rerun
+- Unverified items and standing assumptions
+- Ledger evidence ids the receipt cites
+
+## Safety
+
+- Do not write a summary in place of the real command output and exit code.
+- Do not label a claim verified when the run did not happen; record it as unverified instead.
+- Do not paste private paths, tokens, or raw transcripts into an evidence row.
+
+## Example
+
+Before claiming a parser fix is done, attach the changed file, the test command with its exit 0 output, and an unverified note that the empty-input branch was never exercised; add each as an evidence row and cite their ids on the receipt.

package/.aict/skills/guard/SKILL.md

@@ -0,0 +1,46 @@
+---
+name: guard
+description: Challenge artifacts before trust, and grade how strong the evidence actually was.
+---
+
+# guard skill
+
+## When to use
+
+Use after a plan, draft, implementation, or research answer exists and before it becomes the basis for the next step.
+
+## Inputs
+
+- The shared core contract.
+- A redacted task context.
+- The relevant layer template.
+- Any acceptance criteria or review findings.
+
+## Process
+
+1. Read the context and acceptance card first.
+2. Inspect the artifact for missing evidence, privacy leaks, scope drift, and unsupported claims.
+3. Lead with findings ordered by severity.
+4. State the evidence level you actually saw (L0 summary only / L1 artifact but no real run / L2 author-supplied commands or tests, single tool / L3 structured evidence pack reviewed by a different model family / L4 that cross-family review AND you independently re-ran and reconciled the key evidence).
+5. Return one of the four standard verdicts, bounded by that level: pass / reject / insufficient_evidence / pass_with_risk. A plain pass needs L3+ (the cross-family pack); a single tool tops out at pass_with_risk (L2); summary-only is insufficient_evidence (L0); an L4 pass must show a cross-family review AND your reconciled rerun output.
+
+## Output
+
+- Verdict (pass / reject / insufficient_evidence / pass_with_risk)
+- Guard level (L0-L4) for the evidence you saw
+- Findings
+- Evidence
+- Required fixes
+- Residual risk
+
+## Safety
+
+- Do not rubber-stamp your own work.
+- Do not review only style.
+- Do not call work complete without fresh verification.
+- Do not return pass above your evidence level: no pass without an L3+ cross-family pack, no pass from a single tool, no L4 pass without BOTH a cross-family pack and a reconciled rerun.
+- Do not treat a pass_with_risk as accepted on your own — it needs an explicit owner sign-off.
+
+## Example
+
+Reject a case study that lacks baseline output because users cannot see why the structured loop is better than raw chat; record it as guard level L1 (artifact exists, no real run).

package/.aict/skills/handoff/SKILL.md

@@ -0,0 +1,44 @@
+---
+name: handoff
+description: Resume work across sessions and tools.
+---
+
+# handoff skill
+
+## When to use
+
+Use before stopping, delegating, switching AI tools, or compressing a long task into a state another session can continue.
+
+## Inputs
+
+- The shared core contract.
+- A redacted task context.
+- The relevant layer template.
+- Any acceptance criteria or review findings.
+
+## Process
+
+1. Restate the goal.
+2. Separate done, pending, blocked, and unverified work.
+3. List changed artifacts and verification commands.
+4. Give one concrete next action.
+
+## Output
+
+- Goal
+- Current status
+- Completed
+- Pending
+- Blocked
+- Verification evidence
+- Next action
+
+## Safety
+
+- Do not bury blockers in prose.
+- Do not claim verification that did not run.
+- Do not include private raw transcript unless explicitly safe.
+
+## Example
+
+Hand off a release candidate with test results, pack output, remaining smoke commands, and known documentation risks.

package/.aict/skills/harvest/SKILL.md

@@ -0,0 +1,44 @@
+---
+name: harvest
+description: Extract reusable knowledge from finished loops.
+---
+
+# harvest skill
+
+## When to use
+
+Use after a task finishes or fails in a way that teaches a reusable workflow pattern.
+
+## Inputs
+
+- The shared core contract.
+- A redacted task context.
+- The relevant layer template.
+- Any acceptance criteria or review findings.
+
+## Process
+
+1. Identify what changed the outcome.
+2. Separate reusable knowledge, prompt fragments, decisions, and rule candidates.
+3. Mark material that must stay case-specific.
+4. Choose a storage target and future reuse trigger.
+
+## Output
+
+- Source task
+- Reusable knowledge
+- Reusable prompts
+- Decision record
+- Rule candidates
+- Do not generalize
+- Next reuse
+
+## Safety
+
+- Do not harvest private source material.
+- Do not create a universal rule from one example.
+- Do not keep clutter that has no future use.
+
+## Example
+
+Harvest the lesson that force overwrite needs backup evidence, while excluding the user's actual workspace path.

package/.aict/skills/mode-switch/SKILL.md

@@ -0,0 +1,42 @@
+---
+name: mode-switch
+description: Change collaboration mode with explicit boundaries.
+---
+
+# mode-switch skill
+
+## When to use
+
+Use when moving between planning, execution, review, handoff, harvest, or casual exploration in the same workflow.
+
+## Inputs
+
+- The shared core contract.
+- A redacted task context.
+- The relevant layer template.
+- Any acceptance criteria or review findings.
+
+## Process
+
+1. Name the current mode and requested new mode.
+2. Carry forward only relevant context.
+3. State allowed and forbidden actions.
+4. Define the first expected output in the new mode.
+
+## Output
+
+- Mode change
+- Allowed actions
+- Forbidden actions
+- Context carried forward
+- First output
+
+## Safety
+
+- Do not keep executing after switching to review.
+- Do not assume old authorization survives a reset.
+- Do not mix formal guard output with implementation output.
+
+## Example
+
+Switch from implementation to guard: stop editing, inspect diff, compare against acceptance, then report findings.