Run this repository's work through NodeSpace's built-in playbook and the adopted community workflow skills #3712

Blocked: waits for a workable sync system. This repository's work stays on GitHub issues and nodespace-docs until then, and its development process (skills, commands, hooks, the agent guide) is not changed before the move. The adapted skills ship in the product first (#3719, #3720, #3722); this issue is where the repository starts using them.

Overview

Make this repository the first real user of NodeSpace's built-in playbook: the seeded schemas (spec, plan, task, decision), skills, queues and Plays (ADR-092, ADR-093, ADR-094). The procedures it runs are the adapted community workflow skills (#3719 and #3720), held as skill nodes in the graph and handed to the agent by NodeSpace, not installed into a harness. Using it ourselves is how we find what the built-in playbook is missing before anyone else does, and whether the rules do anything.

Problem Statement

• The mandatory startup sequence is prose in startup-sequence.md and the repository's agent instruction file, plus hooks. Nothing records whether the baseline was run, and the sequence cannot serve as the shipped pattern for other projects.
• The built-in playbook has not been used for real work, on any harness.
• The task spec rule (ADR-097) now applies only to a task that links a spec. Whether development work here actually starts with an approved spec is unmeasured.

Proposed Solution

• A skill "Set up a working checkout for nodespace-core", attached to this repo's project node, holding the git status, pull, worktree, install and baseline steps.
• A checklist item "Baseline recorded" on tasks, and an optional Play that rejects moving to in_review without it.
• For tasks that live in NodeSpace, drop gh:assign and gh:status from the sequence; claiming by version replaces them.
• The merge queue stays a script and reports to the task. bun run merge keeps its queue and lock in git; NodeSpace does not run builds or hold the lock. A task in ready_to_merge (Adapt the community implement and review workflows into NodeSpace delivery skills: test-first, review by a separate session, a decision per finding #3720) is what says "merge this": the gate takes its pull request from the "Ready to merge" queue, moves the task to done and records the commit when the pull request lands, and moves it back to changes_requested with the reason when it is ejected. A session waits on the task (A CLI command that waits until a node or a queue changes, so a session can wait for its review #3723) or on the command, as today.
• Work from NodeSpace tasks here, using the adapted skills from Adapt the community spec, plan-review and ticket-splitting workflows into NodeSpace planning skills #3719 and Adapt the community implement and review workflows into NodeSpace delivery skills: test-first, review by a separate session, a decision per finding #3720 as the procedures. The skills are the ones the product ships, attached to the queues; nothing is installed into a harness except NodeSpace's own connector. The review commands, the issue skill and the hooks this repository uses today are replaced at this point, not before.
• Do the work on at least two harnesses (see Confirm what each coding harness actually receives from NodeSpace #3721 for what each one receives).
• Keep three counts for the period and record them here:
  • tasks started that link an approved spec, against tasks started that link no spec (ADR-097 §7);
  • how often a Play was switched off or a task was created already started to get past a rule;
  • questions the agent asked the user per completed task.

Documentation

• ADR-092 §6 to §9 - the seeded Plays, Ready tasks, the seeded skills and queries, and that installable bundles were removed: the playbook is what a database is seeded with
• ADR-094 "The shipped workflow" - queues, procedures and standards as skills attached to queries and a project
• ADR-093 §2 to §6 - how a coding agent receives skills and task context, per harness
• ADR-072 - a seed is a starting point; an edited aspect is the user's
• ADR-097 §1, §6 and §7 - the spec rule and what to count
• Startup sequence, issue workflow, development/overview.md - what moves
• Updates: development/startup-sequence.md, development/overview.md

Architecture Impact

None. Uses existing primitives (skills attached to nodes, checklist children, saved queries, Plays). No bundle format, playbook type or install mechanism is added (ADR-092 §9 removed those).

Acceptance Criteria

• The setup skill exists, attached to this repo's project, and is delivered to an agent starting a task
• A task can carry a "Baseline recorded" checkbox, and the optional Play rejects in_review without it
• startup-sequence.md points to the skill and no longer duplicates its steps; the startup content in the agent instruction file is absorbed into the graph (skill and project standards), not edited in place
• The existing check-feature-branch.ts and plan-mode reminder hooks are kept or removed, with the reason written down
• Real tasks in this repository are taken from Ready tasks, worked with the adapted skills and finished, on at least two harnesses
• The three counts above are recorded on this issue with what they show
• Each place the playbook failed or had to be worked around is filed as its own issue, saying which of the four parts it is in (schema, skill, query, Play)
• Code passes bun run quality:fix

Technical Specifications

Reference Files

• development/startup-sequence.md and development/issue-workflow.md (nodespace-docs)
• The repository's agent instruction file (content to absorb into the graph), .claude/settings.json, .claude/hooks/
• packages/core/src/playbook/core_plays.rs, packages/core/src/services/query_service/core_queries.rs, packages/agent/src/seeds/skills/

Implementation Details

• The baseline Play is a sketch; whether to reject at in_review or at in_progress is a real choice (the checklist may not exist when the task starts). Try it on a real task first.
• Keep bun run gh:* and EnterWorktree as repository tooling. Only ordering and recorded state move.
• Do not embed issue numbers in nodespace-docs (documentation standard).
• Questions per task is counted by hand for now; nothing in the product records it.

Dependencies

• Remove requires_spec from task; the spec rule applies only to a task that links a spec #3718 (the spec rule this trial runs under)
• Adapt the community spec, plan-review and ticket-splitting workflows into NodeSpace planning skills #3719 (planning skills)
• Adapt the community implement and review workflows into NodeSpace delivery skills: test-first, review by a separate session, a decision per finding #3720 (delivery skills)

Related Issues

• Refuse repo writes until the session has an in-progress task with an approved spec #3710 (the rule as first shipped)
• Confirm what each coding harness actually receives from NodeSpace #3721 (what each harness receives)

Non-Goals

• Changing how GitHub issues are tracked
• Moving or renaming the instruction file: its content is absorbed into the graph and the file is generated from it later
• Checking an agent's repository writes (ADR-097 records why it is not built)
• A bundle format, a playbook node type, a marketplace or installing a playbook: the playbook stays the set a database is seeded with
• Changing the shipped seeds: what using them here shows is wrong is filed separately