Rule - Generate Task Retrospective

Purpose

At the end of every completed task, generate a retrospective report.

The retrospective is a mandatory project artifact used to:

• measure task quality
• measure AI collaboration quality
• identify misunderstandings
• identify friction points
• improve future task writing
• improve project documentation
• build long-term project metrics

Trigger

Execute this rule when:

• the task implementation is completed
• all acceptance criteria are satisfied
• quality gates are green

Required quality gates:

make test
make phpstan
make lint-twig
make npm-build

Retrospective Location

Generate a new file in:

docs/retrospectives/

Naming convention:

<task-id>-retrospective.md

Examples:

011-datatable-component-retrospective.md
012-autofill-filters-retrospective.md
013-faker-data-retrospective.md

Template

The retrospective MUST use:

docs/templates/task-retrospective-template.md

The template must be completed entirely.

Empty sections are not allowed.

Required Analysis

Task Understanding

Analyze:

• initial task clarity
• ambiguity level
• missing information
• overall understanding quality

Provide:

• strengths
• weaknesses
• improvement suggestions

Planning Quality

Analyze:

• quality of the generated plan
• plan completeness
• required plan revisions

Determine:

Plan accepted first try:
Yes / No

Provide explanation.

Collaboration Analysis

Analyze:

• clarification requests
• implementation iterations
• feedback cycles

Determine:

Number of clarification cycles

Provide details.

Implementation Analysis

Analyze:

• technical complexity
• architectural complexity
• implementation quality
• maintainability

Determine:

One-shot implementation:
Yes / No

Provide explanation.

Quality Analysis

Verify:

make test
make phpstan
make lint-twig
make npm-build

Record results.

Required Metrics

The retrospective MUST contain:

Complexity

1 → 5

Scale:

Collaboration Fluidity

1 → 10

Scale:

Overall Success

1 → 10

Scale:

Lessons Learned

Identify:

What worked well

Examples:

• task quality
• architecture quality
• documentation quality
• examples provided

What could be improved

Examples:

• missing examples
• missing acceptance criteria
• ambiguous requirements

What should be reused

Examples:

• architectural pattern
• testing strategy
• implementation approach

Documentation Impact

Determine whether updates are required for:

docs/context.md
docs/roadmap.md
docs/technical/
CHANGELOG.md

Provide recommendations.

Technical Debt

Identify:

• introduced technical debt
• postponed improvements
• refactoring opportunities

If none:

No technical debt identified.

Follow-up Work

Determine whether new tasks should be created.

Examples:

Create follow-up task
Create refactoring task
Create documentation task
No follow-up required

Final Recommendation

Choose one or more:

• Continue roadmap
• Create follow-up task
• Refactor before continuing
• Improve documentation
• Add tests

Provide justification.

Important

Retrospectives are mandatory project artifacts.

A task is not considered fully completed until:

• implementation is finished
• quality gates are green
• retrospective is generated

The retrospective must be objective, factual and actionable.

Avoid generic statements.

Provide concrete observations and measurable feedback whenever possible.