القائمة
Create an implementation plan from a spec or requirements before touching code
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Multi-expert AI/ML specification review with scoring gate — model architecture, evaluation rigor, safety/alignment, and production readiness for AI systems and LLM apps
Multi-expert architecture review — boundaries, integration patterns, failure modes, evolvability
Multi-expert business analysis with advisory recommendations (no scoring gate)
Multi-expert intelligence pipeline review — discovery quality, ingestion resilience, scoring validity, platform compliance, taxonomy coherence, cost efficiency
Multi-expert mobile/native app specification review with scoring gate — Android, iOS, Swift, SwiftUI
Multi-expert personal-development review with scoring gate — learnability, adoption, human-centeredness, and capability impact for talent/learning/AI-augmentation designs
| name | sh-plan |
| description | Create an implementation plan from a spec or requirements before touching code |
Write comprehensive implementation plans assuming the engineer has zero context for our codebase and questionable taste. Document everything they need to know: which files to touch for each task, code, testing, docs they might need to check, how to test it. Give them the whole plan as bite-sized tasks. DRY. YAGNI. TDD. Frequent commits.
Assume they are a skilled developer, but know almost nothing about our toolset or problem domain. Assume they don't know good test design very well.
Announce at start: "I'm using the sh:plan skill to create the implementation plan."
Save plans to: docs/plans/YYYY-MM-DD-<feature-name>.md
If the spec covers multiple independent subsystems, suggest breaking this into separate plans -- one per subsystem. Each plan should produce working, testable software on its own.
Before defining tasks, map out which files will be created or modified and what each one is responsible for. This is where decomposition decisions get locked in.
This structure informs the task decomposition. Each task should produce self-contained changes that make sense independently.
Each step is one action (2-5 minutes):
Every plan MUST start with this header:
# [Feature Name] Implementation Plan
> **For agentic workers:** REQUIRED: Use `/sh:execute` to implement this plan. Steps use checkbox (`- [ ]`) syntax for tracking.
**Goal:** [One sentence describing what this builds]
**Architecture:** [2-3 sentences about approach]
**Tech Stack:** [Key technologies/libraries]
---
### Task N: [Component Name]
**Files:**
- Create: `exact/path/to/file.py`
- Modify: `exact/path/to/existing.py:123-145`
- Test: `tests/exact/path/to/test.py`
- [ ] **Step 1: Write the failing test**
```python
def test_specific_behavior():
result = function(input)
assert result == expected
```
- [ ] **Step 2: Run test to verify it fails**
Run: `pytest tests/path/test.py::test_name -v`
Expected: FAIL with "function not defined"
- [ ] **Step 3: Write minimal implementation**
```python
def function(input):
return expected
```
- [ ] **Step 4: Run test to verify it passes**
Run: `pytest tests/path/test.py::test_name -v`
Expected: PASS
- [ ] **Step 5: Commit**
```bash
git add tests/path/test.py src/path/file.py
git commit -m "feat: add specific feature"
```
After completing each chunk of the plan:
Chunk boundaries: Use ## Chunk N: <name> headings to delimit chunks. Each chunk should be logically self-contained.
After saving the plan:
"Plan complete and saved to docs/plans/<filename>.md. Ready to execute?"
Execution path:
If subagents are available:
/sh:parallel to dispatch independent tasks concurrentlyIf no subagents:
/sh:execute