ワンクリックで
phase-detector
Use when determining task phase - analyzes task file to identify Phase 1, 2, or 3 for a specific task
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
メニュー
Use when determining task phase - analyzes task file to identify Phase 1, 2, or 3 for a specific task
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | phase-detector |
| description | Use when determining task phase - analyzes task file to identify Phase 1, 2, or 3 for a specific task |
| version | 3.0.0 |
| user-invocable | false |
| allowed-tools | Read, Glob |
Analyze a task file to determine its current development phase.
Phases apply to TASKS, not projects. A project has requirements (gathered once), then contains multiple tasks. Each task independently progresses through phases.
Activate when:
project-orchestrator agent| Phase | Focus | Code? |
|---|---|---|
| 1 - Research | Understand requirements, research solutions | NO |
| 2 - Architecture | Design approach, patterns, decisions | NO |
| 3 - Implementation | Build with TDD, interactive coding | YES |
Get task name from:
Check for task directory at:
{project_path}/implementation_process/in_progress/{task_name}/
If not found, check:
{project_path}/implementation_process/completed/{task_name}/
If neither exists, check for v2.x single file (backward compatibility):
{project_path}/implementation_process/in_progress/{task_name}.md
{project_path}/implementation_process/completed/{task_name}.md
If nothing found, task hasn't started yet → Phase 0 (Not Started)
v3.0.0 Folder Structure:
Use Bash to check for phase files:
# Check which phase files exist
[ -f "{task_name}/task.md" ] && echo "tracker"
[ -f "{task_name}/research.md" ] && echo "research"
[ -f "{task_name}/architecture.md" ] && echo "architecture"
[ -f "{task_name}/implementation.md" ] && echo "implementation"
Then use Read on {task_name}/task.md to check:
Phase 1 Complete Indicators:
research.md file existsPhase 2 Complete Indicators:
architecture.md file existsPhase 3 Progress Indicators:
implementation.md file existsv2.x Single File (backward compatibility):
If single .md file found, check for sections:
## Research section exists → Phase 1 complete## Architecture section exists → Phase 2 complete## Implementation section exists → Phase 3 in progressTask file doesn't exist?
→ Phase 0: Not Started - "Create task and begin research"
Task file exists but no Research section?
→ Phase 1: Research - "Research this task"
Research complete but no Architecture section?
→ Phase 2: Architecture - "Design architecture for this task"
Architecture complete?
→ Phase 3: Implementation - "Implement this task"
All checkboxes complete?
→ Done - "Complete this task"
Format output as:
## Task Phase: {task_name}
**Phase:** {0/1/2/3} - {Not Started/Research/Architecture/Implementation}
**Status:** {Not Started/In Progress/Complete}
### Evidence
| Section | Found | Content |
|---------|-------|---------|
| Research | Yes/No | {summary or "Empty"} |
| Architecture | Yes/No | {summary or "Empty"} |
| Implementation | Yes/No | {progress or "Empty"} |
### Next Action
{What to do next for this task}
### Command
{Suggested command to run}
When checking overall project status, summarize all tasks:
## Project: {project_name}
### Requirements
{Complete / Not gathered}
### Task Summary
| Task | Phase | Status | Next Action |
|------|-------|--------|-------------|
| {task1} | 3 | In Progress | Continue implementation |
| {task2} | 1 | In Progress | Complete research |
| {task3} | 0 | Queued | Start research |
### Completed Tasks
- {task_a} ✓
- {task_b} ✓
| Situation | Handling |
|---|---|
| No task specified | List all tasks with their phases |
| Task not found | Offer to create it |
| Task in completed/ | Report as done |
| Multiple tasks in progress | Show all, ask which to focus on |
STOP if:
Use when creating Claude Code plugins - covers skills, commands, agents, hooks, MCP servers, and plugin configuration. Use when user says "create plugin", "make a skill", "add command", "add hooks", "skill authoring", "SKILL.md", "plugin components", "package reusable behavior", "distribute skills", "scaffold plugin", "plugin structure", "write a skill description". NOT for: using existing plugins, installing plugins, plugin marketplace browsing. !`ls .claude-plugin/ 2>/dev/null`
Use when starting a new development project — creates memory folder structure with project_state.md (including codePath), architecture scaffolding, and registers project. Accepts optional code_path argument.
Use when checking code quality, running security audits, testing coverage, finding SOLID/DRY violations, or setting up quality tools. Use when user says "audit this code", "check security", "run PHPStan", "code quality", "find violations", "SOLID check", "DRY check", "test coverage", "lint this", "security review", "is this production ready", "check for vulnerabilities", "code review", "grade this code", "watch mode lint", "deep review", "ultrareview", "schedule quality sweep". Supports Drupal (PHPStan, PHPMD, Psalm, Semgrep, Trivy, Gitleaks via DDEV) and Next.js (ESLint, Jest, Semgrep, Trivy, Gitleaks). Use proactively before deployment or after significant code changes.
Use when an orchestrator must run a task's work-orders CONCURRENTLY behind the same gate floor as the sequential loop — the DB-free parallel sibling of work-order-loop. Each round it reconciles from disk (L1-light), selects a disjoint-file ready batch (wo-parallel-batch.sh), builds every batched WO at once in its OWN ephemeral git worktree branched off the integration HEAD (N parallel build atoms in ONE message), runs /review --headless + the work-order-critique rung per worktree, derives every verdict from disk, and merges each CLEAN WO back into the integration branch with a LOCAL git merge (wo-merge-back.sh — NOT a PR merge), pruning each ephemeral worktree after its verdict. The per-WO retry cap stays the SOLE responsibility of wo-run-state.sh dispatch; terminal-HALT precedence, disk-is-truth, and no-auto-merge are preserved verbatim. At the end it runs ONE integrated /review on the integration branch and opens ONE PR through wo-pr-open.sh (re-runs the merge gate, NEVER merges). MUST be invoked inline (ne
Use when an orchestrator must run the autonomous per-task run-loop behind the gate floor — the thin native glue (③ lifecycle_controls). Resumes from disk (L1-light), drives a ready-queue over the work-orders (a WO is ready when all blocked_by are done), dispatches ONE build atom per WO in clean context, runs /review --headless + the work-order-critique rung per WO, owns EVERY WO status transition via wo-compile.sh set-status, bounds the verify→fix loop with a crash-safe retry cap (wo-run-state.sh), and at the end opens a PR through the wo-pr-open.sh choke point that re-runs the merge gate and NEVER merges. Reads every decision from disk; treats builder transcripts as untrusted data; honors a budget/kill-switch call-site. MUST be invoked inline (never Task-dispatched). Prints a ready-to-paste /goal string; never runs /goal itself.
Use when an orchestrator must run the opt-in adversarial-critique rung on ONE built work-order — the absent-human review layered ABOVE the deterministic gates. Derives the work-order's risk tier (wo-risk-classify.sh), decides whether critique is required (forced-on for high-risk-unattended; else the per-task/per-project dial), spawns risk-scaled INDEPENDENT fresh-context wo-critic agents that re-derive the verdict from artifacts (git diff + gate envelopes), aggregates fail-closed (wo-critique-aggregate.sh) into a per-WO _critique.json, and writes a wo-NN.HALT marker when blocking. Fan-out is the unattended primitive; never edits /review's _review.json. A judgment layer, not a gate — gates always run first.