Added nono profiles & orca integration - Added some extensions to start working on
This commit is contained in:
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: pptx
|
||||
description: Presentation creation, editing, and analysis. When OpenCode needs to work with presentations (.pptx files) for: (1) Creating new presentations, (2) Modifying or editing content, (3) Working with layouts, (4) Adding comments or speaker notes, or any other presentation tasks
|
||||
description: Presentation creation, editing, and analysis. When the harness needs to work with presentations (.pptx files) for: (1) Creating new presentations, (2) Modifying or editing content, (3) Working with layouts, (4) Adding comments or speaker notes, or any other presentation tasks
|
||||
license: Proprietary. LICENSE.txt has complete terms
|
||||
---
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: xlsx
|
||||
description: Comprehensive spreadsheet creation, editing, and analysis with support for formulas, formatting, data analysis, and visualization. When OpenCode needs to work with spreadsheets (.xlsx, .xlsm, .csv, .tsv, etc) for: (1) Creating new spreadsheets with formulas and formatting, (2) Reading or analyzing data, (3) Modify existing spreadsheets while preserving formulas, (4) Data analysis and visualization in spreadsheets, or (5) Recalculating formulas
|
||||
description: Comprehensive spreadsheet creation, editing, and analysis with support for formulas, formatting, data analysis, and visualization. When the harness needs to work with spreadsheets (.xlsx, .xlsm, .csv, .tsv, etc) for: (1) Creating new spreadsheets with formulas and formatting, (2) Reading or analyzing data, (3) Modify existing spreadsheets while preserving formulas, (4) Data analysis and visualization in spreadsheets, or (5) Recalculating formulas
|
||||
license: Proprietary. LICENSE.txt has complete terms
|
||||
---
|
||||
|
||||
|
||||
@@ -11,6 +11,7 @@ Scaffold the per-repo configuration that the design and develop skills assume:
|
||||
- **Issue tracker**: where issues live (Gitea by default; local markdown is also supported out of the box)
|
||||
- **Triage labels**: the strings used for the five canonical triage roles
|
||||
- **Domain docs**: where `CONTEXT.md` and ADRs live, and the consumer rules for reading them
|
||||
- **Sub-agents**: a basic instruction to delegate through Paseo's CLI
|
||||
|
||||
This is a prompt-driven skill, not a deterministic script. Explore, present what you found, confirm with the user, then write.
|
||||
|
||||
@@ -65,7 +66,7 @@ Offer **multi-context** (a root `CONTEXT-MAP.md` pointing to per-context `CONTEX
|
||||
|
||||
Show the user a draft of:
|
||||
|
||||
- The `## Agent skills` block to add to whichever of `CLAUDE.md` / `AGENTS.md` is being edited (see step 4 for selection rules)
|
||||
- The `## Agent skills` block to add to whichever of `CLAUDE.md` / `AGENTS.md` is being edited (see step 4 for selection rules), including the Paseo sub-agent instructions
|
||||
- The contents of `docs/agents/issue-tracker.md`, `docs/agents/domain.md`, and `docs/agents/triage-labels.md` (the last only when `triage` is installed)
|
||||
|
||||
Let them edit before writing.
|
||||
@@ -98,6 +99,10 @@ The block:
|
||||
### Domain docs
|
||||
|
||||
[one-line summary of layout: "single-context" or "multi-context"]. See `docs/agents/domain.md`.
|
||||
|
||||
### Sub-agents
|
||||
|
||||
Delegate sub-agent work through the Paseo CLI. Start work asynchronously in the current workspace with `paseo run --background --title "<task>" "<self-contained prompt>"`; use `--new-workspace worktree` plus the appropriate worktree mode when the task needs isolated edits. Use `paseo send <agent-id> "<follow-up>"` for follow-ups. Let Paseo's completion notification report the result instead of polling. Run `paseo --help`, `paseo run --help`, or `paseo provider ls` when launch details or provider availability are unclear.
|
||||
```
|
||||
|
||||
Include the `### Triage labels` sub-block, and write `docs/agents/triage-labels.md`, only when `triage` is installed and Section B ran. When it isn't, both are omitted.
|
||||
|
||||
@@ -0,0 +1,119 @@
|
||||
---
|
||||
name: nono-profiles
|
||||
description: "Author or revise repository-managed nono sandbox profiles. Use for nono profile changes, additional repository or client-directory access, filesystem grants, Internet access tiers and domain allowlists, Unix sockets, profile inheritance, validation, or troubleshooting profile permissions in this environment."
|
||||
---
|
||||
|
||||
# Nono Profiles
|
||||
|
||||
Author reviewed nono profiles from this repository, using `profiles/nono/pi-local.json` as the local starting point and `~/.config/nono/profiles/` only as the activation location.
|
||||
|
||||
## Process
|
||||
|
||||
### 1. Inspect the live policy
|
||||
|
||||
Locate the repository root and read:
|
||||
|
||||
- `profiles/nono/pi-local.json`
|
||||
- the requested target profile, when it exists
|
||||
- the target's entry under `~/.config/nono/profiles/`, including its resolved symlink target
|
||||
- the installed parent profile named by `extends`
|
||||
|
||||
Run `nono --version` and consult `nono profile --help` when command behavior is uncertain. Read [policy-fields.md](references/policy-fields.md) before changing inheritance, filesystem, network, credentials, or Unix-socket policy.
|
||||
|
||||
Summarize the current parent, working-directory policy, extra filesystem grants, network mode, URL-opening policy, service-launch policy, and active-link state. Treat inherited grants as additive unless the installed nono documentation and validator prove otherwise.
|
||||
|
||||
Completion criterion: account for every effective capability relevant to the requested change, including inherited capabilities.
|
||||
|
||||
### 2. Interview for the intended capability
|
||||
|
||||
Treat details already stated by the user as answers. Collect only unresolved choices with `ask_user`; use a short follow-up when exact paths or domains depend on an earlier answer.
|
||||
|
||||
Always resolve these decisions before drafting:
|
||||
|
||||
1. **Profile strategy** — ask whether to edit `pi-local` or create a named derived profile. Ask for a profile name and description when deriving.
|
||||
2. **Working set** — ask whether access covers only the launch working directory, a list of exact repositories/directories, or a shared parent containing multiple repositories.
|
||||
3. **Access mode** — collect read-only, write-only, or read/write access for every additional path, then map those labels to the profile fields. Recommend exact repositories over a broad client or source-code parent. State the broader blast radius before accepting a shared parent.
|
||||
4. **Internet tier** — offer:
|
||||
- **Offline**: block Internet access, URL opening, and service launching.
|
||||
- **Allowlisted**: enable networking only for an explicit hostname list; confirm URL-opening origins separately.
|
||||
- **Open**: enable unrestricted networking; confirm URL-opening origins separately.
|
||||
5. **Allowlisted hosts** — for allowlisted mode, identify the operations the project needs, then collect exact hostnames for code hosting, package registries, APIs, model providers, and artifact/CDN downloads. Distinguish required hosts from convenience hosts.
|
||||
|
||||
Ask about exact files, credential routes, and Unix sockets only when the request or inspected project indicates they are needed. Keep filesystem, Internet, credential, and Unix-socket decisions separate.
|
||||
|
||||
Completion criterion: map every requested capability to an exact path, hostname, credential route, or socket and an explicit access level.
|
||||
|
||||
### 3. Choose a safe parent
|
||||
|
||||
Use one `extends` parent; build a transitive chain rather than multiple inheritance.
|
||||
|
||||
Apply these inheritance rules:
|
||||
|
||||
- Extend `pi-local` when its filesystem grants, existing domain allowlist, URL-opening origins, and service-launch policy are acceptable as a minimum.
|
||||
- Extend `nolabs-ai/pi` for offline mode. Set `network.block` to `true`, clear `open_urls.allow_origins`, disable `open_urls.allow_localhost`, and set `allow_launch_services` to `false`. Do not extend allowlisted `pi-local`: inherited proxy domains conflict with blocked networking.
|
||||
- Extend `nolabs-ai/pi` rather than `pi-local` when an allowlisted child needs fewer domains than `pi-local`, or when creating an open-network profile. Reproduce only the required local filesystem/socket policy.
|
||||
- Edit `pi-local` only after showing how the change affects every future project launched with it.
|
||||
|
||||
An inherited broad capability cannot reliably be narrowed by an empty child array. Choose a restrictive parent instead.
|
||||
|
||||
### 4. Draft the policy
|
||||
|
||||
Create a candidate at `~/.config/nono/profile-drafts/<name>.json`. Keep the repository target at `profiles/nono/<name>.json`.
|
||||
|
||||
Apply least privilege:
|
||||
|
||||
- Use `workdir.access` for the runtime working directory.
|
||||
- Use directory fields for directory trees and exact-file fields for one file.
|
||||
- Prefer read-only grants for source or reference trees that need no mutation.
|
||||
- Use read/write grants only for repositories, caches, build output, or state that must change.
|
||||
- Use canonical resolved paths for symlinked resources where practical.
|
||||
- Keep hostname allowlists, URL-opening origins, service launching, and Unix socket allowlists independent.
|
||||
- Store hostnames, never URL paths, in `network.allow_domain`.
|
||||
|
||||
Preserve unrelated keys and user formatting when editing an existing profile.
|
||||
|
||||
### 5. Validate and review
|
||||
|
||||
Run:
|
||||
|
||||
```bash
|
||||
nono profile validate --draft <name> --strict
|
||||
nono profile show ~/.config/nono/profile-drafts/<name>.json
|
||||
```
|
||||
|
||||
Show:
|
||||
|
||||
- the proposed profile or focused diff
|
||||
- the resolved policy and selected inherited baseline
|
||||
- every added or removed filesystem capability
|
||||
- the selected Internet tier and all allowed domains
|
||||
- URL-opening origins and service-launch permission
|
||||
- any credential routes or Unix sockets
|
||||
- whether the repository target is already active through a symlink
|
||||
|
||||
Request explicit approval with `ask_user` before copying the validated draft into `profiles/nono/<name>.json`.
|
||||
|
||||
Completion criterion: validation passes and the user approves the exact policy diff.
|
||||
|
||||
### 6. Install without bypassing review
|
||||
|
||||
After approval, copy the validated candidate into the repository target, then run `nono profile validate --strict profiles/nono/<name>.json`. Do not write directly into `~/.config/nono/profiles/` from an agent running inside nono.
|
||||
|
||||
When the active profile already symlinks to the repository target, report that the next nono launch will use the change. Otherwise, provide this outside-sandbox activation step with resolved paths:
|
||||
|
||||
```bash
|
||||
ln -sfn /absolute/repo/profiles/nono/<name>.json ~/.config/nono/profiles/<name>.json
|
||||
nono profile validate <name>
|
||||
```
|
||||
|
||||
Use `nono profile promote <name>` only when the user wants nono to install the draft as a regular active profile instead of preserving the repository symlink convention. When replacing an existing regular profile, create the draft through nono's edit workflow or supply the required `<name>.base` SHA-256 guard described in [policy-fields.md](references/policy-fields.md); never bypass concurrent-change protection.
|
||||
|
||||
For denied paths in the current sandbox, diagnose the concrete operation with:
|
||||
|
||||
```bash
|
||||
nono why --self --path /resolved/path --op read
|
||||
```
|
||||
|
||||
Use `write` or `readwrite` for the corresponding operation. Explain that policy changes apply to a newly launched sandbox, not the current process.
|
||||
|
||||
Completion criterion: the repository profile is approved and valid, activation instructions preserve the chosen repository-link convention, and remaining restart steps are explicit.
|
||||
@@ -0,0 +1,139 @@
|
||||
# Nono policy fields in this environment
|
||||
|
||||
Consult this reference when mapping interview answers into a profile. Treat `nono profile validate` and the installed parent profiles as authoritative for the installed nono version.
|
||||
|
||||
## Inheritance
|
||||
|
||||
Use a single string-valued `extends`. Local profiles may extend `pi-local`, registry profiles such as `nolabs-ai/pi`, or another available profile. Inheritance is transitive.
|
||||
|
||||
Treat included groups and list-valued capabilities as additive. An empty child list does not establish revocation. To create a narrower policy, derive from a narrower parent and add only the required capabilities.
|
||||
|
||||
## Runtime working directory
|
||||
|
||||
`workdir.access: "readwrite"` grants the directory from which nono launches the process. It does not mean the directory containing the profile.
|
||||
|
||||
Use the working-directory grant for a single active repository. Add explicit filesystem paths when one session needs several repositories or client directories.
|
||||
|
||||
## Filesystem access
|
||||
|
||||
Use directory fields for recursive directory-tree access:
|
||||
|
||||
| Field | Capability |
|
||||
| --- | --- |
|
||||
| `filesystem.read` | Read a directory tree |
|
||||
| `filesystem.write` | Write a directory tree |
|
||||
| `filesystem.allow` | Read and write a directory tree |
|
||||
|
||||
Use exact-file fields for one file:
|
||||
|
||||
| Field | Capability |
|
||||
| --- | --- |
|
||||
| `filesystem.read_file` | Read one file |
|
||||
| `filesystem.write_file` | Write one file |
|
||||
| `filesystem.allow_file` | Read and write one file |
|
||||
|
||||
Prefer enumerating exact repositories. Grant a shared parent only after confirming that every current and future child directory may receive the selected capability.
|
||||
|
||||
Resolve symlinks before reasoning about access. nono enforcement and audit output may use canonical targets.
|
||||
|
||||
## Internet tiers
|
||||
|
||||
### Offline
|
||||
|
||||
Derive from `nolabs-ai/pi`, not allowlisted `pi-local`. Inherited proxy domains conflict with blocked networking. Clear the inherited URL-opening and service-launch capabilities too:
|
||||
|
||||
```json
|
||||
{
|
||||
"extends": "nolabs-ai/pi",
|
||||
"network": {
|
||||
"block": true
|
||||
},
|
||||
"open_urls": {
|
||||
"allow_origins": [],
|
||||
"allow_localhost": false
|
||||
},
|
||||
"allow_launch_services": false
|
||||
}
|
||||
```
|
||||
|
||||
Validate the resolved policy and confirm that it reports `network blocked` with no approved URL origins.
|
||||
|
||||
### Allowlisted
|
||||
|
||||
Set networking enabled with a non-empty hostname list:
|
||||
|
||||
```json
|
||||
{
|
||||
"network": {
|
||||
"block": false,
|
||||
"allow_domain": [
|
||||
"example.internal",
|
||||
"registry.npmjs.org"
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Use hostnames only. URL paths belong in credential endpoint rules, not `allow_domain`.
|
||||
|
||||
Inherited hostname lists may remain effective. Derive from `nolabs-ai/pi` when the intended list must be smaller than `pi-local`'s list.
|
||||
|
||||
Collect domains by operation rather than guessing:
|
||||
|
||||
- source fetch and issue API
|
||||
- package metadata and package artifacts/CDNs
|
||||
- language toolchains and binary downloads
|
||||
- model or application APIs
|
||||
- deployment, telemetry, or error reporting
|
||||
|
||||
### Open
|
||||
|
||||
Set networking enabled without a domain allowlist inherited from the chosen parent. Derive from `nolabs-ai/pi`, not an allowlisted `pi-local`, unless installed documentation proves the inherited allowlist can be removed.
|
||||
|
||||
```json
|
||||
{
|
||||
"network": {
|
||||
"block": false
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
State that open mode allows destinations beyond those currently known to the project.
|
||||
|
||||
## URL opening and service launching
|
||||
|
||||
`open_urls.allow_origins` controls origins that sandboxed tools may ask the host to open. `open_urls.allow_localhost` controls localhost URL opening. These capabilities remain separate from direct Internet access.
|
||||
|
||||
`allow_launch_services` controls service launching on supported platforms. Set it to `false` for offline profiles and inspect the inherited value for other tiers.
|
||||
|
||||
The installed `nolabs-ai/pi` parent enables selected OpenAI, Anthropic, and GitHub origins, localhost URL opening, and service launching. Child profiles must review those inherited settings rather than assuming `network.block` or `allow_domain` controls them.
|
||||
|
||||
## Unix sockets
|
||||
|
||||
`filesystem.unix_socket` controls pathname-mediated Unix sockets independently of Internet networking. Add only exact socket paths required by local services. Diagnose socket denials separately from domain denials.
|
||||
|
||||
## Credentials
|
||||
|
||||
Treat a credential route as a separate capability from reaching its domain. Confirm both the route and endpoint restrictions. Prefer nono-mediated credential routes over exposing real API keys inside the sandbox.
|
||||
|
||||
## Local sources of truth
|
||||
|
||||
Read these when behavior or schema details are uncertain:
|
||||
|
||||
- `profiles/nono/pi-local.json`
|
||||
- `~/.config/nono/packages/nolabs-ai/pi/profiles/pi.json`
|
||||
- `~/.config/nono/packages/nolabs-ai/pi/README.md`
|
||||
- `~/.config/nono/packages/nolabs-ai/pi/skills/nono-sandbox/SKILL.md`
|
||||
- `/usr/share/doc/nono-ai-bin/README.md`
|
||||
- `nono profile --help`
|
||||
|
||||
Stage candidates under `~/.config/nono/profile-drafts/`, then inspect them with:
|
||||
|
||||
```bash
|
||||
nono profile validate --draft <name> --strict
|
||||
nono profile show ~/.config/nono/profile-drafts/<name>.json
|
||||
```
|
||||
|
||||
Validate the repository copy with `nono profile validate --strict profiles/nono/<name>.json`.
|
||||
|
||||
When promoting over an existing regular active profile, nono requires `~/.config/nono/profile-drafts/<name>.base` to contain the active profile's lowercase SHA-256 digest. Prefer nono's profile-edit workflow to create this guard. Preserve the repository symlink convention instead of promotion when the profile belongs in this repository.
|
||||
@@ -0,0 +1,69 @@
|
||||
---
|
||||
name: subagents
|
||||
description: invoke this skill when the user asks you to use subagents
|
||||
---
|
||||
|
||||
# Subagents
|
||||
|
||||
Each subagent is headless, has its own context window, cannot see the parent conversation, cannot ask the user, and cannot spawn subagents or workflows. Give every child a self-contained prompt with paths, constraints, and the expected report.
|
||||
|
||||
## Pi Harness
|
||||
|
||||
**Harness:** `pi`
|
||||
**Prompt nicknames:** “pi”, “pi agent”, “pi subagent”
|
||||
**Best default:** Use when the user does not request another harness. It inherits the parent model and thinking level when `model` or `reasoning_effort` is omitted.
|
||||
|
||||
Do not use models from the Anthropic provider even if one appears in the model list.
|
||||
|
||||
Pi can use any model shown by `pi --list-models`. Prefer `provider/model-id`; a bare model id only works when unambiguous. Common picks in this environment:
|
||||
|
||||
| Model | Recommended effort |
|
||||
| -------------------------------- | ------------------ |
|
||||
| inherited parent model (default) | inherited |
|
||||
| `openai-codex/gpt-5.6-sol` | `high` |
|
||||
| `openai-codex/gpt-5.6-terra` | `high` |
|
||||
| `opencode/claude-fable-5` | `medium` |
|
||||
|
||||
**Thinking budgets:** `off`, `minimal`, `low`, `medium`, `high`, `xhigh`, `max`. These map directly to pi thinking levels.
|
||||
|
||||
## Claude Code Harness
|
||||
|
||||
**Harness:** `claude`
|
||||
**Prompt nicknames:** “claude”, “Claude Code”, “claude agent”, “claude subagent”, "cc"
|
||||
**Best default:** use the latest fable model on high reasoning. Do not default to anything else, if the user does not specify, use fable.
|
||||
|
||||
| Model hint | Model | Recommended effort |
|
||||
| ---------- | ------------------- | ------------------ |
|
||||
| `fable` | latest Claude Fable | `high` |
|
||||
|
||||
**Thinking budgets:** `off`, `minimal`, `low`, `medium`, `high`, `xhigh`, `max`. The extension maps these to Claude thinking-token budgets: 0, 1,024, 4,096, 10,000, 16,000, 32,000, and 63,999 tokens respectively.
|
||||
|
||||
Requires Claude Code to be installed and authenticated.
|
||||
|
||||
## Codex Harness
|
||||
|
||||
**Harness:** `codex`
|
||||
**Prompt nicknames:** “codex”, “Codex CLI”, “codex agent”, “codex subagent”
|
||||
**Best default:** `gpt-5.6-sol` with `high` effort for coding work. Do not use anything other than sol unless the user specifically asks for it.
|
||||
|
||||
| Model | Recommended effort |
|
||||
| --------------- | ------------------ |
|
||||
| `gpt-5.6-sol` | `high` |
|
||||
| `gpt-5.6-terra` | `high` |
|
||||
| `gpt-5.6-luna` | `high` |
|
||||
|
||||
**Thinking budgets accepted by the extension:** `off`, `minimal`, `low`, `medium`, `high`, `xhigh`, `max`. Codex maps these to the nearest effort supported by the selected model; `off`/`minimal` become `minimal`, while `max` becomes the highest extension-supported Codex effort.
|
||||
|
||||
Requires the Codex CLI to be installed and authenticated.
|
||||
|
||||
## Spawn and Manage
|
||||
|
||||
Call `subagent_spawn` with a complete `prompt`, short `name`, chosen `harness`, and optional `working_dir`, `model`, and `reasoning_effort`. At most four subagents run concurrently.
|
||||
|
||||
- `subagent_check({ id })`: peek without blocking.
|
||||
- `subagent_list()`: list all runs.
|
||||
- `subagent_wait({ ids })`: block only when results are required to proceed.
|
||||
- `subagent_cancel({ ids })`: stop runs while preserving partial transcripts.
|
||||
- `/subagents`: inspect or take over a run interactively.
|
||||
|
||||
Results return automatically. After spawning, continue useful parent work instead of immediately waiting.
|
||||
Reference in New Issue
Block a user