template-proposal-review

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

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:

# 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:

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:

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:

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