Conducty System

Conducty — Systems-Level Agent Orchestration

Conducty is a per-plan orchestration system for AI agents. It does not tell agents HOW to write code — it orchestrates WHY work succeeds or fails at scale, then improves the system at the end of every plan.

What Conducty is not: A collection of isolated technique skills. If you want "how to debug" or "how to TDD" as standalone recipes, those exist elsewhere. Conducty's skills are phases of a single system — they reference each other, feed data forward, and form feedback loops.

The Conducty Cycle

Every day follows this cycle. You are always somewhere in it.

Shape → Plan → Trace → Execute → Verify → Improve
  ↑                                            |
  └────────────── feedback ────────────────────┘

Foundation skills:

• [[conducty-obsidian]] — Vault conventions; the context engine. Read before any state I/O.
• [[conducty-bootstrap]] — First-run walkthrough. Confirms vault, runs first context, produces a tiny throwaway first plan.

Supporting skills (used within the cycle, not phases themselves):

• [[conducty-verify]] — Evidence gate used by execute and checkpoint
• [[conducty-debug]] — Leverage-point analysis when prompts fail
• [[conducty-tdd]] — Test-driven discipline for orchestrator and implementer
• [[conducty-context]] — Project ingestion as a linked sub-graph (Architecture, Conventions, Invariants, Hotspots, Tests, Glossary, per-module deep notes)
• [[conducty-worktrees]] — Git isolation for parallel execution
• [[conducty-dialectic]] — Multi-persona decision analysis for architectural choices
• [[conducty-review]] — End-of-plan audit that feeds into improve

Post-cycle skills (run after a plan finishes, before merge/deploy):

• [[conducty-code-review]] — Whole-branch holistic review (security, correctness, coupling, tests). Writes a code-review note linked to the plan.
• [[conducty-ship]] — Pre-merge gate: lint, typecheck, tests, secrets scan, vuln check, code-review verdict. Single ship-or-don't verdict.

Maintenance skills:

• [[conducty-vault-graph]] — Vault hygiene audit. Run weekly to surface orphans, broken wikilinks, stale context, recurring failure patterns.

The Ten Principles

These are woven into every skill. They are the philosophy that differentiates Conducty.

1. Appetite Before Plan

Shape Up — Ryan Singer

Define the time and effort budget BEFORE planning. The plan fits the appetite, not the reverse. Every prompt gets a time budget. Exceed it? Stop and re-evaluate — don't spiral. A plan that exceeds the appetite is a bad plan, no matter how thorough.

2. Tracer Bullets Before Volleys

The Pragmatic Programmer — Hunt & Thomas

Before full parallel execution, run ONE prompt end-to-end as a tracer to validate plan assumptions. The first prompt in every group is a tracer. If it fails, the plan has a flaw — fix the plan, not just the prompt.

3. Prompt Quality Is the Highest Leverage Point

Thinking in Systems — Donella Meadows

Everything downstream — verification, debugging, retries — compensates for bad prompts. Invest upstream. A prompt with clear acceptance criteria, scoped context, and a concrete verification command succeeds on the first attempt. A vague prompt generates rework no matter how good your review process is.

4. Deep Modules, Not Ceremony

A Philosophy of Software Design — John Ousterhout

Each skill should REDUCE net complexity for the agent, not add bureaucratic checkboxes. Simple trigger interface, rich guidance inside. If a skill is mostly "red flags" and "rationalization tables," it's shallow — it describes failure instead of enabling success.

5. Improvement Kata: Learn or Repeat

Toyota Kata — Mike Rother

Every plan ends with: what was the target? What happened? What did we learn? What changes next? History is not just a log — it's a learning corpus that shapes future prompts. Conducty is a LEARNING system, not just an execution pipeline.

6. Conceptual Integrity From One Mind

The Mythical Man-Month — Fred Brooks

The orchestrator maintains the vision. Implementers execute. Don't blur the boundary. Every prompt carries the plan's intent — not just mechanical instructions, but WHY this work matters and WHERE it fits. The orchestrator is the chief surgeon; subagents are the surgical team.

7. Define Errors Out of Existence

A Philosophy of Software Design — John Ousterhout

Design prompts so common failure modes are structurally impossible. Instead of catching failures downstream, prevent them at the prompt level. A prompt that includes the exact file paths, the exact verification command, and the exact acceptance criteria doesn't need elaborate error recovery — it succeeds by design.

8. Characterize Before Changing

Working Effectively with Legacy Code — Michael Feathers

Before modifying existing code, first verify and document current behavior. Every refactor prompt starts with characterization, not transformation. The implementer's first act is confirming that existing tests pass and behavior is understood — then and only then does the change begin.

9. Calibrate Rigor to Risk

The Pragmatic Programmer — Hunt & Thomas / Release It! — Michael Nygard

Not every prompt needs two-stage review. Low-risk prompts get verification only. Medium-risk get spec review. High-risk get full two-stage review. Conducty's rigor scales with complexity — blanket ceremony for everything is waste, not quality.