javeedishaq/wip-lifecycle-manager
skills/ballee/wip-lifecycle-manager/SKILL.md
Manage WIP document lifecycle: create, track, review, and archive work-in-progress documentation; use when starting features, reviewing active WIPs, or archiving completed work (project)
$ install --global
skillsauthnpx skillsauth add javeedishaq/ai-workflow-orchestrator wip-lifecycle-managerInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: Apr 6, 2026, 3:10 AM9.0s5 files scanned
SKILL.md
- name:
- wip-lifecycle-manager
- description:
- Manage WIP document lifecycle: create, track, review, and archive work-in-progress documentation; use when starting features, reviewing active WIPs, or archiving completed work (project)
- version:
- 2.0.0
WIP Lifecycle Manager
Manage work-in-progress documentation for multi-step tasks, features, and investigations.
Quick Commands
# List all active WIPs with status
./scripts/wip-list.sh
# Review WIPs and identify completable ones
./scripts/wip-review.sh
# Archive completed WIPs
./scripts/wip-archive.sh "WIP_feature_name_2025_12_24.md"
# Create new WIP from template
./scripts/wip-create.sh "implementing_new_feature"
When to Use WIPs
DO create a WIP for:
- Multi-step features (3+ implementation steps)
- Database migrations with service/UI changes
- Bug investigations requiring research
- Architecture decisions
- Mobile + Web parallel implementations
DON'T create a WIP for:
- Single-file changes
- Trivial bug fixes
- Quick refactors
- Documentation updates
Directory Structure
docs/wip/
├── active/ # Currently being worked on
├── archive/
│ └── 2025-12/ # Organized by month
└── README.md # Index of active WIPs
Naming Convention
Format: WIP_{gerund_description}_{YYYY_MM_DD}.md
Examples:
WIP_implementing_feedback_system_2025_12_19.mdWIP_fixing_rls_policy_issues_2025_12_18.mdWIP_building_mobile_app_2025_12_21.md
Rules:
- Use gerund form (ending in -ing)
- Underscores between words
- Date is creation date (never changes)
- NEVER use version suffixes (-v2, -new, -improved)
WIP Template
# WIP: {Feature Name in Title Case}
**Created**: {YYYY-MM-DD}
**Last Updated**: {YYYY-MM-DD}
**Status**: In Progress | On Hold | Complete
**Priority**: P0 (Critical) | P1 (High) | P2 (Medium) | P3 (Low)
**Target Completion**: {YYYY-MM-DD} (optional)
## Objective
One paragraph describing what we're building and why.
## Progress Tracker
| Phase | Status | Description |
|-------|--------|-------------|
| Phase 1: Database | Complete | Migrations and RLS |
| Phase 2: Service | In Progress | Business logic |
| Phase 3: UI | Pending | Components and forms |
| Phase 4: Testing | Pending | E2E tests |
## Implementation Details
### Phase 1: Database (Complete)
- [x] Create migration `20251224_add_feature.sql`
- [x] Add RLS policies
- [x] Regenerate types
### Phase 2: Service (In Progress)
- [x] Create `feature.service.ts`
- [ ] Implement core methods
- [ ] Add error handling
### Phase 3: UI (Pending)
- [ ] Create form component
- [ ] Add to page
- [ ] Wire up actions
## Files Modified
| File | Change |
|------|--------|
| `supabase/migrations/...` | Added feature table |
| `services/feature.service.ts` | New service |
## Decisions & Notes
- Decision 1: Why we chose approach X over Y
- Note: Important gotcha discovered
## Completion Criteria
- [ ] All phases complete
- [ ] Tests passing
- [ ] Types regenerated
- [ ] Verified in staging
Lifecycle Workflow
1. Create
# Option A: Use script
./scripts/wip-create.sh "implementing_user_auth"
# Option B: Manual
touch docs/wip/active/WIP_implementing_user_auth_2025_12_24.md
2. Track Progress
Update the WIP as you work:
- Mark tasks complete with
[x] - Update phase statuses
- Add notes and decisions
- Update "Last Updated" date
3. Review
# Check all WIPs for completeness
./scripts/wip-review.sh
Indicators a WIP is complete:
- All
[ ]boxes checked - All phases marked "Complete"
- Status says "Complete"
- Target completion date passed
4. Archive
# Archive a single WIP
./scripts/wip-archive.sh "WIP_feature_2025_12_20.md"
# Archive multiple
./scripts/wip-archive.sh "WIP_a.md" "WIP_b.md" "WIP_c.md"
This moves files to docs/wip/archive/YYYY-MM/.
Status Definitions
| Status | Meaning | Action | |--------|---------|--------| | In Progress | Actively being worked on | Continue work | | On Hold | Paused intentionally | Document why, resume later | | Blocked | Cannot proceed | Document blocker, escalate | | Complete | All work done | Archive within 1 week |
Best Practices
DO
- Update WIP before ending work session
- Mark tasks complete immediately (not in batches)
- Document decisions and gotchas
- Link to related issues/PRs
- Archive promptly when complete
DON'T
- Create WIP for trivial work
- Let completed WIPs sit in active/
- Create multiple WIPs for same feature
- Use version suffixes in names
- Leave WIPs without status updates for weeks
Monthly Maintenance
Run on the 1st of each month:
# 1. Review all active WIPs
./scripts/wip-review.sh
# 2. Archive any completed ones
./scripts/wip-archive.sh <files...>
# 3. Update docs/wip/README.md if needed
Integration with Claude
When starting multi-step work, Claude should:
- Check for existing WIP:
ls docs/wip/active/ - Create WIP if none exists for the task
- Update WIP as phases complete
- Suggest archiving when all criteria met
Related Skills
database-migration-manager- For database phasesservice-patterns- For service layer phasesui-patterns- For UI phasestest-patterns- For testing phases
Related Skills
javeedishaq/templates/skills/test-patterns
tools
VerifiedTrustedCommunity
# Test Patterns Testing patterns for reliable, maintainable, and fast tests. > **Template Usage:** Customize for your test framework (Vitest, Jest, Playwright, etc.) and assertion library. ## Test Structure ```typescript // user.test.ts import { describe, it, expect, beforeEach, afterEach } from 'vitest'; import { userService } from '@/services/user.service'; import { createTestUser, cleanupTestData } from '@/tests/helpers'; describe('UserService', () => { let testUserId: string; befor
1SKILL.mdUpdated Apr 6, 2026
javeedishaq/templates/skills/state-management
tools
VerifiedTrustedCommunity
# State Management Patterns Client-side state management patterns for modern applications. > **Template Usage:** Customize for your state library (React Query, Zustand, Jotai, Redux, etc.). ## State Categories | Type | Description | Solution | |------|-------------|----------| | **Server State** | Data from API/database | React Query, SWR | | **Client State** | UI state, user preferences | Zustand, Jotai, useState | | **Form State** | Form inputs, validation | React Hook Form, Formik | | **U
1SKILL.mdUpdated Apr 6, 2026
javeedishaq/templates/skills/service-patterns
development
VerifiedTrustedCommunity
# Service Patterns Service layer patterns for clean architecture with proper error handling, logging, and type safety. > **Template Usage:** Customize for your ORM (Prisma, Drizzle, TypeORM, etc.) and logging solution. ## Result Type Pattern Never throw exceptions from services. Always return a Result type. ```typescript // lib/result.ts export type Result<T, E = Error> = | { success: true; data: T } | { success: false; error: E }; export function ok<T>(data: T): Result<T, never> { r
1SKILL.mdUpdated Apr 6, 2026
javeedishaq/templates/skills/rls-security
testing
VerifiedTrustedCommunity
# Row-Level Security Patterns Database security patterns for multi-tenant and user-scoped data. > **Template Usage:** Customize for your database (PostgreSQL, Supabase, etc.) and auth system. ## RLS Fundamentals ### Enable RLS on Tables ```sql -- Enable RLS (required before policies take effect) ALTER TABLE users ENABLE ROW LEVEL SECURITY; ALTER TABLE posts ENABLE ROW LEVEL SECURITY; ALTER TABLE comments ENABLE ROW LEVEL SECURITY; -- Force RLS for table owners too (recommended) ALTER TABLE
1SKILL.mdUpdated Apr 6, 2026