Frontend Workmate

Frontend Development Orchestration Skill

Execution Entry Point (Primary Action)

Upon receiving a user request, immediately execute the following actions without skipping:

1. Output: Initializing...
2. Set internal state: current_stage = stage0
3. Read and execute stages/init.md (Initialization phase definition)
4. After initialization completes, output: [Initialization] Completed. Conclusion: specific conclusion. Proceeding to next phase: [Project Scan].
5. Set internal state: current_stage = stage1, read and execute stages/project-scan.md

Phase Mapping Table: See stages/index.md (ID ↔ Name)

• Use IDs for internal state (e.g., stage0)
• Use names for user output (e.g., [Initialization])

Prohibited: Skipping initialization, outputting IDs or numbers to users.

Phase Transition Mechanism (General Rules)

After each phase completes, execute the following actions:

1. Output phase completion conclusion: [Phase Name] Completed. Conclusion: specific conclusion. Proceeding to next phase: [Next Phase Name].
2. Set internal state: current_stage = <next_phase_ID>, current_stage_status = in_progress
3. Read and execute stages/<next_phase_definition_file>.md
4. Execute according to phase definition, forming minimum checkpoint artifacts

Explicit Confirmation Points (require user response before proceeding):

• After Project Scan → Output project skill summary, await user confirmation
• After Scope Analysis → Output analysis conclusion, await user confirmation
• After Delivery → Output delivery results, await user confirmation; user may supplement modifications or specify fallback phase

Standard Prompt for Explicit Confirmation Points:

After outputting conclusion at each explicit confirmation point, must append the following prompt:

"If you have other modifications needed, please let me know; if everything looks correct, you can simply reply 'continue' and I'll proceed to the next step."

Prompt Usage Scenarios:

• Project Scan confirmation: After outputting project skill summary → append prompt
• Scope Analysis confirmation: After outputting analysis conclusion → append prompt
• Delivery confirmation: After outputting delivery results → append confirmation prompt (including smart fallback options)

Prohibited Actions:

• Prohibited from only outputting "please confirm" or "reply continue"
• Prohibited from omitting "If you have other modifications needed, please let me know"
• Prohibited from appending prompt after final step (Delivery completed)

Automatic Transition Points (no waiting, directly proceed):

• Initialization → automatically proceed to Project Scan
• Execution Plan → automatically proceed to Material Supply
• Material Supply (user responded provided | not_provided | skipped | not_applicable) → automatically proceed to Implementation
• Implementation → automatically proceed to Verification (Stage 5 completion directly executes Stage 6)
• Verification → automatically proceed to Documentation Sync (Stage 6 completion directly executes Stage 7)
• Documentation Sync → automatically proceed to Delivery

Prohibited Actions During Waiting:

• Must not continue analysis, invoke downstream skills, modify files, or execute commands in same response
• Must not assume user consent and skip confirmation points

Directory Concept Mapping (Three Core Directories Design)

This skill pack uses a Three Core Directories design. The config file only stores these 3 paths; other paths are constructed by concatenation:

Path Concatenation Rules:

Key Rules:

• Config file stored in Project IDE Config Directory: .fw-session-config.json
• Static skills stored in Static Config Root Directory/skills/: Sibling to frontend-workmate
• Project skill stored in Project IDE Config Directory/skills/: fw-project-develop/

Example (Global Install, IDE config directory ~/.qoder):

# Static Config Root Directory
~/.qoder/                                        # static_config_dir
├── skills/
│   ├── frontend-workmate/                       # This skill pack
│   │   ├── rules/
│   │   │   ├── frontend-implementation.md
│   │   │   └── frontend-verification.md
│   │   └── templates/
│   ├── fw-react-best-practices/                    # Static skill
│   ├── fw-systematic-debugging/                    # Static skill
│   └── ...
├── rules/
│   └── ...
└── ...

# Project IDE Config Directory (follows project)
/home/user/my-project/.qoder/                    # project_ide_dir
├── .fw-session-config.json                      # Config file (only 3 paths)
├── skills/
│   └── fw-project-develop/                      # Project skill
├── rules/
│   ├── fw-skill-rule.md                         # Project rule
│   └── fw-session-state.md                      # Project state
└── output/

Example (In-Project Install): When skill is installed within project, static_config_dir = <project>/<IDE>/ (e.g., /home/user/my-project/.qoder/). └── output/

Project Working Directory (user-opened directory)

/home/user/my-project/ ├── src/ ├── package.json └── ...

**Relationship Example (In-Project Install)**:
When skill is installed within project, Static Config Directory and Project IDE Config Directory may be identical or adjacent.

---

## Process Execution Protocol

### Phase Names and Sequence

| Order | Phase Name | Definition File | Core Responsibility |
| --- | --- | --- | --- |
| 1 | Initialization | `stages/init.md` | Execute initialization script, establish task context |
| 2 | Project Scan | `stages/project-scan.md` | Generate or refresh project skill `fw-project-develop` |
| 3 | Scope Analysis | `stages/scope-analysis.md` | Analyze task type, modification scope, skill routing |
| 4 | Execution Plan | `stages/plan.md` | Long task breakdown and checkpoint resume (optional) |
| 5 | Material Supply | `stages/supply.md` | Supply prerequisite materials by task type |
| 6 | Implementation | `stages/implementation.md` | Execute code modifications |
| 7 | Verification | `stages/verification.md` | Verify modification validity |
| 8 | Documentation Sync | `stages/docs.md` | Update directory-level documentation |
| 9 | Delivery | `stages/delivery.md` | Output delivery results |

### Master Process Table

See `stages/index.md` for complete execution logic table (phase/node, decision conditions, branch directions).

### Phase Transition Overview

Initialization → Project Scan → [User Confirmation] → Scope Analysis → [User Confirmation] → Execution Plan (optional) → Material Supply → [User Provides] → Implementation → Verification → Documentation Sync → Delivery → [User Confirmation]

**Explicit Confirmation Points**:
- After Project Scan: User must confirm if project skill is correct
- After Scope Analysis: User must confirm if analysis conclusion is correct
- After Delivery: User must confirm delivery results (user may supplement modifications or specify fallback phase)

**Automatic Transition Points**: Implementation, Verification, Documentation Sync automatically proceed to next phase after completion (Stage 5→6→7→8 fully automatic)

### Phase Completion Output Specification

**After each phase completes, must output**:

[Phase Name] Completed. Conclusion: specific conclusion content. Proceeding to next phase: [Next Phase Name].

**Internal State Maintenance** (use IDs):
- `current_stage`: Internal ID (e.g., `stage0`)
- `current_stage_status`: `pending | in_progress | waiting_user | completed | blocked`
- `next_stage`: Next phase ID (e.g., `stage1`)

**User Output** (use names):
- Output `[Initialization]` not `[stage0]`
- Output `[Project Scan]` not `[stage1]`

**Phase Mapping Table**: See `stages/index.md`

**Prohibited**:
- Outputting Stage numbers or internal IDs
- Silent phase transitions

---

## Core Gate Rules

### 1. Must Start from Initialization

First round must start from Initialization phase; cannot skip initialization to directly enter Project Scan or other phases.

### 2. Phase Artifacts Must Be Formed

Each phase must form minimum checkpoint artifacts; cannot "think internally and jump to next phase".

### 3. User Confirmation Must Wait

At explicit confirmation points, must wait for clear user response:
- User replies `continue / agree / no problem`: Allowed to proceed to next phase
- User replies supplement or correction content: Stay in current phase, merge and re-confirm
- User replies negative: Handle according to fallback rules

### 4. Prohibited from Fabricating Project Capabilities

If project lacks certain capability (e.g., routing, permissions, state management), mark `not_applicable`; must not fabricate implementation.

### 5. Original Requirement Anchor Cannot Be Overwritten

"Original requirement anchor" established in Initialization phase is the task's primary goal; subsequent phases can only supplement constraints, cannot rewrite original requirement.

### 6. Project Skill Only Carries Long-Term Rules

`fw-project-develop` only carries stable project knowledge; must not write current single-task temporary requests or implementation preferences.

### 7. Skill Invocation Recommendation Rules

**Each phase recommends invoking skills based on actual conditions when conditions are met**:

| Phase | Trigger Condition | Recommended Skill | Description |
| --- | --- | --- | --- |
| **Stage 2 (Scope Analysis)** | Project skill exists | `fw-project-develop` | Invoke project skill to understand project structure and tech stack |
| **Stage 5 (Implementation)** | Project skill exists | `fw-project-develop` | Invoke project skill to understand project structure and tech stack |
| **Stage 5 (Implementation)** | Task type is `bug` | `fw-systematic-debugging` | Invoke debugging skill to debug bugs and find root cause |
| **Stage 5 (Implementation)** | Tech stack is React | `fw-react-best-practices` | Invoke React best practices skill |
| **Stage 5 (Implementation)** | Tech stack is React and involves component development | `fw-react-components` | Invoke React component standards skill |
| **Stage 5 (Implementation)** | Involves complex types | `fw-typescript-advanced-types` | Invoke TypeScript advanced types skill |
| **Stage 6 (Verification)** | Project skill exists | `fw-project-develop` | Invoke project skill to understand verification constraints |
| **Stage 6 (Verification)** | Changes involve pages/components/forms/keyboard interactions | `fw-accessibility` | Invoke WCAG accessibility check skill |
| **Stage 6 (Verification)** | Changes involve layout/styles/UI | `fw-web-design-guidelines` | Invoke UI design audit skill |

**Project Skill Description**:
- `fw-project-develop` is the project skill, containing project structure, tech stack, routing, permissions, state management, build rules, etc.
- Recommended invocation: at the beginning of Stage 2 (Scope Analysis), Stage 5 (Implementation), Stage 6 (Verification)
- Invocation purpose: Let AI understand project constraints, avoid violating existing project rules

**Tech Stack Description**:
- `fw-react-best-practices`, `fw-react-components` **only applicable to React tech stack** (marked in project skill)
- Other tech stacks (Vue, Angular, Svelte, etc.) currently have no corresponding skills; can be extended later
- Tech stack determination basis: tech stack field obtained after invoking `fw-project-develop`

**Prohibited Actions**:
- Prohibited from forcibly invoking when trigger conditions not met (avoid over-invocation)
- Prohibited from invoking React skills under non-React tech stack

---

## Skills and Rules Invocation

### Process Rules Entry

See `rules/frontend-orchestrator.md` for complete core chain, query gates, phase transition rules, fallback logic.

### Phase-Specific Rules

| Phase | Rule File |
| --- | --- |
| Project Scan | `rules/project-scan-profile.md` |
| Scope Analysis | `rules/frontend-change-scope.md` |
| Implementation | `rules/frontend-implementation.md` |
| Verification | `rules/frontend-verification.md` |
| Documentation Sync | `rules/directory-doc-sync.md` |

### Reusable Skills

| Skill | Purpose | Invocation Timing |
| --- | --- | --- |
| `fw-systematic-debugging` | Systematic debugging | Bug fixes |
| `fw-react-best-practices` | React best practices | React-related implementation |
| `fw-react-components` | React component standards | Component development |
| `fw-typescript-advanced-types` | TypeScript advanced types | Complex type problems |
| `fw-task-plan-checkpoint` | Long task checkpoint resume | Multi-step tasks |
| `fw-code-analysis-doc` | Code analysis documentation | Directory relationship extraction |
| `fw-accessibility` | Accessibility check | UI verification |
| `fw-web-design-guidelines` | UI guidelines check | UI verification |
| `find-skills` | Skill discovery | When missing key skills |

---

## Fallback Rules

| Scenario | Fallback Target |
| --- | --- |
| Project skill missing or invalid | Project Scan |
| Scope analysis conclusion unstable | Scope Analysis |
| Implementation finds critical skill unavailable | Scope Analysis |
| Verification fails | Implementation |
| Documentation sync finds implementation unstable | Implementation or Verification |
| User supplements new requirements after delivery | Scope Analysis |

---

## Final Delivery Requirements

- Report: What was changed, how verified, remaining risks
- Any claimed "completed" results must be actually verified
- If task interrupted, resume records in `temp/task-runs/<task-id>/`

---

## Related File Index

| Category | Directory/File |
| --- | --- |
| Phase Definitions | `stages/*.md` |
| Process Rules | `rules/*.md` |
| Reusable Skills | `skills/curated/*/SKILL.md` |
| Artifact Templates | `templates/` |
| Project Knowledge | `AGENTS.md` |