# Pre Code > Pre-coding readiness gate. Triggers ONLY when: about to write implementation code for a feature or fix. Do NOT trigger when: writing config files, documentation, scripts, or making quick single-line edits. - Skill: `docat0209/pre-code` (Agent Skill) - Install (CLI): `npx skillmds@latest add docat0209/pre-code` - Raw SKILL.md: https://api.skillmd.com/api/skills/docat0209/pre-code/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Docs & Writing - Author: Docat0209 (https://skillmd.com/u/docat0209) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/docat0209/pre-code --- # 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 / ``` - If on an incorrectly named branch: rename it to follow the `/` 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 ``` - 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: `: (#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"