team-shinchan:start

MANDATORY EXECUTION - DO NOT SKIP

When this skill is invoked, execute immediately. Do not explain.

Injected Context (bigproject phase mode)

This skill is normally invoked standalone. It can also be driven by the bigproject phase loop (skills/bigproject/SKILL.md Step 5), which executes these same steps on the main thread with the following inputs already resolved:

• DOC_ID — pre-set to {PROJECT_ID}-phase-{N}. Use it verbatim; do NOT generate one.
• parent_doc_id — the owning {PROJECT_ID}.
• phase_number — the 1-based phase index.
• PHASE_CONTEXT — project title + this phase's title/domain/acceptance criteria +

summaries of completed phases.

When invoked with injected context:

• Skip Step 0 entirely (expiry/archive is the project's concern, run once by bigproject).
• In Step 1, use the injected DOC_ID and write parent_doc_id / phase_number into the

state (see Step 1).

• In Step 2A, pass PHASE_CONTEXT to Misae so the interview is scoped to this phase.

When invoked standalone (no injected context), behave exactly as before.

Step 0: Expire and Archive Stale Workflows

Read workflow_expiry_days from:

1. .shinchan-config.yaml in the current project root (key: workflow_expiry_days) — takes priority
2. Otherwise use the plugin default: 7 (from plugin.json settings)
3. If workflow_expiry_days is 0 or cannot be read → skip expiry entirely

For each .shinchan-docs/*/WORKFLOW_STATE.yaml where status: active:

Expiry check (skip if workflow_expiry_days == 0):

1. Read the updated timestamp from WORKFLOW_STATE.yaml
2. Parse the timestamp (ISO 8601). If parsing fails → skip this entry
3. Calculate elapsed days: (now - updated) / 86400000
4. If elapsed >= workflow_expiry_days:

a. Set status: expired in WORKFLOW_STATE.yaml b. Add event to history: ```yaml

• timestamp: "{ISO now}"

event: auto_expired agent: shinnosuke archived_at: "{ISO now}" archived_reason: auto_expiry `` c. Calculate archive path: .shinchan-docs/archived/{YYYY-MM}/ where YYYY-MM comes from the current date d. Attempt: mkdir -p .shinchan-docs/archived/{YYYY-MM}/ && mv .shinchan-docs/{DOC_ID}/ .shinchan-docs/archived/{YYYY-MM}/{DOC_ID}/ e. If mv fails: silently continue (status stays expired`, folder stays in place) f. Do NOT output any paused/expired notification to the user g. Continue to next workflow

Non-expired active workflows are left as-is. Multiple workflows can be active simultaneously. The workflow guard (workflow-guard.sh) protects the most recently updated active workflow. Use /team-shinchan:resume to switch the guard target to a different workflow.

Step 1: Setup (Folder + State)

1. DOC_ID: If a DOC_ID was injected (bigproject phase mode), use it verbatim and skip generation. Otherwise: if args contains ISSUE-xxx use it; else {branch}-{next_index} from git branch + ls. When computing {next_index}, **ignore directories matching -phase-** — those belong to a bigproject and are not standalone workflows. Truncate + warn if args > 2000 chars.
2. mkdir -p .shinchan-docs/{DOC_ID}
3. Create WORKFLOW_STATE.yaml:

version: 1
doc_id: "{DOC_ID}"
created: "{timestamp}"
updated: "{timestamp}"
current:
  stage: requirements
  phase: null
  owner: misae
  status: active
  answer_mode: human              # /start default — the human answers every AskUserQuestion. `/autopilot` sets this to `proxy` (see "Answer Mode" below + agents/_shared/proxy-user-panel.md). Absent ⇒ human.
  execution_mode: micro-execute   # /start default — pins Stage 3 to the per-task (spec→quality→skeptic) review chain. Set to `dag` ONLY when explicitly opting into parallel dag-executor dispatch.
  # parent_doc_id / phase_number: ONLY when injected by bigproject phase mode; omit standalone.
  # parent_doc_id: "{parent_doc_id}"
  # phase_number: {phase_number}
  interview: { step: 0, collected_count: 0, last_question: null }
  ak_gate:
    requirements:
      status: pending          # pending | in_review | approved | rejected | escalated
      retry_count: 0           # 0, 1, or 2 (max)
      last_rejection_reasons: []  # list of strings — most recent rejection points
    design:
      status: pending
      retry_count: 0
      last_rejection_reasons: []
    planning:
      status: pending
      retry_count: 0
      last_rejection_reasons: []
history:
  - timestamp: "{timestamp}"
    event: workflow_started
    agent: shinnosuke

History entry format for AK review (appended after each AK review):

- timestamp: "{ISO timestamp}"
  event: ak_review
  agent: action_kamen
  stage: requirements          # or planning
  verdict: REJECTED            # or APPROVED
  retry_count: 0               # which attempt this was (0 = first, 1 = first retry, 2 = second retry)
  rejection_reasons:
    - "Problem Statement lacks quantified success metrics"
    - "FR coverage missing error-handling scenarios"

ak_gate schema notes:

- status values: pending (not yet reviewed) | in_review (AK review in progress) | approved (AK approved) | rejected (AK rejected, retries remaining) | escalated (max retries reached, waiting for user)

- retry_count persists across session restarts (NFR-2: session-restart safe)

- Existing workflows without ak_gate field continue to function (backwards-compatible)

Stage rules and transition gates are defined in CLAUDE.md and hooks/workflow-guard.md.

1. Linear Sync — START (In Progress). If this is a standalone invocation

(NOT bigproject phase mode — i.e. no injected parent_doc_id), run the START → In Progress transition per agents/_shared/linear-sync.md: detect a Linear issue in args/DOC_ID/branch, confirm it with get_issue, and if real move it to In Progress and persist it to current.linear_issue in WORKFLOW_STATE.yaml. When invoked with injected bigproject phase context, skip this — the parent project owns the issue lifecycle. No-op if no Linear issue / Linear MCP unavailable.

Answer Mode — human (default) vs proxy (autopilot)

Read current.answer_mode from WORKFLOW_STATE.yaml (absent ⇒ human). It controls who answers every AskUserQuestion this skill raises — the requirements interview questions (2A.1), the REQUESTS approval (2A.3), the design decisions (2B.1), and the DESIGN approval (2B.3):

• human (default) — behave exactly as written below: call AskUserQuestion and

wait for the user.

• proxy (set by /autopilot) — do NOT call AskUserQuestion. Instead route the

identical {question, options, header, context_hint} through the proxy-user panel (agents/_shared/proxy-user-panel.md): a K=3 diverse panel votes, a cautious judge breaks ties, and the winning option is used as if the user had picked it. Append a proxy_answer history entry per that spec. Everything else in the flow — Misae's clarity gate, Hiroshi's design-completeness gate, the materiality/closure re-entry loops, and every Action Kamen review — runs unchanged. Proxy mode replaces the human at the seam, nothing before it.

ROUTING RULE: wherever a step below calls AskUserQuestion(...), that call is

answer_mode-aware. Under proxy, substitute a proxy-user-panel selection over the

same options and continue with the returned choice. This applies to 2A.1, 2A.3, 2B.1,

and 2B.3. (Options-overflow pagination is a human-UI concern and is skipped under

proxy — the panel sees the full options[] at once.)

ESCALATION UNDER PROXY: the 3-way ESCALATE prompts (2A.1b / 2B.1b) must never

block autopilot on a human. Under proxy, do NOT call AskUserQuestion there —

auto-select B (Open Questions로 기록 후 진행): record the unresolved items and move

on. This is the hands-off, non-destructive default (A risks looping to hard_cap, C

discards prior answers). Log it as a