From 64d6af13e0d2de93679474c5b36098acea384905 Mon Sep 17 00:00:00 2001 From: calvin-archastro Date: Thu, 29 Oct 2026 17:35:36 -0700 Subject: [PATCH] docs(skills): tasks plans write scope as repository paths and lint before review The repository-rule check that tasks graph import and tasks review run uses each node's scope to pick language rules and read repository context. The skill's example used a prose label ("Export API"), which matches no files. The skill also never mentioned the check. - Field guidance and the example now write scope as repository paths. - Section 3 adds a dry-run lint step: fix errors in the node, override only with the human's approval, read not_evaluated as a model outage, and inspect every verdict with extract run plan.rule-verdicts. - Regenerated harness copies with tools/plugin-gen. Co-Authored-By: Claude Opus 5.5 --- plugins/antigravity/skills/tasks/SKILL.md | 32 ++++++++++++++++++++--- plugins/claude/skills/tasks/SKILL.md | 32 ++++++++++++++++++++--- plugins/codex/skills/tasks/SKILL.md | 32 ++++++++++++++++++++--- plugins/copilot/skills/tasks/SKILL.md | 32 ++++++++++++++++++++--- plugins/cursor/skills/tasks/SKILL.md | 32 ++++++++++++++++++++--- plugins/grok/skills/tasks/SKILL.md | 32 ++++++++++++++++++++--- plugins/opencode/skills/tasks/SKILL.md | 32 ++++++++++++++++++++--- plugins/pi/skills/tasks/SKILL.md | 32 ++++++++++++++++++++--- tasks/SKILL.md | 32 ++++++++++++++++++++--- 9 files changed, 261 insertions(+), 27 deletions(-) diff --git a/plugins/antigravity/skills/tasks/SKILL.md b/plugins/antigravity/skills/tasks/SKILL.md index 56b8cb5..79cc04c 100644 --- a/plugins/antigravity/skills/tasks/SKILL.md +++ b/plugins/antigravity/skills/tasks/SKILL.md @@ -177,8 +177,12 @@ content already has that shape: participants with labels of a few words, and about 4–8 messages. A wider diagram shrinks to fit the column and its text becomes unreadable. Draw one diagram instead of a paragraph that narrates the same sequence. -- Keep each implementation step to one or two lines. List touched files once - in `scope` instead of repeating paths in every step. +- Keep each implementation step to one or two lines. List the repository + paths the task changes once in `scope` (files, directories, or git globs + such as `src/api/export/`) instead of repeating them in every step. Write + paths, not a prose label like `"Export API"`: the repository-rule check + uses them to choose the rules for those languages and to read repository + context, and a label matches no files. - Label a guess as `Hypothesis:`, not as an observation. - Write a field that holds a fence or a table as a string array, one line per entry, as in the example below. Such an array is joined as raw markdown, so @@ -226,7 +230,7 @@ The review command also accepts optional `major_decisions` (not part of "grade": "low", "notes": "Reuses an existing, tested query path; blast radius is one new read-only endpoint." }, - "scope": ["Export API"], + "scope": ["src/api/export/", "tests/export-api.e2e.test.ts"], "exclusions": ["Scheduled exports"] }, { @@ -240,6 +244,7 @@ The review command also accepts optional `major_decisions` (not part of "grade": "low", "notes": ["Additive UI change on an existing button.", "No data model or auth changes."] }, + "scope": ["src/pages/results/", "tests/export-ui.e2e.test.ts"], "depends_on": ["export-api"], "dependency_reasons": {"export-api": "The download action needs the export endpoint."} } @@ -384,6 +389,27 @@ test each node with a reader that has only that node. Run exactly one round. Give the human a short summary in the progress update before review: per task, gaps found, how each was resolved, any moved to `major_decisions`, and any node left unchecked. +5. Lint the plan before opening the review: + + ```sh + "$archdev" --json tasks graph import --file plans/task-review.json --dry-run + ``` + + It writes nothing. Its `lint` list holds the deterministic plan lints and + `repository-rule` findings, which come from judging each node's brief + against this repository's rules (`.archdev/rules`, `rules/`) with Jev. + `tasks review start` runs the same checks and refuses to save while an + error stands. + - Fix each error in the node: rewrite the requirement the rule names, or + add an `Exemplar: ` line naming the sibling the task mirrors. + Re-run until no errors remain. + - Pass `--allow-lint ` (import) or `allow_lint` (review JSON) only + when the human approves that override. + - A `repository-rule` warning that says `not_evaluated` means the model + was unavailable. It does not block; re-run later. + - To see every rule's verdict for a node, run `"$archdev" extract run + plan.rule-verdicts --plan plans/task-review.json --json` and read the + receipt file it names. ## 4. Open the review and keep it running diff --git a/plugins/claude/skills/tasks/SKILL.md b/plugins/claude/skills/tasks/SKILL.md index 56b8cb5..79cc04c 100644 --- a/plugins/claude/skills/tasks/SKILL.md +++ b/plugins/claude/skills/tasks/SKILL.md @@ -177,8 +177,12 @@ content already has that shape: participants with labels of a few words, and about 4–8 messages. A wider diagram shrinks to fit the column and its text becomes unreadable. Draw one diagram instead of a paragraph that narrates the same sequence. -- Keep each implementation step to one or two lines. List touched files once - in `scope` instead of repeating paths in every step. +- Keep each implementation step to one or two lines. List the repository + paths the task changes once in `scope` (files, directories, or git globs + such as `src/api/export/`) instead of repeating them in every step. Write + paths, not a prose label like `"Export API"`: the repository-rule check + uses them to choose the rules for those languages and to read repository + context, and a label matches no files. - Label a guess as `Hypothesis:`, not as an observation. - Write a field that holds a fence or a table as a string array, one line per entry, as in the example below. Such an array is joined as raw markdown, so @@ -226,7 +230,7 @@ The review command also accepts optional `major_decisions` (not part of "grade": "low", "notes": "Reuses an existing, tested query path; blast radius is one new read-only endpoint." }, - "scope": ["Export API"], + "scope": ["src/api/export/", "tests/export-api.e2e.test.ts"], "exclusions": ["Scheduled exports"] }, { @@ -240,6 +244,7 @@ The review command also accepts optional `major_decisions` (not part of "grade": "low", "notes": ["Additive UI change on an existing button.", "No data model or auth changes."] }, + "scope": ["src/pages/results/", "tests/export-ui.e2e.test.ts"], "depends_on": ["export-api"], "dependency_reasons": {"export-api": "The download action needs the export endpoint."} } @@ -384,6 +389,27 @@ test each node with a reader that has only that node. Run exactly one round. Give the human a short summary in the progress update before review: per task, gaps found, how each was resolved, any moved to `major_decisions`, and any node left unchecked. +5. Lint the plan before opening the review: + + ```sh + "$archdev" --json tasks graph import --file plans/task-review.json --dry-run + ``` + + It writes nothing. Its `lint` list holds the deterministic plan lints and + `repository-rule` findings, which come from judging each node's brief + against this repository's rules (`.archdev/rules`, `rules/`) with Jev. + `tasks review start` runs the same checks and refuses to save while an + error stands. + - Fix each error in the node: rewrite the requirement the rule names, or + add an `Exemplar: ` line naming the sibling the task mirrors. + Re-run until no errors remain. + - Pass `--allow-lint ` (import) or `allow_lint` (review JSON) only + when the human approves that override. + - A `repository-rule` warning that says `not_evaluated` means the model + was unavailable. It does not block; re-run later. + - To see every rule's verdict for a node, run `"$archdev" extract run + plan.rule-verdicts --plan plans/task-review.json --json` and read the + receipt file it names. ## 4. Open the review and keep it running diff --git a/plugins/codex/skills/tasks/SKILL.md b/plugins/codex/skills/tasks/SKILL.md index 56b8cb5..79cc04c 100644 --- a/plugins/codex/skills/tasks/SKILL.md +++ b/plugins/codex/skills/tasks/SKILL.md @@ -177,8 +177,12 @@ content already has that shape: participants with labels of a few words, and about 4–8 messages. A wider diagram shrinks to fit the column and its text becomes unreadable. Draw one diagram instead of a paragraph that narrates the same sequence. -- Keep each implementation step to one or two lines. List touched files once - in `scope` instead of repeating paths in every step. +- Keep each implementation step to one or two lines. List the repository + paths the task changes once in `scope` (files, directories, or git globs + such as `src/api/export/`) instead of repeating them in every step. Write + paths, not a prose label like `"Export API"`: the repository-rule check + uses them to choose the rules for those languages and to read repository + context, and a label matches no files. - Label a guess as `Hypothesis:`, not as an observation. - Write a field that holds a fence or a table as a string array, one line per entry, as in the example below. Such an array is joined as raw markdown, so @@ -226,7 +230,7 @@ The review command also accepts optional `major_decisions` (not part of "grade": "low", "notes": "Reuses an existing, tested query path; blast radius is one new read-only endpoint." }, - "scope": ["Export API"], + "scope": ["src/api/export/", "tests/export-api.e2e.test.ts"], "exclusions": ["Scheduled exports"] }, { @@ -240,6 +244,7 @@ The review command also accepts optional `major_decisions` (not part of "grade": "low", "notes": ["Additive UI change on an existing button.", "No data model or auth changes."] }, + "scope": ["src/pages/results/", "tests/export-ui.e2e.test.ts"], "depends_on": ["export-api"], "dependency_reasons": {"export-api": "The download action needs the export endpoint."} } @@ -384,6 +389,27 @@ test each node with a reader that has only that node. Run exactly one round. Give the human a short summary in the progress update before review: per task, gaps found, how each was resolved, any moved to `major_decisions`, and any node left unchecked. +5. Lint the plan before opening the review: + + ```sh + "$archdev" --json tasks graph import --file plans/task-review.json --dry-run + ``` + + It writes nothing. Its `lint` list holds the deterministic plan lints and + `repository-rule` findings, which come from judging each node's brief + against this repository's rules (`.archdev/rules`, `rules/`) with Jev. + `tasks review start` runs the same checks and refuses to save while an + error stands. + - Fix each error in the node: rewrite the requirement the rule names, or + add an `Exemplar: ` line naming the sibling the task mirrors. + Re-run until no errors remain. + - Pass `--allow-lint ` (import) or `allow_lint` (review JSON) only + when the human approves that override. + - A `repository-rule` warning that says `not_evaluated` means the model + was unavailable. It does not block; re-run later. + - To see every rule's verdict for a node, run `"$archdev" extract run + plan.rule-verdicts --plan plans/task-review.json --json` and read the + receipt file it names. ## 4. Open the review and keep it running diff --git a/plugins/copilot/skills/tasks/SKILL.md b/plugins/copilot/skills/tasks/SKILL.md index 56b8cb5..79cc04c 100644 --- a/plugins/copilot/skills/tasks/SKILL.md +++ b/plugins/copilot/skills/tasks/SKILL.md @@ -177,8 +177,12 @@ content already has that shape: participants with labels of a few words, and about 4–8 messages. A wider diagram shrinks to fit the column and its text becomes unreadable. Draw one diagram instead of a paragraph that narrates the same sequence. -- Keep each implementation step to one or two lines. List touched files once - in `scope` instead of repeating paths in every step. +- Keep each implementation step to one or two lines. List the repository + paths the task changes once in `scope` (files, directories, or git globs + such as `src/api/export/`) instead of repeating them in every step. Write + paths, not a prose label like `"Export API"`: the repository-rule check + uses them to choose the rules for those languages and to read repository + context, and a label matches no files. - Label a guess as `Hypothesis:`, not as an observation. - Write a field that holds a fence or a table as a string array, one line per entry, as in the example below. Such an array is joined as raw markdown, so @@ -226,7 +230,7 @@ The review command also accepts optional `major_decisions` (not part of "grade": "low", "notes": "Reuses an existing, tested query path; blast radius is one new read-only endpoint." }, - "scope": ["Export API"], + "scope": ["src/api/export/", "tests/export-api.e2e.test.ts"], "exclusions": ["Scheduled exports"] }, { @@ -240,6 +244,7 @@ The review command also accepts optional `major_decisions` (not part of "grade": "low", "notes": ["Additive UI change on an existing button.", "No data model or auth changes."] }, + "scope": ["src/pages/results/", "tests/export-ui.e2e.test.ts"], "depends_on": ["export-api"], "dependency_reasons": {"export-api": "The download action needs the export endpoint."} } @@ -384,6 +389,27 @@ test each node with a reader that has only that node. Run exactly one round. Give the human a short summary in the progress update before review: per task, gaps found, how each was resolved, any moved to `major_decisions`, and any node left unchecked. +5. Lint the plan before opening the review: + + ```sh + "$archdev" --json tasks graph import --file plans/task-review.json --dry-run + ``` + + It writes nothing. Its `lint` list holds the deterministic plan lints and + `repository-rule` findings, which come from judging each node's brief + against this repository's rules (`.archdev/rules`, `rules/`) with Jev. + `tasks review start` runs the same checks and refuses to save while an + error stands. + - Fix each error in the node: rewrite the requirement the rule names, or + add an `Exemplar: ` line naming the sibling the task mirrors. + Re-run until no errors remain. + - Pass `--allow-lint ` (import) or `allow_lint` (review JSON) only + when the human approves that override. + - A `repository-rule` warning that says `not_evaluated` means the model + was unavailable. It does not block; re-run later. + - To see every rule's verdict for a node, run `"$archdev" extract run + plan.rule-verdicts --plan plans/task-review.json --json` and read the + receipt file it names. ## 4. Open the review and keep it running diff --git a/plugins/cursor/skills/tasks/SKILL.md b/plugins/cursor/skills/tasks/SKILL.md index 56b8cb5..79cc04c 100644 --- a/plugins/cursor/skills/tasks/SKILL.md +++ b/plugins/cursor/skills/tasks/SKILL.md @@ -177,8 +177,12 @@ content already has that shape: participants with labels of a few words, and about 4–8 messages. A wider diagram shrinks to fit the column and its text becomes unreadable. Draw one diagram instead of a paragraph that narrates the same sequence. -- Keep each implementation step to one or two lines. List touched files once - in `scope` instead of repeating paths in every step. +- Keep each implementation step to one or two lines. List the repository + paths the task changes once in `scope` (files, directories, or git globs + such as `src/api/export/`) instead of repeating them in every step. Write + paths, not a prose label like `"Export API"`: the repository-rule check + uses them to choose the rules for those languages and to read repository + context, and a label matches no files. - Label a guess as `Hypothesis:`, not as an observation. - Write a field that holds a fence or a table as a string array, one line per entry, as in the example below. Such an array is joined as raw markdown, so @@ -226,7 +230,7 @@ The review command also accepts optional `major_decisions` (not part of "grade": "low", "notes": "Reuses an existing, tested query path; blast radius is one new read-only endpoint." }, - "scope": ["Export API"], + "scope": ["src/api/export/", "tests/export-api.e2e.test.ts"], "exclusions": ["Scheduled exports"] }, { @@ -240,6 +244,7 @@ The review command also accepts optional `major_decisions` (not part of "grade": "low", "notes": ["Additive UI change on an existing button.", "No data model or auth changes."] }, + "scope": ["src/pages/results/", "tests/export-ui.e2e.test.ts"], "depends_on": ["export-api"], "dependency_reasons": {"export-api": "The download action needs the export endpoint."} } @@ -384,6 +389,27 @@ test each node with a reader that has only that node. Run exactly one round. Give the human a short summary in the progress update before review: per task, gaps found, how each was resolved, any moved to `major_decisions`, and any node left unchecked. +5. Lint the plan before opening the review: + + ```sh + "$archdev" --json tasks graph import --file plans/task-review.json --dry-run + ``` + + It writes nothing. Its `lint` list holds the deterministic plan lints and + `repository-rule` findings, which come from judging each node's brief + against this repository's rules (`.archdev/rules`, `rules/`) with Jev. + `tasks review start` runs the same checks and refuses to save while an + error stands. + - Fix each error in the node: rewrite the requirement the rule names, or + add an `Exemplar: ` line naming the sibling the task mirrors. + Re-run until no errors remain. + - Pass `--allow-lint ` (import) or `allow_lint` (review JSON) only + when the human approves that override. + - A `repository-rule` warning that says `not_evaluated` means the model + was unavailable. It does not block; re-run later. + - To see every rule's verdict for a node, run `"$archdev" extract run + plan.rule-verdicts --plan plans/task-review.json --json` and read the + receipt file it names. ## 4. Open the review and keep it running diff --git a/plugins/grok/skills/tasks/SKILL.md b/plugins/grok/skills/tasks/SKILL.md index 56b8cb5..79cc04c 100644 --- a/plugins/grok/skills/tasks/SKILL.md +++ b/plugins/grok/skills/tasks/SKILL.md @@ -177,8 +177,12 @@ content already has that shape: participants with labels of a few words, and about 4–8 messages. A wider diagram shrinks to fit the column and its text becomes unreadable. Draw one diagram instead of a paragraph that narrates the same sequence. -- Keep each implementation step to one or two lines. List touched files once - in `scope` instead of repeating paths in every step. +- Keep each implementation step to one or two lines. List the repository + paths the task changes once in `scope` (files, directories, or git globs + such as `src/api/export/`) instead of repeating them in every step. Write + paths, not a prose label like `"Export API"`: the repository-rule check + uses them to choose the rules for those languages and to read repository + context, and a label matches no files. - Label a guess as `Hypothesis:`, not as an observation. - Write a field that holds a fence or a table as a string array, one line per entry, as in the example below. Such an array is joined as raw markdown, so @@ -226,7 +230,7 @@ The review command also accepts optional `major_decisions` (not part of "grade": "low", "notes": "Reuses an existing, tested query path; blast radius is one new read-only endpoint." }, - "scope": ["Export API"], + "scope": ["src/api/export/", "tests/export-api.e2e.test.ts"], "exclusions": ["Scheduled exports"] }, { @@ -240,6 +244,7 @@ The review command also accepts optional `major_decisions` (not part of "grade": "low", "notes": ["Additive UI change on an existing button.", "No data model or auth changes."] }, + "scope": ["src/pages/results/", "tests/export-ui.e2e.test.ts"], "depends_on": ["export-api"], "dependency_reasons": {"export-api": "The download action needs the export endpoint."} } @@ -384,6 +389,27 @@ test each node with a reader that has only that node. Run exactly one round. Give the human a short summary in the progress update before review: per task, gaps found, how each was resolved, any moved to `major_decisions`, and any node left unchecked. +5. Lint the plan before opening the review: + + ```sh + "$archdev" --json tasks graph import --file plans/task-review.json --dry-run + ``` + + It writes nothing. Its `lint` list holds the deterministic plan lints and + `repository-rule` findings, which come from judging each node's brief + against this repository's rules (`.archdev/rules`, `rules/`) with Jev. + `tasks review start` runs the same checks and refuses to save while an + error stands. + - Fix each error in the node: rewrite the requirement the rule names, or + add an `Exemplar: ` line naming the sibling the task mirrors. + Re-run until no errors remain. + - Pass `--allow-lint ` (import) or `allow_lint` (review JSON) only + when the human approves that override. + - A `repository-rule` warning that says `not_evaluated` means the model + was unavailable. It does not block; re-run later. + - To see every rule's verdict for a node, run `"$archdev" extract run + plan.rule-verdicts --plan plans/task-review.json --json` and read the + receipt file it names. ## 4. Open the review and keep it running diff --git a/plugins/opencode/skills/tasks/SKILL.md b/plugins/opencode/skills/tasks/SKILL.md index 56b8cb5..79cc04c 100644 --- a/plugins/opencode/skills/tasks/SKILL.md +++ b/plugins/opencode/skills/tasks/SKILL.md @@ -177,8 +177,12 @@ content already has that shape: participants with labels of a few words, and about 4–8 messages. A wider diagram shrinks to fit the column and its text becomes unreadable. Draw one diagram instead of a paragraph that narrates the same sequence. -- Keep each implementation step to one or two lines. List touched files once - in `scope` instead of repeating paths in every step. +- Keep each implementation step to one or two lines. List the repository + paths the task changes once in `scope` (files, directories, or git globs + such as `src/api/export/`) instead of repeating them in every step. Write + paths, not a prose label like `"Export API"`: the repository-rule check + uses them to choose the rules for those languages and to read repository + context, and a label matches no files. - Label a guess as `Hypothesis:`, not as an observation. - Write a field that holds a fence or a table as a string array, one line per entry, as in the example below. Such an array is joined as raw markdown, so @@ -226,7 +230,7 @@ The review command also accepts optional `major_decisions` (not part of "grade": "low", "notes": "Reuses an existing, tested query path; blast radius is one new read-only endpoint." }, - "scope": ["Export API"], + "scope": ["src/api/export/", "tests/export-api.e2e.test.ts"], "exclusions": ["Scheduled exports"] }, { @@ -240,6 +244,7 @@ The review command also accepts optional `major_decisions` (not part of "grade": "low", "notes": ["Additive UI change on an existing button.", "No data model or auth changes."] }, + "scope": ["src/pages/results/", "tests/export-ui.e2e.test.ts"], "depends_on": ["export-api"], "dependency_reasons": {"export-api": "The download action needs the export endpoint."} } @@ -384,6 +389,27 @@ test each node with a reader that has only that node. Run exactly one round. Give the human a short summary in the progress update before review: per task, gaps found, how each was resolved, any moved to `major_decisions`, and any node left unchecked. +5. Lint the plan before opening the review: + + ```sh + "$archdev" --json tasks graph import --file plans/task-review.json --dry-run + ``` + + It writes nothing. Its `lint` list holds the deterministic plan lints and + `repository-rule` findings, which come from judging each node's brief + against this repository's rules (`.archdev/rules`, `rules/`) with Jev. + `tasks review start` runs the same checks and refuses to save while an + error stands. + - Fix each error in the node: rewrite the requirement the rule names, or + add an `Exemplar: ` line naming the sibling the task mirrors. + Re-run until no errors remain. + - Pass `--allow-lint ` (import) or `allow_lint` (review JSON) only + when the human approves that override. + - A `repository-rule` warning that says `not_evaluated` means the model + was unavailable. It does not block; re-run later. + - To see every rule's verdict for a node, run `"$archdev" extract run + plan.rule-verdicts --plan plans/task-review.json --json` and read the + receipt file it names. ## 4. Open the review and keep it running diff --git a/plugins/pi/skills/tasks/SKILL.md b/plugins/pi/skills/tasks/SKILL.md index 56b8cb5..79cc04c 100644 --- a/plugins/pi/skills/tasks/SKILL.md +++ b/plugins/pi/skills/tasks/SKILL.md @@ -177,8 +177,12 @@ content already has that shape: participants with labels of a few words, and about 4–8 messages. A wider diagram shrinks to fit the column and its text becomes unreadable. Draw one diagram instead of a paragraph that narrates the same sequence. -- Keep each implementation step to one or two lines. List touched files once - in `scope` instead of repeating paths in every step. +- Keep each implementation step to one or two lines. List the repository + paths the task changes once in `scope` (files, directories, or git globs + such as `src/api/export/`) instead of repeating them in every step. Write + paths, not a prose label like `"Export API"`: the repository-rule check + uses them to choose the rules for those languages and to read repository + context, and a label matches no files. - Label a guess as `Hypothesis:`, not as an observation. - Write a field that holds a fence or a table as a string array, one line per entry, as in the example below. Such an array is joined as raw markdown, so @@ -226,7 +230,7 @@ The review command also accepts optional `major_decisions` (not part of "grade": "low", "notes": "Reuses an existing, tested query path; blast radius is one new read-only endpoint." }, - "scope": ["Export API"], + "scope": ["src/api/export/", "tests/export-api.e2e.test.ts"], "exclusions": ["Scheduled exports"] }, { @@ -240,6 +244,7 @@ The review command also accepts optional `major_decisions` (not part of "grade": "low", "notes": ["Additive UI change on an existing button.", "No data model or auth changes."] }, + "scope": ["src/pages/results/", "tests/export-ui.e2e.test.ts"], "depends_on": ["export-api"], "dependency_reasons": {"export-api": "The download action needs the export endpoint."} } @@ -384,6 +389,27 @@ test each node with a reader that has only that node. Run exactly one round. Give the human a short summary in the progress update before review: per task, gaps found, how each was resolved, any moved to `major_decisions`, and any node left unchecked. +5. Lint the plan before opening the review: + + ```sh + "$archdev" --json tasks graph import --file plans/task-review.json --dry-run + ``` + + It writes nothing. Its `lint` list holds the deterministic plan lints and + `repository-rule` findings, which come from judging each node's brief + against this repository's rules (`.archdev/rules`, `rules/`) with Jev. + `tasks review start` runs the same checks and refuses to save while an + error stands. + - Fix each error in the node: rewrite the requirement the rule names, or + add an `Exemplar: ` line naming the sibling the task mirrors. + Re-run until no errors remain. + - Pass `--allow-lint ` (import) or `allow_lint` (review JSON) only + when the human approves that override. + - A `repository-rule` warning that says `not_evaluated` means the model + was unavailable. It does not block; re-run later. + - To see every rule's verdict for a node, run `"$archdev" extract run + plan.rule-verdicts --plan plans/task-review.json --json` and read the + receipt file it names. ## 4. Open the review and keep it running diff --git a/tasks/SKILL.md b/tasks/SKILL.md index 56b8cb5..79cc04c 100644 --- a/tasks/SKILL.md +++ b/tasks/SKILL.md @@ -177,8 +177,12 @@ content already has that shape: participants with labels of a few words, and about 4–8 messages. A wider diagram shrinks to fit the column and its text becomes unreadable. Draw one diagram instead of a paragraph that narrates the same sequence. -- Keep each implementation step to one or two lines. List touched files once - in `scope` instead of repeating paths in every step. +- Keep each implementation step to one or two lines. List the repository + paths the task changes once in `scope` (files, directories, or git globs + such as `src/api/export/`) instead of repeating them in every step. Write + paths, not a prose label like `"Export API"`: the repository-rule check + uses them to choose the rules for those languages and to read repository + context, and a label matches no files. - Label a guess as `Hypothesis:`, not as an observation. - Write a field that holds a fence or a table as a string array, one line per entry, as in the example below. Such an array is joined as raw markdown, so @@ -226,7 +230,7 @@ The review command also accepts optional `major_decisions` (not part of "grade": "low", "notes": "Reuses an existing, tested query path; blast radius is one new read-only endpoint." }, - "scope": ["Export API"], + "scope": ["src/api/export/", "tests/export-api.e2e.test.ts"], "exclusions": ["Scheduled exports"] }, { @@ -240,6 +244,7 @@ The review command also accepts optional `major_decisions` (not part of "grade": "low", "notes": ["Additive UI change on an existing button.", "No data model or auth changes."] }, + "scope": ["src/pages/results/", "tests/export-ui.e2e.test.ts"], "depends_on": ["export-api"], "dependency_reasons": {"export-api": "The download action needs the export endpoint."} } @@ -384,6 +389,27 @@ test each node with a reader that has only that node. Run exactly one round. Give the human a short summary in the progress update before review: per task, gaps found, how each was resolved, any moved to `major_decisions`, and any node left unchecked. +5. Lint the plan before opening the review: + + ```sh + "$archdev" --json tasks graph import --file plans/task-review.json --dry-run + ``` + + It writes nothing. Its `lint` list holds the deterministic plan lints and + `repository-rule` findings, which come from judging each node's brief + against this repository's rules (`.archdev/rules`, `rules/`) with Jev. + `tasks review start` runs the same checks and refuses to save while an + error stands. + - Fix each error in the node: rewrite the requirement the rule names, or + add an `Exemplar: ` line naming the sibling the task mirrors. + Re-run until no errors remain. + - Pass `--allow-lint ` (import) or `allow_lint` (review JSON) only + when the human approves that override. + - A `repository-rule` warning that says `not_evaluated` means the model + was unavailable. It does not block; re-run later. + - To see every rule's verdict for a node, run `"$archdev" extract run + plan.rule-verdicts --plan plans/task-review.json --json` and read the + receipt file it names. ## 4. Open the review and keep it running