threadroot 0.1.0

package/skills/system-design/references/architecture-checklist.md

@@ -0,0 +1,26 @@
+# Architecture Checklist
+
+Use this checklist to keep architecture useful and grounded.
+
+## Product Fit
+
+- Name the primary user and the job the system performs.
+- State what must work on day one versus what can wait.
+- Prefer a boring design when requirements are uncertain.
+
+## Boundaries
+
+- Define module/service ownership and data ownership.
+- List synchronous calls, async jobs, external services, and human/manual steps.
+- Avoid splitting services until ownership, scale, or deployment needs justify the split.
+
+## Tradeoffs
+
+- Explain why the chosen design is simpler or safer than alternatives.
+- Call out which assumptions would force a redesign.
+- Include migration and rollback paths for risky changes.
+
+## Production Readiness
+
+- Include authn/authz, secrets, rate limits, validation, logging, metrics, alerts, backups, and disaster recovery when relevant.
+- Include a small validation plan: tests, load checks, security checks, smoke checks, and manual acceptance.

package/skills/system-design/references/reliability-observability.md

@@ -0,0 +1,17 @@
+# Reliability And Observability
+
+Use this reference when the system has queues, distributed calls, uptime expectations, or production operations.
+
+## Reliability Questions
+
+- What happens when each dependency is slow, unavailable, or returns bad data?
+- What must be retried, deduplicated, idempotent, or dead-lettered?
+- What data must never be lost, and what can be recomputed?
+- What is the rollback path for schema, deploy, and config changes?
+
+## Observability
+
+- Track user-impacting symptoms first: latency, traffic, errors, and saturation.
+- Add logs around decisions and failure boundaries, not every line of code.
+- Emit metrics for queue depth, retry count, job age, dependency errors, and business-critical outcomes.
+- Define an alert only when a human can take useful action.

package/skills/write-docs/SKILL.md

@@ -0,0 +1,20 @@
+---
+name: write-docs
+description: Use when writing or updating READMEs, command docs, setup guides, architecture docs, agent instructions, generated context, or user-facing technical explanations.
+scope: project
+tags:
+  - docs
+---
+
+# Write Docs
+
+Document the job, the path, and the gotchas.
+
+## Workflow
+
+1. Start with what the user can do after reading.
+2. Include runnable commands and expected outputs when helpful.
+3. Keep concepts close to the commands that use them.
+4. Call out local-only, cloud, auth, security, and destructive behavior clearly.
+5. Remove stale commands and unsupported promises.
+6. Keep docs aligned with tests or smoke paths.

package/skills/write-docs/evals/triggers.json

@@ -0,0 +1,12 @@
+{
+  "shouldTrigger": [
+    "Update the README with the new install command and smoke test.",
+    "Document how this MCP setup flow works for users.",
+    "Write concise command docs for the skills CLI."
+  ],
+  "shouldNotTrigger": [
+    "Debug this TypeScript type error.",
+    "Review this auth change for vulnerabilities.",
+    "Design the event ingestion architecture."
+  ]
+}