---
name: template-proposal-review
description: Review proposal files in localdocs/localdocs/proposals/ and decide whether to apply them to the upstream python-project-template repository. Use when evaluating proposals generated by template-upstream, deciding which ones to accept or reject, and applying accepted ones to the template repo. Triggers on: "proposal 검토", "제안 검토", "template에 반영할지", "proposals 리뷰", "upstream 반영 결정".
---

# template-proposal-review

Acting as template repo maintainer: review proposals in `localdocs/proposals/` and optionally apply accepted ones to the upstream template.

## Prerequisites

- Upstream: `https://github.com/tae0y/python-project-template.git`
- Local template path (if available): ask the user — "Do you have a local clone of the template repo? If yes, provide the path."
- Proposal files follow the format generated by the `template-upstream` skill.

## Proposal Directory Structure

```
localdocs/proposals/
├── draft/       ← new proposals; review targets
│   └── YYYYMMDD/
├── accepted/    ← approved, not yet applied
│   └── YYYYMMDD/
├── rejected/    ← declined
│   └── YYYYMMDD/
└── applied/     ← applied to upstream
    └── YYYYMMDD/
```

Proposals start in `draft/`. Moving to the correct folder is part of the review workflow.

## Proposal Status Values

| Status | Folder | Meaning |
|--------|--------|---------|
| `draft` | `localdocs/proposals/draft/` | Not yet reviewed (default) |
| `accepted` | `localdocs/proposals/accepted/` | Approved for inclusion |
| `rejected` | `localdocs/proposals/rejected/` | Declined |
| `applied` | `localdocs/proposals/applied/` | Applied to upstream repo |

## Steps

### 1. List proposals

```bash
find localdocs/proposals/draft/ -name "proposal-*.md" | sort
```

All files in `draft/` are review targets — no need to check `**Status:**` field.

### 2. Review each draft

Read each `draft` proposal and evaluate against these criteria.

**Accept if:**
- Beneficial to all downstream projects, not just this one
- All project-specific values (domains, paths, secrets) are removed
- No conflict with existing template files
- Backed by localdocs evidence (learn file, ADR, or worklog entry showing real adoption)

**Reject if:**
- Pattern is specific to this project's domain
- Contains sensitive information
- Conflicts with template design principles
- No localdocs evidence and no compelling rationale — theoretical-only proposals without observed value are weak candidates

**Evidence weight:**
- `learn.*.md` citation → pattern was encountered, investigated, and adopted; strong signal
- `adr/*.md` citation → architectural decision it supports; strong signal
- `worklog.done.md` citation → task where the pattern made a difference; moderate signal
- No evidence cited → flag to user; apply higher scrutiny before accepting

Report assessment to user:

```
proposal-add-ruff-hook.md — recommend ACCEPT
  Evidence: learn.ruff-autofix.md documents friction without it; worklog.done.md shows repeated manual fix cycles
  Reason: applicable to all Python projects, no project-specific values

proposal-update-db-schema.md — recommend REJECT
  Evidence: none cited
  Reason: tied to a specific project domain; no evidence of cross-project applicability
```

### 3. Collect user decisions

```
Please decide for each proposal: Accept (A) / Reject (R) / Hold (S)
```

### 4. Update status and move files

Per user decision, update the `**Status:**` field in each file, then move it:

```bash
# Accept
mv localdocs/proposals/draft/YYYYMMDD/proposal-<slug>.md localdocs/proposals/accepted/YYYYMMDD/

# Reject
mv localdocs/proposals/draft/YYYYMMDD/proposal-<slug>.md localdocs/proposals/rejected/YYYYMMDD/

# Hold — leave in draft/, no move needed
```

- Accept → set status `accepted`, move to `localdocs/proposals/accepted/YYYYMMDD/`
- Reject → set status `rejected`, append `**Rejection reason:** <reason>` at end of file, move to `localdocs/proposals/rejected/YYYYMMDD/`
- Hold → leave as `draft`, no move

Create the destination date directory if it doesn't exist. Recording rejection reasons enables context when the same proposal is resubmitted later.

### 5. Apply accepted proposals (optional)

If any proposals were accepted, ask:

```
Apply accepted proposals to the upstream template now?
This will modify files in the template repo.

Y) Apply now
N) Handle manually later
```

**If Y:**

Resolve template root in this priority order:

1. **User-provided path** — if the user provided a local path above and it exists, use it directly. No clone needed.
2. **Clone** — otherwise:

```bash
TMPDIR=$(mktemp -d)
git clone https://github.com/tae0y/python-project-template.git "$TMPDIR/template"
TEMPLATE_ROOT="$TMPDIR/template"
```

Apply each accepted proposal's "Proposed Change > Content" to its "Target path(s)".

Then commit:

```bash
cd "$TEMPLATE_ROOT"
git add -A
git commit -m "[NEW FEATURE] <proposal title summary>"
```

Do not push. Print the actual path and instruct the user:

```
Applied. Push with:
  cd /actual/path/to/template && git push origin main

If a temp directory was created, clean up after push:
  rm -rf /tmp/tmp.XXXXXX
```

### 6. Mark as applied and move files

Update each applied proposal's `**Status:**` to `applied`, then move it:

```bash
mv localdocs/proposals/accepted/YYYYMMDD/proposal-<slug>.md localdocs/proposals/applied/YYYYMMDD/
```

Create `localdocs/proposals/applied/YYYYMMDD/` if it doesn't exist.

### 7. Summary

```
Done:
  accepted: N
  rejected: N
  applied:  N
  on hold:  N
```