template-proposal-review
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 반영 결정".
Best use case
template-proposal-review is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
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 반영 결정".
Teams using template-proposal-review should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/template-proposal-review/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How template-proposal-review Compares
| Feature / Agent | template-proposal-review | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
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 반영 결정".
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
Related Guides
SKILL.md Source
# 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
```