---
description: Run one or more story contracts (A01-A10, S01-S11) with story-specific skills and durable outputs.
args: <story-id|chain|all> <input...>
section: Research Workflows
topLevelCli: true
---
Run story-agent workflow: $@

This is an execution request. Do not answer by explaining the protocol. Execute the requested story agent(s), write durable artifacts, and verify the expected files exist.

Write substantial artifacts with the `write` tool, not an inline shell command, Python `-c`, or heredoc. This is required for Windows compatibility and prevents `spawn ENAMETOOLONG`.

## Architecture

Each story is a separate agent specification with a paired story skill. The parent workflow is the router, executor, orchestrator, and verifier.

The `story-*` names in the table are local agent specification IDs. Do not call `subagent` with `story-*` agent names unless the visible `subagent` tool explicitly lists that exact story name as a supported runtime mode. In the current Pi runtime, custom story specifications can appear in the startup "Agents" list while the `subagent` tool still exposes only built-in modes. Treat the story files as executable contracts for the parent workflow to apply directly.

Journal-Yuga stories (`S01`-`S11`) also use the shared `journal-yuga-common` skill. That common layer controls per-instance state, the clarification gate, the `хватит вопросов` force-start phrase, primary venue database lookup, journal dossier lookup, curated-list fallback, web fallback, and automatic journal dossier updates.

| Story | Agent | Skill | Primary output |
| --- | --- | --- | --- |
| A01 | `story-a01-briefer` | `story-a01-briefer` | `A01-briefer-brief.md` |
| A02 | `story-a02-librarian` | `story-a02-librarian` | `A02-librarian-resource-list.md` |
| A03 | `story-a03-eligibility-screener` | `story-a03-eligibility-screener` | `A03-eligibility-verdicts.md` |
| A04 | `story-a04-quality-screener` | `story-a04-quality-screener` | `A04-quality-resource-matrix.md` |
| A05 | `story-a05-review-summarizator` | `story-a05-review-summarizator` | `A05-resource-review.md` |
| A06 | `story-a06-validation-hu-assistant` | `story-a06-validation-hu-assistant` | `A06-hu-corrections-log.md` |
| A07 | `story-a07-analyser` | `story-a07-analyser` | `A07-landscapes.md` |
| A08 | `story-a08-analysis-hu-assistant` | `story-a08-analysis-hu-assistant` | `A08-focuses-log.md` |
| A09 | `story-a09-hypothiser` | `story-a09-hypothiser` | `A09-hypothesis-system.md` |
| A10 | `story-a10-reporter` | `story-a10-reporter` | `A10-analytical-report.md` |
| S01 | `story-s01-journal-pool` | `story-s01-journal-pool` | `S01-journal-pool.md` |
| S02 | `story-s02-mismatch-map` | `story-s02-mismatch-map` | `S02-mismatch-map.md` |
| S03 | `story-s03-positioning-routes` | `story-s03-positioning-routes` | `S03-positioning-routes.md` |
| S04 | `story-s04-formal-edit-plan` | `story-s04-formal-edit-plan` | `S04-minimal-formal-edit-plan.md` |
| S05 | `story-s05-proceedings-plan` | `story-s05-proceedings-plan` | `S05-proceedings-plan.md` |
| S06 | `story-s06-strategic-designs` | `story-s06-strategic-designs` | `S06-strategic-article-designs.md` |
| S07 | `story-s07-disciplinary-translation` | `story-s07-disciplinary-translation` | `S07-disciplinary-translation-plan.md` |
| S08 | `story-s08-revision-plan` | `story-s08-revision-plan` | `S08-revision-plan.md` |
| S09 | `story-s09-corpus-profile` | `story-s09-corpus-profile` | `S09-journal-corpus-profile.md` |
| S10 | `story-s10-submission-package` | `story-s10-submission-package` | `S10-submission-package.md` |
| S11 | `story-s11-editorial-board-profile` | `story-s11-editorial-board-profile` | `S11-editorial-board-profile.md` |

## Supported calls

- Single story: `/story A01 <input files and natural-language task>`
- Multiple explicit stories: `/story A01,A02,A03 <input files and task>`
- Chain mode: `/story chain A01-A10 <input files and task>`
- Journal-Yuga chain: `/story chain S01-S11 <input files and task>`
- All known stories: `/story all <input directory or task>`

`A01-A10` expands to A01 through A10. `S01-S11` expands to S01 through S11.

## Required durable files

Derive a short slug from the task or input path: lowercase, hyphenated, no filler words, at most 5 words.

Write:

- `outputs/.status/abulafia-live-status.md`
- `outputs/.plans/<slug>-story-plan.md`
- `outputs/.drafts/<slug>-story-evidence.md`
- `outputs/<slug>/<primary-output>` for each story
- `outputs/<slug>/story-run-report.md`

For Journal-Yuga stories (`S01`-`S11`), use the Journal-Yuga run directory:

- `outputs/journal-yuga-runs/<slug>/state.yaml`
- `outputs/journal-yuga-runs/<slug>/publication-model.yaml`
- `outputs/journal-yuga-runs/<slug>/evidence-ledger.yaml`
- `outputs/journal-yuga-runs/<slug>/protected-core.md`
- `outputs/journal-yuga-runs/<slug>/intake.md`
- `outputs/journal-yuga-runs/<slug>/acceptance-criteria.md`
- `outputs/journal-yuga-runs/<slug>/decision-log.md`
- `outputs/journal-yuga-runs/<slug>/journal-search-log.md`
- `outputs/journal-yuga-runs/<slug>/<primary-output>`
- `outputs/journal-yuga-runs/<slug>/story-run-report.md`

If the input is missing or a story cannot run, still write a blocked primary output and include `Status: BLOCKED` with the exact reason.

## Workflow

1. Parse the requested story IDs.
2. Read the relevant methodology docs:
   - `website/src/content/docs/agents/megaagent-user-stories.md`
   - `website/src/content/docs/agents/journal-yuga-user-stories.md`
   - `website/src/content/docs/agents/story-evaluation-methodology.md`
   - for Journal-Yuga stories, also read `../journal_yuga_use_cases.md` if it exists; if it does not exist, continue without blocking.
3. Create the plan file with:
   - requested stories;
   - resolved agents and skills;
   - input paths or user-provided task text;
   - output directory;
   - dependency order;
   - blocked inputs.
4. Create or update `outputs/.status/abulafia-live-status.md` before substantial work. Keep it short and current.
5. For each story, execute its dedicated story contract directly in the parent workflow. Apply the paired skill and the matching `.abulafia/agents/story-*.md` specification as the agent persona/contract.
6. Route stories through the bounded contexts in `journal-yuga-common`. For explicit `chain` calls, pass a prior output forward only when it is a real dependency. For `all`, build a dependency graph and do not pretend that every S-story is a linear successor.
7. After each story contract completes, verify on disk that the expected primary output exists.
8. Write evidence notes listing:
   - executed story contracts;
   - output paths;
   - missing or blocked artifacts;
   - assumptions;
   - handoff relationships.
9. Write `story-run-report.md` in the selected output directory with:
   - Coverage Table;
   - Per-story status;
   - Produced artifacts;
   - Blockers;
   - Recommended validation command using `/evaluate-stories`.

## Live status

The UI reads `outputs/.status/abulafia-live-status.md` while the workflow is running. Update this file after intake, after each major lookup, after each story contract, and whenever the recommended next move changes.

Use this compact format:

```md
# Abulafia Live Status
- Stage: <current phase>
- Active contracts: <story ids and agent specs>
- Skills: <skills currently applied>
- Sources / dossiers: <files, venue database, journal dossiers, web sources, or none yet>
- Working hypothesis: <public, concise hypothesis being checked; not hidden chain-of-thought>
- Latest proposals: <1-3 current recommendations or none yet>
- Next step: <immediate next action>
```

Do not write hidden chain-of-thought or private reasoning. Write public operational state, checked assumptions, candidate recommendations, and the next action.

## Execution mode

Default mode is direct execution. The parent workflow reads the story specification and skill contract, performs the work, writes the required files, and records `Execution mode: direct` in the evidence file.

Do not submit bare tool names, partial tool names, or empty tool calls. When using file tools, include a valid path argument. If a needed tool is unavailable or its schema is unclear, continue in direct mode and write a blocked artifact with the exact blocker instead of trying malformed calls.

Delegation is optional and only for supporting work. If the visible `subagent` tool lists a compatible built-in runtime mode such as `researcher`, `reviewer`, `writer`, or `verifier`, a story may delegate a narrow supporting task to that built-in mode. Do not use built-in modes as replacements for the story contract; the parent remains responsible for the final story artifact.

For chain runs, execute stories sequentially unless the requested stories are explicitly independent. Do not parallelize adjacent stories that depend on previous outputs.

## Journal-Yuga execution rules

These rules apply to `S01`-`S11` in addition to the normal story rules:

- Do not proceed past intake until acceptance criteria are complete or the user says `хватит вопросов`.
- If the user says `хватит вопросов`, set `forced_start: true` in `state.yaml`, continue with available information, and mark unknowns explicitly.
- Use lookup order: `knowledge/journals/journal_yuga_venue_database.md` first, then `knowledge/journals/*.md` dossiers, then `knowledge/journals/index.yaml`, then web search only if local knowledge is insufficient.
- Treat local journal data as a cache, not a whitelist. If fewer than three semantically plausible, evidence-qualified venues remain, use domain-agnostic web discovery when available; never pad the pool with unrelated local entries.
- Maintain `publication-model.yaml`, `evidence-ledger.yaml`, and `protected-core.md` according to the schemas in `knowledge/contracts/`.
- Enforce `unknown != absent`, distinguish vendor claims from independently checked facts, and require explicit user approval for `core_touching` changes.
- Record the lookup trail in `journal-search-log.md`.
- Automatically append compact task-derived observations to the relevant journal dossier when reusable knowledge is learned.
- Do not overwrite existing journal dossier observations.
- Separate observed facts, task-specific inferences, and unverified assumptions.
- Recommendations must explain relevance, required article changes, risk, effort, semantic-loss risk, confidence, and missing evidence.

## Story execution rules

- Do not collapse all stories into one generic assistant answer.
- Do not use `researcher`, `writer`, or `reviewer` as a replacement for a dedicated story contract.
- Story contracts may use researcher/writer/reviewer internally only when the story skill explicitly requires supporting work and those runtime modes are visibly available.
- Never fabricate sources, journals, editor interests, corpus metrics, article facts, or user decisions.
- Preserve explicit user constraints.
- Separate observed facts, assumptions, inferred recommendations, and missing evidence.
- Every primary output must be usable by the next story or by `/evaluate-stories`.

## Completion

Before responding, verify the report at the selected output path:

- For `A01`-`A10`: `outputs/<slug>/story-run-report.md`.
- For `S01`-`S11`: `outputs/journal-yuga-runs/<slug>/story-run-report.md`.

Never verify or read a bare `story-run-report.md` in the repository root. If the selected report path does not exist, create that exact file with a blocked report explaining why. The final chat response should list only the produced paths and the next validation command.