Implement PromptTemplate (#119)

[leogdion]

Closes #119.

Summary

• Adds Sources/AiSTKit/PromptTemplate.swift with PromptTemplate.createAnalysisAndCodeGeneration(syntaxKitLibrary:expectedSwift:swiftAST:swiftDSL:), the prompt builder the ClaudeKit wrapper (Implement ClaudeKit Wrapper #116) will use for skit analyze.
• The prompt wraps the four inputs in XML tags (<syntaxkit_library>, <swift_code>, <swift_ast>, <swift_dsl>), walks Claude through a SyntaxKit-specific gap analysis (CodeBlock conformance, existing protocols, result builders, source directory layout), then requests a plain-text summary followed by the implementation.
• Output contract matches the planned response parser: each file emitted as <file path="relative/path.swift">…</file> with COMPLETE content (diffs and "rest unchanged" elisions explicitly forbidden), no markdown fences, summary before the first file block.
• Compilation validity emphasized (must build with swift build under Swift 6.1 / SwiftSyntax 601) and one-type-per-file organization required.

Notes

• The prompt text is a considerable revision of the original Workbench draft (per review feedback during planning) — only the structural ideas (XML-tagged inputs, analysis-before-output) were kept.
• Caseless enum instead of the issue's "struct": SwiftLint's convenience_type rule flags static-only structs; matches the existing AiSTKit namespace enum.
• public access per ACL preference from Implement AuthenticationMiddleware #117 planning.
• No tests per planning decision; a test target can come with a later Phase 4 issue.

Verification

• swift build passes.
• mise exec -- swiftlint lint and mise exec -- swift-format lint clean on the new file.
• ./Scripts/lint.sh Periphery step fails with a pre-existing "index store path does not exist" error that reproduces on a clean tree (verified via stash); unrelated to this change.

🤖 Generated with Claude Code

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: efe2d5f6-caac-4fd3-8da4-456003c4f444

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch 119-prompt-template

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[claude]

Code Review — PR 172: Implement PromptTemplate

Overall this is clean, well-structured code. One security/correctness concern worth addressing before merge.

Security — XML tag injection in prompt inputs

inputsSection interpolates the four caller-provided strings directly into an XML-tagged block. If any input contains the corresponding closing tag (e.g. a Swift source file that contains the literal string </syntaxkit_library>), the XML structure Claude sees will be malformed or prematurely closed, causing the model to misparse which content belongs to which section. In a worst case, carefully crafted inputs could redirect Claude's instructions (prompt injection). This is not a theoretical edge case — Swift source files may legitimately contain XML strings or multiline comments with angle brackets.

Recommendation: Strip or escape the closing tags from each input before interpolation, or switch to a delimiter that can't collide with arbitrary Swift source (e.g. a random UUID fence, or base64-encode the inputs). At minimum, add a note in the doc comment warning callers that inputs containing the XML closing tags will corrupt the prompt structure.

---

Minor observations

• private static let properties for large string literals is a reasonable choice, but the strings are only ever used in createAnalysisAndCodeGeneration. Consider whether inlining them would be clearer — the current approach works fine either way.
• No tests (noted as intentional): even a simple test that calls createAnalysisAndCodeGeneration and asserts the output contains the expected section markers would catch regressions if the template structure is later edited. Worth revisiting in Phase 4.
• The doc comment on createAnalysisAndCodeGeneration is thorough and accurate. ✓
• Caseless enum for the namespace avoids the SwiftLint convenience_type warning correctly. ✓

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 79.97%. Comparing base (07f505b) to head (e0ffbd4).

Additional details and impacted files

@@                Coverage Diff                @@
##           claude-prompt     #172      +/-   ##
=================================================
- Coverage          80.16%   79.97%   -0.20%     
=================================================
  Files                153      153              
  Lines               5209     5209              
=================================================
- Hits                4176     4166      -10     
- Misses              1033     1043      +10     

Flag	Coverage Δ
spm	79.95% <ø> (ø)
swift-6.1	?
swift-6.2	?
swift-6.3	79.96% <ø> (-0.12%)	⬇️
ubuntu	79.96% <ø> (-0.20%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.