"Use when you need to summarize a completed task into an architectural decision record, reducing clutter in .tasks/. Triggers on: 'use consolidate-task mode', 'consolidate-task', 'consolidate task', 'summarize task'."
Install
npx skillscat add mcouthon/agents/generated-copilot-skills-consolidate-task Install via the SkillsCat registry.
SKILL.md
Summarize Task to Architectural Decision Record
Read the task file at .tasks/{task-folder}/task.md and create an architecture decision summary.
When to Create an ADR
Not every completed task needs an ADR. ADRs document architectural decisions, not implementation work.
Skip ADR entirely when:
- Task adds a minor feature within existing patterns
- Task fixes bugs or refines implementation details
- Task is routine maintenance or cleanup
- Changes follow conventions already documented elsewhere
Update existing ADR when:
- Task extends or modifies patterns documented in a prior ADR
- Task adds significant new component to an existing architectural area
- Changes affect how future developers should approach that area
Create new ADR when:
- Task introduces new architectural patterns
- Task reverses or significantly modifies a prior decision
- Task establishes new conventions for the codebase
When updating, add an entry to the "Updates" table and integrate changes into relevant sections.
File Naming
Required format: ADR-NNN-{decision-name}.md
- Scan
docs/architecture/for existingADR-*files - Check if any existing ADR covers the same architectural area (update if so)
- For new ADRs: find the highest number (e.g.,
ADR-003-*→ next is004) - Start at
001if no ADR files exist - Save to:
docs/architecture/ADR-NNN-{decision-name}.md
Example: ADR-004-unified-query-execution.md
Output Format
# {Decision Title}
**Source:** Task {NNN} ({Month Year})
## Decision
One sentence describing the high-level architectural choice.
## Why
- Bullet points explaining the motivation
- Focus on problems solved, not implementation details
## Problem Statement (if applicable)
What issue prompted this change? What was broken or suboptimal?
## Solution
Brief description with before/after comparison:
### Before
{Old approach - can include diagrams or code}
### After
{New approach - can include diagrams or code}
## Implementation Phases
| Phase | What Changed |
| --------- | ------------------ |
| 1. {Name} | {One-line summary} |
| ... | ... |
## Key Architectural Patterns
Include 2-3 code snippets showing the most important patterns established.
Only patterns that future developers need to understand and follow.
## Current Structure
```
relevant/directory/
├── file1.py # Brief purpose
├── file2.py # Brief purpose
```
## Deleted
- List of deleted files/code (shows what was replaced)
## Updates (for existing ADRs only)
| Date | Task | Summary |
| ------------ | ----- | ------------------------------------ |
| {Month Year} | {NNN} | One-line description of what changed |Guidelines
- High-level only — Skip implementation details that don't affect architecture
- Focus on patterns — What should future code follow?
- Include deletions — Shows what was replaced, not just what was added
- Code examples — Only for patterns that repeat across the codebase
- Keep it scannable — Tables and bullets over paragraphs
After Saving
- Update
docs/architecture/README.md(create if missing with a decisions table) - Delete or archive the original task folder
- If updating an existing ADR: add entry to the Updates table at the bottom