Project

/as:project — Project Setup and Memory

Harness note: use /as:<skill> on Claude Code and $<skill> on Codex. Resolve <skill-root> as the directory containing this loaded SKILL.md and <plugin-root> as the plugin root that contains skills/, and use equivalent native tools when host tool names differ.

/as:project is the only project-memory interface. It owns current facts in PROJECT.md and durable reasoning in decisions/*.md without combining those record types or duplicating a decision index.

Commands

/as:project init
/as:project status
/as:project update
/as:project remember <information>
/as:project decisions
/as:project record-decision <choice>
/as:project supersede <number>
/as:project migrate

Hard boundaries

1. PROJECT.md contains sourced current facts. Decision identity, status, rationale, and history live only in decisions/*.md.
2. PROJECT.md links to decisions/ but has no Decisions table and never copies decision metadata.
3. Never write STUDIO.md. /as:studio alone owns the manifest.
4. Never create a nested project beneath an existing PROJECT.md.
5. Every durable mutation is previewed and requires affirmative confirmation.
6. Preserve malformed records. A parse failure means unknown, not absent or approved.
7. Use project-relative links; never persist machine-specific absolute paths.

Resolve the project root

Run <plugin-root>/skills/project/scripts/resolve-context.sh from the current or explicitly supplied directory and follow references/context-resolution.md. PROJECT.md is the only implicit project boundary. A nearer project inside a monorepo wins over outer repository metadata; typed-record directories, task/time files, Claude instructions, git roots, and the current directory never establish a project. Stop on invalid; use the validated picker for studio-picker; and never write before one exact project is resolved.

/as:project init

1. If the current path resolves an existing PROJECT.md, show status and do not create a nested project.
2. If a STUDIO.md is resolved, route creation to /as:studio create-project. Do not mutate the studio manifest and do not call back recursively after /as:studio has begun its confirmed orchestration.
3. Outside a studio, ask whether to initialize a studio or create a standalone project. Standalone creation requires explicit confirmation.
4. Gather the project name, optional ID, and exact target. Normalize the directory to lowercase kebab-case, prefixing a supplied ID. When no ID is supplied, use the folder slug as the stable local ID. Reject unsafe names, separators, dot segments, control characters, existing files, and non-empty directories. Never silently suffix a project identity.
5. Preview the exact path and full bundle. State that no git repository, ALPA account, or cloud service will be created.
6. After confirmation, run <plugin-root>/skills/project/scripts/project-workspace.sh init <target> <name> <project-id> project and verify every file and directory. Standalone projects always use a project-local task register; portfolio mode belongs to a studio.
7. Report the exact created path plus the .agents/skills/ (Codex) and .claude/skills/ (Claude Code) extension paths. Explain that the active harness should be restarted from the intended project directory if new project-only skills are not visible.

/as:project status

Read PROJECT.md, scan decisions/*.md directly, and summarize known facts, record counts, decision statuses, open tasks, and recent dated records. If an owning STUDIO.md declares portfolio task mode, read open tasks for this Project ID from the studio-root register; otherwise read the project register. Report duplicate decision numbers or malformed files. Do not consult or create a decision index.

Facts: update and remember

Every fact has a value, source, and date. Update an existing fact in place; append only genuinely new facts to the correct section. Git or the file-sharing system preserves history.

For /as:project remember or a natural memory request:

1. Read the exact input and relevant project records.
2. Classify each item as fact-like, decision-like, or mixed:
   • fact-like states a current, sourceable project condition;
   • decision-like expresses a choice, selection, rejection, approval, or rationale;
   • mixed contains separable facts and choices.
3. Preview grouped destinations. Facts show the PROJECT.md section, value, source, and date. Decisions show the proposed decision record.
4. Ask which grouped changes to apply. Confirmation of a source record is not authorization to promote every candidate.
5. Write only selected items, then re-read and verify.

When importing a selected item from minutes or a site report, require its exact project-relative path and stable item label. Read it and preserve its epistemic status. Reported, discussed, interpreted, proposed, or uncertain content cannot silently become a verified fact.

Decisions

/as:project decisions

Discover decisions/*.md independently. Report number, title, status, and path for each parseable record, plus duplicate numbers, missing/unrecognized statuses, and malformed files. Filenames and files are canonical; no PROJECT.md table participates.

/as:project record-decision

1. Scan every decision filename. Allocate max parseable number + 1, zero-padded to four digits; never reuse a number because another record is malformed.
2. Capture one choice per record: context, at least two honestly stated options, status (proposed or decided), deciders, the call, consequences, and source links. Pull from conversation first and ask one grouped question only for missing pieces.
3. A proposed source item remains proposed unless the user affirmatively says the choice was made.
4. Preview the complete record and collision-free path. Wait for confirmation.
5. Write decisions/NNNN-slug.md, re-read it, and verify number, status, title, and backlinks. Do not update PROJECT.md with decision metadata.

/as:project supersede <number>

1. Resolve exactly one parseable decided record. Stop on missing, ambiguous, malformed, or already-superseded records.
2. Allocate a replacement normally. Preview the complete new record and the old record’s single status change together.
3. After confirmation, create and verify the replacement first; only then change the old status to superseded by NNNN and verify both cross-links.
4. On a later failure, preserve the verified replacement, report the exact partial state, and offer recovery against those records. Never allocate another replacement number for recovery.

/as:project migrate

Migration removes the legacy Decisions table only when it is lossless:

1. Read PROJECT.md and discover all decision files.
2. Parse every legacy table row conservatively and match it to exactly one decision file by number plus compatible identity/status.
3. Missing files, duplicate numbers, malformed rows, or status disagreements block mutation. Report exact rows and paths.
4. If every row is accounted for, preview replacing the entire legacy section/table with the stable decisions/ link while preserving all unrelated content byte-for-byte.
5. After confirmation, run the helper migration, re-read PROJECT.md, and verify the table is gone, the link exists, and all decision files are unchanged.
6. A project already using the link-only contract reports “already migrated” without mutation.

Typed record handoffs

• Minutes and site reports may propose selected facts or decisions; /as:project re-reads and confirms them.
• /as:workplan reads facts and decision files but writes only its plan.
• /as:tasklist owns task rows in the canonical project or portfolio TASKS.md; /as:studio alone owns the studio task-mode setting; /as:timetracker owns TIMELOG.md.
• Project registration state and archive belong to /as:studio, not /as:project.

Collaboration and harness boundary

These are plain local files shared however the project already is. This local plugin creates no ALPA account or server. Cross-skill invocation and structured questions are enhancements; when unavailable, preserve completed work and print the exact follow-up command.