fai-technical-spike — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited fai-technical-spike (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
Run timeboxed experiments to de-risk technical decisions.
# Technical Spike: [Title]
**Time box:** [1-3 days]
**Owner:** [name]
**Goal:** [What question are we answering?]
## Hypothesis
[What do we expect to find?]
## Experiment
[What will we build/test to validate?]
## Decision Criteria
| Criterion | Target | Actual |
|-----------|--------|--------|
| Latency | < 500ms | — |
| Integration effort | < 2 days | — |
| Quality | >= 80% accuracy | — |
## Findings
[What did we discover?]
## Recommendation
[Go / No-Go / More research needed]
## Artifacts
- [Link to prototype code]
- [Link to benchmark results]| Type | Duration | Output |
|---|---|---|
| Feasibility | 1 day | Can we do X? Yes/No + evidence |
| Comparison | 2 days | A vs B with benchmark data |
| Integration | 2-3 days | Working prototype + rough edges list |
| Performance | 1-2 days | Benchmark results + bottleneck analysis |
| Practice | Why |
|---|---|
| Strict timebox | Prevents perfectionism — spike explores, doesn't build |
| Written conclusion | Forces clear decision, prevents "let me keep exploring" |
| Throwaway code is OK | Spike code is learning, not production |
| Share findings | Spike value is in the knowledge, not the code |
| Issue | Cause | Fix |
|---|---|---|
| Spike runs over timebox | Scope too broad | Narrow to one specific question |
| No clear conclusion | No decision criteria upfront | Define criteria BEFORE starting |
| Spike code goes to prod | No separation | Use separate branch, delete after |
| Team doesn't learn from spike | No writeup | Require written findings + demo |
| Practice | Rationale |
|---|---|
| Start simple, add complexity when needed | Avoid over-engineering |
| Automate repetitive tasks | Consistency and speed |
| Document decisions and tradeoffs | Future reference for the team |
| Validate with real data | Don't rely on synthetic tests alone |
| Review with peers | Fresh eyes catch blind spots |
| Iterate based on feedback | First version is never perfect |
fai-implementation-plan-generator — Planning and milestonesfai-review-and-refactor — Code review patternsfai-quality-playbook — Engineering quality standards~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.