القائمة
Use when launching, running, reviewing, or extending the Agentic Spec Team workflow that turns missions plus docs/data/mockups into evidence-first implementation specs.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Use when reviewing or modifying ZOB communication, ledgers, Mission Control coms, or live transport safety gates.
Use when an active ZOB handoff, live peer question, required-local coms delivery, or orchestration message is needed.
Use when planning, using, reviewing, or implementing ZOB /goal-linked TODOs, subtodos, TODO HUD progress, delegated TODO claims, or hierarchical subagent work graphs.
Use when working inside the ZOB Pi harness, designing agentic workflows, creating specialist prompts, adding Pi extensions, or turning repeated tasks into software factories.
Use before non-trivial work, uncertain tool selection, orchestration, delegation, context lookup, factory work, autonomous-runtime claims, or evidence-gated completion.
Use when driving the append-only metadata-only worklist blackboard — appending events, reading derived directives, leasing/satisfying directives by content hash, delivering idempotent DIRECTIVE_READY notifications, running the liveness watchdog (observe/escalate), or building/querying the dependency DAG.
| name | zob-agentic-spec-team |
| description | Use when launching, running, reviewing, or extending the Agentic Spec Team workflow that turns missions plus docs/data/mockups into evidence-first implementation specs. |
Use this skill to run a reusable ZOB-native spec production workflow. It ingests a mission plus explicit source paths, coordinates a run-scoped ZTeam, asks the human only through spec-chief, and produces a detailed, testable, traceable implementation spec.
V1 packaging is composite and deliberately not a runtime extension. It is a specialized Agent Factory pattern:
Skill = rules and operating contract
Factory = repeatable checkpoints, sentinels, validators
ZTeam/ZAgents = run-scoped human-facing team
CLI = scriptable entrypoint and tmux automation
Coms = parent-visible async asks, blockers, evidence refs, and oracle/no-ship routing
Use the generic examples/agent-factory-tmux-comms/ pattern for a smaller teaching version of the same shape.
npm run spec-run -- init --mission "..." --source docs/ --source data/export.csv --name billing-redesign
npm run spec-run:auto-pilot -- --mission-file specs/mission.md --source docs/ --source mockups/
Run artifacts are written under:
reports/agentic-spec-runs/<run_id>/
spec-chief — sole human interlocutor, run coordinator, blocker owner.source-intake-steward — inventories sources, sensitivity, freshness, contradictions.data-profile-analyst — profiles CSV/XLS/structured data and writes dictionaries.domain-modeler — extracts entities, states, rules, glossary, assumptions.ux-flow-analyst — maps mockups/screens/user journeys and UI state matrix.spec-writer — writes mission spec, requirements, slices, contracts.bdd-writer — writes acceptance criteria and Gherkin/data-driven examples.planner-handoff-writer — produces workgraph, implementation tasks, agent prompts.spec-oracle — validates traceability, open questions, safety, and no-ship.run-manifest.json
source-register.json/source-register.md
questions.jsonl/questions.md
answers.jsonl/answers.md
analysis/data-profile.json
analysis/data-dictionary.md
analysis/domain-model.md
analysis/business-rules.md
analysis/ux-flows.md
spec/mission-spec.md
spec/functional-requirements.md
spec/non-functional-requirements.md
validation/acceptance-criteria.md
validation/bdd-scenarios.feature.md
validation/traceability-matrix.json
validation/traceability-matrix.md
handoff/workgraph.md
handoff/implementation-tasks.md
oracle/final-oracle-review.json
final-report.json
status.json
Every requirement must map to at least one of:
source_ref | owner_answer | explicit_assumption | decision_ref
The traceability matrix must connect:
source_ref -> extracted_fact/answer/assumption -> requirement -> acceptance_criteria -> task -> oracle_check
No requirement may be accepted if it is unsupported or if the supporting source is known to be stale/contradictory without an explicit assumption or decision.
spec-chief is the only role that asks the owner questions. Other agents propose questions to spec-chief; they do not directly ask the human unless explicitly instructed.
Question shape:
{
"schema": "agentic-spec.question.v1",
"question_id": "Q-001",
"status": "open",
"blocking": true,
"origin_agent": "domain-modeler",
"concerns": ["REQ-014", "AC-022"],
"source_refs": ["SRC-003"],
"question": "Which billing rule wins?",
"options": [{ "id": "A", "label": "Invoice date wins" }],
"recommended_option": "A"
}
If a blocking question is open, auto-pilot must return blocked/no_ship=true and point to questions.md. It must not invent answers.
Answers may be recorded with:
npm run spec-run -- answer <run_id> Q-001 --text "..." --answered-by owner
npm run spec-run -- resume <run_id>
safe_to_copy instead of citation/context evidence;no_ship=true;no_ship=false.V1 uses .pi/skills, .pi/factories, .pi/zagents, .pi/zteams, and scripts/spec-run.mjs.
V2 may add a runtime /spec-run extension command only after the script/team/factory workflow is stable and validated.
Minimum parent validation for scaffold changes:
npm run check
node scripts/spec-run.mjs --help
node scripts/spec-run.mjs init --name smoke --mission "smoke spec" --source README.md
node scripts/spec-run.mjs validate <run_id>