Properize

Turn "I hacked this together for myself, it's AI slop, but I want it proper now" into a repo that meets lgtm-hq standards. This skill sequences other skills into one pipeline — it composes

commit

, design grilling,

issue

, and

implement-issues

pr

, it does not replace them. Never skip a stage or collapse two stages into one session; each stage produces an artifact (commits, a design decision, an issue tree) the next stage depends on.

The mistake this skill prevents

The default failure mode is jumping straight from "make this proper" to writing a full implementation plan and executing it in one pass — no commit checkpoint, no design interrogation, no issue trail. That produces an unreviewable mega-diff and bakes in whatever the prototype already got wrong. Do NOT do this. Do: commit → grill → recon → spec → implement, one stage at a time, stopping between stages for the artifacts to exist and be reviewable.

Pipeline

1. Commit the WIP first

Before any design discussion, get the current state to a lint-clean, committed baseline:

Drive
```
uv run lintro chk
```
to 0 issues. Fix real bugs the gate surfaces (missing imports, undefined names, missing arguments, type errors, dead-code/unused-variable warnings) rather than suppressing them — a lint gate on a prototype routinely finds actual bugs, not just style nits.
Land signed, semantic commits grouped by domain, not one giant commit. For example: a
```
cleanup
```
pass, then commits per feature area (e.g.
```
discover
```
,
```
playlists
```
), then
```
app-infra
```
, then a trailing
```
chore
```
for anything left over. Follow the
```
commit
```
skill for message format and signing.
Do not refactor or redesign here — only make the WIP lint-clean and historied. Design changes belong in the next stage.

2. Grill the design

Stress-test the full design before writing any spec. Prefer the external

grilling

skill when it is installed (e.g. mattpocock/grilling via the vendor catalog); otherwise run the same interview inline. One question at a time, waiting for an answer before the next — do not batch questions. Recommend an answer with each question. Cover at least:

Audience and multi-tenancy (single-user tool vs. shared service?)
Data storage (what DB, migrations, backups?)
Auth (who can access it, how?)
Background jobs / scheduling
Configuration and secrets management
Deployment target and process
Documentation expectations (README, ADRs?)
Scope freeze — what's explicitly out of scope for v1
Observability (logging, metrics, error tracking)
Testing strategy and coverage bar
Issue granularity for the next stage (how small is "one PR"?)

Do not proceed to standards recon until these questions have answers. If the user defers a question, record the deferral explicitly rather than assuming a default.

3. Standards recon (before writing issues)

Run this recon after grilling and before stage 4 so branch rulesets and CI requirements shape the backlog. Treat it as a checklist of repeatable commands, not a judgment call:

Fetch
```
winnow
```
workflows as the gold-standard CI reference (full workflow set).
Fetch
```
lgtm-ci
```
reusable workflows pinned to a release SHA (plus the tooling-ref pin), not a floating tag.
Fetch the org's rulesets for the target repo (
```
checks-<repo>
```
) via
```
gh api repos/<owner>/<repo>/rulesets
```
(or the org-level ruleset endpoint) so branch-protection requirements are known before issues are written.
Bring in the standard community-files set:
```
.editorconfig
```
,
```
SECURITY.md
```
, Renovate config, gitleaks config, and equivalents already used across lgtm-hq repos.
Make
```
lintro
```
the sole lint/format entry point — no bare
```
ruff
```
/
```
eslint
```
/ etc. invocations left in scripts or CI.
Wire releases through the version-PR + auto-tag flow used elsewhere in lgtm-hq, not manual tagging.

Do not create milestones, epics, or issues until this recon is complete.

4. Spec the backlog as milestones, epics, and issues

Turn the grilled design into a milestone → epic → issue tree:

Milestones group epics by release/phase.
Epics group issues by feature area.
Issues are one-PR-sized. Every code issue gets an AI Implementation Prompt comment in the
```
issue
```
skill's format (see
```
skills/issue/SKILL.md
```
), so any issue is fan-out-ready for
```
implement-issues
```
without rework.
Generalize the issue-generation script pattern (Python +
```
gh
```
calls creating milestones, epics, and issues from a structured spec) into a repo-agnostic template rather than a one-off script tied to this repo's domain. Keep the domain content (titles, bodies, prompts) separate from the generation mechanics so the template is reusable on the next prototype.

5. Implement, issue by issue

Only after the tree exists: implement issues one at a time, small PRs, per the

pr

skill (or hand the whole ready backlog to

implement-issues

for parallel, worktree-isolated lanes). Never batch unrelated issues into one PR to save time — the point of stage 4 was to make each unit reviewable on its own.

Guardrails

Stage order is not negotiable. Do not run standards recon before the design has been grilled, do not spec issues before recon is done, and do not implement before the issue tree exists.
Stop between stages. Each stage's artifact (commit history, recorded design decisions, recon notes, the issue tree) should be reviewable before the next stage starts — do not silently chain all five stages into one unattended run.
A stage that cannot stay green (lint, tests, or an unanswered blocking design question) stops and reports rather than pushing through.
This skill never merges — implementation PRs follow the normal review and merge process for the target repo.

properize

NPX Install

Tags

SKILL.md Content