team-shinchan-micro-execute

name	team-shinchan:micro-execute
description	Use when you need micro-task execution with per-task two-stage review.
user-invocable	true

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, tests)
- MINOR: Nice to have (style)

## Output
- Verdict: APPROVED or NEEDS_FIXES
- Strengths: [at least one]
- Issues: [severity] description — file:line
- Assessment: Ready to merge? Yes / Yes with fixes / No`)

If NEEDS_FIXES with CRITICAL issues: Re-dispatch implementer → re-run quality review. Max 1 retry.

3c-bis. Independent Skeptic Cross-Check (runs on the POSITIVE verdict)

Only after spec PASS and quality APPROVED, before marking complete. The pipeline distrusts the implementer but never the reviewers — a reviewer that rubber-stamps while missing a real bug has no second line of defense. This read-only refuter exists to catch reviewer false-negatives.

Task(
  subagent_type="team-shinchan:actionkamen",
  model="opus",
  prompt=`You are an INDEPENDENT SKEPTIC. READ-ONLY: inspect the code/diff only — do not modify any file. Two reviewers already returned Spec: PASS and Quality: APPROVED for this micro-task. Your ONLY job is to DISPROVE that green verdict by reading the ACTUAL code/diff — not the reports.

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

## The Spec
${task_description}

## Changed Files
${changed_files}

## Prior Verdicts (to be attacked, not trusted)
- Spec: PASS — ${spec_verdict_summary}
- Quality: APPROVED — ${quality_verdict_summary}

## YOUR MISSION
Assume the green is WRONG until proven otherwise. Manufacture a concrete reason it should be red:
- A failing input / edge case the tests do not cover
- A spec requirement satisfied only superficially (happy-path only)
- A test that passes WITHOUT exercising the behavior (assertion-free, fully mocked, tautological)
- A security/correctness hole both reviewers anchored past

## Output
- Verdict: UPHELD (genuinely found no counterexample) or REFUTED (concrete counterexample)
- If REFUTED: the exact counterexample (input → expected vs actual) and file:line`)

If REFUTED: treat as a FAIL — re-dispatch the implementer (opus) with the skeptic's counterexample, then re-run spec → quality → skeptic. Max 1 skeptic-triggered retry per task. A counterexample the skeptic cannot make concrete is NOT a blocker (no vague "could be risky").

3d. Mark Task Complete

After both reviews pass:

1. Update PROGRESS.md (if in workflow) with task status
2. Log completion
3. Output to user:

━━━━━━━━━━━━━━━━━━━━
✅ Task {N}/{total}: {title}
  Spec: PASS | Quality: APPROVED
  Files: {changed_files}
━━━━━━━━━━━━━━━━━━━━

4. Move to next task

Step 4: Final Review

After ALL micro-tasks complete:

Task(
  subagent_type="team-shinchan:actionkamen",
  model="opus",
  prompt=`FINAL REVIEW of entire implementation.

All ${total_tasks} micro-tasks passed individual reviews.
Now verify the WHOLE implementation works together.

## Check
1. All tests pass (run full test suite)
2. No integration issues between tasks
3. No duplicate code across tasks
4. Overall architecture is coherent

## Changed Files (all tasks combined)
${all_changed_files}

## Output
- Overall Verdict: APPROVED / NEEDS_FIXES
- Integration Issues: [any cross-task problems]
- Test Results: [full suite output]`)

Step 5: Complete

Output final summary:

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
👦 [Shinnosuke] Micro-Execute Complete
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

📊 {total_tasks} tasks | {total_reviews} reviews
✅ All spec compliance checks passed
✅ All code quality checks passed
✅ Final integration review passed

📝 Files changed:
{file_summary}
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

---

Agent Routing Table

Domain	Agent	Model
General code	Bo	opus (quality-first)
Frontend/UI/CSS	Aichan	opus (quality-first)
Backend/API/DB	Buriburi	opus (quality-first)
DevOps/CI/Docker	Masao	opus (quality-first)
All reviews	Action Kamen	opus (fixed)
Skeptic cross-check	Action Kamen	opus (fixed)
Plan generation	Nene	opus (fixed)

Execution Rules

1. Sequential tasks: Implementation tasks run one at a time (no parallel). Review subagents for each task also run sequentially.
2. Fresh subagent per task: Each task gets a new subagent. No context pollution.
3. Controller provides full context: The controller reads the plan once and provides full task text to each subagent. Subagents never read the plan file.
4. Two-stage review + skeptic: Spec compliance BEFORE code quality. Never skip. Every positive verdict (PASS + APPROVED) is then cross-checked by an independent read-only skeptic (Step 3c-bis) that tries to REFUTE it; a concrete counterexample reopens the task.
5. Retry limits: Max 2 retries for spec compliance, max 1 retry for code quality, max 1 skeptic-triggered retry. If still failing, report to user and pause.
6. Evidence required: No "should work" or "looks correct". Every claim needs a verification command output.