Claude Conductor — Prompts & Templates
Claude Conductor's "prompts" are the Markdown templates it writes into user projects. Claude Code reads these files automatically (especially CLAUDE.md) at session start. Below are verbatim excerpts showing the prompting technique.
Excerpt 1: templates/CLAUDE.md — Session Startup Checklist and Golden Rules (verbatim)
This is the core behavioral prompt injected into every project. Note the hard "NEVER" constraints (Golden Rules) — a directive prompting style rather than soft guidance.
## Session Startup Checklist
**IMPORTANT**: At the start of each session, check these items:
1. **Check TASKS.md** - Look for any IN_PROGRESS or BLOCKED tasks from previous sessions
2. **Review recent JOURNAL.md entries** - Scan last 2-3 entries for context
3. **If resuming work**: Load the current task context from TASKS.md before proceeding
---
## GOLDEN RULE — YOU ARE NOT THE PROJECT MANAGER
**NEVER deprioritize, dismiss, or defer any issue the user raises.**
- NEVER say something "isn't critical", "can wait", "is a nice-to-have", or "not needed right now"
- NEVER suggest deferring a fix to a later session or a future opening of the case
- NEVER editorialize about what features or fixes are more or less important
- The user decides what matters. You diagnose and fix what is asked, immediately, without commentary about priority
- You are a tool, not a project manager. No opinions on roadmap, priority, or scheduling
**If a component is broken, diagnose it and fix it. Period.**
---
## GOLDEN RULE — NEVER BLAME HARDWARE FIRST
**When something isn't working, NEVER jump to "hardware issue", "bad wiring", or "damaged component" as a conclusion.**
- The problem is almost always software, configuration, or timing
- Only suggest hardware problems AFTER exhausting all software explanations
- The user built the hardware and knows it works. Trust that.
- Never say "possible hardware issue", "check your wiring", or "component might be damaged" unless the user specifically asks about hardware
- Diagnose software first. Always.
Excerpt 2: templates/CONDUCTOR.md — Journaling Rules and Compaction Rule (verbatim)
CONDUCTOR.md defines the journaling protocol that Claude must follow. The "Compaction Rule" is a built-in context management strategy:
## Continuous Engineering Journal <!-- do not remove -->
Claude, keep an ever-growing changelog in [`JOURNAL.md`](JOURNAL.md).
### What to Journal
- **Major changes**: New features, significant refactors, API changes
- **Bug fixes**: What broke, why, and how it was fixed
- **Frustration points**: Problems that took multiple attempts to solve
- **Design decisions**: Why we chose one approach over another
- **Performance improvements**: Before/after metrics
- **User feedback**: Notable issues or requests
- **Learning moments**: New techniques or patterns discovered
### Journal Format
YYYY-MM-DD HH:MM
[Short Title]
- What: Brief description of the change
- Why: Reason for the change
- How: Technical approach taken
- Issues: Any problems encountered
- Result: Outcome and any metrics
[Short Title] |ERROR:ERR-YYYY-MM-DD-001|
- What: Critical P0/P1 error description
- Why: Root cause analysis
- How: Fix implementation
- Issues: Debugging challenges
- Result: Resolution and prevention measures
[Task Title] |TASK:TASK-YYYY-MM-DD-001|
- What: Task implementation summary
- Why: Part of [Phase Name] phase
- How: Technical approach and key decisions
- Issues: Blockers encountered and resolved
- Result: Task completed, findings documented in ARCHITECTURE.md
### Compaction Rule
When `JOURNAL.md` exceeds **500 lines**:
1. Claude summarizes the oldest half into `JOURNAL_ARCHIVE/<year>-<month>.md`
2. Remaining entries stay in `JOURNAL.md` so the file never grows unbounded
> ⚠️ Claude must NEVER delete raw history—only move & summarize.
Excerpt 3: templates/TASKS.md — Task Context Preservation Template (verbatim)
This template defines the inter-session context handoff format. Each task record is structured to give Claude everything it needs to resume work cold:
# Task Management
## Active Phase
**Phase**: [High-level project phase name]
**Started**: YYYY-MM-DD
**Target**: YYYY-MM-DD
**Progress**: X/Y tasks completed
## Current Task
**Task ID**: TASK-YYYY-MM-DD-NNN
**Title**: [Descriptive task name]
**Status**: PLANNING | IN_PROGRESS | BLOCKED | TESTING | COMPLETE
**Started**: YYYY-MM-DD HH:MM
**Dependencies**: [List task IDs this depends on]
### Task Context
<!-- Critical information needed to resume this task -->
- **Previous Work**: [Link to related tasks/PRs]
- **Key Files**: [Primary files being modified with line ranges]
- **Environment**: [Specific config/versions if relevant]
- **Next Steps**: [Immediate actions when resuming]
### Findings & Decisions
- **FINDING-001**: [Discovery that affects approach]
- **DECISION-001**: [Technical choice made] → Link to ARCHITECTURE.md
- **BLOCKER-001**: [Issue preventing progress] → Link to resolution
### Task Chain
1. ✅ [Completed prerequisite task] (TASK-YYYY-MM-DD-001)
2. 🔄 [Current task] (CURRENT)
3. ⏳ [Next planned task]
4. ⏳ [Future task in phase]
Excerpt 4: Next-Steps Setup Prompts (verbatim from README)
These are the suggested prompts the user pastes into Claude Code after running the CLI — demonstrating Claude Conductor's "scaffold then prompt" pattern:
Quick Setup prompt:
"Please review this codebase and update the CLAUDE.md and CONDUCTOR.md files with the actual project details. Also perform a security health check and list any potential vulnerabilities or concerns (like exposed .env files, API keys in code, missing .gitignore entries, outdated dependencies with known vulnerabilities, or insecure configurations) - just list them as warnings, don't fix anything."
Comprehensive Setup prompt:
"Please thoroughly review this codebase, update CLAUDE.md with project context, and use CONDUCTOR.md as a guide to fill out all the documentation files. Also check for any syntax errors, bugs, or suggestions for improvement. Additionally, perform a comprehensive security health check and list any potential vulnerabilities or concerns (like exposed .env files, API keys in code, missing .gitignore entries, outdated dependencies with known vulnerabilities, insecure configurations, or other security best practice violations) - just list them as warnings, don't fix anything."
Excerpt 5: templates/ERRORS.md — P0/P1 Error Ledger Structure (verbatim)
# Critical Error Ledger <!-- auto-maintained -->
## Schema
| ID | First seen | Status | Severity | Affected area | Link to fix |
|----|------------|--------|----------|---------------|-------------|
## Active Errors
[New errors added here, newest first]
## Resolved Errors
[Moved here when fixed, with links to fixes]
---
## Error Severity Definitions
### P0 - Critical (System Down)
- Complete service outage
- Data loss or corruption
- Security breach
- Payment system failure
### P1 - Major (Degraded Service)
- Core functionality broken
- Significant performance issues
- Authentication failures
- Data sync problems
Prompting Technique Summary
Claude Conductor uses three distinct prompting patterns:
Directive constraints with "NEVER" — Hard prohibitions in GOLDEN RULE sections prevent Claude from making autonomous priority decisions or blaming hardware. These are unconditional bans, not preferences.
Structured tagging protocol — Journal entries embed machine-parseable tags (|ERROR:ERR-ID|, |TASK:TASK-ID|) that allow Claude to cross-reference documentation files without ambiguity, enabling reliable context recovery in future sessions.
Session startup checklist — Rather than relying on Claude to remember context, the CLAUDE.md template instructs Claude to perform an explicit three-step state check at the start of every session (TASKS.md → JOURNAL.md → resume), making context recovery a mandatory procedure.