Lc rules

LC Rules

Create a small evidence-based rules router. Let agents load only the critical, code, QA, environment, team, and Git guidance relevant to the current task. Preserve existing project files and preview every mutation.

Core workflow

1. Resolve the project root. Prefer the Git root; otherwise use the user's explicit workspace path or current directory.
2. Inspect the entire workspace for Git roots, package manifests, framework configuration, instruction files, existing rules/, and nested projects before changing anything.
3. Read install-contract.md.
4. Select the evidence mode:
   • Existing workspace: infer rules from current configuration, source, tests, CI, and Git history.
   • Greenfield project: research current official guidance for the selected framework versions before coding.
   • Reference project: extract reusable rules from a user-supplied path and separate project-specific values.
5. For a multi-project workspace, new *-fe/*-be project, greenfield setup, or reference-project extraction, read project-discovery.md.
6. Preview the deterministic starter changes for all supported agent entry points:

python3 <skill-dir>/scripts/init_rules.py --target <project-root> --agent all

7. Confirm that AGENTS.md, CLAUDE.md, and GEMINI.md are all in the plan. Existing files must retain everything outside the managed marker; missing files may contain only the managed block. Review every CREATE, UPDATE, PRESERVE, CONFLICT, RELEASE, and UNCHANGED line. Stop on a non-zero exit, any ERROR, any unresolved CONFLICT, an unexpected ownership change, or the wrong target root.
8. Apply the accepted starter setup:

python3 <skill-dir>/scripts/init_rules.py --target <project-root> --agent all --apply

9. Generate focused project rules from evidence. Record assumptions, selected versions, sources, research date, and only a portable reference-project label or repository-relative path under the configuration object in .leecat/lc-rules.json, using the schema in the install contract. Do not turn uncertain observations into mandatory rules.
10. Always ask the user to choose one of the four Git-strategy routes during a new initialization. If an explicit, established strategy already exists, recommend route 4, but do not treat it as accepted without the user's choice. Follow Git strategy selection below.
11. After strategy acceptance, use the four templates under assets/git-guidance/ to generate synchronized rules/git/WORKFLOW.md, WORKFLOW.ko.md, BRANCHING.md, and BRANCHING.ko.md. Replace every template token, preview all four files, and record their portable paths under configuration.git.
12. Manually materialize thin nested routers for accepted subprojects using the exact contract in the project-discovery reference. Do not run the full starter installer against a nested project. Connect each nested instruction file to its nearest rules/RULES.md, then record the portable inventory under configuration.projects.
13. Verify the installation:

python3 <skill-dir>/scripts/init_rules.py --target <project-root> --check

BASELINE_READY means the deterministic starter is healthy but tailoring is not recorded as complete. COMPLETE means the configured evidence, bilingual Git workflow and policy, and nested-project inventory also passed validation.

Git strategy selection

Read branch-strategies.md when initializing Git rules, creating automatic branch rules, or changing an existing branch policy.

For a new policy, first offer these routes and wait for the user's choice:

1. Recommend by team profile — ask only for team size, concurrent work level, release cadence, and risk/compliance level; then recommend one strategy with reasons.
2. Choose a common strategy — show the one-line strategy menu from the reference.
3. Reuse a reference project — inspect a supplied project path and propose a sanitized policy.
4. Keep or customize the current policy — preserve the current rules and change only selected decisions.

Treat "브랜치 규칙 전환해줘" and equivalent requests as a policy migration:

1. Inspect the current local rules and remote protections read-only.
2. Offer the same selection routes again.
3. Show the rule diff, migration impact, and any remote settings that would remain unchanged.
4. Wait for explicit approval before editing the policy.
5. Change local rules first. Modify hosted rulesets, protections, or repository settings only with separate authorization.

Branch strategy depends primarily on collaboration and release topology. Research current provider capabilities when useful, but never replace an active team policy merely because another style is newer.

Project rule quality

• Follow this precedence: explicit team decision → supplied reference project → observed workspace convention → official version-matched documentation → community practice.
• Separate shared team rules from framework and project rules.
• Include ownership, PR review, required checks, API/schema compatibility, migrations, dependencies, security, environments, observability, tests, accessibility, releases, rollback, and decision-record policies when applicable.
• Keep generated routers concise. Put detailed framework or strategy guidance in one-level references and load it only for the relevant task.
• Never silently refresh researched conventions. Preview the diff and ask before changing established behavior.

Agent guidance targets

Treat a normal AI initialization request, including "lc-rules 스킬 초기화 해줘", as an all-agent setup. Inspect and update AGENTS.md, CLAUDE.md, and GEMINI.md in the same preview/apply transaction. Preserve all existing content outside the managed marker and create a missing file with the managed block.

Use --agent auto or a specific target only when the user explicitly narrows the setup. An explicit codex, claude, gemini, or all target replaces the tracked instruction-file selection. auto keeps previously tracked entry points and adds detected ones. Narrowing never deletes files or removes an existing LC Rules block from a dropped entry point; that block becomes project-owned and must be removed manually if it is no longer wanted:

python3 <skill-dir>/scripts/init_rules.py --target <project-root> --agent auto --apply
python3 <skill-dir>/scripts/init_rules.py --target <project-root> --agent codex --apply
python3 <skill-dir>/scripts/init_rules.py --target <project-root> --agent claude --apply
python3 <skill-dir>/scripts/init_rules.py --target <project-root> --agent gemini --apply

Safety

• Keep preview as the default. Pass --apply only after reviewing the target and changes.
• Preserve every existing rules file whose content differs from the starter template.
• Upgrade an untouched previously managed starter file when its recorded hash proves that it has not been project-edited.
• If a formerly managed file was intentionally made project-owned, copy the exact sha256 printed on its CONFLICT preview and rerun with --accept-preserved <relative-path>=<sha256>. Confirm that the preview shows RELEASE for only that file before applying. Repeat the flag for separately reviewed files.
• Modify instruction files only inside the lc-rules marker block.
• Refuse malformed marker blocks and symlinked destinations.
• Never use a force-overwrite mode.
• Do not copy secrets, real service URLs, identities, ports, or repository-specific values from a reference project.
• Do not create, switch, delete, or force-push a branch while unrelated working-tree changes make the operation unsafe.
• Treat the generated starter as a baseline. Project-specific rules remain owned by the project.