skillstore-cli 1.0.0

package/data/free-skills/devflow-postproject/plugin/skills/retrospective/SKILL.md

@@ -0,0 +1,70 @@
+---
+name: retrospective
+description: Conduct project retrospectives — gather lessons learned, identify process improvements, and collect team feedback.
+---
+
+# Project Retrospective
+
+## Triggers
+
+- Project completion and final delivery
+- Phase or milestone completion
+- Major incident resolution (post-mortem)
+- Quarterly team review
+
+## Process
+
+### 1. Data Gathering
+
+Collect objective data before the session:
+
+- Project metrics (velocity, defect rate, release frequency, budget vs actual)
+- Timeline of key events (milestones, scope changes, incidents, team changes)
+- Client feedback received during the project
+- Team survey results (anonymous, collected beforehand)
+- Sprint retrospective action items and their completion rate
+
+### 2. Insight Generation
+
+Facilitate a structured discussion (60-90 minutes):
+
+- Use a retrospective technique suited to the project (see references)
+- Focus on patterns, not individual events
+- Separate observations from opinions
+- Capture both process and technical insights
+- Ensure every team member contributes (use round-robin or anonymous input)
+
+### 3. Action Planning
+
+Convert insights into concrete actions:
+
+- Each action item must be SMART (Specific, Measurable, Achievable, Relevant, Time-bound)
+- Assign an owner to every action item
+- Limit to 5-7 high-impact items (do not overcommit)
+- Distinguish project-level vs organization-level improvements
+- Set a follow-up date to review progress
+
+### 4. Documentation
+
+Produce the lessons learned report:
+
+- Project summary and context
+- What went well (with evidence)
+- What could be improved (with root cause)
+- Key decisions and their outcomes
+- Actionable recommendations
+- Share with project team, management, and knowledge base
+
+## Key Principles
+
+- **Blameless**: Focus on systems and processes, not individuals.
+- **Evidence-based**: Back observations with data and specific examples.
+- **Forward-looking**: The goal is to improve future projects, not to judge the past.
+- **Inclusive**: Every role (dev, QA, PM, design, DevOps) brings a unique perspective.
+- **Action-oriented**: A retrospective without action items is just a complaint session.
+
+## References
+
+- `references/retro-techniques.md` — Facilitation formats and tools
+- `references/lessons-learned-template.md` — Documentation template
+- `assets/sample-output.md` — Example retrospective report

package/data/free-skills/devflow-postproject/plugin/skills/retrospective/assets/sample-output.md

@@ -0,0 +1,79 @@
+---
+name: sample-retrospective
+description: Sample project retrospective for a Mobile Banking App project with lessons learned and action items.
+---
+
+# Project Retrospective — Mobile Banking App
+
+**Project**: SecureBank Mobile App v1.0
+**Client**: SecureBank Financial Services
+**Duration**: 2025-06-01 to 2025-12-20 (7 months)
+**Team**: 12 members (4 backend, 3 mobile, 2 QA, 1 DevOps, 1 BA, 1 PM)
+**Stack**: React Native, Node.js, PostgreSQL, AWS, Plaid API
+
+---
+
+## Project Summary
+
+Delivered a mobile banking app with account management, fund transfers, bill payments, and spending analytics. Fixed-price contract. Launched on schedule with 2 weeks buffer used for performance optimization. Client rated delivery 4.2/5 overall.
+
+## What Went Well
+
+| # | Area | What Happened | Evidence |
+|---|---|---|---|
+| 1 | Architecture | Modular API design allowed parallel development across features | 3 feature teams worked independently; zero merge conflicts on API contracts |
+| 2 | Testing | Early investment in E2E test suite caught 23 critical bugs before UAT | UAT defect rate: 0.8 bugs/story point (team average: 2.1) |
+| 3 | Client communication | Weekly demo + daily async updates via Slack kept client aligned | Zero scope disputes; all 4 change requests processed through CR workflow |
+| 4 | Security | Engaged security review at Sprint 3, not Sprint 10 | Passed PCI-DSS pre-assessment on first attempt; zero findings in pentest |
+| 5 | DevOps | CI/CD pipeline with automated security scanning from week 2 | Average deployment time: 12 minutes; 94 production deployments total |
+
+## What Could Be Improved
+
+| # | Area | What Happened | Root Cause | Improvement |
+|---|---|---|---|---|
+| 1 | Estimation | Fund transfer module took 2.5x estimated effort | Underestimated Plaid API integration complexity and edge cases | Add spike/POC for third-party API integrations before estimating |
+| 2 | Mobile testing | Delayed discovery of performance issues on older Android devices | Only tested on flagship devices until Sprint 8 | Define device matrix in Sprint 0; include budget Android devices from day 1 |
+| 3 | BA capacity | BA was shared across 2 projects; requirement gaps in Sprints 4-6 | Resource allocation; BA had conflicting priorities | Dedicated BA for fixed-price projects above 5-person team |
+| 4 | Timezone | 6-hour timezone gap caused 1-day delay on every blocker needing client input | Offshore-onshore model without overlap hours | Establish 2-hour daily overlap window; empower team to make low-risk decisions independently |
+
+## Key Decisions and Outcomes
+
+| Decision | Rationale | Outcome | Same Again? |
+|---|---|---|---|
+| React Native over native iOS + Android | Faster delivery, shared codebase, client budget constraint | Delivered on time; performance acceptable after optimization | Yes, for this scope. Would reconsider for graphics-heavy apps |
+| Plaid for banking integration | Client preference, market leader | Worked but integration was harder than expected. Documentation gaps | Yes, but add 40% buffer for integration effort |
+| Feature flags for gradual rollout | Reduce risk of big-bang launch | Caught a payment rounding bug affecting 2% of users before full rollout | Absolutely yes |
+
+## Team Feedback Summary (Anonymized)
+
+**Positive themes** (mentioned by 3+ people):
+- "Best CI/CD setup I have worked with — fast feedback loop"
+- "PM handled scope changes professionally — team was protected"
+- "Good knowledge sharing — pair programming sessions were valuable"
+
+**Improvement themes** (mentioned by 3+ people):
+- "Too many meetings on Tuesdays — lost half the day"
+- "Requirement documents arrived late for Sprints 4-6"
+- "Need better device lab for mobile testing"
+
+## Action Items
+
+| # | Action | Owner | Target | Priority |
+|---|---|---|---|---|
+| 1 | Create Plaid integration starter template for future banking projects | Tuan (Tech Lead) | 2026-01-15 | High |
+| 2 | Define standard device testing matrix for mobile projects | QA Lead | 2026-01-10 | High |
+| 3 | Update estimation playbook: add "third-party API complexity" factor | BA Team | 2026-01-31 | High |
+| 4 | Propose dedicated BA policy for fixed-price projects >5 people | Delivery Manager | 2026-02-01 | Medium |
+| 5 | Reduce recurring meetings — consolidate Tuesday syncs into 1 session | PM | Immediate | Medium |
+| 6 | Add React Native performance testing to CI pipeline template | DevOps | 2026-02-15 | Medium |
+
+## Metrics Summary
+
+| Metric | Planned | Actual |
+|---|---|---|
+| Duration | 28 weeks | 29 weeks (1 week buffer used) |
+| Budget | $480,000 | $465,000 (3% under) |
+| Story points delivered | 340 | 358 (includes 4 CRs) |
+| Production defects (first 30 days) | — | 3 (1 P3, 2 P4) |
+| Client satisfaction | — | 4.2 / 5.0 |
+| Team satisfaction | — | 4.0 / 5.0 |

package/data/free-skills/devflow-postproject/plugin/skills/retrospective/references/facilitation-techniques.md

@@ -0,0 +1,178 @@
+---
+name: facilitation-techniques
+description: Advanced retrospective facilitation techniques — 4Ls, Sailboat, Timeline, Mad/Sad/Glad, distributed adaptations, and action item tracking.
+---
+
+# Retrospective Facilitation Techniques (Advanced)
+
+## 4Ls Technique (Liked, Learned, Lacked, Longed For)
+
+Best for: End-of-project retros, milestone reviews, teams wanting structured reflection.
+
+### Setup
+1. Create a board (physical or digital) with 4 columns
+2. Label each column: Liked, Learned, Lacked, Longed For
+3. Distribute sticky notes / cards (3-5 per person per column)
+4. Set a visible timer for each phase
+
+### Facilitation Script
+
+| Phase | Duration | Facilitator Action |
+|-------|----------|-------------------|
+| Introduction | 3 min | Explain the 4 columns, give examples for each, set ground rules (no blame, be specific) |
+| Silent writing | 10 min | Everyone writes independently. No talking. Play ambient music if in-person |
+| Liked | 8 min | Each person shares their Liked items. Facilitator groups similar items. No debate yet |
+| Learned | 8 min | Share Learned items. Highlight learnings that should be carried to next project |
+| Lacked | 8 min | Share Lacked items. Facilitator notes patterns. Encourage "I needed X" not "You failed to give X" |
+| Longed For | 8 min | Share Longed For items. Focus on forward-looking wishes, not complaints |
+| Dot voting | 5 min | Each person gets 5 votes across all columns. Vote on items most important to act on |
+| Action planning | 10 min | Top 3-5 voted items become action items. Assign owners and deadlines |
+
+**Total time**: 60 minutes.
+
+### Tip
+Combine "Lacked" and "Longed For" findings — Lacked identifies the gap, Longed For often suggests the solution.
+
+## Sailboat Technique
+
+Best for: Visual teams, complex projects, identifying both enablers and blockers simultaneously.
+
+### Visual Diagram
+
+```
+                  🏝️ ISLAND (Goal/Destination)
+                     /
+                    /
+    ⛵ SAILBOAT ---/
+   /  |  \
+  /   |   \        💨 WIND (Helps us move forward)
+ /    |    \         - Good practices
+      |               - Helpful tools
+      |               - Supportive people
+   ⚓ ANCHOR
+   (Holds us back)     🪨 ROCKS (Hidden risks)
+      - Blockers          - Near-misses
+      - Inefficiencies    - Potential dangers
+      - Process gaps      - Technical debt
+```
+
+### Facilitation Steps
+
+1. **Draw the sailboat** on a whiteboard or shared canvas (5 min)
+2. **Explain the metaphor** — the boat is the team, we are sailing toward the island (our goal) (3 min)
+3. **Silent brainstorming** — each person writes items for all 4 elements (10 min)
+4. **Wind discussion** — what propelled us forward? Group and discuss (8 min)
+5. **Anchor discussion** — what held us back? Be specific about impact (8 min)
+6. **Rocks discussion** — what risks did we encounter or narrowly avoid? (8 min)
+7. **Island discussion** — did we reach our destination? What changed along the way? (5 min)
+8. **Prioritize and plan** — dot vote, create action items (10 min)
+
+**Total time**: 55-60 minutes.
+
+## Timeline Technique
+
+Best for: Long projects (3+ months), projects with many phases, understanding cause-and-effect.
+
+### Setup
+1. Draw a horizontal timeline on a large surface (whiteboard, Miro board)
+2. Mark project milestones: kickoff, sprints, releases, major events
+3. Prepare two colors of sticky notes: green (positive events), red (negative events)
+
+### Facilitation Steps
+
+| Phase | Duration | Activity |
+|-------|----------|----------|
+| Setup | 5 min | Draw timeline with milestones. Explain the exercise |
+| Individual mapping | 15 min | Each person places events on the timeline (silent) |
+| Walk-through | 20 min | Walk chronologically. Read each note. Author elaborates briefly |
+| Pattern identification | 10 min | Look for clusters. Ask: "What caused this group of issues in Sprint 3?" |
+| Metric correlation | 5 min | Overlay velocity, bug count, or team mood data if available |
+| Root cause analysis | 10 min | For the top 3 problem clusters, ask "5 Whys" |
+| Action items | 10 min | Convert root causes into preventive actions for future projects |
+
+**Total time**: 75 minutes.
+
+### Pattern Signals to Watch For
+- **Cluster of red notes** around a specific date — indicates a systemic issue, not isolated incidents
+- **Green-to-red transition** — something changed; identify what triggered the shift
+- **Recurring themes** across multiple sprints — indicates unresolved root cause
+- **Silent periods** — no notes may mean disengagement, not smooth sailing
+
+## Mad / Sad / Glad
+
+Best for: Short retros (30 min), sprint retros, quick pulse checks.
+
+| Column | Prompt | Example |
+|--------|--------|---------|
+| **Mad** | What frustrated you? What made you angry? | "Deploy process took 2 hours every time" |
+| **Sad** | What disappointed you? What could have been better? | "We didn't get to implement the feature we planned" |
+| **Glad** | What made you happy? What went well? | "Pair programming sessions were really productive" |
+
+**Format**: 5 min write, 10 min share and group, 5 min vote, 10 min action planning.
+
+**When to use over other techniques**: When time is limited, when the team needs emotional release, when you want a low-overhead format that still produces action items.
+
+## Facilitation Best Practices
+
+### Timeboxing
+- **Set a visible timer** for every phase — teams respect time when they can see it counting down
+- **Announce transitions** clearly: "Writing time is over. Let's share Liked items now"
+- **Buffer 5 minutes** between discussion and action planning for mental transition
+- **Hard stop** — end on time even if discussion is ongoing. Capture remaining items in a parking lot
+
+### Dot Voting for Prioritization
+1. Give each participant **3-5 votes** (fewer votes = more focused prioritization)
+2. Allow **multi-voting** on a single item (max 2 votes per item per person)
+3. **Vote silently** — no campaigning for items before voting
+4. Tally immediately and announce top 5
+5. Only create action items for the **top 3** — better to do 3 well than 7 poorly
+
+### Silent Brainstorming Before Discussion
+- **Always start with silent writing** (5-10 min) before any verbal sharing
+- Prevents groupthink — introverts and junior members contribute their genuine thoughts
+- Prevents anchoring — the first speaker doesn't set the agenda for everyone
+- Produces 2-3x more unique items than open discussion alone
+
+## Distributed Team Adaptations
+
+### Async Retro Boards
+- **Miro / FigJam**: Create a template board, share link 2-3 days before the session. Team adds items async
+- **Notion / Confluence**: Create a page with sections. Team adds bullet points over 2 days
+- **RetroTool / EasyRetro**: Purpose-built async retro tools with anonymous mode and voting
+
+### Async-First Flow
+1. **Day 1-2**: Share the board. Team adds items asynchronously (no discussion yet)
+2. **Day 3**: Facilitator groups similar items, identifies themes
+3. **Day 3-4**: Team votes asynchronously (dot voting on the board)
+4. **Day 5**: 30-min synchronous call to discuss top-voted items and assign actions
+
+### Timezone-Fair Scheduling
+- **Rotate meeting times** — do not always favor one timezone
+- **Record sessions** (with consent) for team members who cannot attend
+- **Async follow-up** — post action items in a shared channel within 24 hours
+- **Equal voice** — if some people are async, ensure their written items get equal discussion time
+
+## Action Item Tracking
+
+### SMART Format for Retro Actions
+
+| Attribute | Question to Ask | Bad Example | Good Example |
+|-----------|----------------|-------------|--------------|
+| **Specific** | What exactly will we do? | "Improve communication" | "Create a #blockers Slack channel and post daily" |
+| **Measurable** | How will we know it's done? | "Write more tests" | "Increase API test coverage from 40% to 70%" |
+| **Achievable** | Can we do this in one sprint? | "Rewrite the monolith" | "Extract payment service into a separate module" |
+| **Relevant** | Does this address a top-voted retro item? | "Adopt a new framework" | "Add automated deploy to reduce 2-hour manual process" |
+| **Time-bound** | When will it be done? | "Soon" | "Complete by end of Sprint 12 (March 28)" |
+
+### Owner Assignment
+- Every action item **must have exactly one owner** (not "the team")
+- Owner is accountable for completion, not necessarily the sole doer
+- If no one volunteers, facilitator assigns based on expertise and capacity
+- Owner confirms acceptance before the retro ends
+
+### Follow-Up in Next Retro
+- **First 5 minutes** of every retro: review action items from the previous retro
+- Status for each item: Done / In Progress / Blocked / Dropped
+- **Track completion rate** — healthy teams complete 70%+ of retro action items
+- If an item is carried forward 3 times, either escalate it or consciously drop it
+- Maintain a running retro action log (spreadsheet or Jira board) visible to the whole team

package/data/free-skills/devflow-postproject/plugin/skills/retrospective/references/lessons-learned-template.md

@@ -0,0 +1,118 @@
+---
+name: lessons-learned-template
+description: Structured template for documenting lessons learned — project summary, outcomes, recommendations, and organizational action items.
+---
+
+# Lessons Learned Template
+
+## Project Summary
+
+| Field | Value |
+|---|---|
+| Project name | |
+| Client | |
+| Duration | Start date — End date |
+| Team size | Peak / Average |
+| Technology stack | |
+| Delivery model | Fixed price / T&M / Dedicated team |
+| Budget | Planned vs Actual |
+| Scope changes | Number of CRs, impact on timeline |
+
+## What Went Well
+
+For each item, include evidence or metrics:
+
+| # | Area | What Happened | Evidence / Metric |
+|---|---|---|---|
+| 1 | | | |
+| 2 | | | |
+| 3 | | | |
+
+Areas to consider: delivery speed, code quality, client communication, team collaboration, tooling, testing strategy, DevOps practices, requirement clarity.
+
+## What Could Be Improved
+
+For each item, identify root cause:
+
+| # | Area | What Happened | Root Cause | Suggested Improvement |
+|---|---|---|---|---|
+| 1 | | | | |
+| 2 | | | | |
+| 3 | | | | |
+
+Common root causes in ITO/outsourcing: timezone gap, unclear requirements, scope creep without CR process, insufficient domain knowledge, dependency on client for decisions, under-estimated complexity.
+
+## Key Decisions and Outcomes
+
+| Decision | When | Rationale | Outcome | Would We Decide the Same Again? |
+|---|---|---|---|---|
+| | | | | |
+
+Examples: technology choice, architectural pattern, team structure, process adoption, build vs buy.
+
+## Process Recommendations
+
+For future projects with similar characteristics:
+
+**Estimation**:
+- What estimation technique worked? What did not?
+- How accurate were initial estimates vs actuals?
+- Recommendations for buffer and contingency.
+
+**Development process**:
+- Sprint length that worked best
+- Code review practices that added value
+- Testing strategy effectiveness (unit, integration, E2E, manual)
+- CI/CD pipeline lessons
+
+**Communication**:
+- Meeting cadence that worked (too many, too few, just right)
+- Tools that helped vs added noise
+- Client communication frequency and format
+- Offshore-onshore collaboration patterns
+
+**Quality**:
+- Defect density trend
+- Production incidents caused by code vs infrastructure vs config
+- Test coverage targets and whether they were realistic
+
+## Technology Recommendations
+
+| Technology / Tool | Verdict | Notes |
+|---|---|---|
+| | Keep / Replace / Evaluate | |
+
+Capture: what worked, what caused pain, what you would choose differently.
+
+## Team Feedback Summary (Anonymized)
+
+Aggregate themes from anonymous team survey:
+
+**Positive themes**:
+- (e.g., "Good team collaboration", "PM shielded team from scope changes effectively")
+
+**Improvement themes**:
+- (e.g., "Requirements were often unclear", "Too many meetings broke focus time")
+
+**Individual growth**:
+- Skills gained by the team (new technologies, domain knowledge, soft skills)
+- Training needs identified for future projects
+
+## Action Items for Organization
+
+Items that go beyond this project — improvements for the company:
+
+| # | Action | Category | Owner | Target Date | Priority |
+|---|---|---|---|---|---|
+| 1 | | Process / Tooling / Training / Hiring | | | High / Medium / Low |
+| 2 | | | | | |
+| 3 | | | | | |
+
+## Distribution
+
+| Audience | Content | Format |
+|---|---|---|
+| Project team | Full report | Shared document |
+| Delivery management | Summary + recommendations | Presentation |
+| Sales / Pre-sales | Reusable case study material | Extracted highlights |
+| Organization knowledge base | Full report (anonymized if needed) | Wiki / Confluence |

package/data/free-skills/devflow-postproject/plugin/skills/retrospective/references/retro-techniques.md

@@ -0,0 +1,100 @@
+---
+name: retro-techniques
+description: Retrospective facilitation techniques — formats, prioritization, action planning, and remote facilitation tips.
+---
+
+# Retrospective Facilitation Techniques
+
+## Start / Stop / Continue
+
+Best for: Regular sprint retros, straightforward projects.
+
+| Column | Prompt |
+|---|---|
+| **Start** | What should we begin doing that we are not doing today? |
+| **Stop** | What should we stop doing because it hurts more than it helps? |
+| **Continue** | What is working well and should keep going? |
+
+Time: 10 min write, 15 min discuss, 10 min vote and plan.
+
+## 4Ls (Liked, Learned, Lacked, Longed For)
+
+Best for: End-of-project retros, teams new to retrospectives.
+
+| Column | Prompt |
+|---|---|
+| **Liked** | What did you enjoy or appreciate about this project? |
+| **Learned** | What new knowledge or skills did you gain? |
+| **Lacked** | What was missing that would have helped? |
+| **Longed for** | What do you wish had been different? |
+
+Time: 10 min write, 20 min discuss, 10 min actions.
+
+## Sailboat Method
+
+Best for: Visual thinkers, longer projects, identifying risks.
+
+Draw a sailboat with four elements:
+
+- **Wind** (sails): What helped us move forward? (tools, practices, people)
+- **Anchor**: What held us back? (blockers, inefficiencies, gaps)
+- **Rocks** (underwater): What risks almost hit us or could hit future projects?
+- **Island** (destination): What was our goal and did we reach it?
+
+Time: 5 min explain, 10 min write, 25 min discuss, 10 min actions.
+
+## Timeline Retrospective
+
+Best for: Long projects (6+ months), complex projects with many phases.
+
+1. Draw a horizontal timeline with project milestones
+2. Each team member adds sticky notes for key events (positive and negative)
+3. Walk through chronologically, discuss clusters and patterns
+4. Identify turning points and root causes
+
+Time: 60-90 min (longer format needed).
+
+## Dot Voting for Prioritization
+
+After collecting items in any format:
+
+1. Each participant gets 3-5 votes (dots)
+2. Vote on the items you think are most important to address
+3. Tally votes — top items become action candidates
+4. Discuss the top 5-7 voted items
+5. Convert to action items with owners
+
+This prevents endless discussion on low-impact items.
+
+## Action Item SMART Format
+
+Every action item should be:
+
+| Attribute | Bad Example | Good Example |
+|---|---|---|
+| **Specific** | "Improve testing" | "Add integration tests for payment flow" |
+| **Measurable** | "Write more tests" | "Increase payment module coverage from 45% to 80%" |
+| **Achievable** | "Achieve 100% coverage" | "Add 15 integration tests in next sprint" |
+| **Relevant** | "Rewrite the frontend" | "Add retry logic to prevent payment timeout recurrence" |
+| **Time-bound** | "Eventually" | "Complete by end of Sprint 24 (March 14)" |
+
+## Anonymous Feedback Collection
+
+When team dynamics might prevent open discussion:
+
+- **Pre-retro survey**: Send a Google Form or Typeform 2 days before the session with open-ended questions
+- **Anonymous board**: Use Miro, FigJam, or RetroTool with anonymous mode enabled
+- **Written-first format**: Everyone writes silently before any discussion begins
+- **Facilitator reads aloud**: Facilitator reads anonymous items so no one is identified by handwriting or typing style
+
+When to use anonymous: new teams, conflict situations, cross-cultural teams where hierarchy may suppress honest feedback.
+
+## Remote Retrospective Tips
+
+- **Use a shared board** (Miro, FigJam, Notion) — do not rely on verbal-only discussion
+- **Timebox strictly** — remote meetings lose energy faster than in-person
+- **Camera on** (if culturally appropriate) — non-verbal cues matter for sensitive topics
+- **Silent writing first** — prevents groupthink and ensures introverts contribute
+- **Breakout rooms** for large teams (>8 people) — discuss in groups of 3-4, then share back
+- **Record the session** (with consent) for absent members
+- **Follow up in writing** within 24 hours with action items and owners

package/data/free-skills/devflow-postproject/template/agents/transition-manager.md

@@ -0,0 +1,71 @@
+---
+name: transition-manager
+description: Use this agent to manage the complete post-project transition — coordinates handover, maintenance setup, retrospective, and client feedback activities. Best for end-of-project orchestration.
+tools: Glob, Grep, LS, Read, Edit, Write, WebFetch
+---
+
+You are a Senior Transition Manager with extensive experience in IT outsourcing project closures and transitions. You ensure smooth handovers, establish maintenance processes, capture lessons learned, and nurture client relationships.
+
+## Core Responsibilities
+
+### 1. Project Handover
+- Activate `handover` skill
+- Ensure all documentation is complete and accurate
+- Plan and track knowledge transfer sessions
+- Verify receiving team readiness
+
+### 2. Maintenance Setup
+- Activate `maintenance-support` skill
+- Define SLA agreements with client
+- Setup incident management process
+- Establish on-call and escalation procedures
+
+### 3. Retrospective Facilitation
+- Activate `retrospective` skill
+- Run project retrospective while context is fresh
+- Capture lessons learned for organizational knowledge base
+- Create improvement action items
+
+### 4. Client Relationship
+- Activate `client-feedback` skill
+- Collect client satisfaction data
+- Address concerns before contract closure
+- Identify and propose expansion opportunities
+
+## Operational Guidelines
+
+- Start retrospective early — don't wait until last day
+- Handover documentation should enable self-sufficiency
+- SLAs must be realistic and measurable
+- Client feedback should drive both immediate fixes and long-term improvements
+- Maintain professional relationship even during project closure
+
+## Error Recovery
+
+Reference: `rules/development-rules.md` and `protocols/error-recovery.md`
+
+### Retry Policy
+- Max retries: from config.thresholds.maxRetries (default: 3)
+- Between retries: analyze failure, adjust approach
+- After max retries: STOP, report with context
+
+### Escalation
+| Failure | Action |
+|---------|--------|
+| KT receiving team not understanding | Repeat session with different approach, max 2 repeats |
+| Missing documentation for handover | Flag as gap, create minimal doc, schedule follow-up |
+| SLA targets unrealistic | Present data to user, recommend adjusted targets |
+| Client feedback negative | Escalate immediately, don't wait for full analysis |
+
+## Checkpoint Protocol
+
+After completing each phase (Retrospective → Handover → Feedback → Maintenance):
+1. Save deliverable output
+2. Log: phase completed, key findings, pending items
+3. If interrupted: next session can resume from last completed phase
+
+## Model Usage
+- Documentation tasks: primary model
+- Survey/feedback analysis: primary model
+- Template filling: lightweight model
+- Fall back per config if primary unavailable