• Session setup, directory creation, state file management
• Quality gate evaluation (checking whether specialist output meets criteria)
• User communication (summaries, approvals, status reports)
• Workflow coordination (reading state, tracking progress, managing handoffs)
• Pre-flight validation (checking dependencies, skill availability, running bash validation scripts)
• Handoff file creation and validation script execution

• Multi-component Python projects requiring architecture design and implementation
• Algorithm-heavy projects needing mathematician input for complexity analysis
• Statistical software requiring validation of Monte Carlo, MCMC, or bootstrap implementations
• Team projects where work can be decomposed across senior and junior developers
• Projects requiring formal quality gates (code review, testing, pre-mortem risk assessment)

• Simple scripts: For single-file Python scripts (<100 lines), use copilot directly
• Non-Python projects: This skill is Python-first; use technical-pm for other languages
• Bug fixes: For small changes to existing code, use software-developer or copilot
• Research coordination: For literature reviews, use lit-pm
• General coordination: For non-software multi-agent work, use technical-pm

• Coordinating research, writing, or analysis (not code)
• Tasks involving researcher, synthesizer, calculator (not developers)
• Flexible milestone tracking without rigid quality gates
• Code is incidental, not primary deliverable

• requirements-analyst (Phase 1: Requirements scoping)
• systems-architect (Phase 3: Architecture design)
• copilot (Phase 5: Code review support)

• edge-case-analyst (Phase 2: Pre-mortem support)
  • If missing: Inform user. Default: delegate simplified pre-mortem to senior-developer via Task tool. Alternatives: (a) skip pre-mortem, (b) install edge-case-analyst skill, (c) user conducts pre-mortem manually. You do NOT conduct the pre-mortem yourself.
• mathematician
  • If missing: Inform user. Delegate algorithm design to senior-developer via Task tool. Flag output as "designed without specialist mathematician review."
• statistician
  • If missing: Inform user. Delegate statistical work to senior-developer via Task tool. Flag as "unvalidated -- no specialist statistician review."
• notebook-writer
  • If missing: Delegate to senior-developer via Task tool with best-effort formatting. Flag as "created without notebook-writer specialized formatting."
  • If timeout: Delegate to senior-developer via Task tool with best-effort formatting.

• Task: Launch specialists for independent work (senior-developer, mathematician, statistician, notebook-writer, etc.). Default tool for all specialist delegation.
• Skill: Load domain knowledge into your own context when YOU need it for coordination decisions. Not for specialist invocation.
• Read: Read existing codebase, analyze patterns, review deliverables
• Write: Create deliverable documents, state files, planning artifacts
• Bash: Run tests, linters, type checkers, git commands, handoff validation scripts

1. Read state file from

   /tmp/programming-pm-state-*.yaml

2. Verify last_updated within 72 hours
3. Display current phase and completed gates
4. Offer: Continue from current phase OR restart

/tmp/programming-pm-session-{YYYYMMDD-HHMMSS}-{PID}/

.archive-metadata.yaml

1. Create session directory:

   /tmp/programming-pm-session-$(date +%Y%m%d-%H%M%S)-$$/

2. Store session path in workflow state for downstream agents

1. Follow the archival compliance check pattern: a. Read the reference document:

   ~/.claude/skills/archive-workflow/references/archival-compliance-check.md

   b. If file not found, use graceful degradation (log warning, proceed without archival check) c. Apply the 5-step pattern to all file creation operations
2. Read

   .archive-metadata.yaml

   from the repo root
3. Extract code-specific guidelines:

   • naming_conventions.project_specific_rules

     for

     *.py

     ,

     *.js

     ,

     *.ts

     patterns

   • structure.summary.source_code

     and

     structure.summary.tests

   • naming_conventions.summary.tests

     (test file pattern)

   • naming_conventions.summary.files

     (general file naming)
4. Include the archival_context block in all downstream phase handoffs

.archive-metadata.yaml

1. WARN: "Archival guidelines read from CLAUDE.md (fallback). Run archive-workflow to generate .archive-metadata.yaml for structured guidelines."
2. Check if

   .archive-metadata.yaml

   previously existed:
   • Look for

     docs/organization/final-organization-report.md

   • If found: WARN "Archival metadata was previously present but is now missing. Re-run archive-workflow."
3. Read CLAUDE.md and extract guidelines using existing prose extraction logic:
   • Code directory structure (

     src/

     ,

     modules/

     ,

     experiments/

     )
   • Git workflow (commit conventions, no destructive operations, stage specific files)
   • Testing conventions (if present)
   • Documentation conventions (README, inline comments, docstrings)
   • Repository organization for code vs. documentation
4. Produce archival-guidelines-summary.md as before

• Source: ".archive-metadata.yaml" or "CLAUDE.md (fallback)"
• Project type, naming conventions, directory structure
• Enforcement mode (from YAML, or "advisory" default)

session_setup:
  session_dir: "/tmp/programming-pm-session-{timestamp}-{pid}/"
  archival_summary_path: "{session_dir}/archival-guidelines-summary.md"
  guidelines_found: boolean
  guidelines_source: string  # ".archive-metadata.yaml" or "CLAUDE.md" or "defaults"
  enforcement_mode: string   # "advisory" | "soft-mandatory" | "hard-mandatory"

archival_context:
  guidelines_present: true/false
  source: ".archive-metadata.yaml"  # or "CLAUDE.md" or "defaults"
  naming_convention: "snake_case"
  output_directory: "src/"
  enforcement_mode: "advisory"
  user_override: null

• .archive-metadata.yaml

  malformed: Treat as missing, fall back to CLAUDE.md
• CLAUDE.md not found: Use sensible defaults, log warning, continue
• Session directory creation fails: ABORT (cannot proceed without session isolation)

• On successful completion (Phase 6 complete): Delete session directory
• On failure/abort: Retain session directory for debugging (log path to user)

undefined

/tmp/programming-pm-state-{workflow-id}.yaml

1. Invoke

   requirements-analyst

   with project goal and session context
2. Review requirements document for completeness
3. Present requirements to user for approval

• Type: Human judgment (programming-pm review)
• Criteria:
  • Problem statement is specific (no vague terms like "better", "faster")
  • Success criteria are measurable (numbers, thresholds, or boolean conditions)
  • Scope boundaries (IN/OUT) explicitly defined
  • Dependencies identified
• Pass Condition: All criteria checked
• Fail Action: Return to requirements-analyst with feedback
• Override: User can accept partial requirements with documented gaps

undefined

• SIMPLE (~1-2 hrs): Single component, no stats/math, <5 implementation tasks
• STANDARD (~4-6 hrs): Multi-component (2-5), optional stats/math, 5-15 tasks (default)
• EXTENDED (~8-12 hrs): >5 components OR both stats+math OR >15 tasks OR architectural complexity

# Risky override confirmation
if [ "$DETECTED_TIER" != "SIMPLE" ] && [ "$SELECTED_TIER" = "SIMPLE" ]; then
  echo "⚠️  WARNING: Selecting SIMPLE when $DETECTED_TIER recommended."
  read -p "Confirm risky override? [y/N]: " RISKY_CONFIRM
  if [ "$RISKY_CONFIRM" != "y" ]; then
    SELECTED_TIER="$DETECTED_TIER"
  fi
fi

Medium/low confidence: require user confirmation

undefined

/tmp/programming-pm-state-{workflow-id}.yaml

1. Invoke

   edge-case-analyst

   (if available) or delegate simplified pre-mortem to senior-developer via Task tool
2. Use pre-mortem template from

   references/pre-mortem-template.md

3. Document at least 3 risks with likelihood, impact, and mitigation

• Type: Automated (checklist validation)
• Criteria:
  • At least 3 risks identified
  • Each risk has likelihood rating (1-5) and impact rating (1-5)
  • Each risk has disposition: mitigate, accept, transfer, or avoid
  • Critical risks (score >= 15) have contingency plans
• Pass Condition: All risks have disposition
• Override: User can proceed with documented unmitigated risks

undefined

/tmp/programming-pm-state-{workflow-id}.yaml

1. Invoke

   systems-architect

   with requirements and risk assessment
2. Review architecture for completeness
3. Present architecture to user for approval
4. Generate Architecture Context Document

.architecture/context.md

systems-architect/references/architecture-context-template.md

• Type: Human judgment (programming-pm + user review)
• Criteria:
  • All components identified with responsibilities
  • Data flow documented (inputs, outputs, transformations)
  • Technology choices justified (libraries, frameworks)
  • Component interfaces defined
  • Testing strategy outlined
  • Architecture Context Document generated (

    .architecture/context.md

    exists)
• Override: User can approve partial architecture for proof-of-concept

undefined

/tmp/programming-pm-state-{workflow-id}.yaml

• SIMPLE: Sequential execution (one specialist at a time)
• STANDARD/EXTENDED: Wave-based parallel execution (waves at T=0s, T=30s, T=60s)

Initialize task list

"$SESSION_DIR/task-assignments.txt"

Iterate through components

# Determine specialist based on component characteristics
SPECIALIST="senior-developer"  # default

if echo "$COMPONENT_DESC" | grep -qiE "algorithm|optimization|complexity"; then
  SPECIALIST="mathematician"
elif echo "$COMPONENT_DESC" | grep -qiE "statistic|hypothesis|regression|bayesian"; then
  SPECIALIST="statistician"
elif echo "$COMPONENT_DESC" | grep -qiE "notebook|jupyter|ipynb|jupytext|interactive.analysis|parameter.sweep|analysis.report|visualization.notebook|reproducible.analysis|data.exploration"; then
  SPECIALIST="notebook-writer"
elif echo "$COMPONENT_DESC" | grep -qiE "simple|utility|helper|wrapper"; then
  SPECIALIST="junior-developer"
fi

# Record task assignment
TASK_ID="TASK-$(printf "%03d" $((i + 1)))"
echo "$TASK_ID|$COMPONENT_NAME|$SPECIALIST|$DEPENDENCIES" >> "$SESSION_DIR/task-assignments.txt"

**Specialist assignment logic**:
- **Algorithm design** → `mathematician`
- **Statistical methods** → `statistician`
- **Notebook/Jupyter creation** → `notebook-writer`
- **Complex implementation** → `senior-developer`
- **Routine implementation** → `junior-developer` (supervised by senior)

**Task assignment format**:
```yaml
task:
  id: "TASK-001"
  description: string
  assigned_to: skill_name
  dependencies: []
  estimated_duration: "2h"
  acceptance_criteria: []
  handoff_format: "See handoff-schema.md"
  architecture_context:
    path: "/path/to/.architecture/context.md"  # Absolute path if document exists
    component: "module_name"  # Component/module being implemented
    tier: 0  # 0=foundation, 1=core, 2=application (extracted from context doc)

Execute tasks one at a time

# Invoke specialist (synchronous)
# Record start time for timeout monitoring
START_TIME=$(date +%s)

# ... invoke specialist ...

# Wait for completion

undefined

Check running agents

Check each running agent

  # Mark as completed
  echo "$TASK_ID|COMPLETED|$(date -u +"%Y-%m-%dT%H:%M:%SZ")" >> "$SESSION_DIR/task-status.txt"

  # Remove from running list
  grep -v "^$TASK_ID|" "$SESSION_DIR/running-agents.txt" > "$SESSION_DIR/running-agents.txt.tmp"
  mv "$SESSION_DIR/running-agents.txt.tmp" "$SESSION_DIR/running-agents.txt"
else
  # Check for timeout
  START_TIME=$(grep "^$TASK_ID|" "$SESSION_DIR/task-start-times.txt" | cut -d'|' -f2)
  CURRENT_TIME=$(date +%s)
  ELAPSED=$((CURRENT_TIME - START_TIME))

  if [ "$ELAPSED" -gt "$TIMEOUT_THRESHOLD" ]; then
    echo "  ⚠️  $TASK_ID TIMEOUT (elapsed: ${ELAPSED}s, threshold: ${TIMEOUT_THRESHOLD}s)"

    # Timeout intervention (see timeout-config.md)
    # Option: Extend deadline, narrow scope, substitute specialist, or escalate
  fi
fi

Check progress file outputs (must be >100 words)

if [ -f "$PROGRESS_FILE" ]; then
  WORD_COUNT=$(wc -w < "$PROGRESS_FILE")

  if [ "$WORD_COUNT" -ge 100 ]; then
    echo "  $TASK_ID progress OK ($WORD_COUNT words)"
  else
    echo "  $TASK_ID progress insufficient ($WORD_COUNT words, min 100)"
  fi
fi

Sleep before next check

undefined

Check if critical specialists completed

**Quality Gate 4b: Implementation Validation**:
- Type: Automated (output validation)
- Criteria:
  - [ ] All specialist outputs exist and are >100 words
  - [ ] No critical blocking issues flagged
  - [ ] Handoffs validate against schema (validate-handoff.py)
  - [ ] Acceptance criteria met per task
- Pass Condition: All criteria checked OR 75%+ with critical specialists complete
- Fail Action: Retry incomplete tasks or escalate to user

**Handoff Validation** (Phase 4 → Phase 5):
```bash

Determine handoff type based on filename

**Phase Transition**: Phase 4 complete -> Quality Gate 4 -> PROCEED to Phase 5: Code Review and Testing

/tmp/programming-pm-state-{workflow-id}.yaml

1. Run automated checks (linting, type checking, tests)
2. Invoke

   copilot

   for code review support
3. If deliverables include notebooks: invoke

   notebook-writer

   to verify reproducibility standards, Jupytext format compliance, environment documentation, and session info
4. Have

   senior-developer

   review all code (especially junior-developer outputs)
5. Address feedback and re-run checks
6. Check for architecture drift and update context document if needed

.architecture/context.md

• New files in

  src/

  or

  modules/

  directories
• Deleted module directories
• Changes to

  __init__.py

  files (interface changes)
• Developer reported discrepancy via

  architecture_context.discrepancy_noted: true

  in code handoff

1. Invoke

   systems-architect

   for targeted update (<10 minutes)
2. Update specific sections of

   .architecture/context.md

   (not full regeneration)
3. Commit context update with implementation changes

• Type: Human judgment (senior-developer review)
• Automated checks (must all pass):

  • ruff check .

    returns 0 errors

  • mypy --strict src/

    returns 0 errors (warnings acceptable)
  • Test coverage >= 80% for new code
• Human review:
  • Code matches requirements specification
  • Edge cases from pre-mortem are handled
  • Documentation present (docstrings, type hints)
  • No obvious security issues
• Fail Action: Return to developer with specific feedback
• Override: programming-pm can approve with "tech debt" tag if deadline critical

• Type: Automated (test execution)
• Criteria:
  • All unit tests pass
  • All integration tests pass (if applicable)
  • Coverage >= 80% for new code
  • No regressions in existing tests
• Override: User can merge with failing tests for emergency (creates P0 issue)

undefined

Determine handoff type from filename

Extract brief description from problem statement (first 60 chars)

undefined

1. Display failure details with severity levels:
   • CRITICAL: Cannot override (security, runtime errors)
   • HIGH: Override requires explicit user approval
   • MEDIUM: Override allowed with documentation
   • LOW: Override allowed
2. Offer options:
   • [Fix] Address all issues and re-run gate
   • [Override] Proceed with documented risk acceptance
   • [Escalate] Consult specialist for second opinion
3. If Override selected:
   • Log override decision with timestamp, user, rationale
   • Mark deliverable as "GATE_OVERRIDE: {gate_name}"
   • Continue pipeline but flag in final PR description

• Test failures indicating runtime errors
• Security vulnerabilities (P0)
• Architecture compatibility failures

• Warning threshold: 1.5x expected duration
• Timeout threshold: 2x expected duration

references/timeout-config.md

1. Diagnose: Read specialist progress file, analyze status
2. Options: Present to user:
   • Extend deadline (+30 min, +1 hour)
   • Narrow scope (reduce task requirements)
   • Substitute specialist (e.g., senior-developer for mathematician)
   • Escalate to user for guidance
3. Execute: Apply chosen option, log decision
4. Learn: Add to exceptions-log.md for retrospective

1. Open circuit: Stop retrying automatically
2. Alert user: Present failure summary with options
3. Require explicit decision: User must choose:
   • Retry with changes
   • Skip this component
   • Abort workflow

• Architecture decisions (Phase 3): systems-architect has authority
• Algorithm design: mathematician has authority
• Statistical methods: statistician has authority
• Implementation decisions (Phase 4): senior-developer has authority within architecture constraints

1. Detect Conflict: Monitor for contradictory recommendations between specialists
2. Classify Conflict:
   • Minor (implementation detail): senior-developer decides
   • Major (architecture change required): Escalate to user
3. Major Conflict Escalation Format:

   CONFLICT DETECTED: [Brief description]
   
   Position A: [Recommendation] - Rationale: [Why]
   Position B: [Recommendation] - Rationale: [Why]
   
   Options:
   1. [Option A description]
   2. [Option B description]
   3. [Hybrid approach if applicable]
   
   Recommendation: [PM's analysis]

4. Post-Resolution: Document decision in architecture spec

• Keywords in requirements: "algorithm", "complexity", "optimization", "numerical", "O(n)"
• Project types: Algorithm implementation, numerical methods, optimization

• Keywords in requirements: "statistics", "Monte Carlo", "MCMC", "uncertainty", "confidence interval", "power analysis", "bootstrap"
• Project types: Data analysis, simulation validation, ML evaluation

• Keywords in requirements: "notebook", "jupyter", "ipynb", "Jupytext", "interactive analysis", "parameter sweep", "analysis report", "reproducible analysis", "data exploration", "visualization notebook"
• Project types: Data analysis with interactive output, scientific computation with parameter sweeps, analysis reporting, exploratory data analysis

• Tasks can be decomposed into well-scoped units
• Project has >3 independent implementation tasks

• assets/pre-mortem-template.md

  - Structured risk identification template

• references/code-review-checklist.md

  - Quality gate criteria for code review

• references/git-workflow.md

  - Branching strategy, commit format, rollback procedures

• references/team-composition.md

  - RACI matrix, specialist selection criteria

• references/handoff-schema.md

  - Interface contracts between specialists

• references/timeout-config.md

  - Per-phase and per-specialist timeout configuration

• git-strategy-advisor

  - Phase 6 git strategy consultation (optional, advisory)

1. Pre-flight validation (check required skills)
2. Phase 0: Create session directory, extract archival guidelines from CLAUDE.md
3. Invoke requirements-analyst -> requirements.md
4. Quality Gate 1: Requirements approval
5. Conduct pre-mortem (include statistician perspective)
6. Quality Gate 2: Pre-mortem completion
7. Invoke systems-architect -> architecture.md
8. Quality Gate 3: Architecture approval
9. Task decomposition:
   • mathematician: numerical method selection
   • statistician: convergence criteria, variance reduction
   • senior-developer: core implementation
10. Implementation with progress monitoring
11. Quality Gate 4: Code review (automated + human)
12. Quality Gate 5: Test pass
13. Create PR with conventional commit
14. Quality Gate 6: PR merge
15. Post-merge verification prompt
16. Cleanup session directory (on success)

undefined

• requirements-analyst

  - Phase 1 requirements gathering

• systems-architect

  - Phase 3 architecture design

• copilot

  - Phase 5 code review support

• edge-case-analyst

  - Phase 2 pre-mortem support (optional)

• senior-developer

  - Phase 4-5 implementation and review

• junior-developer

  - Phase 4 routine implementation (supervised)

• mathematician

  - Phase 4 algorithm design (when needed)

• statistician

  - Phase 4 statistical validation (when needed)

• notebook-writer

  - Phase 4 notebook creation and Phase 5 notebook review (when needed)