Claude-skill-registry aico-backend-plan
install
source · Clone the upstream repo
git clone https://github.com/majiayu000/claude-skill-registry
Claude Code · Install into ~/.claude/skills/
T=$(mktemp -d) && git clone --depth=1 https://github.com/majiayu000/claude-skill-registry "$T" && mkdir -p ~/.claude/skills && cp -r "$T/skills/data/aico-backend-plan" ~/.claude/skills/majiayu000-claude-skill-registry-aico-backend-plan && rm -rf "$T"
manifest:
skills/data/aico-backend-plan/SKILL.mdsource content
Plan
⚠️ CRITICAL RULES - READ FIRST
-
DETECT MODE: Determine if input is an existing task reference or a new requirement description
- If input looks like
orstory-user-api Task 1
: MODE Astandalone-fix-auth Task 2 - If input is a new requirement (e.g., "Add user authentication"): MODE B
- If input looks like
-
MODE A - Enhance Existing Task:
- Read the task file from
docs/reference/backend/tasks/ - User must specify task number (e.g., "Task 1", "Task 2")
- Add or update the "Implementation Steps" section for that specific task
- Keep all other sections intact
- Save back to the same file
- Read the task file from
-
MODE B - Create Standalone Task File:
- Analyze the requirement - is it simple (1 task) or complex (multiple tasks)?
- If complex, break into multiple tasks (like task-breakdown does)
- Use filename:
(kebab-case)standalone-{requirement-name}.md - Save to
docs/reference/backend/tasks/ - File format: same as story-based (multiple task sections)
-
READ CONSTRAINTS FIRST:
- Must read
for design tokensdocs/reference/backend/design-system.md - Must read
for tech stackdocs/reference/backend/constraints.md - If task references a design, read from
docs/reference/backend/designs/
- Must read
Language Configuration
Before generating any content, check
aico.json in project root for language field to determine the output language. If not set, default to English.
MODE A: Enhance Existing Task
Process
- Read task file: Get task details from
docs/reference/backend/tasks/{task-file}.md - Read design (if referenced): Load related design from
docs/reference/backend/designs/ - Read design system: Load
for design tokensdocs/reference/backend/design-system.md - Read constraints: Load
docs/reference/backend/constraints.md - Break into atomic steps:
- Start with file creation/setup
- One section/feature per step
- Include verification for each step
- Do NOT include commit step (that happens during execution)
- Keep steps atomic: One action per step
- Update task file: Add/replace "Implementation Steps" section
- Present summary: Show file location and what was added
Example
# Input: User runs /backend.plan story-user-profile-2-header # Output: ✓ Read task: docs/reference/backend/tasks/story-user-profile-2-header.md ✓ Added 4 implementation steps to task file Steps added: 1. Create component file 2. Implement header layout 3. Add responsive styles 4. Add unit tests Task ready for implementation. Use aico-backend-implement to execute.
MODE B: Create Standalone Task
Process
-
Ask user for details:
- Task type: feature | bugfix | improvement
- Confirm task name (auto-generate from description)
-
Read constraints:
- Read design system and technical constraints
- If user mentions a component, check existing code
-
Generate complete task file:
- All metadata (type, source, created, status)
- Description
- Context
- Acceptance Criteria
- Scope
- Implementation Steps (detailed, atomic)
- Notes
-
Save task file: Write to
docs/reference/backend/tasks/standalone-{task-name}.md -
Present summary: Show created file and next steps
Example
# Input: User runs /backend.plan "Fix login button hover state" # Interactive: # Type: [feature | bugfix | improvement] → bugfix # Task name: fix-login-button-hover (auto-generated, confirm?) # Output: ✓ Created standalone task: standalone-fix-login-button-hover.md Task includes: - Description and context - 2 acceptance criteria - 3 implementation steps - Test verification Next: Use aico-backend-implement to execute this task
Implementation Steps Format
Both modes use the same step format:
## Implementation Steps ### Step 1: [Action] **Files**: - Create: `src/components/[Name].tsx` - Modify: `src/pages/[Page].tsx:L10-L20` **Action**: [Exact code or action to take] **Verify**: ```bash [verification command] ```
Expected: [expected output]
Step 2: [Next Action]
...
## Step Granularity Each step = ONE atomic action: | Good Steps | Bad Steps | |------------|-----------| | Create component file with imports | Create component with all logic | | Add component skeleton (empty return) | Implement entire component | | Implement single section | Implement all sections | | Write one test case | Write all tests | ## Step Types ### Setup Step ```markdown **Files**: Create: `src/components/ProfileCard.tsx` **Action**: Create file with basic structure **Verify**: `npx tsc --noEmit` → No errors
Implementation Step
**Files**: Modify: `src/components/ProfileCard.tsx:L8-L10` **Action**: Implement header section with Avatar and name **Verify**: `npm run dev` → Component renders correctly
Test Step
**Files**: Create: `src/components/__tests__/ProfileCard.test.tsx` **Action**: Write unit test for profile name rendering **Verify**: `npm test ProfileCard` → 1 test passed
Standalone Task File Template
For MODE B, see Task File Template for complete structure.
Use the same format as story-based tasks, just with:
- Filename:
standalone-{requirement-name}.md - Header:
# Standalone Tasks: [Requirement Name] - No
line> **Story**: ...
Note: For simple requirements, file may contain only 1 task. For complex requirements, break into multiple tasks.
Key Rules
- ALWAYS include verification command for each step
- MUST keep steps to 2-5 minutes of work
- MUST save to docs/reference/backend/tasks/ directory
- NEVER combine multiple actions into one step
- Do NOT include commit step in plan (commits happen during execution)
- MODE A: Preserve all existing content, only add/update steps
- MODE B: Generate complete, self-contained task file
Common Mistakes
- ❌ Steps too large → ✅ One action per step
- ❌ Skip verification → ✅ Every step has verify command
- ❌ Vague actions → ✅ Include exact code
- ❌ Not saving to file → ✅ Always save task file
- ❌ Including commit in steps → ✅ Commits happen during execution, not planning
- ❌ MODE A: Overwriting existing content → ✅ Only update Implementation Steps section
- ❌ MODE B: Missing metadata → ✅ Include all template sections