code-completion

Code completion checklist

Execute these quality gates before finishing any code work cycle to ensure the codebase is production-ready.

When to use this skill

Use this skill when:

• Implementing new features
• Fixing bugs
• Refactoring code
• Modifying existing functionality
• Making any changes to C# source code
• Adding or updating indicators
• A human reminds you to run the "code completion checklist"

Required tools

• #tool:runCommands - Execute shell commands for linting, building, testing
• #tool:read - Read error output and configuration files

Workflow

Step 0: Remove dead code

Before running quality gates:

• Delete obsolete or commented-out code
• Remove unused imports, variables, helper methods
• Strip debugging aids (Console.WriteLine, breakpoints)
• Remove scratch files (.bak, .new, .debug.*)

Step 1: Run linters

Execute linting for all code (markdown + .NET):

dotnet format --severity info --no-restore
npx markdownlint-cli2 --fix

Success criteria: Zero linting errors and zero warnings. All warnings must be fixed before completing work.

CRITICAL: Suppressing warnings is not an appropriate way to resolve lint or build warnings.

Individual checks (if needed):

# Roslynator only (fast)
roslynator fix --properties TargetFramework=net10.0 --severity-level info --verbosity normal

# .NET format only
dotnet format --severity info --no-restore

# Markdown only
npx markdownlint-cli2 --fix

VS Code tasks: Lint: All (fix) or Lint: .NET code & markdown files (fix) (faster)

Handle failures:

• Review reported issues
• Fix manually or re-run fix commands
• For unfixable issues, document justification and seek approval
• Re-run lint to verify

Step 2: Build solution

Verify compilation and build artifacts:

dotnet build "Stock.Indicators.sln" -v minimal --nologo

Success criteria: All projects compile without errors. No build warnings.

VS Code task: Build: .NET Solution (incremental)

Handle failures:

• Review compilation errors and warnings
• Fix code issues, type errors, or configuration problems
• Ensure all packages are restored (dotnet restore)
• Re-run build to verify

Step 3: Run test suites

Execute all unit tests (integration tests run in CI only):

dotnet test "Stock.Indicators.sln" --no-restore --nologo

Success criteria: All tests pass. No test failures. Coverage ≥ 98% (validated in CI/CD via Codacy).

VS Code task: Test: Unit tests

Handle failures:

• Review test output and failure messages
• Fix code or update tests as appropriate
• Re-run test suite to verify

Step 4: Update documentation

When changing indicators or public APIs:

• Update XML documentation for changed public APIs
• Update docs/indicators/{IndicatorName}.md for indicator changes
• Update docs/migration.md for notable and breaking changes from v2
• Update obsolete bridge files (src/Obsolete.V3.*.cs) for deprecated APIs

Step 5: Verify and commit

After all gates pass:

dotnet format --verify-no-changes --severity info --no-restore
dotnet build "Stock.Indicators.sln" -v minimal --nologo
dotnet test "Stock.Indicators.sln" --no-build --nologo
npx markdownlint-cli2

• Review changes for completeness
• Address any remaining warnings
• Document intentional deviations
• Commit changes if working in unattended mode

Quality standards

Before marking work complete:

• Zero linting errors and zero warnings - all warnings must be fixed
• Zero build warnings and zero errors - all compilation warnings must be addressed
• All projects build successfully
• All tests pass with no warnings
• Coverage threshold maintained (≥ 98% validated in CI/CD)
• Documentation updated for public API changes
• Migration bridges updated for breaking changes

Critical: Treat all warnings as errors. Do not ignore, defer, suppress, or accept warnings regardless of scope, type, or reason. Warnings indicate issues that must be resolved.

Abbreviated verification command:

dotnet format --no-restore && dotnet build && dotnet test --no-restore && npx markdownlint-cli2

Required indicator components

For new or updated indicators, MUST include:

• Series implementation (*.StaticSeries.cs)
• Catalog entry and registration (*.Catalog.cs)
• Unit tests with full coverage (*.Tests.cs)
• Documentation (docs/indicators/{Name}.md)
• Regression test baseline (if algorithm changed)
• Performance benchmark (for complex indicators)

Required migration bridge

When changing public APIs, MUST:

• Add [Obsolete] attribute with migration message
• Update docs/migration.md for notable and breaking changes
• Update bridge files:
  • src/Obsolete.V3.Indicators.cs
  • src/Obsolete.V3.Other.cs

Best practices

• Run linters frequently during development, not just at the end
• Address linting errors as they appear
• Use VS Code tasks for quick access to quality gates
• Run specific tests during active development
• Document exceptions when disabling analyzer rules

Quick reference

Configuration files

Linting:

• Analyzers: #file:../../../src/Directory.Build.props
• .NET format: #file:../../../.editorconfig
• Roslynator: Global configuration
• Markdown: #file:../../../.markdownlint-cli2.jsonc

Build:

• Solution: #file:../../../Stock.Indicators.sln
• Project: #file:../../../src/Indicators.csproj
• Dependencies: #file:../../../src/Directory.Packages.props

Test:

• Unit tests: #file:../../../tests/tests.unit.runsettings
• Regression: #file:../../../tests/tests.regression.runsettings
• Integration: #file:../../../tests/tests.integration.runsettings

About maintenance of this file

When lint/build/test commands change or new quality gates are added, update this skill file to reflect current workflow

Last updated: January 2, 2026