amirbena / amirbena/code-review-skill

Architecture reassessment checkpoint: continue the specialist-depth pattern?

Open
#412 0 comments 0 reactions 1 assignee Claimed by @amirbena View on GitHub
area:instruction-architecture maintainer-led priority:P1 type:research
Dominant language
Python
Stars
7
Forks
2
Avg merge
27m
Merged PRs (30d)
188

Description

## Problem

The roadmap (#403) deliberately does not plan migration of the other 12
capabilities in model.md's list. Deciding to continue the same pattern
without evidence would repeat the exact mistake this roadmap was designed
to avoid: one large, irreversible batch.

## Goal

An explicit, written architecture checkpoint exists, answering whether
specialist-depth's extraction should be repeated for other capabilities,
before any such follow-up issue is created.

## Scope

Answer, with evidence from #411 (and #408/#410 as needed):

- Did progressive loading materially reduce the instruction surface?
- Did benchmark behavior remain stable?
- Were activation predicates reliable, or did they need frequent fallback?
- Did fail-closed behavior actually hold under test?
- Did the manifest/resource ownership model stay understandable, or did
it add orchestration complexity that outweighed what it removed?
- Is specialist-depth representative enough of the other 12 capabilities
to justify repeating the pattern as-is?
- If yes: which capability should be migrated next, and does it need a
new epic or can it extend #403?
- If no: what should change before trying again?

## Non-Goals

- Creating issues for migrating any other capability. That only happens
as a follow-up decision after this checkpoint, not automatically.

## Acceptance Criteria

- [ ] Every question above is answered in writing, citing #408/#410/#411 evidence
- [ ] A clear yes/no recorded on whether to continue the pattern
- [ ] If yes, the next capability and issue structure are named (new issue, not created here)
- [ ] If no, the blocking concern is named precisely enough to act on

## Dependencies

Depends on: #403 (parent), #411
Blocks: none
Parent: #403

## Validation

- Reviewed and approved by a maintainer before #403 is closed or any further capability-migration issue is opened

Release category: none - decision record only.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.