iterate-lessons-log
The iterate-lessons-log skill structures knowledge capture from projects, incidents, or discoveries into organizational memory that persists beyond individual teams. Use it to document patterns, anti-patterns, and hard-won wisdom after project completion, major incidents, recurring problems, or when experienced team members depart. It differs from retrospectives, which facilitate team ceremonies, by creating durable entries with context, factual accounts, extracted lessons, recommendations, and applicability guidance that future teams can reference and apply.
git clone --depth 1 https://github.com/product-on-purpose/pm-skills /tmp/iterate-lessons-log && cp -r /tmp/iterate-lessons-log/skills/iterate-lessons-log ~/.claude/skills/iterate-lessons-logSKILL.md
<!-- PM-Skills | https://github.com/product-on-purpose/pm-skills | Apache 2.0 --> # Lessons Log A lessons log entry captures significant learning from projects, incidents, or experiences in a format that's useful to future teams who weren't there. Unlike retrospectives (which focus on team improvement), lessons logs focus on organizational knowledge that transcends individual teams.patterns, anti-patterns, and hard-won wisdom. ## When to Use - After completing a significant project or initiative - Following a major incident, outage, or failure - When you realize something important that others should know - After discovering a pattern that keeps recurring - When experienced team members leave (capture their knowledge) - During post-mortems to preserve learnings ## When NOT to Use - You are facilitating the team ceremony itself -> use `iterate-retrospective`; this skill banks the durable entry that outlives it - You are deciding whether to change direction based on results -> use `iterate-pivot-decision` - The learning is an experiment readout -> use `measure-experiment-results` first, then bank the transferable lesson here - You are updating stakeholders on what was learned -> use `foundation-stakeholder-update` ## Instructions When asked to create a lessons log entry, follow these steps: 1. **Choose a Descriptive Title** Write a title that someone searching for this topic would find. Include keywords that describe the situation and the learning. Avoid generic titles like "Project X lessons." 2. **Provide Context** Explain the situation fully enough that someone who wasn't there can understand it. Include the project, timeline, team, and any relevant constraints. Future readers need this context to assess applicability. 3. **Describe What Happened** Write a factual account of what occurred. Be specific about actions taken, decisions made, and outcomes observed. Avoid blame.focus on events and systems. 4. **Extract the Lesson** Articulate what you learned clearly. The lesson should be actionable.something others can apply. Distinguish between what you observed and your interpretation of why it matters. 5. **Formulate Recommendations** Provide specific guidance for future teams facing similar situations. What should they do? What should they avoid? What questions should they ask? 6. **Define Applicability** Help readers know when this lesson applies. What situations trigger relevance? What context makes it more or less applicable? 7. **Add Tags for Searchability** Include keywords and categories that will help future searchers find this entry. Think about what someone would search for when facing a similar situation. ## Output Format Use the template in `references/TEMPLATE.md` to structure the output. A complete entry fills every template section: Metadata; Summary; Context; What Happened; The Lesson; Recommendations; Applicability; Supporting Evidence; Tags and Categories; and Review and Updates. ## Quality Checklist Before finalizing, verify: - [ ] Title is descriptive and searchable - [ ] Context is complete enough for someone who wasn't there - [ ] Lesson is clearly articulated and actionable - [ ] Recommendations are specific, not vague - [ ] Entry stands alone (doesn't require external context) - [ ] Tags enable future discovery ## Examples See `references/EXAMPLE.md` for a completed example.
Run an ad-hoc ordered chain of pm-skills with shared context (ephemeral; routes to the pm-workflow-orchestrator)
Defines a testable hypothesis with clear success metrics and a validation approach. Use when forming assumptions to test or aligning a team on what success looks like, before any experiment is designed. To design the A/B test or experiment that will validate the hypothesis, use measure-experiment-design.
Creates a Jobs to be Done canvas capturing the functional, emotional, and social dimensions of a customer job. Use when deeply understanding customer motivations, designing for jobs, or reframing product positioning.
Creates an opportunity solution tree connecting a desired outcome to customer opportunities and candidate solutions, preventing solution-first jumps in continuous discovery. Use when structuring scattered feature ideas or communicating how the roadmap traces to outcomes. For ranking an existing flat list of candidates, use define-prioritization-framework instead; this skill discovers the list, it does not score one.
Run applicable prioritization frameworks (RICE, ICE, MoSCoW, Weighted Scoring, Kano) against a list of features or initiatives. Produces a comparison table showing where rankings agree and diverge across frameworks, and an executive summary with recommendation. Framework applicability is filtered by data availability; Kano requires customer research. Refuses to fabricate scores; produces an estimation scaffold when input data is missing.
Creates a clear problem framing document with user impact, business context, and success criteria. Use when starting a new initiative, realigning a drifted project, or communicating up to leadership.
Generates structured Given/When/Then acceptance criteria for a user story or feature slice, covering the happy path, key failure scenarios, and non-functional expectations in testable form. Use when turning requirements into verifiable scenarios for engineering handoff and QA sign-off. For a dedicated catalog of boundary conditions, error states, and recovery paths across a feature, use deliver-edge-cases; to write the stories themselves, use deliver-user-stories.
Documents edge cases, error states, boundary conditions, race conditions, and recovery paths for a feature - the systematic catalog of what can go wrong and the failure modes to design for. Use during specification to map the failure surface and ensure comprehensive coverage, or during QA planning to identify boundary and limit scenarios to test. Distinct from deliver-acceptance-criteria, which writes story-level Given/When/Then checks; this skill produces the whole-feature edge-case catalog.