Rootbuild

rootbuild — Pattern-Respecting Build Mode

Add a new feature. But be a citizen of the existing codebase. Don't introduce new patterns. Don't merge without tests. Don't bundle multiple features in one PR.

Activation

Explicit: /rootbuild

Auto-triggers:

• "기능 추가", "새 기능", "신규 기능"
• "추가해줘", "구현해줘", "만들어줘"
• "이런 기능 넣어줘"
• "X 같은 거 만들어줘"
• "build", "implement", "add feature"

Note: When the user explicitly invokes another skill (e.g., "autopilot으로 만들어줘"), rootbuild stays inactive. autopilot builds from scratch; rootbuild slots into existing code.

What's Different (vs general / autopilot)

The Two Anti-Patterns (encoded by real experience)

A. "Ignore existing patterns, introduce new ones"

The most common and most damaging anti-pattern. The #1 reason codebases become inconsistent over time.

Python signal:

# BAD: existing code uses FastAPI dependency injection
@app.get("/users/{id}")
def get_user(id: int, db: Session = Depends(get_db)):
    return db.query(User).filter(User.id == id).first()

# new feature suddenly uses global state
db_connection = create_engine(...)  # module level!

@app.get("/products/{id}")
def get_product(id: int):
    with db_connection.connect() as conn:  # ← ignores existing pattern
        return conn.execute(...).fetchone()

Mitigation:

1. Always grep first: find how similar features are implemented
   • grep -rn "@app.get" . (FastAPI pattern)
   • grep -rn "class.*Service" . (Service pattern)
2. Confirm pattern via 3+ examples before extracting it
3. New code follows that pattern exactly
4. If existing pattern is truly bad → exit rootbuild, fix via rootclean first

B. "Merge without tests"

"I'll add them later" → never happens. Regressions can't be caught.

Python signal:

• PR has N new functions, 0 new tests
• Existing test_*.py exists, new module missing
• Only "I ran it manually" in PR description

Mitigation:

• One commit = function + test always paired
• Use pytest fixtures (follow existing patterns)
• Minimum 3 cases:
  • Happy path
  • Edge case (boundary, empty, null)
  • Error path
• Mocks follow project conventions (unittest.mock vs pytest-mock)

Python Pattern Checklist

Before adding new feature, check via grep:

6-Step Workflow

1. Requirement Clarification — Ask immediately if vague

Preferred workflow: systematic (requirements → design → implementation). Never jump to code.

Question priority:

• What: exact input/output? (1-2 example data points)
• Who: auth needed? permissions?
• When: sync? async? batch?
• How: part of existing domain or new?
• On failure: how to handle? retry? error?

If answers are vague, ask again, don't guess. autopilot's deep-interview philosophy.

2. Existing Pattern Learning — Force grep

Once requirements are clear, immediately grep:

• Similar feature exists? (if yes, follow its structure exactly)
• API style? DB access? Error handling?
• Where are tests? How?
• New dependency needed? (if yes, check for existing similar package first)

Confirm via 3+ examples before extracting a pattern. 1 example might be a fluke.

3. Design Proposal — Show before writing code

Show the user:

• New file location: services/notifications.py (existing services/ pattern)
• Function signature: input/output types
• Dependency graph: which existing modules to import?
• Impact scope: which existing functions are affected?
• Pattern match: "Same structure as existing user_service.py"
• Test plan: test_notifications.py — happy/edge/error cases

Never write code without user approval.

4. Incremental Implementation — Inside out

Implementation order:

1. Types/Schema first: Pydantic model, TypedDict, dataclass
2. Tests first (optional): write failing test → make it pass
3. Pure functions first: I/O-free logic
4. I/O integration: DB, API, external calls
5. Endpoint/Entry point: HTTP route, CLI command, Lambda handler

Each step paired with 1+ test. No "test after everything's done".

5. Integration Verification — No breakage

Don't only check the new feature. Verify:

• All tests: pytest passes all
• Type check: mypy passes (if used)
• Lint: ruff check passes
• Manual check: new feature 1x + critical existing scenario 1x

pytest                # all tests
pytest -k new_feature # new feature only
mypy .                # types
ruff check .          # lint

6. PR Separation — 1 feature = 1 PR

Don't mix in one PR:

• ❌ "feature add + bug fix + refactor"
• ✅ PR 1: feature add only
• ✅ PR 2: bug fix → rootfix
• ✅ PR 3: refactor → rootclean

PR description must include:

• What was added
• Which existing pattern was followed (file path explicit)
• How tests were done
• Dependency additions (if any, with reason)

Anti-Patterns (Forbidden in this mode)

1. Write code without grep — Always grep first
2. Introduce new patterns — "This is more modern" rejected. Separate PR via rootclean.
3. No-test implementation — "Urgent, just do it" absolutely forbidden
4. Multiple features in one PR — "While I'm here" forbidden
5. Unauthorized dependencies — New package = explicit user approval
6. Guess vague requirements — Ask, don't guess
7. Manual test = OK — "I ran it once" ≠ verification

Output Format

When receiving a feature request, answer in this order:

[Requirement Check]
- Input: <type + example>
- Output: <type + example>
- Auth/permissions: <required?>
- On failure: <handling>
(If vague → ask, continue after answer)

[Existing Pattern Survey]
grep results:
- API pattern: <FastAPI Depends, ref services/user.py>
- DB access: <SQLAlchemy session, repositories/ pattern>
- Error handling: <HTTPException used>
- Tests: <pytest fixture in conftest.py>

[Design Proposal]
New file: <path>
Signature: <function/endpoint>
Dependencies: <existing imports only / no new packages>
Impact: <which existing code is affected>
Test plan: <file name + 3 cases>

Proceed?

Termination Conditions

Exit rootbuild mode only when ALL of:

• Requirements unambiguous
• Existing pattern grep done + new code follows it
• Design approved by user
• Tests written alongside code (paired commit)
• All tests + types + lint pass
• PR scope is one feature

Notes

• This skill encodes anti-patterns observed in Python (Lambda, FastAPI, AI/ML) work: introducing new patterns instead of following existing ones, and merging without tests.
• Preferred workflow: requirements clarification → design → implementation (systematic).
• Pair with rootfix and rootclean. rootfix changes behavior (bug fixes), rootclean preserves behavior (cleanup), rootbuild adds (new features). Don't mix.
• Small features → regular conversation. Activate this for medium+ feature additions (1+ file).
• Bigger greenfield projects → autopilot is better (rootbuild is for slotting into existing code).
• Works in any project. Global skill.