Skip to content

Commit 8802b40

Browse files
Kyle-YeKyle-Ye
authored
Add LLM prompt file (#303)
1 parent eb5f4a8 commit 8802b40

File tree

2 files changed

+264
-0
lines changed

2 files changed

+264
-0
lines changed

‎.github/copilot-instructions.md

Lines changed: 192 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,192 @@
1+
# OpenSwiftUI Copilot Instructions
2+
3+
This file contains coding guidelines and conventions for AI assistants working on the OpenSwiftUI project.
4+
5+
## Quick Reference
6+
7+
### Key Principles
8+
- Use `swift-testing` framework with `#expect` macro (not XCTest)
9+
- Use `package` access level for cross-module APIs
10+
- Follow SwiftUI API compatibility patterns
11+
- Trim trailing whitespaces automatically
12+
- Use 4-space indentation consistently
13+
14+
## Testing Guidelines
15+
16+
### Testing Framework
17+
18+
- Use the `swift-testing` framework with the `#expect` macro for all test assertions
19+
- Import testing framework with: `import Testing`
20+
- Do NOT use XCTest framework unless specifically required for compatibility
21+
22+
### Test Structure
23+
24+
```swift
25+
import Testing
26+
27+
struct DemoTests {
28+
@Test
29+
func functionality() {
30+
let value = SomeType()
31+
32+
#expect(value.property == expectedValue)
33+
#expect(value.method() == expectedResult)
34+
}
35+
36+
@Test
37+
func errorConditions() {
38+
#expect(throws: SomeError.self) {
39+
try riskyOperation()
40+
}
41+
}
42+
}
43+
```
44+
45+
### Test Conventions
46+
47+
- **Do NOT write any comments in test case body** - keep test code clean and self-explanatory
48+
- Use descriptive test function names that clearly indicate what is being tested
49+
- Group related tests using `// MARK: -` sections
50+
- Use `#expect` for all assertions instead of XCTest assertions
51+
- Prefer multiple focused tests over one large test
52+
- Do not add test prefix to test function names (e.g., `testFunctionality` should be `functionality`)
53+
- Use `@Test` attribute for test functions
54+
55+
## Code Organization
56+
57+
### File Structure
58+
- Use `// MARK: -` to separate different topics and sections within files
59+
- Organize code logically with clear separation of concerns
60+
- Place imports at the top, followed by type definitions, then implementations
61+
62+
### Example MARK Usage
63+
```swift
64+
// MARK: - A
65+
66+
...
67+
68+
// MARK: - B
69+
70+
...
71+
72+
// MARK: - C
73+
74+
...
75+
```
76+
77+
## Swift Coding Style
78+
79+
### Access Control Hierarchy
80+
81+
1. `public` - External API surface
82+
2. `package` - Cross-module internal APIs
83+
3. `internal` - Module-internal APIs (default)
84+
4. `private` - Implementation details
85+
86+
### Naming Conventions
87+
88+
- Follow Swift API Design Guidelines
89+
- Use descriptive names that clearly indicate purpose
90+
- Prefer full words over abbreviations
91+
- Use camelCase for variables, functions, and properties
92+
- Use PascalCase for types, protocols, and cases
93+
- Prefix internal types with `_` when they mirror SwiftUI internals
94+
95+
### Code Formatting Rules
96+
97+
- **Automatically trim trailing whitespaces including whitespace-only lines**
98+
- Use consistent indentation (4 spaces, not tabs)
99+
- Place opening braces on the same line as the declaration
100+
- Use proper spacing around operators and after commas
101+
- Align code vertically when it improves readability
102+
- Maximum line length: 120 characters (soft limit)
103+
104+
### Type Definitions
105+
106+
```swift
107+
struct SomeType {
108+
let property: String
109+
110+
private let internalProperty: Int
111+
112+
func method() -> String {
113+
// Implementation
114+
}
115+
}
116+
```
117+
118+
## Architecture Patterns
119+
120+
### SwiftUI Compatibility
121+
- Maintain API compatibility with SwiftUI when implementing equivalent functionality
122+
- Use similar naming conventions and parameter patterns as SwiftUI
123+
- Implement protocols and extensions that mirror SwiftUI's design
124+
125+
### Module Organization
126+
- Keep related functionality in appropriate modules
127+
- Use clear module boundaries
128+
- Avoid circular dependencies between modules
129+
130+
### Error Handling
131+
- Use Swift's error handling mechanisms (`throws`, `Result`, etc.)
132+
- Provide meaningful error messages
133+
- Handle errors gracefully at appropriate levels
134+
135+
## Documentation
136+
137+
### Code Comments
138+
- Write clear, concise comments for complex logic
139+
- Use documentation comments (`///`) for APIs documentation
140+
- Avoid obvious comments that don't add value
141+
- Keep comments up-to-date with code changes
142+
143+
### API Documentation
144+
```swift
145+
/// A brief description of what this function does.
146+
///
147+
/// - Parameter value: Description of the parameter
148+
/// - Returns: Description of the return value
149+
/// - Throws: Description of potential errors
150+
func someFunction(value: String) throws -> Int {
151+
// Implementation
152+
}
153+
```
154+
155+
## Performance Considerations
156+
157+
- Prefer value types (structs) over reference types (classes) when appropriate
158+
- Use lazy initialization for expensive computations
159+
- Consider memory management and avoid retain cycles
160+
- Optimize for common use cases while maintaining flexibility
161+
162+
## Dependencies and Imports
163+
164+
- Minimize external dependencies
165+
- Use conditional compilation for platform-specific code
166+
- Import only what is needed (avoid importing entire modules when specific types suffice)
167+
- Organize imports alphabetically within groups (system frameworks first, then project modules)
168+
169+
## Version Control
170+
171+
- Make atomic commits with clear, descriptive messages
172+
- Keep changes focused and reviewable
173+
- Follow the project's branching strategy
174+
- Ensure all tests pass before committing
175+
176+
## Platform Compatibility
177+
178+
- Support multiple Apple platforms (iOS, macOS, watchOS, tvOS, visionOS)
179+
- Use availability annotations when using platform-specific APIs
180+
- Test on supported platform versions
181+
- Use feature detection rather than version checking when possible
182+
183+
---
184+
185+
## Troubleshooting
186+
187+
### Common Issues
188+
- **Build errors**: Check `package` vs `internal` access levels
189+
- **Test failures**: Ensure using `#expect` not XCTest assertions
190+
- **SwiftUI compatibility**: Verify API signatures match exactly
191+
192+
Remember: This project aims to provide a compatible alternative to SwiftUI, so maintain consistency with SwiftUI's patterns and conventions while following these OpenSwiftUI-specific guidelines.

‎.github/format.prompt.md

Lines changed: 72 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,72 @@
1+
You are a Swift code formatter. Transform Swift code according to these specific rules:
2+
3+
**FORMATTING RULES:**
4+
1. **Indentation**: Use exactly 4 spaces for all indentation levels
5+
2. **Module prefixes**: Remove all module name prefixes from types (e.g., `SwiftUICore.AttributeGraph.CoreFoundation.TypeName` → `TypeName`)
6+
3. **Availability attributes**: Remove all `@available` attributes EXCEPT `@available(*, unavailable)`
7+
4. **Compiler directives**: Remove all `#if compiler` conditional compilation blocks, keeping only one version of duplicate declarations
8+
5. **Member spacing**: Add blank lines between different members, properties, and functions
9+
6. **Colon spacing**: Remove spaces before colons in type annotations and conformances
10+
7. **Method bodies**: Add placeholder implementations using `preconditionFailure("TODO")` for:
11+
- Function bodies (single line: `{ preconditionFailure("TODO") }`)
12+
- Property getters (`get { preconditionFailure("TODO") }`)
13+
- Property setters (`set { preconditionFailure("TODO") }`)
14+
8. **Extensions**: Format protocol conformances on same line as extension when possible
15+
9. **Prefer Multiple Lines**: Use multiple lines for function parameters when there are more than 3 parameters, aligning them vertically.
16+
eg.
17+
```swift
18+
static func makeView<Value>(
19+
view: _GraphValue<Value>,
20+
inputs: _ViewInputs,
21+
body: (_ view: _GraphValue<Value>, _ inputs: _ViewInputs) -> _ViewOutputs
22+
) -> _ViewOutputs
23+
```
24+
25+
**INPUT FORMAT:** Swift code with various formatting inconsistencies
26+
**OUTPUT FORMAT:** Clean, consistently formatted Swift code following the above rules
27+
28+
**EXAMPLE:**
29+
Input:
30+
```swift
31+
@available(iOS 13.0, macOS 10.15, tvOS 13.0, watchOS 6.0, *)
32+
@_originallyDefinedIn(module: "SwiftUI", iOS 18.0)
33+
@_originallyDefinedIn(module: "SwiftUI", macOS 15.0)
34+
@_originallyDefinedIn(module: "SwiftUI", tvOS 18.0)
35+
@_originallyDefinedIn(module: "SwiftUI", watchOS 11.0)
36+
public struct _ViewInputs {
37+
package var base: SwiftUICore._GraphInputs
38+
package var needsDisplayListAccessibility: Swift.Bool {
39+
get
40+
set
41+
}
42+
#if compiler(>=5.3) && $NoncopyableGenerics
43+
package mutating func popLast<T, U>(_ key: T.Type) -> U? where T : SwiftUICore.ViewInput, T.Value == SwiftUICore.Stack<U>
44+
#else
45+
package mutating func popLast<T, U>(_ key: T.Type) -> U? where T : SwiftUICore.ViewInput, T.Value == SwiftUICore.Stack<U>
46+
#endif
47+
}
48+
@available(*, unavailable)
49+
extension SwiftUICore._ViewInputs : Swift.Sendable {
50+
}
51+
```
52+
53+
Output:
54+
```swift
55+
public struct _ViewInputs {
56+
package var base: _GraphInputs
57+
58+
package var needsDisplayListAccessibility: Bool {
59+
get { preconditionFailure("TODO") }
60+
set { preconditionFailure("TODO") }
61+
}
62+
63+
package mutating func popLast<T, U>(_ key: T.Type) -> U? where T: ViewInput, T.Value == Stack<U> {
64+
preconditionFailure("TODO")
65+
}
66+
}
67+
68+
@available(*, unavailable)
69+
extension _ViewInputs: Sendable {}
70+
```
71+
72+
Now format the following Swift code:

0 commit comments

Comments
 (0)