diff --git a/proposal-template.abi.md b/proposal-template.abi.md
deleted file mode 100644
index 7a1c372..0000000
--- a/proposal-template.abi.md
+++ /dev/null
@@ -1,31 +0,0 @@
-# Types
-
-## <a href="#api_type_one" name="api_type_one"></a> `api-type-one`: record
-
-  Short description
-  
-  Explanation for developers using the API.
-
-Size: 16, Alignment: 8
-
-### Record Fields
-
-- <a href="api_type_one.property1" name="api_type_one.property1"></a> [`property1`](#api_type_one.property1): `u64`
-
-
-- <a href="api_type_one.property2" name="api_type_one.property2"></a> [`property2`](#api_type_one.property2): `string`
-
-
-# Functions
-
-----
-
-#### <a href="#api_function_one" name="api_function_one"></a> `api-function-one` 
-
-  Short description
-  
-  Explanation for developers using the API.
-##### Results
-
-- [`api-type-one`](#api_type_one)
-
diff --git a/proposal-template.wit.md b/proposal-template.wit.md
deleted file mode 100644
index 3c7e8ef..0000000
--- a/proposal-template.wit.md
+++ /dev/null
@@ -1,32 +0,0 @@
-# [Proposal Template] API
-
-[This document contains the actual specification. It should be written in the WIT interface definition format. You can find more documentation on the WIT syntax (coming soon!).]
-
-[Note that all comments inside of WIT code blocks will be included in the developer facing documentation for language bindings generated using this WIT file. If there is additional information that needs to be communicated to implementers of the API, then these should be captured in text directly below the code block.]
-
-[If you want to include examples of the API in use, these should be in the README and linked to from this file.]
-
-## api_type_one
-
-```wit
-/// Short description
-///
-/// Explanation for developers using the API.
-record api-type-one {
-    property1: u64,
-    property2: string,
-}
-```
-
-More rigorous specification details for the implementer go here, if needed.
-
-## api_function_one
-
-```wit
-/// Short description
-///
-/// Explanation for developers using the API.
-api-function-one: func() -> api-type-one
-```
-
-If needed, this would explain what a compliant implementation MUST do, such as never returning an earlier result from a later call.
diff --git a/wasi-threads.abi.md b/wasi-threads.abi.md
new file mode 100644
index 0000000..652e197
--- /dev/null
+++ b/wasi-threads.abi.md
@@ -0,0 +1,34 @@
+# Types
+
+## <a href="#thread_id" name="thread_id"></a> `thread-id`: `u32`
+
+  Unique thread identifier.
+
+Size: 4, Alignment: 4
+
+## <a href="#errno" name="errno"></a> `errno`: enum
+
+  Error codes returned by the `thread-spawn` function.
+
+Size: 1, Alignment: 1
+
+### Enum Cases
+
+- <a href="errno.eagain" name="errno.eagain"></a> [`eagain`](#errno.eagain)
+
+  TBD
+
+# Functions
+
+----
+
+#### <a href="#thread_spawn" name="thread_spawn"></a> `thread-spawn` 
+
+  Creates a new thread.
+##### Params
+
+- <a href="#thread_spawn.start_arg" name="thread_spawn.start_arg"></a> `start-arg`: handle<start-arg>
+##### Results
+
+- result<[`thread-id`](#thread_id), [`errno`](#errno)>
+
diff --git a/wasi-threads.wit.md b/wasi-threads.wit.md
new file mode 100644
index 0000000..244550f
--- /dev/null
+++ b/wasi-threads.wit.md
@@ -0,0 +1,41 @@
+# WASI threads API
+
+WASI threads is an API for thread creation.
+
+It's goal is to provide functions that allow implementation of a subset of `pthreads` API, but it doesn't aim to be 100% compatible with POSIX threads standard.
+
+
+## thread-id
+
+```wit
+/// Unique thread identifier.
+type thread-id = u32
+```
+
+## start-arg
+
+```wit
+/// A reference to data passed to the start function (`wasi_thread_start()`) called by the newly spawned thread.
+resource start-arg {
+}
+```
+
+## errno
+
+```wit
+/// Error codes returned by the `thread-spawn` function.
+enum errno {
+    /// TBD
+    eagain,
+}
+```
+
+## thread_spawn
+
+```wit
+/// Creates a new thread.
+thread-spawn: func(
+    /// A value being passed to a start function (`wasi_thread_start()`).
+    start-arg: start-arg,
+) -> result<thread-id, errno>
+```