|
|
@@ -7,11 +7,21 @@ description: Decision-tree questioning until no doubt remains. Checks wiki QUEST
|
|
|
|
|
|
|
|
|
|
|
|
Every jsc skill that needs user input MUST follow the rules in this skill.
|
|
|
|
Every jsc skill that needs user input MUST follow the rules in this skill.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## Session cache
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Inside one work session this skill is the only writer of `QUESTION_{HASH}` and `QUESTION_CONTENTS`, so both pages are read once and reused.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
1. First call of the session: read both pages and keep them as the session copy. Done when the session holds each page's content, or the note that the page does not exist yet.
|
|
|
|
|
|
|
|
2. Every later call of the session: answer from the session copy. Done when this round's questions are matched against the session copy with no new wiki read.
|
|
|
|
|
|
|
|
3. Right after this skill writes either page: overwrite that page's session copy with the content just written. Done when the session copy equals the written content.
|
|
|
|
|
|
|
|
4. The cache expires with the work session, and only with it. Done when a new session starts again at step 1.
|
|
|
|
|
|
|
|
|
|
|
|
## Before asking
|
|
|
|
## Before asking
|
|
|
|
|
|
|
|
|
|
|
|
1. Confirm the repository name `{owner}/{repo}` of the current work. Done when `{owner}/{repo}` is known, or when it is settled that none exists — then skip steps 2 and 3, ask directly, and do NOT record.
|
|
|
|
1. Confirm the repository name `{owner}/{repo}` of the current work. Done when `{owner}/{repo}` is known, or when it is settled that none exists — then skip steps 2 to 4, ask directly, and do NOT record.
|
|
|
|
2. Compute `HASH` by running `jsc-gitea/tools/hash-id {owner}/{repo}` (the shared wiki hash rule — see guidelines.md for the algorithm). Done when the 8-character `HASH` is known.
|
|
|
|
2. Compute `HASH` by running `jsc-gitea/tools/hash-id {owner}/{repo}` (the shared wiki hash rule — see `jsc-meta/references/guidelines.md` for the algorithm). Exit 0: take the printed 8-character `HASH`. Exit 1 (no SHA-1 helper on this machine): stop the run and report that `sha1sum` or `shasum` must be installed first; never hand-compute the hash and never guess a page name. Any other non-zero exit: stop the same way and report the exit code with the command's stderr. Done when the 8-character `HASH` is known, or the run stopped with that report.
|
|
|
|
3. Read `QUESTION_CONTENTS` and `QUESTION_{HASH}` via `jsc-gitea:wiki`. Never re-ask a question already answered in the record; use the recorded answer directly. When reusing an answer, read the section's recorded intent: reuse it when that intent matches the current situation, and ask again when it differs, instead of forcing the old answer. An answer whose intent covers a similar undecided question in this round answers that one too. Done when every question in this round is marked either answered-from-record with the citing section named, or to-be-asked.
|
|
|
|
3. Resolve the `QUESTION` wiki repo once per session through `jsc-gitea:wiki`. When that skill reports exit 3 for `wiki-repo QUESTION` (neither `JSC_WIKI_REPO_QUESTION` nor `JSC_WIKI_REPO` is set), ask the user for that `{owner}/{repo}`, then keep the answer in the session and reuse it for every later call — this one answer cannot come from the record, because the wiki location is the question itself, so asking again each call would loop forever. Close the run by advising the user to set `JSC_WIKI_REPO_QUESTION` (or `JSC_WIKI_REPO`) in the environment, which ends the asking permanently. Done when the session holds one `{owner}/{repo}` for `QUESTION` and no later call in this session asked for it again.
|
|
|
|
|
|
|
|
4. Load `QUESTION_CONTENTS` and `QUESTION_{HASH}` per "Session cache". A page reported missing (`wiki-get` exit 4) counts as "no record yet": keep going and ask every question of this round. Any other `jsc-gitea:wiki` failure stops the run with a report of the failing page and the underlying exit code; do not ask on a half-read record, because an answer already on file would be asked again. Never re-ask a question already answered in the record; use the recorded answer directly. When reusing an answer, read the section's recorded intent: reuse it when that intent matches the current situation, and ask again when it differs, instead of forcing the old answer. An answer whose intent covers a similar undecided question in this round answers that one too. Done when every question in this round is marked either answered-from-record with the citing section named, or to-be-asked.
|
|
|
|
|
|
|
|
|
|
|
|
## Questioning rules
|
|
|
|
## Questioning rules
|
|
|
|
|
|
|
|
|
|
|
@@ -24,6 +34,5 @@ Every jsc skill that needs user input MUST follow the rules in this skill.
|
|
|
|
## After asking
|
|
|
|
## After asking
|
|
|
|
|
|
|
|
|
|
|
|
1. Without a repository name, do not record; stop here. Done when the answers are handed back to the calling skill and no wiki page was touched.
|
|
|
|
1. Without a repository name, do not record; stop here. Done when the answers are handed back to the calling skill and no wiki page was touched.
|
|
|
|
2. After each Q&A round, apply `templates/question-record.md` to create or update `QUESTION_{HASH}` (append new entries; never overwrite old records). Each section MUST open with the user's original intent (why this questioning round happened), per the template; it lets a later reader judge why the user chose as they did and whether the answer still applies. Done when a section for this round exists on `QUESTION_{HASH}`, carries this round's intent and every answer, and every section written by an earlier round is still there.
|
|
|
|
2. After each Q&A round, hand both wiki writes to one sub agent. That sub agent MUST write through `jsc-gitea:wiki` — it owns the `JSC_WIKI_REPO_QUESTION` → `JSC_WIKI_REPO` resolution and the tea-token fallback, which a hand-rolled Gitea API call loses. It writes `QUESTION_{HASH}` first, applying `templates/question-record.md`: append this round as a new section, keep every earlier section, and open the section with the user's original intent (why this questioning round happened), which lets a later reader judge why the user chose as they did and whether the answer still applies. It then writes `QUESTION_CONTENTS`, applying `templates/question-contents.md`: read the page back, add the `{owner}/{repo}` row when missing, otherwise set 最後更新 to this run's timestamp, then write the whole page. `QUESTION_CONTENTS` is a directory shared by every repository, so it is never overwritten wholesale and no other repository's row is touched; `QUESTION_{HASH}` belongs to this one repository, which is why appending a section to it is the right shape there. Its read branches by exit code, and only exit 4 creates the directory from the template: exit 0 upserts into the content that came back, while exit 7 (key invalid or no permission) and exit 8 (any other API failure) both mean the old rows are unknown, so the write is abandoned and reported instead — a fresh template over a directory whose rows were never read erases every other repository's row, with no merge and no backup behind it. Content page first, contents page second, so the contents page never links a page that failed to write. Done when the sub agent has reported both writes as succeeded and the main agent has accepted that one report — this single confirmation covers both pages and both templates; do not re-read the pages to prove it.
|
|
|
|
3. Apply `templates/question-contents.md` to create or update `QUESTION_CONTENTS` (add the repository row if missing; otherwise refresh its last-updated time). Done when the row for `{owner}/{repo}` carries 最後更新 equal to this run's timestamp.
|
|
|
|
3. On a reported write failure, retry that one page once. Done when the retry succeeded and step 3 of "Session cache" refreshed that page's copy, or — when the retry also failed — the run stops with a report naming the page that stayed unwritten and the exit code behind it, while the answers still go back to the calling skill and the report states plainly that nothing was recorded.
|
|
|
|
4. The wiki writes above MUST run as a sub agent, and that sub agent MUST write both `QUESTION_{HASH}` and `QUESTION_CONTENTS` through `jsc-gitea:wiki` — it owns the `JSC_WIKI_REPO_QUESTION` → `JSC_WIKI_REPO` resolution and the tea-token fallback, which a hand-rolled Gitea API call loses. Completion condition: the main agent has confirmed both writes succeeded.
|
|
|
|
|
|
|
|
