requirement-ledger

Astra Skill Optimizer

Adapt your Skills to GPT-6/Astra. Build toward Jarvis.

Short term: Astra Skill Optimizer keeps existing Skills usable as GPT-6/Astra behaviour changes. Long term: it becomes Jarvis, a personal project manager that keeps goals, requirements, decisions, blockers, and next actions aligned through a focused conversation.

The current release starts with evidence-bound Skill adaptation: select one project and its related Skills, identify outdated constraints, propose the smallest authorized change, and verify the result.

Plain language here does not mean the shortest possible answer. It means a decision-complete explanation: conclusion first, then enough evidence, impact, action, and acceptance detail for the user to understand the problem without translating jargon or asking what the report means.

Astra Skill Optimizer is the current public product and repository identity. The legacy Python package and CLI remain as compatibility entry points during migration. The current plugin is a thin Skill workflow; complete GPT-6/Astra adaptation still requires real project feedback.

中文说明 · product completion contract · stable contract · roadmap · security · Codex alignment

The repository naming migration and public metadata alignment are tracked separately from historical release records.

Quick start

Clone the repository and install the local Codex plugin:

git clone https://github.com/adand-91/gpt-6-astra-skill.git
cd gpt-6-astra-skill
codex plugin marketplace add "$PWD"
codex plugin add gpt6-astra-skill-optimizer@requirement-ledger-local
codex plugin add requirement-ledger@requirement-ledger-local

The first plugin audits Skills; the second provides the Jarvis project-report workflow. Select one project, start a fresh Codex task, and ask for a Skill audit:

Please audit this project and its related Skills for GPT-6/Astra.
Explain the current problem, what an improvement would change, and one next step.

For project takeover instead, say:

Hi Jarvis, take over this project. Recover its goal, current stage,
blocker, and one next action. Do not modify it.

An audit or read-only takeover does not change files. A clear request to implement a scoped fix permits that fix and its validation without repeated permission questions. Publication and other external actions need authorization covering those actions.

See the 1.0.3 changes and verification limits.

Why it exists

Long AI-assisted projects lose decisions inside chat: the current goal drifts, old requirements reappear as facts, useful behaviour gets removed during a fix, and a digest is mistaken for proof that a report is true or approved. Astra Skill Optimizer gives GPT-6/Astra workflows a narrow compatibility loop:

one selected target
  -> goal and current stage
  -> main problem and preserved behaviour
  -> one reviewable improvement
  -> explicit next action and authority
  -> optional exact-source binding and handoff check

It does not discover every task, scan a home directory, edit the target, or turn analysis into permission.

What Jarvis does after installation

Select one Codex task or project and start with the quick-start prompt above. Jarvis then:

• restores the goal, current stage, evidence freshness, and blocker;
• separates verified facts, inferences, and unknowns;
• recommends one next action and states the required authority; and
• leaves a checkpoint that another task can continue from.

If the host does not select the Skill automatically, retry once explicitly: $requirement-ledger-workflow Hi Jarvis, take over this selected project.

The first screen should look like this—not like a request for JSONL paths or schema fields:

# Project goal
...
## Overall progress: scope is not fixed; cannot calculate
Current work area: ...
## Current-area progress: scope is not fixed; cannot calculate
Current blocker: none.
No decision is needed from you now.
# Next step
...
Completion test: ...

This quick result is a host-selected / unbound Codex decision aid. Evidence or authority appears in plain language only when it changes the next action; the first screen has no fixed technical metadata line. It is not a CLI-created source pack, final report, or handoff identity.

Three answer depths

Jarvis does not print the complete project card after every message.

Daily and weekly reports keep their own fixed layouts. The daily report ends with one highest-value next action; the weekly report may rank up to three next-period actions. Neither mode mechanically prepends the ordinary project card.

Six project-manager scenes

Jarvis chooses one primary scene from ordinary language. It does not ask the user to select an internal workflow first.

An ordinary report offers at most three prompts relevant to the current stage. The complete menu appears only when the user asks what Jarvis can do. For unfamiliar implementation work, Jarvis can first check available Skills, official tools, original GitHub projects, documentation, and relevant public forums, then explain what is worth reusing. Discovery does not itself install or run a candidate. Visible user corrections and reproduced failures can become focused improvement candidates; Jarvis does not claim passive observation, automatic memory, or background learning. Daily and weekly reports can run on demand; unattended delivery still needs a separately configured schedule and notification path.

Two review levels

The v1 CLI's review-init --mode audit remains part of the second level and therefore still requires explicit --start, --end, and --timezone. The plugin must never imply that a quick audit already passed the evidence-bound chain.

The complete target experience and its release gates are defined in the Jarvis v1 product completion contract. The Python C