team-shinchan:micro-execute

Micro-Execute: Subagent-Driven Development

Break implementation into 2-3 minute micro-tasks. Each task gets a fresh subagent + two-stage review (spec compliance → code quality). No context pollution between tasks.

Step 1: Validate Input

If args is empty:
  Check for active WORKFLOW_STATE.yaml in .shinchan-docs/
  If found → use PROGRESS.md as plan source
  If not found → Ask: "Which plan file should I execute? (path to PROGRESS.md or plan file)"
  STOP and wait

If args is a file path:
  plan_source = args

If args is a task description:
  Generate micro-task plan inline (see Step 2)

Rubric Override Detection

After parsing args, check for a rubric: field (YAML-style or as part of a plan file frontmatter):

If args contains a `rubric:` field:
  rubric_override = parsed rubric definition
  Announce: "Custom rubric detected: {rubric_override item names}"
Else:
  rubric_override = null  (Action Kamen uses default 3-item rubric)

Step 1.5: Linear Sync (standalone only)

If this skill was invoked standalone (a direct task description, NOT as Stage 3 of an active /start/autopilot workflow — i.e. there is no owning WORKFLOW_STATE.yaml whose current.stage is execution), apply agents/_shared/linear-sync.md:

• START → In Progress now, before execution begins.
• FINISH → In Review after all micro-tasks are complete and verified (Action Kamen

final pass), at the very end of Step 3.

When driven inside a workflow, do NOT transition here — the workflow owns the issue lifecycle (shinnosuke.md Stage 4 handles FINISH). No-op if no Linear issue / Linear MCP unavailable.

Step 2: Parse or Generate Micro-Task Plan

If plan_source exists (PROGRESS.md or plan file):

Read the plan and extract all phases. For each phase, break into micro-tasks:

Each micro-task MUST have:
- Title (what to do in 2-3 minutes)
- Files: Create/Modify/Test (exact paths)
- Steps: 2-5 concrete steps
- Verification: command + expected output

If no plan exists (args is a task description):

Task(subagent_type="team-shinchan:nene", model="opus",
  prompt=`Create a MICRO-TASK PLAN for the following request.

## Micro-Task Plan Format

Break the work into tasks that each take 2-3 minutes. Each task MUST follow this format:

### Task N: [Component Name]

**Files:**
- Create: exact/path/to/file
- Modify: exact/path/to/existing.py:line_range
- Test: tests/exact/path/to/test.py

**Step 1: [Action]**
[Complete code or exact instructions]

**Step 2: Verify**
Run: [exact command]
Expected: [exact expected output or behavior]

**Step 3: Commit** (optional)
git add [files] && git commit -m "[message]"

## Rules
- Each task is ONE focused change (2-3 minutes of work)
- Exact file paths always (no "add a file somewhere")
- Complete code in plan (not "add validation" but the actual code)
- Exact verification commands with expected output
- Assume the implementer has NO project context
- Order tasks by dependency (later tasks may depend on earlier ones)

User request: ${args}`)

Store result as {micro_plan}.

Step 2.5: Score Complexity (Annotation Only — Implementer Runs on Opus)

The implementer is the only agent that writes code, so under the quality-first default it ALWAYS runs on opus — the strongest model raises the floor of every diff before review. collaboration-score.js is still run, but only as an informational complexity annotation (telemetry + planning insight), NOT to down-route the model.

For EACH micro-task in the plan:

score_result = node ${CLAUDE_PLUGIN_ROOT}/src/collaboration-score.js \
  --task "{task.title}" \
  --files {len(task.files)} \
  --domains {task.domain_count || 1}

Parse JSON output → output.score, output.mode  (complexity annotation only)
task.complexity = output.score
task.model = 'opus'    // quality-first: implementer always strongest; never down-routed

The model_tier field is intentionally ignored for routing. Down-routing to haiku/sonnet to save tokens is exactly the cost lever the quality-first default rejects. The only model movement is upward — and the implementer is already at the ceiling.

After scoring all tasks, announce the plan:

Task plan (all implementers on opus):
  Task 1: {title} → opus (complexity: {score})
  Task 2: {title} → opus (complexity: {score})
  ...

Step 3: Execute Micro-Tasks

For EACH micro-task, sequentially (never parallel for implementation):

3a. Dispatch Implementer

Task(
  subagent_type="team-shinchan:{domain_agent}",  // Bo | Aichan | Buriburi | Masao
  model="{task.model}",  // always 'opus' (quality-first default; set in Step 2.5)
  prompt=`You are implementing a SINGLE micro-task.

## Prompt Template
// See: ${CLAUDE_PLUGIN_ROOT}/agents/_shared/micro-task-prompts/implementer-prompt.md

## Your Task
${task_description}

## Files
${file_list}

## Context
- Project: ${project_context}
- Completed tasks: ${completed_tasks_summary}

## Protocol
1. Read ALL listed files first
2. State what you will change (1-2 sentences)
3. Implement EXACTLY what is specified
4. Run verification command
5. Self-review: Did I implement exactly what was asked?
6. Report: changes, verification result, concerns

## Iron Law
NO COMPLETION CLAIMS WITHOUT RUNNING THE VERIFICATION COMMAND.

## Anti-Rationalizations
- "Test is trivial, skip it" → Run it anyway
- "I'll also fix this nearby issue" → Out of scope
- "This approach is better" → Follow the spec, raise concerns`)

Store result as {implementer_report}.

3b. Dispatch Spec Reviewer

Task(
  subagent_type="team-shinchan:actionkamen",
  model="opus",
  prompt=`You are a SPEC COMPLIANCE REVIEWER for a micro-task.

## Prompt Template
// See: ${CLAUDE_PLUGIN_ROOT}/agents/_shared/micro-task-prompts/spec-reviewer-prompt.md

## The Original Spec
${task_description}

## Expected File Changes
${file_list}

## Rubric Override (optional)
${rubric_override || '(none — use default 3-item rubric from actionkamen.md)'}

## Implementer Report
${implementer_report}

## YOUR MISSION
DO NOT TRUST THE REPORT. The implementer may have:
- Finished suspiciously quickly
- Reported success without testing
- Misunderstood the spec
- Added or missed functionality

You MUST independently verify by READING THE ACTUAL CODE.

## Checklist
1. Completeness: Every spec requirement implemented?
2. Correctness: Matches spec exactly (not "close enough")?
3. Scope: No EXTRA functionality beyond spec?
4. Verification: Was the command actually run? Output matches?

## Output
- Verdict: PASS or FAIL
- Completeness: N/total requirements met
- Issues (if FAIL): what's wrong, spec says X, code does Y, file:line`)

If FAIL: Re-dispatch the implementer (model stays opus — already at the ceiling) with the spec reviewer's concrete issues injected → re-run spec review. Max 2 retries per task (matches Execution Rule 5). No model escalation is needed — the implementer is already on opus by default (Step 2.5).

3c. Dispatch Code Quality Reviewer

Only after spec compliance PASS.

Task(
  subagent_type="team-shinchan:actionkamen",
  model="opus",
  prompt=`You are a CODE QUALITY REVIEWER. Spec compliance already PASSED.

## Prompt Template
// See: ${CLAUDE_PLUGIN_ROOT}/agents/_shared/micro-task-prompts/code-quality-reviewer-prompt.md

## Task Context
${task_description}

## Changed Files
${changed_files}

## Rubric Override (optional)
${rubric_override || '(none — use default 3-item rubric from actionkamen.md)'}

## Focus (NOT checking if right thing was built — only if built WELL)
1. Code Quality: naming, DRY, focused functions, error handling
2. Pattern Compliance: follows project conventions?
3. Security: injection, validation, secrets?
4. Testability: covers behavior, not flaky, readable?
5. Maintainability: understandable by new developer?

## Severity
- CRITICAL: Must fix (security, data loss, correctness)
- IMPORTANT: Should fix (quality