一键导入
jikime-workflow-task-format
Structured task format with Do/Files/Done-when/Verify/Commit fields and quality checkpoints for systematic task tracking
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Structured task format with Do/Files/Done-when/Verify/Commit fields and quality checkpoints for systematic task tracking
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
AI-powered legacy site rebuilding workflow. Captures screenshots, analyzes source code, and generates modern frontend/backend code. Claude Code reads screenshots and writes actual code. Use when rebuilding legacy PHP, WordPress, or similar sites to Next.js, React, or other modern frameworks.
하네스를 구성합니다. 전문 에이전트를 정의하며, 해당 에이전트가 사용할 스킬을 생성하는 메타 스킬. (1) '하네스 구성해줘', '하네스 구축해줘' 요청 시, (2) '하네스 설계', '하네스 엔지니어링' 요청 시, (3) 새로운 도메인/프로젝트에 대한 하네스 기반 자동화 체계를 구축할 때, (4) 하네스 구성을 재구성하거나 확장할 때 사용.
Leader agent role guide for jikime team orchestration. Covers task distribution, plan approval, worker monitoring, and team shutdown. Use when spawned as the leader role in a jikime team.
Reviewer agent role guide for jikime team orchestration. Covers plan review, quality assessment, acceptance criteria validation, and feedback delivery via team inbox. Use when spawned as the reviewer role in a jikime team.
Use this skill when the user asks to "jikime team을 사용해줘", "팀 만들어줘", "에이전트 생성해줘", "멀티 에이전트로 작업해줘", "병렬로 에이전트 실행해줘", "여러 에이전트 조율해줘", "작업을 여러 에이전트에게 분배해줘", "team status 확인해줘", "task 만들어줘", "inbox 확인해줘", or mentions "jikime team", "multi-agent coordination", "spawn agents", "team tasks", "agent inbox", "task board", "team leader", "team worker". Also trigger when the scope of work is large enough to benefit from splitting into parallel subtasks — for example "전체 코드베이스 리팩토링", "여러 기능 동시에 구현", "대규모 분석", "full-stack app 만들어줘". Provides comprehensive guidance for using the jikime team CLI to orchestrate multi-agent teams with task management, messaging, and monitoring.
Claude Code skill for operating as part of a jikime multi-agent team (swarm). Provides command reference, coordination protocols, and role-specific workflows for leader, worker, and reviewer agents. Triggers when the task involves multi-agent coordination, spawning workers, assigning tasks, monitoring team progress, or when the scope exceeds what a single agent can efficiently handle (e.g., "build a full-stack app", "implement multiple features in parallel", "refactor the entire codebase"). Also triggers on keywords: "create a team", "spawn agents", "assign tasks", "team status", "board attach", "agent inbox", "multi-agent", "swarm", "jikime team".
基于 SOC 职业分类
| name | jikime-workflow-task-format |
| description | Structured task format with Do/Files/Done-when/Verify/Commit fields and quality checkpoints for systematic task tracking |
| version | 1.0.0 |
| tags | ["workflow","task","format","checkpoint","quality"] |
| triggers | {"keywords":["task format","structured task","task breakdown","checkpoint","verify task"],"phases":["plan","run"],"agents":["manager-ddd","manager-spec","planner"],"languages":[]} |
| progressive_disclosure | {"enabled":true,"level1_tokens":"~100","level2_tokens":"~2500"} |
| user-invocable | false |
| context | fork |
| agent | planner |
| allowed-tools | ["Read","Write","Edit","Bash","Grep","Glob","TodoWrite"] |
Systematic task decomposition with 5-field structure and quality checkpoints.
Every implementation task is decomposed into structured units with clear acceptance criteria. This format ensures nothing is forgotten and quality is verified at regular intervals.
Each task follows this mandatory format:
### Task N: [Title]
**Do**: What to implement (specific action)
**Files**: Which files to create or modify
**Done when**: Measurable acceptance criteria
**Verify**: How to verify completion (test command, manual check)
**Commit**: Commit message when task is complete
| Field | Required | Description |
|---|---|---|
| Do | Yes | Single, actionable implementation step |
| Files | Yes | Explicit file paths (create/modify/delete) |
| Done when | Yes | Measurable criteria (test passes, build succeeds, output matches) |
| Verify | Yes | Concrete verification command or check |
| Commit | Yes | Conventional commit message (feat/fix/refactor/test/docs) |
### Task 1: Create user authentication API
**Do**: Implement POST /api/auth/login endpoint with JWT token generation
**Files**: src/api/auth/login.ts (create), src/types/auth.ts (create)
**Done when**: POST /api/auth/login returns 200 with valid JWT for correct credentials, 401 for invalid
**Verify**: `npm test -- --grep "auth login"` passes
**Commit**: feat(auth): add login endpoint with JWT generation
Insert a [VERIFY] checkpoint task after every 2-3 implementation tasks.
### Task N: [VERIFY] Quality Checkpoint
**Do**: Run full verification suite
**Files**: (none - verification only)
**Done when**: All checks pass with zero errors
**Verify**:
- `npm run build` (zero errors)
- `npm test` (all passing)
- `npm run lint` (zero warnings)
- Manual: feature works as expected
**Commit**: (no commit - checkpoint only)
Task 1: Implementation
Task 2: Implementation
Task 3: Implementation
Task 4: [VERIFY] Quality Checkpoint <-- after 3 tasks
Task 5: Implementation
Task 6: Implementation
Task 7: [VERIFY] Quality Checkpoint <-- after 2 tasks
Task 8: Implementation
...
Task N: [VERIFY] Final Checkpoint <-- always at the end
All tasks MUST be tracked using TodoWrite:
1. Task discovered → TodoWrite: add with "pending" status
2. Task started → TodoWrite: change to "in_progress"
3. Task completed → TodoWrite: change to "completed"
4. [VERIFY] failed → TodoWrite: add fix tasks with "pending"
[pending] Task 1: Create user authentication API
[in_progress] Task 2: Add password hashing
[completed] Task 3: Create login form
[pending] Task 4: [VERIFY] Quality Checkpoint
| Size | Description | Example |
|---|---|---|
| XS | Single function/method | Add validation helper |
| S | Single file change | Create API endpoint |
| M | 2-3 file changes | Feature with tests |
| L | 4+ file changes | Split into smaller tasks |
Rule: If a task touches more than 3 files, split it into smaller tasks.
When working with existing code (DDD workflow), tasks follow ANALYZE-PRESERVE-IMPROVE:
### Task N: [ANALYZE] Understand current auth flow
**Do**: Read and document current authentication implementation
**Files**: src/auth/ (read only)
**Done when**: Current behavior documented with edge cases identified
**Verify**: Documentation matches actual code behavior
**Commit**: (no commit - analysis only)
### Task N+1: [PRESERVE] Add characterization tests
**Do**: Write tests that capture current behavior exactly
**Files**: tests/auth.test.ts (create)
**Done when**: Tests pass against current implementation
**Verify**: `npm test -- --grep "auth characterization"` all pass
**Commit**: test(auth): add characterization tests for existing auth flow
### Task N+2: [IMPROVE] Refactor to JWT-based auth
**Do**: Replace session-based auth with JWT tokens
**Files**: src/auth/login.ts (modify), src/auth/middleware.ts (modify)
**Done when**: All characterization tests still pass with new implementation
**Verify**: `npm test` all pass, no behavior change
**Commit**: refactor(auth): migrate from session to JWT authentication
| Skill | Integration Point |
|---|---|
jikime-workflow-poc | POC phases generate tasks in this format |
jikime-workflow-tdd | RED-GREEN-REFACTOR maps to task sequences |
jikime-workflow-ddd | ANALYZE-PRESERVE-IMPROVE maps to task prefixes |
jikime-workflow-loop | Loop iterations track progress via TodoWrite |
Version: 1.0.0 Last Updated: 2026-02-27 Source: Adapted from smart-ralph structured task format