메뉴
Use when onboarding a new person or a new repo to this pack — constants files don't exist yet, need regenerating, or a repo needs its own landmine list captured. Also use when a standing correction keeps recurring and hasn't been turned into a candidate rule yet.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Use at the polish stage of a design direction, once structure is settled, to turn a prototype's own tokens into a small panel of eye-decidable knobs a designer drives by hand, and to route what they settle back into the token system and the taste rules. Emits an altitude-appropriate facet spec, and at polish a self-contained tunable playground. Skip it when the artifact has no eye-tunable surface.
Use before grounding a design or technical direction in external references — comparing tools, evaluating approaches, gathering prior art — before committing to a direction. Produces a source index, a synthesis, and concrete candidate directions instead of a pile of links.
Use before writing any planning artifact a human has to approve - a spec, an implementation plan, or a long dispatch brief. Gate the full artifact behind a tight stub the human will actually read, get approval on the stub, then elaborate and adversarially review the full thing.
Use when receiving a design or code review to execute, or when writing a review someone else will execute. Splits every review item into one of four buckets before any work starts, so parked items don't get silently rebuilt and outgoing reviews arrive pre-executable.
Use any time more than one lane of work (delegate, agent, or workstream) is active against the same project. Maintains board.json as the single source of truth for lane state — written on every lane transition, not batched — so status reporting, "what's running", handoffs, and kill decisions are all queries against one file instead of reconstructed from memory.
Use when declaring any work item done, or when writing the report/evidence block of a dispatch brief. Defines the gate list — the specific evidence required before something counts as done — per class of work, plus universal rules that apply to every class.
| name | pp-init |
| description | Use when onboarding a new person or a new repo to this pack — constants files don't exist yet, need regenerating, or a repo needs its own landmine list captured. Also use when a standing correction keeps recurring and hasn't been turned into a candidate rule yet. |
This pack works by keeping every specific fact out of skill text and in
one of three constants files: personal, org, and repo (see
constants/schemas/ for the exact shape of each, and
constants/examples/ for a filled worked example of each). This skill is
how those files get written the first time, or regenerated when they go
stale: a short, scoped interview per file, validated against its schema
before anything is saved.
Run the personal and org interviews once per person (org optionally shared across everyone at the same organization). Run the repo interview once per repo, and again whenever that repo's landmines change enough that the file feels out of date.
Confirm which file(s) you're generating and where they'll be written:
constants/personal.yaml (schema:
constants/schemas/personal.schema.json)constants/org.yaml (schema:
constants/schemas/org.schema.json)<repo>/.process/repo.yaml, or a clearly labeled section
of that repo's own root instructions file if a whole file is overkill
(schema: constants/schemas/repo.schema.json)If a file already exists at that path, read it first and treat the interview as an update pass: confirm what's still true, ask only about what's missing or changed, don't re-ask settled questions.
Before writing any answer into a constants file, check which layer it actually belongs to:
The same check runs in reverse: if you notice a skill file contains a specific name, account, or repo-specific detail, that's the two-layer rule being violated somewhere else — flag it, don't silently work around it by also duplicating the fact into a constants file.
Whenever this interview is pointed at one or more actual repos — rather than run with nothing to look at yet — mine what's inferable from them before asking a single question. Whatever can be inferred, lead with it: present every mined finding as a prefilled default, labeled as inferred, for the person to confirm or correct, rather than asking the question cold. A question asked blind when the repo already had the answer sitting in it is a worse interview than one that opens with "here's what was found."
Mine, per repo pointed at:
user.name,
user.email) and its configured remotes (which host, which account/org the
remote path names). Prefills the matching context's identity questions
below instead of asking them cold.Mining reads identity; it does not act on it. Before writing any file, compare the mined git identity and host account against the context the current session is billed to. If they differ - you are onboarding one context from a session that belongs to another (a work context from a personal session, or the reverse) - stop and run the resource-wall preflight before writing anything, and do not invoke the other context's runtime or config to finish the job. Reading a repo is safe; generating that context's constants, installing, or running under it from the wrong session is the wall. Write the file only once the session context matches the file's context, or the person has explicitly confirmed the cross-context write is what they intend.
Ask these, adapting wording to what you already know from the repo/session you're in — skip any question whose answer is already evident and confirm instead of re-asking. Where mining (above) found a prefilled default, present it as the default and ask for confirmation or correction rather than asking cold:
Before asking, mine what's inferable (see "Infer-First: Mine Before You Ask," above): git identities and remotes, tracker references in commit/PR/ branch history, CI workflow check names, lint/format configs, package/build scripts, existing docs, and recent PR history. Bring a draft list of gotchas, checks, stubs, and tool-mapping candidates you already found to the interview instead of asking blind — ask to confirm/correct/extend what you found, not to generate it from nothing.
After drafting a file, validate it against its schema before writing it to disk:
required in the schema is present.additionalProperties: false — an extra field is a sign
the answer belongs somewhere else, not a sign to loosen the schema).On a validation failure, don't write a partial or invalid file. Report the specific field and go back to the relevant question instead.
Run this after the personal interview, or on its own when asked to look for standing corrections.
When an interview finishes, report: