workflow-trivial

Trivial Workflow

Use for typos, single-line fixes (≤20 lines), no new dependencies/files.

Same mandatory phase order, minimal ceremony. Phases are SEQUENTIAL — never skip, merge, reorder, or run phases in parallel. Within a phase, tasks may be combined.

Before You Start

Search project and global memories for relevant context:

1. search_memories(query="<topic>", project="<repo>")
2. get_memories(memory_id="<id>")

MemCan MCP tools. Use if available, skip silently if not.

Phase 1: Planning (Lightweight)

Single agent invocation combining all planning concerns:

Requirements + Test Case Spec + Dev Plan — understand the fix, write 1-3 test case specifications (description + expected outcome), identify the change location.

No separate UX or architecture sub-phases needed for trivial fixes.

Phase 2: Implementation → developer-bilby

1. Write/update tests from the test case spec — must fail initially
2. Implement until tests pass
   • Pre-empt the QA audits before declaring impl done:
     1. Self-check comment rules — every comment block written or modified must satisfy coding-best-practices Cross-Cutting Rules: length cap (≤2 preferred, 3 mediocre), present-state only, two-tier audience (strict for internal commentary, liberal for public-API doc comments).
     2. Self-check duplication — for every helper, parser, signer, fetch loop, atomic-write, etc. introduced, briefly grep the workspace, direct dependencies (per the project's manifest — Cargo.toml, package.json, pyproject.toml, go.mod, etc.), and any project-defined reference repos for an existing equivalent before rolling a new one. If found and publicly exported, use it. If crate-private (or language equivalent), propose promoting it. If only partially overlaps, document the rationale for the new copy.
     3. Report rejected equivalents — list any candidate equivalent considered and rejected, with one-line rationale, in the implementation summary so QA has context.
3. Format, lint, commit

TDD Discipline

1. Tests derive from the test case spec, not from implementation.
2. Tests must fail before implementation begins.
3. If a test matches the spec, the code is wrong.

Phase 3: QA

Pass tests, formatter, linter. Verify the fix delivers the intended experience, not just passes tests.

Two READ-ONLY parallel audits via qa-engineer-marvin (NO code edits — findings go to the lead):

• Docs review (read-only) — apply coding-best-practices Cross-Cutting Rules (length cap + present-state + two-tier audience) to all comments and API doc comments (rustdoc, JSDoc, docstrings, godoc, etc.) introduced by the PR diff. Emit findings with file:line citations and proposed rewrites. Report path: /tmp/claudius-<scope>-docs-report.md.
• Dedup audit (read-only) — for every new publicly exported function, type, trait/interface, and module introduced by the PR, search the workspace, direct dependencies (per the project's manifest — Cargo.toml, package.json, pyproject.toml, go.mod, etc.), and project-defined reference repos for equivalent functionality. Emit findings: high-confidence duplicates, partial overlaps, and reviewed-and-rejected items, each with file:line citations on both sides. Report path: /tmp/claudius-<scope>-dedup-report.md.

Findings go to the lead, who decides follow-up:

• Trivial fixes can land in the same PR via a separate commit
• Substantial refactors land as follow-up PRs
• Findings the lead judges as wrong-call go in a "rejected with rationale" section of the report

Skip rule (workflow-trivial only): Docs review and dedup audit MAY be skipped only when: zero comment lines added/modified (skip docs review) AND zero new public symbols introduced (skip dedup). Both conditions must be documented in the implementation summary (Bilby's commit message + report-back).

project-reviewer-adams omission: workflow-trivial omits the project-consistency audit because trivial scope (≤20 lines, typo fixes, single-line bug repairs) does not warrant a full project-reviewer pass. Consistency is deferred to merge-time review. If the change starts smelling like ≥20 lines or touches multiple files, escalate to workflow-simplified instead.

Phase 4: Lessons Learned

If anything noteworthy was learned, save via claudius:lessons-learned. Default to global memories. Skip for truly trivial fixes. Report count saved.

Failure & Auto-Retry

1. QA fails → return to Implementation with failure report
2. Implementation fails → return to Planning with failure report
3. Do NOT wait for user acceptance unless a decision is required
4. Max 2 retries before escalating to user

Model Selection

All phases use model: "sonnet". Escalate to opus only for debugging non-obvious failures.

Code Deduplication

Verify the change doesn't introduce or miss existing duplication.

Commit Discipline

Agents must commit all changes before exiting — uncommitted work cannot be merged.

ALL spawned agents MUST use isolation: "worktree" — no exceptions.

Pre-flight pattern: see grand-admiral skill — Worktree Isolation. Default is Option A (local-SHA injection, no push); Option B (push first) is the explicit fallback.

Post-wave: verify worktree commits, merge into the feature branch, run tests, then clean up worktrees. Push only when the user explicitly authorizes it (e.g., via /push, /ci-dance, or direct instruction) — never push as an automatic step.