Skip to content

Commit 387ffaa

Browse files
Kyle-YeKyle-Ye
committed
Add LLM prompt file
1 parent eb5f4a8 commit 387ffaa

File tree

2 files changed

+250
-0
lines changed

2 files changed

+250
-0
lines changed

‎.github/copilot-instructions.md

Lines changed: 187 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,187 @@
1+
# OpenSwiftUI Copilot Instructions
2+
3+
This file contains coding guidelines and conventions for AI assistants working on the OpenSwiftUI project.
4+
5+
## Testing Guidelines
6+
7+
### Testing Framework
8+
- Use the `swift-testing` framework with the `#expect` macro for all test assertions
9+
- Import testing framework with: `import Testing`
10+
- Do NOT use XCTest framework unless specifically required for compatibility
11+
12+
### Test Structure
13+
```swift
14+
@Test func testFunctionality() {
15+
let value = SomeType()
16+
17+
#expect(value.property == expectedValue)
18+
#expect(value.method() == expectedResult)
19+
}
20+
```
21+
22+
### Test Conventions
23+
- **Do NOT write any comments in test case body** - keep test code clean and self-explanatory
24+
- Use descriptive test function names that clearly indicate what is being tested
25+
- Group related tests using `// MARK: -` sections
26+
- Use `#expect` for all assertions instead of XCTest assertions
27+
28+
## Code Organization
29+
30+
### File Structure
31+
- Use `// MARK: -` to separate different topics and sections within files
32+
- Organize code logically with clear separation of concerns
33+
- Place imports at the top, followed by type definitions, then implementations
34+
35+
### Example MARK Usage
36+
```swift
37+
// MARK: - Public API
38+
39+
// MARK: - Internal Implementation
40+
41+
// MARK: - Private Helpers
42+
```
43+
44+
## Swift Coding Style
45+
46+
### Access Control
47+
- Use `package` access level for internal APIs that need to be shared across modules
48+
- Prefer explicit access control modifiers
49+
- Use `private` for implementation details
50+
- Use `internal` as the default for module-internal APIs
51+
52+
### Naming Conventions
53+
- Follow Swift API Design Guidelines
54+
- Use descriptive names that clearly indicate purpose
55+
- Prefer full words over abbreviations
56+
- Use camelCase for variables, functions, and properties
57+
- Use PascalCase for types, protocols, and cases
58+
59+
### Code Formatting
60+
- **Automatically trim trailing whitespaces including whitespace-only lines**
61+
- Use consistent indentation (4 spaces, not tabs)
62+
- Place opening braces on the same line as the declaration
63+
- Use proper spacing around operators and after commas
64+
- Align code vertically when it improves readability
65+
66+
### Type Definitions
67+
```swift
68+
struct SomeType {
69+
let property: String
70+
71+
private let internalProperty: Int
72+
73+
func method() -> String {
74+
// Implementation
75+
}
76+
}
77+
```
78+
79+
## Architecture Patterns
80+
81+
### SwiftUI Compatibility
82+
- Maintain API compatibility with SwiftUI when implementing equivalent functionality
83+
- Use similar naming conventions and parameter patterns as SwiftUI
84+
- Implement protocols and extensions that mirror SwiftUI's design
85+
86+
### Module Organization
87+
- Keep related functionality in appropriate modules
88+
- Use clear module boundaries
89+
- Avoid circular dependencies between modules
90+
91+
### Error Handling
92+
- Use Swift's error handling mechanisms (`throws`, `Result`, etc.)
93+
- Provide meaningful error messages
94+
- Handle errors gracefully at appropriate levels
95+
96+
## Documentation
97+
98+
### Code Comments
99+
- Write clear, concise comments for complex logic
100+
- Use documentation comments (`///`) for APIs documentation
101+
- Avoid obvious comments that don't add value
102+
- Keep comments up-to-date with code changes
103+
104+
### API Documentation
105+
```swift
106+
/// A brief description of what this function does.
107+
///
108+
/// - Parameter value: Description of the parameter
109+
/// - Returns: Description of the return value
110+
/// - Throws: Description of potential errors
111+
func someFunction(value: String) throws -> Int {
112+
// Implementation
113+
}
114+
```
115+
116+
## Performance Considerations
117+
118+
- Prefer value types (structs) over reference types (classes) when appropriate
119+
- Use lazy initialization for expensive computations
120+
- Consider memory management and avoid retain cycles
121+
- Optimize for common use cases while maintaining flexibility
122+
123+
## Dependencies and Imports
124+
125+
- Minimize external dependencies
126+
- Use conditional compilation for platform-specific code
127+
- Import only what is needed (avoid importing entire modules when specific types suffice)
128+
- Organize imports alphabetically within groups (system frameworks first, then project modules)
129+
130+
## Version Control
131+
132+
- Make atomic commits with clear, descriptive messages
133+
- Keep changes focused and reviewable
134+
- Follow the project's branching strategy
135+
- Ensure all tests pass before committing
136+
137+
## Platform Compatibility
138+
139+
- Support multiple Apple platforms (iOS, macOS, watchOS, tvOS, visionOS)
140+
- Use availability annotations when using platform-specific APIs
141+
- Test on supported platform versions
142+
- Use feature detection rather than version checking when possible
143+
144+
---
145+
146+
## Example Code Template
147+
148+
```swift
149+
//
150+
// SomeType.swift
151+
// OpenSwiftUI
152+
//
153+
154+
import Foundation
155+
156+
// MARK: - Public API
157+
158+
/// A brief description of SomeType
159+
package struct SomeType {
160+
package let property: String
161+
162+
private let internalState: Int
163+
164+
package init(property: String) {
165+
self.property = property
166+
self.internalState = 0
167+
}
168+
}
169+
170+
// MARK: - Extensions
171+
172+
extension SomeType {
173+
package func method() -> String {
174+
return property.uppercased()
175+
}
176+
}
177+
178+
// MARK: - Testing Support
179+
180+
#if DEBUG
181+
extension SomeType {
182+
static let testInstance = SomeType(property: "test")
183+
}
184+
#endif
185+
```
186+
187+
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: 63 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,63 @@
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+
16+
**INPUT FORMAT:** Swift code with various formatting inconsistencies
17+
**OUTPUT FORMAT:** Clean, consistently formatted Swift code following the above rules
18+
19+
**EXAMPLE:**
20+
Input:
21+
```swift
22+
@available(iOS 13.0, macOS 10.15, tvOS 13.0, watchOS 6.0, *)
23+
@_originallyDefinedIn(module: "SwiftUI", iOS 18.0)
24+
@_originallyDefinedIn(module: "SwiftUI", macOS 15.0)
25+
@_originallyDefinedIn(module: "SwiftUI", tvOS 18.0)
26+
@_originallyDefinedIn(module: "SwiftUI", watchOS 11.0)
27+
public struct _ViewInputs {
28+
package var base: SwiftUICore._GraphInputs
29+
package var needsDisplayListAccessibility: Swift.Bool {
30+
get
31+
set
32+
}
33+
#if compiler(>=5.3) && $NoncopyableGenerics
34+
package mutating func popLast<T, U>(_ key: T.Type) -> U? where T : SwiftUICore.ViewInput, T.Value == SwiftUICore.Stack<U>
35+
#else
36+
package mutating func popLast<T, U>(_ key: T.Type) -> U? where T : SwiftUICore.ViewInput, T.Value == SwiftUICore.Stack<U>
37+
#endif
38+
}
39+
@available(*, unavailable)
40+
extension SwiftUICore._ViewInputs : Swift.Sendable {
41+
}
42+
```
43+
44+
Output:
45+
```swift
46+
public struct _ViewInputs {
47+
package var base: _GraphInputs
48+
49+
package var needsDisplayListAccessibility: Swift.Bool {
50+
get { precondintionFailure("TODO") }
51+
set { precondintionFailure("TODO") }
52+
}
53+
54+
package mutating func popLast<T, U>(_ key: T.Type) -> U? where T: ViewInput, T.Value == Stack<U> {
55+
precondintionFailure("TODO")
56+
}
57+
}
58+
59+
@available(*, unavailable)
60+
extension _ViewInputs: Sendable {}
61+
```
62+
63+
Now format the following Swift code:

0 commit comments

Comments
 (0)