Pre-Code Readiness Gate

Run this checklist BEFORE writing any implementation code. Every item must pass. If any item fails, STOP and resolve it before proceeding.

0. Skill Invocation Check

• Was this skill loaded via the Skill("pre-code") tool call, not just mentioned in text?
• If resuming from a previous session: have you re-evaluated the Skill Gate fresh? Previous invocations do not carry over.
• If taking over from a failed sub-agent: you must still complete this full checklist. Changing executor does not bypass process.

1. Issue Check

• A GitHub issue exists for this work.
• Run gh issue list --state open and confirm a matching issue exists.
• If NO issue exists: STOP. Create one first using the issue-create skill. Do not write code without a tracking issue.
• Note the issue number for branch naming and PR linking.

1.5 Think Before Build

• Has the core question "should this exist?" been answered BEFORE starting to code?
• If the issue is for a new product or major feature: was biz-think or biz-validate run? If not, STOP. Don't build something whose existence hasn't been validated.
• If you're about to spend days coding: step back and ask "is this the highest-value use of time right now?"
• Building is expensive. Validating is cheap. Always validate first.

2. Branch Check

• The current branch is a feature branch created from dev.
• Run git branch --show-current to check.
• Valid branch prefixes: feat/, fix/, chore/, refactor/, test/, docs/
• If on main: STOP. Never branch from main. Switch to dev first, then create a feature branch.
• If on dev: STOP. Do not commit directly to dev. Create a feature branch:

  git checkout dev && git pull origin dev
  git checkout -b <type>/<short-name>

• If on an incorrectly named branch: rename it to follow the <type>/<short-name> convention.

3. Branch Pushed

• The branch has been pushed to the remote.
• Run git log --oneline @{u}.. 2>/dev/null to check tracking status.
• If the branch has no upstream: push immediately:

  git push -u origin <branch-name>

• Every subsequent commit must also be pushed right after creation. Never accumulate unpushed commits.

4. Requirements Clear

• Acceptance criteria are understood and unambiguous.
• Read the linked GitHub issue body. Check for acceptance criteria checkboxes.
• If criteria are vague or missing: STOP. Ask the user to clarify before writing code. Do not guess at requirements.
• If the issue lacks technical notes on approach: confirm the intended approach with the user for non-trivial changes.

Upstream Plan Check (if from work-breakdown)

If the issue body contains a ## Commit Plan or ## Test Plan section (added by the work-breakdown skill):

• Read the planned commits — these are your implementation roadmap. Each planned commit = one focused coding session.
• Read the planned test types — cross-reference with Section 6 below. The test plan here should match or refine what work-breakdown decided.
• If the plan no longer makes sense after reading the code: update the issue body with the revised plan BEFORE starting implementation. Do not silently diverge.

Scope Boundaries

Before starting implementation, identify the boundaries of this issue:

• List the files that SHOULD be modified for this issue (from Technical Notes or Commit Plan).
• During implementation, do NOT modify files outside this list unless strictly necessary. If you must touch an out-of-scope file, note it and justify it.
• During debugging, resist the urge to "fix" unrelated code you happen to see. Create a separate issue for it instead.
• Platform configuration in scope? If this issue involves auth, payments, webhooks, or any third-party integration:
  • List the platform settings that need configuration (OAuth redirect URLs, webhook endpoints, API keys, environment variables)
  • These are NOT "deployment details for later" — they are part of the feature scope
  • Include platform config steps in the Commit Plan or Technical Notes
  • A feature that works in code but fails because of missing platform config is NOT done

5. Design Considerations (SOLID + Clean Code + NASA)

• Design principles have been reviewed for this change.
• Dependency Inversion (SOLID-D): High-level modules depend on abstractions, not concrete implementations. Inject dependencies; never instantiate collaborators directly inside business logic.
• Simple control flow (NASA Rule 1): Avoid deep nesting, no goto, minimize recursion. Every function should be readable top-to-bottom with obvious flow.
• No dynamic memory after init (NASA Rule 3): Allocate resources (connections, buffers, pools) at startup. Avoid runtime allocation in hot paths — prefer pre-allocated structures.
• Single Responsibility (SOLID-S): Each module/class has ONE reason to change. If a module serves two masters, split it.
• Threat model during design (OWASP A04): For security-sensitive features, identify threat vectors before coding. Consider: auth bypass, injection, data exposure, privilege escalation.
• Input validation at system boundaries: Identify where untrusted data enters the system. Validate and sanitize at those boundaries, not deep inside business logic.

6. Test Plan

• A test plan has been identified for this work.
• Unit tests: always required. Identify what logic needs unit tests.
• Integration tests: required if the code touches any external service (database, API, auth, storage). If API keys or env vars are needed, ask the user NOW — not after implementation.
• E2E tests: required if the change completes a user-facing flow. Confirm Playwright is set up.
• Technical feasibility: if the feature depends on third-party APIs, verify the API works BEFORE writing code. Run a proof-of-concept call. Check rate limits, TOS, platform restrictions. Do not design around an unverified API.
• Tests go in the SAME branch and PR as the implementation. Never defer testing to a separate issue.

All Clear

Once every box is checked, proceed with implementation. Reference the issue number in commits using Conventional Commits format: <type>: <description> (#issue)

Next Steps

Report to user: "Pre-code ✅. Issue #[N], branch [name], scope: [N files]. Ready to implement."

Suggested next steps (user decides):

• No issue exists → "Run issue-create first"
• All clear → "Proceed with implementation"