一键导入
implement-spec
Execute an approved spec plan, implementing each task in sequence with mandatory build/test verification before reporting completion.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Execute an approved spec plan, implementing each task in sequence with mandatory build/test verification before reporting completion.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use this skill when the user wants to save, update, or reference visual design assets for the project. Triggers on "save design", "update designs", "sync designs", "add visual", "design assets", "claude design export", "design folder", "/design". Also fires proactively when the agent is about to write UI code (React components, CSS, Tailwind classes, layout) — in that case, read the active design first so code matches the visual spec. The design folder is always at `.pi/design/` and the agent should always check it before writing any UI-facing code.
Pointer to the jsdoc-conventions standards file. Read this before writing or editing any JSDoc in a project.
Pointer to the spec-structure standards file. Read this before writing or editing any implementation spec.
Port new paradigms from the global base harness (~/.pi/agent/) into the current project's .pi/ harness, adapting them to match the project's stack, workflow tier, and conventions. Run in any project to pull in improvements made to another project's harness.
Break down a spec.md or requirements.md into an actionable tasks.md with strategic grouping and ordering. Used after spec creation and before implementation.
Detect the project type from code signals and reorganize standards folders to match — web app, backend API, CLI, library, dotfiles, mobile, or monorepo.
| name | implement-spec |
| description | Execute an approved spec plan, implementing each task in sequence with mandatory build/test verification before reporting completion. |
Execute an approved spec plan, implementing each task in sequence.
This command automatically enters Build mode. If you are currently in plan mode, exit plan mode and switch to build mode before proceeding.
This command requires an existing spec with a plan. Check for:
agent-os/specs/plan.md file within the spec folderIf no spec exists:
No spec found. Run /shape-spec first to create a plan, then return here to implement it.
Check agent-os/specs/ for available specs. If multiple exist, use AskUserQuestion:
I found these specs:
1. **2026-01-15-1430-user-comment-system** — User commenting feature
2. **2026-01-14-0900-auth-improvements** — Authentication flow updates
Which spec should we implement? (1, 2, or specify path)
If only one spec exists, confirm it:
Found spec: agent-os/specs/2026-01-15-1430-user-comment-system/
Implement this spec? (yes / or specify different path)
Read the plan.md file from the selected spec folder. Parse the tasks and present a summary:
Loaded plan for: User Comment System
Tasks to implement:
1. Save Spec Documentation [if not already done]
2. Create comment model and database migration
3. Build comment API endpoints
4. Add comment UI components
5. Write tests for comment functionality
Ready to begin implementation? (yes / review plan first)
If they want to review, show the full plan content.
Read standards.md from the spec folder to understand which standards apply. Keep these in context during implementation.
If standards.md doesn't exist, check agent-os/standards/index.yml and use AskUserQuestion to confirm relevant standards before proceeding.
For each task in the plan:
Starting Task 2: Create comment model and database migration
This task involves:
- Creating the Comment model with fields for content, author, timestamps
- Writing the database migration
- Following the migration patterns from our standards
Execute the implementation:
✓ Task 2 Complete: Create comment model and database migration
Created:
- src/models/comment.ts
- src/db/migrations/20260115_create_comments.ts
Moving to Task 3...
If a task can't be completed, stop and use AskUserQuestion:
⚠️ Blocked on Task 3: Build comment API endpoints
Issue: The user model doesn't have an `id` field that the comment model references.
Options:
1. Add `id` field to user model first
2. Skip this task and continue
3. Modify the approach (I'll explain alternatives)
How should we proceed?
CRITICAL: Before reporting completion, you MUST run these commands and ensure they all pass. Do NOT skip this step. Do NOT report success if any command fails.
Build all affected packages:
pnpm build
If build fails, fix the errors before proceeding.
Run all tests:
pnpm test
If any tests fail, fix them. This includes tests that were broken by your changes — update test assertions to match the new behavior. Never leave failing tests.
Only after both pass, proceed to the final summary.
If a test or build failure is unrelated to your changes (pre-existing failure), note it explicitly but still attempt to fix it if possible.
After all tasks complete AND verification passes:
✓ Implementation Complete
Spec: User Comment System
Tasks completed: 5/5
Verification: ✓ build passed, ✓ tests passed (586 tests)
Files created:
- src/models/comment.ts
- src/db/migrations/20260115_create_comments.ts
- src/api/comments.ts
- src/components/CommentList.tsx
- src/components/CommentForm.tsx
- tests/comments.test.ts
Files modified:
- src/api/index.ts (added comment routes)
- src/models/index.ts (exported Comment model)
Next steps:
- Review the changes before committing
- Consider running /discover-standards if new patterns emerged
Sometimes the plan needs adjustment during implementation. Handle these cases:
If a small change is needed (different file name, additional import):
If a major change is needed (different approach, missing dependency, architectural issue):
If implementation reveals additional work needed:
During Task 3, I discovered we also need:
- A notification system for new comments
- Rate limiting on the comment API
Options:
1. Add these as new tasks and continue
2. Note them for a future spec
3. Skip for now, handle separately
How should we handle these?
During implementation:
Note: I'm using a consistent error handling pattern here that might be worth documenting.
After implementation, consider running /discover-standards on the API code.