axiom-using-axiom

Other Community

Repo stars 0
Author repo skills-registry

Interpretation is structured for decision-making; original keeps the upstream SKILL.md unchanged.

Decide Fit First

Core job: Use when starting any iOS/Swift conversation - establishes how to find and use Axiom skills, requiring Skill tool invocation bef…
Best fit: Use it when the task has reusable inputs, steps, and validation criteria rather than a one-off answer.
Avoid forcing it: If the source lacks commands, platform support, or external-service evidence, keep those fields unknown instead of guessing.

Design Intent

Structure: The skill is organized around “The Rule”, “Red Flags — iOS-Specific Rationalizations”, “Skill Priority for iOS Development”, “iOS Project Detection”, showing how the author expects the agent to judge fit, collect context, and produce verifiable output.
Trigger evidence: Prioritize the author’s wording around when to use it, what context to collect, and what output shape to produce.
Evidence boundary: Author text states facts, repository files prove commands and paths, and Fluxly only adds fit, limits, and usage judgment.

How To Use It

Inputs: Provide target material, scope, expected result, forbidden changes, and validation method.
Invocation: Name axiom-using-axiom directly; if the source includes slash commands, start with the command and then add task context.
Validation: Start small and check whether the result follows “The Rule / Red Flags — iOS-Specific Rationalizations / Skill Priority for iOS Development” before expanding.

Boundaries And Review

Dependencies: It usually needs no extra API key, so start with a small validation task.
Permissions: Declared permissions include read / write; ask the agent to state file, command, and rollback boundaries before acting.
Quality bar: A useful result names the deliverable, evidence, and next action. Generic prose means the task needs tighter context.

<EXTREMELY-IMPORTANT> If you think there is even a 1% chance an Axiom skill might apply to your iOS/Swift task, you ABSOLUTELY MUST check for the skill.

IF AN AXIOM SKILL APPLIES TO YOUR iOS/SWIFT TASK, YOU DO NOT HAVE A CHOICE. YOU MUST USE IT.

This is not negotiable. This is not optional. You cannot rationalize your way out of this. </EXTREMELY-IMPORTANT>

Using Axiom Skills

The Rule

Check for Axiom skills BEFORE ANY RESPONSE when working with iOS/Swift projects. This includes clarifying questions. Even 1% chance means check first.

Red Flags — iOS-Specific Rationalizations

These thoughts mean STOP—you're rationalizing:

Thought	Reality
"This is just a simple build issue"	Build failures have patterns. Check ios-build first.
"I can fix this SwiftUI bug quickly"	SwiftUI issues have hidden gotchas. Check ios-ui first.
"Let me just add this database column"	Schema changes risk data loss. Check ios-data first.
"This async code looks straightforward"	Swift concurrency has subtle rules. Check ios-concurrency first.
"I'll debug the memory leak manually"	Leak patterns are documented. Check ios-performance first.
"Let me explore the Xcode project first"	Axiom skills tell you HOW to explore. Check first.
"I remember how to do this from last time"	iOS changes constantly. Skills are up-to-date.
"This iOS/platform version doesn't exist"	Your training ended January 2025. Invoke Axiom skills for post-cutoff facts.
"The user just wants a quick answer"	Quick answers without patterns create tech debt. Check skills first.
"This doesn't need a formal workflow"	If an Axiom skill exists for it, use it.
"I'll gather info first, then check skills"	Skills tell you WHAT info to gather. Check first.

Skill Priority for iOS Development

When multiple Axiom skills could apply, use this priority:

Environment/Build first (ios-build) — Fix the environment before debugging code
Architecture patterns (ios-ui, axiom-ios-data, axiom-ios-concurrency) — These determine HOW to structure the solution
Implementation details (ios-integration, axiom-ios-ai, axiom-ios-vision) — These guide specific feature work

Examples:

"Xcode build failed" → ios-build first (environment)
"Add SwiftUI screen" → ios-ui first (architecture), then maybe ios-integration if using system features
"App is slow" → ios-performance first (diagnose), then fix the specific domain
"Network request failing" → ios-build first (environment check), then ios-networking (implementation)

iOS Project Detection

Axiom skills apply when:

Working directory contains .xcodeproj or .xcworkspace
User mentions iOS, Swift, Xcode, SwiftUI, UIKit
User asks about Apple frameworks (SwiftData, CloudKit, etc.)
User reports iOS-specific errors (concurrency, memory, build failures)

Using Axiom Router Skills

Axiom uses router skills for progressive disclosure:

Check the appropriate router skill first (ios-build, axiom-ios-ui, axiom-ios-data, etc.)
Router will invoke the specialized skill(s) you actually need
Follow the specialized skill exactly

Do not skip the router. Routers have decision logic to select the right specialized skill.

Multi-Domain Questions

When a question spans multiple domains, invoke ALL relevant routers — don't stop after the first one.

Examples:

"My SwiftUI view doesn't update when SwiftData changes" → invoke both ios-ui AND ios-data
"My widget isn't showing updated data from SwiftData" → invoke both ios-integration AND ios-data
"My Foundation Models session freezes the UI" → invoke both ios-ai AND ios-concurrency
"My Core Data saves lose data from background tasks" → invoke both ios-data AND ios-concurrency

How to tell: If the question mentions symptoms from two different domains, or involves two different frameworks, invoke both routers. Each router has cross-domain routing guidance for common overlaps.

Backward Compatibility

Direct skill invocation still works: /skill axiom-swift-concurrency
Commands work unchanged: /axiom:fix-build, /axiom:audit-accessibility
Agents work via routing or direct command invocation

When Axiom Skills Don't Apply

Skip Axiom skills for:

Non-iOS/Swift projects (Android, web, backend)
Generic programming questions unrelated to Apple platforms
Questions about Claude Code itself (use claude-code-guide skill)

But when in doubt for iOS/Swift work: check first, decide later.

Source: ComeOnOliver/skillshub — distributed by TomeVault.

Fluxly profile Author and license come from source; runtime, permissions, and network are Fluxly detections or estimates

Fluxly category: Other
Author-declared agents: No explicit declaration found; this is not inferred or tested compatibility
Static check: 88 / 100 · heuristic scan, not runtime safety proof
Author / version / license: @tomevault-io · no license declared
Fluxly token estimate: Lean
Fluxly setup estimate: Plug-and-play
External API key: No requirement detected
Detected OS requirements: Unspecified
Runtime requirements: Unspecified
Detected file/system behavior: Read-only
Write / modify
Detected network behavior: Local-only
Install commands: None (reference only)

Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.

Heads up: 未限定 allowed-tools，默认拥有全部工具权限。

Output preview axiom-using-axiom.preview

The current SKILL.md does not define a fixed output example.

SKILL.md SKILL.md

<EXTREMELY-IMPORTANT>
If you think there is even a 1% chance an Axiom skill might apply to your iOS/Swift task, you ABSOLUTELY MUST check for the skill.

IF AN AXIOM SKILL APPLIES TO YOUR iOS/SWIFT TASK, YOU DO NOT HAVE A CHOICE. YOU MUST USE IT.

This is not negotiable. This is not optional. You cannot rationalize your way out of this.
</EXTREMELY-IMPORTANT>

# Using Axiom Skills

## The Rule

**Check for Axiom skills BEFORE ANY RESPONSE when working with iOS/Swift projects.** This includes clarifying questions. Even 1% chance means check first.

## Red Flags — iOS-Specific Rationalizations

These thoughts mean STOP—you're rationalizing:

| Thought | Reality |
|---------|---------|
| "This is just a simple build issue" | Build failures have patterns. Check ios-build first. |
| "I can fix this SwiftUI bug quickly" | SwiftUI issues have hidden gotchas. Check ios-ui first. |
| "Let me just add this database column" | Schema changes risk data loss. Check ios-data first. |
| "This async code looks straightforward" | Swift concurrency has subtle rules. Check ios-concurrency first. |
| "I'll debug the memory leak manually" | Leak patterns are documented. Check ios-performance first. |
| "Let me explore the Xcode project first" | Axiom skills tell you HOW to explore. Check first. |
| "I remember how to do this from last time" | iOS changes constantly. Skills are up-to-date. |
| "This iOS/platform version doesn't exist" | Your training ended January 2025. Invoke Axiom skills for post-cutoff facts. |
| "The user just wants a quick answer" | Quick answers without patterns create tech debt. Check skills first. |
| "This doesn't need a formal workflow" | If an Axiom skill exists for it, use it. |

…

Evidence boundary and execution chain

Author text anchors workflow facts; Fluxly only indexes current sections, terms, files, and commands.

sections -> The Rule → Red Flags — iOS-Specific Rationalizations → Skill Priority for iOS Development → iOS Project Detection → Using Axiom Router Skills → Multi-Domain Questions
terms    -> Check for Axiom skills BEFORE ANY RESPONSE when working with iOS/Swift projects. · Environment/Build first · Architecture patterns · Implementation details · router skills · Do not skip the router. · invoke ALL relevant routers — don't stop after the first one. · both
files/cmd -> .xcodeproj · .xcworkspace · /skill axiom-swift-concurrency · /axiom:fix-build · /axiom:audit-accessibility
body sha256 -> 7a184fc09628