Fci

If .claude/skills/fci/SKILL.md.disabled exists, stop before reading a fallback. Project configuration: If the current project contains .claude/skills/fci/SKILL.md, read and apply it instead of this bundled default. The project copy is the capability source of truth. Repository context: Read ../setup/references/task-context.md when resolving a task, project commands, named agent roles, or legacy .claude/ resource paths. Use repository evidence and applicable project instructions; a missing local workflow copy does not require setup. Resolve bundled resources from the installed skill, never from the target cwd. Invocation guard: use this as a standalone skill only when explicitly requested by the user; automatic selection is not authorization. Portable clients may not enforce Claude Code host-level invocation restrictions.

Fix CI Issues Command

Briefly tell the user you are using the fci skill before starting work, so they know which workflow is running.

PRIMARY OBJECTIVE

Fix all CI pipeline failures blocking the PR merge while maintaining code quality and test integrity.

Resolve the task with ../setup/references/task-context.md before inspecting or changing code. Reuse the linked task or create the minimum record in the configured task root. Record the failing run, actual commands/cwds selected from repo or CI configuration, fixes, observed validation, current state, and next action there. Do not create a separate CI ledger.

SCOPE

• Supports the project CI pipeline as configured in the repository
• If $ARGUMENTS specifies a workflow outside the project scope, inform the user and suggest manual investigation

CONTEXT & CONSTRAINTS

• CI pipeline failed during merge attempt to main branch
• Must resolve all failures without compromising code quality
• Preserve existing test coverage and validation logic
• CI includes the lint, type, test, build, and project-specific checks declared by the selected workflow; resolve their actual commands and working directories before running them.
• Do not silence CI with any, @ts-ignore, // eslint-disable, or architectural shortcuts — the goal is a real fix, not a green checkmark. If a suppression is genuinely correct (e.g. a .d.ts shim), flag it explicitly so the reviewer can confirm.
• Follow project architecture rules (see coding-conventions skill)

RELATED SKILLS

• /dbg - Runtime bugs requiring instrumentation and evidence gathering
• /sr - Post-fix code review before re-attempting merge
• /prc - Addressing reviewer comments on the PR

ANALYSIS REQUIREMENTS

1. Identify CI Failures:

   • Run gh workflow list if you are unsure of the workflow name.
   • Run gh run list --limit=3 to check recent CI status.
   • Pick the most recent failing run and review its logs with gh run view <run-id> --log. Don't fetch logs for older runs unless the recent-run failures are ambiguous.
   • Categorize failures by type (linting, tests, types, build, other).

2. Execute Diagnostic Checks (run in parallel):

   • These commands are independent — batch them in one turn as parallel Bash tool calls, do not chain sequentially.
   • Ensure dependencies are installed first (sequential prerequisite).
   • Resolve the selected workflow's actual scripts and working directory before running checks. Then in parallel: the resolved lint, typecheck, test, and build commands. Do not run unresolved placeholders or assume every command belongs to the repository root.
   • Collect all failure logs before choosing where to start fixing — don't stop at the first red check.

RESOLUTION PROCESS

Scope discipline: fix only what the failing CI checks require. Do not refactor nearby code, rename symbols for consistency, tighten unrelated types, or add defensive error handling that wasn't failing. If you spot adjacent problems, note them in the handoff summary — don't fix them in this PR.

1. Formatting (only if lint reported style violations):

   • Skip this step entirely if formatting is clean.
   • Otherwise run the formatter declared by the selected workflow, then re-run lint to confirm the formatter didn't introduce new issues.

2. Address Type Errors:

   • Resolve typing errors surfaced by lint/test/typecheck output
   • Add precise typings rather than suppressing warnings

3. Resolve Test Failures:

   • Fix failing tests by correcting the implementation bug the test is catching — the test is a spec, so weakening assertions to turn the check green hides the real defect.
   • Maintain or improve test coverage against the repository or CI-configured baseline. If a test is genuinely wrong (e.g. asserts outdated behavior), update it and explicitly flag the change in the handoff summary.

4. Fix Linting Issues:

   • Address linter violations
   • Update tests/fixtures when necessary rather than suppressing rules

5. Security Issues:

   • Address any dependency vulnerability findings that surface during investigation

6. Build Issues:

   • Ensure build succeeds
   • Fix any import or runtime errors

VERIFICATION REQUIREMENTS

Before completion, run the full CI-equivalent validation suite locally and confirm every resolved command exits zero. Run each package command from its declared working directory:

# Run the resolved CI-equivalent validation commands from their declared working directories.
# The command names must be read from repo/CI configuration before execution.

Optional additional checks (if relevant jobs are failing): run the repository's configured coverage command only when it is relevant to the failing job; record the resolved command and result in the task record. Never execute an unresolved placeholder.

TROUBLESHOOTING

• gh auth failure: Run gh auth status; prompt user to run gh auth login if needed
• Docker not running: Run docker info; inform user to start Docker Desktop
• DB connection refused: Verify test database is running; check port conflicts
• Language version mismatch: Check version files (.nvmrc, .tool-versions, etc.) and use appropriate version manager

DEFINITION OF DONE

• All CI checks pass (lint, typing, format, tests, build)
• Test coverage did not drop below the repository or CI-configured baseline (use the configured floor; do not invent a new percentage target).
• No test logic simplified or removed
• Security vulnerabilities resolved (if applicable)
• Build succeeds
• GitHub CI status shows green checkmark
• Ready for clean merge to main branch