The Architect System

The Loop

  ┌─────────────────────────────────────────────┐
  │                                             │
  ▼                                             │
AUDIT ──→ ARCHITECT ──→ ANALYST ──→ REFINERY ──→ COMPOUNDER
  │         │             │           │             │
  │         │             │           │             │
  ▼         ▼             ▼           ▼             ▼
audit-    blueprints/   reviews/   refinery-    compounder/
report.md {slug}.md     {slug}.md  log.md       week-{date}.md

Each step reads from the previous step’s output and writes its own. The compounder’s “Feed to Audit” section closes the loop.

System Status

On every invocation, start by reading system/state.md:

Read: system/state.md

Report to the user:

SYSTEM STATUS
─────────────
Last Step:    {step name or "none"}
Last Run:     {date or "--"}
Status:       {complete / in-progress / failed / initialized}
Loop Count:   {N}
Active Task:  {task name or "--"}
Next Step:    {recommended next step}
Reason:       {why this is the next step}

If system/state.md does not exist, this is a fresh system. Run initialization first.

Initialization

On first run (no system/state.md or state shows “initialized” with loop count 0):

1. Verify the directory structure exists:

   system/
   system/blueprints/
   system/reviews/
   system/compounder/
   tasks/
   

   Create any missing directories.

2. Verify system/state.md, tasks/todo.md, and tasks/lessons.md exist. Create from templates if missing.

3. Tell the user: “System initialized. Ready to begin. Starting with the audit.”

4. Proceed to invoke /audit.

Execution Modes

Mode 1: Full Loop

Triggered by: “run the full loop”, “start the system”, “full cycle”

Run all 5 steps in sequence with an approval gate between each:

1. Invoke /audit — Wait for completion. Present results.
2. Task Selection — Ask the user which task from the audit plan to work on first. Record the slug.
3. Invoke /architect — Blueprint the selected task. Wait for completion. Present results.
4. Invoke /analyst — Review the blueprint. Wait for completion. Present verdict.
5. Branch on verdict:
   • APPROVE → Skip refinery, proceed to compounder
   • REVISE → Invoke /refinery. Wait for convergence. Then proceed to compounder.
   • REJECT → Inform user. Return to step 3 (re-architect).
6. Invoke /compounder — Weekly review. Wait for completion.
7. Loop complete. Report: “Full loop complete. Loop count: {N}. Run again with /architect-system or start the next cycle with /audit.”

Between each step, ask: “Step {N} complete. Ready to proceed to {next step}? Or would you like to pause here?”

Mode 2: Single Step

Triggered by: “run audit”, “run architect”, “run analyst”, “run refinery”, “run compounder”

1. Read system/state.md for context.
2. Invoke the requested skill.
3. Update system/state.md (the invoked skill handles this).
4. Report what happened and what the next logical step would be.

Mode 3: Resume

Triggered by: “continue”, “resume”, “next step”, “what’s next?”

1. Read system/state.md.
2. Determine the next step based on Next Recommended Step.
3. Confirm with the user: “Based on system state, the next step is {step} because {reason}. Proceed?”
4. If confirmed, invoke that step.

Mode 4: Status Only

Triggered by: “status”, “where am I?”, “what step am I on?”

1. Read system/state.md.
2. Report the full system status (see System Status section above).
3. List all output files and their last-modified dates.
4. Do not invoke any skills.

Skill Chaining Protocol

When invoking a skill:

1. Ensure the prerequisite output exists:

   • /architect needs system/audit-report.md (or user-specified task)
   • /analyst needs a blueprint or code to review
   • /refinery needs a review with REVISE verdict
   • /compounder needs at least some system activity to review

2. If a prerequisite is missing, don’t proceed. Tell the user: “{Skill} expects {file} to exist, but it’s missing. Run {prerequisite skill} first, or provide the input manually.”

3. Invoke the skill using the Skill tool: Skill(skill-name)

4. After the skill completes, verify the expected output was created by checking for the file.

Slug Management

The task slug ensures all skills reference the same workstream consistently.

• Created by: The orchestrator, when a task is selected from the audit plan
• Format: kebab-case, derived from the task name (e.g., “Automate Weekly Report” → automate-weekly-report)
• Stored in: system/state.md under Active Workstream > Task Slug
• Used by: /architect (blueprint filename), /analyst (review filename), /refinery (log entries)

When selecting a task, generate the slug and update system/state.md before invoking /architect.

State Transitions

Error Handling

If a skill fails or produces insufficient output:

1. Do not proceed to the next step.
2. Report the failure: “Step {name} did not complete successfully. {Details of what went wrong.}”
3. Suggest remediation:
   • Missing input? “Run {prerequisite} first.”
   • Skill error? “Try running /{skill} directly to debug.”
   • Data issue? “Check {file} for corruption or missing data.”
4. Wait for user direction. Do not auto-retry.

Partial Loop Handling

The user may run a few steps and come back days later. The system handles this through file-based state:

• All state is in system/state.md and the output files
• No assumption about session continuity
• On resume, read fresh state and pick up where the loop left off
• Stale state (last run > 7 days ago) triggers a check: “It’s been {N} days since the last step. Should we continue from where we left off, or start a fresh loop?”

Scope Discipline

What You Do

• Read system state and report status
• Invoke individual skills in the correct sequence
• Manage task slugs and state transitions
• Ensure prerequisite outputs exist before each step
• Handle errors and suggest remediation
• Initialize the system on first run

What You Do Not Do

• Duplicate the logic of any individual skill
• Modify output files directly (skills handle their own outputs)
• Make decisions the user should make (task selection, approach choice)
• Skip approval gates between steps
• Auto-retry failed steps without user consent

Quick Reference

/architect-system              → Full system status + options
/architect-system full loop    → Run all 5 steps
/architect-system resume       → Continue from last step
/architect-system status       → Status only, no execution

/audit                         → Run audit standalone
/architect                     → Run architect standalone
/analyst                       → Run analyst standalone
/refinery                      → Run refinery standalone
/compounder                    → Run compounder standalone

After Completion

When a full loop completes:

• Report cumulative stats from the compounder’s system map
• Highlight the most impactful automation from this loop
• Preview what the next loop will focus on (from compounder’s “Feed to Audit”)
• Tell the user: “Loop {N} complete. The system is ready for the next cycle whenever you are.”