Go

<!-- ⛔⛔⛔ MANDATORY: READ THIS ENTIRE FILE BEFORE ANY ACTION ⛔⛔⛔ -->

⛔ ITP Workflow — STOP AND READ

DO NOT ACT ON ASSUMPTIONS. Read this file first.

This is a structured workflow command. Follow the phases in order.

Your FIRST and ONLY action right now: Execute the TodoWrite below.

Self-Evolving Skill: This skill improves through use. If instructions are wrong, parameters drifted, or a workaround was needed — fix this file immediately, don't defer. Only update for real, reproducible issues.

⛔ MANDATORY FIRST ACTION: Plan-Aware Todo Integration

YOUR FIRST ACTION MUST BE a MERGED TodoWrite that preserves existing todos.

<!-- ADR: 2025-12-05-itp-todo-insertion-merge -->

DO NOT:

• ❌ Overwrite existing todos from plan files or previous sessions
• ❌ Ignore the plan file at ~/.claude/plans/*.md
• ❌ Create your own todos without checking for existing ones
• ❌ Jump to coding without completing Step 0
• ❌ Create a branch before TodoWrite

Follow the full merge strategy (Steps 0.1-0.5) and TodoWrite template: Todo Merge Strategy

After TodoWrite completes, proceed to Preflight section below.

---

Quick Reference

Skills Invoked

File Locations

Spec YAML Frontmatter

---
adr: YYYY-MM-DD-slug # Links to ADR (programmatic)
source: ~/.claude/plans/<adj-verb-noun>.md # Global plan (EPHEMERAL)
implementation-status: in_progress # in_progress | blocked | completed | abandoned
phase: preflight # preflight | phase-1 | phase-2 | phase-3
last-updated: YYYY-MM-DD
---

Note: The source field preserves the global plan filename for traceability, but the file may no longer exist after a new plan is created.

ADR ID Format

ADR_ID="$(date +%Y-%m-%d)-<slug>"

Example: 2025-12-01-clickhouse-aws-ohlcv-ingestion

Folder Structure

/docs/
  adr/
    YYYY-MM-DD-slug.md          # ADR file
  design/
    YYYY-MM-DD-slug/            # Design folder (1:1 with ADR)
      spec.md                   # Active implementation spec (SSoT)

Naming Rule: Use exact same YYYY-MM-DD-slug for both ADR and Design folder.

---

CRITICAL: Mandatory Workflow Execution

THIS WORKFLOW IS NON-NEGOTIABLE. DO NOT SKIP ANY PHASE.

You MUST execute ALL phases in order, regardless of task complexity:

1. Step 0: TodoWrite initialization (FIRST ACTION - NO EXCEPTIONS) 2. Preflight: ADR + Design Spec creation 3. Phase 1: Implementation per spec.md 4. Phase 2: Format & Push 5. Phase 3: Release (if on main/master)

FORBIDDEN BEHAVIORS:

• ❌ Deciding "this is simple, skip the workflow"
• ❌ Jumping directly to implementation without TodoWrite
• ❌ Skipping ADR/Design Spec for "document fixes" or "small changes"
• ❌ Making autonomous judgments to bypass phases

If the task seems too simple for this workflow: Stop and ask the user if they want to proceed without /itp:go. Do NOT silently skip phases.

---

Arguments

Parse $ARGUMENTS for:

Detailed usage examples, branch types, and slug derivation rules: Arguments Reference

---

Workflow Preview

Detect branch and show expected workflow before starting. See Workflow Preview for the branch detection script and condition table.

---

Step 0: Initialize Todo List (ALREADY DONE)

If you followed the STOP instruction at the top, this step is complete.

The TodoWrite template is in the Todo Merge Strategy. If you haven't executed it yet, STOP and go back to the top.

Mark each todo `in_progress` before starting, `completed` when done.

Preflight Gate (MANDATORY)

You CANNOT proceed to Phase 1 until ALL Preflight todos are marked `completed`.

Before starting "Phase 1: Execute implementation tasks":

1. Verify all Preflight: todos show completed 2. Verify ADR file exists at /docs/adr/$ADR_ID.md 3. Verify design spec exists at /docs/design/$ADR_ID/spec.md

If any Preflight item is not complete, STOP and complete it first. Do NOT skip ahead.

---

Preflight: Artifact Setup

MANDATORY Skill tool call: `implement-plan-preflight` -- activate NOW before proceeding.

This skill provides detailed ADR and Design Spec creation instructions (MADR 4.0 frontmatter, perspectives taxonomy, validation).

Preflight Steps (via skill)

1. P.0: Create feature branch FIRST (if -b flag) -- MUST happen before ANY file operations 2. P.1: MANDATORY Skill tool call: `implement-plan-preflight` -- activate NOW for ADR/spec instructions 3. P.2: Create ADR file -- path in Quick Reference 4. P.2.1: ADR Diagram Creation (MANDATORY for ALL ADRs)

ALL ADRs require BOTH diagrams -- NO EXCEPTIONS, regardless of task complexity.

• INVOKE: Skill tool call with `adr-graph-easy-architect` -- triggers diagram workflow
• CREATE: Before/After diagram -- visualizes state change in Context section
• CREATE: Architecture diagram -- visualizes component relationships in Architecture section
• VERIFY: Confirm BOTH diagrams embedded in ADR before proceeding

BLOCKING GATE: Do NOT proceed to P.3 until BOTH diagrams are verified in ADR.

5. P.3: Create design spec -- path in Quick Reference 6. P.4: Verify checkpoint

WHY P.0 FIRST: Files created before git checkout -b stay on main/master. Branch must exist before ADR/spec creation.

Preflight Checkpoint (MANDATORY)

STOP. Verify artifacts exist before proceeding to Phase 1. Full checklist and validator script: Preflight Checkpoint

---

Phase 1: Implementation

1.1 Resumption Protocol

Entry point for both fresh starts and continuations. Full protocol (continuation detection, branch verification, sync checks): Phase 1 Protocols

1.2 Implement the Spec

Execute each task in spec.md:

1. Mark current task as in_progress in todo list 2. Implement the change 3. Verify it works 4. Update spec.md to reflect completion 5. Mark task as completed 6. Move to next task

1.3 Engineering Standards

Skill Execution Order (invoke sequentially, in this order):

1. `impl-standards` -- Apply error handling & constants patterns FIRST 2. `mise-configuration` -- Centralize config via mise [env] SECOND 3. `adr-code-traceability` -- Add ADR references to code THIRD 4. `code-hardcode-audit` -- Final audit LAST (before Phase 2)

MANDATORY Skill tool call: `impl-standards` -- activate NOW for detailed standards.

MANDATORY Skill tool call: `mise-configuration` -- activate when creating/modifying scripts with configurable values.

MANDATORY Skill tool call: `adr-code-traceability` -- activate NOW for ADR references in code.

MANDATORY Skill tool call: `code-hardcode-audit` -- activate NOW before release.

1.4 Decision Capture

When implementation requires a user decision, follow the decision capture protocol: Decision Capture

1.5 Status Synchronization Protocol

Spec implementation-status drives ADR status updates. Full sync table and scripts: Status Sync Protocol

Phase 1 Success Criteria

• [ ] Implementation complete per spec.md
• [ ] All artifacts synced (ADR <-> spec <-> todo <-> code)
• [ ] New files include ADR: {adr-id} in file header
• [ ] Non-obvious changes have inline ADR: comments

---

Phase 2: Format & Push

Execute Prettier formatting, git push, and browser open. Full scripts: Phase 2 Scripts

Phase 2 Success Criteria

• [ ] Markdown formatted with Prettier
• [ ] Pushed to GitHub
• [ ] Files viewable in browser

---

Phase 3: Release & Publish (Requires -r or -p Flag on Main)

Phase 3 requires EXPLICIT flags. It does NOT run automatically.

For entry gate logic and branch-specific messaging, see Phase 3 Gate Logic.

3.1 Pre-Release Verification

Before releasing:

• [ ] All Success Criteria items in design spec are checked off
• [ ] Status value in design spec is updated (e.g., Accepted, Implemented)
• [ ] ADR and spec.md are in sync with final implementation
• [ ] Version fields use semantic-release patterns (no dynamic versioning)

3.2 Semantic Release (if -r flag)

Condition: Only execute if -r or --release flag was provided.

MANDATORY Skill tool call: `semantic-release` -- activate NOW for version tagging and release.

• Follow the Local Release Workflow
• Conventional commits -> tag -> release -> changelog -> push

3.3 PyPI Publishing (if -p flag)

Condition: Only execute if -p or --publish flag was provided.

Only if package pre-exists on PyPI:

• MANDATORY Skill tool call: `pypi-doppler` -- activate NOW to publish

3.4 Earthly Pipeline

Use Earthly as canonical pipeline: non-blocking, observability-first, ensure GitHub Release exists, record stats/errors, Pushover alert, wire into GitHub Actions.

Phase 3 Success Criteria

• [ ] ADR status updated to accepted or implemented
• [ ] Release completed via semantic-release
• [ ] If feature branch: PR created, Phase 3 skipped

---

Troubleshooting

Post-Execution Reflection

After this skill completes, reflect before closing the task:

0. Locate yourself. — Find this SKILL.md's canonical path (Glob for this skill's name) before editing. All corrections target THIS file and its sibling references/ — never other documentation. 1. What failed? — Fix the instruction that caused it. If it could recur, add it as an anti-pattern. 2. What worked better than expected? — Promote it to recommended practice. Document why. 3. What drifted? — Any script, reference, or external dependency that no longer matches reality gets fixed now. 4. Log it. — Every change gets an evolution-log entry with trigger, fix, and evidence.

Do NOT defer. The next invocation inherits whatever you leave behind.

Skill: ITP Go Workflow

Arguments Reference

Usage Examples

# Fresh start modes (no release)
/itp:go                   # Derive slug, stay on current branch
/itp:go my-feature        # Custom slug, stay on current branch
/itp:go -b                # Derive slug, create {type}/{adr-id} branch
/itp:go my-feature -b     # Custom slug, create {type}/{adr-id} branch

# Feature branch with release intent (reminder shown, Phase 3 skips)
/itp:go my-feature -b -r        # Intent to release after merge
/itp:go my-feature -b -r -p     # Intent to release + publish after merge

# Release modes (on main/master only)
/itp:go -r                # On main: run semantic-release only
/itp:go -p                # On main: run PyPI publish only
/itp:go -r -p             # On main: full release + publish

# Continuation modes
/itp:go -c                # Continue: auto-detect ADR, resume
/itp:go -c "use Redis"    # Continue with explicit decision

Mode Selection

• Fresh start: [slug] [-b] -- creates new ADR
• Continuation: -c [decision] -- resumes existing ADR

These modes are mutually exclusive. -c cannot be combined with slug or -b.

Branch Type

Determine {type} from ADR nature (conventional commits):

Slug Derivation

If no slug is provided, derive an appropriate kebab-case slug from the Global Plan's context (the feature/task being implemented). The slug should be descriptive (3-5 words) and capture the essence of the feature.

Word Economy Rule: Each word in the slug MUST convey unique meaning. Avoid redundancy.

ADR ID in Branch, ADR, Design, and Code

The ADR ID (YYYY-MM-DD-slug) is the canonical identifier used in:

• ADR file, Design folder, Code references, Branch name (if -b)

Evolution Log

Convention: Reverse chronological order (newest on top, oldest at bottom). Prepend new entries.

---

2026-02-26: Initial Evolution Log

Status: Skill is in use and maintained. Track improvements here.

Purpose

This evolution log tracks updates to the skill. Each entry should note:

• What changed (content, structure, tooling)
• Why it changed (bug fix, feature request, best practice)
• Files affected

How to Use

1. When updating SKILL.md or references, add an entry here with the date 2. Keep entries reverse-chronological (newest first) 3. Link to ADRs or GitHub issues when relevant 4. Reference specific line changes when helpful

---

Skill: ITP Go Workflow

Phase 1 Protocols

1.1 Resumption Protocol

Entry point for both fresh starts and continuations.

1. Detect mode:

• If -c flag: continuation mode (skip to step 2)
• Otherwise: fresh start (skip to step 3)

2. For continuation (`-c`):

a. Find in-progress ADR:

• Search docs/design/*/spec.md for status: in_progress
• Or find todo list item marked in_progress

b. Re-read spec.md and check for pending decision:

• Look for ## Pending Decision section
• If found AND -c "decision" provided: apply decision, remove pending marker
• If found AND -c alone: use last "Recommended Next Steps" as default action
• If no pending decision: proceed to step c

c. Check todo list for current task:

• Find task with status: in_progress
• Resume implementation from that task

d. Verify branch matches ADR context:

• Check current branch: git branch --show-current
• If ADR was created on a feature branch, verify you're on that branch
• If branch mismatch detected, warn user before proceeding

3. Sync check (both modes):

• Re-read and update the design spec
• Verify: ADR <-> Design Spec <-> Todo <-> Code alignment
• Report any drift before proceeding

1.4 Decision Capture

When implementation requires a user decision:

1. Update spec.md with pending decision:

   ## Pending Decision

   **Topic**: [What needs to be decided]
   **Options**:

   - A: [Option A description]
   - B: [Option B description]
     **Context**: [Why this decision is needed now]
     **Blocked task**: [Current task waiting on this]

2. Update todo list: Mark current task as blocked: awaiting decision

3. Then ask: Use AskUserQuestion with clear options

4. After answer:

• Remove ## Pending Decision section from spec.md
• Update Decision Log in ADR
• Mark task as in_progress again
• Continue implementation

1.5 Status Synchronization Protocol

Rule: Spec implementation-status drives ADR status updates.

At Phase 1 start (immediately upon entering Phase 1, BEFORE executing first task):

# Update ADR status: proposed -> accepted
sed -i '' 's/^status: proposed/status: accepted/' docs/adr/$ADR_ID.md
# Update spec phase
sed -i '' 's/^phase: preflight/phase: phase-1/' docs/design/$ADR_ID/spec.md

Before Phase 2 (sync checklist):

• [ ] ADR status: accepted
• [ ] Spec implementation-status: in_progress or completed
• [ ] Spec phase: phase-1
• [ ] Spec last-updated: YYYY-MM-DD is current

Skill: ITP Go Workflow

Phase 2 Scripts

2.1 Format Markdown

Run Prettier against ADR and spec:

prettier --write --no-config --parser markdown --prose-wrap preserve \
  docs/adr/$ADR_ID.md \
  docs/design/$ADR_ID/spec.md

2.2 Push to GitHub

/usr/bin/env bash << 'GIT_EOF_2'
git add docs/adr/$ADR_ID.md docs/design/$ADR_ID/
git commit -m "docs: add ADR and design spec for <slug>"

# If --branch was used:
git push -u origin <type>/$ADR_ID

# If working on current branch (default):
git push origin $(git branch --show-current)
GIT_EOF_2

2.3 Open in Browser

/usr/bin/env bash << 'GIT_EOF_3'
# Get repo URL from origin remote (works correctly with forks)
REMOTE_URL=$(git remote get-url origin 2>/dev/null)

if [[ -z "$REMOTE_URL" ]]; then
  echo "Error: No origin remote configured"
  exit 1
fi

# Convert SSH format to HTTPS for browser URLs
# Handles: git@github.com:owner/repo.git
# Handles: git@github.com-username:owner/repo.git (multi-account SSH aliases)
# Handles: https://github.com/owner/repo.git
REPO_URL=$(echo "$REMOTE_URL" | sed -E 's|git@github\.com[^:]*:|https://github.com/|' | sed 's|\.git$||')

BRANCH=$(git branch --show-current)

open "$REPO_URL/blob/$BRANCH/docs/adr/$ADR_ID.md"
open "$REPO_URL/blob/$BRANCH/docs/design/$ADR_ID/spec.md"
GIT_EOF_3

Skill: ITP Go Workflow

Phase 3 Gate Logic

Entry Gate Logic

Parse flags from invocation:

• RELEASE_FLAG: true if -r or --release provided
• PUBLISH_FLAG: true if -p or --publish provided

/usr/bin/env bash << 'PREFLIGHT_EOF_2'
# Check branch
CURRENT_BRANCH=$(git branch --show-current)

# Parse flags
RELEASE_FLAG=false
PUBLISH_FLAG=false
[[ "$ARGUMENTS" =~ -r|--release ]] && RELEASE_FLAG=true
[[ "$ARGUMENTS" =~ -p|--publish ]] && PUBLISH_FLAG=true
PREFLIGHT_EOF_2

Case 1: Feature Branch (not main/master)

if [ "$CURRENT_BRANCH" != "main" ] && [ "$CURRENT_BRANCH" != "master" ]; then
  echo ""
  echo "============================================================="
  if [ "$RELEASE_FLAG" = true ] || [ "$PUBLISH_FLAG" = true ]; then
    # Verbose reminder when flags provided on feature branch
    echo "  PHASE 3 DEFERRED (Feature Branch)"
    echo "============================================================="
    echo ""
    echo "  You provided release/publish flags on a feature branch:"
    [ "$RELEASE_FLAG" = true ] && echo "    -r (release): YES"
    [ "$PUBLISH_FLAG" = true ] && echo "    -p (publish): YES"
    echo ""
    echo "  Current branch: $CURRENT_BRANCH"
    echo ""
    echo "  Phase 3 CANNOT run on feature branches."
    echo "  These flags are recorded as YOUR INTENT for after merge."
    echo ""
    echo "  +-----------------------------------------------------------+"
    echo "  | NEXT STEPS (you must do these manually):                  |"
    echo "  +-----------------------------------------------------------+"
    echo "  | 1. Create PR: gh pr create                                |"
    echo "  | 2. Get approval and merge to main/master                  |"
    echo "  | 3. Switch: git checkout main && git pull                  |"
    [ "$RELEASE_FLAG" = true ] && echo "  | 4. Release: /itp:go -r    # semantic-release             |"
    [ "$PUBLISH_FLAG" = true ] && echo "  | 5. Publish: /itp:go -p    # PyPI publish                 |"
    echo "  |                                                           |"
    echo "  | Or combine: /itp:go -r -p    # for both                   |"
    echo "  +-----------------------------------------------------------+"
    echo ""
    echo "  The release/publish steps will NOT happen automatically."
    echo "  You MUST manually run them after merging to main."
  else
    # Standard feature branch message (no flags)
    echo "  WORKFLOW COMPLETE (Phase 2)"
    echo "============================================================="
    echo ""
    echo "  Current branch: $CURRENT_BRANCH"
    echo "  Phase 3 (Release): SKIPPED - not on main/master"
    echo ""
    echo "  Next steps:"
    echo "    1. Create PR: gh pr create"
    echo "    2. Get approval and merge to main/master"
    echo "    3. Run /itp:go -r on main to release (or /itp:go -r -p for both)"
  fi
  echo ""
  echo "============================================================="
  exit 0
fi

Case 2: Main/Master WITHOUT Flags

if [ "$RELEASE_FLAG" = false ] && [ "$PUBLISH_FLAG" = false ]; then
  echo ""
  echo "============================================================="
  echo "  PHASE 3 SKIPPED (No Flags)"
  echo "============================================================="
  echo ""
  echo "  You are on: $CURRENT_BRANCH"
  echo "  But no release/publish flags were provided."
  echo ""
  echo "  To release this version, run one of:"
  echo "    /itp:go -r       # semantic-release (version + changelog + GitHub)"
  echo "    /itp:go -p       # PyPI publishing (if applicable)"
  echo "    /itp:go -r -p    # both release and publish"
  echo ""
  echo "  Phase 3 requires explicit intent via flags."
  echo ""
  echo "============================================================="
  exit 0
fi

Case 3: Main/Master WITH Flags

Proceed to Phase 3 subsections (3.1 through 3.4) in SKILL.md.

Skill: ITP Go Workflow

Preflight Checkpoint (MANDATORY)

STOP. Verify artifacts exist before proceeding to Phase 1.

Run validator:

/usr/bin/env bash << 'PREFLIGHT_EOF'
# Environment-agnostic path (explicit fallback for marketplace installation)
PLUGIN_DIR="${CLAUDE_PLUGIN_ROOT:-$HOME/.claude/plugins/marketplaces/cc-skills/plugins/itp}"
uv run "$PLUGIN_DIR/skills/implement-plan-preflight/scripts/preflight_validator.py" $ADR_ID
PREFLIGHT_EOF

Or verify manually:

• [ ] ADR file exists at /docs/adr/$ADR_ID.md
• [ ] ADR has YAML frontmatter with all 7 required fields
• [ ] ADR has status: proposed (initial state)
• [ ] ADR has **Design Spec**: link in header
• [ ] DIAGRAM CHECK 1: ADR has Before/After diagram in Context section (graph-easy block showing state change)
• [ ] DIAGRAM CHECK 2: ADR has Architecture diagram in Architecture section (graph-easy block showing components)

DIAGRAM VERIFICATION (BLOCKING): If either diagram is missing, STOP and invoke adr-graph-easy-architect skill again. Search ADR for <!-- graph-easy source: -- you need TWO separate blocks.

• [ ] Design spec exists at /docs/design/$ADR_ID/spec.md
• [ ] Design spec has YAML frontmatter with all 5 required fields
• [ ] Design spec has implementation-status: in_progress
• [ ] Design spec has phase: preflight
• [ ] Design spec has **ADR**: backlink in header
• [ ] Feature branch created (if -b flag specified)

If any item is missing: Complete it now. Do NOT proceed to Phase 1.

Skill: ITP Go Workflow

TodoWrite Merge Strategy

Step 0.1: Check for Existing Plan File

1. Check if a plan file exists in ~/.claude/plans/ 2. If system-reminder mentions a plan file path: use that specific path 3. If plan file exists: Read it and extract any tasks/todos from it

Step 0.2: Check Existing Todos

1. Check your mental model of existing todos (from prior conversation) 2. Note any in_progress or pending items that should be preserved

Step 0.3: Merge Strategy (INTERLEAVE)

Map plan tasks into ITP phases intelligently:

Step 0.4: Conflict Resolution

If a plan task doesn't clearly map to an ITP phase, use AskUserQuestion:

AskUserQuestion with questions:
- question: "Where should '{task_name}' be placed in the ITP workflow?"
  header: "Task placement"
  options:
    - label: "Before Preflight"
      description: "Do this task first, before ADR creation"
    - label: "Phase 1"
      description: "Do during implementation"
    - label: "After Phase 2"
      description: "Do last, before release"
  multiSelect: false

Step 0.5: Create MERGED TodoWrite

After mapping, create a MERGED todo list using these prefixes:

• [Plan] -- Tasks from the plan file
• [ITP] -- ITP workflow tasks

MANDATORY TodoWrite template (MERGE with existing, do NOT overwrite):

TodoWrite with todos (MERGED - preserving existing):

# From plan file (if any) - mapped to Preflight
# Example: "[Plan] Research existing implementation" | pending

# ITP Preflight - Skill tool calls marked explicitly
# CRITICAL: Branch creation MUST be FIRST if -b flag (before any file operations)
- "[ITP] Preflight: Create feature branch (if -b flag) — MUST BE FIRST" | pending
- "[ITP] Preflight: Skill tool call → implement-plan-preflight" | pending
- "[ITP] Preflight: Create ADR file with MADR 4.0 frontmatter" | pending
- "[ITP] Preflight: Skill tool call → adr-graph-easy-architect (Before/After + Architecture diagrams)" | pending
- "[ITP] Preflight: Create design spec with YAML frontmatter" | pending
- "[ITP] Preflight: Verify checkpoint (ADR + spec exist)" | pending

# From plan file (if any) - mapped to Phase 1
# Example: "[Plan] Implement the new feature" | pending

# ITP Phase 1 - Skill tool calls marked explicitly
- "[ITP] Phase 1: Sync ADR status proposed → accepted" | pending
- "[ITP] Phase 1: Skill tool call → impl-standards" | pending
- "[ITP] Phase 1: Skill tool call → mise-configuration (if new scripts)" | pending
- "[ITP] Phase 1: Skill tool call → adr-code-traceability" | pending
- "[ITP] Phase 1: Execute implementation tasks from spec.md" | pending
- "[ITP] Phase 1: Skill tool call → code-hardcode-audit" | pending

# From plan file (if any) - mapped to Phase 2
# Example: "[Plan] Update documentation" | pending

# ITP Phase 2
- "[ITP] Phase 2: Format markdown with Prettier" | pending
- "[ITP] Phase 2: Push to GitHub" | pending
- "[ITP] Phase 2: Open files in browser" | pending

# ITP Phase 3 — REQUIRES -r or -p flag on main/master
- "[ITP] Phase 3: Pre-release verification (if -r or -p on main)" | pending
- "[ITP] Phase 3: Skill tool call → semantic-release (if -r flag on main)" | pending
- "[ITP] Phase 3: Skill tool call → pypi-doppler (if -p flag on main)" | pending
- "[ITP] Phase 3: Final status sync (if -r or -p on main)" | pending

After TodoWrite completes, proceed to Preflight section in SKILL.md.

Skill: ITP Go Workflow

Workflow Preview

Detect branch and show expected workflow before starting.

/usr/bin/env bash << 'GIT_EOF'
CURRENT_BRANCH=$(git branch --show-current)
WILL_BE_ON_MAIN=true

# If -b flag used, will end up on feature branch
if [ -n "$BRANCH_FLAG" ]; then
  WILL_BE_ON_MAIN=false
fi

# If already not on main/master
if [ "$CURRENT_BRANCH" != "main" ] && [ "$CURRENT_BRANCH" != "master" ]; then
  WILL_BE_ON_MAIN=false
fi
GIT_EOF

Show workflow preview based on branch and flags:

Phase 3 now requires explicit flags on main/master. This is a breaking change from previous behavior where Phase 3 ran automatically.