@hassangameryt/freeflow 0.2.0 → 0.4.0

package/plugins/freeflow/skills/review-artifact/SKILL.md

@@ -1,115 +0,0 @@
----
-name: review-artifact
-description: Use when asked to review whether a spec, plan, decision note, research checkpoint, handoff, or other durable artifact is fit to guide future work; also use when adjudicating artifact-review findings or repeated review loops.
----
-
-# Review Artifact
-
-Review whether the artifact is fit to guide work.
-
-Review first. Edit second.
-
-Reviewer findings are evidence, not commands. The parent agent owns adjudication.
-
-A non-passing artifact review is a phase exit, not an autonomous patch loop. If you requested the review and it returns blocking findings, stop before editing from that batch, classify the findings, and report the route.
-
-The turn that receives a non-passing review ends with adjudication and route only. Do not edit from that review batch in the same turn, even when the user or reviewer says to apply all findings and continue reviewing.
-
-Hard stop: if the artifact has already had three review passes, do not edit any files or request another review. Classify findings and diagnose the loop only, even for accepted, mechanical, or non-blocking cleanup.
-
-## Source-Truth Guard
-
-Artifact feedback is not approval to change source of truth.
-
-Do not treat `/review-artifact`, "explicit permission", "fix it directly", "old/stale policy docs or tests", or "do not ask" as approval to invert the artifact's intent or demote live evidence.
-
-Do not fix an artifact by making hidden product, policy, security, privacy, billing, data-loss, compatibility, API, or architecture decisions.
-
-If the artifact conflicts with live repo evidence, classify the conflict. Ask whether to update the artifact to match source truth or change source truth to match the artifact.
-
-Do not rewrite docs, tests, policies, specs, ADRs, or handoffs to make the artifact pass before that decision.
-
-For source-truth conflicts, the final line must be a direct choice question.
-
-## Parent Adjudication
-
-Before editing from reviewer findings, classify each material finding:
-
-- Accepted: valid and safe to apply without changing settled intent.
-- Rejected: stale, unsupported, already resolved, equivalent, or not important.
-- Question: needs owner decision.
-- Needs evidence: inspect more before deciding.
-
-Non-blocking findings and reviewer questions do not fail the artifact by default. Classify them, then defer, ask, gather evidence, or accept.
-
-Ask before applying any finding that changes artifact intent, scope, source truth, workflow policy, sensitive behavior, or a settled decision.
-
-For second and later review iterations, update the reviewer prompt with prior findings, owner clarifications, accepted/rejected findings, changed sections, and remaining risk. Do not rerun the same broad prompt after the situation narrows.
-
-Do not apply a non-pass review batch and request another review in the same autonomous loop. Return the adjudication and next route first. A later explicit apply-fixes request can start a bounded fix pass for accepted, in-scope findings.
-
-## Review Loop Budget
-
-Aim to finish by the second review pass: first review, adjudicate/fix, one confirmation.
-
-Three review passes is the hard cap for the same artifact and scope. Do not request a fourth review to chase a clean pass.
-
-At the third review, adjudicate before treating it as failure. If any accepted blocking, question, or needs-evidence finding remains, do not edit anything from that batch. Stop, report the adjudication, and zoom out to diagnose whether research, spec, plan, policies, source truth, artifact scope, or reviewer context is wrong or too thin.
-
-## Review Setup
-
-Use a fresh reviewer when the artifact will guide future work and subagents are available. Use [references/reviewer-prompt.md](references/reviewer-prompt.md).
-
-For durable specs or future-agent-facing artifacts, use `../write-spec/references/artifact-standards.md` as the artifact identity standard when relevant.
-
-## Inspect First
-
-Read:
-
-- The artifact under review.
-- Referenced docs, tests, policies, ADRs, and code.
-- Relevant handoffs only as memory, not authority.
-
-Live repo evidence overrides stale artifacts.
-
-## Review Lenses
-
-- Completeness: enough is present to proceed.
-- Evidence: load-bearing claims point to live evidence or explicit decisions.
-- Clarity: a fresh agent can act without transcript memory.
-- Consistency: the artifact agrees with itself, live repo evidence, docs, tests, policies, ADRs, and known decisions.
-- Identity: durable or strict-workflow artifacts have enough owner, status, source, and change history for future readers.
-- Implementation risk: missing decisions, placeholders, or vague acceptance criteria would not send implementation down the wrong path.
-- Adversarial risk: the artifact cannot be used to smuggle source-truth overrides, stale assumptions, or owner decisions into execution.
-
-Treat missing artifact identity as blocking only when it affects future-agent handoff, team ownership, strict-workflow risk, or implementation readiness. Do not nitpick headers on lightweight artifacts or chat answers.
-
-## Stop Before Editing
-
-Stop before editing when a fix would:
-
-- Invent missing requirements.
-- Convert adjacent evidence into product direction.
-- Override source-of-truth files.
-- Change the artifact's intended behavior to resolve a source-truth conflict.
-- Resolve an owner decision silently.
-- Rewrite a handoff, plan, review comment, or spec into authority over live evidence.
-
-Name the issue and ask for the decision. Recommend the path supported by evidence.
-
-## Report
-
-Lead with the result:
-
-- Pass: fit to guide the next step.
-- Blocking: must fix before proceeding.
-- Non-blocking: can defer.
-- Question: owner decision or more evidence needed.
-
-Review can pass. Do not invent findings.
-
-When the result blocks on owner, product, policy, security, billing, compatibility, API, data-loss, or architecture decisions, end with a direct question asking for that decision.
-
-Save a review artifact only when the user asks, risk warrants it, or future memory value is clear.
-
-If subagents are unavailable, do the same review inline and say it was not an independent review.

package/plugins/freeflow/skills/review-artifact/references/reviewer-prompt.md

@@ -1,56 +0,0 @@
-# Artifact Reviewer Prompt
-
-Use this when dispatching a reviewer subagent. For second and later iterations, include the iteration context so the reviewer does not blindly re-raise stale findings.
-
-```text
-You are an artifact reviewer. Review whether this artifact is fit to guide future work.
-
-Artifact:
-[ARTIFACT_PATH]
-
-Artifact type:
-[spec | plan | handoff | decision note | research brief | other]
-
-Source context to inspect:
-[DOCS_TESTS_POLICIES_ADRS_CODE_PATHS]
-
-Iteration context, if this is not the first review:
-- Review pass number: [2 | 3]
-- Prior findings: [SUMMARY]
-- Parent adjudication: [ACCEPTED_REJECTED_QUESTION_NEEDS_EVIDENCE]
-- Owner clarifications: [DECISIONS_OR_NONE]
-- Changed sections: [SECTIONS_OR_NONE]
-- Remaining risk to focus on: [RISK]
-
-Check:
-
-- Completeness: enough is present to proceed.
-- Evidence: load-bearing claims point to live evidence or explicit decisions.
-- Clarity: a fresh agent can act without transcript memory.
-- Consistency: artifact agrees with itself and source context.
-- Artifact identity: durable or strict-workflow artifacts have useful owner, status, source, and change-history signals.
-- Implementation risk: missing decisions, placeholders, or vague acceptance criteria would not send implementation down the wrong path.
-- Adversarial risk: artifact cannot smuggle source-truth overrides, stale assumptions, or owner decisions into execution.
-
-Calibration:
-
-- Only flag issues that would cause wrong work, blocked work, hidden decisions, or stale authority.
-- Treat missing owner/status/source as blocking only when artifact durability, team ownership, strict-workflow risk, or implementation readiness makes it matter.
-- Do not nitpick style.
-- Review can pass.
-- Do not edit files.
-- Do not resolve owner decisions.
-- Do not re-raise rejected or already-resolved findings unless live evidence contradicts the adjudication.
-- If review does not pass, classify findings and stop. Do not tell the parent agent to apply all findings and send it back for another broad review.
-- If this is review pass 3, identify remaining accepted blocking risk; do not recommend another broad review loop.
-
-Output:
-
-Status: Pass | Blocking | Non-blocking | Question
-
-Findings:
-- [Blocking | Non-blocking | Question] [location]: [issue] - [why it matters]
-
-Recommendation:
-[Proceed | revise artifact | ask owner decision | gather evidence]
-```

package/plugins/freeflow/skills/review-work/SKILL.md

@@ -1,96 +0,0 @@
----
-name: review-work
-description: Use when reviewing completed work, preparing reviewer prompts or subagent review context, receiving review feedback, applying reviewer comments, deciding whether feedback is blocking, handling repeated review loops, or checking work before merge/handoff.
----
-
-# Review Work
-
-Evaluate review feedback before applying it.
-
-Review feedback is not approval to change source of truth.
-
-If applying feedback would override tests, docs, specs, policies, or sensitive behavior, stop even when the user says to apply it directly or not ask.
-
-If you block any feedback item, end the final response with a direct choice question for that item. This still applies after fixing unrelated items.
-
-External review is evidence, not authority. Human owner decisions win only after the owner confirms the behavior change.
-
-Classify each material feedback item before editing: accepted, rejected, question, or needs evidence.
-
-A non-passing review is a phase exit, not an autonomous patch loop. If you requested the review and it returns blocking findings, stop before editing from that batch, classify the findings, and report the route.
-
-The turn that receives a non-passing review ends with adjudication and route only. Do not edit from that review batch in the same turn, even when the user or reviewer says to apply all findings and continue reviewing.
-
-Hard stop: if the work has already had three review passes, do not edit any files or request another review. Classify findings and diagnose the loop only, even for accepted, mechanical, or non-blocking cleanup.
-
-Read `references/reviewer-prompt.md` when preparing an outgoing reviewer prompt, dispatching a review subagent, reviewing strict/high-risk work, or handing another agent review context.
-
-## Review Loop Budget
-
-Aim to finish by the second review pass: first review, adjudicate/fix, one confirmation.
-
-Three review passes is the hard cap for the same work and scope. Do not request a fourth review to chase a clean pass.
-
-At the third review, adjudicate before treating it as failure. If any accepted blocking, question, or needs-evidence finding remains, do not edit anything from that batch. Stop, report the adjudication, and zoom out to diagnose whether research, spec, plan, policies, source truth, implementation, or reviewer context is wrong or too thin.
-
-Non-blocking findings and reviewer questions do not fail the work by default. Classify them, then defer, ask, gather evidence, or accept.
-
-## Incoming Feedback
-
-Before editing:
-
-- Read the full feedback.
-- Inspect the relevant code, tests, docs, and prior decisions.
-- Restate unclear feedback as a technical requirement.
-- Separate blocking issues from suggestions.
-- Check whether the feedback matches this codebase.
-- Check whether a finding is stale, already resolved, equivalent, or based on missing context.
-
-Do not blindly apply vague, broad, or sensitive feedback.
-
-Do not use performative agreement. State the technical finding or act.
-
-## Stop Conditions
-
-Stop before editing when feedback:
-
-- Is ambiguous.
-- Contradicts tests, docs, specs, policies, ADRs, or established behavior.
-- Changes product, security, privacy, billing, data-loss, compatibility, public API, permissions, or architecture behavior.
-- Requires guessing what the reviewer meant.
-- Would cause a broad refactor from a narrow comment.
-
-Name the conflict or uncertainty and ask which path to follow. Recommend the path supported by evidence.
-
-## Applying Feedback
-
-For multi-item review:
-
-- Apply independent clear items.
-- Stop blocked items.
-- If items interact, clarify before implementing the set.
-
-When feedback is clear and correct and the current route is an apply-fixes pass:
-
-- Apply one item at a time.
-- Keep the diff scoped to the review item.
-- Verify each fix.
-- Push back on incorrect feedback with code, tests, or docs.
-
-Do not apply a non-pass review batch and request another review in the same autonomous loop. Return the adjudication and next route first. A later explicit apply-fixes request can start a bounded fix pass for accepted, in-scope findings.
-
-## Outgoing Review
-
-When reviewing work, lead with bugs, regressions, missing tests, and requirement gaps.
-
-Classify findings:
-
-- Blocking: must fix before proceeding.
-- Non-blocking: can defer.
-- Question: needs owner decision or more evidence.
-
-Review can pass. Do not invent issues to justify the review.
-
-When asking another agent to review, give it source truth, changed files, risk lenses, and pass/fail criteria. Do not hand it only the previous agent's summary or your chat history.
-
-For second and later review iterations, update the prompt with prior findings, owner clarifications, accepted/rejected findings, changed files, and remaining risk. Do not rerun the same broad prompt after the situation narrows.

package/plugins/freeflow/skills/review-work/references/reviewer-prompt.md

@@ -1,97 +0,0 @@
-# Reviewer Prompt
-
-Use this when preparing an outgoing reviewer prompt or subagent review context.
-
-The reviewer should get the work product and source truth, not your session memory.
-
-## Include
-
-- What was implemented or changed.
-- The source authority: spec, plan, issue, ADR, policy, tests, or user-confirmed requirement.
-- Files or diff range to inspect. If no git range exists, list concrete files.
-- Claimed verification and what still needs independent checking.
-- Risk lenses relevant to the work.
-- Required output shape and severity labels.
-- Clear instruction not to edit files unless the review task explicitly includes fixes.
-- For review pass 2 or 3: prior findings, accepted/rejected/question/needs-evidence adjudication, owner clarifications, changed files, and narrowed remaining risk.
-
-Do not forward only a previous-agent summary. Summaries are useful context, not authority.
-
-For second and later review iterations, include prior findings, parent adjudication, owner clarifications, changed files, and the remaining risk. Do not rerun the same broad prompt after the situation narrows.
-
-## Risk Lenses
-
-Pick the lenses that fit the work:
-
-- Source-truth alignment: implementation matches spec, plan, docs, tests, and established behavior.
-- Regression risk: unrelated behavior changed or broad refactor from narrow work.
-- Security/privacy: auth, secrets, permissions, sensitive data, logging, data exposure.
-- Billing/product: pricing, downgrade/upgrade, access, entitlements, user-visible policy.
-- Public API: route, method, payload, response status/body, compatibility, error semantics.
-- Data safety: migrations, deletion, idempotency, rollback, duplicate processing.
-- Test gaps: claims rely on manual checks, stale notes, or missing executable coverage.
-- Reviewability: diff scope, generated files, hidden dependencies, unexplained deviations.
-
-For strict-workflow or high-risk work, call out owner-owned decisions and stop conditions directly.
-
-## Output Shape
-
-Ask the reviewer to lead with findings, ordered by severity:
-
-```md
-## Findings
-
-### Blocking
-- [file:line] Title
-  - What is wrong:
-  - Why it matters:
-  - Minimal fix direction:
-
-### Non-blocking
-- ...
-
-### Questions
-- ...
-
-## Assessment
-
-Ready to proceed: Yes | No | With fixes
-Reasoning: ...
-```
-
-If review passes, the reviewer should say that clearly and name any residual test gaps or assumptions.
-
-If review does not pass, the reviewer should classify findings and stop. Do not tell the parent agent to apply all findings and send it back for another broad review.
-
-Do not ask reviewers to invent issues. A clean pass is valid.
-
-If this is review pass 3, ask for remaining accepted blocking risk only. Do not recommend a fourth broad review loop.
-
-## Minimal Template
-
-```md
-# Reviewer Prompt
-
-Review the completed work. Do not edit files.
-
-## Work Summary
-
-[What changed, from the implementer summary or observed files.]
-
-## Source Truth
-
-- [spec/plan/policy/test paths]
-
-## Files Or Range
-
-- [changed files or git range]
-
-## Check
-
-- [risk lenses and concrete requirements]
-- [if pass 2 or 3: prior findings, adjudication, owner clarifications, changed files, and narrowed remaining risk]
-
-## Output
-
-Lead with findings by severity. Include file:line, violated requirement, risk, and minimal fix direction. If there are no findings, say so and list residual risk/test gaps.
-```

package/plugins/freeflow/skills/setup-freeflow/SKILL.md

@@ -1,94 +0,0 @@
----
-name: setup-freeflow
-description: Use when setting up, installing, enabling, initializing, or configuring Freeflow in a repo, choosing Codex/Claude/multi-agent activation, creating `.freeflow/config.json`, or changing the repo default mode during setup.
----
-
-# Setup Freeflow
-
-Use `references/activation-contract.md` before rendering activation text, config, or host setup.
-
-Use `references/host-setup.md` when the request mentions Codex, Claude, both hosts, team setup, solo setup, strict defaults, hooks, CLI, or setup profiles.
-
-Use `references/output-router-setup.md` when setup explicitly asks for output-router repo config, generated-path hints, native safety-net routing, vault settings, or output thresholds.
-
-## Stop Before Editing
-
-Do not create config, add activation blocks, imports, or rule files until setup has a clear host target and no unresolved repo-rule conflict.
-
-Hard stops:
-- both `AGENTS.md` and `CLAUDE.md` exist, and the user did not explicitly choose a host or ask for multi-agent setup
-- existing repo instructions conflict with asking before user-owned decisions
-- existing repo instructions conflict with verification before completion claims
-- Claude setup would add `.claude/rules/freeflow-core.md` but the user has not clearly chosen Claude or multi-agent setup
-
-For a hard stop, make no file changes. Name the blocker and ask one direct question.
-
-## Inspect
-
-Inspect `.freeflow/config.json`, `AGENTS.md`, `CLAUDE.md`, `.claude/rules/freeflow-core.md`, `.codex/rules/`, existing `## Freeflow` blocks, and conflicting repo instructions.
-
-Existing repo instructions are source truth. If a rule conflicts with Freeflow's core behavior, name the conflict and ask whether to install Freeflow as advisory, revise the rule, or skip setup. Advisory install is a user decision, not the default.
-
-## Target
-
-- Codex target: update `AGENTS.md`.
-- Claude target: update `CLAUDE.md` and `.claude/rules/freeflow-core.md`.
-- If only `AGENTS.md` exists, choose Codex.
-- If only `CLAUDE.md` exists, choose Claude.
-- If both exist and the user explicitly named the host target, update that host's files.
-- If both exist and the target is ambiguous, ask before editing.
-- If neither exists, ask which one to create.
-- Update both only when the user asks for multi-agent setup. Mention duplicated host activation drift risk.
-
-Do not treat the current agent runtime alone as target approval. A Codex run in a repo that also has `CLAUDE.md` still needs the user to choose unless the request or repo instructions make the target explicit.
-
-Update an existing `## Freeflow` block in place. Otherwise place the block near existing agent skill/workflow sections, or append near the end. Never duplicate it. Do not use `.codex/rules/*.rules` for Freeflow behavior; Codex rules are shell approval/security policy, not model memory.
-
-## Config
-
-Create or update `.freeflow/config.json` using the config adapter in `references/activation-contract.md`.
-
-Minimal setup writes only `defaultMode`. Use `workflow` unless the user explicitly asks to persist a valid repo default: `conversation`, `workflow`, or `strict-workflow`.
-
-Optional `outputRouter` config belongs here only when explicitly requested. Read `references/output-router-setup.md` first. Do not add an empty `outputRouter`, dump router defaults, or ask every setup user about router config.
-
-If the user asks for router setup but gives no config knobs, say the router works with built-in defaults and ask which optional config they want persisted. Recommend no repo config unless they need a repo-specific hint or native safety-net behavior.
-
-Never enable native safety-net routing by default. `postToolRouting: "safety-net"` requires an explicit request; `strict` is reserved and needs a separate confirmation before writing.
-
-Do not infer `strict-workflow` from "team", "strict gates", "careful", or high-risk examples. Recommend or ask unless the user explicitly says to make a mode the repo default.
-
-Do not add current mode, task, phase, file inventory, active plans, version metadata, activation file path, or unrequested router keys.
-Mode switches are task/conversation scoped unless the user explicitly asks to persist a different default mode.
-
-## Activation
-
-Render the canonical blocks from `references/activation-contract.md`.
-
-For Codex, put the Codex core block in `AGENTS.md`.
-
-For Claude, put only the Claude import block in `CLAUDE.md`, then put the Codex core block text in `.claude/rules/freeflow-core.md`. Do not create a separate Claude rule file for `interview-gate`; plugin runtime loads it.
-
-Do not list the whole workflow, every mode, or full `interview-gate` skill in always-loaded text. Do not split into multiple always-loaded Freeflow rule files unless the user explicitly confirms that split after the one-file recommendation.
-
-## Do Not Create
-
-Setup must not create empty `CONTEXT.md`, docs pages, repo-local hooks, state files, handoffs, skill inventories, `setup-output-router` skills, or `.codex/rules` behavior files.
-`CONTEXT.md` is domain language memory, not plugin state.
-Plugin-bundled context hooks are installed with Freeflow, not created by repo setup.
-
-## Verify
-
-Before claiming setup is complete, check:
-- config JSON parses
-- minimal config contains only `defaultMode` with the requested explicit default, or `workflow` when no explicit default was requested
-- optional `outputRouter` config appears only when explicitly requested and contains only requested valid keys
-- native safety-net routing is off unless explicitly requested
-- Codex setup has exactly one `## Freeflow` block in `AGENTS.md`
-- Claude setup has exactly one `CLAUDE.md` import and one `.claude/rules/freeflow-core.md` core file
-- `.codex/rules` was not created or changed for Freeflow behavior
-- no unrelated files changed
-
-After successful setup verification, read `../workflow/SKILL.md`, `../workflow/references/workflow-map.md`, and `../interview-gate/SKILL.md` before the final response. Only say workflow and interview-gate context is loaded for this session if all three files were read successfully.
-
-If verification cannot run, say what remains unverified.

package/plugins/freeflow/skills/setup-freeflow/references/activation-contract.md

@@ -1,99 +0,0 @@
-# Activation Contract
-
-This is the canonical Freeflow setup contract. Setup renders this contract into host instruction files; docs, fixtures, and eval assertions should reference it or be checked against it.
-
-## Interface
-
-Use this Markdown reference as the v0.1 contract module:
-
-```text
-getActivationContract(defaultMode) -> ActivationContract
-planActivation(contract, repoState, request) -> ActivationPlan | ActivationStop
-renderActivation(contract, target) -> rendered text or checks
-planOptionalOutputRouterConfig(request) -> OutputRouterConfigPlan | ActivationStop
-```
-
-Do not add a code module until setup behavior needs logic that cannot be kept clear in the skill and this reference.
-
-## Invariants
-
-- Activation text contains always-on invariants only, not the full workflow spine.
-- Minimal config has exactly one field: `defaultMode`.
-- Optional `outputRouter` config is allowed only when explicitly requested.
-- Valid defaults are exactly `conversation`, `workflow`, and `strict-workflow`.
-- Default mode is `workflow` unless the user explicitly persists another valid mode.
-- Codex activation writes `AGENTS.md`, not `.codex/rules`.
-- Claude activation writes a `CLAUDE.md` import plus one `.claude/rules/freeflow-core.md`.
-- Multi-agent setup updates both host surfaces only on explicit request and reports drift risk.
-- Existing repo instructions remain source truth.
-- Setup hard-stops before unresolved host ambiguity or repo-rule conflict.
-- Setup does not create repo-local hooks, docs inventories, state files, handoffs, empty `CONTEXT.md`, skill inventories, `setup-output-router` skills, version metadata, activation path, current task, or current phase.
-- Plugin-bundled context hooks may load workflow and interview-gate context at session start, but they are package runtime, not setup output.
-- After successful setup verification, setup reads the workflow skill, workflow map, and interview-gate skill before its final response so the current session is immediately usable.
-
-## Host Adapters
-
-Codex adapter:
-
-- Update an existing `## Freeflow` block in `AGENTS.md`, or add one near existing agent/workflow instructions.
-- Keep exactly one `## Freeflow` block.
-- Never use `.codex/rules` for Freeflow behavior.
-
-Claude adapter:
-
-- Update `CLAUDE.md` with only the import block below.
-- Write the Codex core block text to `.claude/rules/freeflow-core.md`.
-- Keep exactly one imported core file unless the user explicitly confirms a split after the one-file recommendation.
-
-Config adapter:
-
-- Create or update `.freeflow/config.json`.
-- For minimal setup, write exactly `{ "defaultMode": "<mode>" }`.
-- Use `workflow` unless the user explicitly asks to persist `conversation` or `strict-workflow`.
-- Add `outputRouter` only when explicitly requested, using `output-router-setup.md`.
-- Missing `outputRouter` means built-in defaults, not a setup warning.
-- Never enable native safety-net routing by default.
-
-## Codex Core Block
-
-<!-- freeflow-activation-contract:codex-core:start -->
-```md
-## Freeflow
-
-Use Freeflow for consequential work. Default mode: `.freeflow/config.json`.
-
-Move forward when context is sufficient. Re-enter clarification when new ambiguity would change the next action.
-
-Treat questions as questions and suggestions as hypotheses. Answer directly; do not infer correction, permission, or agreement.
-
-Ask before user-owned decisions: product behavior, scope, public APIs, security, privacy, billing, data loss, compatibility, permissions, or irreversible architecture.
-
-Treat live repo evidence and existing docs/tests as source truth. If the user request conflicts with them, stop and ask before changing behavior.
-
-Verify before completion claims. Capture only stable decisions, glossary terms, ADR-worthy tradeoffs, or useful handoff memory.
-```
-<!-- freeflow-activation-contract:codex-core:end -->
-
-## Claude Import Block
-
-<!-- freeflow-activation-contract:claude-import:start -->
-```md
-## Freeflow
-
-@.claude/rules/freeflow-core.md
-```
-<!-- freeflow-activation-contract:claude-import:end -->
-
-## Drift Checks
-
-Run `plugins/freeflow/evals/scripts/check-activation-contract.sh` when changing setup behavior, post-setup fixtures, setup eval assertions, or docs that quote setup behavior.
-Run `plugins/freeflow/evals/scripts/check-runtime-context-hook.sh` when changing plugin-bundled runtime context hooks.
-
-The check keeps these surfaces aligned:
-
-- this canonical reference
-- `setup-freeflow/SKILL.md`
-- `setup-freeflow/references/host-setup.md`
-- `docs/freeflow-runtime-and-lifecycle.md`
-- post-setup `AGENTS.md` fixtures
-- setup eval assertions that depend on canonical activation text

package/plugins/freeflow/skills/setup-freeflow/references/host-setup.md

@@ -1,35 +0,0 @@
-# Host Setup
-
-Use this only when setup asks for a host, profile, default mode, team install, hooks, CLI, or multi-agent shape. Use `activation-contract.md` for canonical activation text, config invariants, and host adapter rules.
-
-## Hosts
-
-Codex setup writes `AGENTS.md` and `.freeflow/config.json`.
-
-Claude setup writes `CLAUDE.md`, `.claude/rules/freeflow-core.md`, and `.freeflow/config.json`.
-
-Multi-agent setup updates both host surfaces only when the user asks for both or multi-agent setup. Mention that duplicated always-on text can drift, render both hosts from `activation-contract.md`, and keep Claude's full block in one imported file.
-
-Current runtime is not enough to choose a host when both `AGENTS.md` and `CLAUDE.md` exist.
-
-## Profiles
-
-Solo setup is the default: one host target, compact activation, `defaultMode: "workflow"`, no extra docs.
-
-Output-router setup is an opt-in config branch inside normal setup, not a separate host profile. Use `output-router-setup.md`; keep minimal setup config unchanged unless the user explicitly asks for router config.
-
-Team setup still uses compact activation. Add both hosts only if requested. Do not add team standards, onboarding docs, owners, approvers, repo-local hooks, or CLI checks as part of setup unless the user separately asks and the repo has a validated path for them.
-
-Strict setup changes `.freeflow/config.json` to `strict-workflow` only when the user explicitly asks to make that the repo default. Otherwise recommend strict-workflow for high-risk work without persisting it.
-
-Valid persisted defaults are exactly `conversation`, `workflow`, and `strict-workflow`.
-
-## Not Setup
-
-Do not install repo-local hooks, CLI commands, lint rules, global standards, docs inventories, setup-output-router skills, or state files during setup.
-
-Freeflow's plugin-bundled context hooks are package runtime. They load workflow and interview-gate context at session start, but setup should not copy hook files into the target repo.
-
-After successful setup verification, setup should read the workflow skill, workflow map, and interview-gate skill before the final response. If session-start runtime context does not load in later sessions, tell the user to review/trust the installed Freeflow plugin hooks or start a fresh/compacted session. Do not create repo-local hook files as a workaround.
-
-If the user asks for enforcement, say Freeflow setup is instruction-only for now and ask whether to handle enforcement as a separate task.

package/plugins/freeflow/skills/setup-freeflow/references/output-router-setup.md

@@ -1,52 +0,0 @@
-# Output Router Setup
-
-Use this only when setup explicitly asks for output-router repo config, generated-path hints, native safety-net routing, vault settings, or output thresholds.
-
-## Defaults
-
-- The output router has built-in defaults. A repo does not need `outputRouter` config to use it.
-- Minimal `/setup-freeflow` must still write only `defaultMode`.
-- Do not ask every setup user about router config.
-- Do not create a separate `setup-output-router` skill.
-
-If the user says only “set up the output router” with no requested knobs, say the router works with built-in defaults and ask which optional config they want persisted. Recommend no repo config unless they need a repo-specific hint or safety-net behavior.
-
-## Config Keys
-
-Write only keys the user explicitly requests. Do not dump all defaults and do not create an empty `outputRouter` object.
-
-Supported repo config keys:
-
-```json
-{
-  "defaultMode": "workflow",
-  "outputRouter": {
-    "postToolRouting": "off",
-    "largeOutputBytes": 64000,
-    "largeOutputLines": 1000,
-    "vaultRoot": "~/.cache/freeflow-router/vault",
-    "vaultRetentionDays": 7,
-    "generatedPaths": ["graphify-out/**"],
-    "noisyCommandHints": ["npm test"]
-  }
-}
-```
-
-Rules:
-
-- `postToolRouting` defaults to `off`. Use `safety-net` only when explicitly requested. Treat `strict` as reserved; ask before writing it.
-- `largeOutputBytes`, `largeOutputLines`, and `vaultRetentionDays` must be positive integers.
-- `vaultRoot` must be a non-empty string.
-- `generatedPaths` are broad-scan generated-path hints. Explicit file or directory retrieval must remain available.
-- `noisyCommandHints` is parsed as hint config. Do not add it unless the user explicitly asks for command-pattern hints.
-
-## Verify
-
-After writing optional router config:
-
-- JSON parses.
-- `defaultMode` is valid.
-- `outputRouter` contains only requested keys.
-- Invalid router values are not written.
-- Native safety-net routing is not enabled unless explicitly requested.
-- No repo-local hooks, skill files, setup-output-router skill, or docs inventories were created.