From potenlab-workflow
Post-completion development skill for adjustments and changes after all phases are done. Accepts change requests from arguments (/developer fix the login button) or via AskUserQuestion. Analyzes existing code and plans, creates change tasks in docs/changes.json, spawns small-coder and high-coder agents in parallel, and tracks all results in changes.json. Triggers on: developer, dev, adjust, change, fix, tweak, modify, post-dev.
npx claudepluginhub potenlab/marketplace-potenlab --plugin potenlab-workflowThis skill uses the workspace's default tool permissions.
Handle post-completion adjustments by analyzing change requests, creating tracked tasks in `changes.json`, and spawning coder agents in parallel.
Generates design tokens/docs from CSS/Tailwind/styled-components codebases, audits visual consistency across 10 dimensions, detects AI slop in UI.
Records polished WebM UI demo videos of web apps using Playwright with cursor overlay, natural pacing, and three-phase scripting. Activates for demo, walkthrough, screen recording, or tutorial requests.
Delivers idiomatic Kotlin patterns for null safety, immutability, sealed classes, coroutines, Flows, extensions, DSL builders, and Gradle DSL. Use when writing, reviewing, refactoring, or designing Kotlin code.
Handle post-completion adjustments by analyzing change requests, creating tracked tasks in changes.json, and spawning coder agents in parallel.
Use /developer when:
/execute-phaseUse /execute-phase instead when:
/developer [change description]
|
v
+----------------------------------------------------------+
| STEP 1: Get change request |
| - From argument: /developer fix the login button |
| - OR from AskUserQuestion if not provided |
+----------------------------------------------------------+
|
v
+----------------------------------------------------------+
| STEP 2: Read project context |
| - docs/progress.json (understand what was built) |
| - docs/dev-plan.md (original plan) |
| - docs/frontend-plan.md (component specs) |
| - docs/backend-plan.md (schema specs) |
| - Scan existing codebase (src/**) |
+----------------------------------------------------------+
|
v
+----------------------------------------------------------+
| STEP 3: Analyze & create change tasks |
| - Break the request into concrete tasks |
| - Classify each: low (small-coder) / high (high-coder) |
| - Identify affected files |
| - Determine dependencies between change tasks |
+----------------------------------------------------------+
|
v
+----------------------------------------------------------+
| STEP 4: Write docs/changes.json |
| - Create or APPEND to changes.json |
| - Each change request = a new "batch" |
| - Tasks inside the batch have IDs like "C1.1", "C1.2" |
+----------------------------------------------------------+
|
v
+----------------------------------------------------------+
| STEP 5: Spawn agents in PARALLEL |
| |
| ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ |
| │ small-coder │ │ high-coder │ │ small-coder │ |
| │ Task C1.1 │ │ Task C1.2 │ │ Task C1.3 │ |
| └─────────────┘ └─────────────┘ └─────────────┘ |
| |
| One agent per task — all run simultaneously |
+----------------------------------------------------------+
|
v
+----------------------------------------------------------+
| STEP 6: Update changes.json with results |
| - Mark completed / blocked tasks |
| - Recalculate batch and global summary |
+----------------------------------------------------------+
|
v
+----------------------------------------------------------+
| STEP 7: Report results |
+----------------------------------------------------------+
If the user provides a description:
/developer fix the login button hover state
/developer add dark mode toggle to settings
/developer refactor the user card to use the new design tokens
/developer the sidebar collapses incorrectly on mobile
Extract the change request directly. Do NOT ask questions — proceed to Step 2.
If the user invokes with no argument (/developer), you MUST use AskUserQuestion:
AskUserQuestion:
question: "What change or adjustment do you need?"
header: "Change Type"
options:
- label: "Bug fix"
description: "Something is broken or behaving incorrectly"
- label: "UI/UX adjustment"
description: "Visual or interaction changes"
- label: "Feature tweak"
description: "Modify existing functionality"
- label: "I'll describe it"
description: "Provide detailed description"
Then follow up to get specifics:
AskUserQuestion:
question: "Describe the change you need. Be specific about what should happen."
header: "Details"
options:
- label: "I'll type it out"
description: "Let me describe the change in detail"
{change_request}Read all available context to understand the current state of the project:
Glob: **/progress.json
Read: [found path] — understand what was built and task structure
Glob: **/dev-plan.md
Read: [found path] — original plan and architecture
Glob: **/frontend-plan.md
Read: [found path] — component specs, file paths, patterns
Glob: **/backend-plan.md
Read: [found path] — schema, queries, RLS policies
Glob: **/changes.json
Read: [found path] — previous change batches (if any)
Also scan the codebase to understand what files exist:
Glob: src/**/*.{ts,tsx}
If progress.json does NOT exist:
Warn the user but proceed anyway — changes.json can work independently:
Note:
progress.jsonnot found. Operating without original task context. Changes will still be tracked inchanges.json.
Break the user's change request into concrete, implementable tasks.
From the change request, determine:
Each distinct unit of work becomes a task. One task = one logical change.
Examples:
User request: "Fix the login button hover state and add a loading spinner"
Task C1.1: Fix login button hover state (1 file — low → small-coder)
Task C1.2: Add loading spinner to login button (1 file — low → small-coder)
User request: "Add dark mode toggle with persistent preference"
Task C1.1: Create dark mode Zustand store (1 file — low → small-coder)
Task C1.2: Add theme toggle component (1 file — low → small-coder)
Task C1.3: Wire dark mode across layout + providers + store (4 files — high → high-coder)
Use the same rules as progress.json:
| Complexity | Criteria | Agent |
|---|---|---|
low | 1-2 files, single concern, no cross-file logic | small-coder |
high | 3+ files, cross-file coordination, multi-concern | high-coder |
If tasks within the same batch depend on each other:
blocked_by: ["C1.1", "C1.2"]blocked_byOnly spawn tasks where blocked_by is empty. Blocked tasks wait for a re-run.
If changes.json does NOT exist — create it fresh.
If changes.json ALREADY exists — read it and APPEND a new batch.
Each invocation of /developer creates a new batch:
C1 with tasks C1.1, C1.2, ...C2 with tasks C2.1, C2.2, ...CN with tasks CN.1, CN.2, ...If changes.json already has batches, find the highest batch number and increment.
{
"project": "[from progress.json or dev-plan.md]",
"generated": "[ISO date of first creation]",
"last_updated": "[ISO date of latest update]",
"summary": {
"total_batches": 1,
"total_tasks": 0,
"completed": 0,
"in_progress": 0,
"pending": 0,
"blocked": 0
},
"batches": [
{
"id": "C1",
"request": "[user's original change request]",
"created": "[ISO date]",
"status": "in_progress",
"progress": "0/3",
"tasks": [
{
"id": "C1.1",
"name": "Fix login button hover state",
"type": "bug_fix",
"priority": "high",
"status": "pending",
"complexity": "low",
"estimated_files": 1,
"complexity_reason": "Single file — src/components/ui/button.tsx hover style",
"domain": "frontend",
"agent": "small-coder",
"dependencies": [],
"blocked_by": [],
"affected_files": [
"src/components/ui/button.tsx"
],
"output": [
"src/components/ui/button.tsx (modified)"
],
"verify": [
"Button hover state shows correct color",
"No regression on other button variants"
],
"notes": ""
},
{
"id": "C1.2",
"name": "Add loading spinner to login",
"type": "enhancement",
"priority": "medium",
"status": "pending",
"complexity": "low",
"estimated_files": 1,
"complexity_reason": "Single file — add spinner state to login component",
"domain": "frontend",
"agent": "small-coder",
"dependencies": [],
"blocked_by": [],
"affected_files": [
"src/features/auth/components/login.auth.tsx"
],
"output": [
"src/features/auth/components/login.auth.tsx (modified)"
],
"verify": [
"Spinner shows during login API call",
"Spinner hides after success or error"
],
"notes": ""
},
{
"id": "C1.3",
"name": "Wire loading state with auth store",
"type": "enhancement",
"priority": "medium",
"status": "pending",
"complexity": "high",
"estimated_files": 3,
"complexity_reason": "Cross-file — auth store + login component + API hook coordination",
"domain": "frontend",
"agent": "high-coder",
"dependencies": ["C1.1", "C1.2"],
"blocked_by": ["C1.1", "C1.2"],
"affected_files": [
"src/stores/auth.store.ts",
"src/features/auth/api/useAuth.ts",
"src/features/auth/components/login.auth.tsx"
],
"output": [
"src/stores/auth.store.ts (modified)",
"src/features/auth/api/useAuth.ts (modified)",
"src/features/auth/components/login.auth.tsx (modified)"
],
"verify": [
"Loading state syncs between store and component",
"No race conditions on rapid submit"
],
"notes": "Depends on C1.1 and C1.2 being done first"
}
]
}
]
}
| Field | Type | Description |
|---|---|---|
id | string | Task ID with batch prefix (e.g., "C1.1", "C2.3") |
name | string | Short description of the change |
type | string | "bug_fix" | "enhancement" | "refactor" | "style" | "new_feature" |
priority | string | "critical" | "high" | "medium" | "low" |
status | string | "pending" | "in_progress" | "completed" | "blocked" |
complexity | string | "low" | "high" — determines agent |
estimated_files | number | How many files this task modifies |
complexity_reason | string | Short specific sentence explaining WHY |
domain | string | "frontend" | "backend" | "fullstack" |
agent | string | "small-coder" | "high-coder" — derived from complexity |
dependencies | string[] | Task IDs that must complete first |
blocked_by | string[] | Same as dependencies, updated at runtime |
affected_files | string[] | Files that will be MODIFIED (not created) |
output | string[] | Files modified or created with annotation |
verify | string[] | Concrete verification steps |
notes | string | Additional context |
Write: docs/changes.json
Same parallel spawning mechanism as /execute-phase.
executable_tasks = batch.tasks.filter(task =>
task.status === "pending" AND
task.blocked_by.length === 0
)
If some tasks are blocked by other tasks in the same batch, only spawn the unblocked ones. Blocked tasks are reported and will need a re-run after dependencies complete.
### Execution Plan — Batch {batch_id}
**Change request:** {change_request}
| Task | Complexity | Agent | Files | Reason |
|------|-----------|-------|-------|--------|
| {id} {name} | low | small-coder | {estimated_files} | {complexity_reason} |
| {id} {name} | high | high-coder | {estimated_files} | {complexity_reason} |
**Spawning:** {executable_count} agents ({small_count} small-coder, {high_count} high-coder)
**Blocked:** {blocked_count} tasks waiting on dependencies
For EACH executable task, use the appropriate agent:
complexity: "low"):Task:
subagent_type: small-coder
description: "Change {task.id}: {task.name}"
prompt: |
Execute change task {task.id}: {task.name}
Context — read ALL plan files first (MANDATORY):
- docs/dev-plan.md (project architecture)
- docs/frontend-plan.md (component specs)
- docs/backend-plan.md (schema specs)
- docs/ui-ux-plan.md (design context)
- docs/progress.json (what was originally built)
- docs/changes.json (current change tracking)
Change details:
- ID: {task.id}
- Name: {task.name}
- Type: {task.type}
- Domain: {task.domain}
- Affected files: {task.affected_files}
- Verify steps: {task.verify}
User's original request: "{change_request}"
Instructions:
1. Read ALL plans to understand the full project
2. Read the affected files to understand current implementation
3. Apply the change — modify existing code, don't rewrite from scratch
4. Keep changes minimal and focused
5. Verify against the verify steps
IMPORTANT:
- This is a SMALL change (1-2 files). If it seems bigger, report back.
- Do NOT update changes.json — the orchestrator handles that.
- Preserve existing code patterns and structure.
When done, return: "COMPLETED: {task.id} — {task.name} | Files: [list of files modified]"
If blocked or too large, return: "BLOCKED: {task.id} — {reason}"
complexity: "high"):Task:
subagent_type: high-coder
description: "Change {task.id}: {task.name}"
prompt: |
Execute change task {task.id}: {task.name}
Context — read ALL plan files first (MANDATORY):
- docs/dev-plan.md (project architecture)
- docs/frontend-plan.md (component specs)
- docs/backend-plan.md (schema specs)
- docs/ui-ux-plan.md (design context)
- docs/progress.json (what was originally built)
- docs/changes.json (current change tracking)
Change details:
- ID: {task.id}
- Name: {task.name}
- Type: {task.type}
- Domain: {task.domain}
- Estimated files: {task.estimated_files}
- Affected files: {task.affected_files}
- Verify steps: {task.verify}
User's original request: "{change_request}"
Instructions:
1. Read ALL plans to understand the full project
2. Read ALL affected files to understand current implementation
3. Plan the modification order across files
4. Apply changes — modify existing code, maintain consistency across files
5. Self-review: check types, imports, no regressions
6. Verify against the verify steps
IMPORTANT:
- This is a COMPLEX change (3+ files, cross-file coordination).
- Do NOT update changes.json — the orchestrator handles that.
- Ensure no regressions in existing functionality.
- Handle edge cases from the change.
When done, return: "COMPLETED: {task.id} — {task.name} | Files: [list of files modified]"
If blocked or has issues, return: "BLOCKED: {task.id} — {reason}"
Wait for ALL agents to complete before proceeding to Step 6.
After all agents complete:
Read: docs/changes.json
IF result starts with "COMPLETED:"
→ Set task.status = "completed"
IF result starts with "BLOCKED:"
→ Set task.status = "blocked"
→ Add reason to task.notes
For completed tasks, remove their IDs from blocked_by arrays of other tasks in the same batch:
for each completed_task_id:
for each task in batch.tasks:
task.blocked_by = task.blocked_by.filter(id => id !== completed_task_id)
completed_count = batch.tasks.filter(t => t.status === "completed").length
total_count = batch.tasks.length
batch.progress = "{completed_count}/{total_count}"
if all tasks completed → batch.status = "completed"
if any task still pending/blocked → batch.status = "in_progress"
summary.total_batches = batches.length
summary.total_tasks = count of ALL tasks across ALL batches
summary.completed = count where status === "completed"
summary.in_progress = count where status === "in_progress"
summary.pending = count where status === "pending"
summary.blocked = count where status === "blocked"
last_updated = [current ISO date]
Write: docs/changes.json
## Developer — Change Batch {batch_id} Complete
### Change Request
> {change_request}
### Results
| Task | Agent | Status | Files Modified |
|------|-------|--------|---------------|
| {id} {name} | small-coder | Completed | {files} |
| {id} {name} | high-coder | Completed | {files} |
| {id} {name} | small-coder | Blocked | {reason} |
### Batch Summary
| Metric | Count |
|--------|-------|
| Tasks in batch | {total} |
| Completed | {completed} |
| Blocked | {blocked} |
| Agents spawned | {total_agents} |
| small-coder | {small_count} |
| high-coder | {high_count} |
### Batch Progress
Batch {batch_id}: {completed}/{total} tasks
### Still Blocked (needs re-run)
| Task | Blocked By | Status |
|------|------------|--------|
| {id} {name} | {blocked_by} | Now unblocked — run `/developer` again |
### changes.json Updated
- Location: `docs/changes.json`
- Batch {batch_id} tracked with all task results
- Summary counts recalculated
### Next Steps
1. Review the modified files for correctness
2. If blocked tasks are now unblocked, run `/developer` again with the same request
3. Run `/developer` with a new request for additional changes
4. All change history is preserved in `docs/changes.json`
When /developer is invoked and changes.json already has batches with blocked tasks that are now unblocked:
Before creating a new batch, check if existing batches have tasks where:
status === "pending" or status === "blocked"blocked_by is now empty (dependencies were completed in a previous run)If found, execute those tasks first WITHOUT creating a new batch.
AskUserQuestion:
question: "Found {N} unblocked tasks from batch {batch_id}. Execute them or start a new change?"
header: "Pending Work"
options:
- label: "Execute unblocked tasks (Recommended)"
description: "Finish pending work from batch {batch_id}"
- label: "New change request"
description: "Skip pending tasks and create a new batch"
- label: "Both"
description: "Execute pending tasks AND add new changes"
Warn but proceed:
"No plan files found. changes.json will be created with limited context.
Consider running /plan first for a better development experience."
1. Keep failed task as "pending" in changes.json
2. Report which agent failed and for which task
3. Other agents' results are still valid
4. Suggest re-running /developer to retry
1. Attempt to parse
2. If unparseable, rename to changes.json.backup
3. Create fresh changes.json
4. Warn user about the backup
Use AskUserQuestion to clarify:
"Your request is broad. Can you be more specific about what to change?"