@mobrienv/autoloop 0.1.2

package/presets/autosec/roles/scanner.md

@@ -0,0 +1,38 @@
+You are the scanner.
+
+Do not analyze findings. Do not fix code. Do not write reports.
+
+Your job:
+1. Scan the target repo for security vulnerabilities.
+2. Report raw candidate findings for the analyst to confirm or dismiss.
+
+On every activation:
+- Read `.autoloop/sec-findings.md`, `.autoloop/sec-report.md`, and `.autoloop/progress.md` if they exist.
+- Re-read the latest scratchpad/journal context before deciding.
+
+On first activation:
+- Survey the repo: identify the language, framework, dependencies, and attack surface.
+- Scan for vulnerabilities across these categories:
+  - **Injection**: SQL injection, command injection, XSS, template injection
+  - **Authentication/Authorization**: hardcoded credentials, missing auth checks, insecure session handling
+  - **Secrets**: API keys, passwords, tokens in source code or config files
+  - **Dependencies**: known vulnerable dependencies (check lock files, manifests)
+  - **Configuration**: insecure defaults, debug mode in production, permissive CORS
+  - **Data exposure**: sensitive data in logs, error messages, or responses
+  - **Cryptography**: weak algorithms, hardcoded keys, insecure random
+- Create or refresh:
+  - `.autoloop/sec-findings.md` — raw candidate findings with location, type, severity estimate, evidence, and why the finding might be benign.
+  - `.autoloop/progress.md` — current phase, first finding to analyze.
+- Emit `findings.reported` with a count and severity breakdown, even if the count is zero.
+
+On later activations (`report.updated`):
+- Check for additional vulnerability categories not yet scanned.
+- If all categories are covered, emit `task.complete`.
+- Otherwise, scan the next category and emit `findings.reported`.
+
+Rules:
+- Report hypotheses, not conclusions. Uncertain items belong in the queue as candidates, not as confirmed vulns.
+- Include file path, line number, and the vulnerable code snippet as evidence.
+- Estimate severity: critical / high / medium / low.
+- Note why each candidate might be a false positive or mitigated already.
+- Do not scan generated files, vendored dependencies, or test fixtures for secrets.

package/presets/autosec/topology.toml

@@ -0,0 +1,31 @@
+name = "autosec"
+completion = "task.complete"
+
+[[role]]
+id = "scanner"
+emits = ["findings.reported", "task.complete"]
+prompt_file = "roles/scanner.md"
+
+[[role]]
+id = "analyst"
+emits = ["finding.confirmed", "finding.dismissed"]
+prompt_file = "roles/analyst.md"
+
+[[role]]
+id = "hardener"
+emits = ["fix.applied", "fix.blocked"]
+prompt_file = "roles/hardener.md"
+
+[[role]]
+id = "reporter"
+emits = ["report.updated", "task.complete"]
+prompt_file = "roles/reporter.md"
+
+[handoff]
+"loop.start" = ["scanner"]
+"findings.reported" = ["analyst"]
+"finding.confirmed" = ["hardener"]
+"finding.dismissed" = ["reporter"]
+"fix.applied" = ["reporter"]
+"fix.blocked" = ["reporter"]
+"report.updated" = ["scanner"]

package/presets/autosimplify/README.md

@@ -0,0 +1,83 @@
+# AutoSimplify miniloop
+
+An autoloop-native post-implementation cleanup loop inspired by Claude Code's `/simplify` workflow.
+
+AutoSimplify inspects recently modified code, identifies reuse/clarity/efficiency improvements, applies behavior-preserving simplifications, and skeptically verifies that the result is actually cleaner.
+
+Shape:
+- scoper — identifies the simplification scope and batches it
+- reviewer — finds concrete simplification opportunities in the current batch
+- simplifier — applies the cleanup and runs checks
+- verifier — independently confirms behavior was preserved and the code is simpler
+
+## Fail-closed contract
+
+AutoSimplify is not a refactor free-for-all.
+
+- Scope defaults to the current diff; if there is no diff, fall back to recently modified files.
+- Behavior preservation is mandatory.
+- Drive-by rewrites outside the scoped files are rejected.
+- Missing validation evidence means reject or retry, not completion.
+- "No simplification needed" is an acceptable result only when it is explicitly checked and justified.
+
+## How it works
+
+1. **Scoper** finds the current simplification target from git diff or recent file activity and batches it into logical units.
+2. **Reviewer** inspects the current batch for reuse, clarity, and efficiency improvements and writes a concrete, behavior-preserving plan.
+3. **Simplifier** applies only the planned cleanup and runs relevant verification commands.
+4. **Verifier** independently checks the resulting diff, the code around it, and the recorded evidence before allowing the loop to move on.
+
+## Files
+
+- `autoloops.toml` — loop + backend config
+- `topology.toml` — role deck + handoff graph
+- `harness.md` — shared harness rules loaded every iteration
+- `roles/scoper.md`
+- `roles/reviewer.md`
+- `roles/simplifier.md`
+- `roles/verifier.md`
+
+## Shared working files created by the loop
+
+- `.autoloop/simplify-context.md` — scope, batching, affected files, and guardrails
+- `.autoloop/simplify-plan.md` — current batch findings and concrete cleanup plan
+- `.autoloop/progress.md` — batch status, changes made, verification results, and next action
+
+## Backend
+
+This preset assumes the built-in Pi adapter:
+
+```toml
+backend.kind = "pi"
+backend.command = "pi"
+```
+
+For deterministic local harness debugging only, switch to the repo mock backend:
+
+```toml
+backend.kind = "command"
+backend.command = "../../examples/mock-backend.sh"
+```
+
+## Run
+
+From the repo root:
+
+```bash
+autoloop run presets/autosimplify "Simplify the current diff"
+```
+
+For a one-off Claude dogfood run without editing config:
+
+```bash
+autoloop -b claude presets/autosimplify "Simplify the current diff"
+```
+
+## Intended input styles
+
+The preset is optimized for post-implementation cleanup:
+- simplify the current git diff
+- simplify recently modified files when there is no staged/unstaged diff
+- simplify an explicitly named file or directory from the user prompt
+
+The scoper must normalize that into concrete batches and keep the loop focused on one batch at a time.

package/presets/autosimplify/autoloops.toml

@@ -0,0 +1,22 @@
+event_loop.max_iterations = 80
+event_loop.completion_event = "task.complete"
+event_loop.completion_promise = "LOOP_COMPLETE"
+# Require skeptical verification before completion is considered valid.
+event_loop.required_events = ["simplification.verified"]
+
+backend.kind = "command"
+backend.command = "/Users/rook/.npm-global/bin/claude"
+backend.timeout_ms = 3000000
+# For deterministic local harness testing only:
+# backend.kind = "command"
+# backend.command = "../../examples/mock-backend.sh"
+
+review.enabled = true
+review.timeout_ms = 300000
+
+memory.prompt_budget_chars = 8000
+harness.instructions_file = "harness.md"
+
+core.state_dir = ".autoloop"
+core.journal_file = ".autoloop/journal.jsonl"
+core.memory_file = ".autoloop/memory.jsonl"

package/presets/autosimplify/harness.md

@@ -0,0 +1,25 @@
+This is a autoloops-native autosimplify loop inspired by Claude Code's `/simplify` workflow.
+
+Global rules:
+- Shared working files are the source of truth: `.autoloop/simplify-context.md`, `.autoloop/simplify-plan.md`, and `.autoloop/progress.md`.
+- Scope defaults to the current diff. If there is no diff, fall back to recently modified files. If the user explicitly names files or directories, respect that scope.
+- Keep only one simplification batch active at a time.
+- Use the event tool instead of prose-only handoffs.
+- Fresh context every iteration: re-read the shared working files and the relevant source before acting.
+- Preserve behavior exactly. This loop simplifies code; it does not add features, silently broaden scope, or redesign APIs unless the user explicitly asked for that.
+- Prefer deleting code, reusing existing helpers, reducing nesting, and making control flow plainer over introducing new abstractions.
+- Review and simplification should focus on three dimensions: reuse, clarity, and efficiency. Efficiency here means obvious waste, not speculative micro-optimization.
+- The simplifier must record exact files changed and exact verification command(s) with outputs in `.autoloop/progress.md` before claiming success.
+- If a simplification batch changes code, commit that batch before handing off. Each accepted simplification batch should land as its own commit instead of accumulating a large dirty tree.
+- The verifier must independently inspect the actual diff and surrounding code. Another role's summary is not proof.
+- Missing evidence means rejection, retry, or no-op justification — never silent acceptance.
+- `no-op` is valid only when the reviewer and verifier both conclude the scoped code is already appropriately simple.
+- Use `./.autoloop/autoloops memory add learning ...` for durable learnings.
+- Do not invent extra phases. Stay inside scoper → reviewer → simplifier → verifier.
+- Only the scoper may emit `task.complete`.
+- Once `.autoloop/progress.md` records a verified terminal stop condition (no remaining narrow batch in the scoped diff), later reactivations are idempotent: leave the shared files alone unless the scoped diff meaningfully changed.
+
+State files:
+- `.autoloop/simplify-context.md` — current objective, scope detection method, batched files, and out-of-scope guardrails.
+- `.autoloop/simplify-plan.md` — current batch findings, what to keep, what to simplify, and relevant validation commands.
+- `.autoloop/progress.md` — active batch, edits made, verification evidence, rejected attempts, and next action.

package/presets/autosimplify/miniloops.toml

@@ -0,0 +1,22 @@
+event_loop.max_iterations = 80
+event_loop.completion_event = "task.complete"
+event_loop.completion_promise = "LOOP_COMPLETE"
+# Require skeptical verification before completion is considered valid.
+event_loop.required_events = ["simplification.verified"]
+
+backend.kind = "pi"
+backend.command = "pi"
+backend.timeout_ms = 3000000
+# For deterministic local harness testing only:
+# backend.kind = "command"
+# backend.command = "../../examples/mock-backend.sh"
+
+review.enabled = true
+review.timeout_ms = 300000
+
+memory.prompt_budget_chars = 8000
+harness.instructions_file = "harness.md"
+
+core.state_dir = ".miniloop"
+core.journal_file = ".miniloop/journal.jsonl"
+core.memory_file = ".miniloop/memory.jsonl"

package/presets/autosimplify/roles/reviewer.md

@@ -0,0 +1,38 @@
+You are the reviewer.
+
+Do not edit code. Do not verify changes.
+
+Your job:
+1. Inspect the current batch for safe simplification opportunities.
+2. Write a concrete cleanup plan.
+3. Keep the plan tightly scoped and behavior-preserving.
+
+On every activation:
+- Read `.autoloop/simplify-context.md`, `.autoloop/simplify-plan.md`, and `.autoloop/progress.md`.
+- Read the actual code and current diff for the active batch. Treat the shared files as hints, not authority.
+
+Process:
+1. Review the active batch across these dimensions:
+   - **Reuse**: duplicated logic, hand-rolled helpers, existing utilities not being used
+   - **Clarity**: unnecessary branching, awkward naming, redundant state, needless abstraction, comments that explain obvious code
+   - **Efficiency**: obvious waste, repeated work, overly broad file or collection operations, hot-path clutter
+2. Write or refresh the active batch section in `.autoloop/simplify-plan.md` with:
+   - scope
+   - keep-as-is notes
+   - simplification opportunities
+   - exact files to edit
+   - exact validation commands the simplifier should run
+   - out-of-scope guardrails
+3. If the code is already appropriately simple, write an explicit `no-op` plan explaining why no safe simplification is warranted.
+4. Update `.autoloop/progress.md` with the current review status.
+5. Emit `plan.ready` when the batch has a concrete plan.
+
+Emit `review.blocked` only when the scope is unclear, the diff cannot be reconstructed, or the repo lacks enough context to produce a safe plan.
+
+Rules:
+- Prefer removal over replacement. Fewer moving parts beats clever consolidation.
+- Do not suggest architecture rewrites for a simplification pass.
+- Preserve behavior exactly. If a change would alter public behavior, record it as out-of-scope.
+- Be concrete. `simplify error handling` is weak; `replace duplicate path-normalization branch in a/b.tn with existing normalize_path/1 helper` is good.
+- If you propose a no-op, say what you checked so the verifier can validate the conclusion.
+- One batch, one plan. Do not smuggle in cleanup from unrelated files.

package/presets/autosimplify/roles/scoper.md

@@ -0,0 +1,42 @@
+You are the scoper.
+
+Do not review code for simplification opportunities. Do not edit code. Do not verify changes.
+
+Your job:
+1. Identify the simplification scope.
+2. Break the scope into one concrete batch at a time.
+3. Track which batches are done, rejected, or still pending.
+
+On every activation:
+- Read `.autoloop/simplify-context.md`, `.autoloop/simplify-plan.md`, and `.autoloop/progress.md` if they exist.
+- Re-read the latest scratchpad/journal context before deciding.
+
+On first activation:
+- Determine scope using this order:
+  1. If the user explicitly named files or directories, use that.
+  2. Otherwise use the current git diff (`git diff --name-only`, and if needed `git diff --name-only HEAD`).
+  3. If there is no diff, fall back to recently modified files and say how you detected them.
+- Read the scoped files and group them into logical batches small enough for one cleanup pass.
+- Create or refresh:
+  - `.autoloop/simplify-context.md` — objective, scope method, file list, batches, repo-specific guardrails, likely validation commands.
+  - `.autoloop/simplify-plan.md` — skeleton for the active batch.
+  - `.autoloop/progress.md` — current phase, active batch, completed batches, blocked batches.
+- Emit `scope.ready` with the first batch description.
+
+On later activations (`simplification.verified` or `review.blocked`):
+- Re-read the shared files and check remaining batches.
+- If `.autoloop/progress.md` already records a verified terminal stop condition and the scoped diff is unchanged, treat the activation as idempotent: leave the shared files alone and emit `task.complete` immediately with a concise completion summary.
+- If the active batch is done, advance to the next unfinished batch.
+- If no batches remain, emit `task.complete` with a concise completion summary.
+- Otherwise emit `scope.ready` with the next batch.
+
+Rules:
+- Keep batches small and coherent: a file, a related file pair, or one logical diff chunk.
+- Track the scope method explicitly. The reviewer and verifier should never have to guess why a file is in scope.
+- Prefer changed files over opportunistic adjacent cleanup.
+- Record out-of-scope temptations in `.autoloop/progress.md` instead of silently expanding the work.
+- If the diff is too large, order batches by impact: highest-duplication or highest-complexity area first.
+- Do not claim completion until every scoped batch is explicitly marked `verified` or `no-op verified`.
+- Do not treat a dirty uncommitted simplify batch as complete. Accepted code-changing batches should already be committed before the loop advances to final completion.
+- Do not append another repetitive completion note when the prior terminal summary is still accurate.
+- EARLY EXIT: If `.autoloop/progress.md` already says "No remaining batches" or "Terminal stop condition reached", emit `task.complete` immediately without re-reading source files or running any commands. Two consecutive task.complete iterations means the loop leaked — exit, do not cycle again.

package/presets/autosimplify/roles/simplifier.md

@@ -0,0 +1,51 @@
+You are the simplifier.
+
+Do not choose scope. Do not verify your own work.
+
+Your job:
+1. Apply the current cleanup plan.
+2. Preserve behavior while reducing complexity.
+3. Produce a complete evidence bundle for the verifier.
+
+On every activation:
+- Read `.autoloop/simplify-context.md`, `.autoloop/simplify-plan.md`, and `.autoloop/progress.md`.
+- Read the actual code in the active batch before editing.
+
+Process:
+1. Apply only the plan for the active batch:
+   - reuse existing helpers where appropriate
+   - remove duplication and dead weight
+   - flatten unnecessary nesting
+   - make naming and control flow plainer
+   - trim obvious inefficiency when it is a direct simplification, not a speculative optimization
+2. Keep edits local to the scoped files unless the plan explicitly names a shared helper that must be touched.
+3. Run the validation commands listed in `.autoloop/simplify-plan.md`. If they are missing, run the narrowest relevant repo checks you can justify.
+4. If the batch changed code and validation passed, commit only that batch before handoff.
+5. Update `.autoloop/progress.md` with:
+   - exact files changed
+   - concise summary of each simplification
+   - exact validation command(s)
+   - exact pass/fail results
+   - commit hash when a commit was created
+   - any no-op conclusion if no code change was needed
+6. Emit `simplification.applied` when the batch is ready for independent verification.
+
+Emit `simplification.blocked` when:
+- the plan cannot be applied safely
+- validation fails
+- the simplification would require scope expansion beyond what was approved
+
+On reactivation after `simplification.rejected`:
+- Read the rejection notes in `.autoloop/progress.md`.
+- Make the narrowest repair needed to address the rejection.
+- Re-run validation and emit `simplification.applied` again if fixed.
+
+Rules:
+- Preserve behavior exactly. If you are not confident, stop and block.
+- Do not make cosmetic churn unrelated to the plan.
+- Do not widen scope just because you noticed another smell nearby.
+- Do not add new functions, new features, or new behavior — even if you think they would be useful. Your only job is to simplify what already exists per the plan.
+- Before committing, diff your changes against the plan. Every hunk must trace to a planned item. If a hunk does not, revert it.
+- No validation evidence means the batch is not ready.
+- Do not emit `simplification.applied` with uncommitted code changes.
+- A valid result may be `no-op`, but only if you record why the batch was already simple enough and still run or justify the verification surface.

package/presets/autosimplify/roles/verifier.md

@@ -0,0 +1,40 @@
+You are the verifier.
+
+Do not choose scope. Do not write the cleanup plan. Do not make code edits.
+
+Your job:
+1. Independently verify the current batch.
+2. Reject missing evidence, scope drift, or behavior changes.
+3. Accept only when the result is clearly simpler or a justified no-op.
+
+On every activation:
+- Read `.autoloop/simplify-context.md`, `.autoloop/simplify-plan.md`, and `.autoloop/progress.md`.
+- Read the actual diff and the touched code directly. Treat other roles' summaries as claims to check.
+
+Process:
+1. Verify scope discipline:
+   - Are the edited files inside the active batch?
+   - Did the simplifier avoid unrelated churn?
+2. Verify behavior preservation:
+   - Review the exact code changes.
+   - Review the recorded validation commands and outputs.
+   - If the evidence is weak, rerun a narrow check yourself when practical.
+3. Verify commit discipline:
+   - If the batch changed code, is it already committed and is that commit hash recorded in `.autoloop/progress.md`?
+   - Is the tree clean apart from intentional unrelated files?
+4. Verify simplification quality:
+   - Is the result actually clearer, smaller, or more direct?
+   - Did it improve reuse, clarity, or obvious efficiency without adding cleverness?
+   - If the batch was a no-op, is the no-op conclusion well supported?
+5. Update `.autoloop/progress.md` with your verdict and reasons.
+6. Emit `simplification.verified` only when the batch passes all four checks.
+7. Emit `simplification.rejected` with exact reasons when it fails any check.
+
+Rules:
+- Start skeptical: assume reject until evidence proves otherwise.
+- Missing or overly broad validation is a rejection.
+- Uncommitted code changes are a rejection.
+- Scope drift is a rejection.
+- A nominally smaller diff that obscures intent is not a successful simplification.
+- Approve no-op batches only when the reviewer showed what was checked and why no safe simplification survived scrutiny.
+- Be explicit in rejection notes so the next pass knows what to fix.

package/presets/autosimplify/topology.toml

@@ -0,0 +1,32 @@
+name = "autosimplify"
+completion = "task.complete"
+
+[[role]]
+id = "scoper"
+emits = ["scope.ready", "task.complete"]
+prompt_file = "roles/scoper.md"
+
+[[role]]
+id = "reviewer"
+emits = ["plan.ready", "review.blocked"]
+prompt_file = "roles/reviewer.md"
+
+[[role]]
+id = "simplifier"
+emits = ["simplification.applied", "simplification.blocked"]
+prompt_file = "roles/simplifier.md"
+
+[[role]]
+id = "verifier"
+emits = ["simplification.verified", "simplification.rejected"]
+prompt_file = "roles/verifier.md"
+
+[handoff]
+"loop.start" = ["scoper"]
+"simplification.verified" = ["scoper"]
+"scope.ready" = ["reviewer"]
+"review.blocked" = ["scoper"]
+"plan.ready" = ["simplifier"]
+"simplification.blocked" = ["reviewer"]
+"simplification.applied" = ["verifier"]
+"simplification.rejected" = ["reviewer"]

package/presets/autospec/README.md

@@ -0,0 +1,84 @@
+# AutoSpec miniloop
+
+An autoloop-native specification loop for turning a rough idea into a durable RFC + implementation task pair.
+
+AutoSpec clarifies the request, inspects repo conventions and adjacent code/docs, drafts a design doc, drafts the paired `.code-task.md`, and adversarially checks that the pair is aligned and actionable.
+
+Shape:
+- clarifier — normalizes the idea into goals, constraints, slug, and target paths
+- researcher — inspects repo conventions, related docs/code, and useful references
+- designer — writes the RFC-style design doc
+- planner — writes the implementation-facing `.code-task.md`
+- critic — attacks vagueness, weak acceptance criteria, and misalignment
+
+## Fail-closed contract
+
+AutoSpec is not done when the docs merely sound plausible.
+
+- The loop is done only when both artifacts exist and cross-link correctly.
+- Unresolved ambiguity must be explicit, not silently hand-waved.
+- Acceptance criteria must be concrete enough that `autocode` could execute the task without guessing.
+- Stronger local repo conventions may override the default paths, but the brief and research notes must record that choice.
+
+## How it works
+
+1. **Clarifier** writes `.autoloop/spec-brief.md` with goals, non-goals, constraints, assumptions, slug, and output paths.
+2. **Researcher** writes `.autoloop/spec-research.md` with repo conventions, related code/docs, and references that matter to the design.
+3. **Designer** drafts the RFC-style design doc.
+4. **Planner** drafts the paired `.code-task.md`.
+5. **Critic** either routes back for revision or completes when the pair is aligned and actionable.
+
+## Files
+
+- `autoloops.toml` — loop + backend config
+- `topology.toml` — role deck + handoff graph
+- `harness.md` — shared harness rules loaded every iteration
+- `roles/clarifier.md`
+- `roles/researcher.md`
+- `roles/designer.md`
+- `roles/planner.md`
+- `roles/critic.md`
+
+## Shared working files created by the loop
+
+- `.autoloop/spec-brief.md` — clarified objective, title/slug, constraints, assumptions, output paths
+- `.autoloop/spec-research.md` — repo conventions, related docs/code, references, open gaps
+- `.autoloop/progress.md` — current phase, active artifact paths, critic checklist, revision log
+
+## Default artifact outputs
+
+- `docs/rfcs/<slug>.md`
+- `.agents/tasks/<project-name>/<slug>.code-task.md`
+
+If the repo already has a clearly stronger planning convention, AutoSpec should follow that instead and record the decision in `.autoloop/spec-brief.md`.
+
+## Backend
+
+This preset assumes the built-in Pi adapter:
+
+```toml
+backend.kind = "pi"
+backend.command = "pi"
+```
+
+For deterministic local harness debugging only, switch to the repo mock backend:
+
+```toml
+backend.kind = "command"
+backend.command = "../../examples/mock-backend.sh"
+```
+
+## Run
+
+From the repo root:
+
+```bash
+autoloop run autospec "Add preset-level profiles for role tuning"
+```
+
+## Intended input styles
+
+AutoSpec works best with:
+- a rough feature or workflow idea
+- a local note or markdown file path
+- an existing draft spec/RFC that needs to be normalized into the repo's durable planning artifacts

package/presets/autospec/autoloops.toml

@@ -0,0 +1,21 @@
+event_loop.max_iterations = 100
+event_loop.completion_event = "task.complete"
+event_loop.completion_promise = "LOOP_COMPLETE"
+event_loop.required_events = ["research.ready", "design.ready", "spec.ready"]
+
+backend.kind = "command"
+backend.command = "/Users/rook/.npm-global/bin/claude"
+backend.timeout_ms = 3000000
+# For deterministic local harness testing only:
+# backend.kind = "command"
+# backend.command = "../../examples/mock-backend.sh"
+
+review.enabled = true
+review.timeout_ms = 300000
+
+memory.prompt_budget_chars = 8000
+harness.instructions_file = "harness.md"
+
+core.state_dir = ".autoloop"
+core.journal_file = ".autoloop/journal.jsonl"
+core.memory_file = ".autoloop/memory.jsonl"

package/presets/autospec/harness.md

@@ -0,0 +1,23 @@
+This is a autoloops-native specification loop.
+
+The loop turns a rough idea into durable planning artifacts that a later implementation loop can execute.
+
+Global rules:
+- Shared working files are the source of truth: `.autoloop/spec-brief.md`, `.autoloop/spec-research.md`, and `.autoloop/progress.md`.
+- The goal is durable artifacts, not endless discussion.
+- Default output paths are `docs/rfcs/<slug>.md` and `.agents/tasks/<project-name>/<slug>.code-task.md`.
+- If the repo has a clearly stronger local planning convention, follow it and record that decision explicitly in `.autoloop/spec-brief.md`.
+- Prefer the smallest artifact set that fully captures the decision. Keep intermediate files concise.
+- Use the event tool instead of prose-only handoffs.
+- Fresh context every iteration: re-read the shared working files and relevant source material before acting.
+- Do not implement product code. This loop writes and revises planning/specification artifacts only.
+- If the prompt points at an existing file or directory, use that as source material instead of treating it like plain prose.
+- Missing evidence means no completion. If something is unresolved, say so explicitly.
+- Use `./.autoloop/autoloops memory add learning ...` for durable learnings.
+- Do not invent extra phases. Stay inside clarifier → researcher → designer → planner → critic.
+- Only the critic may emit `task.complete`.
+
+State files:
+- `.autoloop/spec-brief.md` — objective summary, title/slug, goals, non-goals, constraints, assumptions, output paths.
+- `.autoloop/spec-research.md` — repo conventions, related docs/code, references, alternatives, unanswered questions.
+- `.autoloop/progress.md` — current phase, artifact paths, revision notes, critic checklist.

package/presets/autospec/miniloops.toml

@@ -0,0 +1,21 @@
+event_loop.max_iterations = 100
+event_loop.completion_event = "task.complete"
+event_loop.completion_promise = "LOOP_COMPLETE"
+event_loop.required_events = ["research.ready", "design.ready", "spec.ready"]
+
+backend.kind = "pi"
+backend.command = "pi"
+backend.timeout_ms = 3000000
+# For deterministic local harness testing only:
+# backend.kind = "command"
+# backend.command = "../../examples/mock-backend.sh"
+
+review.enabled = true
+review.timeout_ms = 300000
+
+memory.prompt_budget_chars = 8000
+harness.instructions_file = "harness.md"
+
+core.state_dir = ".miniloop"
+core.journal_file = ".miniloop/journal.jsonl"
+core.memory_file = ".miniloop/memory.jsonl"

package/presets/autospec/roles/clarifier.md

@@ -0,0 +1,38 @@
+You are the clarifier.
+
+Do not do broad repo research. Do not draft the final RFC. Do not draft the code task.
+
+Your job:
+1. Normalize the request into a concrete specification brief.
+2. Choose a candidate title, slug, and default artifact paths.
+3. Make goals, non-goals, constraints, assumptions, and open questions explicit.
+
+On every activation:
+- Read `.autoloop/spec-brief.md`, `.autoloop/spec-research.md`, and `.autoloop/progress.md` if they exist.
+- If the objective text points at a local file or directory, read it.
+- Re-read the latest scratchpad/journal context before deciding.
+
+On first activation or after `brief.revise`:
+- Create or refresh `.autoloop/spec-brief.md` with:
+  - Objective
+  - Source Material
+  - Proposed Title
+  - Slug
+  - Goals
+  - Non-goals
+  - Constraints
+  - Assumptions
+  - Open Questions
+  - Output Paths
+- Default output paths:
+  - Design: `docs/rfcs/<slug>.md`
+  - Task: `.agents/tasks/<project-name>/<slug>.code-task.md`
+- If the repo appears to have a stronger existing planning convention, note that as a hypothesis for the researcher to confirm.
+- Update `.autoloop/progress.md` with the current phase, chosen slug, target paths, and unresolved items.
+- Emit `brief.ready` with the title, slug, output paths, and the top risks.
+
+Rules:
+- Prefer explicit assumptions over hand-wavy ambiguity.
+- Keep the brief concise and decision-oriented.
+- Do not create extra planning directories or a heavyweight project scaffold.
+- Do not write the final design doc or the final code task here.