"Compound Engineering" - Introducing it using Codex Skills

~/.agents/skills/
├── README.md
├── ce-router/
├── ce-plan/
├── ce-review/
└── ce-compound/

## Skill set for this kit
- ce-router (gate/routing): implicit allowed (auto-intervention where possible)
- ce-plan (PLAN deliverables)
- ce-work (WORK execution + mandatory Work Log)
- ce-review (review + P1/P2/P3)
- ce-compound (at least one carry-over artifact required)

---
name: ce-router
description: |
  If the user request is unclear about which stage it belongs to among PLAN/WORK/REVIEW/COMPOUND,
  or asks for implementation/fixes/tests/deployments without approved PLAN, this skill enforces
  the Compound Engineering loop by forcing stage routing and explicit handoff.
  For requests like "implement", "fix", "refactor", "run tests", "deploy",
  it explicitly tells the assistant the current phase, approval state, and next skill to call.
---

## Core Rules
- All responses are written in Korean.
- Code comments are always written in Korean.
- Single-person development is assumed; final decisions belong to the user.
- AI leads planning → implementation → testing → documentation, and stage transitions happen only after explicit user approval.
  - Exception: when the user explicitly requests uninterrupted execution.

## Routing Objective
- Classify the request into exactly one stage.
  - PLAN / WORK / REVIEW / COMPOUND
- Ask only 1~3 high-impact questions if more information is needed.

## Approval Gate (Mandatory)
- Do not move to WORK without an approved PLAN.
- Even with an approved PLAN, if stage transition is not approved:
  - Stop and ask one sentence: "Can I continue to the next stage?"
- If the user requests uninterrupted execution:
  - Continue, except when Plan Drift (scope/policy/invariant changes) occurs; then stop and re-confirm with 1~3 questions.

## Output Format (Mandatory)
1) Current-state summary (3~6 lines)
   - Interpreted objective
   - Current stage (estimated or confirmed)
   - Approval/delegation status
2) One next stage and reason
3) Questions 1~3 (only if needed)
4) Input block template for the next stage
   - Copy-paste ready
5) Final line: `CE ROUTING COMPLETE`

---
name: ce-plan
description: |
  Compose the PLAN stage outputs for Compound Engineering.
  Without implementing or running tests, write goals, scope, DoD, defect mapping,
  invariants, policy, checklist, test plan, and risk controls in a high-quality plan.
  Ask up to 3 questions only when uncertain.
---

## Mode Lock
- PLAN-only.
- No implementation, code edits, or test execution.
- Do not make unsupported assumptions; if evidence is missing, label it as assumption and escalate for approval.

## User Input (required)
Users provide as much as available from the format below. If missing, ask 1~3 questions.
- Project:
- Stack/runtime:
- Work ID:
- Work title:
- Current stage: PLAN
- SoT/reference files (optional): (path list)
- Target requirements/defects: (list)
- Invariants/policies: (list)
- Scope include / exclude
- Non-negotiable invariants: (list)
- (Optional) Code hints: file paths/modules/endpoints

## Quality Standards (Checklist)
- First Principles: refine requirements into atomic units
- Invariants First: lock invariant protection as strategy core
- Failure-Oriented: design with failure/exception/boundary first
- Minimal Complexity: start from the simplest approach
- Tight Loop: enforce stage-by-stage verification loops
- Observability: include logging/metrics/error-message improvement points

## Evidence Rule (Mandatory)
- If possible, attach evidence as "file path + line range" for each claim.
- If evidence cannot be verified yet, write:
  - (1) Unverified evidence
  - (2) Candidate files to verify
  - (3) Commands/methods to verify
  in the PLAN document.

## Output Format (Mandatory)
Must include the following 13 sections in order.

1) Goal / scope / out-of-scope
2) Defect or requirement matrix
3) Invariant protection strategy
4) Policy decision table
5) Completion criteria (DoD, measurable)
6) Candidate changed files + rationale
7) Stagewise Work checklist (W1~Wn, validation command per stage)
8) Test plan (Red → Green split, happy/failure/boundary)
9) Risks/regressions (P1/P2/P3) + response
   - P1: data/security/crash/critical regression
   - P2: durability / major quality / high usability impact
   - P3: documentation / cleanup / improvements
10) Plan Drift rules (stop/approval conditions)
11) Review priority criteria
12) Compound candidates (minimum 1)
13) User approval points (1~3)

### Top summary (required)
- Add a top-of-document summary within 5 lines.

### Bottom sentinel (required)
- Final line: `PLAN COMPLETE — REQUEST WORK APPROVAL`

---
name: ce-work
description: |
  Execute the WORK stage based on an approved PLAN.
  Force a cycle of one checklist item at a time, verify what was done,
  and enforce keeping a Work Log.
  Stop and request approval immediately when Plan Drift is detected.
---

## Preconditions (Gate)
- Do not execute WORK without approved PLAN.
  - Instead, ask 1~3 missing questions or guide to $ce-plan.
- Continuous execution is only allowed when user explicitly says no intermediate confirmation.
  - Stop immediately and re-confirm approval if Plan Drift occurs.

## Basic Rules
- All responses are in Korean.
- Code comments are always in Korean.
- No work outside the approved PLAN scope.
- Enforce meaningful unit commits (commit message must include what and why).

## User Input
- Work ID:
- Work title:
- Current stage: WORK
- Approved PLAN: (paste document path or summary)
- (Optional) Branch/PR strategy:
- (AGENTS.md at repo root) run/test commands:

## Execution Unit (Mandatory)
1) Select one checklist item
2) Implement within PLAN scope
3) Verify (tests/lint/type-check/manual scenarios where possible)
4) Commit with what/why
5) Update Work Log

## Plan Drift Handling (Mandatory)
- Pause immediately if any of these occur:
  - Scope inversion (include/exclude flipped)
  - Possible fixed-policy violation
  - Risk of breaking invariants
  - Need to redefine DoD
- On pause, provide:
  - Before/after state
  - Why the change happened
  - Impact (P1/P2/P3)
  - 1~2 alternatives
  - One-line re-approval request

## Work Log (Mandatory)
- At WORK completion, leave at least one:
  - docs/plans/<work-id>-worklog.md creation
  - or add a `## Work Log` section at the end of docs/plans/<work-id>-plan.md

### Work Log Minimum Items
- Progress summary (3~7 lines)
- Final changed file list
- Checklist completion status ([x])
- Commands run and results (only what ran)
- Commit hash or PR number/link
- Final 3 lines at work end:
  - Completed checklist items in this WORK:
  - Validations passed in this state:
  - Risk points to watch in Review (if any):

## Recommended Output Format (Operational)
- Checklist items completed in this turn
- Changed files + core reason
- Validation commands/results
- Work Log update summary
- Next checklist proposal
- Final line: `WORK STATUS SHARED — REQUEST NEXT STAGE APPROVAL`

---
name: ce-review
description: |
  Run the REVIEW stage after WORK.
  Start with a self PR review, and prioritize checks in order: bugs/edges, risks,
  regressions, then readability/maintainability.
  Classify issues as P1/P2/P3 and summarize so the user can choose what to fix next.
---

## User Input
- Work ID:
- Work title:
- Current stage: REVIEW
- Approved PLAN (path or summary):
- Change summary (if available):
- Commit/PR identifier (if available):
- Validation results (if available):

## Review Priority (Mandatory)
1) Bug likelihood / edge cases
2) Risks (security, data loss, performance, operations)
3) Regression risk (impact on existing behavior)
4) Readability / maintainability

## Issue Classification (Mandatory)
- P1: Must fix now (data/security/crash/critical regression)
- P2: Fix if possible this cycle (usability/durability/important quality)
- P3: Documentation/cleanup/improvements (deferable)

## Evidence Rule (Mandatory)
- Use file path + line range as evidence whenever possible.
- If verification is not complete, mark as "evidence not verified" and list candidate files/lines to check.

## Output Format (Mandatory)
1) Change summary (3~7 lines)
2) DoD completion check (by each PLAN DoD item)
3) P1 / P2 / P3 issue list
   - For each: symptom / impact / reproduction or condition / evidence (file:line) / recommended fix
4) Additional test/observability points (happy/failure/boundary)
5) User decisions required (1~3)
6) Final line: `REVIEW COMPLETE — REQUEST APPROVAL FOR NEXT STAGE (COMPOUND OR ADDITIONAL WORK)`

---
name: ce-compound
description: |
  Run the COMPOUND stage.
  Every work cycle must leave at least one carry-over asset for the next cycle,
  such as tests, docs, guardrails, rules, or observability improvements.
  Answer the question: if this issue happens again, will tests/rules catch it automatically?
  If not, leave at least one artifact that makes future discovery easier.
---

## Input
- Work ID:
- Work title:
- Current stage: COMPOUND
- Final change summary:
- Proposed carry-over artifact candidates (if any):

## Mandatory Rules
- Propose at least one carry-over artifact (preferably immediately actionable).
- Answer these questions:
  - If this issue happens again, will tests/rules/guards catch it automatically?
  - If not, what should be left so it is easier to find next time?

## Recommended Artifact Paths
- docs/solutions/<slug>.md (recommended)
- Or:
  - Add regression tests
  - Strengthen AGENTS.md rules (short, strict)
  - Update review checklist
  - Improve observability (logs/error messages/tracing points)

## Output Format (Mandatory)
1) 1~3 candidate artifacts (priority order)
2) At least one should be immediately actionable
   - propose file path + doc/test skeleton
3) Expected effect (why next work is easier)
4) User approval points (1~3)
5) Final line: `COMPOUND COMPLETE — REQUEST REPEAT APPROVAL`