القائمة
Use the Knots workflow through `kno` when asked to create a new knot from a rough request and you need a concise goal, exact acceptance criteria, and repeatable verification steps.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
Use the Knots workflow through `kno` when asked to drive a knot end to end, run a claimed knot to completion, or keep advancing a knot until it reaches a terminal state such as `SHIPPED`, or a passive waiting state such as `BLOCKED` or `DEFERRED`.
Use the Knots workflow through `kno` when asked to orchestrate an execution plan from start to finish, processing waves sequentially, steps within each wave sequentially, and launching knots within each step concurrently.
Use the Knots workflow through `kno` when asked to create a knot, work on a specific knot, claim or execute a knot, advance a knot to its next state, or recover or roll back a knot safely after blocked or failed work.
Cut a new release of foolery by confirming the version bump, syncing the release branch, previewing changes since the last tag, running quality gates, and publishing verified release artifacts.
Configure Foolery by writing a validated ~/.config/foolery/settings.toml and ~/.config/foolery/registry.json. Triggers: `foolery setup`, "configure foolery", "add an agent", "remove an agent", "change dispatch pools", "mount a repo". Works from any frontier agent (Claude, Codex, OpenCode, Gemini, Copilot) — use plain shell verbs, not harness-specific tooling.
Investigate Foolery lease, session, and server logs when asked why an agent turn failed to advance, rolled back unexpectedly, hung, leaked a lease, or skipped lease usage. Use this for the dev server on port 3000, the installed runtime on port 3210, and recent 24-48 hour forensic reviews across both log roots.
استنادا إلى تصنيف SOC المهني
| name | knots-create |
| description | Use the Knots workflow through `kno` when asked to create a new knot from a rough request and you need a concise goal, exact acceptance criteria, and repeatable verification steps. |
Create or receive a lease before creating the knot:
kno lease create --nickname "<session-name>"
Pass the lease to kno new, notes, and handoff capsules. Authorship for notes
and handoff capsules comes from the bound lease. Without a lease, metadata can
be recorded as [unknown <date>].
Do not copy legacy --*-agentname/model/version identity flags from telemetry
or command history. They are deprecated and ignored by current kno.
Create one well-defined knot. Keep the title short and action-oriented. Put the
goal, verification steps, and constraints in -d. Put only numbered
acceptance criteria in --acceptance.
Write -d with these sections:
Goal: one short paragraph describing the user-visible outcome.Verification: a numbered list of repeatable checks with exact commands or
UI actions and the expected result for each step.Constraints: optional non-obvious requirements, exclusions, or scope
boundaries.Write --acceptance as a numbered list of observable outcomes. Reference exact
interfaces when they exist: CLI commands and flags, API routes, file paths,
state names, schema fields, event names, or UI surfaces. Avoid vague criteria
such as "works well", "clean up", or "handle edge cases".
Run:
kno new "<title>" -d $'Goal:\n<goal>\n\nVerification:\n1. <step>\n2. <step>' \
--acceptance $'1. <criterion>\n2. <criterion>' \
--lease <lease-id>
If verification is not yet repeatable, make that gap explicit in the knot so the agent can close it as part of the work.
Then attach a handoff capsule for the agent who will claim the knot:
kno update <id> -H "<capsule>" --lease <lease-id>
The capsule should include the key context, constraints, and verification notes that are not obvious from the title and acceptance criteria.