[Issue #42] Update /retro command to store learnings and create encoding issues #49

Merged
HugoNijhuis merged 1 commits from issue-42-retro-learnings into main 2026-01-07 19:28:48 +00:00
Owner

Closes #42

Summary

Updates /retro command to store learnings in the learnings/ folder and create encoding issues to update skills/commands/agents.

New Flow

  1. Gather context → 2. Reflect → 3. Identify learnings → 4. Store learning file → 5. Create encoding issue → 6. Update learning with issue ref → 7. Connect to vision

Key Additions

  • Learning file template: Date, Context, Learning, Encoded In, Governance sections
  • Encoding issue template: References learning file, specifies target skill/command/agent
  • Cross-references: Learning file ↔ Issue for traceability
  • Encoding destinations table: Where different types of learnings should be encoded
  • Architecture vs Product repo guidance: Different workflows for each

Test Plan

  • /retro creates learning file in learnings/
  • /retro creates issue to encode learning into skill/command/agent
  • Learning file references the encoding issue
  • Encoding issue references the learning file
  • Flow handles both architecture repo and product repos

🤖 Generated with Claude Code

Closes #42 ## Summary Updates `/retro` command to store learnings in the `learnings/` folder and create encoding issues to update skills/commands/agents. ## New Flow 1. Gather context → 2. Reflect → 3. Identify learnings → 4. **Store learning file** → 5. **Create encoding issue** → 6. Update learning with issue ref → 7. Connect to vision ## Key Additions - **Learning file template**: Date, Context, Learning, Encoded In, Governance sections - **Encoding issue template**: References learning file, specifies target skill/command/agent - **Cross-references**: Learning file ↔ Issue for traceability - **Encoding destinations table**: Where different types of learnings should be encoded - **Architecture vs Product repo guidance**: Different workflows for each ## Test Plan - [x] /retro creates learning file in learnings/ - [x] /retro creates issue to encode learning into skill/command/agent - [x] Learning file references the encoding issue - [x] Encoding issue references the learning file - [x] Flow handles both architecture repo and product repos 🤖 Generated with [Claude Code](https://claude.com/claude-code)
HugoNijhuis added 1 commit 2026-01-07 19:27:46 +00:00
Restructured retro flow to:
1. Store learnings in learnings/ folder (historical + governance)
2. Create encoding issues to update skills/commands/agents
3. Cross-reference between learning files and issues
4. Handle both architecture and product repos differently

Key changes:
- Learning file template with Date, Context, Learning, Encoded In, Governance
- Encoding issue template referencing the learning file
- Encoding destinations table (skill/command/agent/manifesto/vision)
- Clear guidance for architecture vs product repo workflows
- Updated labels (learning instead of retrospective)

Closes #42

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Author
Owner

AI Code Review

This is an automated review generated by the code-reviewer agent.

Summary

Solid implementation of the learning capture flow. The cross-referencing structure is clear, and the architecture vs product repo guidance is well-defined. A few minor suggestions for completeness.

Findings

Code Quality

  • Well-structured flow: The 7-step process (gather → reflect → identify → store → create issue → update → vision) is logical and complete.
  • Good separation of concerns: Learning files serve as historical record, while encoding issues drive actionable changes.
  • Clear examples: The templates and bash examples make the process concrete.

Completeness of Learning Flow

  • Strong bidirectional references: Learning file → Issue (in "Encoded In") and Issue → Learning file (in description). This traceability is excellent.
  • Missing step details: Step 6 says "Update learning file" but doesn't show the bash command to edit it. Consider adding: Edit learnings/YYYY-MM-DD-short-title.md to replace "Pending: Issue #XX" with the actual issue number.
  • Label application: Step 5 shows issue creation but doesn't include --labels flag. The Labels section mentions labels but they're not in the example command.

Architecture vs Product Repo Guidance

  • Clear distinction: The guidance clearly separates where learning files go (architecture repo) vs where vision changes go (manifesto.md vs vision.md).
  • One ambiguity: In product repos, the instruction says "learning files should be added to the architecture repo" but doesn't specify how (switch repos? note it down? create PR?). Consider clarifying the workflow.

Cross-References

  • Excellent two-way linking: Issue references learning file path, learning file references issue number. This creates a strong audit trail.
  • README reinforcement: The learnings/README.md explains the "why" behind the flow, which helps future users understand the governance intent.

Style Notes

  • Consistent markdown formatting and code block usage throughout.
  • The encoding destinations table is duplicated (lines 90-98 and in learnings/README.md), which is intentional redundancy for discoverability.

Verdict

LGTM

The learning capture flow is complete and well-structured. Cross-references are clear and bidirectional. The architecture vs product repo guidance effectively addresses the multi-repo scenario. Minor suggestions above would improve clarity but aren't blocking.

## AI Code Review > This is an automated review generated by the code-reviewer agent. ### Summary Solid implementation of the learning capture flow. The cross-referencing structure is clear, and the architecture vs product repo guidance is well-defined. A few minor suggestions for completeness. ### Findings #### Code Quality - **Well-structured flow**: The 7-step process (gather → reflect → identify → store → create issue → update → vision) is logical and complete. - **Good separation of concerns**: Learning files serve as historical record, while encoding issues drive actionable changes. - **Clear examples**: The templates and bash examples make the process concrete. #### Completeness of Learning Flow - **Strong bidirectional references**: Learning file → Issue (in "Encoded In") and Issue → Learning file (in description). This traceability is excellent. - **Missing step details**: Step 6 says "Update learning file" but doesn't show the bash command to edit it. Consider adding: `Edit learnings/YYYY-MM-DD-short-title.md to replace "Pending: Issue #XX" with the actual issue number`. - **Label application**: Step 5 shows issue creation but doesn't include `--labels` flag. The Labels section mentions labels but they're not in the example command. #### Architecture vs Product Repo Guidance - **Clear distinction**: The guidance clearly separates where learning files go (architecture repo) vs where vision changes go (manifesto.md vs vision.md). - **One ambiguity**: In product repos, the instruction says "learning files should be added to the architecture repo" but doesn't specify *how* (switch repos? note it down? create PR?). Consider clarifying the workflow. #### Cross-References - **Excellent two-way linking**: Issue references learning file path, learning file references issue number. This creates a strong audit trail. - **README reinforcement**: The learnings/README.md explains the "why" behind the flow, which helps future users understand the governance intent. #### Style Notes - Consistent markdown formatting and code block usage throughout. - The encoding destinations table is duplicated (lines 90-98 and in learnings/README.md), which is intentional redundancy for discoverability. ### Verdict **LGTM** The learning capture flow is complete and well-structured. Cross-references are clear and bidirectional. The architecture vs product repo guidance effectively addresses the multi-repo scenario. Minor suggestions above would improve clarity but aren't blocking.
HugoNijhuis merged commit 8868eedc31 into main 2026-01-07 19:28:48 +00:00
Sign in to join this conversation.
No Reviewers
No Label
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: flowmade-one/architecture#49