AgentStack
Browse Sign in
Browse Why AgentStack Sell Docs
Sign in
SKILL verified MIT Self-run

Contract Based Porting

skill-iml1s-flutter-claude-skills-contract-based-porting · by ImL1s

Port native Android/iOS code to Flutter (or any target language) using Contract-Based TDD. Guarantees zero missed features by extracting the complete API surface from the reference project first, writing contract tests, then implementing RED→GREEN. Use when porting Kotlin/Swift/Java to Dart, or any cross-language feature parity task.

No reviews yet
0 installs
27 views
0.0% view→install

Install

$ agentstack add skill-iml1s-flutter-claude-skills-contract-based-porting

✓ scanned · ✓ verified, works with Claude Code, Cursor, and more.

Security review

✓ Passed

No issues found. Passed automated security review. · v0.1.0 How review works →

  • Prompt-injection patterns
  • Secret / credential exfiltration
  • Dangerous shell & filesystem operations
  • Untrusted network calls
  • Known-malicious package signatures

What it can access

  • Network access No
  • Filesystem access No
  • Shell / process execution No
  • Environment & secrets No
  • Dynamic code execution No

From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.

View the full security report →

Verified badge

Passed review? Show it. Paste this badge into your README, it links to the public security report.

AgentStack Verified badge Links to your public security report.
[![AgentStack Verified](https://agentstack.voostack.com/badges/verified.svg)](https://agentstack.voostack.com/security/report/skill-iml1s-flutter-claude-skills-contract-based-porting)

Reliability & compatibility

Security review passed
0 installs to date
no reviews yet
5mo ago

Declared compatibility

Claude CodeClaude Desktop

Compatibility is declared by the source manifest. End-to-end runtime verification is coming, see below.

Preview Execution monitoring

We're building live execution health for every listing: tool-call success rate, median latency, uptime, and last-checked timestamps, measured, not self-reported. It isn't live yet, so we don't show numbers we can't stand behind.

How agent discovery & health will work →
Are you the author of Contract Based Porting? Claim this listing to set pricing, connect Stripe payouts, and keep 70% of every sale.
Sign up to claim

About

Contract-Based Porting: Cross-Language Feature Parity via TDD

When to Use

  • Porting native Android (Kotlin/Java) or iOS (Swift/ObjC) features to Flutter (Dart)
  • Ensuring a Flutter app has 100% feature parity with a reference native implementation
  • Any cross-language porting task where you need guaranteed completeness
  • Migrating from one framework to another (e.g., React→Vue, Express→FastAPI)

Core Principle

Never port line-by-line. Port contract-by-contract.

The #1 failure mode in cross-language porting is missing features — not bugs. The fix is to extract the entire public API surface before writing a single line of target code.

3-Step Methodology

Step 1: Extract the Single Source of Truth (SSOT)

Find the one file in the reference project that serves as the command/capability registry. Common patterns:

| Language | Pattern | Example | |----------|---------|---------| | Kotlin/Android | Registry object | InvokeCommandRegistry.kt | | Swift/iOS | Protocol constants | ProtocolConstants.swift | | TypeScript/Node | Route map | routes/index.ts | | Python/Django | URL patterns | urls.py |

What to extract:

1. All public commands/endpoints/routes → exact string identifiers
2. All capabilities/permissions → exact string identifiers
3. Constructor parameters → each handler's config surface
4. Error codes → all structured error code strings

How to find it:

# Kotlin: find the registry
grep -rn 'register\|addCommand\|mapOf.*command' --include="*.kt" | head -20

# Swift: find protocol constants
grep -rn 'static.*let.*command\|case.*=.*"' --include="*.swift" | head -20

# Search for string enums that look like API contracts
grep -rn '"[a-z]+\.[a-z]+"' --include="*.kt" | sort -u

Step 2: Write Contract Tests (RED Phase)

Create a test file that enumerates every item from the SSOT and asserts the target project advertises/implements them:

// Example: command_registry_contract_test.dart
test('must advertise all 31 reference commands', () {
  // SSOT: extracted from InvokeCommandRegistry.kt
  const referenceCommands = {
    'canvas.open', 'canvas.close', 'canvas.inject',
    'screen.record', 'screen.brightness',
    'camera.snap', 'camera.clip',
    // ... all 31
  };

  // Target: what the Flutter app actually advertises
  final advertised = buildNodeCommands(allPermsGranted).toSet();

  // Gap analysis via set difference
  final missing = referenceCommands.difference(advertised);
  final extra = advertised.difference(referenceCommands);

  expect(missing, isEmpty, reason: 'Missing commands: $missing');
  expect(extra, isEmpty, reason: 'Extra commands: $extra');
  expect(advertised.length, referenceCommands.length);
});

This test MUST fail initially — that's the RED in TDD. The failures tell you exactly what's missing.

Step 3: Implement Until GREEN

For each missing item from the contract test:

  1. Check if handler exists — often the handler code is already written but not advertised
  2. If handler exists → just wire it (add to command list, register provider)
  3. If handler missing → port the reference implementation:
  • Read the reference handler (Kotlin/Swift)
  • Write the equivalent Dart version
  • Focus on the contract (inputs/outputs), not the implementation
# Verify after each batch
flutter test test/protocol/command_registry_contract_test.dart
flutter analyze

Advanced Patterns

Pattern A: UI Wiring Audit

After command parity, audit the integration layer — features implemented but not wired to UI:

# Find all public methods never called outside their own file
grep -rn 'toggleAutoRestart\|seamColorProvider\|TrustPromptDialog' lib/ --include="*.dart" | \
  grep -v '.g.dart\|_test.dart'
# If a method appears only in its definition file → not wired

Pattern B: Error Code Parity

Port the reference error parser for consistent error handling:

// Reference: InvokeErrorParser.kt
// Splits "CAMERA_ERROR: lens not found" → code + message
// Target: invoke_error_parser.dart
ParsedInvokeError parseInvokeErrorMessage(String raw) { ... }

Pattern C: State/Model Field Parity

Compare state classes field-by-field:

# Reference state fields (Kotlin)
grep -A5 'data class.*State\|val ' ConnectionState.kt

# Target state fields (Dart)
grep -A5 'class.*Snapshot\|final ' gateway_connection_provider.dart

Add missing fields (e.g., seamColorHex, tlsFingerprint) with copyWith support.

Pattern D: Capability Advertising

Capabilities are separate from commands. The reference may advertise capabilities conditionally:

// Always-on
caps.add('canvas');
caps.add('device');

// Permission-gated
if (perms['camera'] ?? false) caps.add('camera');

// Platform-specific
if (Platform.isAndroid) caps.add('foreground_service');

Verification Checklist

After all contract tests pass:

# 1. Full test suite (contract + unit + integration)
flutter test

# 2. Static analysis
flutter analyze

# 3. Count parity
echo "Commands: $(grep -c 'expect.*command' test/protocol/command_registry_contract_test.dart)"
echo "Capabilities: $(grep -c 'expect.*capability' test/protocol/command_registry_contract_test.dart)"

Common Mistakes

  1. Porting code without porting the contract first → guaranteed to miss features
  2. Copying implementation instead of contract → fragile, wrong idioms
  3. Not checking for "implemented but not wired" → handler exists, never called
  4. Ignoring conditional logic → permission/platform gates differ across languages
  5. Skipping error code porting → gateway receives unstructured errors

Real-World Results

This methodology was used to port openclaw-node (Kotlin+Swift) → claw_node (Flutter):

  • 31/31 commands parity (7 were missing-but-implemented)
  • 14/14 capabilities parity
  • 5 integration gaps found and fixed (error parser, voice auto-restart, seam color, trust prompt, session drawer)
  • 245 tests, 0 analysis issues
  • Total time: ~2 sessions with zero manual regression testing

Related skills

See [What's inside](../../README.md#whats-inside) for related categories — contract-based-porting is a refactoring methodology without natural composition partners in other skill domains.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

Install and usage instructions live in the source repository linked above.

Reviews

No reviews yet, be the first.

Versions

  • v0.1.0 Imported from the upstream source.