Provision Agentic Config — Workflow Orchestration

Generated: 2026-05-23 | Project: gblock-party-redux | Status: Resolved (provisioning completed)

Summary

This provisioning installed workflow orchestration conventions into two new files:

  • ./CLAUDE.md — created, block inserted at top
  • ./AGENTS.md — created, block inserted at top
  • Monorepo safety block — skipped (not a monorepo)

Both files contain the orchestration block exactly once. Source/verification notes written to both files.

CLAUDE.md Content

Workflow Orchestration

1. Plan Mode Default

  • Enter plan mode for ANY non-trivial task (3+ steps or architectural decisions)
  • If something goes sideways, STOP and re-plan immediately
  • Verification is mandatory, but routine no-op verification runs inside the active execution/shipping step
  • Write detailed specs upfront to reduce ambiguity
  • In Codex: use update_plan in Default mode and request_user_input only when already in Plan mode
  • Do not assume a Claude-style clear-context-on-accept flow or related JSON setting exists

2. Subagent Strategy

  • Use subagents liberally to keep main context window clean
  • Offload research, exploration, and parallel analysis to subagents
  • For complex problems, throw more compute at it via subagents
  • One task per subagent for focused execution
  • For agent-team parallel write lanes, require separate GitHub branches per lane and include a consolidation/PR review step

3. Self-Improvement Loop

  • After ANY correction from the user: update tasks/lessons.md with the pattern
  • Write rules for yourself that prevent the same mistake
  • Ruthlessly iterate on these lessons until mistake rate drops
  • Review lessons at session start for relevant project

4. Verification Before Done

  • Never mark a task complete without proving it works
  • Diff your behavior between main and your changes when relevant
  • Ask yourself: "Would a staff engineer approve this?"
  • Run tests, check logs, demonstrate correctness

5. Demand Elegance (Balanced)

  • For non-trivial changes: pause and ask "is there a more elegant way?"
  • Skip this for simple, obvious fixes
  • Challenge your own work before presenting it

6. Autonomous Bug Fixing

  • When given a bug report: just fix it
  • Point at logs, errors, failing tests — then resolve them
  • Zero context switching required from the user

Task Management

  1. Plan First: Write plan to tasks/roadmap.md and tasks/todo.md
  2. Verify Plan: Check in before starting implementation
  3. Track Progress: Mark items complete as you go
  4. Explain Changes: High-level summary at each step
  5. Document Results: Add review section to tasks/todo.md
  6. Capture Lessons: Update tasks/lessons.md after corrections

Core Principles

  • Simplicity First
  • No Laziness — find root causes
  • Minimal Impact — only touch what's necessary
  • Direct-To-Primary Git Flow — commit to main by default
  • Always Ship Mutations — commit and push before stopping
  • No GitHub Actions — unless explicitly asked

AGENTS.md Content

Same structure as CLAUDE.md with these differences:

  • Subagent Strategy: Subagents only when Codex tool instructions allow them; do not override Codex's current subagent permission
  • Always Ship Mutations: Codex $run ships by default — use $ship only to package existing work or unpushed commits

Monorepo Detection

Result: Not a monorepo

  • pnpm-workspace.yaml: not found
  • package.json workspaces field: no package.json
  • lerna.json: not found
  • packages/ directory: not found
  • apps/ directory: not found

Monorepo safety block was skipped.

Decision Records

The following clarifications were raised during provisioning and have been resolved. They are preserved here as read-only records.

Decision: tasks/ directory creation timing

Resolved: Defer — the tasks/ directory is created on first use rather than pre-created with empty roadmap.md, todo.md, and lessons.md.

Rationale: Q1 asked whether to create the tasks/ directory now or defer until the first task is planned. Deferring avoids committing empty placeholder files and keeps the repo clean until a task actually needs the directory.

Decision: "Always Ship Mutations" with no remote configured

Resolved: Keep the convention as-is — push will fail visibly if no remote exists, rather than adjusting the principle to skip push until a remote is added.

Rationale: Q2 noted the repo had no remote configured and asked whether to soften "Always Ship Mutations" to commit locally but skip push. Keeping the convention as-is preserves the intent of the principle and surfaces the missing-remote condition loudly instead of silently degrading shipping behavior.

Decision: primary branch for Direct-To-Primary Git Flow

Resolved: master — the current branch is confirmed as the primary branch for Direct-To-Primary Git Flow.

Rationale: Q3 flagged that the primary branch was assumed to be "main" by convention but asked for confirmation. The repository's current branch is master, so that is the authoritative primary branch for this project.

Compile Review

Use Compile Feedback to send concerns or clarification requests before answering every gate, or Compile Answers for final approval once all required gate questions are answered. The compiled YAML always includes any optional section feedback you set.